質問
あるEコマースのチェックアウトページにおいて、ブラウザエージェントが商品の絞り込みやフォーム入力を行えるようWebMCPのトライアル導入を検討しています。ツールの定義、権限の制限、ユーザーによる制御の維持、およびエージェントが影響度の高いアクションを誤って呼び出さないことの検証はどのように行いますか？
コンテキストと境界線
WebMCPは提案中のウェブ標準です。Chromeのドキュメントでは宣言的HTMLフォームツールと命令型JavaScriptツールが説明されており、Chrome 149ではオリジントライアルが提供されています。この質問は、Human-in-the-loop（人間の介在）を前提としたブラウザタブ内でのプログレッシブエンハンスメントに関するものです。WebMCPは、ブラウザコンテキストなしで動作する安定したバックエンドプロトコルとして提示されているわけでも、サーバーサイド認可の代替手段として提示されているわけでもありません。
まず以下を明確にします：検索や入力のみを行うアクションと、注文を行ったり請求を発生させたりするアクションはどれか？ツールはトップレベルページのみに表示すべきか、それともクロスオリジンのiframeにも表示すべきか？最終送信の前にユーザーの再確認が必要か？エージェントがWebMCPをサポートしていない場合やオリジントライアルが終了した場合はどうなるか？
面接官がテストしていること
面接官は、エージェントによる操作をフロントエンドの契約（明確なツール説明と入力スキーマ、既存のログイン、CSRF、ビジネス認可、ユーザー確認の維持、最小権限のクロスオリジン公開、ツールの選択・パラメータ・結果に関する評価）へと落とし込めるかをテストしています。
30秒の回答
ジャーニーを「読み取り専用」「可逆的」「不可逆的」なアクションに分割します。検索と入力には宣言的または命令型ツールを使用し、注文の送信にはサーバー認可と明示的な確認を維持します。必要なフィールドのみを公開し、デフォルトを現在のページおよびオリジンに設定し、クロスオリジンiframeには明示的なPermissions Policyを要求します。リリース前には、通常のUIをフォールバックとして維持しつつ、ツール選択、パラメータ検証、エラーハンドリング、拒絶パスを評価します。
ステップごとの詳細解説
- リスク階層：
search、filter、fillは低リスクまたは可逆的です。place-order、pay、住所の変更は影響度が高く、エージェントがツールを持っているという理由だけで自動的に実行されてはなりません。 - 契約：各ツールには、一意で不変な名前、エージェント向けの説明、JSON入力スキーマ、構造化された結果を定義します。列挙型、範囲、通貨、在庫バージョンは、クライアントとサーバーの両方で検証されます。
- ビジネスロジックの再利用：コールバックは、UIをバイパスするリクエストパスを複製するのではなく、既存のフォーム状態やドメイン関数を呼び出します。実行前に、ログイン、CSRF、カートバージョン、価格、在庫を確認します。
- 権限の境界：デフォルトではトップレベルウィンドウおよび同一オリジンコンテキストにのみ公開します。クロスオリジンのiframeへの共有は、
Permissions-Policyとiframeのallow属性で明示的に許可されている場合にのみ行い、不要な個人データは返さないようにします。 - ユーザーの制御：検索と入力では視覚的な変化を表示させます。注文、支払い、削除についてはページ内での確認とサマリーを必須とし、ツールの結果にはアクションが完了したか、確認待ちか、拒絶されたかを明記します。
- 段階的なロールアウト：まずはローカルフラグまたはオリジントライアルの配下で内部アカウント向けに有効化します。機能検出、通常のUI、およびWebMCPが利用できない場合のDOM自動化フォールバックを提供し、ツールのバージョン、結果、拒絶理由を記録します。
- 評価とモニタリング：ツール選択の精度、有効パラメータ率、完了率、誤呼び出し、拒絶の正確性、確認の網羅率を測定するためのタスクセットを構築します。影響度の高いツールには誤呼び出しゼロのゲートを設定し、異常検知時には登録を取り消します。
模範回答
チェックアウト処理を検索、入力、送信に分割します。検索と入力は可逆的であるため、WebMCPによってエージェントのターゲティング精度を向上させることができます。注文と支払いは、既存のサーバー認可、価格・在庫チェック、ページ上での確認の対象であり続けます。WebMCPは実験的機能であり、Chrome 149のオリジントライアルは管理された検証には適していますが、バックエンド権限の代替にはなりません。
ツールは現在のジャーニーに必要なフィールドのみを公開し、そのコールバック内で既存のフォームおよびドメインロジックを再利用します。入力スキーマは商品ID、数量、住所フォーマットを制約し、サーバーはログイン、CSRF、在庫、価格、注文の冪等性を再度チェックします。デフォルトでは、ツールをトップレベルページと同一オリジンのエージェントにのみ公開します。クロスオリジンのiframeが必要な場合は、パーミッションポリシーとiframeのallowの両方を設定し、アカウントプロファイル全体を返すことは決してありません。
const controller = new AbortController();
document.modelContext?.registerTool({
name: "cart_set_quantity",
description: "Set the quantity of one visible cart item; never submits an order.",
inputSchema: {
type: "object",
properties: {
itemId: { type: "string", minLength: 1 },
quantity: { type: "integer", minimum: 1, maximum: 10 }
},
required: ["itemId", "quantity"]
},
async execute({ itemId, quantity }) {
const result = await setVisibleCartQuantity(itemId, quantity);
return { content: [{ type: "text", text: result.summary }] };
}
}, { signal: controller.signal });注文ツールが存在する場合でも「ユーザー確認が必要」と返し、ツール自体が金銭を請求することはできません。各呼び出しでは、ツールのバージョン、パラメータ検証結果、ページ状態を記録します。評価セットは、誤った商品、過剰な数量、古い価格、拒否された確認、WebMCPの利用不可状態をカバーします。したがって、WebMCPは取り消し可能なプログレッシブエンハンスメントであり、ビジネス認可とユーザーの意図は既存のパス内に維持されます。
よくある間違い
- 初期トライアル段階のWebMCP機能を、安定したバックエンドAPIであるかのように説明すること。
- 支払い、アカウント削除、任意の住所変更を直接実行できる万能ツールを公開すること。
- ブラウザでのみスキーマを検証し、ログイン、在庫、価格、冪等性のサーバーチェックを省略すること。
- デフォルトでクロスオリジンiframeとツールを共有したり、ツールの結果としてユーザープロファイル全体を返したりすること。
- 通常のUI、機能検出、無効化パス、エージェント評価セットを提供しないこと。
優れた回答では、ツールの契約、サーバー認可、オリジン分離、ユーザー確認、フォールバック、定量的評価を網羅します。「ボタンに説明を追加する」だけでは、安全な操作実行を実証したことにはなりません。
フォローアップの質問と回答
なぜ注文の確定もWebMCPツールとして登録しないのですか？
注文サマリーを準備するツールを登録することは可能ですが、最終送信にはページ上での確認とサーバーの認可が必要です。ツール呼び出しはユーザーが支払いに同意したことを証明するものではなく、価格、在庫、不正利用チェックをバイパスすることはできません。
クロスオリジンiframeへのツールの公開はどのように制限しますか？
デフォルトではクロスオリジンコンテキストに公開しません。必要な場合は、明示的なPermissions-Policyおよびiframeのallow設定を使用し、ツール層で読み取りおよび書き込み可能なデータを制限します。オリジン、ページライフサイクル、および取り消しをログに記録します。
エージェントがスキーマ上は有効だがビジネス上は無効なパラメータを送信した場合はどうなりますか？
非表示の商品、古い状態、現在のユーザーのスコープ外の値をクライアントで拒絶し、その後サーバー上でビジネス検証を繰り返して構造化された拒絶レスポンスを返します。文字列を任意の操作に変換したり、パラメータを暗黙的に書き換えたりしないでください。
エージェントがツールを理解していることをどのように証明しますか？
固定のタスクセットと実際のページを使用して、ツール選択、有効パラメータ率、完了率、誤呼び出し、拒絶の正確性を測定します。支払いと削除については誤呼び出しゼロのゲートを設定し、API変更後には評価を再実行します。