この記事は、自社サイトにWebMCP（Webサイトが自分の機能を「ツール」としてブラウザ上のAIエージェントに公開する提案仕様）を載せる、開発・情報システム担当者に向けて書いています。読み終えると、公開の前後に何を確かめるかを、項目ごとの表として手元に持てるようになります。
先に断っておきます。WebMCPはW3Cの標準ではなく、W3CのWeb Machine Learning Community Groupによる草案です。Chromeではオリジントライアル（試験提供）の段階で、公式資料も「議論の最中で、変更される可能性がある」と述べています。この記事は2026年10月20日時点の確認に基づきます。
もう一つ、区別を明確にしておきます。この記事には、草案やChrome資料に書かれている内容と、Otsumuの「自社での一般的な考え方」の両方が出てきます。後者は公式の推奨ではありません。ログや保存期間のように、公式資料に具体的な指針がない項目は、その旨を書いたうえで一般的な設計の考え方として示します。
全体像を先に知りたい方は、WebMCPの入門記事から読むと流れがつかめます。このチェックリストは、WebMCPシリーズの中で安全面をまとめる役割です。
前提：仕様と公式資料が言っている安全の範囲
チェックリストの前に、公式資料が安全について何を述べているかを確認します。
- Chromeの安全性に関する資料は、「LLMの内側で安全を保証することは不可能」という立場です。モデルが読む内容に悪意ある指示が埋め込まれる間接プロンプトインジェクション（ツールの説明・入力・出力に紛れた指示）が、主な懸念です。
- 同じ資料の指針は暫定的なもので、中心は三つです。注釈（ヒント）の付与、公開範囲の限定、出力サイズの制限です。
- 草案は、ツール実行時のユーザー確認を必須とは定めていません。クライアント（エージェントを動かす側）が、重要な操作の前に確認を出せるという位置づけです。
- 草案は、宣言と実際の動作が一致する保証がないこと、サイトの善意を前提にしていることを、現状の限界として挙げています。
- Chromeの安全性の資料には、認証・ログ・入力検証・データ最小化の具体的な指針は書かれていません。
つまり、公式資料だけで安全が完結するわけではありません。足りない部分は、サイト側の設計で補うことになります。以下のチェックリストは、その補い方を整理したものです。
チェックリスト（一覧表）
次の表は、公開前に一巡し、公開後も定期的に見直すための一覧です。「根拠」の列は、その項目が公式資料に基づくのか、自社の一般的な考え方なのかを示します。
| 項目 | 何を確かめるか | 根拠 |
|---|---|---|
| 公開範囲 | ツールを見せる相手は、同一オリジンだけか。他オリジンに見せるなら、exposedToで信頼するオリジンに限っているか | 草案・Chrome資料 |
| 最小の権限 | 各ツールが触れるデータと操作は、目的に必要な範囲に収まっているか | 自社での一般的な考え方 |
| 読み取り・書き込みの分離 | 読み取り専用のツールと、状態を変えるツールが分かれているか | Chrome資料（注釈の考え方）と自社の考え方 |
| 注釈の付与 | readOnlyHint、untrustedContentHint、consequentialHintを、実態に合わせて付けているか | 草案・Chrome資料 |
| 出力の最小化 | 返す内容は必要な項目だけか。出力が長大になっていないか | Chrome資料（出力サイズの目安） |
| 入力の検証 | executeの側で、コードによって入力を厳しく検証しているか | Chrome資料（Validate strictly in code, loosely in schema） |
| 確認が要る操作 | 購入・送金・予約確定など、取り消せない操作に確認の仕組みがあるか | 草案・Chrome資料と自社の考え方 |
| ログと保存期間 | 誰が・いつ・どのツールを呼んだかを追えるか。保存期間は決まっているか | 自社での一般的な考え方 |
| レート制限 | 短時間の大量呼び出しに、意味のあるエラーや案内を返せるか | Chrome資料（ベストプラクティス） |
| 変更管理 | ツールの追加・変更・削除が、記録され、レビューされているか | 自社での一般的な考え方 |
| 見直しの周期 | 点検の時期と担当者が決まっているか | 自社での一般的な考え方 |
以降の見出しで、各項目の確認の仕方を説明します。
公開範囲と権限：誰に見せ、何を許すか
公開範囲
Permissions Policy（ブラウザの機能を制御する仕組み）のtools機能で、アクセスが制御されます。既定は自オリジンです。他オリジンのiframeにツールを使わせるには、allow="tools"が必要です。ページ全体で無効にしたいときは、Permissions-Policy: tools=() が使えます。
ツールは既定で、登録したドキュメントと同一オリジンの文書、ブラウザ内蔵のエージェントから見えます。他のサイトやクロスオリジンのiframeには、既定では見えず、使えません。他オリジンへ見せる場合は、registerToolのoptionsにあるexposedToで明示します。安全なオリジンに限られます。
確認する点は次のとおりです。
- exposedToに入れたオリジンは、本当に信頼できる相手か。一覧を文書化しているか。
- 読み取り専用でも、利用者の情報が見えうることを理解しているか。Chrome資料は、共有してよい相手にだけ公開するよう述べています。
- 読み書きするツールは、利用者の代わりに動く信頼できるオリジンにだけ公開しているか。Chrome資料は、postCommentを一つの信頼するサイトにだけ公開する例を挙げています。
最小の権限と、読み取り・書き込みの分離
ここからは、自社での一般的な考え方です。ツールは、必要なデータと操作だけに触れるように作ります。一つのツールに検索も更新も持たせるより、読み取り専用のツールと、状態を変えるツールに分けるほうが、注釈も付けやすく、確認の要否も判断しやすくなります。Chrome資料のベストプラクティスも、1ツール1機能を勧めています。ツール設計の詳細はWebMCPのツール設計の記事にまとめています。
認証や権限の扱いについては、注意があります。W3Cの草案は、認証・Cookie・ログイン状態の扱いを規定していません。「ページ自身の実行環境で動く」までしか述べていません。一方、Chromeの資料は、WebMCPが「ライブのタブにある、ログイン中のセッション情報、Cookie、DOM要素にアクセスする」と述べています。両者の書き方に差があるため、ログイン状態に依存するツールは、慎重に設計する必要があります。詳しくは認証と権限の記事で扱います。
注釈・出力・入力：ツールの中身を点検する
注釈の付与
セキュリティに関わる注釈は三つあり、既定はいずれもfalseです。付けないと、確認や慎重な扱いの判断材料がクライアントに渡りません。
| 注釈 | 意味 | 確かめること |
|---|---|---|
| readOnlyHint | 状態を変えない。確認が要るかの判断材料になる | 本当に何も書き換えていないか。ログの書き込みなども含めて点検する |
| untrustedContentHint | 利用者生成や外部由来など、信頼できない可能性のある内容を返す | 口コミ、問い合わせ内容、外部データを返すツールに付けているか |
| consequentialHint | 予約・送金など、重大で取り消せない操作 | 該当する操作に付けているか。付けると、クライアントが確認を求められる |
注釈は、あくまでヒントです。草案は、宣言と実際の動作が一致する保証がないことを、リスクとして挙げています。たとえば、finalizeCartという名前のツールが、実際には購入まで行ってしまう例です。注釈と動作の食い違いは、自社のレビューで防ぐ必要があります。
出力の最小化
Chromeの安全性ガイダンスは、エージェントに見せる量の目安として、ツール名とパラメータ名は30文字、ツールの説明は500文字、パラメータの説明は150文字、ツールの出力は1.5K文字を挙げています。これは、ツールが渡す内容の上限の目安です。セキュリティ対策そのものとして示されたものではありません。
なお、草案の上限は名前128文字以内で、Chromeの目安と数値が異なります。草案の上限は仕様上の最大で、Chromeの資料は実質的に短く保つ目安を示している、と理解してください。短く書くほうが安全です。
出力に関する確認点は、返す項目が次の手を決めるのに必要な範囲か、内部IDや個人情報を不用意に含めていないか、の二つです。
個人情報を返しうるツールは、特に注意が必要です。草案は、過剰なパラメータによるプライバシー漏えい（「パーソナライズからフィンガープリントへ」）を懸念として挙げています。詳細は個人情報の扱いの記事にまとめています。プロンプトインジェクションへの備えはプロンプトインジェクションの記事を参照してください。
入力のサーバー側検証
Chromeのベストプラクティスには、「Validate strictly in code, loosely in schema（検証はコードで厳しく、スキーマでは緩く）」という一文があります。入力スキーマ（JSON Schema）を厳しくしすぎるとエージェントが止まりうるので、スキーマは緩めにし、厳しい検証はexecuteの中のコードで行う、という考え方です。草案も、execute側で入力を検証し、次の手が分かるエラーを返すことを勧めています。
ここで一点、注意があります。ブラウザ上のexecuteは、利用者の端末で動くJavaScriptです。ブラウザ側の検証だけでは、安全の根拠になりません。重要な検証は、呼び出される自社のサーバー側のAPIでも行ってください。これは自社での一般的な考え方であり、Chrome資料に書かれた指針ではありません。
確認が要る操作：人が止める場所を作る
consequentialHintを付けた操作は、クライアントが利用者の確認を求められます。ただし、草案の本文は確認を必須とは規定していません。Chromeの資料は、購入など重要な操作で、ユーザーに確認ダイアログを出す指示をツールに含められると述べています。ツールはページ上で見える形で実行されます。
ツール実行中に利用者へ非同期に入力を求めるrequestUserInteraction()が草案に含まれる、とChrome資料は書いています。ただし、命令型APIのページには記載がなく、consequentialHintとの関係も不明です。同意の管理は議論中と考え、確認の仕組みはクライアント任せにしないのが安全です。
自社での一般的な考え方としては、取り消せない操作の最終確定を、サイト自身の画面での利用者の操作に残す設計があります。たとえば、ツールは入力と確認画面の表示までを行い、確定ボタンは人が押す、といった形です。人が関わる使い方が前提という点は、Chromeの資料の想定とも合っています。詳しくは人の確認（ヒューマン・イン・ザ・ループ）の記事をご覧ください。
ログ・レート制限・変更管理：運用の項目
この章のうち、ログの保存期間や変更管理は、公式資料に具体的な指針がない領域で、自社での一般的な考え方です。レート制限と公開後のログ確認は、Chromeの資料が触れています。
ログと保存期間
ツールの呼び出しを後から追えるようにしておくと、問題が起きたときの調査と、改善の両方に役立ちます。Chromeの資料も、公開後はログを見て改善することを勧めています。
- 記録する項目の例：呼び出し時刻、ツール名、結果の状態、エラーの種類。入力や出力の中身をどこまで残すかは、慎重に決める。
- 入力や出力に個人情報が含まれうる場合、ログ自体が個人情報の保管になる。保存期間と閲覧できる人を決める。
- 保存期間や記録の範囲は、法令や社内規程に関わる。具体的な期間は、法務の担当者や専門家に確認する。
レート制限
Chromeのベストプラクティスは、レート制限に対して、意味のあるエラーか手動の案内を返すことを勧めています。エージェントは短時間に何度もツールを呼べるため、既存のAPIの制限が効いているかを確認してください。
変更管理と見直し
草案には、登録済みツールを更新する仕組み（updateTool）がなく、名前・説明・スキーマを変えるときは、登録解除してから再登録します。説明文の変更は、エージェントの振る舞いを変えるため、コードの変更と同じようにレビューの対象にするのが無難です。
見直しの周期は、機能を追加するたび、あるいは定期的に、などの形で決めます。周期は自社の更新頻度に合わせます。点検の観点はAIエージェント対応サイトのチェックリストも参考になります。
インシデント時の止め方
問題が見つかったとき、すぐ止められるかどうかを、公開前に確かめておきます。仕様から読み取れる止め方は、次のとおりです。
- 該当ツールの登録を解除する：registerToolに渡したsignal（AbortSignal）をabortすれば、登録が解除されます。Chrome 153以降は、実行中の処理を中断せずに解除できる、とChrome資料にあります。
- ページ全体で無効にする：Permissions-Policy: tools=() で、ページ全体のツール機能を無効にできます。
- 公開先を絞る：exposedToのオリジンを外すか、減らします。
これらを、すぐ実行できる形で用意してあるかが要点です。たとえば、設定の切り替えだけでツール登録を止められる設計にしておく、といった工夫が考えられます（自社での一般的な考え方）。
Chrome拡張がページ上でスクリプトを動かせる点
Chromeの安全性の資料は、host_permissionを持つChrome拡張は、WebMCPがなくてもページ上でスクリプトを動かせる、と述べています。つまり、WebMCPのツールを絞っても、拡張機能が持つ権限の問題は残ります。操作ごとの権限は、サーバー側で確認する設計が基本です（自社での一般的な考え方）。
注意点
- 仕様は変わります。W3Cの標準ではなくコミュニティグループの草案で、Chromeはオリジントライアルです。Edgeなど他のブラウザの対応時期は、確認できていません。
- このチェックリストは網羅ではありません。公式資料に具体的な指針がない項目は、自社での一般的な考え方です。公式の推奨ではありません。
- モデルの内側では安全を保証できません。Chrome資料の立場のとおり、サイト側の設計と運用で守る範囲を決める必要があります。
- 法務・セキュリティ・個人情報に関わる判断は、断定できません。ログの保存期間、個人情報の取り扱い、利用規約との関係などは、セキュリティの専門家や法務の担当者に確認してください。利用規約とボットの扱いは規約とボットの記事にまとめています。
- 導入の順序も大切です。段階的に進める考え方は導入ロードマップの記事をご覧ください。
Otsumuに相談できること
チェック表に沿った棚卸しは、社内で始められます。まず、公開予定のツールを書き出し、公開範囲、注釈、出力の内容を表の順に確かめてみてください。
一方で、確認の設計や、ログ・止め方の仕組みは、既存システムとの兼ね合いで難しくなりがちです。Otsumuは、AIファーストの事業再構築（事業の組み直し）を支援しており、その一環として、サイトをAIが使える形にする設計もご一緒できます。法務や専門的なセキュリティ監査は専門家の領域のため、必要に応じてそちらと連携します。
詳しくはAIエージェント開発をご覧ください。具体的なご相談は、お問い合わせからどうぞ。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。参照元は、W3C Web Machine Learning Community Group の仕様草案、WebMCPの提案リポジトリ、ChromeのWebMCP公式資料です。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20