MCPとAIエージェントの動作概要説明

概要

Anthropic が提唱する Model Context Protocol（MCP）は、LLM と外部システムとの連携を標準化するためのプロトコルです。本記事では MCP の基本構造と目的を整理しつつ、Claude をはじめとする AI エージェントが MCP を利用する際にどのようなコンテキスト設計が考えられるのかを仮説ベースで解説します。MCP はモデル内部のアーキテクチャを公開するものではなく、外部接続のインターフェースを整える設計思想である点を押さえながら、エージェント実装におけるポイントを整理します。

MCP の目的と役割

• N×M 統合問題の解消: MCP は LLM と外部ツール・データソースを結びつける際の共通インターフェースを提供し、「特定の LLM × 特定のツール」ごとに個別コネクタを実装する必要を減らします。
• 「AI 用 USB-C」的な発想: Anthropic は MCP を、AI がさまざまなツールに接続するための汎用ポートとして位置づけています。モデルは MCP を通じて、統一的なメッセージフォーマットでツールやリソースを呼び出せます。
• 仕様としての公開範囲: MCP が定義しているのはクライアント・サーバー間の通信手順やトランスポート層であり、モデル内部のプロンプトやアーキテクチャは公開対象外です。したがって MCP を有効化してもモデルの構造そのものが変わるわけではなく、外部との接続方法が標準化されるという理解が重要です。

MCP の基本構成

構成要素	役割・特徴
Host / Client / Server	MCP はホスト（例: Claude Desktop 等）がクライアントを束ね、MCP サーバーがツールやリソースを提供する三者構成を前提にしています。
Tools	サーバー側で提供される呼び出し可能な機能（関数、API、処理）群。tools/list で一覧化し、tools/call で実行します。
Resources	読み取り専用のデータセットやドキュメントを指し、resources/list・resources/read で参照します。
Prompt templates	サーバーがタスク向けプロンプトのテンプレートを配布し、クライアントがそれを使ってモデルへの指示を組み立てるための仕組みが想定されています。
JSON-RPC メッセージ	MCP は JSON-RPC 2.0 を通信形式に採用し、リクエスト・レスポンス・通知を統一フォーマットでやり取りします。
セッション管理	ステートフルな対話を可能にし、外部呼び出しの結果や履歴を踏まえた連携を実現します。
Capability Negotiation	初期フェーズでクライアントとサーバーが利用可能な機能をすり合わせる「能力交渉」が行われます。

この構造により、MCP サーバーはツールやデータを一元的に提供し、AI クライアントは標準的な手順で呼び出しを行えます。

Claude + MCP の動作イメージ

Claude などのエージェントが MCP を利用する際の高水準な流れは次のように推測できます。

1. 設定読み込みと接続準備: クライアント（例: Claude Desktop）が起動時に MCP サーバーの設定を読み込み、接続や権限を確認します。
2. 能力交渉: tools/list や resources/list を通じて利用可能な機能を把握し、クライアント側に登録します。
3. ユーザー入力の解析: ユーザーからのプロンプトが来ると、クライアントは MCP が有効であることを踏まえて、モデルに渡す前提指示を組み立てます。
4. モデルへのコンテキスト注入: プロンプトには、利用可能なツールやリソースの概要・呼び出し仕様が組み込まれ、モデルが必要なときに外部呼び出し命令を生成できるようにします。
5. 外部呼び出しの実行: モデルがツール利用を決定すると、クライアントが MCP の tools/call や resources/read を実行し、その結果を取得します。
6. 結果の再提示: 取得したデータは追補のプロンプトとしてモデルに再投入され、最終的な回答生成に活用されます。
7. 履歴・状態管理: どのツールをいつ利用したか、どんなレスポンスを得たかをクライアントが管理し、継続的なタスク遂行を支援します。

このループにより、モデルは「ユーザー入力 → ツール呼び出し → 結果反映 → 応答生成」というエージェント的な挙動を実現します。

モデルコンテキストにおける指示設計の仮説

MCP 自体は外部インターフェースを規定するものであり、モデルにどのような指示を与えるかはクライアント実装に依存します。想定される構成要素は以下の通りです。

• システム指示: 「あなたは高度な AI アシスタントであり、必要に応じて MCP 経由で外部リソースを呼び出す」といった役割定義を含む。
• ツール仕様の提示: 利用可能なツール名、引数、出力形式、注意点などをテキストで記述し、モデルが JSON 形式の呼び出しを生成できるようにする。
• ユーザー入力との統合: 通常の会話履歴や質問文と合わせて、どのタイミングでツールを使うべきか判断できるよう文脈を提供する。
• レスポンスの再投入: MCP 呼び出しの結果は次のターンでコンテキストに追加し、モデルがそれを参照しながら推論を続ける。

この構成は OpenAI の function calling 等と似ていますが、MCP はツール・リソースの登録と呼び出し手順を標準化し、異なるエコシステム間でも同じ手触りで連携できるように設計されている点が特徴です。

設計時に考慮すべきポイント

1. プロンプト長と情報選択: すべてのツール仕様を一度に注入するとトークンを圧迫するため、必要な情報のみを段階的に渡す工夫が必要です。
2. 遅延ロード戦略: 実際に利用する段階で初めてツール情報を追加するなど、プロンプト設計の効率化を検討します。
3. セキュリティと権限管理: MCP サーバー側でアクセス制御やサンドボックスを設定し、モデルが誤って権限外の操作を行わないようにします。
4. エラー処理: タイムアウトやフォーマット不一致など、ツール呼び出し失敗時のハンドリングをクライアント側で用意し、モデルにもリカバリ方針を伝えます。
5. 仕様と実装のギャップ: 公開仕様だけではクライアント実装の詳細は分からないため、実務では SDK やサンプルコードを参照しながら挙動を検証することが重要です。
6. 並列・複合ワークフロー: 複数ツールの同時利用やマルチエージェント構成を想定する場合、状態管理の複雑さが増すため、セッション設計やタスク分割の戦略をあらかじめ考慮します。

まとめ

• MCP は LLM と外部リソースを接続するための共通プロトコルであり、JSON-RPC ベースで Tools や Resources を扱うアーキテクチャを提供します。
• Claude のようなエージェントは、MCP を通じて利用可能な機能を把握し、必要に応じて外部呼び出しを行うループを構成すると考えられます。
• モデルに渡す前提指示は、システム指示・ツール仕様・ユーザー入力を統合して設計する必要があり、プロンプト長やエラー処理、権限管理などの観点で実装工夫が求められます。
• MCP の仕様は公開されていますが、各エージェントの内部実装はブラックボックスであるため、実証実験や SDK の活用を通じて挙動を理解する姿勢が重要です。

MCP を導入することで、AI エージェントが扱える外部リソースの幅は大きく広がります。コンテキストエンジニアリングの視点では、モデルがどのような情報を必要とし、いつツールを呼び出すべきかを丁寧に設計することで、より信頼性の高いエージェント体験を構築できます。