WebMCPとMCP Appsをつなぐ：エージェントの操作から、人が判断するUIへ

AIエージェントに候補の調査を任せても、最後の選択には画面が欲しくなることがあります。グラフの期間を変える、候補を並べて比較する、公開前の見た目を確認する。こうした操作を会話だけで繰り返すより、必要な場面で小さなUIを開けると便利です。

WebMCPは、Webページの機能をエージェントが呼べるツールとして公開する仕組みです。MCP Appsは、対応するホストの中に対話的な画面を表示するためのMCP拡張です。この2つを組み合わせると、サイトで始めた作業の一部を、エージェント側の画面で人が引き受ける構成を考えられます。

ただし、WebMCPの戻り値にHTMLを含めれば、どのエージェントでもMCP Appとして表示されるわけではありません。既存の仕様が扱う範囲と、その間を接続する実装を分けて理解する必要があります。

WebMCPの公開リポジトリでは、ページ内のJavaScript関数に説明と入力スキーマを付け、エージェントから利用できるツールとして公開する方法を説明しています。人が見ているページの状態や操作を、エージェントと共有するための入口です。

MCP Appsの公式ドキュメントでは、ツールに関連付けたUIリソースをホストが取得し、隔離されたiframeで表示します。UIとホストはメッセージを交換でき、画面からの操作をツール呼び出しへつなげられます。

まず、利用者がどの画面で作業を続けると分かりやすいかを決めます。サイト内に十分な操作画面があるなら、その画面を使う構成が自然です。会話の文脈を見ながら候補を比較したいなら、ホスト内のViewが役に立ちます。

一方は、ホストが表示したViewの機能をエージェントから操作できるようにする方向です。もう一方は、Webページのツールを呼んだ結果としてViewを受け取り、ホストがそれを表示する方向です。

Oraの記事「When a WebMCP tool returns an MCP App」は後者を扱っています。WebMCPとMCP Appsが自動的に相互運用できるという発表ではなく、両者の間を専用の実装で接続した実験です。

この区別は実装時にも重要です。画面を操作するツールを公開することと、ツールの戻り値から画面を起動することでは、ホストが受け取る情報も、検証するタイミングも異なります。

Kulikowski/webmcp-appsは、自宅向けトレーニング器具のページとChrome拡張を組み合わせたローカルデモです。エージェント役はスクリプトで動き、LLMの推論は使いません。示しているのは、UIとツールを接続する通信経路です。

ページの gym_open_fit_sidecar は、テキスト、ページ状態、埋め込んだUIリソースを返します。拡張がそのリソースをサイドパネルに表示し、人が条件を変えると、ページ側の gym_update_profile や gym_set_preferences が呼ばれ、元のページの推薦が更新されます。

試す場合はリポジトリのREADMEに従い、対応するChromeとWebMCPの実験設定を用意します。デモは本番用サービスではなく、架空の入力値でローカル実行するものとして公開されています。

この構成を別の用途へ適用する例として、レポートの比較期間を人が選ぶ画面を考えます。以下は戻り値の役割を示す概念例です。WebMCPの標準的なUI起動APIや、Orchestorの提供機能を表すものではありません。

テキストは操作の意味を伝え、構造化データは現在の値を伝え、UIリソースは操作画面を提供します。概念例のHTML部分だけでは動作しません。実際には入力処理、ホストとの初期化、ツール呼び出しの処理を持つViewが必要です。

webmcp-apps と allowedPageTools は公開デモ独自の取り決めです。一般のWebMCPクライアントがこのフィールドを解釈することは前提にできません。

MCP Appsの仕様ドラフトでは、UIに ui:// URIを使い、ツールのメタデータで関連付けます。接続時の能力交渉やホスト側の実装も必要です。

公開デモでは、次のように一部の責務をページと拡張の間の取り決めへ移しています。

とくに、独自の許可リストはページのツールそのものを非公開にする仕組みではありません。Viewからの呼び出しを制限しても、別のエージェントからそのページのツールが見える可能性は残ります。

受け取ったHTMLは、ホストの画面と同じ権限で実行しない設計が必要です。MCP Appsはsandbox内での表示とホスト経由の通信を使います。CSPによって外部接続やリソース読み込みの範囲を指定する仕組みもあります。

期間選択の例なら、Viewに必要なのは現在の期間を受け取り、新しい期間を送る能力です。レポートの削除、認証情報の読み取り、任意URLへの通信まで与える理由はありません。

実装時には、少なくとも次を別々に確認します。

これは画面を表示できるかとは別の検証です。たとえば期間入力が整数でも、負数や極端に大きな値を受け付ける必要はありません。UIの入力制約と、実際に状態を更新する処理の制約をそろえます。

ツール実行前にUIの存在が分かれば、ホストは表示準備や検査を先に行えます。結果にだけ含める方式では、呼び出し後に初めてUIの存在が分かります。どちらを採る場合も、読み込みの失敗を「ユーザーの選択が完了した」と扱わない設計が必要です。

表示機能がないことと、人がその場にいないことは別です。テキストで条件を確認できる操作なら代替経路を用意できます。人の判断が必須の操作なら、入力が届くまで待つ状態を明示します。タイムアウトを同意として扱わないようにします。

期間の切り替えと、レポートの外部公開では、必要な承認が異なります。後者を追加するなら、公開対象と送信先を人に提示し、その操作への承認を確認する必要があります。ボタンが押された事実だけでは、人とエージェントのどちらが押したかは分かりません。入力経路と権限の設計を先に決めます。

人がページ側で期間を変更した直後、View側から古い値が送られる場合を考えます。この例ではページ側に確定値を持たせ、操作後に確定した状態をViewへ返す設計が考えられます。同時更新があるなら、状態の版番号を持たせるなど、古い操作を見分ける方法も必要です。

専用のホストを持つ実験と、複数のエージェントで動く製品では維持する範囲が違います。仕様の更新、能力交渉、UIの取得、権限の制限、エラー処理を誰が担うかを書き出します。独自の戻り値を採用するなら、対応ホストと未対応ホストの挙動を両方確認します。

最初の対象には、期間選択や表示条件の比較のように、結果を確認しやすく元に戻せる操作が向いています。ページを操作し、Viewを開き、人が値を変え、元のページへ反映されるところまでを1本の経路として検証します。

成功条件はUIが開くことだけではありません。選んだ値が正しく適用されること、失敗が利用者へ伝わること、Viewを閉じても確定済みの状態が失われないことまで確認します。そこから、会話内に置くと役立つ操作だけを増やしていくのが、この構成を評価する具体的な進め方です。