MCP（モデルコンテキストプロトコル）の現状

Q: 1. モデルコンテキストプロトコル (MCP) とは何ですか?

モデル コンテキスト プロトコルは、AI モデルをさまざまなデータ ソースやツールに接続するための構造化された双方向の方法を提供し、より関連性の高い情報に基づいた応答を生成できるようにするオープン スタンダードです。

Q: 2. MCP は他のエージェント プロトコルと比べてどうですか?

ほとんどのエージェント プロトコルは、エージェント同士の通信に重点を置いたエージェント間プロトコルと、構造化されたコンテキストを LLM に提供することに重点を置いた MCP などのコンテキスト指向プロトコルの 2 種類に分類できます。

Elasticsearchは、業界をリードする生成AIツールやプロバイダーとネイティブに統合されています。RAG応用編やElasticベクトルデータベースで本番環境対応のアプリを構築する方法についてのウェビナーをご覧ください。

ユースケースに最適な検索ソリューションを構築するには、無料のクラウドトライアルを始めるか、ローカルマシンでElasticを試してみてください。

最近、サンフランシスコで開催された MCP 開発者サミットに出席しましたが、モデルコンテキストプロトコル (MCP) が急速に AI エージェントとコンテキストリッチな AI アプリケーションの基礎となる構成要素になりつつあることは明らかでした。Elastic では、 Agent Builderから MCP サーバーを直接公開することでこの方向に傾き、Elasticsearch をあらゆる MCP 互換エージェントにとって第一級のコンテキストおよびツールプロバイダーにしています。この記事では、イベントからの主な最新情報、新しいユースケース、MCP の今後の展望、Agent Builder を使用して MCP 経由でエージェントが Elasticsearch を利用できるようにする方法について説明します。

モデルコンテキストプロトコル (MCP) とは何ですか?

ご存じない方のために説明すると、モデルコンテキストプロトコルは、AI モデルをさまざまなデータソースやツールに接続するための構造化された双方向の方法を提供し、より関連性の高い情報に基づいた応答を生成できるようにするオープンスタンダードです。一般的に「 AI アプリケーション用の USB-C ポート」と呼ばれています。

双方向の性質を強調したアーキテクチャ図を以下に示します。

これは AI 実践者にとって大きな変化です。AI アプリケーションを拡張する際の主な課題の 1 つは、新しいデータソースごとにカスタム統合を構築する必要があることです。MCP は、モデルにコンテキストを管理および提供するための持続可能で再利用可能なアーキテクチャを提供します。モデルやサーバーに依存せず、完全にオープンソースです。

MCP は、アプリケーション間の統合を標準化することを目指す一連の API 仕様の最新版です。これまで、RESTful サービスには OpenAPI、データクエリには GraphQL、マイクロサービス通信には gRPC を使用していました。MCP は、これらの古い仕様の構造化された厳密さを共有するだけでなく、それを生成 AI 設定に取り入れることで、カスタムコネクタなしでエージェントをさまざまなシステムに簡単に接続できるようになります。多くの点で、MCP は HTTP が Web に対して行ったことと同じことを AI エージェントに対して行うことを目指しています。HTTP がブラウザと Web サイト間の通信を標準化したのと同様に、MCP は AI エージェントが周囲のデータの世界と対話する方法を標準化することを目指しています。

MCPと他のエージェントプロトコルの比較

エージェントプロトコルの状況は急速に拡大しており、エージェントの相互作用方法を定義するために 12 を超える新しい標準が競合しています。LlamaIndex のLaurie Voss氏は、ほとんどのプロトコルを 2 つのタイプに分類できると説明しています。エージェント同士の対話に重点を置くエージェント間プロトコルと、構造化されたコンテキストを LLM に提供することに重点を置く MCP などのコンテキスト指向プロトコルです。

Google のA2A (Agent to Agent)、Cisco と IBM のACP (Agent Communication Protocol)、 Agoraなどの他の一般的なプロトコルは、エージェント間のネゴシエーション、連合の構築、さらには分散型 ID システムを可能にすることを目的としています。MCP は、エージェントがツールやデータにアクセスする方法に焦点を当てており、必ずしもエージェント同士が通信する方法に焦点を当てているわけではないため、もう少し実用的なアプローチを採用しています (ただし、MCP は将来的にさまざまな方法でそれを可能にすることもできます)。

