T最新テックトレンド

【深層分析】AIエージェント開発の未来を拓く「Model Context Protocol (MCP)」の隠れた可能性

AI Engineer
0:00--:--

AI Engineer World's Fair 2024で語られた、リッチでステートフルなサーバー構築への道

はじめに：AI進化の最前線で求められる「協調性」

AI技術の進化は目覚ましく、私たちの想像をはるかに超えるスピードで新しいソリューションが生まれています。2023年から2025年にかけての「エージェントオープンスタンダード」競争の勝者がエコシステムを席巻し、OpenAIからGoogle DeepMind、AnysphereからZedまで、あらゆるクライアントや研究室がその恩恵を受けている時代です。しかし、この動画で語られたように、「まだやるべきことはたくさんあります」。特に、AIエージェントがより複雑なタスクをこなし、人間のように状況を理解し、協調して動作するためには、その基盤となるプロトコルの進化が不可欠です。

AI Engineer World's Fair 2024で、MicrosoftのVS Codeチームに所属するHarald Kirschner氏が登壇し、「Full Spec MCP: Hidden Capabilities」と題して、Model Context Protocol（以下、MCP）の全貌とその秘められた可能性について語りました。本記事では、この講演の内容を深く掘り下げ、MCPがAIエージェント開発の未来をどのように形作るのか、その重要性、具体的な機能、ビジネスへの影響、そして将来性を専門的な視点と分かりやすさの両面から解説します。

第1章：MCPエコシステムの現状と、見過ごされがちな「APIラッパー症候群」

1.1 MCPの基本的な構成要素：プリミティブの役割

MCPは、AIエージェントが相互に、あるいは外部システムと連携するための共通言語と枠組みを提供するプロトコルです。その基本的な構成要素、すなわち「プリミティブ」は、エージェントがタスクを遂行し、環境と対話するために必要な機能の基盤を形成します。これらのプリミティブが組み合わさることで、AIエージェントは環境を認識し、適切なツールを選択し、データを処理し、LLMの推論能力を活用しながら、複雑なタスクをこなすことが可能になります。

  • Roots (ルート) クライアント側で動作するRootsは、サーバーに対して現在の環境に関する動的なコンテキストを提供します。これには、開いているファイル、プロジェクトの依存関係、ユーザーの設定ファイル、仮想環境のパスといった、エージェントが作業を行う上で不可欠なローカル情報が含まれます。Rootsがあることで、サーバーはエージェントがどのプロジェクト、どの構成で作業しているかを理解し、文脈に応じた適切なツールやデータを提供できるようになります。これは、エージェントに「環境認識能力」を与える上で非常に重要な要素です。

  • Sampling (サンプリング) Samplingはクライアント側で動作し、サーバーがLLM（大規模言語モデル）の補完機能をクライアントにリクエストするための画期的な仕組みです。通常、LLMへのリクエストはクライアントから行われますが、Samplingではサーバーが「このテキストを要約してほしい」「このデータから特定の情報を抽出してほしい」といったLLMの推論能力が必要なタスクをクライアントのLLMに要求できます。これにより、サーバーはLLMの強力な推論能力をオンデマンドで活用し、リソースの要約やデータの分類・抽出といった複雑な処理を効率的に実行できます。

  • Prompts (プロンプト) サーバー側で定義されるPromptsは、エージェントが特定のタスクを開始したり、ユーザーに情報を求めたりするための指示文やテンプレートです。これらは、LLMが理解しやすい形式でタスクの目的、期待される出力、利用可能なツールなどを記述するために使用されます。動的なプロンプトは、エージェントが現在の状況に基づいてユーザーとの対話を調整し、より効果的なコミュニケーションを図ることを可能にします。

  • Tools (ツール) サーバー側で定義されるToolsは、LLMが特定のアクションを実行するために呼び出す関数群です。これらは、外部APIとの連携、メール送信、テストの実行、システムコマンドの呼び出しなど、具体的な操作を抽象化したものです。ツールは、LLMの推論能力を具体的な行動に結びつけ、エージェントが現実世界に影響を与えることを可能にする、エージェントシステムの「手足」とも言える存在です。

  • Resources (リソース) Resourcesはサーバー側で提供されるデータそのもので、ファイル、ドキュメント、データベースのエントリ、画像など、多種多様な情報源を含みます。ツールがアクションを定義するのに対し、リソースはデータを定義します。リソースの適切な管理と提示は、LLMの処理効率を高め、ユーザーエクスペリエンスを向上させる上で極めて重要です。サーバーは、巨大なデータを直接送る代わりに、データへの参照を返すことで、LLMやユーザーが後から必要なデータを取得し、活用できるようにします。

  • Dynamic Discovery (動的発見) Dynamic Discoveryは、クライアントとサーバー間でこれらのプリミティブが動的にやり取りされ、相互に能力を認識し、更新するメカニズムです。これにより、エージェントシステムは固定的な機能セットに縛られることなく、環境の変化やタスクの進行状況に応じて、利用可能なツールやリソースをリアルタイムで適応させることができます。MUDゲームのデモのように、特定の状況で新しいツールが動的に出現するといった、柔軟で状況認識的な振る舞いを実現します。

