Claude Codeの「今後確認しない」設定がAPIキーをGitHubに漏洩させる—

Claude Codeの「Don't Ask Again（今後確認しない）」ボタンは、承認したコマンドをそのままの形で .claude/settings.local.json の許可ルールとして保存します。そのコマンドにパスワードやAPIキーが含まれていた場合、シークレットはプロジェクトフォルダ内に平文で置かれることになり、ファイルがコミットされれば公開されてしまいます。セキュリティ企業のApiiroは、公開GitHub上でこうしたファイル1,122件から1,379件の本物のシークレットを発見しました。この記事では、1つのコマンドで自分のリポジトリをチェックする方法、クリーンアップの方法、そして再発を防ぐ方法を紹介します。

何が起きたのか：数字で見るApiiroの調査結果

Apiiroは公開GitHub上で .claude/settings.local.json（Claude Codeが個人の権限承認を保存するプロジェクトごとのファイル）のコピーを検索しました。その結果、103,617のリポジトリにわたって104,185件のコピーが見つかりました。そのうち1,122件には少なくとも1件の本物のシークレットが含まれており、合計で1,379件の固有のシークレットが確認されたと、iTnewsの調査記事が伝えています。

シークレットの種類	件数
データベースのパスワード	379
Supabaseのservice-roleキー	122
公開サーバーへのSSHログイン情報	43
GitHub、GitLab、npmのトークン	42
AWSキー	23

Apiiroが検索対象をファイルの古いgitバージョン、共有用の .claude/settings.json、保存されたエージェントのトランスクリプトにまで広げると、件数は1,994リポジトリにわたる2,539件のシークレットに達しました。Apiiroは認証情報がまだ有効かどうかまでは検証していませんが、通知を受けたある組織はキーが実際に有効だったことを確認しています。

最も注意すべきはスキャナーの検出率です。本物のシークレットを含む1,122件のファイルのうち、TruffleHogが検出したのは643件、gitleaksが検出したのは564件にとどまりました。215件のファイルは両方のツールを見逃しました。つまり、「シークレットスキャナーを導入しているから大丈夫」では保証されないのです。

この話題は582ポイントでHacker Newsのトップに達しました。AnthropicでClaude Codeを率いるBoris Chernyは、スレッド内で「Claude Codeはこれまでシークレットを消去してこなかった」と認め、チームが対応を検討していると述べました。原文のApiiroの調査レポートもお読みください。

「Don't Ask Again」がシークレットをファイルに保存してしまう仕組み

Claude CodeがBashコマンドを実行しようとするとき、まず確認を求めます。「Yes, and don't ask again（はい、今後確認しない）」を選ぶと、Claude CodeはAnthropicの設定ドキュメントに記載されているとおり、恒久的な承認を allow ルールとして .claude/settings.local.json に書き込みます。このルールにはコマンドのテキストがそのまま記録されます。コマンドが次のようなものだった場合：

psql "postgresql://admin:Sup3rS3cret@db.example.com:5432/prod" -c "select count(*) from users"

設定ファイルには次のような内容が保存されます：

{
  "permissions": {
    "allow": [
      "Bash(psql \"postgresql://admin:Sup3rS3cret@db.example.com:5432/prod\" -c \"select count(*) from users\")"
    ]
  }
}

パスワードがルールに含まれるのは、コマンドに含まれていたからです。Claude Codeは承認した内容を一字一句そのまま保存します。

Diagram of how a Claude Code approval with an inline password flows into settings.local.json and then into a public GitHub repository

なぜGitHubに流出するのか

Claude Codeはこのファイルをgitの管理外に保とうとします。リポジトリがまだ対象を無視していない状態で初めて .claude/settings.local.json を書き込む際、グローバルなgit除外ファイルに **/.claude/settings.local.json を追加します。しかし、この保護には抜け穴があります：

手動でファイルを作成した場合。 ドキュメントには明確に「自分でファイルを作成した場合は .gitignore に追加する必要がある」と記載されています。HNでのChernyの見解では、流出したコピーは手動で作成されコミットされたものだということでした。
無視ルールは1台のマシンにしか存在しない。 ルールはリポジトリの .gitignore ではなくグローバルな除外ファイルにあるため、チームメイト、CIジョブ、新しくフォルダをコピーしたノートPCには引き継がれません。
ルールが存在する前にファイルが強制追加または追跡されていた場合。 git add -f は無視ルールを上書きし、一度追跡対象になったファイルには無視ルールが適用されなくなります。
共有用ファイルの場合。 VS Code拡張機能の承認カードでは、コミットされる .claude/settings.json を含む保存先ファイルを選択できます。そこに保存されたルールは全員に適用されます。

1つのコマンドでリポジトリをチェックする

