モデル・コンテキスト・プロトコル（MCP）とは何か

マルチエージェント・システムを構築しようとした後、各専門エージェント間で情報を効果的に伝達するのに苦労したことはありませんか。AIエージェントに提供される事前構築ツールやカスタム・ツールによって、ツールの実行またはアウトプットの解析エラーが発生していませんか。あるいは、こうした複雑さにより、独自のエージェントを完全に開発することを思いとどまったことはないでしょうか。

これらの問題は、モデル・コンテキスト・プロトコル（MCP）を使用して解決できます。MCPを使用すると、AIエージェントはツール統合の標準化されたプロトコルに準拠しながら、コンテキストを認識できます。

AIエージェントは、ユーザーまたは別のシステムに代わってタスクを自律的に実行できるシステムまたはプログラムです。ワークフローを設計し、利用可能なツールを使用して実行します。マルチエージェント・システムは、ユーザーまたは別のシステムに代わってタスクを実行するために共同で動作する複数のAIエージェントで構成されます。

AIアプリケーションのMCPは、ハードウェアのUSB-Cポートと同じ目的を果たすと考えられます。¹この類似は、USB-Cポートがハードウェアを接続するために提供する適応性と、さまざまなツールやデータ・ソースがMCPを通じてAIモデルにコンテキストを提供する標準化された方法を比較して強調しています。

Granite、Gemini、Llamaなどの大規模言語モデル（LLM）は、単独でデプロイすると機能が制限されます。AIツールがない場合、LLMは次のようないくつかの分野で熟練しています。

• 後続テキスト予測： LLMに「Jack and Jill went up the...（ジャックとジルは～に登った）」のような文を入力すると、「ジャックとジルは丘の上に登った」という正しい推測が得られます。このプロンプトと応答は、後続テキスト予測の一例であり、モデルがトレーニングされたテキストで最もよく機能します。
• 基本的なQ&A： LLM自体は外部データベースやWeb検索にアクセスできないため、モデルのトレーニングに使用されたデータ内の情報に関連する自然言語による質問に答えることができます。たとえば「ベルサイユ条約について教えて」などです。歴史上の戦争に関するこの情報は汎用モデルのトレーニング・データに含まれている可能性が高いからです。LLMは多くの場合、このテキスト生成をチャットボットの形式で実行します。
• センチメント分析： LLMはテキストを処理し、それが肯定的、否定的、または中立的な感情を表現しているかどうかを判断できます。
• 言語翻訳： LLMは、言語や地域を超えてテキストを翻訳できます。ただし、すべてのLLMが複数の言語のデータでトレーニングされるわけではありません。

基本機能とは別に、外部ツールにアクセスできないLLMは、リアルタイムの情報へのアクセスが必要なユーザー・クエリーを正常に実行できません。LLMがより有意義な結果を生み出せるように、ツールの統合を導入できます。Web検索、データセット、APIなどの外部ツールを提供することで、LLMの機能をトレーニング・データを超えて拡張できます。

さらに一歩進めて、LLMと利用可能なツールを使用してAIエージェントを構築できます。要約すると、エージェント・システムはLLMに一連のツールを提供し、モデルが適切なツールの使用を決定できるようにし、変化する環境に適応し、ツールのアウトプットに基づいて合成された結論を導き出せるようにします。しかし、こうしたAIシステムは大規模に失敗する傾向にあります。そのため、2024年にAnthropic社によって導入されたMCPが、AIツールとのやり取りのオープン・スタンダードになりました。 ²

外部サービスをLLMに接続するのは面倒です。モーターをさまざまな電源に接続する電気回路を想像してください。MCPはこの回路の配線と配電盤のようなもので、モーター（AIモデル）に流れる電流（情報）を決定します。ツールのアウトプットまたはモデルのコンテキストは、入力電流と比較できます。これは、電源から流れる電圧であり、メモリー、ツール、過去の結果を含むことができます。