1.2 「単なるAPIラッパー」シンドロームの罠

Harald Kirschner氏は、MCPエコシステムが急速に成長している一方で、多くの開発者がMCPを「単なるAPIラッパー」と誤解している現状を指摘しました。これは、MCPが持つ真の「リッチでステートフルなインタラクション」の可能性を十分に引き出せていない原因となっています。この「APIラッパー症候群」は、主に以下の3つの要因によって引き起こされています。

  1. Pragmatic Shortcuts (実用的なショートカット) 開発者は、新製品を迅速に市場に投入するために、最も手軽で分かりやすい機能、すなわち「ツール」に焦点を当てがちです。ツールはLLMが特定のアクションを呼び出すシンプルな関数として機能するため、短期間で目に見える成果を出しやすいのです。例えば、GitHub CopilotがPlaywrightを使ってウェブサイトを起動し、スクリーンショットを撮るという一連のツール呼び出しを実行するデモは、その分かりやすさと即効性を示しています。しかし、このアプローチは、より深いコンテキスト理解や動的な状態管理といった、MCPの真価を見過ごすことにつながります。実際、モデルコンテキストプロトコルのウェブサイトから得られたデータが示すように、クライアントの採用状況はツールが圧倒的に多く、リソースやプロンプトの採用は後れを取っています。これは、多くの開発者が「ツールの呼び出し」にとどまり、MCPの持つ「リッチなステートフルなインタラクション」を構築する上での障壁となっています。

  2. Self-Reinforcing Loop (自己強化ループ) 一度シンプルなツール連携のパターンが確立されると、新規参入者もその最小限のパターンを模倣し、コピーする傾向があります。これにより、「ツールのみ」に特化したエコシステムが自己強化され、より高度な機能やパターンが試されにくくなる悪循環が生じます。開発者が既存の成功事例に倣うのは自然なことですが、それがプロトコルの可能性を限定してしまう側面も持ち合わせています。この自己強化ループは、イノベーションの機会を狭め、エコシステム全体の多様な発展を阻害する可能性があります。

  3. Technical Barriers (技術的な障壁) クライアント、SDK、ドキュメント、そしてリファレンス実装における初期の制限も、この症候群に拍車をかけています。利用可能なサポートが限られているため、開発者はフルスペックを活用しようにも情報や手段が不足していると感じる場合があります。例えば、特定のプリミティブ（例えばSampling）に関する公式ドキュメントやSDKのサポートが不足している場合、開発者はその機能の重要性を認識していても、実際に実装することが困難になります。これは、プロトコルの普及初期段階では避けられない課題とも言えますが、コミュニティ全体の取り組みによって克服すべき点であり、これらの障壁を取り除くことで、より多くの開発者がMCPの全機能を探索できるようになります。

このような課題がある中で、Harald氏は、MCPが単なるツール呼び出しの枠を超え、より洗練されたエージェント体験を実現するための「隠れた能力」に焦点を当てることの重要性を訴えました。VS Codeも当初はツールサポートから始まったものの、現在ではディスカバリーやルートのサポートを追加し、今後のリリースではリソース、プロンプト、サンプリングを含むフルスペックサポートを提供する予定です。この動きは、エコシステム全体がより包括的なMCPの活用へと移行するための良い前例となるでしょう。

第2章：フルスペックMCPが解き放つ「リッチなステートフルなインタラクション」

