AIにおけるMCPとは？Model Context Protocolを解説

AIにおけるMCPとは？

MCPはModel Context Protocolの略です。

これは、AIアプリケーションをファイル、データベース、検索ツール、カレンダー、コードリポジトリ、業務ソフトウェアなどの外部システムに接続するためのオープンソース標準です。公式MCPドキュメントでは、MCPをUSB-Cポートにたとえています。さまざまなデバイスが、組み合わせごとに新しいケーブルを必要とせず、同じ接続規格を利用できるという意味です。

このたとえは分かりやすい一方で、MCPを実際よりも単純なものに聞こえさせる可能性もあります。

MCPはAIモデルでも、アプリケーションでも、APIの代替でもありません。互換性のあるAIアプリケーションとサーバーが使用する通信標準です。アプリケーションがユーザーの&​​rsquo;リクエストを理解するには、依然として言語モデルが必要です。また、接続されたサービスは通常、内部で既存のAPIを利用します。

より正確に定義すると、次のようになります。

MCPは、AIアプリケーションが外部ツールやデータソースを発見し、接続し、情報を交換する方法を標準化します。

ここで「コンテキスト」という言葉が重要になります。言語モデルが知っているのは、学習データに含まれている情報、または現在のやり取り中に提供された情報だけです。MCPを使うと、必要に応じて、現在のデータベースレコード、ローカルファイル、リアルタイムAPIリクエストの結果など、追加のコンテキスト—にAIアプリケーションがアクセスできるようになります。

Model Context Protocolはなぜ作られたのか？

MCP以前は、開発者は通常、AIアプリケーションと外部サービスの組み合わせごとに個別の連携を構築していました。

Google Calendar、GitHub、顧客データベース、社内請求システムと連携する必要があるAIアシスタントを想像してください。連携ごとに、独自のAPI形式、認証プロセス、関数定義、エラー処理ルールが存在する可能性があります。

さらに、別のAIアシスタント向けに同じ接続をもう一度構築することを考えてみてください。

MCPは、この繰り返し発生する連携作業の削減を目指します。サービスはMCPサーバーを通じて機能を公開でき、互換性のあるAIアプリケーションは共通プロトコルを通じて接続できます。

これは、開発者が連携の構築をやめられるという意味ではありません。誰かがMCPサーバーを実装し、基盤となるサービスに接続し、認証情報を管理し、リクエストを検証し、システムを保守する必要があります。メリットは再利用性です。ある機能がプロトコルに準拠すれば、複数の互換性のあるAIホストに接続しやすくなる可能性があります。

MCPの価値が最も高まるのは、ツール、データソース、AIクライアントの数が増え始めたときです。1つのアプリケーションを1つの安定したサービスに接続するだけなら、直接API連携のほうがシンプルな選択肢であり続ける場合があります。

MCPの仕組み：ホスト、クライアント、サーバー

MCPはクライアント・サーバーアーキテクチャを使用しますが、3つの要素が関わるため、用語が分かりにくいことがあります。

MCPホスト

ホストとは、ユーザーが操作するAIアプリケーションです。チャットアシスタント、コーディング環境、デスクトップアプリケーション、カスタムAIエージェントなどが該当します。

ホストは会話を調整し、言語モデルと通信し、権限を管理し、どのMCP接続を利用可能にするかを決定します。

MCPクライアント

MCPクライアントは、ホスト内でMCPサーバーへの接続を維持するコンポーネントです。

公式MCPアーキテクチャによると、ホストは通常、サーバーごとに個別のクライアント接続を作成します。アプリケーションがファイルシステムサーバーとカレンダーサーバーに接続する場合、2つのMCPクライアントを管理します。

MCPサーバー

MCPサーバーは、特定の機能をMCPクライアントから利用できるようにするプログラムです。ユーザーのデバイス上でローカルに実行することも、別のサーバー上でリモートに実行することもできます。

MCPサーバーは、次の3種類の中核機能を公開できます。

• ツール：データベースへのクエリ、カレンダーイベントの作成、メッセージの送信など、実行可能な関数。
• リソース：ファイル、データベースレコード、APIレスポンスなど、アプリケーションが読み取れる情報。
• プロンプト：モデルとのやり取りの構成に役立つ再利用可能なテンプレート。

ホストとサーバーはまず、双方がサポートするプロトコル機能をネゴシエーションします。その後、クライアントは利用可能な機能の一覧をリクエストできます。モデルがあるツールに関連性があると判断すると、ホストは構造化されたリクエストをMCPクライアント経由で適切なサーバーに転送します。

結果はAIアプリケーションに返され、モデルの次の応答のための追加コンテキストになります。

リクエストからツール結果まで：MCPの実例

社内AIアシスタントに、開発者が次のように依頼したとします。

「今月のAPI利用額を確認してください。予算を20%以上超えている場合は、エンジニアリングチーム向けのアラートを作成してください。」

簡略化したMCPワークフローは、次のようになります。

