Skip to content
Published on

Model Context Protocol(MCP)リファレンス — AIを外部世界につなぐ開かれた標準

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

はじめに — MCPとは何か、何を解決するのか

Model Context Protocol(MCP)は、公式ドキュメントの言葉を借りれば「AIアプリケーションを外部システムに接続するためのオープンソース標準」です。ClaudeやChatGPTのようなアプリケーションが、ローカルファイルやデータベースといったデータソース、検索や電卓のようなツール、特化したプロンプトのようなワークフローに接続する方法を統一します。ドキュメントはこれを「AIアプリケーションのためのUSB-Cポート」にたとえます — ケーブル規格が1つに統一されるように、接続方法を1つに統一するという意味です。

なぜ標準が必要なのでしょうか。よくM×N問題と呼ばれます。AIアプリケーションがM個、つなぎたいツールやデータソースがN個あるとき、標準がなければM×N個のばらばらな統合を手で作ることになります。共通プロトコルが1つできれば、このコストはM+Nに減ります — サーバーを一度作ればプロトコルを話すすべてのクライアントが使え、クライアントもプロトコルさえ実装すればすべてのサーバーにつながります。ドキュメントの表現では「一度作ってどこにでも統合(build once, integrate everywhere)」です。MCPはこの発想をLanguage Server Protocol(LSP)から借りたと述べています。LSPが「エディタ × 言語」の組み合わせを1つの標準に整理したように、MCPは「AIアプリ × ツール」の組み合わせを整理します。

MCPはAnthropicが2024年11月に公開・オープンソース化し、当初はPython・TypeScriptのSDKと、Google Drive・Slack・GitHub・Git・Postgres・Puppeteer向けのサーバーを一緒にリリースしました。その後OpenAIやGoogle DeepMindも採用し、事実上の業界標準になりました。

アーキテクチャ — ホスト・クライアント・サーバー、そしてトランスポート

MCPはクライアント-サーバー構造で、参加者は3つに定義されます。

  • ホスト(Host)。 1つ以上のMCPクライアントを調整・管理するAIアプリケーション(例: Claude Code、VS Code)。
  • クライアント(Client)。 1つのサーバーとの接続を維持し、そこからコンテキストを受け取る構成要素。
  • サーバー(Server)。 クライアントにコンテキストを提供するプログラム。ローカルで動いても遠隔で動いても「サーバー」です。

核心となる規則は「サーバー1つにつきクライアント1つ」です。ホストは接続するサーバーごとに専用のクライアントを作り、それぞれ独立した接続を維持します。VS CodeがファイルシステムサーバーとSentryサーバーに接続すると、内部的にクライアントオブジェクトが2つできる、という具合です。

プロトコルは2つの層に分かれます。データ層(data layer)はJSON-RPC 2.0ベースの交換プロトコルで、ライフサイクル管理とプリミティブ(ツール・リソース・プロンプト・通知)を定義し、トランスポート層(transport layer)は実際の通信チャネルと認証を扱います。接続はステートフルで、クライアントがinitializeリクエストでprotocolVersionと互いのcapabilities(能力)を交渉し、準備ができるとnotifications/initializedで通知して始まります。

トランスポートは2つあります。

  • stdio。 標準入出力で同じマシンのプロセス同士が直接通信します — ネットワークのオーバーヘッドがなくローカルサーバーに適し、通常はクライアント1つを相手にします。
  • Streamable HTTP。 クライアント→サーバーはHTTP POST、ストリーミングが必要ならServer-Sent Events(SSE)を重ねます。遠隔サーバー用で、ベアラートークン・APIキー・カスタムヘッダーに対応し、ドキュメントはトークン取得にOAuthを推奨します。

同じJSON-RPCメッセージがどのトランスポートでもそのまま通るよう、トランスポート層は通信の詳細をプロトコルから切り離します。

3つのプリミティブ — ツール・リソース・プロンプト

プリミティブはMCPで最も重要な概念であり、サーバーが公開する3つがその中心です。それぞれ「誰が主導するか」が異なります。

  • ツール(Tools)― モデル主導。 AIが実際に呼び出して行動する関数です(ファイル書き込み、API呼び出し、DBクエリ)。入力はJSON Schemaで検証します。発見はtools/list、実行はtools/call。モデルが自分でいつ使うか決めるため、実行前のユーザー承認のような制御が重視されます。
  • リソース(Resources)― アプリケーション主導。 読み取り専用のコンテキストデータです(ファイル内容、DBスキーマ、ドキュメント)。各リソースは固有のURIとMIMEタイプを持ちます。固定URIの直接リソースと、パラメータを取るリソーステンプレートがあります。メソッドはresources/list、resources/templates/list、resources/read、変更購読はresources/subscribe。
  • プロンプト(Prompts)― ユーザー主導。 再利用可能なテンプレートで、ツールやリソースをどう組み合わせて使うかを示します。スラッシュコマンドのように、ユーザーが明示的に呼び出します。メソッドはprompts/list、prompts/get。