現在、MCP が他と一線を画しているのは、その牽引力と勢いです。フロントエンドフレームワークの初期の React と同様に、MCP はニッチな問題から始まり、現在では実際に最も採用され、拡張可能なエージェントプロトコルの 1 つとなっています。

サミットのまとめ: MCP の優先事項の進化

サミットには、Anthropic、Okta、OpenAI、AWS、GitHub などの貢献者による講演者が登壇しました。講演では、コアプロトコルの強化から実際の実装まで幅広い話題が取り上げられ、短期的および長期的な優先事項が概説されました。これらの講演は、初期の実験や単純なツール呼び出しから、MCP を基盤として使用した信頼性が高く、スケーラブルでモジュール化された AI システムの構築への移行を反映していました。

何人かの講演者は、MCP が単なるプロトコル配管にとどまらず、AI ネイティブ Web の基盤となる将来を示唆しました。JavaScript によってユーザーが Web ページをクリックして操作できるのと同じように、MCP によってエージェントが私たちに代わって同じアクションを実行できるようになります。たとえば、電子商取引では、ユーザーが買い物をするために手動で Web サイトに移動するのではなく、エージェントにログインして特定の製品を見つけ、カートに追加してチェックアウトするように指示するだけで済みます。

これは単なる憶測や誇大宣伝ではありません。PayPal はサミットで、まさにこのエージェントによるコマース体験を可能にする新しいエージェントツールキットと MCP サーバーを披露しました。MCP はツールやデータソースへの安全で信頼性の高いアクセスを提供するため、エージェントは Web を読み取るだけでなく、それに基づいて行動できるようになります。現在、MCP はすでに大きな勢いを持つ強力な標準であり、将来的には Web 全体で AI を活用したユーザーインタラクションの標準になる可能性があります。

MCPプロジェクトの最新情報: トランスポート、抽出、構造化ツール

MCP のコア貢献者であるJerome Swannack 氏が、過去 6 か月間のプロトコル仕様の更新をいくつか共有しました。これらの変更の主な目的は次のとおりです。

ストリーミング可能なHTTPを追加してリモートMCPを有効にする
抽出とツール出力スキーマの追加により、より豊富なエージェントインタラクションモデルを可能にする

MCP はオープンソースであるため、開発者は Streamable HTTP などの変更を実装できる状態になっています。抽出およびツール出力スキーマは現在リリースされておらず、ドラフト段階にあり、進化する可能性があります。

ストリーミング可能な HTTP ( 2025 年 3 月 26 日リリース) :ストリーミング可能な HTTP が新しいトランスポートメカニズムとして導入されたことは、大きなインパクトのある技術更新でした。これにより、サーバー送信イベント (SSE) が、チャンク転送エンコーディングと単一の HTTP 接続を介したプログレッシブメッセージ配信をサポートする、よりスケーラブルな双方向モデルに置き換えられます。これにより、AWS Lambda などのクラウドインフラストラクチャに MCP サーバーを展開し、長時間の接続やポーリングを必要とせずにエンタープライズネットワークの制約をサポートできるようになります。

Elicitation ( 2025 年 6 月 18 日リリース) : Elicitation を使用すると、サーバーはクライアントからのコンテキストの構造化方法を指定するスキーマを定義できます。基本的に、サーバーは必要なものと期待する入力の種類を記述できます。これにはいくつかの意味があります。サーバービルダーにとっては、より複雑なエージェントのインタラクションを構築できます。クライアントビルダーは、これらのスキーマに適応する動的な UI を実装できます。ただし、ユーザーから機密情報や個人を特定できる情報を抽出するために、誘導法を使用するべきではありません。特に MCP が成熟するにつれて、開発者はベストプラクティスに従って、誘導プロンプトが安全かつ適切な状態を保つようにする必要があります。これは、この投稿の後半で説明する、より広範なセキュリティ上の懸念に関係しています。