MCPの全機能を活用することで、AIエージェントは単発的なアクションの実行だけでなく、時間や状況に応じて変化する、より豊かな「ステートフルなインタラクション」を構築できるようになります。これは、人間とAI、あるいはAIエージェント同士の協調性を飛躍的に向上させる可能性を秘めています。

2.1 ツールの深化：量より質、そしてユーザー主導のコントロール

ツールはMCPの最も普及したプリミティブですが、その運用には課題も存在します。LangChainのReact Agent Studyは、「ツールの数が増えても、必ずしもより良いエージェントになるわけではない」という重要な知見を明らかにしました。この研究では、ツールの過負荷（Tool Overload）、ドメインの混乱（Domain Confusion）、軌道崩壊（Trajectory Breakdown）といった問題が指摘されており、ツールの数が増えるほどAIのパフォーマンスが悪化し、エージェントがタスクを解決する能力が低下することが示されています。これは、AIが大量のツールの中から適切なものを選択するのに苦労したり、多様なドメインのツールが混在することで混乱したり、多くのステップを要するタスクでエラーが発生しやすくなるためです。

このような課題に対処するため、クライアントはユーザーがツールの使用を細かく制御できる機能を提供する必要があります。VS Codeが実装している例は、ツールの「量」ではなく「質」と「関連性」を重視するアプローチを示しています。

  1. Per-chat Tool Selection (チャットごとのツール選択) VS Codeでは、特定のチャットセッション中に利用可能なツールを手動で選択・絞り込む機能を追加しました。これは、ツールピッカーを通じて行われ、開発者はその時に本当に必要なツールセットに集中できます。すべての利用可能なツールを表示するのではなく、タスクの文脈に合わせた少数のツールを選ぶことで、エージェントがどのツールを使うべきか判断する際の負荷を軽減し、ツールの過負荷やドメインの混乱を防ぎます。選択されたツールはセッション間で保持されるため、開発者はより効率的に作業を進めることができます。

  2. Mention Tools in Prompts (プロンプトでのツール言及) ユーザーがプロンプト内で明示的に特定のツールを指定できる機能も重要です。これにより、LLMがどのツールを使うべきかを推測する手間が省け、より的確なツール呼び出しが可能になります。例えば、ユーザーが「[検索ツール]を使って最新のデータを探して」と指示すれば、LLMは迷うことなく検索ツールを呼び出します。これにより、LLMの推論プロセスが簡素化され、より迅速かつ正確な結果が期待できます。

  3. User-defined Tool Sets (ユーザー定義ツールセット) VS CodeのInsiders版で出荷される新機能は、複数のツールを組み合わせて特定のワークフローに対応する「ツールセット」をユーザーが定義し、再利用できるというものです。例えば、フロントエンドのテストを行うためのツール群（ウェブサイト起動、スクリーンショット撮影、DOM要素操作など）を一つのツールセットとしてまとめ、「フロントエンドテストを実行して」といった形で呼び出すことができます。これにより、複雑なタスクも簡潔に実行できるようになり、開発者は頻繁に使うツール群を効率的に管理・再利用できます。

さらに、MCPの仕様には「ツールの動的発見 (Dynamic Discovery)」が組み込まれています。これは、サーバーが実行中に新しい機能（ツール）をクライアントに通知したり、既存の機能を更新したりする能力を指します。これにより、エージェントは固定的な機能セットに縛られることなく、環境の変化やタスクの進行状況に応じて、利用可能なツールをリアルタイムで適応させることができます。

  • MUDゲームのデモ：動的発見の具体例 GitHub上で公開されているMUD (Multi-User Dungeon) MCP (github.com/weslen/mud-mcp) をVS CodeのCopilot上で実行するデモは、ツールの動的発見の優れた具体例です。このデモでは、エージェントがMUDゲームのゲームマスターとして振る舞い、プレイヤー（ユーザー）をテキストベースのアドベンチャーに導きます。

    1. 初期状態の認識: ゲームが開始されると、エージェントはまず「look」（周囲を見る）や「inventory」（所持品を確認する）といった基本的なMUDツールを認識しています。Copilotはこれらのツールを呼び出し、現在の位置情報（ダンジョンの入り口、アイテム：トーチ）や所持品（空の手と空のリュック）をユーザーに提示します。
    2. 状況に応じたツールの出現: ユーザーが「pick up stuff, accept the quest and continue east!」と入力すると、Copilotは「pick_up」（アイテムを拾う）と「move」（移動する）というツールを呼び出し、トーチを拾ってダンジョンの奥へと進みます。
    3. 新たな状況でのツール発見: ダンジョンを進む中で、エージェントは「A fierce Cave Goblin grows menacingly at you!」というメッセージでゴブリンに遭遇します。この時、MUDゲームの現在の状況が「モンスターとの遭遇」に変化したことを認識したエージェントは、新たに「battle」（戦う）というツールを動的に提示します。ゴブリンに遭遇するまではこの「battle」ツールは表示されず、必要な状況になって初めて利用可能になるのです。
    4. インタラクションの進行: ユーザーが「To battle!」と入力して戦闘を開始すると、Copilotは「Run battle --mud (MCP Server)」を実行し、ゴブリンを倒して「VICTORY!」のメッセージを返します。

    このデモは、エージェントが単に利用可能なツールを羅列するのではなく、現在のゲームの状態や文脈を深く理解し、その状況に応じて最適なツールを動的に「発見」し、「提供」していることを示しています。これにより、エージェントはより賢く、より人間らしいインタラクションを実現し、ユーザーは常に適切な選択肢を与えられるため、より没入感のある体験が得られます。これは、MCPが実現するリッチなステートフルなインタラクションの強力な証左と言えるでしょう。

