【ITニュース解説】Elicitation in MCP: Bridging the Human-AI Gap

近年、人工知能（AI）の進化は目覚ましく、人間がほとんど介入せずにデータにアクセスし、タスクを実行できる自律システムの開発が中心であった。このような背景の中で、「モデルコンテキストプロトコル（MCP）」は非常に重要な進展であり、大規模言語モデル（LLM）と外部ツールとの間の通信を標準化する役割を担っている。これは、AIアプリケーションにとっての「ユニバーサルAPI」のようなものと考えることができる。

しかし、すべての作業フローが完全に自動化されるべきだとは限らない。AIエージェントが一時停止し、人間ユーザーに明確な説明を求めたり、確認を依頼したりする必要がある重要な局面がある。このような「ヒューマン・イン・ザ・ループ」（人間が介入する仕組み）の機能に対する要求に、MCPの新しい「エリシテーション（Elicitation）」機能がまさに応えているのである。

エリシテーションは、MCPサーバーがMCPクライアントを介して、ユーザーから構造化された入力を要求するための動的なメカニズムを提供する。これは、すべてのパラメータが事前に固定されているか、最初からすべて収集されるという従来のモデルとは大きく異なる点である。エリシテーションは、この双方向通信を可能にすることで、金融取引のような重要な行動の確認から、曖昧な要求の明確化に至るまで、より洗練された安全な対話型ワークフローを実現する。

エリシテーション導入以前の一般的なMCPワークフローでは、クライアントがMCPサーバーにリクエストを送信し、サーバーはツールを実行して結果を返すという流れであった。例えば、経費管理ツールで上司の承認が必要なシナリオでは、このプロセスは非常に煩雑だった。ツールは承認待ちの状態を処理するように設計する必要があり、ユーザーとの対話はアプリケーションロジックのカスタムかつ非標準的な部分として実装されていた。MCPのプロトコル自体には、このような人間との対話を表現するためのネイティブなメカニズムが存在しなかったのである。

現在、MCP仕様のドラフト版であるエリシテーションは、ユーザー入力を要求するプロセスを標準化することでこの問題を解決する。サーバーは構造化されたエリシテーション要求をクライアントに送信でき、クライアントはこれを任意のインターフェース、例えばコンソールプロンプト、ポップアップダイアログ、SlackやMicrosoft Teamsのようなプラットフォーム上のメッセージを通じてユーザーに提示できる。重要な利点は、ユーザーのインターフェースが何であれ、クライアントとサーバー間の対話がプロトコルと一貫性を保つことである。ユーザーが必要な入力を提供すると、クライアントはそれをサーバーに送り返し、ワークフローが再開される。この動的な、実行時（アットランタイム）の機能こそが、MCPを静的なツール呼び出しプロトコルから、複雑でインタラクティブな、複数回のやり取りを伴うワークフローを処理できるフレームワークへと変貌させるのである。

エリシテーションの仕組みを理解するためには、まず「ストリーマブルHTTP」のメカニズムを把握する必要がある。これはMCPにおける二つの標準的な転送メカニズムの一つであり、もう一つは標準入出力（stdio）である。従来のステートレスなREST APIとは異なり、ストリーマブルHTTPは状態を保持し、双方向通信のために設計されている。この転送プロトコルは、エリシテーション要求のようなリアルタイムイベントをサーバーがクライアントにプッシュすることを可能にする、重要な構成要素である。

ストリーマブルHTTPを通じた通信フローは、複数のステップからなるハンドシェイク（合意形成）によって行われる。まず、クライアントはセッションを開始するために初期のHTTP POSTリクエストをサーバーに送信する。サーバーは、その会話全体の識別子として機能する一意の「MCP-Session-Id」を返信する。次に、クライアントは通知チャネルを初期化するためにもう一度POSTリクエストを送信する。その後、クライアントは/mcpエンドポイントに対し、Content-Typeがtext/event-streamである長時間接続のHTTP GETリクエストを行う。これにより、サーバーがクライアントに継続的にポーリング（問い合わせ）することなく、複数のメッセージをストリーム配信できる「Server-Sent Events（SSE）」チャネルが確立される。チャネルが確立されると、クライアントはtool/listエンドポイントを介して、サーバーから利用可能なツールのリストを要求する。クライアントはツール情報とユーザーのプロンプトをLLMに渡し、LLMはどのツールを呼び出すかを決定し、それを起動する。