ツール出力スキーマ( 2025 年 6 月 18 日リリース) :このコンセプトにより、クライアントと LLM はツール出力の形状を事前に知ることができます。ツール出力スキーマを使用すると、開発者はツールが返すことが予想される内容を記述できます。これらのスキーマは、コンテキストウィンドウの非効率的な使用という、直接ツール呼び出しの主な制限の 1 つに対処します。コンテキストウィンドウは、LLM を操作するときに最も重要なリソースの 1 つと考えられており、ツールを直接呼び出すと、LLM のコンテキストに完全にプッシュされる生のコンテンツが返されます。ツール出力スキーマを使用すると、MCP サーバーが構造化データを提供できるようになるため、トークンとコンテキストウィンドウをより有効に活用できるようになります。ここでは、ツール全般に関するベストプラクティスをいくつか紹介します。

これらの新しいアップデートと今後の追加により、MCP はよりモジュール化され、型付けされた、実稼働対応のエージェントプロトコルになります。

あまり使われていない強力な機能：サンプリングとルート

MCP 仕様では目新しいものではありませんが、基調講演ではサンプリングとルートの両方が強調されました。これら 2 つのプリミティブは現在見過ごされ、十分に調査されていませんが、エージェント間のより豊かで安全なインタラクションに大きく貢献する可能性があります。

サンプリング - サーバーはクライアントからの補完を要求できます。サンプリングにより、MCP サーバーはクライアント側の LLM から補完を要求できます。これにより、プロトコルの双方向性が強化され、サーバーはリクエストに応答するだけでなく、クライアントのモデルにプロンプトを出して応答を生成するように要求できるようになります。これにより、クライアントはコスト、セキュリティ、MCP サーバーが使用するモデルを完全に制御できます。したがって、事前構成されたモデルを備えた外部 MCP サーバーを使用する場合、サーバーはクライアントにすでに接続されているモデルを要求するだけでよいため、独自の API キーを提供したり、そのモデルに対する独自のサブスクリプションを構成したりする必要はありません。これにより、より複雑でインタラクティブなエージェントの動作が可能になります。

ルート - リソースへのスコープアクセス:ルートは、クライアントが関連するリソースと焦点を当てるワークスペースについてサーバーに通知する方法を提供するために設計されました。これは、サーバーが動作する範囲を設定するのに強力です。ルートは「情報提供のみを目的としており、厳密に強制するものではない」ことに注意することが重要です。つまり、MCP サーバーまたはエージェントの権限やアクセス許可を定義しないということです。つまり、サーバーまたはエージェントが特定のツールを実行したり書き込みアクションを実行したりするのを防ぐために、ルートだけに頼ることはできません。ルートの場合も、ユーザー承認のメカニズムを使用して、権限はクライアント側で処理する必要があります。また、開発者は、ルートによって設定された境界を尊重し、ベストプラクティスを使用するように設計されたサーバーの使用にも注意する必要があります。

エージェントの認証: OAuth 2.1 と保護されたメタデータ

このセクションでは、安全でないフローを排除し、ベストプラクティスを統合した OAuth 2.0 の最新バージョンである OAuth 2.1 に焦点を当てます。

OAuth サポートは、特にセキュリティとスケーラビリティが、MCP がエージェントをツールに接続するための標準となることを妨げる大きな障害であると考えられているため、非常に期待されていたトピックでした。Aaron Parecki 氏(Okta の OAuth 2.1 編集者兼 ID 標準専門家) は、サーバー開発者の複雑さのほとんどを軽減する、クリーンかつスケーラブルな OAuth フローを MCP がどのように採用できるかについて説明しました。公式の OAuth 2.1 認証仕様は、 2025 年 6 月 18 日の最新プロトコル改訂版で最近公開されました。

この実装では、OAuth の責任を MCP クライアントとサーバーの間で分割できます。認証フローの大部分は MCP クライアントによって開始および処理され、最後にサーバーが関与するのは安全なトークンの受信と検証のみです。この分割により、開発者がすべての接続を構成する必要なく、多くのツール間で認証を行うという重要なスケーリングの問題が解決され、MCP サーバー開発者が OAuth の専門家になる必要がなくなります。

