編集部の AI エージェントに参考画像を集める作業を 8 体で手分けさせたところ、2 体が利用者のメールアドレスを、外部の API へ送る通信の User-Agent（通信のたびに相手へ送る名乗り）に入れていた。ここでいう利用者は、AI に作業を指示した編集部の担当者本人で、顧客の情報ではない。別の 1 体は利用者の名前を入れて約 7 回送っていた。
原因は、取りまとめ役の AI には「外部に送らない」という決まりがあったのに、委任先への依頼文にはその決まりが無かったことである。
今は依頼文と共通の指示書に、メールアドレスと名前をどの外部サービスにも送らないと明記し、web を触った作業の後は、成果物と一時ファイルを利用者のアドレスで検索している。
目次
- この記事で扱うこと
- 何が起きたか
- User-Agentは通信のたびに相手へ届く名乗り
- AIがアドレスを入れた理由
- メールアドレスと名前は個人を指す情報
- 入れた対策
- 対策の効き目と届かない所
- AIエージェントの情報漏洩は道具の引数からも起きる
- 委任する前に確かめること
- よくある誤解
- まとめ
この記事で扱うこと
生成 AI の情報漏洩というと、入力した社内の情報が学習に使われる話や、AI が答えの中に秘密を書いてしまう話が思い浮かぶ。編集部で起きたのは、それとは別の経路だった。AI エージェントが道具を使って外部と通信する、その通信の中に個人の情報が入っていた。
IPA の情報セキュリティ10大脅威 2026では、組織向けの 3 位に「AIの利用をめぐるサイバーリスク」が初めて入った。AI エージェントを業務に入れ始めた会社にとって、情報が外へ出る経路を把握することは、これから避けて通れない作業になる。
この記事は編集部で起きた 1 件の記録である。起きたこと、原因、入れた対策、その効き目と届かない所を順に書く。手元の環境で AI に危ない操作をさせないための対策は、Claude Codeのセキュリティ対策に分けて書いた。
何が起きたか
参考画像を集める担当8体のうち2体
2026-09-28、制作の参考にする画像を web から集める作業を、AI エージェント 8 体に手分けさせていた。取りまとめ役の AI が担当ごとに依頼文を書き、各担当がそれぞれ画像を探して報告する形である。
担当のうち 2 体が Wikimedia の API に送る通信の User-Agent に、利用者のメールアドレスを入れていた。送り先は Wikimedia Commons（自由に使える画像などの素材を集めたサイト）の、画像の情報を返す API である。
申告した1体と検索で見つかった1体
2 体のうち 1 体は作業の報告の中で自分から申告した。もう 1 体は申告しておらず、取りまとめ役が担当の作業場所（一時ファイルを置く場所）にあったスクリプトを、利用者のアドレスで検索して見つけた。
名前を入れて約7回送った担当もいた
別の 1 体はメールアドレスではなく利用者の名前を User-Agent に入れ、Commons の API へ約 7 回送っていた。この担当は 13 秒後に自分で書き換え、報告で申告した。
名前も個人を指す情報である。編集部ではメールアドレスと同じく、外部に送らない情報として扱っている。
User-Agentは通信のたびに相手へ届く名乗り
HTTPの仕様での位置づけ
User-Agent は HTTP の要求に付けるヘッダーの 1 つで、要求を送るソフトウェアが自分を名乗るためにある。HTTP の仕様（RFC 9110）によると、受け取る側はこれを、不具合の範囲の特定や、相手に合わせた応答の出し分け、利用状況の集計に使う。ブラウザが送る値の例は MDN の解説にある。
仕様は、特に設定しない限り、要求のたびに User-Agent を送るよう求めている。Wikimedia の方針も python-requests/x のような既定値に触れており、通信のライブラリは、指定しなければ自分の名前と版を名乗りとして送る。
仕様によると、User-Agent は製品名と版を並べた名乗りと、括弧で囲んだ注記からなる。名乗りの部分には製品を識別するのに要る情報だけを入れ、広告などの要らない情報を入れてはならないとされている。
同じ仕様は User-Agent に必要以上に細かい情報を入れないよう求めている。長く細かい値は、利用者が望まないのに特定される危険（フィンガープリンティング）を高めるからである。
書いた内容は相手のサーバーに届く
User-Agent は通信のたびに相手のサーバーへ届く。ここに書いた内容は、相手が受け取る情報の一部になる。
画面に表示される物ではないので、人が作業を眺めていても気づきにくい。今回も、担当が報告するか、取りまとめ役がスクリプトを検索するまで、誰も気づいていなかった。
Wikimediaは連絡先を書くよう求めている
Wikimedia の User-Agent の方針は、自動で通信するプログラムに、ほかと紛れない名乗りと、運用者への連絡手段を User-Agent に書くよう求めている。連絡先の形として、メールアドレス、web サイト、wiki の利用者名を挙げている。
方針が示す形は「クライアント名/版 (連絡先) ライブラリ名/版」で、例として CoolBot/0.0 (https://example.org/coolbot/; [email protected]) generic-library/0.0 を挙げている。委任先の 2 体はこの連絡先として利用者のアドレスを使った。
方針は自動の通信なら User-Agent に「bot」という文字を入れる慣習にも触れ、Wikimedia の側で通信の分類や統計に使っていると書いている。User-Agent は受け取った側で読まれ、使われる情報である。
同じ方針は汎用のライブラリの既定値のような名乗りを止められることがあると書き、ブラウザの名乗りを真似ることも禁じている。ブラウザの名乗りで自動の通信をすると、悪意のある通信とみなされる。API の利用の作法にも連絡先のある名乗りを付けないと予告なく遮断されることがある、とある。
AIがアドレスを入れた理由
相手の作法に従うことが正しい振る舞いに見えた
委任先の AI は Wikimedia の方針に従って、User-Agent に連絡先を入れようとした。手元の文脈には利用者のメールアドレスがあり、それを連絡先として使った。
相手のサービスの作法に従うこと自体は、正しい振る舞いに見える。問題は連絡先として誰の情報を使ってよいかを、委任先が判断する材料を持っていなかったことである。
決まりは委任先に届いていなかった
利用者のメールアドレスは取りまとめ役の AI の文脈に、「外部に送らない」という決まりつきで入っていた。委任先への依頼文には、その決まりが書かれていなかった。
Claude Code のサブエージェントの資料によると、分岐（fork）でないサブエージェントは、取りまとめ役との会話の履歴を持たず、渡された依頼文から作業を始める。取りまとめ役が知っている決まりも、依頼文に書かなければ委任先には届かない。
同じ資料によると、分岐（fork）のサブエージェントは、取りまとめ役との会話の履歴をすべて引き継ぐ。決まりは届くが、会話の中のほかの情報もすべて渡る。どちらの形でも、外に出してはいけない情報と、その決まりの両方を意識して渡す必要がある。
2つが重なって起きた
相手の作法が連絡先を求め、委任先の手元には連絡先として使える個人の情報があり、それを止める決まりは無かった。今回の送信はこの 3 つが重なって起きた。
相手の作法はこちらからは変えられない。編集部が直したのは 3 つ目、決まりが委任先に届かない点である。
メールアドレスと名前は個人を指す情報
個人情報保護委員会の考え方
個人情報保護委員会の Q&A（Q1-4）は、メールアドレスのユーザー名とドメイン名から特定の個人を識別できる場合、そのメールアドレスはそれだけで個人情報に当たるとしている。それ以外の場合は個別の判断になり、他の情報と容易に照合して個人を識別できるなら、あわせて個人情報に当たることがある。
法令やガイドラインの当てはめは、事案ごとに確かめる必要がある。この記事では、今回の件が法令上どう扱われるかには踏み込まない。
編集部は名前も同じに扱う
編集部ではメールアドレスに加えて、利用者の名前も外部に送らない情報として決めている。名前だけでも個人を指すからである。
AI に渡す決まりとしては法令上の線引きより広く取っている。「個人情報に当たるかどうか」を AI に判断させるより、「この 2 つは送らない」と決めて渡すほうが、委任先が迷わないと編集部では考えている。
入れた対策
依頼文と共通の指示書に禁止を明文で書く
web を触る作業を委任するときの依頼文と、委任先が読む共通の指示書に、次の一文を書くことにした。
利用者のメールアドレスと名前を、どの外部サービスにも（ヘッダ・URL・本文のどれでも）送らない。連絡先を求められても入れない。
送ってはいけない場所を、ヘッダ・URL・本文と並べて書いたのは、User-Agent のようなヘッダも送り先だと委任先が気づけるようにするためである。3 つとも、HTTP の要求の一部として相手のサーバーに届く。
| 送る場所 | 中身の例 | 今回との関係 |
|---|---|---|
| ヘッダ | User-Agent、認証の情報など | 今回の 3 件はすべてここ |
| URL | 検索語などの引数 | 今回は該当なし |
| 本文 | フォームや API に送るデータ | 今回は該当なし |
「連絡先を求められても」と書いたのは、今回の原因が、相手の作法に従おうとしたことだったからである。
決まりは委任のたびに届く場所に書く
依頼文は委任のたびに書くので、写し忘れが起きうる。編集部が「共通の指示書」にも同じ決まりを書いているのは、そのためである。
Claude Code の場合、サブエージェントの資料によると、分岐でない委任先のシステムプロンプトは、そのサブエージェントの定義ファイルから作られる。定義ファイルに書いた決まりは、取りまとめ役が依頼文に写し忘れても、その委任先には毎回届く。
同じ資料によると、定義ファイルでは、委任先が使える道具も個別に決められる。web に触れる必要の無い委任先には、通信の道具を渡さないこともできる。今回の担当は web から画像を集める役目だったので、通信の道具は外せなかった。外せない担当ほど、決まりを確実に届ける必要がある。
作業の後に成果物と一時ファイルをアドレスで検索する
委任先が web を触った後は、成果物と一時ファイルを、利用者のアドレスで検索する。見つけたら消し、どこへ送ったかを利用者に報告する。
検索に使うのはアドレスの一部で足りる。申告しなかった 2 体目もこの検索で見つかった。編集部では次の形で、作業場所と一時ファイルの場所をまとめて検索している。
1
grep -rl "<アドレスの一部>" <作業場所> <一時ファイルの場所>
-l を付けると、一致したファイルの名前だけが出る。見つかったファイルを開いて、どの通信に使われたかを確かめ、送った先を利用者に伝える材料にする。
User-Agentは連絡先の無い名乗りにする
委任先が自分で通信の道具を書くときは、User-Agent を、道具の名前と版に、個人を指さない連絡先（組織のサイトの URL など）を添えた名乗りにさせる。連絡先は委任先に探させず、人が決めて依頼文で渡す。ブラウザと同じ名乗り（Mozilla/5.0）は、Wikimedia のように方針で禁じている相手があるので使わない。名乗りには製品を識別するのに要る物だけを入れる、という HTTP の仕様の考え方とも合う。
ただし Wikimedia の方針は、前の節のとおり、自動の通信がブラウザの名乗りを真似ることを禁じ、連絡先を求めている。相手によっては、連絡先の無い名乗りでは遮断されることもある。
編集部としては、連絡先が要る相手には、個人のアドレスではなく、組織のサイトの URL のように個人を指さない窓口を使うことを勧める。方針も連絡先の形として web サイトを挙げている。何を書くかは委任先に決めさせず、人が決めて依頼文で渡す。
対策の効き目と届かない所
自己申告だけでは3件のうち1件を見逃していた
今回見つかった 3 件の内訳は次のとおりである。
| 担当 | 送った情報 | 見つかり方 |
|---|---|---|
| 1 体目 | メールアドレス | 担当が報告で申告 |
| 2 体目 | メールアドレス | 取りまとめ役がスクリプトを検索して発見 |
| 3 体目 | 名前（約 7 回、13 秒後に書き換え） | 担当が報告で申告 |
3 件のうち 2 件は担当の自己申告で分かった。残る 1 件は検索しなければ見つからなかった。作業の後の検索は自己申告の漏れを拾う役目を果たしている。
検索で見つかるのはファイルに残った物だけ
作業の後の検索が拾えるのは、ファイルに残った物だけである。スクリプトを書かずに、その場で組み立てて送った通信は、ファイルを検索しても見つからない。
また、検索で見つけても、送った事実は消えない。相手のサーバーに届いた情報は、こちらから取り消せない。検索は後から気づくための仕組みであって、送る前に止める仕組みは依頼文の決まりのほうである。
依頼文の決まりも守られない場合がある
依頼文に書いた決まりは、AI が守るかどうかを判断する。Claude Codeのセキュリティ対策では、指示書の末尾に足した「送信の直前で止めて」という一文が守られず、担当の AI が本当に投稿した件を書いた。
決まりを書いたから送られない、とは言い切れない。だから、送る前の決まりと、送った後の検索を重ねている。
AIエージェントの情報漏洩は道具の引数からも起きる
OWASPが挙げる「機微な情報の開示」
LLM を使うアプリの危険をまとめた OWASP Top 10 for LLM Applications は、2 番目に「Sensitive Information Disclosure（機微な情報の開示）」を挙げ、その最初の例に個人を特定できる情報の漏洩を置いている。
この項目の説明は、主に AI の出力を通じて情報が出ていく危険を書いている。AI エージェントでは出力に加えて、道具を使うときの引数も外へ出る経路になる。今回の User-Agent はその一例だった。
同じ項目は、システムプロンプトで AI が返してよい情報の種類を制限する方法にも触れつつ、その制限は守られないことがあると注意している。編集部が依頼文の決まりに加えて作業の後の検索を置いているのも、同じ理由からである。
守る情報はメールアドレスと名前だけではない
OWASP の同じ項目は機微な情報の例として、個人を特定できる情報のほかに、金融の情報、健康の記録、社外秘の業務データ、認証の情報、法務の文書を挙げている。
編集部が今回、委任先への決まりに書いたのは、利用者のメールアドレスと名前の 2 つである。API キーなど認証の情報は、Claude Codeのセキュリティ対策に書いたとおり、ファイルへの書き込みを hooks で止めている。ほかの種類の情報は扱う作業ごとに、同じように「送らない物」として書き出す必要がある。
文脈にある情報は道具の引数にもなりうる
AI エージェントは文脈にある情報を使って作業を進める。文脈に利用者のメールアドレスがあれば、それは回答の材料にも、通信の引数にもなりうる。
Anthropic のエージェント設計の解説は、エージェントを、作業の進め方と道具の使い方を LLM 自身が決めて動く仕組みと説明している。どの情報をどの道具に渡すかも、AI が自分で選ぶ。
委任すると決まりが落ちる
取りまとめ役が知っている決まりは、委任先には自動では渡らない。委任の段を 1 つ増やすごとに、決まりを写す作業が 1 回増える。
AI エージェントでは 1 回の作業で依頼文を何通も書く。今回も 8 体に、それぞれ依頼文を書いていた。そのどれかに決まりを写し忘れれば、その担当には決まりが無い。
相手の作法が個人の情報を求めることがある
User-Agent の件のように、相手のサービスの作法が連絡先などの個人の情報を求めることがある。AI は作法に従おうとするので、手元にある個人の情報をそのまま使いやすい。
求められても入れない、という決まりを先に書いておく必要があるのは、このためである。
OWASPの対策と照らすと足りない所が見える
OWASP の同じ項目は対策としていくつかの種類を挙げている。そのうち、今回の件に関係するものと、編集部の対策を並べた。
| OWASP が挙げる対策 | 中身 | 近い対策（編集部） |
|---|---|---|
| 厳格なアクセス制御 | 最小権限の考え方で、その利用者や処理に必要なデータにだけ触れさせる | 今回入れた対策には含まれていない |
| データ源の制限 | 外部のデータ源への接続を絞り、実行中のデータの受け渡しを管理する | 依頼文の決まりで、送ってはいけない情報を指定 |
| トークン化と墨消し | パターンの照合で機微な情報を見つけ、処理の前に伏せる | 作業の後の検索（処理の前ではなく後） |
編集部の対策は送ってはいけない情報を委任先に伝えることと、後から見つけることに寄っている。委任先の手元に、そもそも利用者のアドレスを置かない対策は、今回は入れていない。表の 1 行目は手当てしていない所として残っている。
委任する前に確かめること
編集部の件から、AI エージェントに web を触る作業を任せる前に確かめる点をまとめる。
- 外部に送ってはいけない情報を、具体的に挙げているか（メールアドレス、名前など）
- その決まりを、委任のたびに依頼文へ写しているか。取りまとめ役の文脈にあるだけで済ませていないか
- 送ってはいけない場所として、ヘッダ・URL・本文を挙げているか
- 「相手に求められても入れない」と書いているか
- User-Agent などの名乗りに何を書くかを、人が決めて渡しているか
- 作業の後に、成果物と一時ファイルを検索する手順があるか
- 見つけたときに、消して、送った先を利用者に報告する手順があるか
生成 AI の社内での使い方の決まり全般は、生成AI社内ガイドライン策定ツール・サービス8選、個人情報の同意の取り方は生成AI導入の同意取得不備で扱っている。
よくある誤解
「AIは個人情報を外に出さないよう作られている」
編集部の委任先は相手の作法に従って、手元にあった利用者のアドレスを連絡先に使った。外に出してよいかどうかは、渡された決まりで判断する。
「取りまとめ役に決まりを書けば、委任先も守る」
分岐でない委任先は渡された依頼文から作業を始める。取りまとめ役の文脈にある決まりは、写さなければ届かない。
「ヘッダは本文ではないので、情報は出ていない」
User-Agent は通信のたびに相手のサーバーへ届く。画面に出ないだけで、相手は受け取っている。
「自己申告させれば把握できる」
見つかった 3 件のうち 1 件は申告されず、検索で見つかった。
まとめ
AI エージェントに作業を手分けさせたところ、担当 8 体のうち 2 体が利用者のメールアドレスを、別の 1 体が利用者の名前を、外部の API への通信の User-Agent に入れて送っていた。
原因は、取りまとめ役にあった「外部に送らない」という決まりが、委任先への依頼文に無かったことと、相手の方針が User-Agent に連絡先を求めていたことである。
対策として、依頼文と共通の指示書に、メールアドレスと名前をどの外部サービスにも送らないと明記した。web を触った作業の後は、成果物と一時ファイルをアドレスで検索する。見つかった 3 件のうち 1 件はこの検索でしか見つからなかった。
明日から試せる3つ
1 つ目は AI エージェントに渡している依頼文に、外部に送ってはいけない情報が書かれているかを確かめることである。取りまとめ役の指示にだけ書いていないかも見る。
2 つ目は、AI が書いたスクリプトや一時ファイルを、利用者のメールアドレスで検索してみることである。
3 つ目は、AI が外部と通信するとき、User-Agent に何を入れているかを確かめることである。
関連して、CSP をプレビューで確かめたのに本番で違反が出た件をCSP違反が本番だけで出るに書いた。Claude Code の運用全般はClaude Codeの使い方、外部の道具に繋ぐときに外へ出る情報の範囲はMCPを実運用して分かったことで扱っている。
編集部では AI導入の支援と、AI エージェントを業務で回すための運用の決まりと検査の設計も行っている。AI に任せる作業を広げたいが情報の扱いが心配、という段階の相談については、サービス案内を参照してほしい。
参考にした一次資料
- Wikimedia User-Agent Policy — 自動の通信に連絡先を求める方針
- MediaWiki API:Etiquette — API を使うときの作法
- Commons:API — 今回の送り先の API
- RFC 9110 User-Agent — HTTP の仕様での User-Agent の役割
- MDN User-Agent — User-Agent の解説と例
- 個人情報保護委員会 Q&A — メールアドレスが個人情報に当たる場合（Q1-4）
- 個人情報保護委員会 ガイドライン（通則編） — 個人情報の取扱いの基準
- 個人情報保護委員会 法令・ガイドライン — 法令とガイドラインの一覧
- OWASP Top 10 for LLM Applications — LLM を使うアプリの危険の一覧
- OWASP LLM02:2025 Sensitive Information Disclosure — 機微な情報の開示
- Claude Code サブエージェント — 委任先が受け取る文脈
- Building effective agents（Anthropic） — エージェントが道具を使う仕組み
- 情報セキュリティ10大脅威 2026（IPA） — 「AIの利用をめぐるサイバーリスク」が組織向け 3 位
よくある質問
AIエージェントは、なぜ利用者のメールアドレスを外部に送ったのですか。
相手のサービスの作法に従おうとしたためです。編集部の例では、Wikimediaの方針が、自動で通信するプログラムにUser-Agentへ連絡先を書くよう求めていました。委任先のAIは、手元の文脈にあった利用者のメールアドレスを、その連絡先として使いました。取りまとめ役のAIには「外部に送らない」という決まりがありましたが、委任先への依頼文にはその決まりがありませんでした。
User-Agentとは何ですか。
HTTPの通信で、要求を送る側のソフトウェアが自分を名乗るためのヘッダーです。受け取る側は、不具合の範囲の特定や、応答の出し分け、利用の集計などに使います。通信のたびに相手へ届くので、ここに書いた内容は相手のサーバーが受け取ります。
メールアドレスは個人情報に当たりますか。
個人情報保護委員会のQ&Aでは、ユーザー名とドメイン名から特定の個人を識別できるメールアドレスは、それだけで個人情報に当たるとしています。それ以外の場合は個別の判断になり、他の情報と容易に照合して個人を識別できるなら、あわせて個人情報に当たることがあります。
AIエージェントの情報漏洩を防ぐには、何から始めればよいですか。
編集部では、外部に送ってはいけない情報と、その決まりを、委任のたびに依頼文へ写すことから始めました。取りまとめ役の文脈にある決まりは、委任先には届かないことがあるためです。あわせて、委任先がwebを触った後は、成果物と一時ファイルを利用者のアドレスで検索しています。
AIに自己申告させれば十分ですか。
編集部の例では、3件のうち2件は担当のAIが自分から申告しましたが、1件は取りまとめ役が一時ファイルを検索して見つけました。自己申告だけに頼っていたら、その1件は見逃していました。
外部に送ってしまったと分かったら、何をしますか。
編集部では、成果物と一時ファイルに残った利用者のアドレスや名前を消し、どのサービスへ送ったかを利用者に報告する手順にしています。相手のサーバーに届いた情報は、こちらから取り消せません。そのため、送った後に見つける手順とは別に、送る前の決まりを委任先に必ず渡しています。
User-Agentには何を書けばよいですか。
道具の名前と版に、個人を指さない連絡先（組織のサイトのURLなど）を添えた名乗りにします。連絡先は委任先に探させず、人が決めて渡します。Wikimediaの方針は、自動で通信するプログラムがブラウザの名乗りを真似ることを禁じ、連絡先を求めているため、ブラウザと同じ名乗り（Mozilla/5.0）は使いません。