「次から聞かないで」で鍵まで保存。Claude Codeの設定ファイルから秘密情報2,539件、Apiiroが公表

まず初めに

「次から聞かないで」というボタンは、面倒くささと引き換えに押すものだ。まさか、その一言が「承認した命令文を、鍵ごと、プロジェクトのフォルダに書き写しておきます」という意味だったとは誰も思わない。便利さの請求書は、いつも設定ファイルの形で届く。

※個人の感想です

仕組み——承認したコマンドが、そのまま許可ルールになる

Claude Codeは通常、シェルコマンドを実行する前に利用者へ許可を求めます。利用者が「Yes, and don't ask again」を選ぶと、その承認はプロジェクトフォルダ内の .claude/settings.local.json に許可ルール（allow rule）として保存され、次回からは同じコマンドが確認なしで実行されるようになります。これはClaude Codeの権限に関する公式ドキュメントにも沿った動作です。

問題は、保存されるのが「パターン」ではなく実際のコマンド文そのものになる場合があることです。データベース接続の確認などで、パスワードやAPIキーえーぴーあいきーを含むコマンドを承認すると、その秘密情報が平文のまま設定ファイルに残ります。Apiiroは、この動作がモデルの種類によるものではなくClaude Code自体の動作であり、最新のOpus 5.5とFable 5.1でも再現したとしています。比較した16のコーディングエージェントの中で、承認した完全なコマンドを既定でプロジェクトファイルへ書き込むことが確認されたのはClaude Codeだけだった、とも述べています。

ファイルが公開されてしまう経路にも触れられています。Claude Codeは、このファイルを初めてgitリポジトリ内に書く際、利用者のグローバルなgit除外リストへファイルを追加し、その端末ではリポジトリに含まれないようにします。しかしこの保護はその端末・その利用者の設定の中だけの話で、リポジトリ自身の .gitignore には入りません。後からリポジトリになったフォルダ、別の端末へのクローン、既にコミット済みのファイルには効かず、保護がプロジェクトと一緒に移動しない、というのがApiiroの指摘です。追跡済みのファイルについては、除外ルールはそもそも適用されません。

実際、秘密情報を含むファイルが変更されたコミットの多くに、Claude自身が共著者として名を連ねていました。Apiiroが追跡した1,105リポジトリのうち539件で、Claudeを共著者とするコミットがこのファイルを変更していたとしています。

見つかった秘密情報の中身

Apiiroの調査は2026年11月1日から3日にかけて、GitHubの公開コード検索などで行われました。中心の数字は次のとおりです。

調査対象	件数	見つかった秘密情報
.claude/settings.local.json の公開コピー	104,185件（103,617リポジトリ）	1,122件のファイルに1,379件
同ファイルの過去の版（git履歴）	—	現在のコピーに無い734件（509リポジトリ）
共有設定 .claude/settings.json	76,011件	298件のファイル
合計（履歴・共有設定・会話記録等を含む）	1,994リポジトリ	2,539件

1,379件の内訳では、提供事業者の形式に合う鍵が636件、公開ホストに向けたパスワードやトークンが743件とされています。種類別ではデータベースのパスワード379件が最多で、Supabaseのサービスロールキー122件、同アカウントトークン103件、公開サーバーへのSSHログイン43件、GitHub／GitLab／npmのトークン42件、AWSキー23件、秘密鍵6件などが挙げられています。影響を受けた組織は63組織とされ、データベース事業者の管理権限のクラウドキーや、医療記録アプリのデータベース所有者パスワードのような強い権限の例も含まれるとしています。

露出の期間も短くありません。秘密情報を含むファイルは、調査時点でいずれもリポジトリのデフォルトブランチ上にあり、初めてコミットされてからの期間の中央値は217日、118リポジトリでは1年を超えていたとしています。フォーク経由でも広がり、74リポジトリの211件のフォークが同じ秘密情報を保持していたとされます。

ただし線引きは必要です。Apiiroは認証情報を一切試しておらず、「実在の秘密情報」とは、事業者の鍵の形式に合うか、公開ホストのアドレスと対になっている値を指し、今も有効だと確認されたものではありません。同社はセキュリティ製品を販売する事業者であり、この集計は同社の調査として読む必要があります。それでも、通知を受けた1組織が自社の鍵が有効だったと確認したという報告は含まれています。

