話題のAIエージェントの活用に重要な MCP（Model Context Protocol） とは何か 2 0 2 5 / 0 9 / 0 1 博 報 堂 Ｄ Ｙ ホ ー ル デ ィ ン グ ス 執 行 役 員 ・ C A I O 森 正 弥 

先日、AIエージェントの開発に必要となる知識として「コンテキスト・エンジニアリ ング」について解説しました。今回は、MCP（Model Context Protocol）を取り上 げます。AIエージェントの議論において頻繁に登場する技術仕様ですが、ここではで きるだけ平易な解説を試みます。 話題のAIエージェントの活用に重要な MCP（Model Context Protocol） とは何か 

LLMの基本構造と課題 まずLLMの基本的な構造を振り返ります。入力としてプロンプトを与 えると、出力として言語による回答が得られます。マルチモーダル LLMでは、入力や出力が画像や音声、動画、ファイルなど多様な形式 に拡張されることも広く知られています。 この基本構造には二つの課題があります。 知識の限界 LLMの内部に含まれる知識には限界があるため、最新かつ広範な情 報にアクセスできる仕組みが必要です。そのためRAGや外部APIの 活用によって、企業が保有するドキュメントやデータ、他システム の情報を動的に利用しながら応答を生成する仕組みが構築されてき ました。 行動の制約 LLMが生成する出力があくまで「回答」にとどまってしまうことで す。情報獲得の目的であれば十分ですが、現実世界で「行動」や「 効果」をもたらすには不十分です。ここにAIエージェントの本質が あります。AIが実世界に作用するためには、LLMが適切な「ツール 」を呼び出し、外部に働きかけることができなければなりません。 

LLM活用の拡張と新しい標準プロトコルの必要性 従来、LLM（大規模言語モデル）を用いたアプリケーションやシステムの開発においては、RAG（Retrieval Augmented Generation）と呼 ばれる枠組みが広く利用され、外部のデータソースやサービス、さらに各種ツールとの接続が行われてきました。 この際には主にAPIを介してシステム間を接続しており、多くのLLMがREST APIによるアクセスを提供しています。開発者はJSON形式でプ ロンプトを送信し、同じくJSON形式で応答を受け取ることで、さまざまな処理を実現してきました。 AIエージェントも例外ではなく、REST APIを通じてWeb検索を行ったり、企業内部のサービスと通信したりする仕組みを備えています。 個別API接続の限界 今後、AIが自律的に振る舞うエージェントとして機能し、さまざまなシステムと連携しながら情報 を収集・判断・実行していく社会においては、個別にAPIを接続する方法では開発コストが高く、 拡張性や相互運用性にも限界が生じます。 オープン標準の登場 そこで必要とされるのが、オープンかつ標準的な接続方式です。その要請に応えるかたちで、2024 年末にAnthropic社が「Model Context Protocol（MCP）」をオープン標準プロトコルとして発表 し、大きな注目を集めました。 

MCPのアーキテクチャ アーキテクチャの観点から整理すると、AIエージェントは自律的に動作するAIアプリケーションであり、多様なシステムやデータベース、ドキ ュメントにアクセスします。その起点となるアプリケーションは「ホストアプリケーション」と呼ばれます。 ホストアプリケーションはMCPクライアント・ライブラリを利用して内部にクライアントを生成し、MCPサーバーと接続します。MCPサーバ ーは一般公開されたサービスである場合もあれば、企業内に独自に構築される場合もあります。 MCPの通信方式 MCPにおけるクライアントとサーバーの接続は、ネットワーク通信を通じて実現されます。特に重要なのは、MCPがAIエージェントと外部環 境との相互作用を体系的に支える枠組みを提供しているという点です。 例えば、HTTPを利用してインターネット経由で外部の企業が公開するMCPサーバーにアクセスすることも可能です。この際、交換されるメッ セージはJSON-RPC形式であり、クライアントが自身をサーバーにアナウンスして通信を確立するプロトコルが存在します。 また、サーバーがクライアントに非同期的に通知を送信する仕組みも備わっており、双方向かつ柔軟な通信が可能です。したがって、MCPは 単なる接続方式ではなく、クライアントとサーバー間の相互作用を豊かに支える設計を有しているといえます。 

MCPの三つの基本要素 MCPの枠組みにおいてリソースやツールを定義し配置することで、それらは標準化された形で公開 され、他のAIエージェントやアプリケーションからも利用可能になります。 MCPサーバーはプロンプトテンプレートを含めたこれらを「プリミティブ（基本単位）」として公 開し、クライアントが動的に利用できるように設計されています。 プロンプトテンプレート （Prompt Templates） あらかじめ定義された入力テンプレートで あり、推奨されるプロンプトの形式を提供 します。 リソース（Resources） MCPサーバーが提供する読み取り専用のデ ータや文書であり、テキストファイルやデー タベーススキーマ、ファイル内容等が含まれ ます。クライアントは必要に応じてそれらを 取得し、文脈情報として利用します。 ツール（Tools） 個別のアクションや関数を指します。たとえば天気情 報サービスを呼び出して情報を取得したり、カレンダ ーサービスを呼び出してスケジュールをブロックした り等のアクションを行います。ツールには名称、説明 、入出力のスキーマが含まれ、MCPサーバーの能力リ スト（capabilities）に記載されます。クライアントが ツールを呼び出すと、サーバーがその機能を実行しま す。 MCPの基本構成と通信方式 