講演の2つの重要なハイライト:

保護されたリソースメタデータ: MCP サーバーは、目的、エンドポイント、認証方法を記述した JSON ファイルを公開できます。これにより、クライアントはサーバー URL だけで OAuth フローを開始できるようになり、接続プロセスが簡素化されます。詳細: MCP で OAuth を修正しましょう
IDP と SSO のサポート: 企業は ID プロバイダーを統合してアクセスを集中管理できます。これは、ユーザーエクスペリエンスとセキュリティの両方にとってメリットとなります。ユーザーは 10 個の異なる同意画面をクリックする必要がなくなり、セキュリティチームは各接続を監視できるようになります。

OAuth ロジックをクライアントにプッシュし、サーバーからのメタデータに依存することで、MCP エコシステムは大きなボトルネックを回避します。これにより、MCP は、今日の運用環境で最新の API が保護される方法とより密接に連携するようになります。

追加の参考資料: OAuth 2 Simplified 。

コンポーザブルエコシステムにおけるセキュリティの課題

新たな開発には新たな攻撃対象領域も伴います。Cisco の Arjun Sambamoorthy 氏は、MCP 環境における主な脅威をいくつか挙げています。

脅威	説明	修復とベストプラクティス
迅速な注射とツールの中毒	LLM システムのコンテキストまたはツールの説明内に悪意のあるプロンプトを挿入し、LLM がファイルの読み取りやデータの漏洩などの意図しないアクションを実行するようにする方法。	MCP Scan などのツールを使用して、ツールのメタデータのチェックを実行します。説明とパラメータをプロンプトに含める前に検証します。最後に、リスクの高いツールに対してユーザー承認を実装することを検討してください。詳細については、表の下の追加の読書リストにある OWASP プロンプトインジェクションガイドを参照してください。
サンプリング攻撃	MCP のコンテキストでは、サンプリングにより、MCP サーバーが LLM に対してプロンプトインジェクション攻撃を実行できるようになります。	信頼できないサーバーのサンプリングを無効にし、サンプリング要求に人間による承認を追加することを検討してください。
悪意のあるMCPサーバー	現在の MCP サーバーのコレクションでは、安全性を確保するために各サーバーを検査するのは困難です。不正なサーバーは密かにデータを収集し、悪意のある人物に公開する可能性があります。	信頼できるレジストリまたは内部リストからのみ MCP サーバーに接続します。サンドボックス化されたコンテナ内でサードパーティのサーバーを実行します。
悪意のあるMCPインストールツール	コマンドラインインストーラーとスクリプトは、MCP サーバーまたはツールを迅速に実装するのに便利ですが、検証されていない侵害されたコードをインストールしてしまう可能性があります。	サンドボックス環境にインストールし、パッケージ署名を検証します。検証されていないソースからの自動更新は行わないでください。

この問題にさらに対抗するために、Arjun は、信頼できる MCP レジストリを使用してすべての検証を処理すること (これは最重要トピックです。詳細については、以下の読書リストの上位 2 項目を参照してください) と、このセキュリティチェックリストの使用を提案しています。

追加の参考資料:

次はレジストリ、ガバナンス、エコシステム

集中型の MCP レジストリが開発中であり、サミットで最も頻繁に議論されたトピックの 1 つでした。現在のサーバーエコシステムは、断片化、信頼性と発見可能性の低さに悩まされています。特にメタデータが不完全であったり偽装されたりする可能性がある分散型エコシステムでは、開発者が MCP サーバーを見つけ、その動作を検証し、安全にインストールすることは困難です。

集中型レジストリは、信頼できる真実のソースとして機能し、発見可能性を向上させ、サーバーメタデータの整合性を確保し、悪意のあるツールをインストールするリスクを軽減することで、これらの問題点に直接対処します。

MCP レジストリの目標は次のとおりです。

サーバーのメタデータ（サーバーが何をするか、どのように認証するか、インストールして呼び出すか）に関する唯一の真実の情報源を提供します。
不完全なサードパーティのレジストリと断片化を排除して、サーバーを登録するときに、インターネット上の他のすべてのレジストリを更新する必要がなくなります。
CLI ツールと、前述のメタデータを含む server.json ファイルを含むサーバー登録フローを提供します。

