MCPとは何か：全体像とクイックスタートを一本で押さえるハブ¶

2026年2月 Update

GitHub Copilot / VS CodeでのMCPサーバー利用にallowlistポリシーが追加されました。組織管理者が許可されたMCPサーバーを指定できます。

この記事のポイント¶

なぜ必要か: M×N接続問題を「クライアント + サーバー」でM+Nに圧縮する発想を理解する。
どう動くか: 3つのプリミティブ（Tools/Resources/Prompts）とJSON-RPC 2.0のリクエスト/レスポンス像をつかむ。
どう試すか: tools/list → tools/call の最小ループで「動いた」状態を作り、セキュリティの初期設定を外さない。

まず押さえる3ポイント¶

M×N → M+N: すべてのAIアプリにそれぞれのツール統合を実装する代わりに、「MCPクライアント」と「MCPサーバー」の標準プロトコルで接続を抽象化する。
3プリミティブ: Tools（動詞）/ Resources（名詞）/ Prompts（テンプレート）で、行動・データ・文脈を分離して扱う。
JSON-RPC 2.0: tools/list で機能を発見し、tools/call で実行する双方向の標準メッセージング。

1. なぜMCPが必要か（問題設定）¶

断片化: AIごと・ツールごとに個別実装が必要→保守が爆発する。
拡張性: 新しいツール追加のたびに全AI側を改修するスケール問題。
標準化不足: セキュリティ/権限モデルやリソース表現がバラバラ。
解決の方向性: 「AI側=MCPクライアント」「ツール側=MCPサーバー」という役割分担で、接続の作法を共通化する。

M×N問題を1枚で¶

従来: M個のAI × N個のツール → 実装はM×N通り。
MCP: M個のクライアント + N個のサーバー → プロトコルを一度実装すれば再利用可能。

2. 仕組みを最短でつかむ¶

2-1. アーキテクチャの流れ¶

ユーザー → Host App（例: Claude Desktop/IDE）
Host App → MCP Client（プロトコル処理）
MCP Client ⇄ MCP Server（ツール実装・データアクセス）
MCP Server → 外部システム（DB/API/ファイル等）

2-2. 3つのプリミティブ¶

Tools（動詞）: AIが呼び出せるアクション群。tools/list で発見し、tools/call で実行。
Resources（名詞）: 参照可能なデータ。resources/list → resources/read で取得。
Prompts（文法）: 再利用可能なテンプレート。prompts/list → prompts/get。

2-3. JSON-RPC 2.0リクエスト/レスポンス例¶

// tools/list (request)
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

// response
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "query_db",
        "description": "SQLを実行",
        "inputSchema": { "...": "..." }
      }
    ]
  }
}

2-4. 最小シーケンス例（IDE → DBスキーマ取得）¶

Hostが tools/list で利用可能なツールを取得
tools/call で describe_table("users") を実行
MCP ServerがDBに問い合わせ、結果を返す
Hostがユーザーにスキーマ情報を提示

3. どんなとき効くか（適用判断）¶

✅ 複数ツールを横断して操作したい（Slack/Drive/GitHub/DB など）
✅ 異なるモデル間で同じ接続を共有したい（Claude/GPT/Gemini 等）
✅ 実行時に機能を発見したい（動的な tools/list）
❌ 単一ツールの軽い試験接続だけなら Function Calling でも十分
❌ レイテンシ極小が最優先（MCP層を挟むオーバーヘッドを避けたい）

4. すぐ試すクイックスタート（サンプル最小構成）¶

MCPサーバーを1つ立てる（例: DBスキーマを返す簡易サーバー）。
MCPクライアントが動く環境（例: Claude Desktop / IDEプラグイン）でサーバーを登録。
tools/list → tools/call の往復が通ることを確認。
読み取り系で動いたら、書き込み系は Human-in-the-loop（確認ダイアログ）を挟む。

💡 ポイント: まず 1ツール・1リソース で「動いた」を作る。拡張は後からでも間に合う。

5. 導入時のチェックリスト（セキュリティ含む）¶

最小権限の原則: Roots/ツール権限は必要最小限に限定。
認証: リモートサーバーには認証（例: OAuth）を必須にする。
承認フロー: 書き込みや外部コールは Human-in-the-loop を挟む。
ロギング: tools/call と結果を監査ログに残す。
インシデント対応: サーバー停止/権限剥奪の手順を用意。

6. 公式リソースと関連ガイド¶

公式仕様・SDK: GitHub modelcontextprotocol（仕様とPython/TS/Java/C#の実装が提供）
Claude Codeとの連携: MCPコード実行エージェントの設計パターン
初心者向けの導入記事（例）:
Claude Code自動許可ガイド（運用設計）
Claude Codeインストール＆環境構築

7. よくある質問（FAQ）¶

Q. Function Callingと何が違う？ A. Function Callingはモデル固有の関数登録で、各ツール/モデルに個別実装が必要。MCPはツール側を「サーバー」として標準化し、モデルに依存しない接続を提供する。
Q. まず何を試せばいい？ A. 読み取り専用のツール（例: describe_table）を1つ用意し、tools/list → tools/call が通るか確認するのが最短。
Q. セキュリティで注意すべき点は？ A. 認証なし公開を避ける、書き込み系はユーザー承認を挟む、監査ログを残す——この3点が最低ライン。