MCP Elicitationとは？AIの処理中に人へ追加入力を求める仕組み

MCP Elicitationとは？AIの処理中に人へ追加入力を求める仕組み

処理に必要な条件を人へ尋ね、回答に応じて次の動作を決めるのが基本です。入力欄が表示されることと、回答後にどの操作を実行するかは、分けて理解すると使いどころが見えてきます。

MCP Elicitationが必要になる場面

この機能が役立つのは、ツールが仕事を進めるために必要な情報を、まだ持っていない場面です。たとえば「駅の近くで会議室を探して」という依頼だけでは、利用日や参加人数が分かりません。AIが今日の日付や少人数を勝手に選べば、空室が見つかっても利用者の希望に合わない可能性があります。

推測で埋めると結果が変わる条件を、利用者に確認できることが主な利点です。後からすべてをやり直すより、検索前に必要な項目を確認するほうが、条件違いの結果を減らせます。一方、すでに依頼文から明確に分かる人数まで毎回聞き直す必要はありません。

ここには三つの役割があります。利用者は条件を選んだり入力したりする人です。MCPクライアントは、AIアプリ側でサーバーとのやり取りを担い、入力要求を利用者へ提示する窓口になります。MCPサーバーは検索などのツールを提供し、処理に必要な条件や受け取った値を扱います。実際の画面の形や表示場所は、利用するアプリによって異なります。

通常のチャットでも、AIは「何人で使いますか」と質問できます。Elicitationの特徴は、会話の文章だけに頼らず、ツール連携の中で入力要求とその応答を扱える点です。たとえば人数を数値の項目として受け取れば、後続の処理へ渡しやすくなります。

ただし、これはAIが必ず質問文を生成する機能ではありません。ツールの実装が必要な入力項目や説明を用意することもあります。また、利用者に一度確認すれば残りをすべて自動実行できる、という意味でもありません。どの情報が不足し、回答後に何を行うかを定めておく必要があります。

フォームと外部URLをどう使い分けるか

方式を選ぶときは、何を入力するかと、その情報をどこで扱うべきかを考えます。会議の日付や人数のように、アプリ内で簡潔に確認できる条件にはフォーム方式が向いています。別サービスへのログインなど、そのサービスの画面で進める必要がある手続きにはURL方式を検討します。

フォームでは、入力項目の型や制約をスキーマで伝えます。スキーマとは「どの項目に、どのような値を入れるか」を記した設計図です。たとえば人数を整数として扱い、必須項目にする、といった指定に使います。クライアントはその情報を基に入力画面を用意するため、サーバーが完成済みの画面全体を配る仕組みとは異なります。

日付を表す文字列や選択肢をどう指定できるか、どの型や制約に対応するかは、採用する仕様とクライアントの実装で確認します。スキーマに条件を書くだけで、あらゆる入力部品や複雑な画面を同じように表示できると考えないことが大切です。

二つの方式では入力する場所が変わりますが、どちらも利用者が要求の目的を理解して選べることが前提です。

URL方式では、ブラウザーでページを開いたことと、手続きを終えたことを区別します。利用者がログイン画面を開いたまま離れたり、途中で閉じたりする場合があるためです。完了通知の仕組みや確認方法は採用する仕様・サービスに合わせて確認し、必要な結果を受け取ってから次の処理へ進めます。外部ページを使えば無条件に安全になるわけではなく、接続先の信頼性も判断が必要です。

入力要求から受諾・拒否・中止までの流れ

概念上の流れは、不足情報の判明、入力要求の提示、利用者の応答、応答に応じた処理の四段階です。たとえば検索に人数が必要だと分かったら、その目的と入力項目を示し、利用者の選択を受け取って次の動作を決めます。

これは役割を理解するための説明です。実装時には、採用する仕様の版に合わせて、要求の表し方、応答の返却先、追加の要求を行える条件を確認します。異なる版の通信例を一部だけ組み合わせると、要求を送る方向や処理を再開する手順が食い違うおそれがあります。

利用者の応答を考えるうえで重要なのが、accept・decline・cancelの違いです。日本語ではそれぞれ受諾、拒否、中止と捉えると理解しやすくなります。

受諾は入力要求への応答であり、後続の処理が成功したという報告ではありません。正しい人数を送れても、条件に合う部屋がないことはあります。外部手続きへ進む意思を示しても、ログインや必要な登録が完了したとは限りません。

無応答や通信切断も、同意として扱えません。利用者が何も選ばないまま時間切れになった場合は、待機を終了する条件や再開方法をアプリ側で定めます。明示的な拒否が届いた場合と、応答を受け取れなかった場合を区別すると、誤った案内を防げます。

入力値が不正なときは、問題の項目と修正方法を伝えます。人数が「0」で検索できないなら、その理由を説明して再入力を求めます。拒否された値を勝手な既定値で補ったり、同じ要求を無限に繰り返したりする設計は避けます。再要求は、仕様上の条件に加え、利用者が続ける意思を持っているかも踏まえて行います。

予約検索の具体例で追加入力を理解する

ここからは、実在サービスの導入事例ではなく、会議室検索アプリの仮想例で考えます。利用者は「来週、駅の近くで会議室を探して」と依頼しました。検索対象の地域はアプリで選択済みですが、具体的な日付と参加人数が不足しています。

