【ITニュース解説】MCP em Escala Corporativa: Roteamento Stateless e Tool Bloat

ニュース記事は、AIエージェントと外部システムを連携させるための標準技術であるModel Context Protocol（MCP）が、どのようにして初期の課題を克服し、現代の企業環境で利用されるようになったかを解説している。

Model Context Protocol（MCP）は、2024年にAnthropic社によって提案された。その基本的なアイデアは、人工知能（AI）ソフトウェアエージェントが、さまざまなデータベース、コードリポジトリ、ローカルツールなどに簡単かつ標準的な方法で接続できるようにすることだった。これは、異なるデバイスを統一された規格で接続できるようにするUSB-Cのような存在を、AIの世界で実現しようとする試みである。独自の接続コードを一つ一つ書く手間をなくすことを目指していた。

このプロトコルは急速に普及し、2026年9月にはLinux Foundationがガバナンスを引き継ぎ、Cloudflare、Datadog、Microsoftといった大手クラウド企業も大規模に参入したことで、世界中で15,000を超えるMCPサーバーが稼働するほどになった。しかし、この爆発的な普及は、予期せぬ重大なアーキテクチャ上の問題を引き起こした。それが「ツール肥大化（Tool Description Bloat）」と呼ばれる現象と、それに伴う「コンテキスト汚染（Tool Poisoning）」のリスクである。

初期のMCP実装では、開発者はAIエージェントを多数のMCPサーバーに接続していた。例えば、GitHub、Jira、PostgreSQL、Slack、Kubernetes、AWSなどである。その結果、AIエージェントが何か処理を行おうとするたびに、80種類以上ものツールの詳細な説明（JSONスキーマというデータ形式で記述されたもの）が、AIモデルへの指示（プロンプト）の中にすべて注入されてしまった。この情報過多は、AIモデルが情報を処理する最小単位である「トークン」を、1回のリクエストで20,000から40,000も消費した。これは推論コストを大幅に増加させ、AIモデルの応答速度を低下させる原因となった。

さらに深刻だったのは、AIモデルが情報過多によって「注意散漫」になってしまったことである。まるで膨大な説明書を一度に渡されて、必要な部分を見つけ出すのが難しくなるように、AIモデルは正しいツールを間違って選択したり、ツールの引数を誤って生成したりする「幻覚」を引き起こすようになった。例えば、研究では、5つの選択肢からツールを選ぶ場合は94%の精度を保てたAIモデルが、50以上のツールが提示されると精度が61%以下に低下することが示された。200以上のAPIが統合された企業システムでは、この方式はもはや現実的ではなかった。また、ツール記述の中に悪意のあるコードを仕込むことで、AIモデルをだまして機密情報を漏洩させたり不正な操作をさせたりする「ツール汚染」というセキュリティ上の脅威も浮上した。

これらの課題を解決するため、Model Context Protocolの新しい仕様が導入された。この新仕様の核となるのは、「ステートレスな核（Stateless Core）」というアーキテクチャである。以前のMCPでは、クライアント（開発環境やローカルエージェント）とサーバー間の通信は、サーバー側にセッション情報が保存される「ステートフル」な接続に依存していた。このため、特定のサーバーに状態が固定され、サーバーがダウンするとAIエージェントの作業が中断したり、多数のサーバーで処理を分担する「負荷分散」が難しかったりした。

新しい「ステートレスな核」のアーキテクチャでは、各MCPリクエスト（JSON-RPCというプロトコル形式）が、セッションID、ルーティングキー、能力情報といった必要な全てのコンテキスト情報を、標準化されたHTTPヘッダーに含めて送信する。これにより、どのサーバーでもそのリクエストを独立して処理できるようになり、特定のサーバーに状態が依存しないため、クラウド環境での水平スケーリング（サーバーの数を増やすことで処理能力を向上させること）や、サーバーレス機能（Cloudflare WorkersやAWS Lambdaのような、サーバー管理不要でコードを実行できるサービス）での柔軟な運用が可能になった。サーバーが落ちても、セクエスト自体に必要な情報が含まれているため、他のサーバーで処理を継続できるのだ。

