WebMCPと個人情報：同意・最小化・取り扱いの考え方

この記事は、自社サイトにWebMCP（Webサイトが自分の機能を「ツール」としてブラウザ上のAIエージェントに公開する提案仕様）を載せようとしている、事業責任者や担当者に向けて書いています。ツールが氏名・住所・注文履歴のような個人情報に触れるとき、設計の段階で何に気をつけるかを整理します。読み終えると、社内の法務や情報システムの担当者と話すための論点を、自分で並べられるようになります。

先にお断りします。WebMCPは草案の段階で、内容が変わり続けています。この記事の内容は2026年10月20日時点の確認に基づきます。また、個人情報の扱いは法令や業種によって求められることが異なります。この記事は一般的な考え方の整理であり、法的な助言ではありません。適用される法令の確認は、専門家に依頼してください。

WebMCPの全体像はWebMCPの入門記事で扱っています。この記事は、そのシリーズの一部です。

個人情報が、ツールのどこに現れるか

WebMCPのツールは、名前・説明・入力スキーマ（入力項目の定義）・実行する処理で構成されます。個人情報が入り込む場所は、大きく四つあります。

• 入力：エージェントが、利用者に代わって氏名や連絡先をツールに渡す場合。
• 出力：ツールが、注文履歴やプロフィールのような情報を返す場合。返した内容は、エージェントを動かす側に渡ります。
• ログ：呼び出しの記録に、入力や出力がそのまま残る場合。
• 画面：フォームに入力された内容が、画面上に表示される場合。

Chromeの資料が挙げる使いどころには、勤怠や中古車検索、保証請求、ケータリングの問い合わせといった長いフォームの入力があります。こうした場面は便利である反面、入力項目が多く、個人情報が集まりやすい場面でもあります。便利さと扱う情報量は、セットで考える必要があります。

仕様の草案も、過剰なパラメータによるプライバシー漏えいをリスクとして挙げています。「パーソナライズからフィンガープリントへ」という表現で、便利のための情報が、利用者を特定する手がかりに変わりうる点を指摘しています。

最小化：必要な項目だけを、入力にも出力にも

最初の原則は、扱う情報を減らすことです。これは草案やChromeの資料に具体的な手順があるわけではなく、自社での一般的な考え方です。

入力を絞る

ツールの入力に、目的に要らない項目を入れないでください。たとえば、在庫の照会に氏名は要りません。入力項目が少なければ、エージェントが余計な情報を集めて渡すことも減ります。

出力に含めない

出力のほうが見落とされがちです。ツールが返す内容は、そのままエージェントに渡ります。注文の状況を知りたいだけなのに、住所や電話番号まで返す必要はありません。「状況」と「到着予定」だけを返せば足りることは多いはずです。Chromeの資料は、安全性の面で、ツールの出力の量を抑える目安を示しています（出力は1.5K文字が目安として挙げられています。個人情報の対策として示されたものではなく、渡す内容の上限の目安です）。

上の表の場面は、説明のための架空の例です。実在のサイトや実績とは関係ありません。

誰の情報かは、AIの入力でなく、サーバー側で決める

ここは設計の肝です。たとえば「注文履歴を返すツール」に、顧客IDを入力として渡す設計を考えてみます。エージェントが別のIDを渡せば、他人の注文履歴が返ってしまうかもしれません。

これを避けるには、「誰の情報か」を入力で受け取らず、サーバー側のセッション（ログイン中の利用者を識別する仕組み）で決めます。ツールが受け取るのは「直近の注文を見せて」のような中身だけにして、対象の利用者は、サーバーが自分で判断します。権限の考え方は、認証と権限の記事で詳しく扱っています。

認証やCookieの扱いは、資料によって書き方が違うので、両方を書き分けます。

• W3Cコミュニティグループの草案は、ツールが「ページ自身の実行環境で動く」ところまでを述べています。認証やCookieの扱いを、仕様として定めてはいません。
• Chromeの資料は、WebMCPが「ライブのタブにある、ログイン中のセッション情報、Cookie、DOM要素にアクセスする」と述べています。

つまり、ログイン中の利用者の情報に触れうる設計になりえます。だからこそ、「誰の情報か」をサーバー側で確実に絞る設計が大切です。入力の検証についても、Chromeの資料にある「検証はコードで厳しく、スキーマでは緩く」の考え方が参考になります。スキーマで細かく縛るのではなく、実行する処理の側で、厳しく確かめます。詳しくはツール設計の記事をご覧ください。