2.2 リソースの活用：データとコンテキストの最適化

ツールがアクションの実行を担うのに対し、「リソース」はエージェントが利用するデータそのものです。ファイル、ドキュメント、データベースのエントリ、画像など、多種多様な情報源がリソースとして扱われます。リソースの適切な管理と活用は、LLMの処理効率を高め、ユーザーエクスペリエンスを向上させる上で極めて重要です。MCPは、データをクライアントとユーザーにアクセス可能にするためのいくつかのユースケースを提供します。

  1. Reduce Response Tokens (レスポンストークンの削減) LLMに直接大量のデータを送ると、コストがかかるだけでなく、トークン制限に達するリスクもあります。MCPのリソース機能を使えば、サーバーが巨大なファイルをLLMに直接送る代わりに、ファイルへの参照（URIなど）を返すことで、LLMが処理するトークン数を大幅に削減できます。LLMは必要な時にその参照先のデータを取得し、処理を行うため、効率的なやり取りが可能です。例えば、ウェブサイトのスクリーンショットを生成するツールが、画像ファイルを直接返すのではなく、その画像へのURLを返すことで、LLMは必要な時に画像を閲覧したり、ユーザーがダウンロードしたりできます。これにより、LLMのコスト効率と処理速度が向上します。

  2. Expose Data/Files to User (ユーザーにデータ/ファイルを公開) エージェントが生成したデータやファイルを、ユーザーが直接利用できる形で提供することもリソースの重要なユースケースです。例えば、Playwrightで取得したスクリーンショットは、単にLLMのコンテキストとして利用されるだけでなく、ユーザーが直接ダウンロードして確認できるように提示されることで、より実用的な価値が生まれます。これにより、エージェントは単にタスクを自動化するだけでなく、その結果を人間が理解・活用しやすい形で提供し、ユーザーの具体的な行動を支援できるようになります。

  3. Attach as Context (コンテキストとしてアタッチ) 特定のタスクに関連するリソースをコンテキストとしてエージェントに明示的にアタッチすることで、エージェントが不要なツール検索を行う手間を省き、より的確な情報に基づいてアクションを実行できるようになります。例えば、あるプログラミング言語のドキュメントをリソースとしてアタッチすれば、エージェントはそのドキュメント内の情報に基づいてコードを生成したり、質問に答えたりできます。これにより、LLMの推論プロセスが効率化され、結果の精度が向上します。サーバーは、ファイルの内容を全てLLMに送るのではなく、関連するリソースへのセマンティックなレイヤーを提供することで、エージェントの理解を深めます。

これらのリソースの活用方法は、エージェントが単に情報を返すだけでなく、その情報を「どのように」返すか、そして「誰が」その情報を利用するかを考慮することで、よりスマートなエージェント体験を実現します。

2.3 ルートの強化：環境への深い理解

