WebMCPとは何か：WebサイトがAIエージェントに「ツール」を自ら公開するとき

#WebMCPが解決する課題（Webサイトオーナーの視点）

過去2年間、AI向けのWebサイト最適化といえば、「読み取られ、引用されること」（AEO/GEO）に終始していました。WebMCPは、さらにその先の新たな領域 ―― 「操作されること」 ―― を切り開きます。AIエージェントがユーザーの代わりにカレンダーの予約を入れたり、商品を絞り込んだり、複数ステップのフォームを入力したりするとき、エージェントは単に読むだけでなく、ページ上で何らかのアクションを実行する必要があります。

現在、エージェントがこれを行う主な方法は「人間のように画面を見ること」です。すなわち、ページのスクリーンショットを撮る → Visionモデルに渡す → ボタンの位置を推測する → クリックする → 再びスクリーンショットを撮る → これを繰り返す、という流れです。この手法は極めて脆弱です。CSSが少し変わっただけで機能しなくなりますし、各ステップごとに高額なトークン消費が発生し、Webサイト側はエージェントが何を実行しようとしているのかを全く把握できません。

WebMCPはこのアプローチを根本から変えます。エージェントにUIをリバースエンジニアリング（逆解析）させる代わりに、Webサイト側から実行可能なアクションを自発的に宣言します。エージェントは説明とパラメータ定義（JSON Schemaなど）が含まれるツールリストを受け取り、必要なツールを1回で構造的に呼び出します。バックエンドに構築する通常のMCPサーバーが真似できない最大のアドバンテージは、**「Webページがすでにユーザーのログイン状態、セッションデータ、ビジネスロジックを保持している」**という点です。WebMCPはブラウザ上で動作するため、これらすべてを新たにバックエンドサーバーを用意することなく、そのまま活用できます。

AIエージェントによるWebサイト操作手法の比較（従来 vs WebMCP導入後）：

WebMCPは構造を逆転させます。エージェントが画面から操作を推測するのではなく、Webサイト側が可能な操作を能動的に公開します。

#ツールの2種類の宣言方法：宣言的（Declarative）と命令的（Imperative）

WebMCPでは、要件の複雑さに応じて以下の2つの方法を選択できます。

• 宣言的（Declarative）アプローチ ―― HTMLフォーム経由： 検索、フィルタリング、新規登録といった、すでにフォームとして実装されている機能に対して、既存のHTMLフォーム要素に追加のアノテーション（属性情報としてツールの名前や説明を追加）を行うだけで、WebMCPツールに変換できます。実装コード量が最も少なく、メディアサイトやECサイトの多くに適しています。
• 命令的（Imperative）アプローチ ―― JavaScript経由： 複数ステップの動的な制御や独自のビジネスロジックが必要なフローでは、JavaScriptの navigator.modelContext.provideContext(...) を使ってツールを定義します。各ツールは name、description、入力値定義（JSON Schemaである inputSchema）、および実行ロジック（execute）を持ちます。記述方法はOpenAIやAnthropicのAPIを叩く際のアシスタントのツール定義に酷似していますが、すべてブラウザのクライアントサイドで完結します。

Webサイト側からブラウザ上でAIエージェント向けのツールを宣言する：

// Webサイト側からブラウザ上でAIエージェント向けのツールを宣言する
navigator.modelContext.provideContext({
  tools: [
    {
      name: "search_products",
      description: "キーワードと価格上限による商品検索",
      inputSchema: {
        type: "object",
        properties: {
          query: { type: "string" },
          maxPrice: { type: "number" },
        },
        required: ["query"],
      },
      async execute({ query, maxPrice }) {
        // 既存のページロジックやセッション状態をそのまま利用
        const results = await store.search(query, { maxPrice });
        return { results };
      },
    },
  ],
});

エージェントは画面上の「検索」ボタンがどこにあるかを知る必要はありません。search_products を読み込み、スキーマに沿ったパラメータを送信し、構造化された検索結果を受け取るだけです。

#セキュリティ境界（絶対に軽視してはならない領域）

WebMCPはエージェントがページ上で「アクションを実行する」ことを許可するため、セキュリティ対策は不可欠です。