同意と確認：利用目的を示し、人が確かめる

個人情報を扱う操作では、利用者が何のために情報が使われるのかを分かる状態にしておくことが大切です。

• 利用目的を示す：情報を入力させる前に、何に使うのかを画面で示す。これは自社での一般的な考え方で、エージェントを介した場合にも、通常の画面操作と同じ水準で示す方向で検討する。
• 人が確認する：送信や確定のような操作の前に、人が内容を確かめられるようにする。

仕様の草案は、ツール実行時のユーザー確認を必須とは定めていません。クライアント（エージェントを動かす側）が、重要な操作の前に確認を出せる、という位置づけです。確認の標準的な仕組みは議論中で、草案には未解決の課題として残っています。そのため、確認が自動で入る前提で設計せず、自社の側でも用意するのが現実的です。

手がかりとして、草案にはconsequentialHintという注釈があります。実世界への影響が大きい、取り消しにくい操作を示すもので、クライアントは、これを使って確認を求められます。Chromeの資料も、購入のような重要な操作では、確認ダイアログを出す指示を含められると述べています。一方、宣言的APIでは、フォームの送信は、既定では利用者が送信ボタンを押して完了します。自動送信を許す属性もありますが、個人情報を伴うフォームでは、安易に使わないほうがよいでしょう。人の確認の設計は、人の確認の記事にまとめています。

ログ：個人情報を残さない、残すなら期間を決める

運用で最も起きやすい問題が、ログです。ツールの呼び出しを記録しておくと、不具合の調査や改善に役立ちます。しかし、入力や出力をそのまま保存すると、個人情報がログの中に溜まっていきます。

• 入力と出力を、そのまま保存しない。呼び出したツール名、時刻、成功か失敗かのような、個人を特定しない情報にとどめる。
• 残す場合は、伏せる。氏名や連絡先は、記録する前に除くか、置き換える。
• 保存期間を決める。何のために、どのくらいの期間残すのかを、あらかじめ決めておく。
• 見られる人を絞る。ログを閲覧できる担当者を限定する。

これらは自社での一般的な考え方です。具体的な保存期間やログの扱いは、適用される法令や社内規程によって変わります。専門家に確認してください。

エージェントを動かす側にも、データが渡る

見落としやすい点です。ツールの出力は、エージェントに渡ります。Chromeの資料はWebMCPのクライアントをブラウザ内蔵のエージェントとしていますが、そのエージェントが外部のAIサービスを使って動いている場合があります。その場合、ツールが返した個人情報が、外部のサービスに渡る可能性があります。

ただし、どのエージェントが、どこへデータを送るかは、自社では決められません。草案や資料にも、そこまでは書かれていません。ですから、次のような確認が必要です。

• 自社のプライバシーポリシーや利用規約に、AIエージェントが情報を扱う場合のことをどう書くか。
• 利用者に対して、情報が外部のサービスに渡りうることを、どう伝えるか。
• 外部に渡してよい情報と、渡さない情報の線引きを、どこに置くか。

こうした文面の確認は、法務の専門家に依頼してください。サイトの利用条件とボットの関係は、利用規約とボットの記事でも扱います。

出力に悪意ある指示が紛れ込むプロンプトインジェクションの危険も、別途あります。ユーザーが書いた内容を返すツールには、untrustedContentHintという注釈を付けられます。詳しくはプロンプトインジェクションの記事をご覧ください。

よくある失敗

ここまでの内容を、失敗の形で振り返ります。

1. 出力に全項目を入れる：手元の関数の戻り値をそのまま返してしまい、不要な個人情報まで渡る。
2. 顧客IDを入力で受け取る：他人の情報を呼べる余地が生まれる。
3. ログに入出力を丸ごと保存する：調査のつもりが、個人情報の蓄積になる。
4. 確認を省く：確定や送信を、人が確かめないまま実行できる設計にする。
5. 外部への受け渡しを考えない：プライバシーポリシーが、実態と合わなくなる。
6. 公開してから見直さない：機能追加で出力項目が増えても、点検しない。

公開前の点検は、AIエージェント対応サイトのチェックリストと併せて行うと、抜け漏れが減ります。段階的に進める考え方は、導入ロードマップの記事にまとめています。

注意点

• 仕様は変わります。WebMCPはW3Cの標準ではなく、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