「Roots」は、MCPがエージェントに「環境認識」を与える上で不可欠なプリミティブです。クライアントが現在作業している開発環境の動的なコンテキストをサーバーに提供することで、エージェントはより賢く、よりパーソナライズされたサポートを提供できます。これは、エージェントが盲目的に動作するのではなく、周囲の状況を理解した上で行動することを可能にします。

  1. Shared Env/Secrets Access (共有環境/秘密アクセス) エージェントは、開発環境の.envファイル、仮想環境のパス（.venv）、秘密情報が格納されたディレクトリ（/mnt/secrets）、VS Codeの設定ファイル（.vscode/settings.json）などを参照できます。これにより、エージェントは環境変数、設定値、APIキーなどの秘密情報に安全にアクセスし、より正確なコード生成やデプロイメントの補助が可能になります。例えば、エージェントが特定のAPIキーを必要とする場合、ユーザーに尋ねることなく.envファイルからその情報を取得し、自動的に利用できます。これは、開発者が手動で環境情報を入力する手間を省き、セキュリティを確保しながら、エージェントの能力を最大限に引き出すことを意味します。

  2. Framework-aware Tooling (フレームワーク認識ツール) Rootsを通じて、エージェントは現在のプロジェクトがReact、Svelte、PythonのPoetryなど、どのフレームワークや言語スタックを使用しているかを自動的に認識できます。例えば、package.json（JavaScript/Node.jsプロジェクトの依存関係）、pyproject.toml（Pythonプロジェクトの依存関係）、devcontainer.json（開発コンテナの設定）などのファイルを読み取ることで、エージェントはプロジェクトの依存関係や構成を理解し、そのフレームワークに特化した適切なツールやテストを実行できます。これにより、「どのフレームワークを使っていますか？」といった質問を繰り返すことなく、エージェントは開発者の意図をより深く理解し、文脈に即したサポートを提供します。これは、開発者が異なるプロジェクト間を移動する際に、エージェントが自動的に環境に適応することを意味します。

  3. Deployment Activation (デプロイメントのアクティベーション) エージェントは、devcontainer.jsonやdeploy.ymlなどのインフラファイルが存在する場合にのみ、CI/CDツールを有効にするなど、デプロイメントの文脈を認識できます。これは、開発者体験のエンドツーエンドを繋ぐ上で極めて重要です。エージェントは現在のプロジェクトのデプロイメントパイプラインを理解し、それに合わせた自動化されたタスクやチェックを実行することで、開発プロセスの効率性を高めます。例えば、デプロイメントパイプラインが定義されている場合にのみ、デプロイ関連のツールを提示し、それ以外の場合は表示しないといった動的な振る舞いが可能です。

これらのRootsの活用方法は、エージェントがユーザーの作業フォルダやプロジェクト構造を認識し、その環境に合わせた動的でステートフルな体験を提供できることを示しています。これにより、エージェントはより「賢いアシスタント」となり、開発者はよりスムーズに作業を進められるようになります。

2.4 サンプリングの潜在力：LLMの推論をサーバーで活用

「Sampling」は、MCPのプリミティブの中でも最もエキサイティングでありながら、Harald氏が「最も実装が遅れている」と語る機能です。これは、サーバーがクライアントからのLLM補完をリクエストできるという画期的な仕組みであり、LLMの推論能力をエージェントシステムに深く統合する鍵となります。

通常のLLM連携では、クライアントがLLMにリクエストを送り、その結果を受け取ります。しかし、Samplingではその逆です。サーバーが「このテキストを要約してほしい」「このデータから特定の情報を抽出してほしい」といったLLMの推論能力が必要なタスクをクライアントのLLMに要求できるのです。これにより、サーバーは自らがLLMを持つ必要なく、クライアントが提供するLLMの能力をオンデマンドで活用し、複雑な処理を効率的に実行できます。

VS CodeのInsiders版ではすでにSamplingが実装されており、サーバーがLLMアクセスを要求すると、ユーザーに許可を求めるダイアログが表示されます。これにより、LLMの利用に関する透明性とユーザーコントロールが確保されます。ユーザーは、サーバーが自分のLLMにアクセスすることを許可するかどうかを選択できます。

