1
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@startdevin(Devin 太郎)

DevinのMCP連携でバグ調査はどう変わる？調べてみた

1
Posted at

きっかけ

Devinを使っていて、「ログを手動でコピペして渡す」という作業が気になっていました。「このバグ、Datadogのログを見ないとわからない」「Sentryのエラー詳細を確認してほしい」——そんな依頼をするたびに、一度自分でログを検索して、コピーして、Devinに渡す。

バグ修正自体よりも「調査の準備」に時間がかかっている気がする。もっと効率化できないか？

そんな中、DevinがMCP（Model Context Protocol）に対応したというアナウンスを見つけました。MCPを使えば、Devinが直接Datadogやデータベースにアクセスできるようになるとのこと。どんな機能なのか、公式ドキュメントや関連記事を調べてみました。

MCPとは何か

MCP（Model Context Protocol）は、AIエージェントが外部ツールやデータソースと安全に通信するためのオープンプロトコルです。Anthropicが2024年11月に発表し、2025年12月にはLinux Foundation傘下のAgentic AI Foundationに寄贈されました。

要するに、「Devinに渡すツールボックス」です。MCPサーバーが接続の確立、ツール実行、結果処理を裏側で処理してくれるので、ユーザーもDevinも技術的な詳細を気にする必要がありません。

MCP Marketplaceの使い方

DevinにはMCP Marketplaceが用意されており、Settings > MCP Marketplaceから簡単に有効化できます。

多くのMCPはワンクリックで有効化できます。Vercel、Notion、Sentry、Neon、Asanaなどは、Enableをクリックするだけ。認証が必要なものは、初回セッションで自動的にプロンプトが表示されます。

利用可能なMCPの例

カテゴリ MCP 用途
モニタリング Datadog, Sentry, Vercel ログ分析、エラー追跡
チケット管理 Linear, Asana, Jam タスク作成、進捗管理
データベース PostgreSQL, MySQL, BigQuery, Neon データ分析、クエリ実行
ドキュメント Notion, Google Docs ドキュメント作成・更新
デザイン Figma デザイン参照
開発 GitHub, CircleCI, SonarQube CI/CD連携、コード品質

バグ調査ワークフローの変化

Cognitionの公式ブログでは、MCP連携によってバグ調査のワークフローがどう変わるか紹介されています。

Before: 手動で情報を集める場合

  1. Slackでバグ報告を受け取る
  2. Datadogを開いてエラーログを検索（5分）
  3. 該当ログをコピー
  4. Devinに貼り付けて調査を依頼
  5. 追加情報が必要になるたびに繰り返し

After: MCPで自動化した後

  1. Slackでバグ報告を受け取る
  2. Devinに「金曜デプロイ後の /billing ページの500エラーを調査して」と依頼
  3. Devinが自動で：
    • Datadogからエラーログを取得
    • データベースをクエリしてデータ状態を確認
    • git historyで原因コミットを特定
    • 修正とリグレッションテストを作成
    • PRを作成

Cognitionの内部では、バグレポートが来た時点で「調査は既に終わっている」状態を目指しているそうです。ここまで自動化できれば、かなりの時間短縮になりそうです。

MCPの設定方法

トランスポートタイプ

Devinは3つのトランスポートタイプをサポートしています。

タイプ 用途 設定項目
STDIO ローカルCLIベースのサーバー（npx, uvx, Docker） コマンド、引数、環境変数
SSE リモートサーバー（Server-Sent Events） サーバーURL、ヘッダー（非推奨）
HTTP リモートサーバー（Streamable HTTP） サーバーURL、ヘッダー（推奨）

新しい連携ではHTTPが推奨されています。SSEは非推奨になりつつあるので、これから設定する場合はHTTPを選びましょう。

Datadogの設定例

Datadogを接続するには、2つのヘッダーが必要です。

  1. DD-API-KEY: Organization Settings > API Keys から取得
  2. DD-APPLICATION-KEY: Organization Settings > Application Keys から取得

また、Datadogのサイト/リージョン（US1, US3, US5, EU, AP1, AP2）を選択する必要があります。なお、GovCloud（US1-FED）はMCPサーバー非対応です。

カスタムMCPの追加

Marketplaceにないツールも、「Add Your Own」から追加できます。

例えば、社内APIをMCPサーバーとして公開し、Devinから直接クエリできるようにすることも可能です。STDIOトランスポートでラッパーを書けば、MCPツールコールをAPIリクエストに変換できます。

セキュリティのベストプラクティス

MCPは便利ですが、外部ツールへのアクセス権を与えることになるので、セキュリティには注意が必要です。

1. サービスアカウントを使う

公式ドキュメントで強く推奨されています。「OAuthで認証するMCPでは、個人アカウントではなくサービスアカウントを使用してください。アクセスは組織内で共有されます。」

個人アカウントで認証してしまうと、後からサービスアカウントに切り替える手間が発生するので、最初からサービスアカウントを使うのが良さそうです。

2. データベースは読み取り専用で

Cognitionの事例でも、「read-only database access」と明記されています。本番データベースに接続する場合は、必ず読み取り専用の接続文字列を使い、権限を最小限に制限しましょう。

3. シークレット管理を活用

APIキーなどの機密情報は、組織のシークレットとして保存し、設定で参照する形にします。引数にハードコードしないように。

