この記事は、自社サイトにログイン機能や会員向けの機能があり、それをWebMCPで公開してよいか迷っている方に向けて書いています。Webの責任者、情報システム担当、開発を発注する立場の方を想定しています。読み終えるころには、どの機能をAIに見せ、どの機能は見せないかを、自社で判断するための考え方がつかめます。
先にお断りします。WebMCPは、W3Cのコミュニティグループが進める草案（2026年10月16日付）で、W3Cの標準ではありません。内容は変わり続けています。この記事は、草案とChromeの公式資料で確認できた範囲だけを書き、分からないことは「分からない」と書きます。WebMCPの全体像は、WebMCPとAIエージェント対応サイトの解説で先に整理しています。
まず押さえる前提：ツールはページの中で動く
草案では、WebMCPのツールは、サイトのページ自身の実行環境で動きます。ツールとは、名前・説明・入力の形・実行する処理（JavaScriptの関数）をまとめたものです。ブラウザ上のAIエージェントが、画面操作の代わりにこの関数を呼びます。
ここで大事なのは、ツールが「サイトの外側にある別の窓口」ではない点です。ページの中で動く関数なので、そのページが持っている情報や、その時点の画面の状態と、切り離せません。だからこそ、権限の話は最初に決めておく必要があります。
認証の方式は、仕様が決めていない
一番よくある疑問は「ログインした人の機能を、AIはどう使うのか」です。結論から言うと、草案は認証の方式を定めていません。草案が述べているのは、ツールがページ自身の実行環境で動く、というところまでです。ログイン状態やCookieの扱いを、仕様が決めているとは言えません。一方、Chromeの資料（MCPとの比較のページ）は、WebMCPが「ライブのタブにある、ログイン中のセッション情報、Cookie、DOM要素にアクセスする」と述べています。
そのため、実務では次のように考えるのが安全です。
- 認証と認可（誰に何を許すか）は、サイトが今持っている仕組みに任せる
- ツールの中で、既存の権限チェックを毎回通す設計にする
- 「AIだから特別に許す」という近道を作らない
つまり、ツールは新しい権限を生むものではありません。ログインしている利用者に許された範囲を、AIが代わりに操作できるようにするだけ、という位置づけで設計します。権限の判定は、ブラウザ側の画面表示ではなく、サーバー側の処理で行うのが基本です。これはWebMCPに限らない、Webの一般的な心得です。
よくある誤解を二つ
一つ目は「WebMCPを入れれば、ログインの仕組みも用意される」という誤解です。草案はそこまで定めていません。二つ目は「注釈を付ければ、AIが勝手に危ない操作をしなくなる」という誤解です。注釈は、クライアント（AIを動かす側のソフト）が確認を出す手がかりになりますが、動作の保証ではありません。どちらも、サイト側の設計で補う部分です。
オリジンの考え方：既定は自分だけに見せる
オリジンとは、「https://example.com」のように、プロトコル・ドメイン・ポート番号の組み合わせで決まる、Webの安全の単位です。草案の考え方を整理すると、次のとおりです。
| 項目 | 草案とChrome資料の内容 |
|---|---|
| 窓口 | document.modelContext。HTTPSなどの安全な接続（SecureContext）が必要 |
| 既定の見え方 | 登録したページと同じオリジンの文書、ブラウザ内蔵のエージェントから見える |
| 他オリジンへ見せる | 登録時のexposedToで、公開先を明示する。安全なオリジンのみ |
| 他オリジンからの探り | 存在しないツールでもNotFoundErrorを返し、探られにくくしている |
要するに、何も書かなければ自分のオリジンの中だけ、他に見せたいなら名前を挙げて明示する、という作りです。「全員に開く」が既定ではない点は、設計する側にとって助かります。
一方で、草案は「同一オリジンの境界」自体もリスクとして挙げています。同じオリジンの中なら、同じページの他のスクリプトも同じ関数に触れうる、という意味に読めます（筆者の解釈です）。外部の広告タグや計測タグを多く入れているサイトは、そこも見直しの対象です。
Permissions Policyのtools機能で、公開範囲を絞る
Permissions Policy（ブラウザの機能を、ページやiframe単位で許可・禁止する仕組み）には、WebMCP用のtools機能があります。草案とChrome資料の内容は次のとおりです。
- 既定は自オリジン（'self'）のみ
- 他オリジンのiframeにツールを使わせるには、iframeにallow="tools"が必要
- Permissions-Policy: tools=() というヘッダーで、そのページ全体のツールを無効にできる
たとえば、決済画面や管理画面のように「AIに触らせたくないページ」では、このヘッダーで無効にする、という使い方が考えられます。また、外部の埋め込み（iframe）にツールの利用を許す場合は、本当に必要かを一件ずつ確認してください。
最小権限：ツールごとに、許す範囲を決める
最小権限とは、必要な範囲だけを許す、という原則です。WebMCPでは、ツール一つひとつに対して適用します。草案には、ツールの性質を伝える注釈（annotations）があります。読み取りだけならreadOnlyHint、返す内容が信頼できない可能性があるならuntrustedContentHint、取り消せない操作ならconsequentialHintです。いずれも既定はfalseです。
これらは宣言であり、動作の保証ではありません。草案も、宣言と実際の動作が一致する保証がない（意図の偽装）ことを、リスクとして認めています。注釈を付けるだけで安心せず、ツールの中身で権限を確かめてください。確認の出し方は人が確認する設計（ヒューマン・イン・ザ・ループ）の記事で扱っています。
権限別に、ツールを出し分ける考え方
ログイン前、一般会員、管理者のように、利用者の立場で使える機能は違います。ツールも同じ考え方で、立場に合うものだけを登録する方法があります。草案には、ツール数がモデルの文脈量に制約されるため、動的な登録が勧められている、という記述があります。立場が変わったら登録を解除し、必要なものだけを登録し直す、という運用になります。なお、草案にはツールの内容を更新する機能（updateTool）がなく、変更するなら解除して再登録する形です。
次の表は、考え方の一例です。架空の例として、会員制の予約サイトを想定しています。
| 利用者の状態 | 登録を考えるツール（架空の例） | 見せないもの |
|---|---|---|
| ログイン前 | 空き状況の検索（読み取りのみ） | 会員情報、予約の変更 |
| ログイン済みの会員 | 自分の予約の確認、変更の下書き | 他の会員の情報、管理機能 |
| 管理者 | 必要な管理機能のうち、読み取り中心のもの | 削除など取り消せない操作は、人の確認を必須にする運用を検討 |
ただし、ツールを出し分けても、サーバー側の権限チェックは省けません。出し分けは「入口を絞る」工夫で、守りの本体ではありません。
架空の例：会員向けの見積もりツール
架空の例として、ある設備会社の会員サイトを考えます。会員は、ログイン後に、自社の過去の見積もりを一覧できます。この一覧をツールにする場合、次の順で考えます。
- ツールの目的を「ログイン中の会員自身の見積もり一覧を返す」と一文で決める
- 入力には、会員番号を受け取らない（他人の番号を入れられてしまうため）
- サーバー側で、ログイン中の会員に紐づく見積もりだけを取り出す
- 返す項目は、画面で見せているものの範囲に絞る
- 読み取りのみなので、readOnlyHintを付ける
ポイントは、「誰の情報か」をAIの入力に頼らず、サーバーが持つログイン状態から決めることです。AIが渡す入力は、悪意ある指示が混ざる可能性もあるため、権限の根拠にはしません。
他オリジンへ見せる前の確認項目
exposedToで他オリジンに公開する前に、次の点を確認してください。どれも、草案が挙げるリスクから導いた確認事項です。
- その公開先は、自社または契約関係のある、安全なオリジンか
- 見せるツールは、読み取りのみのものに限っているか
- 返す内容に、個人情報や社内情報が混ざらないか（過剰な情報は、利用者の特定につながるおそれがある）
- 入力の長さや形を、実行側でも検証しているか
- 公開先で問題が起きたとき、すぐに登録を解除できるか
実行側での入力検証と、次の手が分かるエラーの返し方は、ツール設計の記事で詳しく扱っています。
導入前のチェック項目
最後に、権限まわりのチェック項目をまとめます。社内の確認会にそのまま使えます。サイト全体の準備状況は、AIエージェント対応サイトのチェックリストも参照してください。
- どの機能を公開するか、機能ごとに一覧にしたか
- 各機能に、サーバー側の認証・認可チェックがあるか
- 読み取りと、書き込み・取り消せない操作を分けて考えたか
- 注釈（readOnlyHintなど）を付けた上で、中身でも確認しているか
- Permissions Policyで、公開範囲を明示したか
- 外部タグや埋め込みが、同じオリジンで動いていないか確認したか
- プロンプトインジェクション（ツールの説明・入力・出力に紛れる悪意ある指示）を想定した確認をしたか
注意しておきたいこと
草案には、まだ解決していない課題が残っています。ユーザー確認の標準化は未解決で、ツール実行時の確認を必須とする規定も、草案の本文にはありません。確認を出すかどうかは、クライアント側に委ねられています。また、宣言を検証する手段がなく、サイトの善意を前提にしている点も、現状の限界です。
Edgeなど他のブラウザの対応時期は、公式な確認が取れていません。ChromeはChrome 149からオリジントライアルとして提供されていますが、仕様も実装も変わりうるため、本番の重要な機能は、まず読み取り中心の小さな範囲から試すのが無理のない進め方です。
Otsumuに相談できること
公開する機能の棚卸しや、読み取りと書き込みの切り分けは、自社だけでも始められます。まずは上のチェック項目を、機能ごとに埋めてみてください。
一方で、既存の認証の仕組みとの接続や、権限別のツール設計は、サイトの作りによって難しさが変わります。Otsumuは、AIを前提に事業の構造や業務を組み直す「AIファーストの事業再構築」を支援しています。その一環として、AIエージェント開発で、安全に公開する範囲の設計から実装までをお手伝いできます。
設計の見直しや、進め方の相談は、お問い合わせからご連絡ください。
この記事について
Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。参照元：WebMCP 仕様草案（W3C Web Machine Learning Community Group）、Chrome for Developers：WebMCP。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20