Model Context Protocol (MCP) とは何か？ AI とツールやデータをつなぐ標準

Model Context Protocol (MCP) は、AI アプリケーションが外部ツール、データ、プロンプト、その他の機能と一貫したインターフェースを通じて接続できるオープン標準です。 各モデルとシステムの組み合わせごとにカスタム統合を構築する代わりに、開発者は AI ホストと MCP サーバー間で共有プロトコルを実装できます。

MCP はしばしば AI のユニバーサルコネクタと説明されますが、この比喩は不完全です。プロトコルは単にデータを移動させるだけではありません。参加者が機能を確立し、リソースやアクションを公開し、構造化メッセージを交換し、セキュリティ境界を維持する方法を定義します。これにより、AI アシスタントやエージェント向けの新興インフラストラクチャの重要な部分となります。

MCP が存在する理由

モデル単体では、企業のプライベート文書を閲覧したり、ローカルリポジトリを検査したり、ライブデータベースにクエリを投げたり、内部サービスを呼び出したりすることはできません。開発者は従来、これらの機能を単発プラグインやアプリケーション固有の API を通じて接続してきました。

このアプローチは統合の問題を生み出します。10 個の AI アプリケーションがそれぞれ 10 個のシステムに接続する必要がある場合、チームは数十のカスタムアダプタを維持することになり得ます。各アダプタはツール、コンテキスト、認証、エラー、更新をそれぞれ異なる方法で表現する可能性があります。

MCP は共通の契約を作成します。MCP 対応アプリケーションは、既知の形式で機能を公開する MCP サーバーと通信できます。公式の Model Context Protocol specification はプロトコルを定義し、個々のホストとサーバーはサポートする機能やセキュリティポリシーを決定します。

MCP アーキテクチャ

MCP は、AI アプリケーションの対話とモデルロジックを、各データソースやサービスに必要な統合ロジックから分離します。ホストは同時に複数のクライアント接続を維持でき、たとえばファイルシステムサーバー用、データベースサーバー用、ビジネスアプリケーション用の接続を持ち、これらの機能を一貫したインターフェースを通じてモデルに提示します。

サーバーは必ずしもリモートのインターネットサービスである必要はありません。デスクトップアプリケーションの横でローカルに実行したり、社内ネットワーク内で動作させたり、リモートサービスとして提供したりできます。この配置選択は転送方法や信頼境界を変えますが、中心的な関係は変わりません。クライアントはサーバーから機能を検出し、構造化メッセージを交換します。

MCP はホスト‑クライアント‑サーバー アーキテクチャを使用します。

• Host: ユーザーが対話する AI アプリケーション（アシスタント、コーディング環境、エージェントプラットフォームなど）
• Client: 特定の MCP サーバーとの接続を維持するためにホストが作成するプロトコルコンポーネント
• Server: 選択されたツール、リソース、プロンプトを MCP クライアントに公開するプログラム

ホストは同時に複数のサーバーに接続できます。あるサーバーはファイルリポジトリへのアクセスを提供し、別のサーバーはプロジェクト管理システムへのアクセスを提供し、さらに別のサーバーは内部データベースへのアクセスを提供することがあります。ホストはユーザー体験、モデルのオーケストレーション、同意、そしてモデルコンテキストに配置される情報について責任を負い続けます。

メッセージは JSON-RPC の慣例に従って構造化されます。初期化時に、参加者はプロトコルバージョンと機能を交渉します。この交渉は重要です。なぜなら、クライアントとサーバーはすべてのオプション機能を実装する必要はないからです。

ツール、リソース、プロンプト

MCPはサーバーが提供する機能をいくつかのプリミティブに整理します。最もよく知られている3つはツール、リソース、そしてプロンプトです。

ツール

ツールとは、AIアプリケーションが呼び出すことのできる実行可能な関数です。例として、顧客データベースの検索、課題の作成、クエリの実行、現在の在庫の取得などがあります。ツールの定義には名前、説明、入力スキーマが含まれ、モデルとランタイムが期待される引数を把握できるようにします。

ツールの使用は外部システムを変更する可能性があるため、ホストは意味のある説明を表示し、入力を検証し、権限を適用し、重要な操作については確認を求めるべきです。

リソース

リソースとは、アプリケーションが読み取れるコンテキストで、ファイル、データベースレコード、ドキュメントページ、生成されたレポートなどが含まれます。リソースは識別子を使用し、名前やメディアタイプといったメタデータを公開できます。これにより、ホストはすべての読み取り操作をアクションと見なすことなく、情報を発見・取得する標準化された手段を得られます。

プロンプト

プロンプトは、サーバーがホストに提供する再利用可能なテンプレートまたはワークフローです。ユーザーが機能を正しく呼び出すのを支援したり、構造化された引数を提供したり、ドメイン固有の指示と関連コンテキストを組み合わせたりすることができます。

MCPは逆方向の機能もサポートします。交渉内容に応じて、サーバーはホストにモデルの補完やユーザー入力の取得を依頼することがあります。重要な設計原則は、すべての参加者がすべての操作を実行できると仮定せず、明示的に機能交渉を行うことです。

MCPツール呼び出し時に何が起こるか

リポジトリ分析サーバーに接続されたAIコーディングアシスタントを考えてみましょう。

