結論から言うと、Claude Codeの“Don't ask again”は便利な時短機能ですが、承認したコマンド文字列を許可ルールとして保存するため、秘密情報をコマンドに直書きする運用では漏えいリスクが残ります。Anthropic公式ドキュメントでは、Bashコマンドで恒久承認を選ぶと`.claude/settings.local.json`に保存され、gitリポジトリではルートに置かれると説明されています。Apiiroの2026年11月5日の調査は、このファイルが公開リポジトリに混入したケースを大規模に数えたものです。
Claude Codeや社内AI開発環境の権限設計を見直したい場合は、 HelloCraftAIにご相談ください 。PoC前の許可ルール、シークレット管理、CIでの検出ルールまで一緒に整理できます。
Claude CodeのDon't ask againとは？
Claude Codeの権限システムは、読み取り、Bash、ファイル編集、WebFetch、WebSearchなどの操作ごとに承認の扱いを分けます。ManualモードではBashコマンドは基本的に確認が入り、ユーザーは一度だけ許可するか、同じコマンドを今後も許可するかを選べます。公式ドキュメント上の表現では、Bashの恒久承認はリポジトリとコマンド単位で保存されます。
問題は、この「同じコマンド」の中に接続文字列、APIキー、データベースパスワードが入っていた場合です。実行承認したコマンドが許可ルールに残ると、設定ファイル自体がシークレット保管場所になります。
1,122件の漏えい調査で何が見えたか
Apiiroの調査では、公開GitHub上の`.claude/settings.local.json` 104,185件のうち、1,122ファイルに実際の秘密情報が含まれていたと報告されています。内訳として、379件のデータベースパスワード、122件のSupabase service-role key、43件のSSHログインなどが挙げられています。
Anthropic公式がこの漏えい数を発表したわけではありません。公式で確認できるのは、権限ルールをファイルに保存する仕様、`settings.local.json`が個人用・ローカル用であること、初回作成時にグローバルgit除外へ追加されるという説明です。
管理者が今日見るべき5項目
- 1. 公開リポジトリに`.claude/settings.local.json`や`.claude/settings.json`が入っていないかを検索する。現在のdefault branchだけでなく、履歴、fork、テンプレートも対象にします。
- 2. 許可ルールの中に`PGPASSWORD=`, `mysql -p`, `sshpass -p`, `Authorization: Bearer`, `DATABASE_URL=`のような文字列がないかを確認する。
- 3. 見つかった秘密情報は、ファイル削除より先にローテーションする。公開履歴やforkに残った値は、削除しても無効化されません。
- 4. コマンドには実値ではなく環境変数やシークレットマネージャー参照を使う。許可ルールに残るのは`$DB_URL`や`$API_TOKEN`のような参照名に留めます。
- 5. チーム共通の`.claude/settings.json`には広すぎるallowを置かず、denyとaskを優先する。本番DB、クラウドCLI、デプロイ、秘密情報を読むコマンドは明示的にaskまたはdenyに寄せます。
公式仕様から見る安全な設定方針
Anthropicのドキュメントでは、設定ファイルはUser、Shared project、Project local、Managedの4系統に分かれます。チームに配るべきなのは共有プロジェクト設定、個人の例外はプロジェクトローカル設定、組織ポリシーはManaged設定です。`settings.local.json`は個人の一時的な承認や例外に向いた場所であり、リポジトリにコミットして共有する前提のファイルではありません。
また、権限ルールはdeny、ask、allowの順に評価されます。広いdenyは狭いallowより優先され、askもallowより優先されます。運用上は、まずdenyとaskの境界を決め、その後で本当に安全な定型コマンドだけallowに落とす順番が現実的です。
30日PoCでの導入チェックリスト
1週目は棚卸しです。全リポジトリで`.claude/`、`.cursor/`、`.gemini/`、`.specstory/`、エージェントのメモファイルを検索し、default branchと履歴の両方を確認します。secret scannerがコマンド引数のパスワードも検出できるかを見ます。
2週目はルール設計です。Claude Codeの`/permissions`で現在のallow、ask、denyを確認し、チーム共通で許可してよいコマンド、毎回確認すべきコマンド、止めるコマンドを分類します。秘密情報が含まれていた場合は、ルール削除より先に認証情報をローテーションします。
3週目はCIへの組み込みです。`.claude/settings.local.json`をリポジトリ固有の`.gitignore`テンプレートに加え、pre-commitとCIの両方で検出します。チーム共通の`.claude/settings.json`は内容検査も必要です。
4週目は教育と例外処理です。開発者には「秘密をコマンドに貼らない」「環境変数名で渡す」「本番接続ではDon't ask againを使わない」の3つを徹底します。例外は期限付きaskルールやManaged settingsで配布します。
FAQ
Q. `.claude/settings.local.json`を消せば安全ですか？ A. 現在の作業ツリーから消すだけでは不十分です。すでに公開履歴やforkに入った秘密情報は残るため、先に該当キーをローテーションし、その後で履歴削除やブロックルール追加を検討します。
Q. グローバルgit除外に入るなら、なぜ漏れるのですか？ A. 公式ドキュメント上はClaude Codeが作成時にグローバルgit除外へ追加するとされています。ただし、後からリポジトリ化したフォルダ、別マシンのclone、手作業で作ったファイル、すでに追跡済みのファイルなどでは、プロジェクト側の`.gitignore`がないと混入を止めきれません。
Q. 企業ではClaude Codeを止めるべきですか？ A. いきなり全面停止するより、権限ルールと秘密情報の扱いを分けて設計するほうが実務的です。問題は本番秘密情報をコマンドに直書きし、それを恒久承認として残す運用にあります。
Claude Codeの社内展開で、どの操作をallowにしてよいか迷う場合は、 AI導入・権限設計の相談 としてHelloCraftAIにご相談ください。PoC用の権限表、secret scannerの追加パターン、開発者向けガイドまでまとめて設計できます。
