タラバガニー設計局stalins.clubNOTE/notes/webmcp-and-typed-actions-for-agentic-web

WebMCPとTyped Actionは、人間向けUIの上にAgent向け意味層を足す

Browser Agentが人間向けUIを直接読む方式と、backend APIを直接呼ぶ方式の間に、現在のweb pageがagentへ意味付きactionを公開するという設計が現れている。代表例がWebMCPである。

WebMCPは2026年8月19日時点でW3C Web Machine Learning Community GroupのDraft Community Group Reportであり、W3C Recommendationではない。Chromeでは149からOrigin Trialとして提供されている。したがって確立したweb標準として扱うのはまだ早い。

WebMCPではweb applicationがJavaScriptやHTML annotationを通じてstructured toolを登録する。Chromeの説明では、agentがbuttonやinputの意味を画面から推測するactuationより、site側がtoolのpurposeとschemaを宣言する方がreliabilityとtask completionを改善できるとしている。Declarative APIでは通常のHTML formへannotationを加え、form fieldをtool parameterとしてbrowserが構造化する。Imperative APIではJavaScriptでより一般的なtoolを定義できる。

これは「agentのために別backend APIを全面的に作る」こととも少し違う。toolは現在開いているpageのcontextで動作し、ユーザーのauthenticated sessionやpage stateと結びつけられる。人間には従来のUIを見せながら、agentには同じ機能をsemantic actionとして見せることができる。

同時期のWeb Verbs研究も近い問題意識を持つ。click/keystrokeのようなlow-level primitiveはbrittle、inefficient、verificationしにくいとして、precondition、postcondition、policy tag、loggingを持てるtyped functionをweb actionのsemantic layerとして提案する。実装がbackend APIでもrobust client-side workflowでも、agentからはstableなverbとして扱う構想である。

ただし「structured toolなら必ずGUIより優れる」と一般化してはいけない。GUI対APIは、Agent対Programとは別の軸であるで扱ったように、programmatic interfaceはcoverageが不足すると実行不能になる。またtool selection自体もLLMによる確率的判断であり、WebMCPのChrome documentationもtool description/schemaが適切に理解されるかevalすることを推奨している。

security上もGUIをtoolへ置き換えればprompt injectionが消えるわけではない。ChromeはWebMCP agentに対し、malicious manifestとcontaminated tool outputという二つのattack vectorを明示している。tool name、parameter、descriptionやtool responseに悪意あるinstructionが混入し得るためである。

したがってWebMCPの重要性は「Browser Useを廃止する規格」という点ではない。むしろ、

  • 人間向けGUI
  • agent向けtyped action
  • backend向けAPI/MCP

を同じapplication capabilityの異なるsurfaceとして持てる点にある。未知・未対応箇所ではComputer Useへfallbackし、安定した頻出操作はtyped actionへ寄せるというhybridが可能になる。

これはAgentic Automationが自分自身を固定workflowへ「コンパイル」する設計とも相性がよい。agentが探索して発見した安定操作を、将来はUI座標のmacroではなく、typed actionやprogramへ固定できるからである。

出典

▸ ノート一覧に戻る