ここでエリシテーションが登場する。ツールがユーザー入力を必要とする場合、サーバーは事前に確立されたSSEチャネルを使用して、構造化されたJSONイベントをクライアントにプッシュする。クライアント側でエリシテーションのために登録されたコールバックハンドラが引き継ぎ、ユーザーにプロンプトを提示し、入力を収集する。クライアントはユーザー入力をサーバーに送り返し、サーバーはそれを処理し、LLMはタスクを完了するための新しいコンテキストを受け取る。最後に、クライアントはセッションを終了し、サーバー側のリソースをクリーンアップするために、最終的なHTTP DELETEリクエストを送信する。この詳細で状態を保持するプロセスこそが、ストリーマブルHTTPを標準的なRPCやRESTと区別し、エリシテーションのようなインタラクティブな機能に必要な基盤を提供するのである。

エリシテーションは、MCPがいかに動的で非同期なワークフローを可能にするかを示す強力な例である。その中核ロジックは、明確に定義されたデータフローとスキーマ（データの構造定義）に依存している。サーバー側の開発者は、ユーザー入力を引き出すことができるツールを定義する必要がある。Pythonでは、FastMCPのようなライブラリを使用すると、このようなツールを宣言的に作成することが容易になる。重要なのは、期待されるユーザー入力を定義するためのデータクラスを使用し、エリシテーション要求を発生させるツール関数を定義することである。例えば、ユーザー情報を収集するツールが呼び出されると、context.elicit_inputメソッドがプロンプトと応答タイプスキーマをJSON-RPC通知としてパッケージ化し、SSEチャネルを介してクライアントにプッシュされる。

クライアント側では、専用のハンドラがエリシテーション要求を処理する役割を担う。クライアントはこのハンドラを初期化時に登録する。このハンドラは、サーバーから構造化されたメッセージを受け取り、ユーザーと対話し（簡単な場合はコンソール入力など）、そしてaccept_with_contentというヘルパーメソッドを使用して、ユーザーの入力を構造化されたJSON-RPC応答としてフォーマットし、サーバーに送り返すことでエリシテーションのループを完了する。この設計の優れた点は、サーバーが何を必要とするかを明確なスキーマで定義するが、クライアントがそれをどのように収集するかについては完全に独立していることである。これにより、コマンドラインインターフェースから洗練されたグラフィカルユーザーインターフェースまで、多様な実装が可能となり、同時にプロトコルへの準拠を維持できる。

エリシテーションの導入は、MCPエコシステムにとって極めて重要な瞬間であり、MCPを単なるツール呼び出しプロトコルから、複雑な対話型AIアプリケーションを構築するためのフレームワークへと昇華させるものである。ユーザーを動的かつ安全にワークフローに組み込む能力は、特に規制の厳しい業界や、高いリスクを伴うアクションを行うエンタープライズグレードのソリューションにとって不可欠である。

しかし、新しい機能には常に考慮すべき点や限界が存在する。主要な懸念の一つはセキュリティである。エリシテーション自体は暗号化を義務付けていないため、パスワードや個人識別情報のような機密情報に使用すべきではないことが強調されている。開発者はこの点を認識し、認証フローや機密データを扱うために、MCP仕様内で適切に、そして最近更新されたOAuthや認証・認可の標準を使用する必要がある。さらに、動的なスキーマの概念は強力である一方で、堅牢で適応性の高いユーザーインターフェース（UI）を開発するクライアント開発者に負担をかける可能性もある。単純なコンソール入力は容易だが、実稼働に対応するクライアントは、受信するスキーマに基づいて動的にフォームやUI要素をレンダリングできる必要があり、これは複雑になる可能性がある。

今後、エリシテーションは、ユーザーとAIエージェントが協調してタスクを完了する「エージェント型アプリケーション」の新しいクラスの触媒となることが期待される。将来的な改善としては、複数回のやり取りを伴うエリシテーションや、現在サポートされている基本的なデータ型を超えたより洗練されたデータ型への対応が考えられる。これにより、ガイド付きフォーム入力や複数ステップのトラブルシューティングなど、さらにきめ細かく複雑なワークフローが可能になるだろう。