Claude Codeの許可設定から秘密情報を公開しないために

2026年11月、セキュリティ企業Apiiroが、AIコーディングエージェントの設定ファイルや会話ログなどから、2,539件の秘密情報が公開GitHub上で見つかったと報告しました。1,994リポジトリにまたがる調査結果で、11月9日には国内でも報じられています。 Apiiroの調査原文（11月5日公開、11月8日追記）

今回取り上げるのは、その調査で報告されたClaude Codeの許可設定です。「今後は確認しない」を選んだコマンドにAPIキーやDBのパスワードが含まれていると、その値が設定に残ることがあります。そのファイルをコミットして公開リポジトリへpushすると、秘密情報も公開されてしまいます。

なお、2,539件はGit履歴や共有設定、会話ログなどを含む調査全体の数字です。すべてがClaude Codeの個人用設定ファイルから見つかったわけではなく、認証情報が実際に使えるかも検証されていません。

Claude CodeにAPIの疎通確認やDBの調査を頼んでいる方は、アプリのコードに加えて .claude/ の中も確認してみましょう。この記事では、設定ファイルがGitの管理対象になっていないかを調べ、秘密情報が見つかった場合の対処まで扱います。

実行を許可したコマンドが、設定ファイルに残る

Anthropic公式では、Bashコマンドで「Yes, and don’t ask again」を選び、永続的な許可を保存すると、.claude/settings.local.json にルールを書き込むと説明しています。毎回の確認を省くために、次回以降も参照する設定です。 公式の許可設定ドキュメント

Apiiroが報告したのは、秘密情報を含むコマンドがそのまま許可ルールとして保存されるケースです。許可の選択肢が npm test * のようなパターンなのか、秘密情報まで含む具体的なコマンドなのかで、保存される内容が変わります。

報告された経路を図にすると、次のようになります。設定への保存と、GitHubへの公開は別の段階です。

出典： Apiiroの報告。すべての承認で秘密情報が保存される、という図ではありません。

まず、設定ファイルがGitの管理対象かを確認する

調べるファイルは、少なくとも次の2つです。

ファイル	用途	確認すること
.claude/settings.local.json	そのプロジェクトで使う個人用設定	Gitの追跡対象になっていないか、許可ルールに秘密情報がないか
.claude/settings.json	チームで共有する設定	共有してよい値だけが入っているか

公式ドキュメントでは、Claude Codeが個人用ファイルを初めて書くとき、端末のグローバルなGit除外設定に追加すると説明しています。ただし、自分で作ったファイルには除外設定が必要です。共有用の settings.json はコミットして使う設計なので、こちらも中身を確認します。 設定ファイルの用途と保存先

Gitでは、すでに追跡しているファイルに .gitignore の除外指定は効きません。「localという名前だから」「除外設定があるから」だけでは判断できないので、追跡状態を確認してみましょう。 Git公式：gitignore

以下はリポジトリのルートで実行する例です。本文や秘密情報を表示せず、まずファイル名だけを調べます。

git ls-files -- .claude/settings.local.json .claude/settings.json

settings.local.json が表示されたら、現在のGitのインデックスに入っています。まだコミットしていない追加も含むため、この結果だけで「公開済み」とは判断しません。 Git公式：git ls-files

過去にコミットされた形跡も確認します。

git log --all --format='%h %ad' --date=short --name-only -- .claude/settings.local.json .claude/settings.json

出力があれば、そのコミットで設定ファイルが変更されています。手元にある履歴を調べるコマンドなので、浅いクローンや未取得のブランチ、別のクローンなどは網羅できません。出力がない場合も、過去の公開がなかった証明には使わず、GitHub側のブランチや履歴も確認してください。 Git公式：git log

ファイルが存在する場合はローカルのエディターで開き、permissions.allow にパスワード、トークン、認証情報付きの接続URLがないか確認します。共有設定では env など、許可ルール以外の値も確認対象です。見つけた値を、調査依頼のチャットやIssueへそのまま貼らないようにしてください。

公開していたら、先に認証情報を失効させる

秘密情報を含む設定が公開されていた場合、最初に行うのは、その認証情報の失効・再発行です。利用しているアプリやCIにも新しい値を反映し、古い値でアクセスできない状態にします。GitHubも、履歴の削除に取りかかる前に認証情報を失効・ローテーションするよう案内しています。 GitHub公式：機密データの削除

その後、現在の設定から秘密情報を含むルールを取り除きます。過去のコミットやフォーク、他の人のクローンに残った値は、現在のファイルを編集しただけでは消えません。履歴の書き換えが必要なら、共同作業者と手順を合わせて進めます。同じGitHub公式ページに、コミットIDが変わる影響や、古いクローンから秘密情報が再混入する注意点がまとまっています。

まだ外部へ共有していない場合も、秘密情報入りの設定を次のコミットに含めないよう、以下の追跡状態を整えましょう。

個人用の設定を追跡対象から外す

プロジェクトの .gitignore に、次の指定を追加します。すでに同じ指定がある場合は追加不要です。

**/.claude/settings.local.json

前の確認で settings.local.json が追跡対象だった場合だけ、次を実行します。

git rm --cached -- .claude/settings.local.json

--cached は、手元のファイルを残してインデックスから外す指定です。変更が競合してエラーになったら、表示された理由を確認してください。強制削除で進める必要はありません。 Git公式：git rm

最後に、この2つを確認します。

git ls-files -- .claude/settings.local.json
git check-ignore -v -- .claude/settings.local.json

1つ目が何も表示せず、2つ目で意図した .gitignore の除外ルールが表示されれば、個人用設定が追跡されず、除外ルールも適用されています。! で始まる否定パターンが出る場合は、除外が打ち消されていないか見直します。 Git公式：git check-ignore

.gitignore の追加と追跡解除の差分を確認してコミットします。これは今後の混入を防ぐ作業であり、過去の履歴から消す操作ではありません。チームで共有する .claude/settings.json は、秘密情報を取り除いたうえで必要な設定を残します。

次からは、承認するコマンドの「値」まで見る

APIキーを使う処理なら、キーをコマンドに直接書かず、実行環境から受け取る形にできないか確認しましょう。たとえば、自作のAPI確認スクリプトが API_TOKEN を環境変数から読み込むなら、Claude Codeに実行させるコマンドは次の形にできます。

python scripts/check_api.py

これは設計例です。スクリプト側で必要な変数がなければエラーにし、認証ヘッダーやトークンをログに出さないようにします。環境変数に移すだけで、AIや子プロセスから秘密情報が見えなくなるわけではありません。コマンド文字列に実値を埋め込まないことと、その実値へのアクセスを制限することは、それぞれ確認が必要です。

「常に許可」を選ぶ前は、実行内容に加えて、保存されるルールに実値が含まれないかを見ます。確認を減らすために Bash(*) などへ広げると、今度は許可する操作自体が広がってしまいます。必要なコマンドに範囲を絞っておきましょう。 公式のBash許可ルール

おわりに

次のコミット前に、まず git ls-files で .claude/settings.local.json が出てこないか確認してみてください。共有設定をレビューするときも、許可している操作と、そこに書かれた値を一緒に見ると、秘密情報の混入に気づきやすくなります。