スキャナーは半分ほどしか見つけられない

もう1つの指摘は、既存の秘密情報スキャナーの検出漏れです。Apiiroが1,122件のファイルへ代表的なスキャナー（gitleaksとTruffleHog）をかけたところ、検出できたのはgitleaksが564件、TruffleHogが643件で、215件はどちらも検出しませんでした。

理由は保存場所と形です。スキャナーは既知の鍵の形式を探すのが得意ですが、PGPASSWORD= の後ろや sshpass -p、mysql -p の後ろに書かれたパスワードは、普通のコマンド文の中の普通の単語に見えます。コマンド文ごと保存される形式の漏えいは、従来型の検出と相性が悪い、というのが同社の説明です。

Anthropic側の反応（11月8日の更新）

Apiiroの記事は11月8日に更新され、AnthropicのClaude Code責任者であるBoris Cherny氏が11月7日にHacker Newsで回答した内容が追加されました。同氏は、これまでClaude Codeは秘密情報の除去（スクラブ）を行ってこなかったとしたうえで、防止のために何ができるか検討していると述べ、自動モード（auto mode）でこの問題を捉えることや、基本的な秘密情報スキャンの組み込みなどが検討中の方法として挙げられたとされています。一方で同氏は、ファイル作成時にgitignoreへ追加していることや、公開されたコピーは手動で作成・チェックインされたものだという見解、権限ルールより自動モードの利用や、GitHub側の秘密情報スキャンの有効化も勧めたとされています。修正版や提供時期は示されていません。

利用者が今すぐ確認できること

Apiiroの推奨は、順番が重要です。

1. 自分のリポジトリ（組織のものを含む）で .claude/settings.local.json と .claude/settings.json を検索し、削除済みのファイルも含めてgit履歴まで確認する
2. ファイルに書かれたことのあるパスワード、トークン、鍵を全て交換（ローテーション）する。ファイルの削除だけでは履歴、フォーク、クローンに残った分は消えない
3. ローカルファイルの追跡を外し（git rm --cached）、リポジトリ自身の .gitignore へ追加する
4. コミットしたことがなくても手元のファイルを開き、秘密情報を含む許可ルールを削除する
5. コマンドに秘密情報を直接書かず、秘密管理の仕組みから環境変数（$DB_URL のような形）で参照する。許可は単発のコマンドではなく Bash(npm run:*) のようなパターンで承認する

セキュリティ担当向けには、.claude/ などのエージェント用フォルダやエージェントのメモリファイルを、.env ファイルと同じく秘密情報を含むものとして扱い、コミット前とCIのスキャン対象（履歴を含む）へ加えること、組織の .gitignore テンプレートへこのファイルを追加することが挙げられています。

IT Postの見方

IT Postでは、この問題の本質は「AIが鍵を漏らした」ではなく「承認の記録が、そのまま秘密の写しになった」ことだと考えます。許可ルールは本来、次回の手間を省くためのメモです。そこへコマンド文を丸ごと書き写す設計は、メモが金庫の合鍵の写しになるのと同じで、写しがプロジェクトフォルダに置かれた瞬間、あとはコミットされるかどうかだけが問題になります。グローバルな除外リストという保護は、作った本人の端末でしか効かない個人用の付箋であって、チームで共有される成果物への保護にはなっていませんでした。

開発者側の教訓は単純です。エージェントに渡すコマンドへ秘密を直書きしない、そして「次から聞かない」は、コマンドの中身ごと保存され得る前提で押す。その2つは、修正版を待たずに今日から効きます。

今後どうなりそうか

今後の確認点は、Anthropicが検討中とした秘密情報の除去やスキャンの仕組みがいつ・どの形で実装されるか、既に公開されたファイルへの対応（通知を受けた組織の鍵交換の進み具合）です。11月8日時点では、修正の提供時期は示されていません。

IT Postでは、新しい公式情報が確認できれば続報として整理します。