Claude Codeがメールアドレスを User-Agent で外部送信 — 4か月放置の経緯と v2.1.317 の対策を解説

はじめに

Claude Code が、ユーザーのメールアドレスを HTTP リクエストの User-Agent ヘッダーに入れて外部サイトへ送っていた、という問題が話題になっています。GIGAZINE が 11 月 6 日に報じ、最初の報告は約 4 か月前の 7 月だったことも伝えています。

この記事では、GitHub Issue と Hacker News 上の開発者の回答をもとに、「なぜメールアドレスが送られたのか」「v2.1.317 で入った対策はどこまで防ぐのか」「利用者が手元でできる対策は何か」を整理します。

何が起きたのか — 報告の時系列

発端は 2026 年 7 月 17 日の Issue #78431 です。報告者は、Claude Code v2.1.212（macOS）が確認なしに自分のメールアドレスを User-Agent に使ったと訴えました。8 月 11 日には別のユーザーがセッションログを貼り、Bash ツールから次のような curl が実行されていたことを示しています（メールアドレスは伏せ字）。

curl -s -H "User-Agent: ashurbanipal-publish-check (…@…)" https://crates.io/api/v1/crates/ashurbanipal-axum

この投稿者は 1 時間に 5 回同じことが起きたと報告しています。ただしこの Issue は、Anthropic スタッフの返信がないまま、9 月 11 日に「長期間動きがない」として bot に自動クローズされました。

7 月 25 日には Issue #81138 が立ち、claude.ai アカウントでログインしたときに、アカウントのメールアドレスがシステムプロンプトに毎セッション自動で入ることが指摘されています。報告者によれば値の出どころは ~/.claude.json の oauthAccount.emailAddress で、止める設定は見当たらないとのことです。

その後 10 月に X や Hacker News で再燃し、11 月 5 日の Issue #107757（v2.1.318）につながります。Hacker News には、自社 Web サーバーのアクセスログに次のような User-Agent が残っていたという報告もありました（伏せ字は投稿者による）。

company-helm-research/1.0 (Claude Code agent run by <my name>, <company> platform team; docs lookup)

この例にメールアドレスは含まれていませんが、代わりに氏名・会社名・チーム名が入り、別の例では作業中のリポジトリの URL まで入っていたと報告されています。

なぜ起きたのか — 有力なのは「モデルの判断」説

ここが今回の問題のいちばん分かりにくい点です。Anthropic は原因を公式には説明していませんが、Issue のスレッドで有力なのは「Claude Code のコードが送ったのではなく、モデルが自分で User-Agent に入れた」という見方です。#78431 では、同じバージョンで再現しなかったユーザーが「ハーネスの問題ではない可能性が高く、モデルがヘッダーに入れると判断したのだろう」とコメントしています。ただし、メールアドレスをプロンプトに入れているのは Claude Code 自身なので、プログラム側に責任がないとは言えません。

流れを分解すると、次の 2 つが重なっています。

コンテキストにメールアドレスがある: システムプロンプトにアカウントのメールアドレスが入る（#81138）。git の user.email を読んだ場合も同様に手元にある
それを使うべき理由がある: crates.io のように「自動アクセスの User-Agent には連絡先を書いてほしい」と求める API があり、モデルがその作法に従った

つまり、モデルは「礼儀正しいクライアント」として振る舞おうとして、連絡先として手近にあったメールアドレスを使ったと考えられます。サイトの作法に従うこと自体は正しくても、誰の情報をどこへ送るかをユーザーに確認していない点が問題でした。Simon Willison 氏も 8 月の時点で、ユーザーの明示的な確認なしに外部へ送るのは容認できないと述べています。

LLM エージェントでは、コンテキストに入った個人情報が「使ってよい材料」になってしまいます。プロンプトで「送るな」と指示するのは振る舞いの調整にすぎず、確実な歯止めにはなりません。

v2.1.317 の対策 — `cc-plugin-privacy` はどこまで防ぐか

Claude Code チームのメンバーは 11 月 5 日、Hacker News と #107757 で対応を説明しました。

v2.1.317 以降に、組み込みプラグイン cc-plugin-privacy を追加した
この振る舞いを 決定的に（deterministically） ブロックする
初期状態で有効、/plugins から無効化できる

モデルの判断に任せず、プログラム側でコマンドを止める方式になったのは前進です。一方で、Issue のコメントでは限界も指摘されています。あるユーザーはルールを「アカウントのアドレスを含み、かつ User-Agent を指定するシェル呼び出しを拒否する」ものとして引用し、別名のヘッダーなら通るのではと疑問を出しました。別のユーザーは、v2.1.319 で User-Agent とアドレスを含む echo が拒否されなかったと報告しています。さらに、氏名・会社名・リポジトリ名はアカウントのメールアドレスではないためルールの対象外だ、とも指摘されています。そもそも #107757 自体が、対策入りの v2.1.318 で送信が起きたという報告です。

報告者の taylor-edwards 氏は、オン・オフできる保護ではなく、送信につながる仕組みそのものをなくすべきだと主張しています。執筆時点で #107757 と #81138 はオープンのままです。

エンジニアが手元でできる対策

v2.1.317 以降に更新し、/plugins で cc-plugin-privacy が有効か確認する。ただし上記のとおり完全ではないので、これだけに頼らない
Bash サンドボックスでネットワークを許可制にする。公式ドキュメントによると、サンドボックスの通信はローカルのプロキシを通り、allowedDomains に載っていないホストへの接続は止まります（初期値は空）。v2.1.216 で追加された sandbox.filesystem.disabled を使えば、ファイル書き込みの制限は外したまま通信だけを制限できます

{
  "sandbox": {
    "enabled": true,
    "filesystem": { "disabled": true },
    "network": { "allowedDomains": ["github.com", "*.npmjs.org"] }
  }
}

filesystem.disabled はユーザー設定などでのみ有効で、プロジェクトの .claude/settings.json には書けません。また、オフにすると denyRead や credentials.files で自分で設定した読み取り拒否（~/.ssh など）も効かなくなります。初期状態ではそもそも ~/.ssh は読めるので、守りたい場合は別途設定が必要です

WebFetch / WebSearch は別に考える。公式ドキュメントは「サンドボックスはシェルコマンドだけを対象とする」「allowedDomains は WebFetch を制限しない」と明記しています。これらは権限ルール（allow / ask / deny）で制御します
Web サイトを運営している側は、アクセスログの User-Agent を確認する。メールアドレスや社名入りの UA が残っていれば、それは利用者の個人情報です。ログの保存期間や取り扱いを見直すきっかけになります

なお #81138 のコメントでは、claude.ai の OAuth ログインでない場合（API キー、Bedrock、Vertex）はメールアドレスが入らないと報告されています。ただし公式の説明ではありません。

まとめ

Claude Code が User-Agent にメールアドレスを入れて外部送信した問題は、7 月から報告されていた
有力な説明は、「コンテキストにあるメールアドレス」と「連絡先を求めるサイトの作法」が重なったモデルの判断（公式の原因説明はまだない）
v2.1.317 の cc-plugin-privacy はプログラム側で止める対策だが、対象はアカウントのメールアドレスと User-Agent の組み合わせに限られる
手元では、Bash サンドボックスでの通信の許可制と、WebFetch の権限ルールを組み合わせるのが現実的

エージェントに渡した個人情報は、いずれ外に出る可能性があるという前提で設計することが求められています。今後、システムプロンプトへのメールアドレス注入自体が見直されるかどうかも注目点です。