話題のAIエージェントの活用に重要な MCP（Model Context Protocol）とは何か
先日、AIエージェントの開発に必要となる知識として「コンテキスト・エンジニアリング」について解説しました。今回は、MCP（Model Context Protocol）を取り上げます。AIエージェントの議論において頻繁に登場する技術仕様ですが、ここではできるだけ平易な解説を試みます。
今後のAIエージェントの基盤となるMCP
従来、LLM（大規模言語モデル）を用いたアプリケーションやシステムの開発においては、RAG（Retrieval Augmented Generation）と呼ばれる枠組みが広く利用され、外部のデータソースやサービス、さらに各種ツールとの接続が行われてきました。この際には主にAPIを介してシステム間を接続しており、多くのLLMがREST APIによるアクセスを提供しています。開発者はJSON形式でプロンプトを送信し、同じくJSON形式で応答を受け取ることで、さまざまな処理を実現してきました。AIエージェントも例外ではなく、REST APIを通じてWeb検索を行ったり、企業内部のサービスと通信したりする仕組みを備えています。
しかし今後、AIが自律的に振る舞うエージェントとして機能し、さまざまなシステムと連携しながら情報を収集・判断・実行していく社会においては、個別にAPIを接続する方法では開発コストが高く、拡張性や相互運用性にも限界が生じます。そこで必要とされるのが、オープンかつ標準的な接続方式です。その要請に応えるかたちで、2024年末にAnthropic社が「Model Context Protocol（MCP）」をオープン標準プロトコルとして発表し、大きな注目を集めました。MCPは今後のAIエージェントの基盤となりうる概念であり、その仕組みをここでは丁寧に整理したいと思います。
LLMの基本と課題
まずLLMの基本的な構造を振り返ります。入力としてプロンプトを与えると、出力として言語による回答が得られます。マルチモーダルLLMでは、入力や出力が画像や音声、動画、ファイルなど多様な形式に拡張されることも広く知られています。この基本構造には二つの課題があります。第一に、LLMの内部に含まれる知識には限界があるため、最新かつ広範な情報にアクセスできる仕組みが必要です。そのためRAGや外部APIの活用によって、企業が保有するドキュメントやデータ、他システムの情報を動的に利用しながら応答を生成する仕組みが構築されてきました。
第二の課題は、LLMが生成する出力があくまで「回答」にとどまってしまうことです。情報獲得の目的であれば十分ですが、現実世界で「行動」や「効果」をもたらすには不十分です。ここにAIエージェントの本質があります。AIが実世界に作用するためには、LLMが適切な「ツール」を呼び出し、外部に働きかけることができなければなりません。
MCPの基本構成と通信方式
アーキテクチャの観点から整理すると、AIエージェントは自律的に動作するAIアプリケーションであり、多様なシステムやデータベース、ドキュメントにアクセスします。その起点となるアプリケーションは「ホストアプリケーション」と呼ばれます。ホストアプリケーションはMCPクライアント・ライブラリを利用して内部にクライアントを生成し、MCPサーバーと接続します。MCPサーバーは一般公開されたサービスである場合もあれば、企業内に独自に構築される場合もあります。サーバー内部にはプロンプト、リソース、ツールといった機能が備わり、AIエージェントからアクセス可能な形で提供されます。
サーバープロセスはURLやポートを持ち、MCP仕様に基づいたREST（JSON形式）の接続ポイントを公開します。そこには利用可能なツールやリソース、プロンプトを一覧化し、ホストアプリケーションに知らせる「機能リスト（capabilities）」が含まれます。具体的には、データベースアクセス、コードリポジトリの参照、メールサーバーとの接続、ブラウザの自動操作など、多様な機能が提供されます。
MCPにおけるクライアントとサーバーの接続は、ネットワーク通信を通じて実現されます。特に重要なのは、MCPがAIエージェントと外部環境との相互作用を体系的に支える枠組みを提供しているという点です。例えば、HTTPを利用してインターネット経由で外部の企業が公開するMCPサーバーにアクセスすることも可能です。この際、交換されるメッセージはJSON-RPC形式であり、クライアントが自身をサーバーにアナウンスして通信を確立するプロトコルが存在します。また、サーバーがクライアントに非同期的に通知を送信する仕組みも備わっており、双方向かつ柔軟な通信が可能です。したがって、MCPは単なる接続方式ではなく、クライアントとサーバー間の相互作用を豊かに支える設計を有しているといえます。
MCPの用途例と意義
では、この仕組みは具体的に何を可能にするのでしょうか。仮に「さまざまなスケジュールの調整を行ってくれる」サービスを構築するとします。これは単に業務上の会議室予約にとどまらず、コーヒーを飲みに行く、朝食を共にする、あるいは家族とのディナーといった私的な時間の調整まで含み、広い意味で「誰かと会うための予定設定」や「自分のために時間を確保する行為」を支援する仕組みです。
この場合、必要となる要素はいくつかに分けられます。予定を登録するためには、カレンダーへの招待作成が不可欠です。そのためカレンダーAPIとの統合が求められ、自分の空き時間を確認できるだけでなく、権限が許される範囲で相手の予定を参照できることが望ましいでしょう。これらは「リソース」に該当します。また、利用可能なレストランやカフェといった飲食店情報もリソースの一部であり、これらがAIエージェントに文脈情報を与えることで、より適切な提案が可能になります。これは先日の「コンテキスト・エンジニアリング」の議論ともつながります。
一方で、予定を実際に作成する処理や、レストラン予約といった具体的な操作は「ツール」に分類されます。もしGoogleカレンダーなどのAPIを直接AIエージェント内部に組み込み、そこからツールやリソースを呼び出す設計とした場合、それはそのエージェント専用の仕組みにとどまり、他のAIエージェントやアプリケーションからは利用できません。
ここにMCPの意義があります。MCPの枠組みにおいてリソースやツールを定義し配置することで、それらは標準化された形で公開され、他のAIエージェントやアプリケーションからも利用可能になります。
MCPの３つの基本要素
MCPサーバーは、ここまで述べてきた、このリソースやツールに、プロンプトテンプレートを含めた３つを「プリミティブ（基本単位）」として公開し、クライアントが動的に利用できるように設計されています。
プロンプトテンプレート（Prompt Templates）
あらかじめ定義された入力テンプレートであり、推奨されるプロンプトの形式を提供します。リソース（Resources）
MCPサーバーが提供する読み取り専用のデータや文書であり、テキストファイルやデータベーススキーマ、ファイル内容などが含まれます。クライアントは必要に応じてそれらを取得し、文脈情報として利用します。ツール（Tools）
個別のアクションや関数を指します。たとえば天気情報サービスを呼び出して情報を取得したり、カレンダーサービスを呼び出してスケジュールをブロックしたり等のアクションを行います。ツールには名称、説明、入出力のスキーマが含まれ、MCPサーバーの能力リスト（capabilities）に記載されます。クライアントがツールを呼び出すと、サーバーがその機能を実行します。
すべてのMCPサーバーがこれら三要素を備えているわけではなく、多くはツール機能に特化しています。しかし重要なのは、AIエージェントが実行時にMCPサーバーへ問い合わせることで、利用可能な機能を動的に発見できるという点です。各サーバーは tools/list、resources/list、prompts/list といったカタログを公開しており、AIエージェントはその一覧をもとに新しい機能を即座に利用可能とします。この仕組みによって、追加のソースコード改修を行わなくとも、新しいサービスや機能に柔軟に対応できるのです。
ワークフローの例：プロンプト、リソース利用、ツール呼び出し
ここで、MCPを活用した実際のワークフローを想定してみましょう。ユーザーから「来週、家族とガチ中華レストランでディナーを食べたい」といったプロンプトが入力されたとします。通常であれば、LLMは「家族とは誰か」「どこのレストランを選ぶのか」といった前提情報を持たないため、十分な対応は困難です。しかしMCPを介することで、より適切な処理の流れを構築できます。
まずAIエージェント（ホストアプリケーション＝クライアント）は、MCPサーバーに対して「利用可能な機能は何か」と問い合わせを行います。サーバーはURLやプロパティファイルに基づき応答し、利用可能なリソース一覧を返します。このとき各リソースには説明文が付与されますが、開発者がサーバーを設計する際にはその説明を整備することが極めて重要となります。
次にAIエージェントはLLMを用いて判断を行います。ユーザー入力とリソース一覧を提示し、「この中で利用すべきリソースはどれか」と問いかけると、LLMは「リソース2（近隣の中華レストラン一覧）が有用である」といった応答を返します。そこでAIエージェントはMCPサーバーに対してリソース2の詳細を要求し、必要なパラメータを渡してデータを取得します。そのデータはテキストや構造化情報として次のプロンプトに添付され、改めてLLMに「ユーザーの要望と取得したリソースを踏まえ、何をすべきか」を問うことになります。この段階でLLMは、文脈を反映した具体的な行動指針を提示できるようになります。
ツールの利用についても同様の流れです。MCPサーバーはツールの名称、URL、パラメータスキーマなどを構造化データとして公開しているため、LLMはプロンプト操作を複雑に調整しなくても「このツールを呼び出し、このパラメータを渡すべきだ」という推奨を提示できます。ただし、ChatGPTやClaude、GeminiといったLLMが直接ユーザー環境で外部処理を実行するわけではありません。セキュリティ上の観点からも、それは避けられます。実際に処理を実行するのはAIエージェント（クライアント側）のコードであり、必要に応じてユーザーの確認を得た上で、外部に効果を及ぼす処理が行われます。
MCPサーバの拡張性
開発者は呼び出すツールの内部実装をすべて把握している必要はなく、MCPサーバーに登録されている機能であることが分かれば利用可能です。そして、ツールとして登録されていれば、MCPサーバーが別のMCPサーバーを呼び出すということも可能です。例えば、AIエージェントが「レストラン情報用MCPサーバーX」にアクセスし、その MCPサーバX が外部の「ガチ中華用MCPサーバY」をツールとして登録していたら、AIエージェントはYに直接アクセスする必要はありません。サーバーXが中継的にアクセスし、情報を返す構造を取れるのです。
このように、MCPの枠組みは拡張性と再利用性に優れています。結果として、プラグ適用性（pluggability）、発見可能性（discoverability）、構成可能性（composability）といった、ソフトウェア設計において極めて望ましい特性を備えることができます。
各種ソフトウェアで進む MCP 対応
現在では、MCPを利用する企業や開発者が世界中で増加しており、1万人以上のサーバービルダーが存在しています。当初はローカル環境中心の運用が主でしたが、現在ではクラウド上にMCPサーバーをホストする「リモートMCP」が台頭し始めています。これにより、Web上のMCPサーバーとAIツールを簡単に統合できる環境が整いつつあり、LLMとWebサービスとの新たな接続様式として、標準化の兆しを見せています。
同時に、MCPに関するコミュニティ活動も活発化しており、国際会議や各企業の参加などを通じて、認証や権限管理など、エンタープライズ向け要件への対応も進められています。
実際の各種ソフトウェアの対応状況に目を向けると、Anthropic社のClaudeや、Cursor、VS Code向けのエージェントであるClineなど、複数のホストアプリケーションがMCP対応を進めています。さらにSlack、Gmail、Notion、GitHub、Postgres、SQLite、ブラウザ、クラウドプラットフォームなど、多様なMCPサーバー実装が公式およびコミュニティによって展開されています。今後、業務システムの設計もAIエージェントとMCPサーバーを中心としたアーキテクチャに移行し、機能を柔軟に後付け接続できるような仕組みが主流となっていくと考えられます。
MCPの今後
今後MCPの世界で非常に大きな進展として注目されているのが、「レジストリAPI（Registry API）」の実装です。これは、大規模言語モデル（LLM）自身が、必要に応じて追加のMCPサーバーを自律的に検索し、それらを取り込むことを可能にする仕組みです。
このレジストリAPIが導入されることで、クライアント側（ホスト）であるAIエージェントが「これとこれとこれのMCPサーバーを使って処理を行う」といった予め決められたMCPサーバへのアクセスだけではなく、AIエージェント自身が状況に応じて適切なサーバーを探索し、動的に文脈を拡張するような、より期待されているエージェントとしての挙動（「agentic loop」と表現されたりします）が実現されることになります。
さらに、MCPの次なる重要な進化ポイントとして、「長時間実行タスク（long-running tasks）」への対応も挙げられます。これにより、モデルが一時的な応答にとどまらず、継続的な処理やタスク管理を行うことがより容易になります。
さらにもう一つの注目ポイントは「情報引き出し（elicitation）」の仕組みです。これは、MCPサーバーが必要な情報をユーザーに能動的に問い合わせる、つまり、追加の文脈や入力が不足している場合に、サーバー側からユーザーに確認を促すような対話的機構を取り入れることを意味します。
こうした新機能は、MCPの適用範囲を単なる統合プロトコルにとどめず、より動的かつ自律的なAIエージェントの基盤へと拡張するものであり、今後の発展に大きな期待が寄せられています。
MCPのビジョンと課題
ここまでの説明から理解できるように、MCPは単なる「API型のシステム間通信プロトコル」にとどまるものではありません。その先には、より広いビジョンがあります。すなわち、多様なAIエージェントが自律的に連携し、組織内部の業務プロセスにとどまらず、社会の多様なシステムと接続しながら価値を柔軟に実現していく未来像です。MCPはそのためのゲートウェイとして機能すると捉えられており、この観点を踏まえるとその重要性はいっそう明確になります。
もっとも、現時点でMCP関連の取り組みがすべて実運用レベルに到達しているわけではありません。各種ツールの安定性やセキュリティ確保といった観点では依然として検討課題が残されており、MCPそのものも規格として進化の途上にあります。そのため、標準化や普及のプロセスには一定の時間を要することが予想されます。それでも、MCPが共通インターフェースとして複数の企業や開発者コミュニティから支持を得はじめているのは確かであり、ツール接続の仕様を統一することによってAIエージェントを中心とした新しいエコシステムの形成が加速していくことが期待されます。
おまけ：エージェント間通信について （A2A）
ユーザーの目的によっては、単一のAIエージェントとMCPサーバ群の組み合わせだけでは十分でない場合があります。例えば旅行予約の場面を考えると、「フライト予約に特化したエージェント」と「ホテル予約に特化したエージェント」が既に存在しているとき、「旅行予約エージェント」が上位のエージェントとしてこれらを統合的に呼び出し、最終的な目的を達成することが望ましい場合があります。これはすなわち、AIエージェントのオーケストレーションの問題であり、このケースでは旅行予約エージェントがフライトエージェントやホテルエージェントをエージェント間通信（agent-to-agent call）によって利用する必要があります。
こうした仕組みを体系的に実現するためにGoogleが開発を進めているのが、エージェント間プロトコル（Agent2Agent Protocol = A2A）です。A2Aは、動的に連携する複数のエージェントから成るエコシステムを支える標準として設計され、パートナー企業や研究者と協力しながら整備が進められています。具体的には、エージェント間での能力の発見、タスクの割り当てと進捗管理、通信形式の標準化、文脈や結果の共有方法といった要素が定義されます。MCPと同様に、A2Aも今後注目すべき枠組みであり、エージェントの発展を支える重要な基盤の一つになると考えられます。
