WebMCP オリジン トライアルに参加する

Chrome 149 が WebMCP オリジン トライアルの提供を開始した後、Web ページとプロキシの関係はより直接的になります。ページは、マシンが推測できるように DOM と目に見えるコピーをレイアウトするだけでなく、コントロール自体も目的、ステータス、実行可能ファイルの境界を宣言できます。この変更は API トライアルのように見えますが、実際には、「インターフェイスの意図」を暗黙的な情報から明示的なプロトコルに引き上げることに似ています。

WebMCP のようなものの価値は、Web ページに用語のレイヤーを追加することではなく、エージェントが最も恐れる不確実性を強化することです。ボタンが送信、切り替え、確認、または単にポップアップ レイヤーを開くためのものであるかどうか。入力ボックスが日付、検索語、または特別な形式を必要とする約束の時間であるかどうか。以前は、この情報は主にテキスト、構造、コンテキストから推測されていました。推論は機能しますが、ページが複雑になると、エージェントは「のように見える」を「である」と誤解し始めます。

人間にとって、この誤読は通常、単なるクリックミスにすぎません。エージェントにとって、誤読は間違いの連続する道となります。検証、ロールバック、または副作用が発生し、前のステップが間違っていたことが明らかになるまで、誤った理解に基づいて実行され続けます。 WebMCP がこのセマンティクス層を明示的にすると、エージェントはページを純粋に視覚的なマップとして推測する必要がなくなり、Web ページで主要なインタラクション サーフェスの役割を明確に説明できるようになります。

この問題は、カレンダー、予約、許可アプリケーション、設定パネル、または通常の入力ボックスのように見えて実際には異なるビジネス上の意味を持つ多数のページなど、純粋な HTML コピーライティングでは説明するのが難しいインターフェイスに最も適しています。ラベルとプレースホルダーのみに依存すると、エージェントは多くの場合、ページを一周して何度も試行する必要があります。ページが「ここが日付選択です」「ここが確認アクションです」「ここのステータスはこの方向にのみ変更できます」と宣言できれば、統合コストは直接的に削減されます。

しかし、オリジントライアルでは、このセマンティクス層を維持する必要があるという別の問題も生じます。ページ構成が変わり、ボタンコピーが変わり、営業状況も変わります。エージェントが実際に依存するインテント層がコンポーネントとともに更新されないと、すぐにドリフトしてしまいます。このとき最も危険な状態は、「全く使えない」のではなく、「まだ走れるが、たまにミスをする、そしてミスが当たり前」の状態です。

したがって、WebMCP は、エージェントに投稿されるリマインダー カードというよりは、Web ページ自体に対する契約に似ています。フロントエンドは、インタラクション境界を実装、テスト、回帰チェックに書き込む必要があります。この契約層がまだデモンストレーション段階にある限り、エージェントが理解できるのは成功事例だけです。実際のページに入ったときに本当に対処する必要があるのは、バージョンの互換性、ダウングレードパス、および宣言が無効になった後の解決策です。

私は、この原点の試みを方向性の信号と見なすことを好みます。ブラウザーは、エージェントが Web ページを読み取る方法を真剣に考慮し始めました。これは、フロントエンドが人間向けにフォーマットするだけでなく、マシン向けのアクションも定義することを意味します。ページが複雑であればあるほど、この定義層の価値は高くなります。ページが変更される頻度が高くなるほど、この定義層の保守コストが大きくなります。 WebMCP などの機能の最後の遺産は、新しい用語ではなく、フロントエンドとエージェントの間の継続的な調整を意味する用語になります。