Samplingを使うことで、以下のようなことが可能になります。

  • リソースの要約 (Summarize resources) 例えば、サーバーがウェブサイトのコンテンツをフェッチした後、その長いHTMLを直接処理する代わりに、Samplingを使ってクライアントのLLMにMarkdown形式で要約するよう依頼できます。これにより、LLMはより簡潔な情報に基づいて推論を行い、ユーザーにも理解しやすい形式で情報を提供できます。長いドキュメントを読み込む手間を省き、主要なポイントを素早く把握するのに役立ちます。

  • データの分類と抽出 (Categorize and extract data) 大量のテキストデータから特定のカテゴリを識別したり、必要なキーポイントを抽出したりする際にも、Samplingが役立ちます。サーバーはRawデータをクライアントのLLMに渡し、構造化されたデータ（例えばJSON形式）として返してもらうことができます。これにより、データの前処理や分析が大幅に効率化され、エージェントがより意味のある情報に基づいて行動できるようになります。

  • エージェンティックサーバーツール (Agentic server tools) さらに将来を考えると、Samplingは、LLMの推論を通じて動作する、より高度な「エージェンティックサーバーツール」の基盤となり得ます。例えば、サーバーが状況に応じて複数のLLMを連携させ、それぞれに異なる推論タスクを割り当てるといった複雑なエージェントワークフローが可能になるかもしれません。これにより、エージェントはより自律的で高度な意思決定を行うことができ、より複雑な問題解決に貢献できるようになります。

Samplingの普及は、サーバー側でLLMの強力な推論能力をオンデマンドで活用し、より賢く、より動的なエージェントを構築するための大きな一歩となるでしょう。これは、エージェントが提供する情報の質と、その情報に基づいて実行されるアクションの精度を飛躍的に向上させる可能性を秘めています。

第3章：MCPの進化を加速する開発者体験と将来の展望

MCPは、単なるプロトコル仕様に留まらず、その開発者体験（DevX）の向上にも注力しています。そして、将来の仕様策定は、AIエージェントエコシステムの成長に不可欠な要素となります。MCP運営委員会は、コミュニティからのフィードバックを積極的に取り入れながら、仕様の安定化と新機能の導入を進めています。

3.1 Better DevX: 開発モードの導入

MCPサーバーを開発する上で、デバッグやログ記録はしばしば困難な作業となります。これは、MCPサーバーが通常、開発者が手動で起動するプロセスではなく、クライアント（例: VS Code）のプロセスによって所有され実行されるためです。このため、従来のデバッグツールをアタッチするのが難しいという問題がありました。

VS Codeでは、この課題を解決するために画期的な「開発モード（Dev mode）」が導入されました。

  • 統合されたデバッグ体験: 開発モードを有効にすると、MCPサーバーがVS Codeのデバッガーにアタッチされた状態で起動します。これにより、開発者はサーバーサイドのコードにブレークポイントを設定し、ステップ実行でコードのフローを追跡したり、変数の状態をリアルタイムで確認したりできるようになります。これは、PythonやNode.jsなどの言語でMCPサーバーを開発する際に、非常に強力なデバッグ環境を提供します。例えば、動的に生成されるプロンプトの動作を確認したい場合、サーバーコード内のブレークポイントで処理を一時停止し、プロンプトの内容がどのように構築されているかを詳細に調べることができます。

  • シームレスなログ表示: サーバーの出力（ログやエラーメッセージ）は、VS Codeのコンソールに直接表示されるため、開発者は問題が発生した場合でも迅速に原因を特定できます。サーバーとクライアント間の通信ログも統合的に表示されるため、両者のやり取りを俯瞰的に把握しやすくなります。

  • ワークフローの簡素化: 開発者は、手動でのサーバー起動やデバッガーアタッチといった煩雑な作業から解放され、より本質的なコード開発とデバッグに集中できるようになります。Harald氏も、この機能が自身のMCP開発ワークフローを大きく変え、生産性を向上させたと述べています。

この開発モードは、MCPサーバーのビルド、テスト、デバッグのプロセスを劇的に簡素化し、より多くの開発者がMCPエコシステムに参加するための敷居を下げるものです。これにより、開発者はより複雑で洗練されたMCPサーバーの構築に挑戦しやすくなります。

3.2 仕様の最新情報と今後の展開