• セキュアコンテキスト（Secure Context）限定： HTTPS接続、およびオリジン分離されたドキュメント上でのみ動作します。暗号化されていないHTTPページ上でツールが露出することはありません。
• Web標準のセキュリティポリシー準拠： 同一生成元ポリシー（Same-Origin Policy）やコンテンツセキュリティポリシー（CSP）は、他のブラウザ機能と同様に適用されます。
• 権限管理（Permission/Consent）： Permissions Policyの tools ディレクティブ（デフォルト値は self）によって制御されます。異なるオリジンのiframe上でツールを実行させる場合は、明示的に allow="tools" を指定する必要があります。これにより、開発者が意図した場所でのみツールを公開できます。

実案件で私が厳守している基本原則：書き込み処理や「取り消しが困難なアクション」には、必ずユーザー確認（承認ステップ）を挟むこと。 検索、絞り込み、閲覧といった「読み取り」ツールは自由に動かして構いません。しかし、「注文確定」「予約キャンセル」「決済」といったツールを設計する場合は、必ず人間による最終確認を挟むセキュリティ設計にすべきです。

#Webサイト向けWebMCP対応フレームワーク（4つの軸）

これは、WebMCPがまだプレビュー版である現時点から準備できることです。未確定のAPIの実装に賭けるのではなく、Webサイト全体の土台を整えるアプローチだからです。私は以下の4つの軸でサイトの準備状況を評価します。

要約すると、**「WebMCPのコードを1行も書かなくても、ツールの洗い出し、HTMLフォームのクリーンアップ、セキュリティの境界線決めを行っておくだけで、いつでも対応できる状態になれる」**ということです。APIが安定した段階で行う作業は、純粋なテクニカルな実装のみになります。

#全体像におけるWebMCPの位置づけ（混同の防止）

これら3つの手法は互いに補完し合う関係にあり、どれか一つが他方を置き換えるものではありません。AEO/GEOは「AIに読まれること」を解決し、WebMCPは「AIに行わせること（操作）」を解決します。もしあなたが現在すでにAIに引用されるための最適化を進めているなら（AEO・GEO対応Webサイト最適化を参照）、WebMCPはその次のステージであり、エージェントが読むだけでなく実際にボタンを押す未来への備えとなります。

#警告：現時点での過剰投資は禁物

率直に申し上げて、WebMCPはまだプレビュー版です。APIの仕様は変更される可能性があり、ブラウザサポートも現時点ではChrome（機能フラグの有効化が必要）に留まっており、他のブラウザエンジンは明確な対応時期を表明していません。そのため、以下の方針を推奨します。

• 確定していない仕様に対して、今すぐ本番環境向けにWebMCPを実装するための大規模なリソースを投じるべきではありません。
• WebMCPを通常のバックエンドMCPサーバーと混同しないでください。前者はブラウザ上のフロントエンドで動作し、後者はバックエンドサーバーで動作します。
• 上記の4つの準備軸を進めておくべきです。 これはWebMCPの最終的な行く末に関わらず、サイト自体の品質向上として価値があり、APIが普及した際には最速で対応できるアドバンテージになります。

これこそが、私が好む「早期準備の期間」です。先行利益を得るのに十分なほど新しく、かつ、ただの過剰なハイプ（一時的な流行）で終わらないだけの十分な根拠（Google、Microsoft、W3Cによるバックアップと動く実装の存在）があります。

#おわりに

WebMCPは、AIエージェントとWebページとの間を繋ぐ「失われていたミッシングリンク」であり、エージェントが画面表示に迷うことなくサイト上で**「作業を遂行する」**ための架け橋になります。Webサイトのオーナーにとって、AI対応とはもはや「引用されること」に留まらず、「操作されること」に進化しようとしていることを意味します。コードを書き始めるのはまだ先で良いですが、今からサイトのアクションを「ツール」という言語で考え始めましょう。あなたのサイトは何を可能にし、そのうちどれがエージェントによる自動呼び出しに対して安全でしょうか？

関連トピックとして、MCPプロトコルの基本構造を説明したModel Context Protocol、およびそのアドバンスドガイドをご参照ください。また、これらのツールを呼び出すエージェントを自ら開発する際は、Claude Agent SDK vs Claude API vs Claude Codeを参考にしてください。エージェント学習のロードマップ全体は [/learn/claude?lang=ja] にまとめられています。

Nguyễn Phúc Nguyên Châu
Delivery Manager
ベトナム・日本市場向けに14年のデリバリー経験（Web・システム・AI自動化）