1. ホストはMCPサーバーに接続し、サポートされる機能について交渉します。
2. クライアントは利用可能なツールの一覧を要求します。
3. サーバーは入力スキーマを含む構造化されたツール定義を返します。
4. ホストは選択されたツールの説明をモデルに提供します。
5. モデルは関数への参照検索など、ツール呼び出しを提案します。
6. ホストはポリシーを確認し、必要に応じてユーザーに承認を求めます。
7. クライアントは検証済みのリクエストをサーバーに送信します。
8. サーバーは操作を実行し、構造化されたコンテンツまたはエラーを返します。
9. ホストは次のステップでモデルに提供する結果のどの部分かを決定します。

MCPはやり取りを標準化しますが、モデルがツールを呼び出すべきかどうかの判断は行いません。その決定はホストとそのポリシーレイヤーに委ねられます。

MCPはAPIに取って代わるものではありません

MCPサーバーは既存のAPI、ソフトウェア開発キット、コマンドラインツール、またはデータベースドライバーをラップすることが多く、これらの基盤インターフェースが実際の処理を行います。MCPはそれらの上にAI指向の発見と相互作用の層を追加します。

この違いにより、MCPがREST、GraphQL、その他のアプリケーションインターフェースと補完的であることが説明されます。決済サービスは成熟したAPIを維持しつつ、MCPサーバーはモデルに適した説明とスキーマを持つ、慎重に限定された操作のサブセットを公開できます。

MCP と関数呼び出しの比較

関数またはツール呼び出しはモデルの機能であり、モデルは関数を呼び出すための構造化リクエストを返すことができます。MCPはツールやコンテキストの提供者を発見し、通信するためのプロトコルです。

この二つはしばしば連携して動作します。MCPサーバーはホストに利用可能なツールを通知し、ホストは選択された定義をモデルに提示します。モデルはツール呼び出しを発行し、ホストはMCPを使ってそのリクエストを適切なサーバーに送ります。

MCP と Agent2Agent の比較

MCPはAIアプリケーションと機能・コンテキストを接続します。Agent2Agent（A2A）は、異なるシステムや組織が所有する自律エージェント間の通信に焦点を当てます。

実用的なシステムは両方を利用できます。エージェントはMCPでツールやデータにアクセスし、A2Aで別のエージェントに大規模なタスクを委任することができます。MCPは「このアプリケーションはその機能をどう利用できるか？」に答え、A2Aは「これらのエージェントはどう協調して作業できるか？」に答えます。

セキュリティリスクと制御

安全なホストはサーバーとツールの明示的な許可リストを維持し、アクセスが許可された際には意味のある同意を表示し、すべての呼び出しをそれを認可したユーザーまたはワークロードの ID と紐付けます。ツールスキーマは予期しない引数を拒否できる程度に絞り、監査ログにはサーバー、機能、入力、結果ステータス、承認経路を記録すべきです。

返却されたリソースやツールの結果もプロンプトインジェクションの対象となります。MCP を通じて読み取られた文書には、モデルに指示を無視させたりデータを外部に流出させたりするテキストが含まれることがあります。ホストは信頼できないコンテンツとシステムポリシーの区別を保ち、あるサーバーの出力が別のサーバーの権限を黙って拡大しないようにすべきです。

標準化は相互運用性を向上させますが、サーバーを信頼できるものにするわけではありません。MCP サーバーは機密データ、誤解を招くツール説明、危険な操作、または侵害された依存関係を露出させる可能性があります。リソースを通じて取得された信頼できないコンテンツにも、モデルを操作しようとするプロンプトインジェクション指示が含まれることがあります。

重要な制御項目は次のとおりです：

• 最小特権: 各サーバーには目的に必要な認証情報とスコープだけを付与します。
• サーバーの信頼性: 接続前にサーバーの出所、コード、所有権、更新経路を検証します。
• ユーザーへの可視性: どのサーバーがデータを受け取り、どの操作を実行するかを明確に示します。
• 入力検証: モデル外でスキーマとビジネスルールを適用します。
• 承認境界: 敏感、外部、財務、破壊的な操作を確認します。
• データ最小化: 必要な一部だけで済む場合に、文書全体や会話全体を送信しないようにします。
• ロギングと取り消し: 呼び出しを記録し、異常を監視し、認証情報や接続を簡単に無効化できるようにします。

MCP プロジェクトはアーキテクチャとセキュリティガイダンスの改良を続けています。プロジェクトの 2026 specification update は、標準がシンプルなインフラストラクチャ、認可、そして本番展開を中心に進化していることを示しています。

開発者が MCP を使用すべきタイミングは？

MCP は、複数の AI クライアントが同一機能への一貫した接続を必要とする場合、ツールを実行時に検出可能にしたい場合、またはチームが AI オーケストレーションとシステム固有の統合コードを分離したい場合に適しています。

バックエンドが一つで厳密に管理された小規模アプリケーションでは、直接関数呼び出しの方がシンプルなままであることがあります。プロトコルの採用には、サーバーのライフサイクル管理、互換性テスト、認証、可観測性、ガバナンスといった運用作業が伴います。

Model Context Protocol (MCP) について覚えておくべきこと

MCP は AI アプリケーションとそれらを取り巻くツールやコンテキスト間の共通言語です。その価値は、個別の統合慣例を発見可能で構造化された拡張性のあるプロトコルに置き換えることにあります。

この標準は慎重なエンジニアリングの必要性を排除するものではありません。ホストは依然として、どのサーバーを信頼し、どの機能を公開し、どのデータを共有し、いつ人が操作を承認すべきかを判断しなければなりません。MCP は接続をポータブルにし、ガバナンスがそれらを安全かつ有用にします。