MCPアーキテクチャのアイデア（2026.6）

MCP 2026年ロードマップの主要トピックス（a2a-mcp.org）

2026年のMCP（Model Context Protocol）は、個人開発のフェーズを超え、「大規模な企業運用」と「AIエージェントの自律性向上」へ向けて進化します。重要なアップデートは以下の4点です。

• 1. イベント駆動（トリガー機能）の導入 これまでの「AIからの問い合わせを待つ」スタイルから、サーバー側から能動的にデータ更新をAIへ通知（Webhooksなど）できるようになり、バックグラウンドでの自動タスクが容易になります。
• 2. ネイティブ・ストリーミング対応 ツールが生成したテキストや音声・ビデオなどの大容量データを、小分けにしてリアルタイム（インクリメンタル）にAIへ送信できるようになり、応答速度が向上します。
• 3. エンタープライズ向けセキュリティの標準化 Linux Foundation傘下でのガバナンス強化に伴い、OAuth 2.1やmTLSなどの強固な認証、およびAIの行動を記録する「監査ログ（Audit Trail）」の標準仕様が組み込まれます。
• 4. コンテキスト肥大化の解消（参照ベースのデータ取得） すべてのデータをプロトコル内に詰め込むのではなく、必要な時に必要な分だけ大きなデータ（ペイロード）を引き出す「参照ベース」の仕組みを導入し、効率化を図ります。

ソース：https://a2a-mcp.org/blog/mcp-2026-roadmap

※ a2a-mcp.org は、AIエージェントの相互連携や外部ツール接続のための最先端プロトコルに関する情報や、対応ツール・サーバーのディレクトリ（カタログサイト）を提供している専門ポータルサイトです。

Progressive Disclosure （Matthew Kruczek）

一言で言うと、「AIにツールの説明書を最初から全部読ませるな、必要な時にだけ読ませろ」という、MCPサーバーの劇的な軽量化・効率化テクニックに関する解説です。

• 直面している課題（コンテキストの肥大化と精度低下） 従来のMCPサーバーは、起動時に「持っているすべてのツール（機能）の仕様書（JSON Schema）」をAIの頭脳（コンテキスト）に一括で読み込ませていました。機能が多いエンタープライズ向けのサーバーだと、これだけで膨大なトークン（料金）を消費し、AIの頭の中が情報過多になって誤作動（ハルシネーション）の原因になっていました。
• 解決策：「段階的開示（Progressive Disclosure）」 開発者がよく使うCLIコマンドの --help と同じアプローチです。
  1. ディスカバリー（発見）： 起動時はツールの「名前」と「短い概要（目次）」だけをAIに見せる。
  2. アクティベーション（有効化）： AIが「この機能が使えそうだ」と判断した瞬間だけ、そのツールの詳細なルールや仕様書を動的に読み込む。
  3. エグゼキューション（実行）： 実際に動かす。
• もたらされる効果 検証では最大91%のトークン削減を達成。AIの視界が常にクリアに保たれるため、複雑なタスクでも「迷わずに正しいツールを選ぶ精度」が圧倒的に向上します。

ソース：https://matthewkruczek.ai/blog/progressive-disclosure-mcp-servers.html

『Dynamic ReAct: Scalable Tool Selection for Large-Scale MCP Environments』（Nishant Gauravら）

• 背景と課題：ツールの詰め込みすぎによるAIのパンク 数千・数万ものAIツール（MCPサーバー）が存在する環境では、すべてのツールの仕様書（JSON Schema）を最初に一括でAIに読み込ませると、脳みそ（コンテキスト）が即座にパンクします。これがAPIコストの爆発や、AIが正しいツールを見失う誤作動（ハルシネーション）の原因になっていました。
• 核心のアイデア：「メタ・ツール」による動的な2段階アクセス AIに最初から個別のツールを持たせるのをやめ、ツールを管理するための道具（メタ・ツール）として、「ツールを探す機能（search_functions）」と「ツールの説明書を読み込む機能（load_functions）」の2つだけを常時持たせます。
• 実行のプロセス：使う直前に「その場」でロード AIはタスクを処理する際、まず検索ツールを使って膨大なツール群から候補を絞り込みます。そして「このツールを使う」と決めた瞬間にだけ、その仕様書を動的にロード（一時記憶）して実行に移します。
• 検索の工夫：AI自らの「思考（Thought）」をクエリにする ユーザーの指示をそのままキーワード検索するのではなく、AIが一度「このタスクを解くには、具体的にどんな機能を持ったツールが必要か」を自ら思考し、その思考結果をもとに検索をかけることで、的外れなツールが引っかかるのを防ぎます。
• もたらされる効果：コストの劇的削減とスケーラビリティ ツールがどれだけ増えても、LLMに渡すツール情報のコンテキスト量を最大90%以上削減できます。ノイズが消えるためツールの選択精度（タスク成功率）が大幅に向上し、ツールの数が1万個を超えても、常に最小限のコストで安定して動作するエージェントシステムが実現します。

ソース：https://arxiv.org/pdf/2509.20386

MCP Server Patterns for Enterprise AI Agents（Digital Applied）

1. トランスポート仕様の世代交代