1. AIアプリケーションがリクエストを受け取り、言語モデルに送信します。
2. MCPクライアントは、接続された財務サーバーがget_api_usageとget_budget_limitを提供していることを発見します。
3. モデルはそれらのツールを選択し、必要な日付範囲を指定します。
4. MCPサーバーは会社の請求APIを呼び出し、現在の利用額と予算を返します。
5. モデルは、利用額が上限を20%以上超えているかどうかを計算します。
6. アラートが必要な場合、アプリケーションはcreate_alertなど、接続されたメッセージングツールを特定します。
7. この操作は外部システムを変更するため、アプリケーションはユーザーに確認を求めることができます。
8. 承認後、メッセージングサーバーが基盤となるメッセージングAPIを呼び出します。
9. モデルは、見つかった内容と実行した操作をユーザーに伝えます。

MCPは、このプロセスの中間部分、つまりツールの発見、入力要件の説明、ツールの呼び出し、構造化された結果の返却を標準化します。

MCP自体が計算を実行したり、言語モデルを提供したり、請求APIやメッセージングAPIを置き換えたりするわけではありません。

MCP vs API vs 関数呼び出し vs RAG

これらの用語は、互いに競合するテクノロジーとして説明されることがあります。実際には、それぞれ異なるレイヤーで動作し、同じアプリケーション内に共存することがよくあります。

MCPはAPIに取って代わるのか？

いいえ。MCPとAPIは、関連していますが異なる課題を解決します。

APIは、特定のサービスを呼び出す方法を定義します。たとえば、請求APIはアカウントの利用状況を返すエンドポイントを定義できます。

MCPは、互換性のあるサーバーが公開する機能をAIアプリケーションが発見し、利用する方法を定義します。そのサーバーは、実際のデータを取得するために請求APIを呼び出す場合があります。

言い換えると、次のとおりです。

APIはソフトウェアをサービスに接続します。MCPは、AIアプリケーションが共通プロトコルを通じて多くのサービスを扱えるようにします。

アプリケーションが必要とする機能が1つだけで固定されている場合は、直接API連携のほうが高速で簡単なこともあります。複数のAIクライアントでツールを再利用したい場合や、利用可能な機能を動的に変更したい場合は、MCPの魅力が高まります。

MCPは関数呼び出しと同じものか？

いいえ。関数呼び出しは一般にモデルの機能です。開発者が1つ以上の関数を記述し、モデルはその関数を使うべきだと判断したときに、構造化された引数を生成します。

MCPはそのプロセスを取り巻く仕組みです。すべてのツールをアプリケーションにハードコードする代わりに、接続されたサーバーからツール定義を発見できるようアプリケーションを支援します。

モデルは、MCPが提供するツールを選択するために、関数呼び出しまたはツール呼び出しに依存する場合があります。

MCPはRAGの一種か？

いいえ。検索拡張生成（RAG）は、関連情報を取得してモデルのコンテキストに追加してから、モデルに回答させる手法です。

MCPサーバーは、RAGシステムの一部となるドキュメント検索ツールを公開できます。ただし、MCPはドキュメントのインデックス方法、結果のランキング方法、取得したテキストをプロンプトに追加する方法を決定しません。

MCPはリクエストと結果を運びます。検索を実行するのは検索システムです。

MCPでできること、できないこと

MCPは、互換性のあるアプリケーション間でツールを再利用しやすくします。また、ハードコードされた接続だけに頼るのではなく、利用可能なツールと必要な入力をアプリケーションが発見できるようにします。

ただし、一般的な主張の中には行き過ぎたものもあります。

MCPは次のことを行いません。

• MCPクライアントをサポートしていないアプリケーションを互換性のあるものにする。
• 基盤となるAPIやビジネスロジックを不要にする。
• すべての認証要件や権限要件を自動的に処理する。
• モデルが正しいツールを選択することを保証する。
• ツールが正確なデータを返すことを保証する。
• サードパーティ製サーバーをデフォルトで安全にする。
• 連携の監視、更新、保守を不要にする。
• 接続されたシステム間で全データを自動的に共有する。

また、モデルに接続されたすべてのサービスへの無制限アクセスを与えるわけでもありません。どのサーバーを接続するかはホストが制御し、何を読み取ったり変更したりできるかは、サーバーの機能とユーザー権限によって決まります。

開発者はいつMCPを使うべきか？

複数のツールやデータソースに接続する必要があるアプリケーションでは、MCPを検討する価値があります。特に、これらの機能を異なるAIホスト間で再利用する可能性がある場合に有効です。

代表的な状況は次のとおりです。

• ドキュメント、データベース、サポートチケットを検索する社内アシスタント。
• リポジトリ、課題管理システム、監視システムを扱うコーディングエージェント。
• 複数のライブデータソースにクエリを実行する調査アプリケーション。
• レコードを読み取り、他のソフトウェアで承認済みの操作を実行する業務エージェント。
• 自社サービスを複数のMCP互換クライアントで利用できるようにしたいツールプロバイダー。