まず今いるリポジトリから始めましょう。次のコマンドで、ファイルが現在实际に追跡されているか、過去にコミットされたことがあるかを確認できます：

git ls-files | grep -E '(^|/)\.claude/settings(\.local)?\.json$'
git log --all --name-only --format= | grep -E '\.claude/settings(\.local)?\.json$' | sort -u

1行目が何かを出力すれば、ファイルは現在のツリーに存在します。2行目が何かを出力すれば、後から削除した場合でも履歴に残っています。

フォルダ配下のすべてのリポジトリを一括でスキャンするには：

find ~/code -path '*/.claude/settings.local.json' -exec sh -c \
  'cd "$(dirname "$1")/.." && git ls-files --error-unmatch .claude/settings.local.json >/dev/null 2>&1 && echo "TRACKED: $PWD"' _ {} \;

GitHub組織の場合は、GitHub CLIでファイル名を指定してコードを検索できます：

gh search code permissions --owner your-org --filename settings.local.json

見つかったファイルの中身を必ず確認してください。スキャナーが流出ファイルの19%を見逃したという事実があるため、緑色のスキャン結果を鵜呑みにせず、自分でルールを読みましょう：

grep -nE 'Bash\(' .claude/settings.local.json | grep -iE 'pass|token|key|secret|://[^/]*:[^@]*@'

user:password@ を含む接続文字列、Authorization: Bearer ヘッダー、-p の後に続くリテラルのパスワード、あるいは sk-、ghp_、AKIA、eyJ で始まる文字列は認証情報です。確認の2段階目として（唯一の手段ではなく）gitleaksをリポジトリ全体に実行しましょう。

流出した設定ファイルへの対処方法

順序が重要です。ファイルを削除しても、フォーク、クローン、キャッシュに既に存在するコピーには何の効果もないため、鍵のローテーションが最優先です。

ファイルが保持していたすべての認証情報をローテーションする。 git log -p --all -- .claude/settings.local.json でファイルの全履歴を確認し、含まれるすべてのシークレットをリストアップして、各プロバイダーでそれぞれ無効化してください。Apiiroのガイダンスでもこの手順が最初に挙げられています。
ファイルを追跡対象から外し、リポジトリ自体で無視設定にする：

git rm --cached .claude/settings.local.json
echo '.claude/settings.local.json' >> .gitignore
git add .gitignore && git commit -m "Stop tracking Claude Code local settings"
git check-ignore -v .claude/settings.local.json

最後のコマンドで、一致する .gitignore の行が出力されるはずです。リポジトリ内のルールはすべてのクローンを保護します。

リポジトリが公開されている、または広く共有されている場合は履歴を消去する。 git-filter-repoはすべてのコミットからこのファイルを削除します：

git filter-repo --invert-paths --path .claude/settings.local.json
git push --force --all

これは全員に対して履歴を書き換えるため、事前にチームに警告してください。フォークには届かないため、あくまでクリーンアップであり、手順1の代替にはなりません。

ローカルのファイルもクリーンアップする。 .claude/settings.local.json を開き、リテラルのシークレットを含むルールをすべて削除し、パターン（次のセクション参照）に置き換えてください。
プッシュ保護を有効にする。 GitHubのシークレットスキャニングによるプッシュ保護は、既知のシークレット形式を含むプッシュをブロックします。見逃された215件のファイルが示すとおりすべてを検出できるわけではありませんが、一般的なトークン形式を防ぐことができます。

再発を防ぐ

対処方法はシンプルです：エージェントが実行するコマンドにリテラルのシークレットを決して含めないこと。そして、正確なコマンドではなくパターンを承認すること。

Side-by-side comparison of a risky Claude Code allow rule containing a literal password and a safe rule that references an environment variable

シークレットは参照し、直接入力しない。 シェルは実行時に変数を展開しますが、allowルールには記述されたテキストがそのまま保存されます。つまり、psql "$DATABASE_URL" と書けば、パスワードではなく $DATABASE_URL がルールに保存されます：

{
  "permissions": {
    "allow": ["Bash(psql \"$DATABASE_URL\" *)", "Bash(npm run test *)"],
    "deny": ["Read(./.env)", "Read(./.env.*)"]
  }
}

deny ルールはAnthropicの設定ドキュメントからそのまま引用したものです。これによりClaude Codeが .env ファイルを読み取れなくなり、キーがそこからコマンドに貼り付けられることも防げます。

ルールは狭く保つ。 調査を引用したHNのコメントによれば、ファイルの5%があらゆるシェルコマンドを許可しており、43%に Bash(python:*) のようなインタープリタールールが含まれていました。そのようなルールではエージェントがPython経由で何でも実行できるため、回りくどい「すべて許可」のルールにすぎません。