トラブルシューティング

MCPの設定でハマりやすいポイントをまとめました。

エラー 原因 対処法
"Verify server URL and network connectivity" URLに到達できない URL、ネットワーク設定を確認
"Check authentication credentials" 認証失敗 APIキー、トークンを再確認
"Server took too long" タイムアウト サーバーが起動しているか確認
ツールが表示されない プロトコル実装の問題 tools/listメソッドとJSON-RPC準拠を確認

設定後は「Test listing tools」で必ず接続テストを実行しましょう。Devinが分離されたテスト環境を起動し、サーバーに接続して利用可能なツールを検出してくれます。

DeepWiki MCPでコードベース理解を強化

最近追加されたDeepWiki MCPサーバーも便利です。GitHubリポジトリのドキュメントにプログラマティックにアクセスできます。

DeepWikiは完全無料で認証不要。3つのツールが提供されています：

  • ask_question: リポジトリに関する質問に回答
  • read_wiki_contents: Wikiコンテンツを読み取り
  • read_wiki_structure: Wiki構造を取得

パブリックリポジトリはDeepWiki.comでインデックスすれば、すぐに利用可能になります。プライベートリポジトリの場合は、Devinアカウントを作成してGitHub認証を連携する必要があります。

本番環境での課題と注意点

MCPは便利ですが、本番環境で運用する際にはいくつかの課題があります。セキュリティに関する記事や公式ロードマップを調べた結果をまとめます。

うまくいかないケース

状況 問題 対策
複雑なクエリ Devinが意図と異なるクエリを実行することがある 具体的な指示を心がける、結果を確認する
大量データ ログが多すぎてコンテキストウィンドウを超える 時間範囲やフィルタを明示的に指定
認証エラー トークン期限切れ、権限不足 定期的な認証確認、適切な権限設定
ネットワーク問題 タイムアウト、接続断 リトライ設定、ネットワーク監視

エンタープライズ導入の壁

企業でMCPを本格導入しようとすると、いくつかの壁に直面するようです。

特に注意が必要な点：

  • シャドーIT問題: AIエージェントがSlackやGitHubに接続しても、企業のIdPからはユーザーがそのサービスにログインしたようにしか見えない。エージェント接続は可視化されにくい
  • セキュリティリスク: プロンプトインジェクション、ツールポイズニング（悪意あるツール説明による誤動作）などのリスクが研究で指摘されている
  • スケーリング: ステートフルなセッション管理とロードバランサーの相性が悪く、水平スケーリングに工夫が必要

現実的な期待値

公式ブログで紹介されているような「バグ調査が完全自動化」は、理想的なケースです。現実には：

  • 簡単なバグ: エラーログが明確で、原因箇所が特定しやすい → 効果大
  • 複雑なバグ: 複数サービスにまたがる、再現条件が複雑 → 人間の判断が必要
  • 本番データ: センシティブなデータへのアクセスは慎重に検討が必要

「完全自動化」ではなく、「調査の初動を加速する」という期待値が現実的かもしれません。

今後の展望：こうなったらいいな

MCPを調べていて、「こうなったらもっと使いやすいのに」と思った点をまとめます。

期待したい改善

課題 現状 期待する将来
認証 各MCPで個別に設定 企業IdPとの統合、SSO対応
監査 エージェントの操作履歴が見えにくい 操作ログの一元管理、ダッシュボード
権限制御 読み取り専用などは手動設定 ツールごとのリスクレベル分類、自動制御
エラーハンドリング 失敗時のリトライは実装依存 標準的なリトライ・フォールバック機構

2026年のMCPロードマップ

MCP公式ロードマップ（2026年3月更新）によると、以下が優先領域として挙げられています：

  • トランスポートの進化とスケーラビリティ: ステートレス運用、水平スケーリング対応、MCP Server Cards（サーバーメタデータの標準化）
  • エージェント間通信: タスクのリトライ・有効期限ポリシーの明確化
  • ガバナンスの成熟: コントリビューターラダー、WGへの権限委譲モデル
  • エンタープライズ対応: 監査証跡、SSO統合、ゲートウェイパターン（Enterprise WGで検討中）

活用アイデア

調べていて「こういう使い方もできそう」と思ったアイデアです。

  • Slack連携の自動化: バグ報告がSlackに来たら、自動でDevinセッションを起動してMCP経由で調査開始
  • 定期監査の自動化: 毎日のセキュリティスキャン結果をMCP経由で取得し、問題があれば自動でチケット作成
  • 社内API統合: 社内のマイクロサービス群をMCPサーバーとして公開し、横断的な調査を可能に

まとめ：MCPで「調査の準備」を減らす

MCPを導入すると、「調査の準備」がなくなるのが大きなメリットのようです。従来は「ログを見せる」「データを渡す」という下準備に時間を取られていたのが、タスクを依頼するだけで済むようになります。

変化 従来 MCP導入後
バグ調査の準備時間 15分程度 ほぼ0分
追加情報のやりとり 2〜3往復 大幅に減少
調査の網羅性 人間の気づきに依存 自動で複数ソースを確認

公式ブログの事例を見ると、「まずはDatadog MCPだけ」でも効果がありそうです。バグ調査に時間がかかっている場合は、試してみる価値がありそうです。

参考リンク

公式

関連記事

1
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?