MCP（Model Context Protocol）とは：定義・仕組み・具体例

自分自身としか対話できないAIエージェントは、あまり役に立ちません。本当に行動するためには、ファイルを読み、データベースに問い合わせ、ツールに書き込む必要があります。MCPは、新しいツールが登場するたびに接続方法を再発明するのではなく、この接続を標準化するために生まれたプロトコルです。

詳しい定義

プロトコルの公式サイトは、MCPを「AIアプリケーションを外部システムに接続するためのオープンスタンダード」と定義しています。これにより、データソース(ローカルファイル、データベース)、ツール(検索エンジン、計算機)、ワークフロー(専用のプロンプト)へのアクセスが可能になります。公式ドキュメントはこの考え方をシンプルな比喩でまとめています。MCPは「AIアプリケーションにとってのUSB-Cポートのようなもの」であり、機器ごとに異なるケーブルを用意するのではなく、標準化されたコネクタだというわけです。

このプロトコルは、2024年11月25日にAnthropicによって発表されました。発表では、MCPが解決しようとする課題が説明されています。AIアシスタントは、重要なデータからも切り離されたままであり、新しいデータソースが増えるたびに専用の実装が必要になるため、新しいツールや新しいモデルが登場するたびに連携の問題が倍増していく状況でした。Anthropicは同時に、仕様、開発キット、Google Drive、Slack、GitHub、Git、Postgresといったツール向けのリファレンスMCPサーバーのリポジトリを公開しました。詳しくはAnthropicの発表をご覧ください。

IBMは、補完的な技術的定義を提示しています。MCPとは、「AIアプリケーションが、ツール、データベース、あらかじめ定義されたプロンプトのテンプレートといった外部サービスと効率的にやり取りできるようにする標準化のレイヤー」だとしています。この説明は、しばしば見落とされがちな点を強調しています。MCPは、エージェントにいつツールを使うべきか、複数のステップをどうオーケストレーションすべきかを指示するものではありません。ツールがどのように自らを記述し、接続するかを標準化するだけです。詳しくはIBMのMCPに関するページをご覧ください。

仕組み

MCPは、公式ドキュメントで詳しく説明され、Microsoftの.NETドキュメントでも取り上げられている、3つの役割からなるクライアント・サーバーアーキテクチャに従っています。MCPホスト(MCP host)は、アシスタントやコードエディタといったAIアプリケーションそのものです。接続する各サービスごとに専用のMCPクライアントを作成します。各クライアントは、実際にデータやアクションを公開するプログラムであるMCPサーバーとの接続を維持します。MCPサーバーは、ユーザーのマシン上でローカルに動作することもあれば、ツール提供元のサーバー上でリモートに動作することもあります。

具体的には、MCPサーバーは3種類の要素を公開します。ツール(データベースへの問い合わせやメッセージの送信など、エージェントが起動できるアクション)、リソース(ファイルの内容など、参照可能なデータ)、プロンプト(再利用可能なリクエストのテンプレート)です。クライアントはまずサーバーに問い合わせて何が提供されているかを確認し、その後、具体的な引数を指定して特定のツールを呼び出せます。これは、当社のツールコーリングに関する記事で説明している仕組みに近いものです。

まさにこの点で、MCPの正確な範囲について情報源の間に見解の違いがあります。IBMとMicrosoftは、MCPがツールコーリングに取って代わるものではないという点で一致しています。ツールコーリングは、モデルが実際にアクションの実行を要求する、より基盤となる仕組みとして残り続けます。MCPが加えるのは、モデル提供元ごとに独自の呼び出し形式が課されていた状況に対して、モデル提供元に依存しない、ツールを記述し発見するための共通の方法です。同様に、MCPは従来のAPIに取って代わるものでもありません。Microsoftの.NETドキュメントには、MCPサーバーが「REST APIの上に抽象化レイヤーを提供できる」とあり、業務データをモデルに公開するために使われます。つまりMCPは、既存のAPIを不要にする技術ではなく、その上に重ねる共通のインターフェースなのです。

MCPサーバーは、応答する前に検索できるドキュメントベースを公開することもでき、これはRAGの原則、つまり信頼できる情報源をまず検索し、見つかった内容をもとに応答を生成するという考え方と直接重なる用途です。

Atakoでの具体例

Atakoのスタンダードプランでは、料金ページにおいて、インテグレーション、可観測性、BYOKなどと並んで、含まれる機能の一つとして「Atako MCP」が挙げられています。アカウント設定から発行するAPIキーは、他の用途とともに、外部のMCPクライアントをプラットフォームに接続する際に使用します。

具体的な実装の詳細、どのサーバーで、どのツールが公開されているかについては、現時点で公に文書化されていません。ツールの一覧や公開時期を推測するよりも、この点については事実に忠実であるほうが確実です。

よくある誤解

1つ目の誤りは、MCPをツールコーリングに取って代わる、まったく新しい仕組みだと考えることです。そうではありません。MCPはツールの記述と発見を標準化しますが、呼び出し自体は、モデルが生成する従来通りの関数呼び出しのままです。

2つ目の誤りは、「MCPサーバー」は必ず大規模なリモートマシンを指すと考えることです。公式ドキュメントは、ユーザーのコンピューター上で動作しローカルで通信するローカルサーバーと、ツール提供元によってホストされHTTP経由でアクセスするリモートサーバーを明確に区別しています。

3つ目の誤りは、MCPをそれ自体でセキュリティの保証だと混同することです。このプロトコルは、モデルがツールを発見し呼び出す方法を標準化するものであり、そのツールに付与される権限をモデルの代わりに決めるものではありません。信頼できるプラットフォームでは、この判断は、使用する接続プロトコルとは独立した、別のレイヤーとして扱われます。

4つ目の誤りは、エージェントに接続されるツールはすべて必ずMCPを経由すると考えることです。GitHubやSlackのようなインテグレーションを使うものも含め、多くのエージェントは、専用のMCPサーバーを経由せずに、従来のツールコーリングでアクションを呼び出しています。Atakoは、自社のMCPが公開するツールの詳細を公に文書化していません。MCPは、エージェントにツールを与えるための必須の手段ではなく、数ある接続方法の一つにすぎません。

さらに詳しく

MCPは、幅広いエコシステムに支えられた標準として比較的早く定着しました。公式ドキュメントでは、Claudeのようなアプリケーションや、Visual Studio Code、Cursorといったコードエディタが、対応するMCPクライアントとして挙げられています。このプロトコルに関連する概念についてさらに詳しく知りたい場合は、用語集全体をご覧ください。ツールコーリング、RAG、BYOKは、いずれもモデル側の接続や設定に関わる仕組みです。