はじめに — 承認プロンプトは本当に必要か

Claude Codeを日常的に使っていると、承認プロンプトの多さに悩まされることがあります。ファイルの読み書き、コマンドの実行、外部APIの呼び出し——あらゆる操作で「許可しますか？」と問われ、そのたびに手を止めて「Yes」を押す作業が発生します。

この承認プロンプトは、本当にセキュリティに貢献しているのでしょうか。

1セッションで50回以上の承認プロンプトが表示される環境では、多くの場合、内容を確認せずに反射的に「Yes」を押す習慣がついてしまいます。これはセキュリティの世界でアラート疲れ（Alert Fatigue）と呼ばれる現象であり、過剰な承認はむしろセキュリティを低下させるという逆説的な結果を招きます。

本記事では、承認プロンプトをゼロにしながらセキュリティを維持するdeny-firstアーキテクチャの設計方法を解説します。セキュリティリスクの評価についてはAIコーディングツールの「承認ゼロ運用」を支えるセキュリティ設計を、障害発生時のバックアップ体制についてはCloudflareサービスの障害復旧完全ガイドをあわせてご覧ください。

deny-firstアーキテクチャとは何か

Claude Codeの権限モデルは、deny → ask → allowの評価順序で設計されています。denyルールに該当する操作はAIの判断に関係なく100%ブロックされ、いかなるallowルールやHooksでも覆すことができません。

この設計を活用し、「危険な操作をdenyで絶対的にブロックし、それ以外をallowで自動承認する」のがdeny-firstアーキテクチャです。

従来の承認モデルとの比較を整理します。

従来モデル（人間が毎回判断） では、すべての操作に対して人間が「安全か危険か」を判断します。この判断は確率的であり、疲労や慣れによって精度が低下します。1日に数百回の判断を求められれば、いずれ見落としが発生します。

deny-firstモデル（ルールが自動判断） では、危険な操作は機械的にブロックされ、安全な操作は機械的に承認されます。この判断は決定論的であり、100万回実行しても同じ結果を返します。人間の疲労や見落としの影響を受けません。

三段階の安全境界を設計する

deny-firstアーキテクチャは、3つの安全境界で構成されます。

第1層 — 絶対禁止（denyルール）

「何があっても実行してはならない操作」 を定義します。deny ルールはAIの判断に依存せず、パターンマッチで100%ブロックする決定論的制御です。

設定すべきdenyルールは、大きく5つのカテゴリに分類できます。

破壊的コマンドの防止として、rm -rf や rm -fr など、ファイルシステムを不可逆に破壊するコマンドをブロックします。Claude Code自体にも破壊的操作に対する内部的な安全制約がありますが、これはLLMの判断に依存する確率的な防御です。denyルールによる決定論的なブロックを追加することで、二重の防御になります。

機密ファイルの保護として、.envファイルや認証情報ファイルへのアクセスをブロックします。Claude Codeの承認設定を最適化するで解説した権限モデルの知識が、ここで直接役立ちます。

データ流出経路の遮断として、curlやwgetなど、外部にデータを送信できるコマンドをブロックします。正規のWebアクセスはClaude CodeのWebFetchツールを使うことで、セキュリティフィルタを経由した安全なアクセスに限定できます。

危険なGit操作の防止として、git push --force（リモート履歴の不可逆な破壊）やgit reset --hard（未コミット変更の消失）をブロックします。

シェルバイパスの遮断として、PowerShellやcmdなど、ファイルシステム制限を迂回できるシェルへのアクセスをブロックします。

第2層 — 自動承認（allowルール）

denyに該当しないすべての操作を自動承認します。Claude Codeのallowルールは、ツール名を指定子なしで記述するとブランケット許可として機能します。たとえば "Bash" と記述すれば、deny ルールに該当しないすべてのBashコマンドが自動承認されます。

ファイルの読み書き、Gitの通常操作、ビルド・デプロイコマンド、Web検索、MCPツールなど、日常的な開発操作のすべてをallowに含めることで、承認プロンプトの発生をゼロにします。

第3層 — 監査ログ（Hooks）

承認プロンプトをゼロにしても、何が実行されたかの記録は残すべきです。Claude CodeのHooks機構を使い、PostToolUseイベントで全操作をJSONL形式のログファイルに自動記録します。

Hooksは「LLMの判断に依存しない決定論的制御」（サンドボックスと同様の確実性を持つ仕組み）を実現する機構であり、設定されたイベントに対して100%確実に発火します。監査ログにはタイムスタンプ、ツール名、操作内容（コマンドやファイルパス）を記録し、問題が発生した場合の事後調査に備えます。

Hooksの詳細についてはAnthropic公式のHooksガイドを参照してください。

設定ファイルの4層階層を活用する

Claude Codeの設定ファイルは、Managed（最高優先度）→ CI/CDパイプライン等のCLI引数 → Local → Project → User（最低優先度）の4層階層で構成されています。

deny/allowルールが複数の層に存在する場合、配列は**マージ（結合+重複排除）**されます。そして重要な原則として、あるレベルでdenyされたツールは、いかなる下位レベルでもallowできません。

この階層構造を活用し、組織全体のセキュリティポリシーをMDM配布のManaged Settingsで強制し、プロジェクト固有のallow/denyをProject Settingsで定義し、個人の作業スタイルに応じた設定をUser Settingsで調整する——という多層構成が実現できます。

設定ファイルの全仕様はClaude Code Settings公式ドキュメントで確認できます。

バックアップ体制との組み合わせ

deny-firstアーキテクチャは「危険な操作をブロックする」予防的制御ですが、denyの境界外で問題が発生する可能性は残ります。このリスクをカバーするのがバックアップ体制です。

Cloudflareの各サービスには、問題発生時に迅速に復旧できる仕組みが備わっています。Workersは100バージョンの保持とワンコマンドロールバック、D1データベースは30日間のPoint-in-Time Recovery（Time Travel）、Pagesは全デプロイ履歴からの即時ロールバックをサポートしています。

「denyで予防し、allowで自動化し、Hooksで記録し、バックアップで復旧する」——この4つの組み合わせが、承認ゼロ運用の完全な安全アーキテクチャです。技術的な復旧手順の詳細はCloudflareサービスの障害復旧完全ガイドで解説しています。

「スマート承認ゼロ」の設計原則

最後に、承認ゼロ運用を設計する際の原則をまとめます。

denyは狭く、深く設定することが重要です。ブロックすべき操作を正確に特定し、それ以外は積極的にallowします。denyが広すぎると作業効率が落ち、狭すぎるとセキュリティに穴が開きます。破壊的コマンド、機密ファイル、データ流出経路、危険なGit操作、シェルバイパス——この5カテゴリを網羅すれば、実用上の安全性は十分に確保できます。

allowはブランケットで設定することで、個別の操作を1つずつ許可する煩雑さを排除します。「ツール名のみ指定（specifierなし）」のallowルールが、その実現手段です。

監査ログは必ず残すことで、承認プロンプトなしでも「何が起きたか」を事後検証できる状態を維持します。ログの存在自体が、問題の早期発見と迅速な復旧を可能にします。

バックアップは承認ゼロの前提条件です。「問題が起きても元に戻せる」という保証があるからこそ、予防的制御（deny）の境界外のリスクを受容できます。バックアップなしの承認ゼロ運用は推奨しません。

承認プロンプトは、セキュリティのための儀式ではなく、リスク管理の手段の一つにすぎません。deny-firstアーキテクチャは、その手段をより確実で効率的なものに置き換える設計パターンです。

関連リソース