より広範な期待は、信頼できるレジストリがエコシステムを安全に拡張し、開発者が自信を持って新しいツールを構築して共有できるようにすることです。

ガバナンスは、Anthropic にとってもう一つの最重要課題でした。MCP はオープンかつコミュニティ主導であり続けるべきだと明言しましたが、ガバナンスモデルの拡張はまだ進行中です。彼らは現在、その分野での支援を求めており、オープンソースプロトコルのガバナンスの経験がある方は誰でも連絡を取るよう呼びかけています。これは私が言及したかったもう一つの話題につながります。イベント全体を通じて、講演者は、エコシステムはその内部の開発者の貢献によってのみ成長できると強調しました。MCP を新しい Web 標準にして、他の一般的なエージェントプロトコルと差別化するために、集中的な取り組みが必要です。

現実世界におけるMCP：ケーススタディとデモ

いくつかの組織は、MCP がすでに実際のアプリケーションでどのように使用されているかを共有しました。

PayPal - エージェンティックコマース向け MCP サーバー: PayPal は、ユーザーのショッピング体験を根本的に変えることができる新しいエージェントツールキットと MCP サーバーを展示しました。ユーザーは、ソーシャルメディアで商品を探したり、価格を比較したり、チェックアウトしたりする代わりに、PayPal MCP サーバーに接続してそれらのすべてのアクションを処理するエージェントとチャットできます。
EpicAI.pro - Jarvis: MCP の開発により、現実世界の Jarvis タイプのアシスタントの実現にますます近づいています。アイアンマン映画をご存じない方のために説明すると、Jarvis は自然言語を使用し、マルチモーダル入力に応答し、応答時に遅延がなく、ユーザーのニーズを積極的に予測し、統合を自動的に管理し、デバイスと場所の間でコンテキストを切り替えることができる AI アシスタントです。Jarvis を物理的なロボットアシスタントとして想像すると、MCP は Jarvis に「手」、つまり複雑なタスクを処理する能力を与えます。
Postman - MCP サーバージェネレーター: API リクエスト用のショッピングカートエクスペリエンスを提供します。さまざまな API リクエストを選択してバスケットに入れ、バスケット全体を MCP サーバーとしてダウンロードできます。
Bloomberg - Bloomberg は、エンタープライズ GenAI 開発における主要なボトルネックを解決しました。約 10,000 人のエンジニアを抱える同社では、チーム間でツールとエージェントを統合するための標準化された方法が必要でした。MCP を使用することで、社内ツールをモジュール式のリモートファーストコンポーネントに変換し、エージェントが統合インターフェースで簡単に呼び出すことができるようになりました。これにより、エンジニアは組織全体にツールを提供できるようになり、AI チームはカスタム統合ではなくエージェントの構築に集中できるようになりました。Bloomberg は現在、MCP エコシステムとの完全な相互運用性を実現する、スケーラブルで安全なエージェントワークフローをサポートしています。ブルームバーグは公開リソースへのリンクを一切提供していないが、これはサミットで彼らが公開した内容である。
Block – Block は MCP を使用して、従業員がエンジニアリング、営業、マーケティングなどのタスクを自動化できるようにする社内 AI エージェントであるGooseを強化しています。同社は、Git、Snowflake、Jira、Google Workspace などのツール用に 60 台以上の MCP サーバーを構築し、日常的に使用するシステムとの自然言語によるやり取りを可能にしました。Block 社の従業員は現在、Goose を使用してデータのクエリ、不正行為の検出、インシデントの管理、内部プロセスのナビゲートなどを行っており、これらはすべてコードを書かずに実行できます。MCP は、Block がわずか 2 か月で多くの職務にわたって AI の導入を拡大できるよう支援しました。
AWS - AWS MCP サーバー: AWS は、サイコロを振る動作をシミュレートし、過去のロールを追跡し、Streamable HTTP を使用して結果を返す、楽しいダンジョンズアンドドラゴンズをテーマにした MCP サーバーを発表しました。この軽量な例では、Lambda や Fargate などの AWS ツールとインフラストラクチャを使用して MCP サーバーを簡単に構築およびデプロイできることが強調されました。また、MCP サーバーと対話するマルチモーダルエージェントを構築するためのオープンソースツールキットであるStrands SDKも紹介されました。

