WebMCPを静的サイトへ足す前に決めること

WebMCPは、AIエージェントに引用されるためのSEO設定ではありません。Webサイトが「このページでは何ができるか」を、名前・説明・入力スキーマを持つ構造化ツールとしてブラウザへ渡すための、提案中のWeb標準です。Chrome公式の説明でも、現時点はOrigin Trialやローカルフラグを含む開発段階で、仕様は議論中とされています。

したがって、導入の最初の問いは「WebMCPを入れられるか」ではなく、「人間が使う既存の操作に、エージェントが安全に使うべき一つの責任を追加する価値があるか」です。価値がなければ、静的HTMLとアクセシビリティを整えたまま見送ることが正しい判断です。

先に結論：WebMCPは既存UIの代替ではなく、条件付きの拡張

WebMCP、agent-friendlyなHTML、通常のMCPサーバーは、似た単語で説明されますが責任が違います。

WebMCPを追加しても、本文、リンク、フォーム、結果表示、no-JSの代替を削除しません。エージェントがツールを発見できないブラウザや、通常の閲覧者には、従来のUIがそのまま機能する必要があります。

1. WebMCPは何を解決するのか

通常のブラウザエージェントは、スクリーンショット、DOM、アクセシビリティツリーから、どの要素をどう操作するかを推測します。WebMCPでは、サイト側がエージェントに実行可能なツールの目的と入力を宣言します。Chrome公式の資料では、ツールの発見、JSON Schemaによる入力・出力の定義、ページ状態の共有が主要な要素として整理されています。

「操作を短くできる」だけでは採用理由になりません。何を実行したか、何が変わったか、誰が確認したかを、画面と通常のHTMLでも追跡できることが前提です。

2. 静的サイトとの相性を判断する

WebMCPはJavaScriptのImperative API、または標準HTMLフォームへ注釈を付けるDeclarative APIから始められます。しかし、静的生成されたHTMLにツール宣言を置けることと、サイトへ導入する価値があることは別です。

導入を検討できる条件

• ユーザーが繰り返す一つの作業があり、目的を一文で説明できる。
• 入力が型付きで、許容範囲と無効値への応答をコードで検証できる。
• ツールの実行結果が、画面上の見出し・状態・次のリンクへ戻る。
• ツールがなくても、人間は標準のリンクやフォームで同じ目的へ到達できる。
• 書き込みや高リスク操作には、明示的なユーザー確認と中断方法がある。
• 正常系だけでなく、権限不足、通信失敗、レート制限、古い状態を評価できる。

見送るべき条件

• 「AI対応」というラベルを付けること以外に、利用者の仕事が変わらない。
• 読み物や一覧を、ツール名・説明・schemaのためだけに分割する。
• エージェントが使うために、既存の視覚UIやno-JS fallbackを隠す。
• 個人情報、ログイン状態、購入、削除を扱うのに、確認・権限・取消しが未定義である。
• Origin Trialや対応ブラウザが変わったときの代替経路を持てない。
• ツールの成功率を測る評価シナリオ、許容出力、失敗時の再試行条件がない。

3. BUILD ORBITでの現在の判断

このサイトには、WebMCPを急いで追加する理由はありません。理由は「静的サイトだからできない」ではなく、現時点の公開資産が別の責任をすでに満たしており、新しいツールに委ねるべき確定したユーザー作業がないからです。

このサイクルでは実装を見送ります。見送ることはagent対応を否定することではなく、既存のHTMLとアクセシビリティを先に保ち、実際の反復作業が見つかったときにProgressive Enhancementとして追加できる状態を残す判断です。

4. ツールの責任を一つに絞る

Chromeのベストプラクティスは、最初にtool strategyを作り、一つのツールへ一つの関数を割り当て、重複するツールを増やさないことを勧めています。名前と説明は、実行する動詞と対象を含めます。

ツール説明に長い禁止事項を詰め込むより、使える状態を登録し、使えない状態では登録を外すほうが判断しやすくなります。説明、parameter、tool name、outputは短く保ち、モデルの文脈を無駄に消費しないことも設計条件です。

5. 書き込み操作には確認の境界を置く

WebMCPの資料は、購入や予約のような重要・不可逆な操作でユーザー確認を求める例を示しています。Chromeのセキュリティガイドでは、読み取り専用、重大な結果を伴う操作、信頼できない内容を示すannotation hintが説明されています。

最低限、次の境界を分けます。

1. read-only：現在の公開データを読む。個人情報が混ざるなら読み取り専用でも安全とは限らない。
2. preview：入力を検証し、実行前の変更内容を表示する。副作用は起こさない。
3. consequential：購入、予約、送信、削除、アカウント変更。人間が対象・値・結果を確認してから実行する。
4. recovery：拒否、期限切れ、権限不足、通信失敗の後に、手動UIやサポートへ戻す。

ツールを登録できることは、ユーザーがその操作をエージェントへ委任したことを意味しません。認証済みブラウザで動く場合ほど、ツールの入力と戻り値を最小化し、信頼できない本文や第三者データを命令として扱わない境界が必要です。

6. Origin、Permissions Policy、対応範囲を確認する

Chrome公式のWebMCP資料では、APIはorigin isolationとtools Permissions Policyで制限され、デフォルトでは同一originの文脈が中心です。クロスオリジンiframeへ公開する場合は、信頼するoriginへ明示的に限定します。

これはSEOメタタグのようにページへ一行足して終わる機能ではありません。少なくとも次を記録します。

• 対応ブラウザ、Origin Trialまたはローカルflagの前提
• top-level documentかiframeか、originとPermissions Policyの範囲
• ツールを発見できない環境での標準UIとno-JS fallback
• tool metadataと戻り値に含めるデータの最小範囲
• 個人情報、認証情報、第三者コンテンツを扱うかどうか
• 仕様変更時にツールを停止・撤去する判断条件

現段階では、仕様がActive discussion中であること自体が、採用を急がない理由になります。将来導入する場合も、feature detection、限定された操作、既存UIへのfallbackを同時に実装します。

7. Evalsは成功率の飾りではなく契約の確認にする

WebMCPのEvals資料は、エージェントがツールを呼ぶタイミング、引数、許容される回答をリリース前に確認する必要があると説明しています。これは通常のunit testだけでは足りませんが、いきなり「agent成功率」を公開指標にすることとも違います。

最初の評価シナリオは、次のような小さい契約にします。

結果はブラウザ、モデル、プロンプト、データ、時点に依存します。このローカルリポジトリのa11y/E2E PASSを、WebMCP対応や検索表示、エージェント成功の証拠へ拡張しません。

8. SEOとの関係を混同しない

Google Searchの生成AIガイドは、通常のSEO、クロール可能性、独自性、良いページ体験を土台とし、llms.txtや特別なchunkingを順位対策として求めていません。WebMCPは検索結果へ表示されるためのschemaでも、検索エンジンへ隠れた要約を渡すファイルでもありません。

WebMCPで公開する操作がある場合も、検索向けの本文、canonical、sitemap、RSS、JSON-LDの責任は別に残ります。検索ユーザーに必要な説明を、agent toolのdescriptionだけへ移しません。

よくある質問

このNoteの責任範囲は、WebMCPを導入するかどうかの設計判断、ツールの責任分割、確認・権限・評価・fallbackです。HTML、role、label、状態、スクリーンショットをそろえる基礎はAIエージェントにも読みやすいWebサイトの設計へ、Astroの静的生成とIslandの境界はAstroで静的サイトを作る前に決める5つのことへ、リリースPASS/FAILは品質ゲートへ戻ります。