さらに、新しい仕様では「複数往復リクエスト（Multi Round-Trip Requests）」もサポートされた。これは、以前のツール呼び出しが1回ごとの同期的なやり取りだったのに対し、サーバーがツール実行中に部分的な情報確認、二段階認証、または予算確認を要求できるようになったことを意味する。AIエージェントは、これらの確認応答に応じて対話的に処理を進められるようになり、より複雑な処理に対応できるようになった。

「ツール肥大化」の問題に対する最も効果的な解決策として、2026年には「2段階ツール呼び出し」または「ジャストインタイム意味的ルーティング」と呼ばれる実践方法が確立された。このアプローチでは、まず第一段階として「発見とベクトルフィルタリング」が行われる。AIエージェントの制御システムは、企業内で利用可能な全てのMCPツールの完全なスキーマをAIモデルに直接渡すのではなく、ツールの名前、説明、機能の要約など「意味的な情報」だけを、ローカルのデータベースやメモリ上に保持する。ユーザーからのタスクが与えられると、AIモデルの一種である「埋め込みモデル」が、そのタスクの意図と、登録されているツールの意味的な情報を比較し、最も関連性の高い少数のツール（通常3〜6個）だけを選択する。そして、この厳選されたツールの完全なJSONスキーマだけが、AIモデルへのリクエストに動的に注入される。

第二段階は「ゼロトラストガードレールによる実行」である。このようにAIモデルには必要最小限の情報だけが提供されるため、モデルは明確で集中したコンテキストの中で、ほぼ正確にツール呼び出しを決定できる。実際のツール実行は、企業内のプロキシサーバーを介して対応するMCPサーバーに送られる。このプロキシは、アクセス権限（ロールベースのアクセス制御）、トークンのスコープ、機密情報（個人情報など）のマスキングなどを厳密に検証してから、実際のツール実行を許可する。これは「ゼロトラスト」というセキュリティ原則に基づき、何も信頼せず常に検証を行うことで、システム全体のセキュリティを強化する。

Pythonによる実装例では、SemanticToolRegistryというクラスが、数百ものツールのカタログをAIモデルのコンテキストから分離して管理し、ツールの情報を保存するコストと、AIモデルがトークンを消費するコストを分離する。get_top_k_toolsという関数は、ユーザーの意図に最も関連性の高いツールを数個だけ「ジャストインタイム」で選択し、AIモデルに渡すためのスキーマを生成する。これにより、AIモデルに注入されるスキーマのトークン数を大幅に削減できる。StatelessMCPClientは、この選ばれたツールスキーマを標準的なJSON-RPC形式でAIモデルのエンドポイントに渡し、AIモデルが正確なツール呼び出しを生成できるようにする。

企業環境でMCPサーバーを運用するには、厳格なセキュリティ対策も不可欠となる。AIエージェントからの全てのツール呼び出しは、認証済みのゲートウェイを通過する必要があり、そこでJSON Web Token（JWT）の検証、実行範囲の制限、呼び出しレートの制御（レートリミット）が行われる。AIモデル自体は、APIキーやデータベースのパスワードなどの機密情報に直接アクセスできないようにする。これらの資格情報は、検証が完了した後に実際のアクションを実行するMCPサーバーにのみ存在させる。また、全てのJSON-RPCリクエスト、送信されたパラメータ、ツールの出力は、改ざん不可能なログとして構造化され、規制遵守（LGPD、GDPR、SOC 2など）のための完全な追跡可能性を確保する。

2026年末の技術的な展望では、Model Context Protocolは、単なるツール接続の役割を超え、AIエージェント経済の標準的な基盤へと進化している。認証標準の統合、エッジコンピューティング（ネットワークの末端でデータを処理する技術）で動作するステートレスサーバーのサポート、動的意味的ルーターの普及により、「ツール肥大化」の問題は克服された。MCPのルーティングとセキュリティアーキテクチャを習得したシステムエンジニアは、最もスケーラブルで経済的、かつ信頼性の高い自律型企業プラットフォームを構築するためのリーダーとなるだろう。この技術は、これからのITシステム開発において非常に重要な分野である。