端末上でコードを生成し、依存関係を解決し、シェルコマンドまで実行するAIコーディングエージェントは、開発者の作業負担を大幅に減らしている。しかし、作業を効率化するための「確認を省略する」機能が、意図せぬ情報流出につながっていることが明らかになった。
セキュリティ企業Apiiroが2026年11月5日に公表した調査報告によると、Anthropicの開発支援ツール「Claude Code」のローカル設定ファイルが10万件以上の公開GitHubリポジトリで見つかり、そのうち1,122件にAPIトークンやデータベースのパスワードなどの秘密情報が含まれていた。問題の背景には、コマンドの実行許可を記憶する際に認証情報を平文で保存し、その保護をGitの除外設定に依存しているという設計上の課題がある。
「次回から確認しない」が秘密情報を保存する仕組み
Claude Codeは、開発者のローカル環境でBashなどのシェルコマンドを実行する際、必要に応じてユーザーに許可を求める。このとき表示される選択肢の一つが「Yes, and don't ask again（許可し、次回から確認しない）」だ。これを選ぶと、Claude Codeは次回以降の確認を省略できるよう、プロジェクト内の.claude/settings.local.jsonにあるpermissions.allow配列へ許可ルールを記録する。
問題は、実行時のコマンド文字列がそのまま保存される場合があることだ。例えば、APIへのアクセスに次のようなコマンドを使用したとする。
curl -H "Authorization: Bearer sk-ant-api03-xxxx..." https://api.example.com/dataこのコマンドに継続的な実行許可を与え、コマンド全文が保存される条件に該当すると、Authorizationヘッダーに含まれるAPIキーもJSONファイルに平文で残る。データベース接続文字列に埋め込まれたパスワードや、サーバーへのログイン認証情報についても同様だ。
ただし、ローカルの設定ファイルに秘密情報が保存されただけでは、外部への情報漏洩は成立しない。GitHub上で公開されるまでには、次の3段階を経る必要がある。
- コマンドの承認: 開発者が認証情報を含むコマンドに対して「Yes, and don't ask again」を選択する。
- 秘密情報の平文保存: コマンド全文が許可ルールとして記録され、認証情報を含む文字列が
.claude/settings.local.jsonに保存される。 - 公開リポジトリへの流出: Gitの除外設定が機能しない状態でファイルがコミットされ、公開GitHubリポジトリへプッシュされる。
この問題は以前から報告されていた。2025年8月11日には、Anthropicの公式GitHubリポジトリにIssue #5544として登録されている。報告者はmacOS 14.5環境で、認証情報を含むコマンドが許可ルールにそのまま保存されることを確認し、再現手順を示していた。ただし、影響を受ける具体的なClaude Codeのバージョンは特定されていなかった。
Apiiroが確認した1,122件の設定ファイルとスキャナーの検出限界
Apiiroは公開GitHubリポジトリを調査し、.claude/settings.local.jsonを104,185件発見した。このうち1,122件のファイルに秘密情報と判定された文字列が含まれ、その総数は1,379件だった。つまり、1,122件は認証情報そのものの数ではなく、秘密情報を含んでいた設定ファイルの数である。
調査では、63の組織に関係する秘密情報が確認された。内容はクラウドサービスのAPIトークン、本番・開発環境のデータベースパスワード、SSH関連の認証情報、秘密鍵、サーバーのrootアカウントに関するログイン情報など多岐にわたる。個人開発者だけでなく、企業やオープンソースプロジェクトの開発環境にも問題が及んでいる。
| 調査項目 | Apiiroの観測結果 | 留意点 |
|---|---|---|
| 公開されていた設定ファイル | 104,185件 | ファイルの存在だけでは秘密情報の漏洩を意味しない |
| 秘密情報を含む設定ファイル | 1,122件（約1.1%） | 含まれる秘密情報は計1,379件 |
| 影響が確認された組織 | 63組織 | 企業や開発プロジェクトなど |
| 主な秘密情報 | APIトークン、DBパスワード、秘密鍵、SSHログイン情報 | コマンドの引数などに含まれていた認証情報 |
| Gitleaks・TruffleHogの双方が見逃したファイル | 215件（約19.2%） | 秘密情報を含む1,122件のファイルに対する割合 |
特に注目すべきは、既存のシークレットスキャナーによる検出漏れだ。Apiiroが広く利用されているオープンソースツール「Gitleaks」と「TruffleHog」で調査対象のファイルを走査したところ、秘密情報を含む1,122件のうち215件は、どちらのツールでも検出されなかった。約5件に1件が両ツールによる検査をすり抜けた計算になる。
一般的なシークレットスキャナーは、既知のAPIキーの形式や文字列のランダム性などを手掛かりに秘密情報を検出する。しかし、シェルコマンドの引数に埋め込まれた独自形式のトークンや、通常の単語を組み合わせたデータベースパスワードなどは、こうした手法では見つけにくい。特に、複雑なコマンドやJSON、URLエンコードされた文字列の内部に認証情報が含まれるケースでは、検出が難しくなる可能性がある。
データを表で見る
| ファイル数 (件) | |
|---|---|
| 秘密情報を含む設定ファイル | 1,122 |
| 両スキャナーが見逃したファイル | 215 |
ただし、この結果はApiiroが調査対象としたファイルに対する両ツールの検出状況を表すものであり、あらゆるシークレットスキャナーの性能を評価したものではない。また、検出された認証情報について、実際にサービスへ接続して有効性を検証したわけではない。そのため、すべてが現在も有効なのか、攻撃者による悪用があったのかは確認できていない。
Gitの除外設定では防ぎきれなかった情報流出
本来ローカル環境にとどまるはずの設定ファイルが、なぜ大量に公開リポジトリへ混入したのか。この点について、Claude Codeの開発に携わるBoris Cherny氏は、Hacker Newsでの議論で説明している。同氏によれば、Claude Codeは設定ファイルを生成する際、自動的にGitの除外設定へ登録する仕組みを備えており、.claude/settings.local.jsonはソースコード管理の対象に含めないことを想定しているという。
しかし、この仕組みには重要な制約がある。Claude Codeは設定ファイルを生成する際、リポジトリ内で共有される.gitignoreではなく、開発者のローカル環境に適用されるGitの除外設定を利用する。この設定は、別の端末へのクローンやCI/CD環境、コンテナには引き継がれない。また、Claude Codeを使用したフォルダーを後からgit initでリポジトリ化した場合にも、除外設定が適切に機能しない可能性がある。
こうした環境では、設定ファイルが通常の未追跡ファイルとして扱われるため、git add .やgit add -Aによる一括追加でコミットされる恐れがある。さらに、一度Gitの追跡対象となったファイルは、後から除外設定を追加しても追跡が自動的に解除されない。
実際、2025年12月4日に登録されたIssue #13106では、.claudeディレクトリが適切に除外されず、平文のAPIトークンを含む設定ファイルが公開リポジトリにコミットされた事例が報告されている。Cherny氏は、公開されたファイルが手動で作成されたり、明示的にコミットされたりした可能性を指摘した。一方、Apiiroの調査では、Claude Codeが共同作成者として記録されたコミットに設定ファイルの変更が含まれる例も見つかっており、流出経路をすべて人間の手動操作だけで説明することはできない。
過去の報告への対応にも課題が残る。Issue #5544は、一定期間更新がなかったことを理由に2026年1月3日に自動クローズされており、関連する報告にも同様の扱いや重複によるクローズが見られた。ただし、Issueが閉じられたことは問題の修正を意味しない。どのバージョンから問題が存在し、どのリリースで対処されたのかについて、包括的な公式情報は示されていない。
今回の問題は、単にGitの除外設定が不十分だったという話ではない。そもそも認証情報を含むコマンドを平文のまま保存し、その保護をGitの設定や開発者の注意に依存していたことが根本的な課題だ。適切な除外設定があっても秘密情報はローカルのディスク上に残るため、端末への不正アクセスやファイルの誤共有といった別の流出経路も考えられる。
Anthropicの見解とauto modeに残る問題
Cherny氏はHacker News上で、Claude Codeがこれまで秘密情報の自動除去処理を行っていなかったことを認め、対策を検討していると説明した。ただし、具体的な修正パッチの提供時期や対象バージョンを発表したわけではない。
同氏は当面の対応として、Claude Codeの「auto mode（自動モード）」を推奨している。Cherny氏の説明によると、auto modeはすべてのプランで利用でき、標準で有効になっている。コマンドを実行するたびに人間が許可する従来の方式と異なり、分類器を利用して実行の可否を判断することで、頻繁な承認ダイアログによる「承認疲れ」を軽減する仕組みだ。Anthropic側は、静的解析やプロンプトインジェクションへの対策、社内レッドチームによる検証などを安全性の根拠として挙げている。
しかし、分類器による判断は、明示的に定義された許可・拒否ルールとは性質が異なる。Hacker Newsでも、機械学習モデルによる判断を確定的なアクセス制御の代わりに使用することへの懸念が示された。さらに、あるユーザーはauto modeでも、機密情報を含むコマンドが設定ファイルに保存される場合があると指摘した。Cherny氏はこれを「的確な指摘」と認め、改善策を検討すると回答している。
また、Cherny氏はClaude Code本体へシークレットスキャン機能を組み込む可能性にも言及した。ただし、スキャナーの追加は情報流出の検出には役立つものの、秘密情報を平文で保存する問題自体を解消するものではない。
開発現場のセキュリティ対策と残るリスク
開発現場では、Gitの除外設定やシークレットスキャンなど、複数の対策が利用されている。しかし、今回のようにAIエージェントが秘密情報を含む設定ファイルを自動生成する場合、それぞれの対策だけでは十分とはいえない。主要な防御策の効果と限界は以下の通りだ。
| 防御策 | 主な効果 | 制約・限界 |
|---|---|---|
| ローカルのGit除外設定 | 当該環境で設定ファイルの追跡を防ぐ | 別端末やコンテナには引き継がれず、追跡済みファイルにも適用されない |
リポジトリの.gitignore |
プロジェクト全体で除外ルールを共有できる | git add -fによる強制追加や設定ミスは防げない |
| auto mode | 承認回数を減らし、分類器で実行の可否を判断する | 秘密情報の平文保存を完全には防げない |
| シークレットスキャナー | コミットやプッシュ前に認証情報を検出する | 独自形式のトークンやコマンド内のパスワードを見逃す場合がある |
| 環境変数・シークレット管理ツール | コマンドへの認証情報の直接埋め込みを減らせる | 展開後の値がログや引数に残る可能性がある |
これらの対策は、情報流出の異なる段階を対象としている。したがって、単一の仕組みに依存するのではなく、認証情報をコマンドに含めない設計、設定ファイルの除外、コミット前の検査を組み合わせることが重要になる。特に、公開された秘密情報は検出後に削除しても第三者による取得を取り消せないため、保存段階からリスクを抑える必要がある。
開発チームが取るべき対応と認証情報の無効化
Claude Codeを利用している開発者や組織は、公開リポジトリに問題の設定ファイルが含まれていないか確認する必要がある。現在のファイルだけでなく、過去のコミット履歴も調査対象となる。GitHub上でファイルを削除しても、過去のコミットや第三者のフォーク、外部アーカイブに情報が残る可能性があるためだ。
1. 認証情報の無効化と再発行を最優先する
公開された可能性のあるAPIキー、アクセストークン、データベースパスワードなどは、第三者に取得された可能性があるものとして扱う。各サービスの管理画面から該当する認証情報を無効化し、新しいものへ交換（ローテーション）する。あわせて、アクセスログや監査ログを確認し、不審な認証や操作が行われていないか調査する。
この対応は、リポジトリからファイルを削除する作業より優先度が高い。第三者が認証情報をコピーしていれば、GitHub上から削除しても不正アクセスを防げないためだ。
2. 過去のコミット履歴を調査する
git logなどを使用して、過去のコミットに.claude/settings.local.jsonが含まれていないか調査する。必要に応じてシークレットスキャナーも併用するが、検出結果が陰性でも秘密情報が存在しないことの証明にはならない。
問題のあるファイルが見つかった場合は、証拠を保全した上で、git-filter-repoやBFG Repo-Cleanerによる履歴の書き換えを検討する。この作業では強制プッシュや共同開発者側での履歴の再同期が必要になるため、関係者との調整が欠かせない。また、フォーク先や外部アーカイブの情報をすべて削除できるとは限らず、必要に応じてGitHubサポートへの相談も検討する。
3. コマンドに認証情報を直接埋め込まない
シェルコマンドの引数へパスワードやAPIトークンを直接記述する運用を避け、環境変数やシークレット管理ツールから取得する構成へ移行する。例えば、1Password CLIやAWS Secrets Managerなどを利用し、実行時に必要な認証情報を取得する方法がある。
ただし、環境変数を使えば必ず安全になるわけではない。.envファイルを適切に除外するとともに、値がコマンド引数やログに展開されないよう注意する必要がある。Claude Codeの許可ルールにも、認証情報そのものではなく環境変数への参照が残るようにすることが望ましい。
4. 設定ファイルとGitの除外設定を検証する
Anthropicによる修正版の提供とその挙動が確認されるまでは、実際の認証情報を使わず、ダミー文字列による動作確認を行うことが有効だ。例えば、curl -H "Authorization: Bearer test-dummy-token"のようなコマンドを承認し、.claude/settings.local.jsonにその文字列が保存されるかを確認する。
同時に、設定ファイルがGitの追跡対象になっていないか、リポジトリ固有の.gitignoreで除外されているかも点検する。すでに追跡されている場合は、git rm --cached .claude/settings.local.jsonなどを使って追跡対象から外せる。ただし、この操作では過去のコミット履歴からファイルは削除されない。
自律型AIエージェントは、開発者が個々の操作を確認する手間を減らし、生産性を高めている。しかし、確認の省略によって開発者の知らないところで認証情報が保存されるのであれば、その利便性には新たなセキュリティリスクが伴う。今回の問題は、AIエージェントの実行権限だけでなく、エージェントが何を記録し、どこへ保存するのかまで含めた安全設計が必要であることを浮き彫りにした。今後はAnthropicによる根本的な修正と、既存環境に残された認証情報への対応が求められる。