Claude Codeのセキュリティ｜「今後確認しない」から鍵が漏れる仕組み
この記事の要点
- Claude Codeで「今後は確認しない」を選ぶと、承認したコマンドがそのまま .claude/settings.local.json に保存されます。コマンドにパスワードや鍵が入っていれば、それも平文で残ります。
- Apiiroの調査では、公開GitHubにある同ファイル104,185件のうち1,122件に秘密情報がありました。履歴や共有設定なども含めると1,994リポジトリで2,539種類です（形式で判定、有効性は未確認）。
- Claude Codeはこのファイルをパソコン全体のgit除外設定に加えますが、リポジトリ自身の .gitignore には書きません。別のパソコンでのクローンや、すでにコミット済みのファイルは守られません。
- 秘密を含む1,122件のうち215件は、gitleaksとTruffleHogを両方かけても検出されませんでした。主に、コマンドに打ち込まれたパスワードが鍵の形式に合わないためです。
- 今週中に、公開・社内のリポジトリと履歴でこのファイルを探し、社員のパソコン内のファイルも開いて確認してください。秘密が見つかったら、ファイルを消す前に鍵やパスワードを作り直します。
Claude Code（Anthropic のAIコーディングツール）でデータベースの確認やAPIの呼び出しを頼むと、パスワードや鍵を含んだコマンドが提案され、実行してよいかを尋ねられることがあります。そこで「Yes, and don't ask again（はい、今後は確認しない）」を選ぶと、そのコマンドが秘密情報ごとプロジェクト内の設定ファイルに保存されます。セキュリティ企業 Apiiro は2026年11月5日、このファイルが公開 GitHub の1,122件に秘密情報を含んだまま置かれていたと公表しました[1]。
同じ週に Microsoft は、AIエージェント型の攻撃ツールで GitHub 上の鍵を探し、見つけた鍵でクラウドに侵入する攻撃者を報告しています[6]。社員が Claude Code を使っている会社なら、開発部門に限らず関係があります。
この記事では、鍵がなぜ設定ファイルに残るのか、Claude Code の git 除外がどこまで効くのか（git の挙動を編集部で確かめました）、自社が影響を受けているかの確かめ方、再発を防ぐルールを順に整理します。情報は2026年11月8日時点のものです。
何が起きたのか？
Apiiro は2026年11月1〜3日に公開 GitHub を検索し、Claude Code の個人用設定ファイル .claude/settings.local.json を104,185件集めました。このうち1,122件（1.1%）に、データベースのパスワードやクラウドの鍵などの秘密情報が含まれていました[1]。
見つかった中には、データベース製品の提供企業自身の管理者権限つきクラウド鍵、本番の Azure Postgres のパスワード、決済サービス Square の本番トークン、医療記録アプリのデータベース所有者パスワードがありました。Apiiro は11月2〜3日に各組織へ連絡し、1社が「鍵は有効だった」と認めています[1]。
2025年8月11日
利用者が GitHub で不具合として報告
承認したコマンドが資格情報ごと平文で保存されるという報告。2026年1月3日に60日間動きがないとして自動でクローズ[4]。
2025年12月4日
同様の報告が重複扱いに
トークンが保存され git の除外もされないという報告が、重複として自動でクローズ[5]。
2026年8月〜
AIエージェントで GitHub の鍵を探す攻撃
Microsoft が、AIエージェント型の攻撃フレームワークで GitHub を大量に検索する攻撃者を観測[6]。
11月1〜3日
Apiiro が公開 GitHub を調査
読み取り専用の検索で、既定ブランチの設定ファイルを収集[1]。
11月5日
Apiiro と Microsoft が公表
なぜパスワードが設定ファイルに残るのか？
「今後は確認しない」の許可は、承認したコマンドの文字列そのものを許可ルールとして保存する仕組みだからです。コマンドの中にパスワードが書かれていれば、ルールにもそのまま残ります。これはAIモデルではなく Claude Code というツールの動作で、Apiiro は最新モデルでも再現したとしています[1]。
Claude Code の公式ドキュメントも、Bash コマンドの確認で「Yes, and don't ask again」を選ぶと、その承認を許可ルールとして .claude/settings.local.json に保存すると説明しています[2]。保存先は原則としてリポジトリのいちばん上の階層で、サブフォルダで作業していても同じ1つのファイルに書かれます。Windows や git 管理外のフォルダなど、一部の条件では保存先が変わります[3]。
「Yes, and don't ask again」を選ぶと、その正確なコマンドを、秘密情報も含めて、プロジェクトフォルダ内の .claude/settings.local.json に保存します。
Pick "Yes, and don't ask again" and it saves that exact command, secret included, to .claude/settings.local.json inside the project folder.
なぜコマンドに秘密が入るのでしょうか。開発者のパソコンには、データベースの接続文字列や .env（鍵などを書いておく設定ファイル）が置かれています。「ステージング環境でログインが失敗する理由を調べて」と頼めば、Claude が提案するコマンドには接続に必要なパスワードが入ります。確認は1回の作業で何度も出ます[1]。編集部の見方では、そのたびに承認するのが面倒になり、「今後は確認しない」を選びたくなる場面は多いと考えられます。
許可を重ねるほどファイルは大きくなり、秘密を含む割合も上がります。8KBを超えるファイルでは10件に1件に秘密がありましたが、500バイト未満では500件に1件未満でした[1]。長く使っている人ほど注意が必要です。
Claude Code は git から外してくれるのではないのか？
外してくれますが、それはパソコン単位の設定です。Claude Code は git リポジトリの中でこのファイルを初めて作るとき、**/.claude/settings.local.json をそのパソコンの「グローバル除外ファイル」に追加します。ただし、リポジトリ自身の .gitignore には書きません[2][1]。
このため、いくつかの場面で守りが外れます。Apiiro は、後から git リポジトリになったフォルダ、別のパソコンでのクローン、すでにコミット済みのファイルを挙げています[1]。公式ドキュメントも、手でこのファイルを作った場合は自分で .gitignore に加えるよう求めています[2]。
編集部は2026年11月8日、ダミーの値を入れた設定ファイルで git の挙動を確かめました。Claude Code 自体は動かしておらず、git が除外をどう扱うかだけを見ています。結果は次のとおりです。
| 条件 | 結果 | 意味 |
|---|---|---|
| グローバル除外があるパソコン | 除外される（git status に出ない） | Claude Code が書いた除外が効く |
| 除外のない別のパソコン・CI環境 | 未追跡ファイルとして表示される | git add . で一緒にコミットされる |
| すでにコミット済みのファイル | 変更が「変更あり」として表示される | 除外は追跡中のファイルに効かない |
git rm --cached ＋ リポジトリの .gitignore | 追跡が外れ、別のパソコンでも除外される | リポジトリ側で守る設定になる |
| 上の処理をした後の履歴 | 過去のコミットに秘密が残る | 鍵の作り直しが必要 |
2026年11月8日、git の標準機能で編集部が確認。グローバル除外のない環境は、git のグローバル設定を空にして再現した。
Apiiro の調査では、秘密を含み、履歴を追跡できた1,105リポジトリのうち539で、Claude が共著者として記録されたコミットがこのファイルを変更していました[1]。Claude 自身がこのファイルを含めてコミットしていることも多いということです。
どんな秘密が、どれだけ見つかったのか？
現行のファイルにあった1,379種類の秘密のうち、3分の1以上はデータベースに直接入れるものでした。内訳はデータベースのパスワード（379）と、Supabase の service-role 鍵（122）です[1]。
| 種類 | 件数 | 持っていると何ができるか |
|---|---|---|
| データベースのパスワード | 379[1] | データベースへの直接ログイン |
| Supabase の service-role 鍵 | 122[1] | データベースを直接操作 |
| Supabase のアカウントトークン | 103[1] | アカウント内のすべてのプロジェクトを操作 |
| SSH のログイン情報 | 43[1] | 公開サーバーへのログイン（root を含む） |
| GitHub・GitLab・npm のトークン | 42[1] | ソースコードやパッケージの操作 |
| AWS の鍵 | 23[1] | クラウド資源の操作 |
1,379種類の内訳の一部（Apiiro、2026年11月1〜3日の収集）。残りは主に外部サービスのAPIトークンとAIモデルの鍵。「実際の秘密」は形式や接続先から判定したもので、有効かどうかは試していない。
ファイルを消しても終わりません。過去の版には、現在のどのファイルにもない秘密が509リポジトリで少なくとも734件ありました。211件のフォーク（他人がコピーしたリポジトリ）にも同じ秘密が残っていました[1]。秘密を含むリポジトリでは、ファイルが最初にコミットされてから調査時点まで中央値で217日たっており、118リポジトリでは1年を超えていました[1]。
このファイル以外にも秘密は残っていました。チームで共有するためにコミットされる .claude/settings.json は76,011件中298件、AIとの会話記録の書き出しは、確認した2,523件のうち120件に秘密を含んでいました[1]。Apiiro は16のコーディングエージェントの仕様をドキュメントで比べ、承認したコマンドを既定で丸ごとプロジェクト内のファイルに書くと確認できたのは Claude Code だけだとしています[1]。
秘密情報の検査ツールで見つけられないのか？
1つのツールだけでは半数近くを見逃し、2つを両方かけても5件に1件ほどは見逃されます。Apiiro が代表的な検査ツールの gitleaks と TruffleHog を全ファイルにかけたところ、秘密を含む1,122件のうち、gitleaks は564件、TruffleHog は643件を検出し、215件はどちらでも検出されませんでした[1]。
見逃しの主な原因は、コマンドの中に打ち込まれたパスワードです。検査ツールは主に、事業者ごとの決まった接頭辞や長いランダムな文字列で鍵を見分けます。PGPASSWORD= や sshpass -p、mysql -p の後ろに書かれたパスワードや、curl の認証ヘッダーは、普通のコマンドの一部に見えてしまいます[1]。
GitHub の利用者向けプッシュ保護は既定で有効で、公開リポジトリへの秘密のプッシュを止めます[8]。一方、データベースの接続文字列のような汎用の形式や、形式のないパスワードの検出は、リポジトリ側で有償の Secret Protection を有効にしたときの機能で、AIによるパスワード検出はプレビュー段階です[8]。編集部の見方では、既定の設定のままでは、コマンドの中のパスワードを止める仕組みとしては頼れないと考えたほうが安全です。
GitHub に上げていなければ安全なのか？
安全とは言えません。このファイルは、「今後は確認しない」を選んだすべてのパソコンに、平文のJSONとして残っています。Apiiro は、開発者のパソコンから資格情報をまとめて集めるマルウェアがすでに存在すると指摘しています[1]。
2025年9月の npm ワーム「Shai-Hulud」は、感染したパソコンで TruffleHog を動かして秘密を探しました。TruffleHog は今回の1,122件のうち643件を検出します[1]。ファイルは git を通らなくても、npm パッケージや Docker イメージ、zip ファイル、同期フォルダに紛れて外へ出ることがあります[1]。
公開された鍵を探す側も速くなっています。Microsoft は2026年8月以降、AIエージェント型の攻撃フレームワークが対象組織の名前やクラウドの用語を組み合わせて GitHub を大量に検索する様子を観測しました。ある事例では、GitHub での探索から Azure Key Vault（鍵の保管庫）のデータ持ち出しまで5分でした[6]。AIサービスの鍵が繰り返し狙われていたことも報告されています[6]。
公開された資格情報は、元の場所を後から編集・削除していても、侵害されたものとして扱ってください。
Treat credentials that have been publicly exposed as compromised, even if the original location has subsequently been edited or deleted.
漏れた鍵は、無効にしない限り使える状態が続きます[6]。Truffle Security は、昨年 GitLab と Bitbucket で見つけて報告した有効な鍵21,981件のうち81%が、半年後もまだ使えたとしています。同社の分析では、有効な鍵を漏らしたコミットのうちAIエージェントが署名したものは、2025年半ばまでゼロでしたが、2026年5月には6.8%になりました[7]。
自社が影響を受けているか、どう確かめるか？
確かめる場所は3つです。公開されているか、過去にコミットされたことがあるか、社員のパソコンに何が入っているか。秘密が見つかったら、ファイルの削除より先に鍵やパスワードを作り直します[1]。
今週中に確認すること
- GitHub の組織内で
.claude/settings.local.jsonと.claude/settings.jsonを検索する。公開リポジトリで見つかったものは、誰でも読める状態にある[1] - 各リポジトリで
git log --all -- .claude/settings.local.jsonを実行し、過去に一度でもコミットされていないか確かめる。履歴にあれば、フォークやクローンにも残っている[1] - 社員のパソコンにある
settings.local.jsonを開き、allowの一覧にPGPASSWORD=、sshpass -p、mysql -p、Bearer、://ユーザー名:パスワード@のような記述がないか確認する[1] - 見つかった鍵・パスワードは、まず作り直して古いものを無効にする。そのあと許可ルールから削除する[1][6]
- 作り直した鍵について、使われた記録（ログイン履歴・API の利用履歴・請求）を確認する[6]
- 共有の
.claude/settings.jsonも同じように確認する。チームでコミットする前提のファイルで、298件に秘密が含まれていた[1]
コミット済みのファイルは、git rm --cached .claude/settings.local.json で追跡から外し、リポジトリの .gitignore に加えます[1]。編集部の再現でも、この2つをそろえると、グローバル除外のない環境でもファイルが表に出なくなりました。ただし、過去のコミットに残った値は消えません。
再発を防ぐには何を決めればよいか？
コマンドに秘密を書かないこと、許可は具体的なコマンドではなく型で与えること、AIの設定フォルダを .env と同じ扱いにすること。この3点を社内ルールにします[1]。
- 秘密は環境変数で参照する。 パスワードをコマンドに直接打たず、秘密情報の管理ツールから
$DB_URLのような変数で渡す。こうすれば、許可ルールに残るのは変数名だけになる[1] - 許可は型で与える。 1つのコマンドを丸ごと承認するのではなく、
Bash(npm run test *)のような前方一致のルールを自分で書く[1][3] - リポジトリの
.gitignoreに入れる。 組織の.gitignoreのひな型に.claude/settings.local.jsonを加え、パソコンごとの設定に頼らない[1] - AIの設定フォルダを秘密の置き場所として扱う。
.claude/、.cursor/、.gemini/、会話記録やメモのファイルを、.envと同じく検査の対象にする。パソコンもリポジトリも対象[1] - コミット前とCIで履歴まで検査する。 検査ツールが、コマンドの中のパスワード（
PGPASSWORD=など）も拾えるか確かめてから入れる[1] - Claude に鍵ファイルを読ませない。
Read(./.env)のような拒否ルールで、Claude のファイル読み取りから鍵の置き場所を外す[3]
鍵の作り直しを後回しにしないことも大切です。Microsoft は、秘密に頼る認証からマネージドID（クラウドが自動で管理する認証）へ移すことを勧めています[6]。長く使える鍵を減らせば、漏れたときの被害も小さくなります。
AIツールの利用ルールで見直す点
AIエージェントは、承認の記録や会話の記録、メモといったファイルを自分で書き残します。人が意識しないうちに、そこへ秘密が入ります。利用ルールには「何を入力してよいか」に加えて、「AIが書き残すファイルをどう扱うか」を入れる必要があります[1]。
Apiiro は、同じ「コマンドの中のパスワード」が、会話記録、メモ、引き継ぎメモなど、エージェントが実行内容を記録するあらゆる場所に現れると指摘しています[1]。AI利用の全体像はAIセキュリティとはで、エージェントの設定ファイルを悪用する別の手口はAIエージェントの指示ファイル乗っ取りで解説しています。漏れた鍵が高額請求につながる流れはLLMjackingの記事を参照してください。
まとめ
Claude Code の「今後は確認しない」は、承認したコマンドを文字どおり .claude/settings.local.json に保存します。コマンドに秘密が入っていれば、それも平文で残ります。公開 GitHub では1,122件のファイルから秘密が見つかりました[1][2]。
Claude Code の git 除外はパソコン単位で、別のパソコンやコミット済みのファイルは守りません。代表的な検査ツールでも、コマンドの中のパスワードは見逃されることがあります[1]。AIエージェントを使う攻撃者が、GitHub での探索から5分でデータを持ち出した事例も報告されています[6]。
今週は、リポジトリと履歴、社員のパソコンの3か所でこのファイルを確認し、見つけた鍵を作り直してください。そのうえで、コマンドに秘密を書かない、リポジトリの .gitignore で守る、AIの設定フォルダを検査対象にする、という3つのルールを決めます。AI利用の社内ルールの考え方はよくある質問でも紹介しています。
よくある質問
settings.local.json とは何ですか？
Claude Code がプロジェクトごとに使う個人用の設定ファイルです。.claude フォルダの中にあり、権限の確認で「Yes, and don't ask again（今後は確認しない）」を選ぶと、承認したコマンドが許可ルールとしてここに保存されます。本人のパソコンだけで使う前提のファイルです。
Claude Code はこのファイルを git から自動で除外しないのですか？
git リポジトリの中で初めてファイルを書くとき、そのパソコンのグローバル除外ファイルに追加します。ただしリポジトリの .gitignore には書かないため、除外設定のない別のパソコンやCI環境、すでにコミット済みのファイル、手で作ったファイルは守られません。
パスワードが見つかったら、ファイルを消せば大丈夫ですか？
いいえ。ファイルを消しても git の履歴、フォーク、クローンには残ります。Microsoft も、公開された資格情報は元の場所を削除していても侵害されたものとして扱うよう求めています。先に鍵やパスワードを作り直して古いものを無効にし、そのあと許可ルールとファイルを整理してください。
秘密情報の検査ツールを入れていれば見つかりますか？
一部は見つかりますが、見逃しもあります。Apiiro の調査では、秘密を含む1,122件のうち215件が、gitleaks と TruffleHog を両方かけても検出されませんでした。1つだけでは半数近くを見逃しています。主に、コマンドの中に打ち込んだパスワードには決まった形式がないためです。導入前に、こうした書き方も拾えるか確かめてください。
社員に Claude Code を使わせるとき、最低限決めるルールは何ですか？
コマンドにパスワードや鍵を直接書かず環境変数で渡すこと、秘密を含むコマンドは「今後は確認しない」ではなく「今回だけ許可」にすること、リポジトリの .gitignore に .claude/settings.local.json を入れること、の3点です。あわせて、AIの設定フォルダをコミット前の検査対象にします。
出典・参考資料
- 調査レポートCoding Agents Are Leaking Your Secrets to GitHub
- 公式発表Settings files and precedence - Claude Code Docs
- 公式発表Configure permissions - Claude Code Docs
- 投稿[BUG] approved bash commands containing credentials are stored as is with plain text credentials in settings.local.json
- 投稿[BUG] Sensitive tokens stored in .claude/settings.local.json and not ignored by git by default
- 調査レポートThreat actors use agentic AI tooling to find and abuse exposed secrets
- 調査レポートIntroducing the Secrets Revocation Program: revoking 1.4 million live secrets
- 公式発表Push protection
- 投稿VSCode extension: 'always allow' permission grants written to tracked .claude/settings.json instead of gitignored settings.local.json
本記事の事実関係は、2026.11.08 時点で上記の出典をすべて再確認しています。 独立のファクトチェックで全9出典を開き直して照合。指摘（修正6件・要注記12件、サムネイルと題の言い切り）を反映済み。編集部の再現は git の挙動のみで、Claude Code は動かしていない。
AIセキュリティの基本は「AIセキュリティとは」で解説しています。
