結論：2026年11月8日時点で、Claude Code の確認の画面で「Yes, and don’t ask again」（日本語のドキュメントの訳は「はい、今後は聞かない」）を選んだコマンドは、中に入っていたパスワードやトークン（Claude Code が設定ファイルや .env から読んで入れた物も含む）ごと .claude/settings.local.json に保存されることがあり、公開の GitHub では 1,122 個のファイルから本物らしい秘密が見つかっています（Apiiro の調査）。見つかったら、ファイルを消す前に中の秘密を作り直してください。
- 要点1：Apiiro は公開の GitHub にある 104,185 個の
.claude/settings.local.jsonを調べ、1,122 個（約 1.1%）に秘密を見つけました。過去の版や共有の設定ファイルまで含めると 2,539 の秘密です。 - 要点2：Claude Code はこのファイルを PC の git の除外の設定に足しますが、効くのはその PC だけです。リポジトリに一度入ったファイルは、消しても過去のコミットとフォークに残ります。
- 要点3：確かめる場所は GitHub の検索・git の過去のコミット・手元の PC の 3 つです。見つかったら、作り直す、使われた跡を確かめる、追跡をやめる、の順に進めます。
対象読者：Claude Code を開発や社内の自動化に使っている会社の、開発チーム・情報システム・セキュリティの担当の方
読了後にできること：自社の GitHub の組織と手元の PC で 2 つの設定ファイルを探し、秘密が入っていた時に何から手を付けるかを決められます。
2026年11月8日時点で、Claude Code で「Yes, and don’t ask again」（はい、今後は聞かない）を選んで承認したコマンドが、パスワードや鍵ごと .claude/settings.local.json に保存されることがあり、公開の GitHub のリポジトリでは 1,122 個のファイルから見つかっています（ソフトウェアのセキュリティの会社 Apiiro が 11月5日付で公開した調査）。見つかった時は、ファイルを消す前に秘密を作り直すのが先です。
「うちのリポジトリにも残っていないか」が気になった方も多いと思います。実は、このファイルはリポジトリに入れていなくても、承認した人の PC に平文で残っています。GitHub だけ見て終わりにしないことが大事なんです。
この記事では、Apiiro の調査と、Claude Code・GitHub・git の公式の文書をもとに、仕組み、確かめ方、見つかった時の順番、残さない設定を説明します。仕組みは 2026年11月8日時点で公式ドキュメントを確認した内容で、当社はこの動きを再現していません。調査の数字はすべて Apiiro の原典の値です。
Claude Codeの設定ファイルに秘密が残った件で何が起きたか
Claude Code は、Manual モード（その都度確認するモード）では、シェルのコマンド（ターミナルで打つ命令）を動かす前に「動かしてよいか」を聞きます。公式ドキュメント（Choose a permission mode）によると、v2.1.283 以降の端末と VS Code の会話は、モードを決めていなければ、別のモデルが代わりに確かめる auto モードで始まり、auto モードが使えない環境では Manual モードで始まります。「Yes, and don’t ask again」を選ぶと、次から聞かずに動くよう、許可の規則がプロジェクトの .claude/settings.local.json に書かれます。規則はコマンドの文字列そのものになることがあり、コマンドにデータベースのパスワードや API のトークンが入っていれば、それも平文で残ります。たとえるなら、「この暗証番号で開けてよい」と番号ごと書いた許可メモを引き出しにしまったつもりが、書類ごとリポジトリに入れて公開していた、という話です。
出来事を日付の順に並べると、次のとおりです。
- 2025年8月11日：利用者が同じ動きを Claude Code の GitHub の issue #5544 に報告。2026年1月3日に「60 日動きがない」として自動で閉じられました（not planned）。issue の上に Anthropic の担当者の返答は見当たりません。
- 2026年11月5日付：Apiiro が調査を公開。Apiiro は、2025年8月から同じ仕組みの報告が issue に 4 件あり、どれにも Anthropic の返答がなかったと書いています。
- 2026年11月7日：セキュリティの報道サイト The Hacker News が報じました。
- 2026年11月8日時点：Anthropic の公式の発表は確認できませんでした。Claude Code の変更履歴（GitHub で 11月6日〔協定世界時〕に公開された v2.1.319 まで）にも、承認した規則を保存する時に中の秘密を伏せる、または保存しないといった変更の記載は見当たりません。
言えるのは「11月8日時点で公式の発表が見つからない」までで、対応していないと言い切れる材料はありません。まずは利用している会社の側で、今日できる確認から始めましょう。
秘密がsettings.local.jsonに残る仕組み
流れは、秘密を含むコマンドを承認する、allow（許可）の規則に保存される、リポジトリにコミットする、公開して誰でも読める、の順です。この件は、Claude Code が秘密を盗んで外部へ持ち出したという話ではありません。承認の記録が、そのまま秘密の置き場になってしまう。これがこの件の芯です。
承認すると allow の規則に保存される
公式ドキュメント（Configure permissions）によると、Manual モードでは、読み取りだけの決まったコマンドを除き、Claude Code はシェルのコマンドの前に確認し、「Yes」「Yes, and don’t ask again for: …」「No」などの選択肢を出します。「Yes, and don’t ask again」を選ぶと、規則は git リポジトリのルートの .claude/settings.local.json に保存され、そのリポジトリでの今後のセッションにも効きます。これは CLI の場合で、VS Code の拡張機能では承認のカードで保存先のファイルを選べ、チームで共有する .claude/settings.json も選べます。共有のファイルを選ぶと、規則は全員に効きます（公式ドキュメント「Settings files and precedence」）。
保存されるのは、選択肢に出ていた範囲
公式ドキュメントは、確認の画面から保存した規則は「その選択肢が示した範囲だけ」を許すと説明しています。画面の例は「npm test 」のように、続きを で受けるパターンです。一方で Apiiro は、データベースの確認や API の呼び出しのように秘密がないと動かないコマンドでは、Claude Code が提案するコマンドに設定ファイルや .env の値が入り、承認するとそのコマンドの文字列が秘密ごと規則として残っていたと報告しています。これはモデルではなく Claude Code 自体の動きで、Anthropic の最新のモデル（Opus 5.5 と Fable 5.1）でも再現したそうです。
git の除外は「その PC だけ」の守り
Claude Code は、このファイルを git に入れない手も打っています。公式ドキュメント（Settings files and precedence）によると、まだ除外されていない git リポジトリで初めてこのファイルを書く時、**/.claude/settings.local.json を利用者のグローバルの git の除外の設定（global git excludes。core.excludesFile のファイルか ~/.config/git/ignore など）に足します。手でファイルを作った場合は、自分で .gitignore に足すよう書かれています。
ただし、これはその PC の git の設定です。Apiiro は、後から git のリポジトリにしたフォルダ、別の PC のクローン、すでに誰かがコミットしたファイルには効かず、除外の規則がリポジトリ自身の .gitignore に入らないので、守りがプロジェクトと一緒に移らないと指摘しています。git の公式の文書も、除外の設定は「すでに追跡しているファイルには効かない」と書いています。
コミットした物は、消しても残る
一度コミットしたファイルは、今の版から消しても過去のコミットに残り、フォーク（他の人が作ったリポジトリの写し）やクローン（各自の PC に写したリポジトリ）にも写っています。Apiiro は、秘密のある 1,105 のリポジトリを追ったところ、539 で Claude が共同作成者として記されたコミットがこのファイルを変えていたとし、Claude がこのファイルごとコミットすることが多いと見ています。
Apiiroの調査で分かった数字
Apiiro は 2026年11月1日から3日に、公開の GitHub のコードとコミットの検索で、既定のブランチにある .claude/settings.local.json を集めて 1 つずつ調べました。秘密のあったファイルは、11月2日の時点でどれも既定のブランチに残っていたそうです。主な数字を表にまとめます（すべてApiiro の原典の値です）。
| 項目 | 数（Apiiro の原典の値） |
|---|---|
公開の GitHub にあった .claude/settings.local.json | 104,185 個（103,617 のリポジトリ） |
| そのうち本物らしい秘密を含むファイル | 1,122 個（約 1.1%） |
| その 1,122 個に入っていた別々の秘密 | 1,379 個（同じ値を重ねて数えない数。決まった形の鍵 636・公開のサーバーの宛先と組になったパスワードやトークン 743） |
| 主な中身 | データベースのパスワード 379、Supabase（クラウドのデータベースのサービス）の service-role の鍵 122、Supabase のアカウントのトークン 103、SSH のログイン 43、GitHub・GitLab・npm のトークン 42、AWS のキー 23 など |
| 本物らしい秘密が見つかった組織 | 63（多くはさまざまな規模のソフトウェアの会社） |
| 秘密のあるリポジトリで、ファイルが最初にコミットされてからの日数 | 中央値 217 日（11月2日を基準。1 年を超えるリポジトリは 118） |
| 今のファイルには無く、過去の版にだけ残っていた秘密 | 734（509 のリポジトリ。過去の版を調べたのは 43,120 のリポジトリで、Apiiro は下限としている） |
| 同じ秘密を持つフォーク | 211（74 のリポジトリから） |
チームで共有する .claude/settings.json | 76,011 個を調べ、298 個に秘密 |
| 過去の版・共有の設定・会話の記録まで含めた合計 | 2,539 の秘密（1,994 のリポジトリ） |
1,379 個の秘密の 3 分の 1 以上は、データベースに直接入れるものでした（データベースのパスワード 379 と、Supabase の service-role の鍵 122）。過去の版にだけ残る 734 は、多くがファイルを消したためだそうです（Apiiro）。
数え方にも注意が要ります。Apiiro の言う「本物の秘密」は、決まった形の鍵か、公開のサーバーの宛先と同じ行にあるパスワードやトークンで、除外の規則と、別の AI（LLM）による確認の両方が本物と判断した物だけです。実際に使えるかは試していません（秘密を使わず、サーバーにも接続していないと書いています）。ただ、11月2〜3日に知らせた組織のうち 1 社は、鍵が有効だったと認めたそうです。
Apiiro は「GitHub は数えられた場所にすぎない」とも書き、Hugging Face（AI のモデルやアプリを公開するサービス）や GitLab.com（GitHub と同じくリポジトリを置くサービス）でも同じファイルに秘密を見つけています。また、16 の AI のコーディングの道具の説明書を比べ、承認したコマンドをそのまま既定でプロジェクトのファイルに書くと確かめられたのは Claude Code だけだった、としています。
自社のリポジトリと手元のPCの確かめ方
確かめる場所は 3 つです。Apiiro が「影響を受けているかの確かめ方」として挙げた順に、GitHub の今のファイル、git の過去のコミット、手元の PC を見ます。チームで共有する .claude/settings.json も、同じように調べてください。
| 場所 | 分かること | 使うもの |
|---|---|---|
| GitHub の検索 | 今のファイル（既定のブランチ）。公開のリポジトリなら、今だれでも読める状態か | org: と path: の検索 |
| git の過去のコミット | 今は消えていても、過去に一度でもコミットされたか | git log --all --full-history |
| 手元の PC | コミットしていないファイルの中身。zip・npm・同期フォルダで外へ出ていないか | ファイルを開く・/permissions |
GitHub の検索で今のファイルを探す
GitHub のコードの検索では、org: で組織を、path: でファイルのパスを絞れます（GitHub の検索の書き方の説明）。ORG_NAME を自社の組織名に替えて、2 つのファイルを探します。
org:ORG_NAME path:.claude/settings.local.json
org:ORG_NAME path:.claude/settings.jsonpath: は、パスのどこかにその語を含むファイルに一致します。ただし、GitHub の公式の文書によると、GitHub のコードの検索は今のところ既定のブランチしか探しません。すべてのコードを索引しているわけではなく（とても大きなリポジトリは索引されないことがあります）、すべてを探し切る検索には対応しておらず、結果は 100 件までです。path: で似た中身のファイルが複数のリポジトリにあると一部しか出ず、ページ下の「Show identical files」で広げられます。検索に出なかったことだけで「無い」とは判断せず、ほかのブランチと過去のコミットも含めて、次の git で各リポジトリを確かめます。
git の過去のコミットを見る
リポジトリを手元にクローンして、次のコマンドを打ちます。--all はすべてのブランチやタグを対象にする指定で、-- の後ろのパスのファイルがどう変わってきたかを示すコミットだけが並びます（git の公式の文書）。
git log --all --full-history -- .claude/settings.local.json
git log --all --full-history -- .claude/settings.json--full-history は、既定では省かれる枝（合流した結果が同じになる枝）も省かずに見る指定です（git の公式の文書）。付けないと、枝の中でファイルを足して消してから合流させた履歴が出ないことがあります。
1 件でもコミットが出れば、そのファイルは過去にコミットされています。今の版に無くても、中にあった秘密は、そのリポジトリを読める人と、フォークやクローンを持つ人に渡っていると考えます。Apiiro も「履歴にあれば、すべてのフォークとクローンにもある」と書いています。
作り直す秘密を洗い出すには、git log --all --full-history -p -- .claude/settings.local.json のように -p（各コミットの変更の中身を表示する指定）を付けると、過去の版に入っていた規則が読めます（git の公式の文書）。画面に秘密が出るので、AI のエージェントの中ではなく、ふつうのターミナルで打ちます。
サブフォルダから起動していた場合も見てください。v2.1.211 より前の Claude Code は起動したフォルダにこのファイルを作り、今も Windows や git の外では起動したフォルダの .claude に置きます（公式ドキュメント）。そのパスでも同じコマンドを打ちます。
手元の PC のファイルを開いて読む
コミットしていなくても、ファイルは PC に平文で残っています。Apiiro は、PC にあるこのファイルをすべて探して開き、allow の一覧を読むよう勧めています。1 行ずつが、承認したコマンドです。パスワード、トークン、鍵、接続の文字列（データベースの宛先とパスワードを 1 行にした物）がないかを見ます。
Claude Code の中では、/permissions で許可の規則と、それぞれの出どころの設定ファイルを一覧でき、規則を消すこともできます（公式ドキュメント）。権限まわりのコマンドは「Claude Code コマンド一覧｜使い方・カスタム・許可」にまとめています。
見る順番は、大きなファイルからが効率的です。Apiiro の調査では、8KB を超えるファイルは 10 個に 1 個に秘密があり、500 バイト未満では 500 個に 1 個未満でした。また Apiiro は、公開した npm のパッケージ、コピーの命令で作った Docker のイメージ、zip の書庫、同期しているフォルダから、git を通らずに外へ出る道も挙げています。社外に渡した成果物も確かめましょう。
1 つ気をつけたいのは、この確認を Claude Code などの AI に頼まないことです。ファイルを AI に読ませると、中の秘密もそのまま AI に渡ります。人が開いて読み、秘密を含む規則を消してください。
検出の道具だけに任せない理由
秘密を見つける道具（シークレットスキャナー）を通したから大丈夫、とは言えません。Apiiro は 104,185 個のファイル全部に、一般的な秘密の検出の道具である gitleaks と TruffleHog を、有効かどうかの確認なしで走らせました。秘密のある 1,122 個のうち、gitleaks が見つけたのは 564 個、TruffleHog は 643 個で、215 個はどちらも見逃しました。
理由は、道具が「決まった形の鍵」を探しているからです。データベースや SSH につなぐ時の PGPASSWORD=、sshpass -p、mysql -p の後に打ったパスワードや、curl で API のトークンを渡す bearer のヘッダーは、ふつうのコマンドの中のふつうの語に見えて、ほとんど素通りします。道具が何も出さなくても、allow の一覧は目で読みましょう。GitHub 側の秘密の検出の仕組みは「GitHub シークレット 漏えい検出｜専用モデル」で説明しています。
見つかった時の順番と、戻せるか
秘密が見つかったら、Apiiro の言うとおり「まず作り直し、片付けはその後」です。GitHub の公式の文書も、消したい物がパスワードやトークンなら、最初の手順は無効にするか作り直すことだと書いています。順番は次の 5 つです。
- 秘密を作り直す：ファイルが一度でも持っていた秘密は、すべて無効にして新しい物に替えます（Apiiro は「ファイルが持ったことのある認証情報はすべて」と書いています）。中でも、公開のサーバーの宛先と組になったパスワードやトークンは、実際に入れてしまう物なので先に手を付けます。
- 使われた跡を確かめる：作り直した秘密のサービスで、身に覚えのない接続や操作がないかを、アクセスの記録で確かめます。記録の場所と残る期間はサービスごとに違うので、各サービスの説明で確かめてください。
- 規則を消して追跡をやめる：ファイルから秘密を含む規則を消します。リポジトリで追跡されているなら
git rm --cached .claude/settings.local.jsonで追跡をやめ、リポジトリの .gitignore に足してコミットします。--cachedは、git の管理からだけ外し、手元のファイルは残す指定です（git の公式の文書）。 - 過去のコミットから消すか決める：GitHub の文書は、作り直して秘密が使えなくなれば、それで足りる場合もあるとしています。書き換えには、古いクローンから再び押し戻される、コミットの番号が変わる、といった副作用があるからです。消す時は、GitHub の文書にある git-filter-repo（過去のコミットからファイルを消す道具）の手順に沿って進めます。
- 外へ出た写しを洗い出す：フォーク、メンバーのクローン、npm のパッケージ、Docker のイメージ、zip の書庫、同期しているフォルダなど、ファイルが写った先を一覧にします。過去のコミットを書き換えた時は、メンバーにはクローンの片付けを、フォークの持ち主には秘密を消すかフォークごと削除するよう頼みます（GitHub の文書。GitHub はフォークの持ち主の連絡先を教えられないとしています）。
戻せるか：使えなくはできるが、公開した事実は戻せない
作り直せば、漏れた秘密はそれ以上使えなくなります（GitHub の文書）。ただし、作り直す前にすでに使われていた場合、入られた後の被害（別の鍵やアカウントを作られた、データを持ち出されたなど）は、作り直しだけでは止まりません。2 番目の手順で、使われた跡を確かめてください。一方で、公開してしまったファイルそのものは取り戻せません。GitHub の文書は、他の利用者のクローンから機密の情報を消すことはできず（各自に手順を渡して消してもらう）、フォークに残ったコミットはそこで読み続けられる（持ち主に、消すかフォークごと削除するよう頼む）と書いています。GitHub のサポートが消すのは、GitHub 上に残った古い表示とプルリクエストの中の参照で、それも作り直しでは危険を防げないと判断した場合に限るとしています。
つまり、「ファイルを消す」「過去のコミットを書き換える」は片付けで、身を守るのは作り直しです。1 番目を飛ばして 3 番目から始めると、秘密が使える状態のまま、片付けたつもりになってしまいます。正直、ここがいちばん間違えやすいところです。
この記事の内容を社内で使うなら
要点と手順をまとめた資料を無料で受け取れます。研修6,000名以上・支援100社以上の実績をもとに、自社の業務に当てはめる相談も30分から受け付けています。
これから秘密を残さない4つのやり方
残さないための手は 4 つです。Apiiro が開発者に勧めた手と、Claude Code の公式ドキュメントにある許可の書き方を合わせて表にしました。
| やり方 | 中身 | 効く理由 |
|---|---|---|
| リポジトリの .gitignore に足す | .claude/settings.local.json をリポジトリの .gitignore に書き、その変更もコミットする | どのクローンでも効く。GitHub の文書も、.gitignore の変更をコミットして push すれば、ほかの開発者も守られると書いている |
| 秘密は変数で渡す | コマンドに値を打たず、秘密の管理の仕組みから $DB_URL のような変数で参照する | 規則には $DB_URL と残る。秘密の値そのものは残らない（Apiiro） |
| パターンで許可する | 1 つのコマンドそのままではなく、変わる所を * にして Bash(npm run *) のように許可する | 公式ドキュメントの書き方。Apiiro は Bash(npm run:*) と書いており、末尾の :* は同じ意味（公式ドキュメント） |
| 表示を読んでから承認する | 「Yes, and don’t ask again for:」の後ろに出ている中身を読み、パスワードやトークンが見えたら、その回だけの「Yes」を選ぶ | この選択肢は、許す範囲を全部画面に見せられる時だけ出る（公式ドキュメント）。見えている中身がそのまま規則になるので、秘密があれば Yes だけ |
変数で渡す時の置き場は、PC の秘密の管理の仕組みが向いています。macOS なら Keychain に API キーを入れて Claude Code から使う方法を、「macOS KeychainでAPIキー管理｜Claude Code」で説明しています。
あわせて、Claude Code に秘密のファイルを読ませない設定もあります。公式ドキュメントの例の Read(./.env) を deny（拒否）の規則に入れると、Claude Code の読み込みの道具や cat などでの .env の読み込みを止められます。ただし、スクリプトが自分で開くファイルには効かず、OS の段で止めるには sandbox（シェルのコマンドとそこから動くプロセスが触れるファイルと通信を、OS の機能で絞る仕組み）を使うよう書かれています。
会社として決めること（AIのエージェントを使う会社向け）
個人の設定だけに任せると、新しく入った人の PC から同じことが起きます。Apiiro がセキュリティの担当向けに勧めた手を土台に、AI のエージェントを使う会社として決めておきたいことを並べます。
エージェントのフォルダを .env と同じ扱いにする
Apiiro は、.claude/ のようなエージェントのフォルダやメモのファイルを、PC でもリポジトリでも .env と同じく秘密を持ちうる物として扱うよう勧めています。具体的には、コミットの前と CI（自動の検査）の秘密の検出に入れて過去のコミットまで調べ、コマンドの中のパスワード（PGPASSWORD= など）も拾えるようにすること。組織で使う .gitignore の雛形に .claude/settings.local.json を入れておくことです。Apiiro は、リポジトリに保存されたエージェントの会話の記録や、メモのファイル（MEMORY.md など）、引き継ぎのメモにも同じ形で秘密を見つけています。
AI に渡す秘密の範囲を絞る
エージェントが使う秘密は、漏れる前提で範囲を決めておくと、作り直しが楽になります。JPCERT/CC は 2026年10月の注意喚起（JPCERT-AT-2026-0030）で、API トークンには必要最小限の権限だけを付け、適切な有効期限を設け、不要になった物や漏えいが疑われる物はすぐ無効化できるようにする、と書いています。国内で続いた不正アクセスへの注意喚起で、API を運用する側への対策として書かれていますが、同じ考え方はエージェントに渡すトークンにも使えます。本番のデータベースの所有者のパスワードを手元の調べ物に使わない、という線も決めておきたいところです。
承認の決まりを、管理者の設定でそろえる
「Yes, and don’t ask again」を使ってよい場面は、社内で決めておくと迷いません（例: 秘密を含まないコマンドだけ、パターンで）。管理者が組織の PC にまとめて入れる設定（managed settings）の allowManagedPermissionRulesOnly を使うと、許可の規則の出どころを管理者の設定だけにでき、確認の画面から「Yes, and don’t ask again」のような常に許す選択肢が消え、新しい規則も保存されなくなります。利用者やプロジェクトのファイルにある allow・ask・deny の規則は無視されるので、Read(./.env) のような deny の規則も管理者の設定に入れます（公式ドキュメント「All settings」）。ファイルに残っている規則が消えるわけではないので、上の確認と作り直しは別に進めます。便利さとの引き換えなので、試す部署から始めるのが現実的です。IT 管理者向けの導入の全体は「Claude Code 法人導入完全ガイド｜IT管理者向け」、会社として入れる時の対策は「Claude Codeセキュリティ設定｜企業導入の必須対策」にまとめています。
新しく入る人に、最初に伝える
Claude Code を使い始める人には、初日に 3 つだけ伝えておくと効きます。コマンドに秘密を打たない（変数で渡す）、「Yes, and don’t ask again」を選ぶ前に表示を読む、.claude/settings.local.json は秘密を持ちうるファイルなのでコミットしない、の 3 つです。教育だけで防げるわけではないので、上の検出や .gitignore の雛形と組み合わせてください。
【要注意】この件でよくある読み違い4つ
報道の見出しだけを読むと、手当ての順番を取り違えやすい件です。よくある読み違いを 4 つ挙げます。
読み違い1：ファイルを消せば済む
❌ リポジトリから .claude/settings.local.json を消せば、もう大丈夫
⭕ 消しても、過去のコミットとフォークに残ります。Apiiro の調査では、今のファイルには無く過去の版にだけ残っていた秘密が 734、同じ秘密を持つフォークが 211 ありました。先に秘密を作り直し、片付けはその後です。
読み違い2：コミットしていなければ安全
❌ git に入れていないから、うちは関係ない
⭕ ファイルは承認した人の PC に平文で残り、npm のパッケージや Docker のイメージ、zip の書庫、同期しているフォルダから外へ出ることもあります（Apiiro）。Apiiro は、2025年9月に npm で広がったマルウェアが、感染した PC のファイルに秘密の検出の道具を走らせた例も挙げています。一度承認した秘密は、規則を消すまで残り続けます。
読み違い3：秘密の検出の道具が通れば大丈夫
❌ スキャナーで何も出なかったから問題ない
⭕ 秘密のある 1,122 個のうち 215 個は、gitleaks と TruffleHog の両方が見逃しました（Apiiro）。見逃しの多くは、コマンドの中に打ったパスワードで、決まった形をしていないからです。allow の一覧は目で読みます。
読み違い4：Claude Code が勝手に秘密を盗んで公開した
❌ Claude Code が秘密を集めて、外に出した
⭕ 保存されるのは人が承認したコマンドで、置き場は手元のファイルです。外へ出たのは、そのファイルがリポジトリと一緒に公開されたからです。Claude Code はファイルを PC の git の除外に足していますが、その守りは 1 台の PC の中だけです。ただし Apiiro は、Claude を共同作成者とするコミットがこのファイルを変えていた例も多いと書いています。コミットを任せる時は、何が入ったかを人が見ましょう。
よくある質問
今のリポジトリに settings.local.json が無ければ安全ですか？
言い切れません。過去に一度でもコミットしていれば、過去のコミットとフォーク・クローンに残っています。git log --all --full-history -- .claude/settings.local.json で確かめ、承認した人の PC のファイルも開いて読みます。
「Yes, and don’t ask again」はもう使わないほうがいいですか？
秘密を含まないコマンドなら使ってかまいません。選ぶ前に「for:」の後ろの表示を読み、パスワードやトークンが見えたら、その回だけの「Yes」を選びます。よく使うコマンドは Bash(npm run *) のようなパターンで許可しておきます。
.gitignore に入れたのに、なぜコミットされることがあるのですか？
除外の設定は、すでに追跡しているファイルには効かないからです（git の公式の文書）。git rm --cached で追跡をやめてから .gitignore に足します。Claude Code が足す除外は PC ごとの設定なので、リポジトリの .gitignore にも書いてコミットしておきます。
秘密を作り直したら、過去のコミットから消さなくてもよいですか？
GitHub の公式の文書は、作り直して秘密が使えなくなれば、それで足りる場合もあるとしています。書き換えには副作用があるので、ファイルに秘密以外の情報（社内のサーバーの名前など）が入っていないかも見て決めてください。
Anthropic はこの件に対応しましたか？
2026年11月8日時点で、Anthropic の公式の発表は確認できませんでした。変更履歴（v2.1.319 まで）にも、承認した規則を保存する時に中の秘密を伏せる、または保存しないといった変更の記載は見当たりません。利用者の報告（issue #5544）は、2026年1月3日に自動で閉じられています。
非公開のリポジトリなら問題ありませんか？
Apiiro が数えたのは公開のリポジトリだけです。非公開でも、そのリポジトリを読める人と、クローンした PC には同じ秘密が渡っています。後から公開に切り替える場合も考えると、見つかった秘密は作り直しておくのが安全です。
まとめ：今日やる順番
Claude Code の「Yes, and don’t ask again」は便利な機能ですが、承認したコマンドが秘密ごと .claude/settings.local.json に残ることがあります。2026年11月8日時点で Anthropic の公式の発表は確認できていないので、利用している会社の側で、次の順に進めましょう。
- GitHub の組織で
.claude/settings.local.jsonと.claude/settings.jsonを検索し、各リポジトリでgit log --all --full-historyを打って過去のコミットも確かめる - 秘密が見つかったら、ファイルを消す前に作り直し、使われた跡をアクセスの記録で確かめる
- 秘密を含む規則を消し、
git rm --cachedで追跡をやめ、リポジトリの .gitignore に足してコミットする - 手元の PC のファイルも開いて読み、秘密があれば同じく作り直してから規則を消す。これからはコマンドに秘密を打たず、変数とパターンで許可する
会社としては、組織の .gitignore の雛形と秘密の検出に .claude/ を入れておくと、新しく入った人の PC からの再発も減らせます。
参考・出典
- Coding Agents Copy Your Secrets to a Hidden File. Thousands Are on GitHub — Apiiro（2026年11月5日・参照日: 2026-11-08）
- Configure permissions — Claude Code Docs（Anthropic・参照日: 2026-11-08）
- Settings files and precedence — Claude Code Docs（Anthropic・参照日: 2026-11-08）
- Choose a permission mode — Claude Code Docs（Anthropic・参照日: 2026-11-08）
- All settings — Claude Code Docs（Anthropic・参照日: 2026-11-08）
- Issue #5544: approved bash commands containing credentials are stored as is with plain text credentials in settings.local.json — GitHub anthropics/claude-code（参照日: 2026-11-08）
- Release v2.1.319・CHANGELOG.md — GitHub anthropics/claude-code（参照日: 2026-11-08）
- Understanding GitHub Code Search syntax — GitHub Docs（参照日: 2026-11-08）
- About GitHub Code Search — GitHub Docs（参照日: 2026-11-08）
- Removing sensitive data from a repository — GitHub Docs（参照日: 2026-11-08）
- git-log Documentation・git-rm Documentation・gitignore Documentation — Git（参照日: 2026-11-08）
- 直近で相次いでいる国内組織における不正アクセスに関する注意喚起（JPCERT-AT-2026-0030） — JPCERT/CC（2026年10月8日公開・10月23日更新・参照日: 2026-11-08）
- Claude Code’s “Don’t Ask Again” File Exposes Passwords and Keys in 1,122 Public Copies on GitHub — The Hacker News（2026年11月7日・参照日: 2026-11-08）
この記事の内容を社内展開する方へ: Claude Code × ビジネス活用 実践ガイド（無料・PDF 30ページ＋Excel） をダウンロードできます。
