この記事は、自社サイトにAIエージェント経由の利用が増えたときに、利用規約や運用ルールをどう整えるかを考える、事業責任者や法務担当、サイト運営の担当者に向けて書いています。読み終えると、規約で決めておきたい事項の一覧と、誰に何を相談すべきかが整理できます。
最初にお断りします。この記事は論点の整理であり、法的助言ではありません。法令名や判例、条文番号は扱いません。実際の規約の文面や法的な判断は、弁護士などの専門家に確認してください。また、題材のWebMCP（Webサイトが自分の機能を「ツール」としてブラウザ上のAIエージェントに公開する提案仕様）は草案の段階で、内容は変わり続けています。記事の内容は2026年10月20日時点の確認に基づきます。
WebMCPの全体像は、WebMCPの入門記事で扱っています。この記事は、その入門記事に続くシリーズの一部として、規約と運用の面を取り上げます。
エージェントからのアクセスは、何が従来と違うのか
これまでサイトへのアクセスは、大きく二種類に分けて考えられてきました。人がブラウザで見る操作と、プログラム（検索のための巡回やデータ収集など）が自動で行う操作です。規約や運用も、この二分法を前提に書かれていることが多いはずです。
AIエージェントが利用者の代理として操作する場合、この境目があいまいになります。操作しているのは自動化された仕組みですが、指示を出したのは人で、その人は自分のブラウザでサイトを開いています。規約が「自動化されたアクセス」を一律に禁じていると、利用者が自分の用事のためにエージェントを使うことまで禁止になるのか、という疑問が生じます。
この疑問に、この記事は答えを出しません。出せるのは、決めておくべき論点を並べるところまでです。結論は、自社の事業内容、扱う情報、リスクの許容度で変わり、最終的には専門家の判断が必要になります。
WebMCPで公開されるツールの位置づけ
規約を考える前に、WebMCPの仕組みの性質を確認しておきます。法的な評価ではなく、技術面の事実です。
- ツールはページ上にある：WebMCPのツールは、サイト自身がページ上で登録するものです。名前、自然言語の説明、入力スキーマ、実行する処理（JavaScript関数）で構成されます。サイトが公開を決めた機能だけが、エージェントから呼べます。
- ページが開いている間だけ存在する：Chromeの資料は、WebMCPを「一時的（タブに紐づく）」と説明し、ツールはページが開いている間だけ存在するとしています。バックグラウンドで常時動く仕組みとは性格が違います。
- 人が関わる使い方が主に想定されている：Chromeの資料は、ローカルのブラウザで人が関わる（human in the loop）使い方を主に想定すると述べています。草案も、人向けのUIが主役のままで、完全自律でUIなしの運用を想定したものではないとしています。
- 実行は見える形で行われる：草案の説明では、ツールはページ上で見える形で実行されます。フォームをツールにする方式でも、Chromeの資料によれば、フォームは利用者に見える状態のままです。
つまり、WebMCPで想定されているのは、利用者が自分のブラウザでページを開き、その上でエージェントがサイトの用意したツールを使う場面です。誰かが見えないところで大量に巡回する形とは、技術的な前提が異なります。ただし、これは仕様の想定であって、実際の利用がすべてその想定に収まる保証はありません。
また、ログイン状態の扱いは、情報源によって書き方が違います。W3Cの草案は、認証やCookieの扱いを規定していません。一方、Chromeの資料は、WebMCPがライブのタブにあるログイン中のセッション情報やCookie、DOM要素にアクセスすると説明しています。この違いは、規約上の「誰の操作か」を考えるうえでも重要です。認証の詳細は、認証と権限の記事で扱っています。
スクレイピング、API、WebMCPの違い
規約を検討するときに、混同しやすいのが、似た言葉で呼ばれる複数の仕組みです。技術的な性格の違いを、次の表にまとめます。法的な扱いの違いを示す表ではありません。
| 方式 | サイトの関与 | 技術的な特徴 |
|---|---|---|
| スクレイピング | サイトが用意していない形で、画面の内容を読み取る | DOM（画面の構造）を読む。画面の変更に弱い |
| API | サイトが、外部のプログラム向けに窓口を用意する | サーバー側の接続。認証や利用条件を別途定めることが多い |
| WebMCP | サイトが、ブラウザ上のエージェント向けにツールを公開する | ページ上で動き、タブが開いている間だけ存在する |
WebMCPでは、エージェントはDOMのスクレイピングやクリックの代わりに、サイトが用意したツールを呼びます。サイト側が「この操作は受け付ける」と宣言し、入力の形を定めている点が、サイトの意図しない読み取りとの大きな違いです。
ただし、WebMCPはバックエンド連携の代わりではなく、その補完です。サーバー側でAPIを提供している場合、それを置き換えるものではありません。両者の使い分けは、WebMCPとAPI、RPA、スクレイピングの比較記事で整理しています。
なお、ここで述べた違いは技術的な性格です。「どの方式なら許されるか」「自社の規約上どう扱うか」は、法的な判断を含みます。この点は、弁護士に確認してください。
規約で決めておきたい事項
以下は、検討の出発点になる論点です。すべてを規約に書くべきだという意味ではありません。運用で決める事項、別の文書に書く事項もあります。
代理操作を認めるか
利用者がエージェントに指示して、自分のアカウントで操作させることを、認めるのか、条件つきで認めるのか、認めないのか。まずここを決めないと、他の項目が決まりません。認める場合も、サイトが公開したツールを通す操作だけを想定するのか、画面を直接操作する方式まで含めるのかで、書き方が変わります。
自動化の範囲
どこまでの自動化を想定するか。たとえば、照会のような読み取りだけを許すのか、予約や購入のような変更を伴う操作も含めるのか。WebMCPのツールには、読み取りのみを示すreadOnlyHint、実世界への影響や取り消せない操作を示すconsequentialHintという注釈があります。ツールの設計上の区分と、規約上の区分を揃えておくと、説明しやすくなります。
責任分界
エージェントが行った操作の結果について、サイト運営者、利用者、エージェントを提供する事業者が、それぞれどこまで責任を負うのか。この線引きは、契約や消費者保護に関わる難しい論点です。この記事では線の引き方を示しません。専門家と相談して、自社の事業に合わせて決める事項です。
誤操作の扱い
エージェントが利用者の意図と違う操作をしたとき、取り消しや訂正を受け付けるのか。どの段階までなら取り消せるのか。草案は、ツール実行時のユーザー確認を必須とは規定していません。クライアントが重要な操作の前に確認を出せる、という位置づけです。つまり、確認の仕組みはサイト側でも考える必要があります。確認の設計は、人が確認する設計の記事が参考になります。
禁止行為
エージェントの利用に限らず、禁止したい行為を明確にしておきます。たとえば、サイトに過度な負荷をかける操作、他人のアカウントを使った操作、公開していない機能への不正なアクセスなどです。どの行為を禁止するかは、自社の事業と運用に合わせて決めます。具体的な文言は、専門家に確認してください。
公開するツールの範囲の明示
サイトが公開しているツールの一覧や、その使い方の注意を、利用者向けのページで説明するかどうか。ツールの説明文はエージェントが読むものですが、人が読める形の案内があると、運用上の問い合わせに答えやすくなります。ツールの作り方は、ツール設計の記事で扱っています。
robots.txtや利用条件との関係
robots.txtは、巡回するプログラム向けに、サイトの側が意思を示す慣習的な仕組みです。ここでは一般論だけを述べます。
- robots.txtや既存の利用条件は、WebMCPの登場以前から、プログラムによるアクセスを想定して作られてきました。
- WebMCPのツール公開は、サイトが自ら機能を差し出す行為であり、既存の巡回向けの意思表示とは別の層の話です。
- 既存の文書が、ブラウザ上でエージェントが動く場面を想定しているかどうかは、文面を読み直して確かめる必要があります。
検索エンジンや各種の巡回プログラムがrobots.txtをどう扱うかは、この記事の確認範囲の外で、断定できません。また、WebMCPの仕様が、robots.txtや利用条件との関係を定めているかどうかも、確認できていません。既存の文書との整合は、自社で見直す必要があります。
WebMCPの側で用意されている制御としては、Permissions Policyのtools機能があります。既定では自オリジンのみで、他オリジンのiframeにはallow="tools"が必要です。Permissions-Policy: tools=() を指定すれば、ページ全体でツールの公開を無効にできます。これは技術的な制御であり、規約の代わりにはなりません。技術と規約の両方で、意思を示すのが現実的です。
ありがちな失敗と、進め方の例
ありがちな失敗
- 既存の規約を読み直さない：「自動化されたアクセスの禁止」のような一文が、エージェント経由の利用まで禁じる書き方になっていないか、点検されないまま残る。
- 技術と規約が食い違う：規約では代理操作を認めないのに、ツールは広く公開している。逆に、規約は認めているのに、技術的には遮断している。
- 責任の所在が曖昧なまま公開する：誤操作が起きたときの窓口や取り消しの手順を決めずに、変更を伴うツールを出す。
- 一度決めて放置する：WebMCPは草案段階で変わり続けます。規約や運用の見直しの時期を決めていない。
- 法務と開発が別々に動く：ツールの設計と規約の検討が接点なく進み、実態と文面にずれが生じる。
特に、技術と規約の食い違いは、後から直すのが面倒です。ツールを公開する前に、一度、開発と法務の担当者が同じ表を見て、公開するツールと規約上の扱いを突き合わせておくと、ずれに気づきやすくなります。
架空の例：予約サイトの場合
以下はすべて架空の例で、実在のサイトとは関係ありません。教室の予約サイトが、WebMCPで予約状況の照会と予約の申し込みのツールを公開すると仮定します。
| 検討項目 | 考え方の例 |
|---|---|
| 代理操作 | ログインした利用者本人の指示によるものに限る、と整理する案 |
| 自動化の範囲 | 空き状況の照会は広く、予約の申し込みは確認を挟む前提とする案 |
| 誤操作 | 予約の取り消しを、確認の画面と合わせて案内する案 |
| 禁止行為 | 他人名義での申し込みや、過度な負荷をかける操作を禁じる案 |
| 見直し | ツールを増減するたびに、規約との整合を点検する案 |
これは考え方の一例であり、推奨する規約の内容ではありません。実際には、事業の性質や利用者の属性で、必要な項目は大きく変わります。
社内での進め方
- 現状の棚卸し：既存の利用規約、プライバシーに関する文書、サイトの案内にある、自動化やプログラムによるアクセスに触れた箇所を洗い出す。
- 公開するツールの整理：どの機能を公開する予定か、読み取りか変更を伴うかを一覧にする。
- 論点の突き合わせ：この記事の論点と、一覧を照らし、決めるべき事項に印を付ける。
- 専門家への相談：弁護士に、整理した論点と公開予定の機能を見せて、文面と運用について助言を受ける。
- 段階的な公開：リスクの低いものから公開し、運用しながら規約と設計を直す。
段階の進め方は、導入ロードマップの記事で扱っています。公開前の点検項目は、AIエージェント対応サイトのチェックリストにもまとめています。
注意点
- この記事は法的助言ではありません。規約の文面、責任の分担、個人情報の扱い、各種の規制との関係は、弁護士などの専門家に確認してください。
- 仕様は変わります。W3Cのコミュニティグループの草案は、W3Cの標準ではありません。Chromeの資料も、議論の最中で変更される可能性があると明記しています。
- 対応状況は限られます。Chromeではオリジントライアルとして提供されています。Edgeなど他のブラウザの対応時期は、確認できていません。
- 安全面の限界があります。草案とChromeの資料は、プロンプトインジェクションなどのリスクを挙げ、LLMの内側で安全を保証することはできないとしています。規約だけで防げるものではありません。
- 同意の仕組みは議論中です。ユーザー確認の標準化は、未解決の課題とされています。
Otsumuに相談できること
規約の文面づくりは法務や弁護士の領域で、Otsumuが代わりに行えるものではありません。一方で、論点を整理するための材料づくりは、ご一緒できます。公開したい機能の棚卸し、読み取りと変更を伴う操作の仕分け、確認の画面の設計などです。それらを弁護士に見せられる形にしておくと、相談がスムーズに進みます。
Otsumuは、AIファーストの事業再構築（事業の組み直し）を支援しています。その一環として、サイトを「AIが使える形」にする設計も扱っています。詳しくはAIエージェント開発をご覧ください。具体的なご相談は、お問い合わせからどうぞ。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。内容は論点の整理であり、法的助言ではありません。参照元は、W3C Web Machine Learning Community Group の仕様草案、WebMCPの提案リポジトリ、ChromeのWebMCP公式資料です。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20