オートモードとサンドボックスの検討。 Chernyは手書きの権限ルールよりもオートモードを推奨し、Anthropicがオープンソースのサンドボックスを構築したと述べました。ただし、複数のコメント者が指摘しているように、オートモードはセキュリティ境界ではなく分類器であるため、上記の習慣と組み合わせることが重要です。

エージェントを本番環境のシークレットから遠ざける。 最も安全なキーは、エージェントが一切目にしないキーです。そのパターンについてはAIエージェントにキーを見せずにAPIキーを使わせる方法、流出したAIキーを攻撃者がどう利用するかについては盗まれたAI APIキーとLLMjackingで解説しています。

Apidog CLIで、キーを入力せずにコーディングエージェントからAPIを呼び出す

承認されたコマンドにキーが紛れ込む一般的なケースのひとつは、エンドポイントを確認するための curl -H "Authorization: Bearer sk-..." のようなAPI呼び出しです。その作業は代わりにApidog CLIに任せられます。キーはApidogの環境変数に保存され、テストシナリオからは {{API_KEY}} として参照され、エージェントが実行するコマンドにはプロジェクト、シナリオ、環境のIDしか含まれません。保存すべき秘密情報がコマンド内に存在しないのです。

初期設定は、エージェントを通さず自分のターミナルで一度だけ行ってください。こうすることでアクセストークンが承認フローを経由することがありません：

npm install -g apidog-cli@latest
apidog auth login
npx -y skills add https://apidog.com   # pick Claude Code when prompted

その後、Claude Codeに次のようなプロンプトを1つ渡します：

List the environments in Apidog project 123456, then run test scenario 7890
against the staging environment and summarise any failed assertions.
The API key is stored in that environment as {{API_KEY}}. Never pass a key,
token or password on the command line, and never use --env-var for secrets.

エージェントは次のようなコマンドを実行します。これらは「Don't Ask Again」で安全に承認できます：

apidog environment list --project 123456
apidog run -t 7890 --project 123456 -e <envId> -r cli,json

正直な注意点が2つあります。第一に、apidog run は変数の共有値を使用します。これはApidogに同期され、プロジェクトのメンバーから見えるため、本番のルートキーではなくスコープを限定したテストキーを保存してください。値をディスク上に置きたい場合は、apidog run は --variables <path> も受け付けます。リポジトリ外のファイルを指定してください。第二に、--env-var "key=value" フラグはコマンドラインで変数を渡すために存在しますが、まさにそれがリークを引き起こすパターンです。シークレットには使わないようエージェントに指示しておきましょう。

Enterpriseプランのチームは、Apidog Vault SecretsでHashiCorp Vault、Azure Key Vault、AWS Secrets Managerからシークレットを取得することもできます。さらにEnterprise SaaS Secret Scannerは、Apidogのリクエスト、スクリプト、変数に保存されたキーを検出します。ただしGitHubリポジトリはスキャンしないため、上記のチェックも併せて行ってください。完全な設定手順については、Claude CodeでのApidog CLIの使い方とApidogでの環境とシークレット変数の管理を参照してください。ApidogのFreeプランは最大4ユーザーまで利用できます。

button

FAQ

Claude Codeのsettings.local.jsonはデフォルトでgitignoreされますか？

部分的にそうです。Claude Codeがgitリポジトリ内でこのファイルを作成する際、グローバルなgit除外ファイルに **/.claude/settings.local.json を追加します。しかしそれは自分のマシンのみを保護するものであり、手動でファイルを作成した場合や強制追加した場合には適用されません。リポジトリ自身の .gitignore にもこの行を追加してください。

ファイルを削除すれば流出したキーは消えますか？

いいえ。キーはgitの履歴、フォーク、公開されていた間に作成されたすべてのクローンに残ります。まずキーをローテーションし、その後ファイルを追跡対象から外し、git-filter-repoで履歴を消去してください。

gitleaksやTruffleHogでこの流出を検出できますか？

確実には検出できません。Apiiroのサンプルでは、本物のシークレットを含む1,122件のファイルのうち215件が両ツールとも見逃しました。スキャナーを実行したうえで、ファイル内の Bash(...) ルールを自分で読んで確認してください。

これはモデルの問題ですか、それともClaude Codeの問題ですか？

ApiiroはOpus 5.5とFable 5.1でこの問題を再現し、モデルではなくClaude Codeの特性だと結論づけました。どのモデルがコマンドを書いたかにかかわらず、承認にはコマンドのテキストが保存されます。

Claude Codeでコマンドを安全に承認するには？

Bash(npm run test *) のようなパターンを承認し、シークレットは $DATABASE_URL のような環境変数として参照してください。Read(./.env) と Read(./.env.*) に対する deny ルールも追加しましょう。