MCPは配電盤として、どの電源（ツールのアウトプットまたはコンテキスト）を接続するか、いつ接続するかを決定し、電流（情報の流れ）を規制し、入力をフィルタリングし、優先順位を付けます。関連するワイヤーのみが作動する（関連するコンテキストがロードされる）ようにし、回路のタイミングとルーティングを管理して、システムが過負荷にならないようにします。

適切に設計された回路が過負荷を防止し、効率的な電力使用を保証するのと同様に、MCPは最適なAIモデルの性能を実現するための、効率的で関連性が高く構造化されたコンテキストの使用を促進するコネクターとして機能します。

MCPは、AIエンジニアが合意できる新しいオープンソース標準を確立します。ただし、ソフトウェアの業種において標準は新しい概念ではありません。たとえば、REST APIは業界標準であり、REST設計原則に準拠したHTTP要求を通じてアプリケーション間で一貫したデータ交換を提供します。

同様に、MCPはLLMと外部サービスを統合し、標準を設定することで効率的に通信させます。この標準により、各ツールのカスタム統合のコードを記述する代わりに、"プラグ・アンド・プレイ"ツールを使用できるようになります。

MCPはエージェント・フレームワークではなく、ツールにアクセスするエージェントのための標準化された統合レイヤーです。エージェント・オーケストレーション・フレームワークを補完します。MCPは、LangChain、LangGraph、BeeAI、LlamaIndex、CrewAIなどのエージェント・オーケストレーション・フレームワークを補完できますが、これらを置き換えるものではありません。MCPは、ツールをいつ、どのような目的で呼び出すかについては決定しません。

MCPは、ツールの統合を合理化するための標準化された接続を提供するだけです。 ³最終的に、LLMがユーザーの要求のコンテキストに基づいて、どのツールを呼び出すかを決定します。

MCPクライアント/サーバー・モデルは、3つの主要なアーキテクチャー・コンポーネントに分類できます。

AIアプリケーションはユーザーからの要求を受信し、MCPを通じてコンテキストへのアクセスを求めます。この統合レイヤーには、CursorやClaude DesktopなどのIDEを含めることができます。これにはオーケストレーション・ロジックが含まれており、各クライアントをサーバーに接続できます。これにはオーケストレーション・ロジックが含まれており、各クライアントをサーバーに接続できます。⁴

ホストとサーバー間のMCPエコシステム内の通信は、クライアントを介する必要があります。このクライアントはホスト内に存在し、ユーザーからの要求をオープン・プロトコルが処理できる構造化形式に変換します。1つのMCPホストに複数のクライアントが存在できますが、各クライアントはMCPサーバーと1:1の関係を持ちます。

MCPクライアントの例としては、IBM® BeeAI、Microsoft Copilot Studio、Claude.ai、Windsurf Editor、Postmanなどがあります。クライアントはセッション・マネージャーとして機能し、中断、タイムアウト、再接続、セッションの終了を処理します。クライアントは応答の解析も行い、エラー処理を実施して、応答がコンテキストに関連し、適切であることを確認します。⁴

ユーザー要求をサーバーのアクションに変換することにより、LLMにコンテキストを提供する外部サービス。MCPサーバー統合の例には、Slack、GitHub、Git、Docker、Web検索などがあります。これらのサーバーは通常、さまざまなプログラミング言語（C#、Java™、 TypeScript、Pythonなど）で利用可能なGitHubリポジトリであり、MCPツールへのアクセスを提供します。

チュートリアルは通常、これらのGitHubリポジトリ内にあり、技術的な実装を支援します。MCPサーバーは、IBMやOpenAIなどのAIプラットフォーム・プロバイダーを介してLLM推論をMCP SDKに接続するためにも使用できます。そうすることで、クライアントが"標準化された"チャット・ツールとしてアクセスできる、再利用可能なMCPサービスが作成されます。

MCPサーバーは、多用途で、内部と外部両方のリソースとツールへの接続を可能にします。Anthropic社が提供する資料によると、モデル・コンテキスト・プロトコルのサーバーは次のようにしてデータを公開しています。

