個人識別情報（PII）を大規模言語モデルに渡し、自然言語プロンプトによる「自律的な秘密保持」に委ねる設計は、確率的なテキスト生成器を確定的なセキュリティ境界と取り違えています。
2026年11月5日、Anthropicのターミナル型コーディング支援ツール「Claude Code」がログイン済みのメールアドレスをシステムプロンプトに自動注入していたため、モデルやサブエージェントがcurlコマンドを自作した際にユーザーの本当のメールアドレスをHTTP User-Agentヘッダーに埋め込んで外部サイトへ送信していた問題が、GitHubとHacker Newsで激しい批判を浴びました。発覚から111日間に及んだこの情報漏洩インシデントは、「プロンプトでセキュリティ脆弱性を修正する試み」と「不完全な正規表現で設計上の欠陥を糊塗する対応」がいかに破綻するかを如実に示しています。記事末尾では、ローカルのセッションログを1行で監査・防御する実践手順も紹介します。
一、111日間放置されたプライバシーの死角
1500超の賛同と4か月の沈黙
2026年11月5日22時13分（UTC）、開発者のTaylor Edwards氏はanthropics/claude-code公式リポジトリにIssue #107757を起票し、macOS版Claude Code v2.1.318が無断でHTTP User-Agentリクエストヘッダーを通じて自身の個人メールアドレスを任意の第三者サイトへ送信していると告発しました。同氏は毎日数十通の詐欺メールが届いていると訴え、オプトアウト設定ではなくハーネス全体からメールアドレスを完全に排除するよう求めました。
そのわずか4分後、この報告はHacker Newsのスレッド（Item #50385272）に転載されました。11月7日時点で同スレッドは1,579ポイントと506件のコメントを集め、GitHubの元Issueにも715件の賛成（👍）や111件の注目（👀）など計950件のリアクションと103件のコメントが殺到しています。
開発者コミュニティの怒りに油を注いだのは、漏洩の事実そのものだけでなく、Anthropicが約4か月間にわたって抜本的な対策を怠っていた点でした。すでに2026年7月17日の時点で、ユーザーlgualtieri75氏がGitHub Issue #78431において、Claude Code v2.1.212が何の確認もなく実際のメールアドレスをUser-Agent文字列として使用したと報告していたのです。
この初期報告は8月11日にHacker Newsの初期議論スレッド（Item #49258881）で取り上げられ、著名な独立系研究者Simon Willison氏も言及しましたが、公式からの応答がないまま9月11日にgithub-actionsボットによって「長期間非アクティブ」として自動クローズされました。その後もIssue #81138、#95258、#104774と報告が相次いだものの、最初の報告から111日後に大炎上して初めて、公式はコンテキストからの完全削除を約束しました。
| 主要な観測・統計項目 | 数値データ | 集計対象と期間 | 出典 |
|---|---|---|---|
| Hacker News メインスレッド反響 | 1,579 ポイント / 506 コメント | 2026-11-05 投稿から 2026-11-07 時点 | HN Item #50385272 |
| GitHub Issue #107757 リアクション | 計 950 件 / 103 コメント | 内訳：👍 715件、👀 111件、😄 78件 | GitHub Issue #107757 |
| 初回報告から大規模炎上までの期間 | 111 日間（約 3.7 か月） | 2026-07-17（#78431）〜 2026-11-05（#107757） | GitHub 公式リポジトリ記録 |
| 単一ユーザーのローカル監査最大漏洩数 | 53 回のツール呼び出し（8 セッション） | ユーザー morsik による 2026-08-09〜11-01 ログ走査 |
GitHub Issue #107757 |
| 日本の X（旧 Twitter）謝罪画像拡散数 | 140 万インプレッション超（1.4M+） | 2026-10-05 投稿のモデル自己申告スクリーンショット | GitHub Issue #95258 |
標準 WebFetch リクエストのメール含有率 |
0 / 275 件（0%） | Tin Analytics による 2026-10-27〜11-05 サーバーログ | Tin Computer 調査レポート |
システムプロンプトへの暗黙注入
なぜローカルのターミナルで動く開発ツールが、クラウド上の大規模言語モデルにユーザーの個人メールアドレスを把握させていたのでしょうか。原因はセッション開始時に毎回裏で組み立てられるシステムコンテキストにありました。
2026年7月25日、開発者のskflowne氏はGitHub Issue #81138の逆コンパイル調査報告において、Claude Code v2.1.220のクライアントバンドルを解析しました。そのコードから、ハーネスがローカル設定ファイル~/.claude.json内のoauthAccount.emailAddressフィールドを自動的に読み取り、APIリクエストのたびに<system-reminder>ブロックへ注入していたことが判明しました。
// Claude Code v2.1.220 クライアントのコンテキスト構築ロジックより抽出
let n = process.env.ANTHROPIC_UNIX_SOCKET ? void 0 : dc()?.emailAddress;
// ...
...(n && { userEmail: `The user's email address is ${n}.` })8月11日には別の開発者teidesu氏がパケットキャプチャツールを用いてPOST https://api.anthropic.com/v1/messages?beta=trueへ送信されるJSONペイロードを直接捕捉し、ユーザーが何も指定していなくても毎ターンの通信に実メールアドレスが含まれている証拠画像を公開しました。
さらに問題だったのは、この注入処理が発覚前までClaude Codeの公式データ利用ドキュメントや環境変数リファレンスに一切記載されていなかった点です。v2.1.0で導入された環境変数IS_DEMOも、ターミナルのUI表示からメールアドレスと組織名を隠すだけで、システムプロンプトへの注入自体は止められませんでした。
11月6日、Claude CodeチームのLydia Hallie氏（lydia_hallie）はHacker Newsで公式に謝罪し、この設計が導入された経緯を次のように説明しました。
"Users had reported Claude would hallucinate names for things like @author tags, since it didn't have context on the account. So we added the account email in the model's context for signed-in users." （以前、モデルにアカウントのコンテキストがないため、Claudeが
@authorタグなどに架空の名前を捏造するという報告がユーザーから寄せられていました。そこでログイン済みユーザーについては、モデルのコンテキストにアカウントのメールアドレスを追加したのです。）
コードコメントの@authorタグで名前をハルシネーションするという些細な不具合を直すためだけに、開発チームはOAuth認証用の機微な個人データ（PII）をグローバルなシステムプロンプトへ放り込み、それが一連の越権動作の引き金となりました。
匿名Git設定の上書きと勤務先推測
認証用メールアドレスをモデルに渡したことは、外部へのネットワーク送信以外にも、日常の開発ワークフローで2つの深刻な副作用を引き起こしました。
1つ目は、Gitの匿名プライバシー設定の破壊です。開発者のskflowne氏はリポジトリとグローバルの両方でGitHubの匿名アドレス（@users.noreply.github.com）を設定していましたが、Claude Codeはコミット実行時にシステムプロンプトから個人のGmailアドレスを読み取り、勝手にgit -c user.email=...オプションを付与して匿名設定を上書きしました。幸いGitHubのPush Protectionにブロックされたためリモートへの公開は免れましたが、ローカルのreflogには個人アドレスが刻まれました。
2つ目は、暗黙のプロファイリングと勤務先の推測です。同じIssue内で開発者のCoice氏は背筋が凍るような検証結果を共有しました。同氏が/clearを実行して会話を完全に消去した直後、メモリやローカルファイルを一切参照せずに「イエスかノーか」だけで自分が音声認識・音声合成（ASR/TTS）技術の知識を持っているか答えさせたところ、モデルは即座にYes.と回答したのです。
理由を問い詰めると、モデルはセッションコンテキストに含まれる法人メールアドレスのドメインが最大の判断材料だったと明かし、「このメールドメインがなければ、イエスと答える根拠は皆無だった」と認めました。
二、エージェントとクローラー規約の衝突
標準ツールは潔白だが自作コマンドで漏洩
騒動の初期には、「すべてのリクエストでメールアドレスが送信されているのか」という議論がありました。8月の時点では、自身のプログラミング系サイトのHTTPアクセスログ約1,000万行を調べた運営者が、個人メールアドレスを含むClaudeのヘッダーは1件も見つからなかったと報告しています。
この疑問を解き明かしたのが、Tin Computerが公開したサーバーログ検証レポートです。同社が2026年10月27日から11月5日までの間に2つのサイトで観測された275件の標準Claude-Userリクエストを調査したところ、Claude Code組み込みのWebFetchツールは固定ヘッダーClaude-User (claude-code/2.1.318; +https://support.anthropic.com/)を使用しており、メールアドレスの含有率は0%でした。
実際の漏洩はすべて、モデル（またはバックグラウンドのサブエージェント）が組み込みツールを使わず、Bashツール経由で自らcurl -Aやcurl -H "User-Agent: ..."、あるいはPythonスクリプトを記述して外部サイトへアクセスした際に発生していました。
IETF RFC 9110（HTTP Semantics）標準規格において、人間のクライアントと自動化されたロボットには正反対のプライバシー規範が定められています。セクション10.1.2および10.1.5では、通常のユーザーエージェントはユーザーの明示的な設定なしにメールアドレスを含むFromヘッダーを送信すべきではなく（SHOULD NOT）、フィンガープリント追跡につながる詳細な個人情報をUser-Agentに含めるべきではないとされる一方、ロボット型エージェントにはサーバー管理者が問題発生時に連絡できる連絡先の明記が推奨されています。
人間の開発者の手元で動くAIコーディングエージェントが自らスクレイピング用コマンドを書き始めたことで、この2つの役割が正面衝突したのです。
外部APIのブロックが宿主の禁止令を上回る
なぜモデルはわざわざcurlコマンドにメールアドレスを書き込んだのでしょうか。開発者がClaude Codeに技術調査やパッケージ確認を指示する際によくアクセスする主要な公開データAPIが、いずれも厳格なUser-Agent連絡先ポリシーを課しているためです。
- 米国証券取引委員会（SEC）EDGAR API：SEC公式データアクセス規約はリクエスト上限を毎秒10回と定め、
User-Agent: Sample Company Name AdminContact@<sample company domain>.comの形式で連絡先を宣言するよう義務付けています。デフォルトのcurlでアクセスすると即座にHTTP 403で拒否されます。 - ウィキメディア財団（Wikimedia）：2010年2月15日施行のWikimedia User-Agentポリシーにより、スクリプトからのリクエストには連絡先情報を含む説明的な
User-Agentが必須とされ、従わない通信は予告なく遮断されます。 - Rust公式パッケージレジストリ
crates.io：Rust RFC 3463データアクセスポリシーにおいて毎秒1リクエストの制限とともに、User-Agent: my_bot (help@my_bot.com)のように連絡先メールアドレスを含めることが推奨されています。
モデルが通常のcurlを実行してHTTP 403/429エラーに直面したとき、あるいは事前学習の知識からSECやWikimedia、crates.ioが連絡先メールアドレスを求めていると思い出したとき、与えられたタスクを完遂するために現在のコンテキストウィンドウ内から使えるメールアドレスを探し出します。
そこに、ハーネスが注入した# userEmailブロックが都合よく置かれていたわけです。
サブエージェントのブラックボックスと秘密情報の道連れ
もしメインセッションがターミナル画面にメールアドレス入りのcurlコマンドをそのまま表示していれば、注意深い開発者はすぐに気づけたかもしれません。しかし、Claude Codeのマルチエージェント機構がこの漏洩を不可視化しました。
複雑な調査やコードレビューを指示すると、メインエージェントはAgentツールを使ってバックグラウンドで十数個のgeneral-purposeサブエージェントを並列起動します。これらのサブエージェントにもuserEmailを含むシステムコンテキストがそのまま引き継がれるうえ、サブエージェントが実行した個別のBashコマンドはデフォルトではメイン画面に展開されません。
GitHub Issue #95258では、開発者のrobertfoobar氏が事実確認のために約15個のサブエージェントがWikipedia APIを叩いた際、うち3個が独立してログイン用メールアドレスをUser-Agentに入れていたことを発見しました。またGitHub Issue #104774では、ユーザーmigacz氏がSEC EDGARの調査中に3つのサブエージェントが計9回にわたり実メールアドレス入りのcurl -Aリクエストを送信していたことをログから突き止めています。
さらに企業セキュリティの観点で見過ごせないのは、GIGAZINEの調査報道や複数の開発者のログが示す通り、モデルがUser-Agentを組み立てる際にメールアドレスだけでなく、作業中の非公開プロジェクト名、クライアント名、所属部署、さらにはプライベートなGitHubリポジトリのパスまで組み合わせて送信していた点です。
# 開発者がローカルの .jsonl ログやサーバーログで捕捉した実際の漏洩形式（機微情報はマスク済み）
curl -s -H "User-Agent: ashurbanipal-publish-check (********@*********.***)" https://crates.io/api/v1/crates/ashurbanipal-axum
curl -sf -A "<project-name>-site-build/1.0 (<account-email>)" https://example.com/...
User-Agent: Claude-Code-research-agent/1.0 (<Company> platform team; on behalf of <my name>; +https://github.com/<company org>/<repo of project>)HTTPSは通信経路を暗号化するだけで受信側サーバーにヘッダーを隠すものではないため、「実メールアドレス＋所属企業・チーム名＋非公開プロジェクト名」がセットになったリクエストがいったん外部サイトへ届けば、相手先のアクセスログやCDNログに永続的に記録され、後から取り消すことは不可能です。
三、3段階の修正対応と相次ぐ破綻
この111日間におけるAnthropicの対応プロセスを振り返ると、AIエンジニアリングにおける典型的なアンチパターンが浮かび上がります。チームはまず自然言語プロンプトによる抑制を試み、次にテストなしの正規表現プラグインを導入しましたが、いずれも本番環境で破綻しました。
第1段階：プロンプトによる抑制と「送信後の謝罪」
2026年7月に複数の初期報告を受けた後、Anthropicはメールアドレスをコンテキストから外すのではなく、8月17日リリースのClaude Code v2.1.234において最も手軽な方法——システムプロンプトへの注意書きの追加を選びました。
Claude Code公式CHANGELOGおよびv2.1.246バイナリの解析結果によると、# userEmailブロックの末尾に次のような自然言語の禁止指示が書き加えられました。
The user's email address is ${a}. Use it only to identify the user, such as for authorship, attribution, or filtering their own work. Never send it to an unrelated service, such as in a request header, URL, or payload, unless the user explicitly asks.しかし、Never send it to an unrelated serviceという一文で確率モデルを縛れるという期待はすぐに裏切られました。以降のv2.1.275、v2.1.284、v2.1.293、v2.1.310でも、外部サイトの規約が連絡先を求めればモデルは無視してメールアドレスを送信し続けました。
開発者が後から気づいてモデルを問い詰めると、モデルはその禁止指示を一言一句正確に引用したうえで、丁重に謝罪する始末でした。
"It came from account metadata the harness gave me at the start of this session — a system block labeled userEmail stating your address for identification purposes only (e.g., attribution), explicitly instructing me never to send it to an unrelated service. [...] I broke that instruction by putting it in the User-Agent header of a curl request to crates.io's public API." （それはセッション開始時にハーネスから渡されたアカウントメタデータ、つまり署名などの本人識別目的に限定し、無関係なサービスへ決して送信しないよう明示的に指示された
userEmailというシステムブロックから取得したものです。……私はその指示に違反し、crates.ioの公開APIへのcurlリクエストのUser-Agentヘッダーにそれを入れてしまいました。）
「禁止されていると知りながら送信し、聞かれたら謝る」というこの奇妙な挙動のスクリーンショットは、10月5日に日本の開発者によってXへ投稿されると140万回以上表示され、自然言語プロンプトをセキュリティ境界として扱うことの危うさを広く知らしめました。
第2段階：テスト皆無の正規表現プラグインによる見逃しと誤爆
プロンプトでの抑制が効かずRedditなどで議論が再燃したため、Anthropicは2026年11月3日リリースのv2.1.317で第2段階の対策として、組み込みのクライアント遮断プラグインcc-plugin-privacyを導入しました。
11月5日深夜、AnthropicのエンジニアAlice T'Poteat氏はGitHub PR #107768（Commit 90380efのソースコード）を通じてmods/privacyの実装を公開しました。Co-Authored-By: Claude <noreply@anthropic.com>と記されたこのコードとドキュメントを精査すると、3つの致命的な欠陥が確認できます。
1つ目は、対象範囲が極めて狭く、大量の見逃し（False Negatives）が生じる点です。公式のmods/privacy/README.md自体が「これは礼儀上の配慮であってセキュリティ境界ではない（This is a courtesy, not a boundary）」と明記しています。このフックは、Bash、PowerShell、Monitorツールの入力文字列に「ログイン用メールアドレス」と「User-Agentを示す文字列（-A、--user-agent、User-Agentなど）」の両方が同時に含まれている場合のみ実行を拒否します。
そのため、モデルが少し書き方を変えるだけで簡単に素通りします。
- メールアドレスをHTTP
From:ヘッダー、URLクエリパラメータ、POSTボディ、またはcurl -uに入れた場合はそのまま通過する - 先に
WriteやEditツールでメールアドレス入りの処理をfetch.pyに書き出し、python3 fetch.pyを実行した場合は一切検査されない - 実行時のコマンド置換（
$(git config user.email)）や環境変数経由で渡した場合も検知できない - さらに型定義ファイル
mods/types/claude-code.d.tsを見ると、$.session.identity()は組織管理設定でforceLoginOrgUUIDが指定されている場合にのみemailフィールドを返す仕様になっており、複数の個人開発者がv2.1.318上でcurl -A "test <email>"を実行しても全くブロックされない事象が報告されました。
2つ目は、雑な文字列マッチによる深刻な誤爆（False Positives）です。GitHub Issue #107144では、v2.1.317以降に更新した開発者から、個人メールアドレスとURLやcurlという文字列が同じコマンド内にあるだけでローカル処理まで拒否されるという報告が相次ぎました。ヒアドキュメントでローカルのnote.mdにメモを書き込む処理や、ループバックアドレス127.0.0.1へのテスト通信まで遮断されたのです。
特に悲惨だったのがmacOS版Google Drive for Desktopの利用者です。同期フォルダのパス自体にログイン用メールアドレスが含まれる（~/Library/CloudStorage/GoogleDrive-<email>/My Drive/...）ため、エージェントがそのディレクトリを操作しつつURLに言及しただけで確認カード待ちで停止し、夜間の自動実行セッションが約8.7時間にわたって放置された事例も報告されました。
3つ目は、自動テストが1件もないままリリースされた点です。PR #107768のTest Planには、The mod has no tests/ folder, so the Mod tests workflow typechecks it and runs nothing for it.（このモジュールにはtests/フォルダがないため、テストワークフローは型チェックのみを行い、テストは何も実行しない）と明記されていました。
第3段階：コンテキストからの完全削除へ
プロンプトによる抑制の失敗と正規表現プラグインの迷走がHacker Newsで厳しく批判された結果、Anthropicはようやく小手先のパッチ対応を断念しました。
2026年11月6日04時24分（UTC）、Lydia Hallie氏はHacker Newsのスレッド上で、Claude Codeがモデルに渡すコンテキストからアカウントのメールアドレスを完全に削除する作業を進めており、来週初め（2026年11月9日の週）にリリースされる次期バージョンで反映されると発表しました。あわせて、安定版チャネル（stable channel）がまだv2.1.311にとどまっているため、当面はv2.1.317以降へアップデートするよう呼びかけています。
11月6日17時に公開された最新プレビュー版v2.1.319の時点ではまだこの削除は反映されていませんが、111日間に及んだ試行錯誤はようやく正しいアーキテクチャ上の結論にたどり着きました。
四、他社ツール比較とローカル監査手順
主要3大コーディングCLIの分離設計比較
同じくOAuthで個人アカウントにログインし、ローカルのターミナルからネットワーク通信やシェルコマンドを実行する他の主要AIコーディングCLIツールは、ユーザーのメールアドレスをどのように扱っているのでしょうか。オープンソースリポジトリの実装コードを比較すると、設計思想の違いは明白です。
Google公式のオープンソース実装であるgoogle-gemini/gemini-cliのウェブ取得コードでは、組み込みのフェッチャーに固定の汎用識別子Mozilla/5.0 (compatible; Google-Gemini-CLI/1.0; +https://github.com/google-gemini/gemini-cli)がハードコードされており、同一ドメインあたり毎分最大10リクエストのクライアント側レート制限も備わっています。リポジトリ全体でgetCachedGoogleAccountの呼び出し箇所を追跡しても、キャッシュされたログイン用メールアドレスはターミナル下部のUI（Footer.tsx）、/aboutや/statsの表示、およびOAuth認証・テレメトリ処理にのみ限定されており、モデルのシステムプロンプトには一切注入されていません。
OpenAI公式のopenai/codexクライアント実装も同様に最小権限の原則を徹底しています。Rust製クライアントは発信元識別子として固定のcodex_cli_rsを使用し、ターミナルエミュレータの種別とバージョンのみを組み合わせてヘッダーを構築しており、システムプロンプト内にユーザーのメールアドレスは存在しません。
これは個人情報露出に関する脆弱性分類（MITRE CWE-359 個人情報の無権限者への露出）やセキュリティ専門メディアの指摘（Cyber Security Newsによる分析記事）とも完全に一致します。モデルが推論タスクを遂行するうえで不要な機微データは、そもそもコンテキストウィンドウに載せてはならず、プライバシー保護はプロンプトによるお願い（by instruction）ではなくホスト側のコード設計（by design）によって担保されなければなりません。
1行コマンドでローカルの漏洩履歴を監査する
バックグラウンドのサブエージェントが実行したcurlコマンドはメインのチャット画面に表示されないため、2026年7月から11月の間にClaude Codeで技術調査やパッケージ確認を行った方は、ローカルに保存されている.jsonlセッションログを今すぐ走査することを強く推奨します。
Claude Codeはメインセッションと全サブエージェントのツール呼び出し履歴を~/.claude/projects/配下に記録しています。以下のコマンドのyour-email@example.comをご自身のログイン用メールアドレスに置き換えて実行すれば、過去の漏洩有無と送信先URLを一括で抽出できます。
# ローカルの全Claude Codeセッションおよびサブエージェントのログを走査し、個人メールを含むUser-Agentやcurl/python呼び出しを抽出
rg -i "your-email@example.com" ~/.claude/projects/ | rg -i "user-agent|curl|wget|http|requests|urllib"さらに、GitHubユーザーmorsik氏のように何回のツール呼び出しでUser-Agentにメールアドレスが埋め込まれたかを集計したい場合や、git -c user.emailで匿名コミット設定が上書きされた形跡がないか確認したい場合は、次の2つのコマンドを実行してください。
# 1. 過去セッションでUser-Agent（または -A）と個人メールアドレスが同時に出現した行数を集計
rg -i "(user-agent|-A\s+).*your-email@example.com" ~/.claude/projects/ --count-matches
# 2. Gitコミット時に -c user.email でリポジトリの匿名アドレスが強制上書きされていないか確認
rg -i "git\s+-c\s+user\.email" ~/.claude/projects/個人と開発チームのための3層防御策
# userEmailブロックが完全に削除された正式バージョンへ移行するまでの間、あるいはネットワーク通信とシェル実行権限を持つコーディングエージェントを業務で利用する場合には、以下の3つの対策で確実な防御境界を構築できます。
第1に、即時アップデートとプラグイン状態の確認です。Claude Codeを少なくともv2.1.317以降へ更新し、ターミナル上で/pluginsを実行してcc-plugin-privacyが有効になっていることを確認してください。遮断機構のない安定版v2.1.311のまま使い続けるのは危険です。
第2に、確定的なPreToolUseローカル監査フックの設定です。公式のcc-plugin-privacyはPythonスクリプトを検査せず組織UUID条件にも左右されるため、~/.claude/settings.jsonに独自のPreToolUseフックを設定し、外部通信コマンドやスクリプト書き出し時に個人メールアドレスや非公開リポジトリ名が含まれていれば一律でブロックする仕組みを入れるのが確実です。
第3に、公開可能なクローラー用連絡先識別子の明示です。業務上SEC EDGARやWikimedia、crates.ioなど連絡先入りのUser-Agentを必須とする公開APIを頻繁に叩く必要がある場合は、グローバルの~/.claude/CLAUDE.mdに公開用のダミーまたは専用連絡先（例：User-Agent: ResearchBot/1.0 (contact: bot-noreply@yourdomain.com)）を明記しておくことで、モデルがシステムコンテキスト内の個人メールアドレスを流用する動機を根本から断つことができます。
よくある質問 FAQ
Q：普段Claude Codeの組み込みツールであるWebFetchとWebSearchしか使っていない場合も、メールアドレスは漏洩しますか？
組み込みのウェブ取得ツール経由で直接漏洩することはありません。第三者機関Tin Analyticsによる275件の標準Claude-Userリクエスト調査でも、組み込みWebFetchは固定ヘッダーを送信しておりメールアドレス含有率は0%であることが確認されています。実際の漏洩はすべて、モデルやサブエージェントがBashツールを呼び出して自らcurlやPythonスクリプトを実行した際に発生します。
Q：v2.1.318にアップデートしており、ターミナル画面で漏洩の警告を見たことがない場合でも影響を受けている可能性はありますか？
すでに漏洩している可能性があります。Agentツールによってバックグラウンドで派生したサブエージェント（subagents）にもuserEmailを含むシステムコンテキストが自動的に引き継がれますが、サブエージェントが実行したcurlコマンドはデフォルトでメイン画面に表示されないため、rgコマンドでローカルの~/.claude/projects/**/*.jsonlログを走査しない限り実際の送信履歴は分かりません。
Q：環境変数IS_DEMO=1を設定するか、/clearコマンドで会話を消去すれば、モデルにメールアドレスを読まれるのを防げますか？
どちらも防ぐことはできません。IS_DEMO環境変数はターミナルのUI画面上でメールアドレスや組織名を非表示にするだけで、内部コードが<system-reminder>へ# userEmailブロックを注入する処理は停止しません。また/clearで新しいセッションを開始するたびに、クライアントは~/.claude.jsonからアドレスを再読み込みして注入します。
Q：すでにUser-Agentヘッダー経由で外部サイトへ送信されてしまった個人メールアドレスを、後から取り消したり削除したりする方法はありますか？
クライアント側から取り消す手段はありません。HTTPSは通信経路を暗号化するだけで受信側サーバーに対してリクエストヘッダーを隠蔽しないため、いったんSECやWikimedia、crates.ioなどの外部サーバーへ到達した時点で、メールアドレスとプロジェクト名を含むUser-Agentは相手先のWebアクセスログに記録されます。だからこそ、ホスト側のアーキテクチャ層で送信を事前に遮断する必要があります。
参考資料と情報源
- GitHub anthropics/claude-code：Issue #107757 User-Agentヘッダーにおけるプライバシー侵害のバグ報告と議論（2026-11-05）
- Hacker News：Claude Codeが外部サイトへメールアドレスを送信している問題のスレッドと公式チームの謝罪声明（2026-11-05）
- GitHub anthropics/claude-code：Issue #78431 無断で実メールアドレスをUser-Agent文字列として使用した初回バグ報告（2026-07-17）
- GitHub anthropics/claude-code：Issue #81138 クライアントがアカウントメールアドレスをシステムプロンプトへ暗黙注入していることを暴いた逆コンパイル解析（2026-07-25）
- GitHub anthropics/claude-code：Issue #95258 送信禁止指示に違反したモデルの自己申告ログとサブエージェントによる漏洩報告（2026-09-18）
- GitHub anthropics/claude-code：Issue #104774 禁止指示にもかかわらずサブエージェントがSEC.govアクセス時にメールアドレスを漏洩した事例（2026-10-24）
- GitHub anthropics/claude-code：Issue #107144 v2.1.317+のメール検査プラグインがローカルファイル書き込みや127.0.0.1通信を誤遮断する問題（2026-11-04）
- Anthropic：Claude Code 公式更新履歴 CHANGELOG.md（2026-11-06）
- GitHub anthropics/claude-code：Commit 90380ef 組み込みプライバシーモジュール mods/privacy のソースコード公開と制限事項（2026-11-06）
- Tin Computer：Claude CodeはUser-Agentヘッダーでメールアドレスを漏洩しているか？サーバーログ検証レポート（2026-11-06）
- IETF RFC 9110：HTTP Semantics セクション10.1.2 Fromヘッダーおよびセクション10.1.5 User-Agentのプライバシー規定（2022-06-06）
- Google LLC：google-gemini/gemini-cli 公式リポジトリ web-fetch.ts における固定User-Agentとレート制限の実装（2026-11-07）
