MCP（Model Context Protocol）詳解：AI Agent にデータソースを設定する方法

ひとことで言うと：Agent はコードを書けるのに、GitHub Issue、データベース schema、社内ドキュメントを読めない——問題はモデルではなく、「データがどこから来るか」が整理されていないことが多い。 本記事では MCP プロトコルの原理から、アーキテクチャの層分け、Tools / Resources / Prompts 三大能力、stdio と HTTP トランスポート、Cursor と Claude Code の設定例と検収チェックリストまでをカバーします。読み終えれば、各 SaaS ごとにボイラープレートを書かずに、主要なデータソースを Agent に接続できるようになります。

関連記事：Claude Code MCP インストールチュートリアル · MCP Server 20選おすすめ · MCP 権限の最小露出

MCP とは？何を解決するか？

Model Context Protocol（MCP、モデルコンテキストプロトコル）は、2024年末に Anthropic がオープンソース化した開放標準です。目的は明快：AI アプリケーション（Host）が統一され監査可能な方法で外部世界——コードリポジトリ、データベース、ドキュメントサイト、チケットシステム、ブラウザ——に接続できるようにすること。各データソースごとにカスタム統合を書く必要がありません。

MCP 登場以前、チームが取る道はだいたい2つでした：

• 手動でコンテキストを運ぶ——Issue リンク、SQL 結果、API レスポンスをチャットにコピペ。正確だが遅く、スケールしない。
• 自前の Function Calling——GitHub、Postgres、Notion ごとに tool schema と認証を実装。柔軟だがメンテコストが高く、クライアント（Cursor → Claude Code）を変えると書き直しが必要。

MCP は3つ目の道を提供します：「データソース ↔ Agent」のインターフェースを標準化する。GitHub MCP Server を1つ設定すれば、Cursor、Claude Code、VS Code Copilot、OpenAI Codex で再利用できます。コミュニティには既に数千の Server があり、主要 SaaS と開発ツールをカバーしています。

3層アーキテクチャ：Host、Client、Server

MCP 設定を理解するには、3つの役割の協調関係を把握しましょう：

典型的な呼び出しチェーン：Cursor で「PR #42 で変更されたファイルは？」と質問 → Host が大規模言語モデルに渡す → モデルが mcp__github__get_pull_request の呼び出しを決定 → Client が stdio または HTTP で GitHub MCP Server にリクエスト → Server が GitHub API を呼び出し構造化 JSON を返す → モデルが実データに基づいて回答を生成。

注意：設定するのは Server の接続方法（コマンド、URL、環境変数）です。Host が自動的に公開ツールを発見します。prompt に API ドキュメントを手書きする必要はありません——Server 起動時に tools/list で能力一覧を Client にプッシュします。

三大能力プリミティブ：Tools、Resources、Prompts

MCP Server は Agent に3種類の能力を公開し、それぞれ異なるデータソース接続パターンに対応します：

Tools（ツール）——「Agent にアクションを実行させる」

最もよく使われます。各 Tool には名称、説明、入力 schema（JSON Schema）があり、Agent が推論中に必要に応じて呼び出します。例：GitHub MCP の search_code、Playwright MCP の browser_click、データベース MCP の execute_query。

データソース設定では、90% のシナリオが Tool 型 Server の選択です：リポジトリ読み取り、テーブル照会、HTTP 送信、ブラウザ操作。

Resources（リソース）——「Agent に静的コンテキストを読ませる」

Resources はアドレス指定可能なデータ断片で、「URI 付きの読み取り専用ファイル」に似ています。Server が file://docs/api.md や db://schema/users を宣言し、Host が会話開始前または途中で内容を取得してコンテキストに注入できます。Agent がどの Tool を呼ぶべきか「推測」する必要がありません。

向いているもの：プロジェクト README、OpenAPI spec、データベース schema スナップショット、設定テンプレートなど比較的安定し列挙可能な知識。

Prompts（プロンプトテンプレート）——「プリセットワークフローの入口」

Server は命名された Prompt テンプレート（パラメータ付き）を公開でき、Host 上で「Code Review」「マイグレーションスクリプト作成」などの固定フローをワンクリックで起動できます。コミュニティ Server での採用率は Tools より低いですが、チーム SOP を再利用可能な入口として封装するのに適しています。

データソース種別と代表的 MCP Server マッピング

下表で「何を接続したいか」を「どの Server を入れるか」に素早くマッピングできます。より完全な20製品リストはMCP Server おすすめを参照。

トランスポート層：stdio と HTTP、どちらを選ぶ？

MCP Client と Server は JSON-RPC 2.0 で通信します。2026年の主流は2種類：

stdio（標準入出力）

Host が子プロセスとして Server を起動します。例：npx -y @modelcontextprotocol/server-github。stdin/stdout でメッセージを交換。利点：設定が簡単、ポート開放不要、ローカル開発向き。欠点：Server ごとに1プロセス；一部フル Docker 版はツール数が多すぎ、Cursor の約40ツール上限を超える場合あり。

Streamable HTTP / SSE（リモート）

Server がリモート（または公式ホスティング）で動作し、Client が HTTPS で接続。OAuth で認可が一般的。GitHub、Supabase、Linear、Sentry など公式が Remote 版を提供。利点：ツールセットが精選、ローカル Node/Docker 不要、token は OAuth で管理。欠点：ネットワーク依存；企業内網ではアウトバウンドポリシーの確認が必要。

Cursor でデータソースを設定する