• リソース： 内部または外部のデータベースからの情報検索。リソースはデータを返しますが、実用的な計算は実行されません。⁵
• ツール： 計算やAPI要求を通じたデータ取得などの副次作用を実行できるツールとの情報交換。⁶
• プロンプト： LLMサーバー通信用の再利用可能なテンプレートとワークフロー。⁷

クライアントとサーバー間のトランスポート層は、双方向のメッセージ変換を担当します。クライアントからサーバーへのストリームにおいて、MCPプロトコル・メッセージはJSON-RPC形式に変換され、複数のデータ構造とその処理ルールを転送可能にします。⁸

サーバーからクライアントへの逆方向の通信ストリームでは、JSON-RPC形式で受信したメッセージをMCPプロトコル・メッセージに戻して変換します。⁹JSON-RPCの3つのメッセージ・タイプには、要求、応答、通知が含まれます。要求にはサーバーからの応答が必要ですが、通知には必要ありません。

クライアントとサーバー間のトランスポート層には、MCPプロトコルの主な転送方法が2つあり、どちらもJSON-RPC 2.0形式でメッセージを送信します。1つ目は、標準入出力（stdio）です。これは、シンプルなインプット/アウトプット情報が送信されるため、ローカルなリソースの統合に最適です。この形式は、軽量で同期型のメッセージングに使用されます。⁴このようなリソースには、ローカル・ファイル・システム、データベース、ローカルAPIが含まれます。

2つ目は、リモートのリソースの統合に最適なサーバー送信イベント（SSE）です。HTTP POST要求はクライアントからサーバーへのメッセージを送信するメカニズムとして機能し、SSEはその逆に使用されます。この形式は、複数の非同期でイベント駆動型のサーバー呼び出しを同時に処理するために使用できます。⁴

受信トレイをスキャンしてクライアントとの会議のスケジュールを設定し、在庫情報を送信し、過去1時間のSlackアクティビティの概要をテキストで送信してくれる、現実世界のAIを想像してみてください。どのサービス・プロバイダーも、渡すために必要な情報が異なるためAPIの構築方法が異なり、異なるアウトプット・スキーマを返します。したがって、これらのツールのわずかな変更が、このAIワークフロー全体のインフラストラクチャーの崩壊につながりかねません。

また、これらのツール接続を手動で構築し、APIキーやツール権限などの認証をデバッグおよび維持するために、エンジニアに大きな開発負荷がかかります。ツールは他のツールのアウトプットに依存することが多く、これらの接続が失敗するエッジ・ケースは多く存在します。

したがって、LLMと開発ツールの間の中間層としてMCPの統合を提供することが重要です。この層では、MCPはモデルに理解できる方法でツールのアウトプットを変換できます。CLIを切り替える必要がなく、ツールの統合はすべて一箇所で行われます。

MCPには多くの実際のユースケースがあります。たとえば、MCPは、共通のツールを備えた共有ワークスペースを通じてマルチエージェントのオーケストレーションとコミュニケーションを強化し、直接統合の必要性を排除します。³

MCPは、検索拡張生成（RAG）を補完するためにも使用できます。MCPは、ベクトル・ストアまたはナレッジ・ベースを検索するためのリトリーバーを提供するのではなく、サーバー・アクションを通じてベクトル・データベースに接続できます。LLM呼び出しごとにリトリーバーに渡すのではなく、ツールとしてデータベースを検索することで、ツールをより戦略的に使用できるようになります。このアプローチにより、データ取得時に他のツールを呼び出すこともできます。³

MCPは、時間の経過とともに成熟し、再構築し続けるLLMツールへの統合に対する進化するアプローチです。技術的な課題が発生し、MCPサーバーが進化するにつれて、標準が適応され、MCPは改善し続けます。

いずれにせよ、AIエージェントが自律的に動作し、現実世界の環境に動的に適応するためには、標準化されたツールの統合が必要です。¹⁰MCPを使用すると、複雑なエージェントのワークフローの自動化を合理化し、人間による監視を減らすことができます。MCPによって実現されるこの変化により、人間の知性と直感を必要とするより細かなタスクに時間を費やすことができます。