MCPサーバの拡張性 すべてのMCPサーバーがこれら三要素を備えているわけではなく、多くはツール機能 に特化しています。しかし重要なのは、AIエージェントが実行時にMCPサーバーへ問 い合わせることで、利用可能な機能を動的に発見できるという点です。 各サーバーは tools/list、resources/list、prompts/list といったカタログを公開し ており、AIエージェントはその一覧をもとに新しい機能を即座に利用可能とします。 この仕組みによって、追加のソースコード改修を行わなくとも、新しいサービスや機 能に柔軟に対応できるのです。 

MCPの具体的な活用例 では、この仕組みは具体的に何を可能にするのでしょうか。仮に「さまざまなスケジ ュールの調整を行ってくれる」サービスを構築するとします。これは単に業務上の会 議室予約にとどまらず、コーヒーを飲みに行く、朝食を共にする、あるいは家族との ディナーといった私的な時間の調整まで含み、広い意味で「誰かと会うための予定設 定」や「自分のために時間を確保する行為」を支援する仕組みです。 カレンダー連携 予定を登録するためには、カレンダーへ の招待作成が不可欠です。そのためカレ ンダーAPIとの統合が求められ、自分の空 き時間を確認できるだけでなく、権限が 許される範囲で相手の予定を参照できる ことが望ましいでしょう。これらは「リ ソース」に該当します。 飲食店情報 また、利用可能なレストランやカフェと いった飲食店情報もリソースの一部であ り、これらがAIエージェントに文脈情報 を与えることで、より適切な提案が可能 になります。 予約処理 予定を実際に作成する処理や、レストラン予約といった具体的な操作は「ツール」に分 類されます。もしGoogleカレンダーなどのAPIを直接AIエージェント内部に組み込んで 呼び出す設計とした場合、それはそのエージェント専用の仕組みとなり、他のAIエージ ェントやアプリケーションからは利用できません。 スケジュール調整に必要な要素 

MCPを活用したワークフロー例 ユーザー入力 ユーザーから「来週、家族とガチ中華レストランでディナーを食べ たい」といったプロンプトが入力されたとします。通常であれば、 LLMは「家族とは誰か」「どこのレストランを選ぶのか」といった 前提情報を持たないため、十分な対応は困難です。 機能の問い合わせ まずAIエージェント（ホストアプリケーション＝クライアント）は 、MCPサーバーに対して「利用可能な機能は何か」と問い合わせを 行います。サーバーはURLやプロパティファイルに基づき応答し、 利用可能なリソース一覧を返します。 リソース選択 次にAIエージェントはLLMを用いて判断を行います。ユーザー入力 とリソース一覧を提示し、「この中で利用すべきリソースはどれか 」と問いかけると、LLMは「リソース2（近隣の中華レストラン一 覧）が有用である」といった応答を返します。 データ取得と処理 そこでAIエージェントはMCPサーバーに対してリソース2の詳細を 要求し、必要なパラメータを渡してデータを取得します。そのデー タはテキストや構造化情報として次のプロンプトに添付され、改め て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 対応 実際の対応状況に目を向けると、Anthropic社のClaudeや、Cursor、VS Code向けの エージェントであるClineなど、複数のホストアプリケーションがMCP対応を進めて います。 さらにSlack、Gmail、Notion、GitHub、Postgres、SQLite、ブラウザ、クラウドプ ラットフォームなど、多様なMCPサーバー実装が公式およびコミュニティによって展 開されています。 今後、業務システムの設計もAIエージェントとMCPサーバーを中心としたアーキテク チャに移行し、機能を柔軟に後付け接続できるような仕組みが主流となっていくと考 えられます。 現在では、MCPを利用する企業や開発者が世界中で増加しており、1万人以上のサー バービルダーが存在しています。当初はローカル環境中心の運用が主でしたが、現在 ではクラウド上にMCPサーバーをホストする「リモートMCP」が台頭し始めていま す。これにより、Web上のMCPサーバーとAIツールを簡単に統合できる環境が整いつ つあり、LLMとWebサービスとの新たな接続様式として、標準化の兆しを見せていま す。 同時に、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サーバ群の組み合わせだけ では十分でない場合があります。例えば旅行予約の場面を考えると、「フライト予約 に特化したエージェント」と「ホテル予約に特化したエージェント」が既に存在して いるとき、「旅行予約エージェント」が上位のエージェントとしてこれらを統合的に 呼び出し、最終的な目的を達成することが望ましい場合があります。 こうした仕組みを体系的に実現するためにGoogleが開発を進めているのが、エージェ ント間プロトコル（Agent2Agent Protocol = A2A）です。A2Aは、動的に連携する複 数のエージェントから成るエコシステムを支える標準として設計され、パートナー企 業や研究者と協力しながら整備が進められています。具体的には、エージェント間で の能力の発見、タスクの割り当てと進捗管理、通信形式の標準化、文脈や結果の共有 方法といった要素が定義されます。MCPと同様に、A2Aも今後注目すべき枠組みであ り、エージェントの発展を支える重要な基盤の一つになると考えられます。 

筆者紹介 博報堂ＤＹグループが目指す「人間中心のAI」の進化 アクセンチュア、楽天を経て デロイト トーマツにて先端技術・AI領域をリード（APACリード） 日本ディープラーニング協会 顧問 東京大学 共創プラットフォーム開発 顧問 慶應義塾大学 xDignity センター アドバイザリーボード 森 正弥 （もり まさや） 博報堂ＤＹ ホールディングス 執行役員 CAIO（Chief AI Officer） / Human-Centered AI Institute 代表 

HCAI （人間中心のAI）コンセプトムービー：「人間を極める。AIと」 • AIは単なるツールをこえていく。AIを使いこなすことで企業のパフォーマンスを高めるだけ でなく、人の持つ創造性を解き放っていく https://www.hakuhodody- holdings.co.jp/topics/2025/04/5431.html https://www.youtube.com/watch?v=ELtSqhqPsEo