Cursor の MCP 設定は Settings → MCP、または ~/.cursor/mcp.json を直接編集。mcpServers オブジェクトに Server ごとに1エントリ。

例1：ローカル stdio — Fetch MCP

{
  "mcpServers": {
    "fetch": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-fetch"]
    }
  }
}

例2：ローカル stdio — GitHub MCP（PAT）

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxx"
      }
    }
  }
}

Cursor UI で GitHub 公式 Remote MCP（OAuth）を追加する方が推奨。ツール数が少なく、PAT を手入力する必要がありません。PAT は細粒度読み取り専用にし、git にコミットしないでください。

例3：Context7（ドキュメントデータソース）

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    }
  }
}

保存後 Cursor を再起動し、Settings → MCP パネルで Server 状態が緑の Connected か確認。Agent モードで「Next.js 15 の middleware の書き方を調べて」と質問——設定が正しければ、モデルは Context7 を呼び出し、API を幻覚しません。

Claude Code でデータソースを設定する

Claude Code は ~/.claude.json（ユーザー単位）またはプロジェクトルートの .mcp.json（プロジェクト単位）を使用。構造は Cursor と似ていますが、フィールド名とパスに若干の差異があります。

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxx"
      }
    },
    "codegraph": {
      "command": "codegraph",
      "args": ["mcp"]
    }
  }
}

設定変更後は Claude Code を完全に終了して再起動。リポジトリルートで claude を実行し、セッション内で /mcp を入力して接続済み Server とツール一覧を確認。成功の目安：mcp__github__*、mcp__codegraph__* などのプレフィックス付きツールが表示されること。

ステップバイステップはClaude Code MCP インストールチュートリアル；トリプルコネクトアーキテクチャはMCP 総覧を参照。

プロジェクト単位 vs ユーザー単位：設定をどこに書く？

ベストプラクティス：認証情報とユーザー設定はユーザー単位（git に入れない）；リポジトリに紐づくデータソース（CodeGraph インデックスパス、プロジェクトドキュメント Server）はプロジェクト単位で .mcp.json をコミットし、チームメイトが clone 後すぐ使えるようにする。機密 token は環境変数参照を使い、例："env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PAT}" }。shell または CI から注入。

設定検収：Agent が本当にデータソースを使うようにする

設定しただけでは使えません。以下のチェックリストで項目ごとに検収：

1. 接続性 — Cursor：Settings → MCP で緑ランプ；Claude Code：/mcp で Server 一覧、error なし。
2. ツール可視性 — 対象 Tool 名が存在するか確認（例：mcp__github__search_code）。
3. スモークタスク — 明確な1文でツールをトリガー。「GitHub MCP でこのリポジトリの open issues を一覧」または「Context7 で Prisma 最新 migrate 構文を調べて」。
4. 失敗の可観測性 — Agent がツールを呼ばない場合、ツール過多、説明不明瞭、タスクが曖昧すぎないか確認。必要なら prompt に「GitHub MCP を使用してください」と明記。
5. 権限境界 — 意図的に権限のない操作（リポジトリ削除など）を試し、Server が 403 を返すことを確認。黙って成功しないこと。

権限とセキュリティ境界

データソースを1つ接続するたび、Agent に外部システムへの扉を開けます。核心原則：デフォルト読み取り専用、書き込みは明示的に有効化、本番環境は分離。

• GitHub PAT — 細粒度 token、対象リポジトリのみ許可；Issues/Contents 読み取り専用で大半の開発シナリオをカバー。
• データベース DSN — 開発 DB は読み取り専用ロール；本番書き込み接続文字列をプロジェクト設定に書かない。
• Filesystem MCP — args でプロジェクトルートに限定。$HOME や / を指さない。
• 内網 API — ステージング読み取り専用エンドポイントを使用；Claude Code ワークスペースに本番 .env を読み込ませない。

完全なポリシーマトリクスと攻撃チェーン分析はMCP 権限の最小露出を参照。

よくあるトラブルシューティング

よくある質問

MCP と Function Calling の違いは？

Function Calling は単一 API リクエスト内のツール宣言で、通常は特定モデル/ベンダーに紐づきます。MCP は永続的な Server 接続と開放プロトコルで、一度設定すれば複数クライアントで再利用でき、コミュニティがエコシステムをメンテナンスします。MCP を「標準化されたプラグアンドプレイ Function Calling ランタイム」と理解できます。

自前の MCP Server を書けますか？

可能です。公式 SDK として TypeScript（@modelcontextprotocol/sdk）、Python などがあります。典型シナリオ：社内 Wiki、チケット API、専有データレイクへの接続。最小 Server は tools/list と tools/call を実装し、stdio トランスポートで Cursor 上でデバッグできます。

MCP はデータをモデルベンダーに送りますか？

Tool 呼び出しの結果は会話コンテキストに入り、Host が使用する大規模言語モデル API にリクエストとともに送られます——これは Agent 動作の必要部分です。MCP 自体が追加でデータを「アップロード」するわけではありません。リスクは Server に何の権限を与えるか（どのリポジトリを読めるか、どんな SQL を実行できるか）にあります。最小権限で露出面を制御してください。

2026年、最初に接続すべきデータソースは？

多くの開発者は Context7（ドキュメント）+ GitHub（リポジトリ）+ Playwright（ブラウザ検証）から始めます。バックエンドなら Supabase または DBHub を追加；チームが Linear/Notion を使う場合は必要に応じて。詳細はMCP Server 20選おすすめを参照。