• 従来の「HTTP+SSE（Server-Sent Events）」は非推奨（Deprecated）となりました。
• 新しい標準仕様では、ローカル接続用の stdio と、リモート接続用の Streamable HTTP の2つのみが標準トランスポートとして定義されています。

2. 強固な認証規格（OAuth 2.1）の完全義務化

リモート（HTTP）環境でMCPサーバーに認証をかける場合、単なるAPIキー認証などは許されず、以下の高度なセキュリティ標準の実装が必須（MUST）とされています。

• OAuth 2.1 + PKCE S256: 認証コード横取り攻撃を防ぐ仕組み（PKCE）の義務化。
• RFC 9728（Protected Resource Metadata）： AIクライアントが、接続先MCPサーバーの認証サーバーURLを動的に自動発見する仕組み。これによって個別の設定ファイル管理が不要になります。
• RFC 8707（Resource Indicators）： 発行されたアクセストークンに「このMCPサーバー専用」という利用範囲（オーディエンス）を埋め込む仕様。これにより、他のMCPサーバーへのトークンの使い回しを防ぎます。

3. 「トークンのそのまま転送（Token Passthrough）」の絶対禁止

• ここが最も多くの開発者が犯している設計ミスとして指摘されています。
• AIクライアントから届いた認証トークンを、MCPサーバーがそのまま社内システム（Upstream API）へ横流し（転送）してリクエストを送ることは、仕様上厳格に禁止（Forbidden）されています。
• 理由：これをやると、プロンプトインジェクション（AIへの悪意ある指示）によって、MCPサーバーが「騙された身代わり（Confused Deputy）」となり、社内データを不正に盗み出す攻撃が簡単に成立してしまうため。MCPサーバーは必ず独自のトークンを取得・交換して社内システムと通信しなければなりません。

4. 企業向け4つの導入パターン（トポロジー）

企業がMCPサーバーを社内にデプロイする際、用途に合わせて以下の4つのパターンから選択することを推奨しています。

1. シングルテナント（Single-Tenant stdio） 特定のチームや個人環境向けに、ローカルプロセスで完結させる最も安全な分離パターン。
2. マルチテナント・行レベル分離（Multi-Tenant Row-Isolated） SaaSのように、1つのMCPサーバーで複数顧客・テナントを裁くパターン。RFC 8707を使ってトークンレベルで顧客データを厳格に分離する。
3. フェデレーテッド・ゲートウェイ（Federated Gateway） 社内に何百ものMCPサーバーが乱立する大企業向けの最強パターン。中央のゲートウェイが全ての認証と監査ログ（Audit）を一括統括する。
4. エッジキャッシュ・読み取り専用（Edge-Cached Read-Only） AIエージェントが「今どんなツールが使えるか」を高速に探索（ディスカバリー）するための、キャッシュを効かせた超高速な読み取り専用サーバーの配置。

Code execution with MCP: Building more efficient agents（bagrounds.org）

1. 従来のツール呼び出し（Tool Calling）が抱える限界

• コンテキストのオーバーロード: 接続するツールが増えれば増えるほど、何十万トークンもの「ツールの定義（説明書）」を毎回AIに読み込ませる必要があり、コストと遅延が跳ね上がります。
• 中間データの無駄な往復: 例えば、AIが「大きなドキュメントから特定のデータを抽出して加工する」という複数ステップのタスクを行う際、加工前後の巨大な未整理データが何度もLLMのコンテキスト（脳内）を往復するため、トークンを激しく浪費します。

2. 核心のアイデア：「コード実行型MCP（Code Execution with MCP）」

• ツールをAIに直接使わせるのではなく、ツールを「プログラムのライブラリ（API）」としてAIに見せます。
• AIはタスクを処理するための「コード」を自ら記述し、セキュアなサンドボックス環境（実行環境）でそのコードを走らせて、コード経由でMCPサーバーのツール群を操作します。

3. このアプローチがもたらす圧倒的なメリット

• データの地産地消（プライバシー保護と効率化）: 巨大なデータセットのフィルタリングや加工はすべて「コードの実行環境内」でローカルに処理されます。LLMの脳内には「処理が終わった最終的な結果だけ」が戻るため、最大98.7%ものトークン削減を達成できます。また、不要な個人情報（PII）が外部のモデルに送信されるのを防ぐ盾にもなります。
• 高度な制御フローの実現: 従来のAIは、ループ処理（繰り返し）や条件分岐のたびに「ツールを叩く ➡️ 結果を待つ ➡️ 考える ➡️ またツールを叩く」という無駄なターンを消費していました。コード実行型にすれば、AIが書いたプログラム内で for ループや if 文が完結するため、AIの待ち時間がゼロになります。
• 「スキル」の永続化: AIが一度作成した複雑な処理コードはファイルとして保存され、次回からはAI自作の「再利用可能な関数（新しいスキル）」として呼び出せるようになり、使えば使うほどAIが賢くなります。

4. トレードオフと課題

• セキュリティ・エンジニアリングの負荷: AIが生成したコードを安全に実行するために、リソース制限や徹底的な監視（ロギング）を施した堅牢な「サンドボックス（隔離）環境」の構築が必須となり、インフラ側の運用コストや複雑性が増します。

ソース：https://bagrounds.org/articles/code-execution-with-mcp-building-more-efficient-agents