MCPの仕様は継続的に進化しており、安定化された機能やドラフト段階の提案が活発に議論されています。これらの進化は、AIエージェントエコシステム全体の能力と相互運用性を高めることを目的としています。MCP運営委員会は、オープンなプロセスを通じてコミュニティからのフィードバックを積極的に取り入れ、仕様の安定化と新機能の導入を進めています。

  1. Stable: Streamable HTTP (安定版: ストリーマブルHTTP) Streamable HTTPは、エンタープライズグレードの認証とスケーリングを可能にする機能で、VS Codeではすでに2バージョン前からサポートされています。これは、サーバーがクライアントにイベントを継続的にストリーミング配信するための効率的な方法を提供します。従来のServer-Sent Events (SSE)と比較して、より現代的でスケーラブルなHTTP通信を実現し、サーバー側のステートフルな処理の負担を軽減します。しかし、この機能を活用するサーバーがまだ少ないため、テストが困難であるという課題があります。ホスティングサービスを提供する開発者にとって、Streamable HTTPへの移行は、より堅牢でパフォーマンスの高いMCPサーバーを構築するための大きなメリットをもたらすでしょう。

  2. Draft: Updated Auth (ドラフト: 更新された認証) Updated Authは、MCPサーバーの認証機能をエンタープライズグレードに強化し、Microsoft Azure Active Directory (AAD) や他の多様なIDプロバイダーをサポートするためのドラフト仕様です。これにより、MCPサーバーはよりセキュアな環境で運用され、企業システムへの統合が容易になります。組織は、既存の認証インフラを活用してMCPサーバーへのアクセスを管理できるようになり、セキュリティポリシーの遵守が簡素化されます。この仕様に関する詳細な議論は、今後のセッションで「Building Protected MCP Servers」として紹介される予定であり、認証の専門家が深く掘り下げた情報を提供するでしょう。

  3. Community Registry (コミュニティレジストリ) Community Registryは、MCPサーバーの発見とインストールを容易にするためのコミュニティ主導のレジストリ構想です。公開およびプライベートなレジストリの仕様が検討されており、これにより開発者は自身のMCPサーバーを公開しやすくなり、他の開発者も既存のサーバーを簡単に見つけて利用できるようになります。これは、MCPエコシステムの成長と相互運用性を促進する上で不可欠な要素です。サーバーが乱立する中で、いかに優れたサーバーを発見し、利用できるかは大きな課題であり、レジストリはその解決策となります。GitHub上のモデルコンテキストプロトコルリポジトリ（github.com/modelcontextprotocol/registry）で、その詳細を確認できます。

  4. Elicitation (誘発) Elicitationは、明示的なユーザーフィードバックと同意を求めるためのドラフト仕様です。これは、ツールがユーザーからより具体的な情報を必要とする場合に、LLMが間接的に質問するのではなく、ツールが直接ユーザーに情報を求める入力インターフェースを提供することを目的としています。例えば、ツールが特定のファイルパスを必要とする場合、LLMが「どのファイルパスが必要ですか？」と尋ねる代わりに、ツールが直接ファイル選択ダイアログを表示し、ユーザーに入力を促すことができます。これにより、インタラクションがより効率的かつ直感的になり、ツールのステートフルネスがさらに高まります。これは、AIエージェントがより人間中心の対話設計を取り入れるための重要な一歩となります。

これらの仕様の進化は、MCPが単なるプロトコルではなく、成熟した開発プラットフォームへと成長していく過程を示しています。特にドラフト段階の機能は、コミュニティからのフィードバックを通じて安定化され、エコシステム全体に恩恵をもたらす可能性があるため、その動向に注目し、積極的に貢献することが重要です。

第4章：Call to Action！リッチでステートフルなサーバー構築への貢献

Harald Kirschner氏は講演の最後に、MCPエコシステムのさらなる発展に向けた「Call to Action」を呼びかけました。MCPが持つ変革的な可能性を最大限に引き出すためには、私たち開発者コミュニティの積極的な参加と貢献が不可欠です。

4.1 実装ギャップの解消と漸進的な強化

