はじめに — 承認プロンプトはセキュリティの万能薬ではない

AIコーディングツールの利用が急速に広がる中、多くの組織が承認プロンプト（人間による操作確認） をセキュリティの主要な防御手段として位置づけています。ファイルの編集、コマンドの実行、外部APIの呼び出し——あらゆる操作で「本当に実行しますか？」と確認を求めることで、危険な操作を防いでいるつもりになっています。

しかし、セキュリティの専門家の間では、過剰な承認プロンプトはセキュリティを低下させるという認識が広まっています。これは「アラート疲れ（Alert Fatigue）」として知られる現象であり、SRE（Site Reliability Engineering）の分野でも「対処不要なアラートはノイズであり、ノイズが多いと本当のアラートを見逃す」という原則として確立されています。

本記事では、AIコーディングツールの承認をゼロにする場合のセキュリティリスクを体系的に評価し、四層防御モデルによる対策を解説します。deny-firstアーキテクチャの設計方法についてはClaude Codeの承認プロンプトをゼロにするを、バックアップ体制についてはCloudflareサービスの障害復旧完全ガイドをあわせてご覧ください。

AIコーディングツールの脅威動向（2025-2026年）

2025年から2026年にかけて、AIコーディングツールに関する重大なセキュリティインシデントが複数報告されています。

CVE-2025-59536（CVSS 8.7） は、悪意あるリポジトリの設定ファイルを通じた任意コード実行の脆弱性です。開発者が信頼できないリポジトリをクローンして開くと、ツールの初期化処理中にユーザーの確認なく任意のシェルコマンドが実行されるというものでした。

CVE-2025-53773（CVSS 7.8） は、GitHub Copilotにおいてワークスペース設定の変更を通じたリモートコード実行が可能な脆弱性です。攻撃者はリポジトリに埋め込んだ設定変更により、自己伝播する「AIウイルス」を作成できる状態でした。

これらのCVEに共通する特徴は、いずれも承認プロンプトでは防御できなかったという点です。CVE-2025-59536は承認ダイアログの表示前に攻撃が完了し、CVE-2025-53773は正常な操作として承認を通過しました。

業界全体の統計データも、AIコーディングツールのセキュリティリスクの大きさを示しています。Veracodeの2025年調査によれば、AI生成コードの約45%に高重大度の脆弱性が含まれ、Snykの調査ではAI共著のプルリクエストは人間のみのコードと比較して2.74倍の脆弱性を含むことが報告されています。

OWASPの2025年版LLM Top 10では、**プロンプトインジェクション**が第1位のリスクに指定されています。外部コンテンツに埋め込まれた悪意ある指示がAIに正常な操作として解釈されるこの攻撃は、自動実行モードで66.9-84.1%の成功率を示す研究もあります。

リスク分類 — 承認プロンプトが防御できる範囲を正しく理解する

セキュリティリスクを正しく評価するには、承認プロンプトが実際に防御できるリスクと防御できないリスクを区別する必要があります。

承認プロンプトで防御できないリスクは意外に多く存在します。プロンプトインジェクション攻撃では、AIが悪意ある操作を正常な操作として提示するため、承認ダイアログを見ても人間は異常に気づきません。AI生成コードの脆弱性についても、承認ダイアログでコードの安全性を判断できる人間はまずいません。サプライチェーン攻撃においては、npm installの承認ダイアログで「このパッケージは安全か？」を判断することは現実的に不可能です。

承認プロンプトが一定の防御力を持つリスクは、対外メッセージの送信（送信内容の妥当性は人間が判断できる）や、明らかに危険なコマンドの誤実行（rm -rf / のような自明な破壊操作）に限られます。

つまり、承認プロンプトがセキュリティ上の価値を持つ場面は極めて限定的なのです。

四層防御モデル

承認プロンプトに代わるセキュリティアーキテクチャとして、以下の四層防御モデルを提案します。

第1層 — denyルール（決定論的ブロック）