アプリケーションのワークフローが1つに限定されている場合、1つのサービスしか使わない場合、またはすべてのリクエストを低レベルで厳密に制御する必要がある場合は、直接API連携のほうが適している可能性があります。MCPサーバーを追加すると、デプロイ、セキュリティ確保、テスト、監視が必要な別のコンポーネントが増えます。

MCPは連携の重複作業を一部削減しますが、アーキテクチャ上のトレードオフをなくすものではありません。

MCPは安全か？

MCPは自動的に安全にも危険にもなりません。セキュリティは、ホスト、サーバー、その基盤サービス、認証フロー、各操作に付与された権限に依存します。

接続されたサーバーは、AIアプリケーションから機密情報を受け取る可能性があります。書き込み権限を持つツールは、ファイルの変更、メッセージの送信、レコードの作成、その他の外部操作の実行も可能です。

公式のMCPセキュリティガイダンスでは、トークンパススルー、サーバーサイドリクエストフォージェリ、セッションハイジャック、侵害されたローカルサーバー、混乱した代理人攻撃などのリスクを扱っています。これらは実装上のリスクであり、標準プロトコルを使用することで消える理論上の問題ではありません。

開発者は、次の基本的な対策を講じるべきです。

• 信頼でき、検証可能なサーバーにのみ接続する。
• 各サーバーには必要最小限の権限のみを付与する。
• 読み取り専用ツールとデータを変更するツールを分離する。
• 機密性の高い操作や破壊的な操作には確認を必須にする。
• ツールの入力と出力を検証する。
• 認証情報をプロンプトやツールの説明に含めない。
• 調査と監査のためにツール呼び出しをログに記録する。
• リモートサーバーに送信される可能性がある情報を確認する。

OpenAIも、カスタムMCPサーバーがデータを受け取り、外部操作を実行できる可能性があると警告し、信頼できるサーバーにのみ接続するよう推奨しています。現在の実装では、ChatGPTの会話における書き込み操作の前に確認を求めますが、すべてのMCPクライアントが同じポリシーを適用すると想定してはいけません。OpenAIのMCPドキュメント

2026年にMCPで何が変わったのか？

2026年7月現在、最新の安定版MCP仕様は、2025年11月25日にリリースされたバージョンです。公式プロジェクトは、それ以降に別の仕様バージョンを公開していないと説明しています。2026年MCPロードマップに記載されているのは計画中の作業であり、安定版プロトコルですでに保証されている機能ではありません。

現在の仕様では、2つの標準トランスポートを定義しています。

• stdio：ローカルプロセスとの通信に使用。
• Streamable HTTP：リモートMCPサーバー向け。

Streamable HTTPは従来のHTTP+SSEトランスポートに取って代わりましたが、クライアントとサーバーは後方互換性を維持できます。現在のトランスポート仕様には、認証、オリジン検証、ローカルネットワークへのバインディング、セッション管理に関する要件と推奨事項も含まれています。

MCPのガバナンスも変化しました。2025年12月、プロトコルはLinux FoundationのAgentic AI Foundationの創設プロジェクトになりました。同財団は、10,000を超えるMCPサーバーが公開され、ChatGPT、Claude、Gemini、Microsoft Copilot、Cursor、Visual Studio Codeなどの製品で採用されていると報告しています。Linux Foundationの発表

2026年のロードマップは、トランスポートのスケーラビリティ、エージェント間通信、ガバナンス、エンタープライズ対応の4分野に重点を置いています。監査証跡、SSO統合認証、構成のポータビリティ、ゲートウェイの動作など、エンタープライズ分野の課題は引き続き取り組まれています。

最後の点は重要です。MCPはローカル開発者ツール向けの実験段階を超えましたが、エンタープライズ向けのセキュリティと運用モデルの一部はまだ成熟の途上にあります。

MCPアプリケーションにおけるGPT Protoの役割

GPT ProtoとMCPは、AIアプリケーションの異なるレイヤーに属します。

MCPはアプリケーションを外部ツールやコンテキストに接続します。一方、アプリケーションには、リクエストを理解し、アクションを選択し、最終的な応答を生成するモデルが依然として必要です。

そのモデルには、モデルAPIプロバイダーを通じてアクセスできます。GPT Protoモデルカタログを利用する開発者は、この推論レイヤー向けにテキストモデルや推論モデルを選択でき、MCPサーバーは外部システムへの接続を担います。

簡略化した構成には、次の要素が含まれます。

• MCPホストとして動作するAIアプリケーション。
• 推論と生成のためにGPT Proto経由でアクセスする言語モデル。
• ホストが管理する1つ以上のMCPクライアント。
• 外部ツールとデータを公開するMCPサーバー。
• それらのサーバーが内部で利用する既存のAPI。

この2つのレイヤーは相互補完的です。共通のモデルAPIにより、アプリケーションの背後にあるモデルのテストや変更が容易になります。一方、MCPは、そのアプリケーションを複数のツールに接続する際の繰り返し作業を削減できます。