Elastic Agent Builder での MCP サポート

Elastic Agent Builder を使用すると、今すぐ MCP の実験を始めることができます。これは、データ上に直接エージェントを構築する最も簡単な方法です。Agent Builder を使用すると、Elasticsearch を利用したツールを MCP 対応エージェントに公開できます。また、次のような強力な組み込みツールがすでに付属しています。

platform.core.search - 完全なElasticsearchクエリDSLを使用して検索を実行します
platform.core.list_indices - Elasticsearch 内で利用可能なすべてのインデックスを一覧表示します (エージェントがどのようなデータが存在するかを検出できるようにします)
platform.core.get_index_mapping - 特定のインデックスのフィールドマッピングを取得します (エージェントがデータの形状と種類を理解するのに役立ちます)
platform.core.get_document_by_id - IDで特定のドキュメントを取得します（正確な検索のため）

これらのツールを使用するだけで、信頼性の高い AI エージェントを構築するための中核となるエンタープライズレベルの検索と関連性をエージェントに装備できます。

Agent Builder をさらに強力にするのは、アプリケーションのニーズに合わせて独自のカスタムツールを定義し、公開できる機能です。これは、毎回そのロジックを再検出することなく、エージェントが特定のインデックスに対して特定のタイプの検索を実行するようにしたい、意見が強いワークフローや繰り返し可能なワークフローに特に役立ちます。同じ結論に到達するために計画と推論にトークンを費やす代わりに、その意図をツールに直接エンコードすることで、エージェントの速度、信頼性、コスト効率を高めることができます。

Agent Builder UI 内で、ES|QL を使用するカスタムツール定義の例を次に示します。

カスタムツールを定義したら、 Manage MCPのドロップダウンをクリックして MCP サーバー URL をコピーすることで、MCP を使用してカスタムツール (および組み込みのネイティブツール) を公開できます。

これで、この MCP エンドポイントを、MCP を使用する任意のクライアントにインポートして Agent Builder に接続し、利用可能なすべてのツールにアクセスできるようになります。詳細については、 Agent Builderの紹介をお読みください。

まとめ

MCP Dev Summit では、MCP がこれらの AI エージェント同士、そして周囲のデータの世界と対話する方法を形作っていることが明らかになりました。エージェントをエンタープライズデータに接続する場合でも、完全に自律的なエージェントを設計する場合でも、MCP は標準化された構成可能な統合方法を提供し、大規模な環境ですぐに役立つようになります。トランスポートプロトコルやセキュリティパターンからレジストリやガバナンスに至るまで、MCP エコシステムは急速に成熟しています。MCP は今後もオープンかつコミュニティ主導であり続けるため、今日の開発者には MCP の進化を形作るチャンスがあります。

よくあるご質問

1. モデルコンテキストプロトコル (MCP) とは何ですか?

モデルコンテキストプロトコルは、AI モデルをさまざまなデータソースやツールに接続するための構造化された双方向の方法を提供し、より関連性の高い情報に基づいた応答を生成できるようにするオープンスタンダードです。

2. MCP は他のエージェントプロトコルと比べてどうですか?

ほとんどのエージェントプロトコルは、エージェント同士の通信に重点を置いたエージェント間プロトコルと、構造化されたコンテキストを LLM に提供することに重点を置いた MCP などのコンテキスト指向プロトコルの 2 種類に分類できます。

3. Elastic の MCP サーバーではどのような種類のツールを公開できますか?

Elastic の MCP サーバーでは次のツールを公開できます。 list_indices: 利用可能なすべてのElasticsearchインデックスを一覧表示する get_mappings: 特定のElasticsearchインデックスのフィールドマッピングを取得します search: 提供されたクエリDSLを使用してElasticsearch検索を実行します。 get_shards: すべてのインデックスまたは特定のインデックスのシャード情報を取得します。

問題を報告する