リソースURIは固定型(直接リソース)とパラメータ型(テンプレート)の2種類です(説明用)。

file:///Users/me/notes.md          # 直接リソース (固定URI)
calendar://events/2026             # 直接リソース
weather://forecast/{city}/{date}   # リソーステンプレート (パラメータ)

発見は*/list、取得は*/get、実行はtools/callという規則的なパターンに従います。一覧は動的なので、サーバーのツールが変わるとnotifications/tools/list_changedのような通知でクライアントに知らせられます。

逆に、クライアントがサーバーに公開するプリミティブもあります。

  • サンプリング。 サーバーがクライアントのLLMに補完を要求するsampling/createMessage — サーバーが自前のモデルSDKを持たずにモデルを使えます。
  • エリシテーション。 サーバーがユーザーに追加入力や確認を要求するelicitation/create。
  • roots とロギング。 サーバーが扱うファイル・URIの境界を伝えるroots、そしてデバッグ用のログ送信。

サーバーをどう作るか

サーバー作りの本質は「何をツール、何をリソース、何をプロンプトとして公開するか」を決めることです。行動はツール、読み取るコンテキストはリソース、定型のワークフローはプロンプトに分けます。公式SDKはTypeScript・Python・C#・Go(Tier 1)、Java・Rust(Tier 2)、Swift・Ruby・PHP・Kotlin(Tier 3)があり、いずれも同じ機能を各言語の流儀に合わせて提供します。細かなAPIはSDKごとに異なるので、言語別のドキュメントを見てください。

ツール定義は、名前・説明・入力スキーマからなります。公式ドキュメントの例の形(説明用)です。

{
  "name": "searchFlights",
  "description": "Search for available flights",
  "inputSchema": {
    "type": "object",
    "properties": {
      "origin": { "type": "string", "description": "Departure city" },
      "destination": { "type": "string", "description": "Arrival city" }
    },
    "required": ["origin", "destination"]
  }
}

クライアントはまずtools/listでこれらの定義を受け取りLLMに登録し、モデルがツールを選ぶとtools/callで実行します。実際にやり取りされるJSON-RPCはこのような形です(説明用)。

{ "jsonrpc": "2.0", "id": 3, "method": "tools/call",
  "params": { "name": "weather_current",
              "arguments": { "location": "San Francisco", "units": "imperial" } } }

応答はcontent配列として返り、テキスト・画像・リソースなど複数の形式を含められます。開発とデバッグには、公式のMCP Inspectorとリファレンスサーバー集が出発点として便利です。

トレードオフと成熟度 — 正直な整理

MCPの魅力は明快です。統合を一度作ればよく、LSPのようにエコシステム全体が同じ規格を共有します。ただし冷静に見るべき点もあります。

  • セキュリティはプロトコルに組み込まれていません。 仕様自身が「ツールは任意のコード実行」であり、信頼できないサーバーのツール説明(annotation)は信用すべきでないと明言しています。ユーザーの同意・ツール実行の承認・サンプリングの承認はホスト実装の役目です — つまり安全はプロトコルではなくクライアントが守ります。
  • 遠隔サーバーの認証はいまだに重いです。 Streamable HTTPとOAuthの組み合わせは強力ですが、ローカルstdioの単純さとは距離があります。
  • 仕様は動き続けています。 バージョンは日付ベースで(現在の最新は2025-11-25)、Tasksのような機能はまだ実験的(Experimental)段階です。SDKもティアに分かれ、成熟度は言語ごとに異なります。
  • ガバナンスは移行中です。 報道によれば、2025年12月にMCPはLinux Foundation傘下のAgentic AI Foundationへ移管されました — 一企業のプロジェクトから中立的な標準へ移る兆しです。

おわりに

MCPの核心は華やかな新技術ではなく「退屈な標準化」であり、まさにそこに価値があります。ツール・リソース・プロンプトという3つのプリミティブと、JSON-RPCという薄い規格さえ理解すれば、どのクライアントもどのサーバーも同じ方法でつながります。エージェントを実際のシステムに接続したいエンジニアなら、フレームワークを選ぶ前にこのプロトコルの一層を理解しておくほうが、長く役に立ちます。

参考資料

Discuss on Twitter • View on GitHub