MCP アーキテクチャ図：ホスト、クライアント、サーバー、トランスポート

コーディングエージェントは、リポジトリを読み、ビルドを確認し、トラッカーに issue を登録します。この構成の典型的な図には、モデルとツールの間に「MCP」と書かれたボックスが 1 つ描かれています。そこでセキュリティレビュアーが、どのプロセスがホームディレクトリを読めるのか、どのトークンがトラッカーに届くのか、issue を作成した呼び出しを誰が承認したのかを尋ねます。このボックスには答えがありません。

Model Context Protocol（MCP）には明確なアーキテクチャがあり、2026-07-28 リビジョンでその一部が変わりました。この記事では、参加者、プロトコルの層、トランスポート、機能、1 回のツール呼び出し、リモート認可、信頼境界を、コピーして使える図とともに説明します。

ホスト、クライアント、サーバー

MCP 以前は、AI アプリケーションごとにツールごとのアダプターが必要でした。アプリケーション 5 つとツール 20 個なら、統合は最大 100 件になります。MCP では、25 個の実装（アプリケーションごとに 1 つのクライアント、ツールごとに 1 つのサーバー）であらゆる組み合わせをカバーできます。

ホストはサーバーごとに 1 つのクライアントを作成し、各クライアントはちょうど 1 つのサーバーと通信します。モデルがサーバーを直接呼び出すことはありません。モデルはツール呼び出しを要求し、実行するかどうか、どのクライアントが送るかはホストが決めます。サーバーは互いに隔離されたままです。会話全体や他のサーバーが見えてはいけません。

2 つの層と 2026-07-28 での変更点

データ層は JSON-RPC 2.0 です。リクエスト（id は null になりません）、結果、エラー、一方向の通知で構成されます。トランスポート層はそれらのメッセージを運び、フレーミング、キャンセル、認可を扱います。

2026 年 7 月 28 日にリリースされた 2026-07-28 仕様で、MCP はステートレスになりました。以前のリビジョンでは、すべての接続を initialize ハンドシェイクで始めてバージョンとケイパビリティを固定し、HTTP サーバーは Mcp-Session-Id でセッションを固定できました。現在は、すべてのリクエストがプロトコルバージョンとクライアントのケイパビリティを _meta に含むため、単純なラウンドロビンのロードバランサーの背後にあるどのサーバーインスタンスにも届きます。

古い SDK で作られたサーバーは今もハンドシェイクを期待するため、両世代に対応するクライアントはまずプローブし、initialize にフォールバックします。2026-07-28 だけを話すクライアントは、レガシー専用のサーバーを使えません。変更履歴に、互換性を破るすべての変更が載っています。

トランスポート：stdio と Streamable HTTP

Streamable HTTP は 2025-03-26 で HTTP+SSE トランスポート（GET ストリームと別の POST エンドポイント）に置き換わり、HTTP+SSE は正式に非推奨となりました。ゲートウェイは本文を解析せずに Mcp-Method と Mcp-Name でルーティングやレート制限ができ、サーバーはヘッダーが本文と食い違うリクエストを拒否します。HTTP サーバーは DNS リバインディングに備えて Origin ヘッダーを検証しなければならず、ローカルのサーバーは 127.0.0.1 にバインドすべきです。

サーバー機能とクライアント機能

Elicitation のフォームモードでは、パスワード、API キー、トークンを尋ねてはいけません。代わりに URL モードで、ユーザーをクライアントの外にあるページへ誘導します。Sampling、roots、サーバーログは 2026-07-28 で非推奨となり、2027 年 7 月 28 日以降に最初にリリースされるリビジョンより前には削除できません。

1 回のツール呼び出しを順に追う

モデルがリモートサーバー経由で issue を登録します。