破壊的コマンド、機密ファイルへのアクセス、データ流出経路となるコマンドを、パターンマッチにより100%ブロックします。この層はAIの判断に一切依存せず、denyルールに該当する操作は常にブロックされます。

denyルールの最も重要な特性はdeny-first設計であり、いかなるallowルールやHooksの設定でもdenyを覆すことができないという点です。これにより、設定ミスや権限昇格攻撃によるdenyの無効化を防ぎます。

第2層 — サンドボックス（OS レベル分離）

Claude Codeは2025年10月にOSレベルのサンドボックス機構を実装しました。Linuxではbubblewrap、macOSではseatbelt、WindowsではWSL2ベースの分離を使用し、Bashコマンドのファイルシステムアクセスとネットワーク通信をOSレベルで制限します。

denyルールはエージェント型AIとしてのClaude Codeのツール選択をブロックしますが、Bash経由の間接アクセスまでは制御できません。サンドボックスはこのギャップを埋める補完的な防御層です。

第3層 — 監査ログ（全操作記録）

PostToolUse Hooksにより、全操作をJSON Lines形式のログファイルに自動記録します。タイムスタンプ、ツール名、操作内容を含む構造化ログは、事後の異常検出やインシデント対応の基盤になります。

監査ログは「セキュリティイベントの後付け検出」を可能にします。リアルタイムでの防御は第1層と第2層が担い、第3層は「問題が発生した場合に迅速に発見・調査する」ための仕組みです。

第4層 — バックアップ（復旧保証）

すべての予防的制御を突破する問題が発生した場合に備え、迅速に復旧できる体制を確保します。Cloudflare Workersの100バージョンロールバック、D1データベースの30日間Time Travel、Pagesの無制限デプロイ履歴がこの層を支えます。

復旧手段の詳細はCloudflareサービスの障害復旧完全ガイドを参照してください。

「セキュリティ劇場」を超えて

セキュリティの専門家として、一つ重要な指摘をします。

形式的な承認プロンプトは「セキュリティ劇場」になりやすいという事実です。セキュリティ劇場とは、実際のセキュリティ向上にはほとんど寄与しないにもかかわらず、安心感を提供するだけの対策を指します。

1セッションで50回以上の承認プロンプトが表示される環境は、まさにセキュリティ劇場の典型例です。人間は内容を読まずに「Yes」を押す習慣がつき、本当に危険な操作が紛れても気づかず、承認の「判断コスト」が生産性を圧迫し、結果的に急いで承認するという悪循環に陥ります。

適切なdenyルールによる少数の絶対的ブロックは、多すぎる承認プロンプトよりセキュリティ上も優れています。denyルールは疲労しませんし、見落としもありません。

Webサイトのセキュリティ対策チェックリスト2026年版で解説したセキュリティの基本原則——「完璧を目指すのではなく、最低限の対策を確実に実行する」——は、AIツールのセキュリティにも同じように当てはまります。

まとめ — 承認ゼロ運用の条件

四層防御モデルに基づく承認ゼロ運用は、以下の5条件を満たす場合に安全に実施できます。

denyルールの網羅的設定として、破壊的コマンド、機密ファイル保護、データ流出経路遮断を決定論的にブロックすること。監査ログの常時記録として、PostToolUse Hooksによる全操作の自動記録を有効にすること。バックアップ体制の確認として、D1 Time Travelの有効化、Workers/Pagesロールバック可能状態、Gitリモートの同期を確認すること。ツールの最新バージョン使用として、既知のCVE（CVE-2025-59536、CVE-2026-21852等）の修正パッチが適用されたバージョンを使用すること。定期的な監査ログレビューとして、週次で異常パターンがないかを確認すること。

これらの条件が揃えば、人間の承認プロンプトはセキュリティ上の価値をほとんど持たず、むしろアラート疲れによるリスク増大要因になります。deny-firstアーキテクチャへの移行を検討する価値は十分にあります。

関連リソース