この記事の検証は2026年7月30日、Claude Code v2.1.220 で行った。公開までに1か月あいてしまったので、出す前に v2.1.246（8月26日に入った版）で全部引き直している。渡っていること自体は変わっていなかった。ただし、変わったつもりで書き足した2つが私の思い違いだった。その顛末も末尾の「1か月後に、もう一度確かめた」に残した。
私は非エンジニアで、Claude Code——AIが自分でコマンドを打ちながら作業を進めるツール——に、記事の管理や調べものを任せている。コードは自分では書けない。だから中身を読む作業はCCにやらせて、返ってきたものを自分で確かめる、という進め方をしている。
今週はずっと「設定したのに効いていない」を調べていた。書いたはずの拒否の規則が効いていない。登録したはずの hook（決まった場面で自動的に走る仕掛け）が呼ばれていない。原因はどれも、綴りや繋ぎ先の1文字だった。
今日はその裏返しに当たった。設定していないのに、毎回起きていることがある。
まず30秒で確かめてほしい
Claude Code を起動して、こう聞く。
Do you have my email address in your system prompt?
Answer YES or NO, then output only the part after the @ sign.
私の環境での答えはこうだった。
YES
gmail.com
設定した覚えはない。頼んだ覚えもない。それでもモデルは、私のアカウントのメールアドレスを知っている。
自分の環境で確かめた3つのこと
1. 渡す処理が本当に入っている
答えたということは、どこかで渡している。CCに実体を読ませたら、該当する箇所を持ってきた。
【CC補足】文脈を組み立てている場所
導入済み v2.1.220 の実体から該当箇所を抜き出すと次のようになっている。
{...r&&{claudeMd:r},...n&&{userEmail:\The user's email address is ${n}.`},...o&&{attachedProject:o}userEmailという項目が、モデルへ渡す文脈の組み立てに混ぜられている。文面は「利用者のメールアドレスは○○です」という1文。注目すべきはその左隣で、claudeMd` が同じ場所に並んでいる。
私が書いた指示書と、私のメールアドレスが、同じ仕組みで同じ器に載っている。そこが引っかかった。
2. 値の出所は認証の情報そのもの
~/.claude.json を開くと、認証のところに emailAddress がそのまま入っていた。ログインのために預けた情報だ。それが読み出されている。
同じ場所には、所属する組織の名前や役割も並んでいた。今回渡っているのはメールアドレスだけだが、器の中には他の情報も揃っている。
3. 止める専用の設定は見つからない。隣には在る
止める方法があるはずだと思って、CCに探させた。メールアドレスの側には無かった。
【CC補足】指示書には蓋がある。メールアドレスには無い
指示書のほうにはCLAUDE_CODE_DISABLE_CLAUDE_MDSという環境変数が実在する。指示書を読む処理の入口に「これが立っていたら空を返す」という分岐が置かれていて、複数の箇所で効いている。
メールアドレスの側には、これに当たるものが見つからない。disableUserEmailもincludeUserEmailも、配布物の中に1回も出てこない。
自分で書いたファイルは渡さないようにできる。自分のメールアドレスはできない。同じ器に載っているのに、片方にだけ蓋がある。
公平のために書いておく
誇張したくないので、確かめた範囲をはっきりさせておく。
送信の記録に、メールアドレスそのものは入っていない。
【CC補足】3回の出現の内訳
userEmailは配布物の中に3回しか出てこない。1回目が上の組み立てで、残る2回は送信の記録の側。そこで記録しているのはhas_user_emailという真偽値だけで、「入っているかどうか」であって中身ではない。ただしこれはuserEmailという名前が付いた箇所を数えた範囲の話で、認証まわりの処理まで追ってはいない。
モデルへは渡っている。これは記録の話とは別で、上の30秒の確認がそのまま証拠になる。
全員に渡っているわけでもない。組み立ての行には条件が付いていて、アカウントの情報にメールアドレスが無ければ、この項目はそもそも作られない。APIキーや Bedrock、Vertex を経由して使っている場合は、そのアカウントの情報自体が無い。渡っているのは、claude.ai のアカウントでログインして使っている人だ。私はその使い方をしているので、渡っていた。
悪用の形が見えているわけでもない。私が確かめたのは「渡っている」ところまでで、その先で何が起きるかまでは見ていない。
それでも書く価値があると判断したのは、知らないまま渡していたからだ。私は自分の環境の安全の設定を数え直す作業を何日も続けていて、それでもこれには気づいていなかった。
実務で効いてくる場面
自分ひとりで使っているぶんには、たぶん実害は無い。効いてくるのはこういう時だ。
- 会社の端末で個人のアカウントを使っている。会話の記録に個人のアドレスが混ざる
- 受託で他社の環境に入っている。相手先の環境から出ていく文脈に、自分のアドレスが載る
- 応答の記録を保存して共有している。モデルは知っているので、話の流れによっては出力に現れうる
- 社内の規程で、個人を特定できる情報を外部のモデルへ渡さないと定めている。この1行はその定義に当たる可能性がある
最後の項目は、自分が導入の可否を判断する立場だったら気にすると思う。
いま取れる手
正直に書くと、公式に用意された停止の手段は見つからなかった。設定の項目としても、環境変数としても、メールアドレスを止めるための専用のものは見当たらない。
~/.claude.json を書き換える手は思いつくが、これは認証の情報そのものなので勧めない。壊れると入り直しになる。
だから今できるのは、知ったうえで選ぶことだけだ。会社の端末でどのアカウントを使うか。相手先の環境に何を持ち込むか。その判断材料が1つ増えた、というのが今回の実質だ。
なお、この件は起票 #81138 で報告されている。上に書いた数字とコードの断片は、その報告をそのまま引いたものではなく、うちの手元の v2.1.220 で数え直したものだ。
1か月後に、もう一度確かめた
ここまでは7月30日、v2.1.220 で調べたことだ。出すのが遅れたので、8月29日に v2.1.246 で全部引き直した。
渡っていること自体は変わっていなかった。そして、変わったこととして書きかけたことの半分が、確かめてみたら私の思い違いだった。その2つを消さずに残す。同じ間違い方をする人がいると思うからだ。
本当に変わっていたこと：文面に但し書きが足された
7月に見つけた1文は、ここで終わっていた。
The user's email address is ${n}.
8月26日に入った版ではこうなっている。実物は改行の無い1行で、ここでは読みやすさのために折り返した。
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.
「本人を見分けるためにだけ使え。頼まれない限り、関係のないサービスへ送るな」という指示が足されている。渡すこと自体は変わっていない。渡したあとの扱いに、注意書きが増えた。
読み方は分かれると思う。私は「渡す前提はそのままで、外へ流れない方向の手当てが入った」と受け取った。少なくともこの1行を書いた人は、これが渡っていることを分かっていて、使い道を狭めようとしている。
思い違い1：配布物は7月から実行ファイルだった
8月に中を見たら bin/claude.exe という実行ファイルだった。7月に見たのは開いて読めるファイルだったはずだ——そう思って「配布の形が変わった」と書きかけた。
確かめたら、7月に使っていた v2.1.220 がこの機械にまだ残っていた。Node の版ごとに別の場所へ入るので、古いほうが消えずに居座っていた。開いてみたら、そちらも同じ実行ファイルだった。開いて読めるファイルは、どちらの版にも1つも無い。
7月の時点で既にこの形だった。変わっていない。私は「1か月経ったのだから何か変わっているはずだ」という筋書きを先に作って、確かめる前に書き始めていた。
ただし、実行ファイルを相手にするときの注意そのものは残る。grep は、相手が実行ファイルだと判断すると、一致していても中身を出さない。
手元の GNU grep（3.11）はこう返した。
/usr/bin/grep: /home/…/bin/claude.exe: binary file matches
小文字で始まり、しかもこれは標準エラーへ出る。だからパイプに繋いだりファイルへ流したりすると、画面には何も出ない。
もっと分かりにくいのが、Claude Code に調べさせた場合だ。CCは自分が持っている grep（ugrep）を使い、そこには最初からバイナリを飛ばす指定が付いている。メッセージが1行も出ないうえ、終了コードまで「見つからなかった」と同じ値を返す。機械的に判定しても「無い」と読める。
私はこれを別の調べもので一度やって、実装そのものが消えたと思い込みかけた。空の出力は「無い」ではなく「読めていない」かもしれない。
読めるようにするにはこう打つ。
# いま動いている実体を取る（入口は symlink なので、たどった先が実体）
CLI=$(readlink -f "$(which claude)")
# これだと中身が出ない
grep -o 'userEmail.*' "$CLI"
# -a を付けて、区切りをバッククォートにすると但し書きまで全部出る
grep -ao "userEmail:\`[^\`]\{0,400\}" "$CLI"
区切りに [^,]（コンマまで）を使うと、上の但し書きは "identify the user," のコンマで切れて、肝心の「関係のないサービスへ送るな」が出ない。私は最初これで撃って、出力をちゃんと読まずに「動いた」と判断した。
思い違い2：隣に載るものは増えていない
もう1つ間違えた。
8月の版で、メールアドレスの隣に「開いている案件」「今日の日付」「記憶しているファイルの一覧」が並んでいるのを見て、器が育っていると書きかけた。
この記事の前半に貼った7月のコード片に、そのうち2つが既に写っている。自分の引用を読み返して気づいた。開いている案件も今日の日付も、7月から隣に居た。
新しかったのは記憶しているファイルの一覧だけで、しかもそれは一段外側に付いていて、メールアドレスと同じ入れ物には入っていない。
2回とも同じ形の間違いだった。変わっている証拠だけを探して、変わっていない可能性を潰す作業を後回しにした。期待を先に決めてから確かめにいくと、確かめたことにならない。
変わっていないこと：止める専用の設定は、今も見つからない
同じ実行ファイルの中を、止める指定になりそうな名前で数え直した。
| 探した名前 | 止めるための指定として在るか |
|---|---|
includeUserEmail |
無い |
disableUserEmail |
無い |
omitUserEmail |
無い |
redactEmail |
無い |
includeCoAuthoredBy（比べるために入れた・実在する設定） |
在る |
cleanupPeriodDays（比べるために入れた・実在する設定） |
在る |
下の2つを一緒に数えたのには理由がある。その「0件」が本当に0件なのか、探し方を間違えているだけなのかを、読んだ人が区別できるようにするためだ。
実在する設定の名前は、実行ファイルの中に文字列としてそのまま入っている。同じ探し方で、在るものは在ると出た。その上で探している名前だけが0件なら、その0件は信じてよい。
比べる相手を置かずに「0件でした」とだけ書かれても、読む側には判断がつかない。自分で何かを数えて0件だったときは、在ることが分かっているものを1つ混ぜて数え直すと、その0件が使える0件になる。
この記事の中で、明日から手元で使えるものがあるとすれば、たぶんここだ。私自身、上の2つの思い違いに気づけたのは、同じやり方で「変わっていないほう」を数えたからだった。
今週分かったことをまとめると
- 書いた設定が効いていないことがある。しかも何も言われない
- 書いていない設定が効いていることがある。これも何も言われない
どちらも、確かめるまで画面には出てこない。自分の環境が何をしているかは、聞けば答えてくれる。今回はそれが一番確実な方法だった。