アプリは「空き状況と収容人数を確認するため、利用日と人数を入力してください」と説明し、二つの項目をフォームで提示します。「来週」をアプリが一日へ決めつけるのではなく、利用者に希望日を選んでもらいます。利用者が10月15日、6人と入力すれば、その値を検索条件に組み込めます。

受諾された場合は、日付が受付可能な範囲か、人数が正の整数かを検証して検索します。拒否された場合は、「日付がないため空き状況は調べられません」と伝え、可能なら施設一覧だけを案内します。中止された場合は、その入力手続きを閉じます。元の検索依頼を履歴に残すか、後から再開できるかはアプリの設計次第です。

さらに、会員限定の施設を検索するために、予約サービスへのログインが必要だったとします。この場合はURL方式でサービスの正規ページへ案内し、認証情報をそのページで扱う構成を検討します。AIとの会話や通常フォームにパスワードを入力させる必要はありません。

外部手続きの後は、対象の利用者・検索依頼と結果を対応付け、必要な手続きが完了したことを確認します。ページが開いただけで検索を再開すると、まだ使えない会員機能を呼び出す可能性があります。利用者が戻らなかったときの終了条件も用意しておきます。

最後に、検索条件の入力と有料予約の確定は別の操作です。「6人」と答えたことを、特定の施設への支払いや予約の承認に読み替えてはいけません。確定へ進むなら、候補、利用時間、料金、キャンセル条件などを示し、その操作に必要な確認を別途行います。

安全に使うための入力と権限の設計

入力画面には、何のための要求か、どのサービスが求めているか、情報がどこへ送られるかを分かりやすく示します。「追加情報が必要です」だけでは、利用者は入力してよいか判断できません。「会議室の収容人数で絞り込むため、参加人数を検索サービスへ送ります」と説明すれば、用途が具体的になります。

求める項目は、その処理に必要な範囲へ絞ります。空室検索の段階で住所や支払い情報まで集める理由は通常ありません。必須項目と任意項目を区別し、拒否や中止の操作も見つけやすくします。入力しない場合に使えなくなる機能を説明すれば、利用者は結果を理解して選択できます。

受け取った値は、画面側の制約だけに頼らず、サーバー側でも検証します。整数として読めるかという型の検証に加え、予約可能な日付か、人数が施設の上限内かといった業務上の条件も確認します。フォームに入力できたことは、その値を使って処理してよい証明にはなりません。

入力内容をモデルへ渡す範囲と、ログに残す範囲も決めておきます。画面で集めたすべての値を会話履歴や診断用ログへコピーすると、本来は処理担当のサービスだけが必要とする情報まで広がります。機密情報は適切な場所で扱い、処理結果だけを返すなど、不要な受け渡しを減らします。

外部URLについては、表示名だけで判断せず、実際の接続先と手続きの内容を確認できるようにします。認証情報を外部で扱う手順、MCPサーバーへ接続するための認可、有料予約を確定する承認は、それぞれ目的が異なります。外部サイトへのログインが済んでも、MCP接続の権限や業務操作への同意がすべてそろうわけではありません。

導入前には、クライアントとサーバーが利用予定の入力方式に対応しているか、対応機能をどう確認するかも調べます。未対応なら、入力できない理由と、手動で条件を指定するなどの代替手段を案内します。利用者に見えない要求を待ち続ける状態を作らないことが大切です。

また、Elicitationを使うだけで実行状態が保存されるわけではありません。待機中の状態保存、タイムアウト、再試行時の重複実行防止は別途設計します。検索の再試行と、料金が発生する予約の再試行では影響が違うため、後者では同じ依頼による二重予約を防ぐ仕組みも必要です。

MCP Apps・HITL・チェックポイントとの違い

似た場面で登場する用語でも、担当する役割は異なります。どれも「人が途中で関わる機能」とまとめてしまうと、入力画面を用意すれば状態保存までできる、といった誤解につながります。何を実現するためのものかで整理すると、組み合わせ方が分かります。

たとえば、日付と人数を尋ねる小さなフォームなら、定型入力として考えやすい場面です。一方、会議室の写真や座席配置を見比べ、複数の条件を操作しながら候補を選ぶ画面なら、MCP Appsのような対話UIが検討対象になります。画面に入力欄があるという理由だけで、二つを同じ機能として扱うことはできません。

HITLはHuman-in-the-Loopの略で、人の判断を処理へ組み込む考え方です。Elicitationで人から条件を得ることはその一例ですが、Elicitation自体がモデルを再学習させる機能という意味ではありません。チェックポイントを併用すれば待機前の状態を保存できますが、その保存や復元は入力要求とは別に用意します。

A2Aによる別エージェントへの依頼にも、追加情報が必要になる場面はあります。ただし、エージェント間の仕事のやり取りと、MCPクライアントを通じた利用者への入力要求は、同じ通信手順ではありません。利用する層を分けて考える必要があります。

選択の出発点は、必要なのが少数の条件入力か、外部サービスでの手続きか、柔軟な操作画面かを見極めることです。そのうえで、回答を待つ状態の保存や、実行前の承認が必要なら、対応する仕組みを組み合わせます。

更新履歴