MCPにおける「漸進的な強化」は、すでに技術的には可能ですが、まだ十分に活用されていません。現在のエコシステムはツールの利用が先行し、Roots、Resources、Sampling、Dynamic Discoveryといった他のプリミティブの活用が遅れています。この実装ギャップを埋め、MCPの全機能を活用した「リッチでステートフルなサーバー」を構築するためには、以下が必要です。

  • ベストプラクティスの共有: リッチでステートフルなサーバーを構築するための具体的なベストプラクティスを、リファレンスサーバーやサンプルコードを通じて広く共有し、他の開発者がそれに倣えるようにすること。これにより、開発者はより効率的にMCPの高度な機能を実装できるようになります。
  • アクション指向、コンテキスト認識、セマンティック認識のサーバー: 現在のAIエージェントが直面している課題（ツールの過負荷、ドメインの混乱、軌道崩壊など）を解決するためには、エージェントが単にアクションを実行するだけでなく、状況を深く理解し、文脈に応じた適切な判断を下せるような、より高度なサーバーの構築が求められます。これは、MCPのフルスペック（Roots、Resources、Samplingを含む）を最大限に活用することで実現可能です。エージェントが「なぜ」「何を」「どのように」行うべきかを理解し、ユーザーや環境と協調して動作する能力を高めることが目標です。

クライアント（例えばVS Code）はすでに最新のMCP仕様をサポートしており、開発者はすぐにでもフルスペックのMCPサーバーを構築し、テストすることができます。ユーザーがこれらのリッチでステートフルなサーバーを使い始め、そのメリットを実感し、共有することで、相互運用性のギャップは自然と埋まり、クライアントは仕様に追いついていくでしょう。これは、エコシステム全体が相互に学び、成長するプロセスです。

4.2 エコシステムへの積極的な貢献

MCPはオープンなプロジェクトであり、コミュニティの貢献がその進化を大きく左右します。あなたの積極的な参加は、MCPの未来を形作る上で大きな影響力を持っています。

  • RFC (Request for Comments) への参加: NamespacesやSearchといった新しいRFCの提案を読み、その議論に参加し、フィードバックを提供することで、将来の仕様策定に直接影響を与えることができます。これは、MCPがより堅牢で、実用的で、開発者のニーズに応えるプロトコルへと進化するための重要なプロセスです。
  • クライアントとSDKへの貢献: 自身が使用しているクライアントやSDKの課題（例えば、特定のMCP機能のサポート不足）について、積極的にIssueを報告したり、プルリクエストを送ったりすることで、これらのツールの改善を促進できます。Harald氏も、VS CodeチームがユーザーからのIssueやフィードバックを綿密に分析し、それがロードマップを推進していると述べています。あなたの具体的な問題報告や提案が、次世代のMCPクライアントの機能に繋がる可能性があります。
  • 経験の共有: 自身のMCPサーバー開発経験や、フルスペックMCPを活用した成功事例をブログ記事、カンファレンス発表、GitHubリポジトリなどを通じて共有することは、エコシステム全体の知識と実践レベルを高める上で非常に重要です。オープンソースプロジェクトにコントリビュートする、リファレンス実装を開発する、あるいはワークショップを開催するといった活動は、MCPの普及と理解を深める上で大きな影響を与えます。

MCPには、AIが私たちの日々の仕事や生活にシームレスに統合され、より賢く、より生産的な未来を築くための共通基盤となる、変革的な可能性があります。この可能性は、すでに存在する仕様を活用し、エコシステムがそれに追いつくことで、私たち全員が解き放つことができます。あなたの声は、MCPの未来を形作る上で大きな影響力を持っています。コミュニティに参加し、フィードバックを共有し、積極的に貢献することで、AIエージェント開発の変革的な可能性を共に解き放つことができるのです。

まとめ：MCPが拓くAIエージェントの新時代

AIエージェント技術の進化は止まることを知りません。そして、その進化の鍵を握るのが、Model Context Protocol (MCP) です。Harald Kirschner氏がAI Engineer World's Fair 2024で示したように、MCPは単なるAPI連携の枠を超え、よりリッチでステートフルな、そして環境認識能力の高いエージェントの構築を可能にする潜在力を秘めています。

この変革を現実のものとするためには、私たち開発者コミュニティの積極的な参加が不可欠です。「単なるAPIラッパー症候群」から脱却し、Roots、Resources、Sampling、Dynamic DiscoveryといったMCPの全プリミティブを最大限に活用する、革新的なサーバーを開発すること。そして、その経験を共有し、仕様の改善に貢献すること。これらすべてが、AIエージェントが次の段階へと進むための原動力となります。

MCPは、AIが私たちの日々の仕事や生活にシームレスに統合され、より賢く、より生産的な未来を築くための共通基盤です。このエキサイティングな旅に、ぜひあなたも参加し、AIエージェントの新時代を共に創造しましょう。「Let's Go!」

← 一覧に戻る