1. 必要に応じて、クライアントが server/discover を呼び出し、バージョンとケイパビリティを取得します。
2. クライアントが tools/list を呼び出します。ホストはすべてのサーバーのリストをマージし、名前が衝突するものにはプレフィックスを付けて、モデルに渡します。
3. モデルが create_issue を要求します。ホストが呼び出しを表示し、ユーザーが承認します。
4. クライアントが tools/call を送ります。内容は下に示します。
5. サーバーが確認を必要とする場合、elicitation リクエストを添えて input_required を返します。クライアントはユーザーに尋ね、回答とサーバーの不透明な requestState を付けて再試行します。
6. 結果が complete として届きます。ツールが失敗すると isError: true が設定され、モデルは自分で修正できます。
7. subscriptions/listen ストリーム上で notifications/tools/list_changed が届くと、クライアントはツールを再度一覧取得します。

POST /mcp HTTP/1.1
Host: mcp.tracker.example
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: create_issue

{"jsonrpc": "2.0", "id": 7, "method": "tools/call",
 "params": {"name": "create_issue",
  "arguments": {"title": "Login fails on Safari"},
  "_meta": {"io.modelcontextprotocol/protocolVersion": "2026-07-28",
   "io.modelcontextprotocol/clientInfo": {"name": "my-ide", "version": "1.4.0"},
   "io.modelcontextprotocol/clientCapabilities": {"elicitation": {}}}}}

{"jsonrpc": "2.0", "id": 7, "result": {"resultType": "complete",
 "content": [{"type": "text", "text": "Created issue #482"}], "isError": false}}

リモートサーバーと認可

リモート MCP サーバーは OAuth のリソースサーバーです。トークンは、同じベンダーまたは別の ID プロバイダーが運用する認可サーバーから発行されます。初回接続の流れは次のとおりです。

1. クライアントがトークンなしで呼び出して 401 を受け取ります。通常は、サーバーの保護リソースメタデータ（RFC 9728）を指す WWW-Authenticate ヘッダーが付きます。
2. そのドキュメント（フォールバックは /.well-known/oauth-protected-resource）が認可サーバーを示し、クライアントはそのメタデータを読みます。PKCE が示されていなければ、クライアントは処理を止めます。
3. クライアントは、登録済みのクライアント ID、Client ID Metadata Document（HTTPS URL をクライアント ID にする方式）、または 2026-07-28 で非推奨となった Dynamic Client Registration のいずれかを使います。
4. クライアントは、PKCE（S256）と、MCP サーバーを指定する resource パラメーター（RFC 8707）を使って認可コードフローを実行します。ユーザーはブラウザーでサインインして同意し、クライアントはレスポンスの iss を確認します（RFC 9207）。
5. すべてのリクエストに Authorization: Bearer が付きます。insufficient_scope を伴う 403 は、ステップアップ認可を開始します。

サーバーは自分宛てに発行されたトークンだけを受け付け、決してそのまま渡しません。上流 API の呼び出しには別のトークンを使います。OAuth 2.0 フロー図で PKCE を解説しています。認可仕様には、OAuth 2.1 ドラフトに基づく全ルールが載っています。

信頼境界はどこにあるか

stdio トランスポートはサンドボックスではありません。MCP のローカルサーバーのセキュリティガイドには、stdio サーバーはクライアントの権限で動作し、分離はホストとマシンの運用者に委ねられると書かれています。ステートレスなサーバーが発行する状態ハンドルも認証情報ではないので、認証済みユーザーに紐づけてください。脅威モデリングのデータフロー図では、STRIDE でこうした境界をたどる方法を示しています。

MCP アーキテクチャ図

図の読み方は次のとおりです。

• 緑のフレームは 1 つの信頼ドメインです。ホスト、3 つのクライアント、2 つの stdio サーバーは、開発者の OS ユーザーとして動作します。
• サーバーごとに 1 つのクライアントです。 クライアント 1 と 2 は stdin と stdout を使い、クライアント 3 は Streamable HTTP を使います。
• モデルから出る灰色のエッジは、ホストが振り分けるツール呼び出しです。サーバーがモデルに直接届くことはありません。
• 青は Bearer トークン付きでネットワークを横断します。紫の破線は OAuth フローで、クライアントが有効なトークンを持たないときだけ実行されます。
• ティールは、リモートサーバーが自身のトークンで API を呼び出す経路です。パススルーはありません。
• Markdown ブロックは、2026-07-28 リビジョンの要点をまとめています。

MCP アーキテクチャ図をわかりやすく描くには

• サーバーごとに 1 つのクライアントを描きます。 「MCP」と書いたボックス 1 つでは、各サーバーが何を見られるのかが隠れてしまいます。
• エッジにはトランスポートとペイロードを書きます。stdin と stdout、Bearer トークン付きの POST、OAuth フロー、ツール名の例などです。
• 信頼境界はフレームで描きます。マシン、ホスト、各ベンダーが対象です。サンドボックス化したサーバーには印を付けます。
• 認可サーバーと上流 API には専用のノードを用意します。トークンの発行元とパススルー禁止のルールが見えるようになります。
• プロトコルのリビジョンを明記します。 2026-07-28 の図には、ハンドシェイクもセッション ID もありません。
• 省くものは、SDK の内部、ツールの完全な一覧、モデルプロバイダーのインフラです。

これらの呼び出しを取り巻くエージェントループについては、AI エージェントのアーキテクチャ図で説明しています。

Archboard で作る

1. Google または GitHub でサインインし、ダイアグラムを作成します。
2. 開発者マシン用に基本パックのフレームを追加し、その中にホスト用の C4 Model パックのコンテナ境界を追加します。
3. 境界の中に ML パックのモデルと、クライアント用に C4 Model パックのコンポーネントノードを 3 つ追加し、テクノロジーを stdio、stdio、Streamable HTTP にします。
4. ローカルサーバー用に C4 Model パックのコンテナノードを 2 つ追加して「stdin / stdout」のエッジでつなぎ、同じパックの人物を追加してモデルにつなぎます。
5. フレームの外に、C4 Model パックのシステム境界を追加し、その中にリモートサーバー用のコンテナ、その API 用の外部システム、セキュリティパックの IDプロバイダーを置きます。続いて、Bearer トークン、破線の OAuth、「own token」のエッジを描きます。
6. プロトコルの要点を書いた基本パックの Markdown ブロックと、境界の説明用に基本のテキストメモを追加します。

MCP クライアントの設定ファイルを読める無料ツールはありません。サーバーは自分で描くか、MCP 仕様にあるような Mermaid のフローチャートを Mermaid から編集可能なダイアグラムへの変換ツールに貼り付けてください。

執筆時点（2026 年 11 月）で、Archboard 自体が https://getarchboard.app/mcp にあるリモート MCP サーバーです。Streamable HTTP を使い、独自の認可サーバーによる OAuth 2.1 で PKCE（S256）とこの URL をリソースインジケーターとして用い、クライアント登録は Client ID Metadata Document または Dynamic Client Registration で行います。MCP サーバーのドキュメントにツールの一覧があり、AI エージェントのページではアプリの接続方法を紹介しています。

この例で使うダイアグラムノードは 14 個で、Free プランの範囲に収まります。

よくある質問

MCP のホスト、クライアント、サーバーの違いは何ですか？ ホストは IDE などの AI アプリケーションです。ホストはサーバーごとに 1 つのクライアントを作成し、各クライアントは、ツール、リソース、プロンプトを公開する 1 つのサーバーと専用の接続を保ちます。

MCP は今はステートレスですか？ はい。リビジョン 2026-07-28 以降は、initialize ハンドシェイクもセッション ID もなく、すべてのリクエストが自身のバージョンとケイパビリティを持ちます。古いリビジョンのサーバーは今もハンドシェイクを使います。

MCP はどのトランスポートに対応していますか？ 標準は 2 つで、ローカルサーバー向けの stdio とリモートサーバー向けの Streamable HTTP です。HTTP+SSE は非推奨で、独自のトランスポートでも JSON-RPC のメッセージ形式は維持する必要があります。

ローカルの MCP サーバーに OAuth は必要ですか？ いいえ。仕様では、stdio サーバーは認証情報を環境から取得するべきとされています。サーバーごとに権限を絞ったトークンを渡し、サードパーティのサーバーはサンドボックス化してください。

MCP のトークンパススルーとは何ですか？ MCP サーバーが、自分宛てに発行されていないトークンを受け付けたり、クライアントのトークンを別の API に転送したりすることです。仕様はこれを禁止しており、上流の呼び出しにはサーバー自身のトークンが必要です。

無料で始める — 1 シート、クレジットカード不要。