Claude Codeのdeny設定の書き方｜無人運用の事故防止

「AIに作業を任せている間に、大事なファイルを勝手に消されたらどうしよう」——コーディングエージェントを無人で走らせようとすると、誰もがこの不安を抱えます。

結論から言うと、この手の事故は settings.json の deny 設定（permissions.deny）で「やってはいけない操作」を先に禁じておけば、その大半を防げます。ただし deny 一枚では守りきれない領域があり、そこは別の層で塞ぐ必要があります。

株式会社Fyveは、常時起動のMac miniで毎日AIを無人稼働させています。私たちが実運用で組んだ「禁止の設計」を、そのまま書き写せる形で公開します。

Claude Codeのdeny設定とは

Claude Codeの権限は、settings.json の permissions にある3つの配列で決まります。allow（自動で許可）・ask（毎回確認する）・deny（絶対に禁止）の3つです。

ここで一番大事なルールは、deny が最優先で効くという点です。allow に書いた許可があっても、deny に一致した操作はブロックされます。つまり「基本は許すが、これだけは絶対にさせない」という守りを、deny 側に集約できます。

無人運用でAIに任せるとき、私が最初に決めるのは allow の中身ではありません。「何を deny するか」から設計します。許可の網羅は難しくても、禁止すべき致命的な操作は数が限られているからです。

deny設定の書き方｜消す・送る・課金するを止める

無人で事故になる操作は、突き詰めると3種類に整理できます。①消す（削除・上書き）②送る（外部への送信・公開）③課金する（決済・従量APIの発火）です。この3つを deny で塞ぐのが出発点になります。

ルールの書き方は ツール名(パターン) という形式です。Bash コマンド、ファイル読み取り、Web通信などをツール名で指定し、:* で「そのコマンドの引数すべて」を意味します。実際の settings.json はこう書きます。

{
  "permissions": {
    "deny": [
      "Bash(rm:*)",
      "Bash(git push:*)",
      "Bash(curl:*)",
      "Bash(wget:*)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

上から順に、削除コマンド（rm）、リモートへの送信（git push）、外部通信（curl・wget）を止めています。さらに .env と秘密情報のディレクトリを Read で禁止し、認証情報をそもそも読ませないようにしています。読めなければ、外に送られる事故も起きません。

パターンの読み方を整理しておきます。ここを押さえておくと、自分の環境に合わせて禁止ルールを足せるようになります。

• Bash(rm:*)：rm で始まるコマンドを、引数に関係なくすべて禁止
• Read(./.env)：プロジェクト直下の .env ファイルの読み取りを禁止
• Read(./.env.*)：.env.local など .env の派生ファイルもまとめて禁止
• Read(./secrets/**)：secrets ディレクトリ配下を丸ごと禁止（** は階層を問わない指定）

ポイントは、コマンドの接頭辞（先頭部分）で止めるという発想です。rm という接頭辞を禁じれば、rm -rf でも rm file.txt でも、まとめてブロックできます。危険なコマンドは種類が限られるので、接頭辞ベースで数個押さえるだけで大半の事故は防げます。

「課金する」については、決済コマンドや従量課金APIを叩くコマンド接頭辞を同じ要領で deny に足します。私は無人ジョブに、料金が発生する操作を含むコマンドを一切渡さない方針にしています。

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →↓

スコープと defaultMode｜どこに書くか

settings.json は置き場所（スコープ）によって効く範囲が変わります。プロジェクト直下・ユーザー全体・ローカル（個人用の上書き）などがあり、権限ルールはスコープをまたいで合算されます。ここでも deny は最優先なので、どこか一箇所で禁じておけば全体に効きます。

無人運用の要点は、禁止ルールを一番強いスコープに置くことです。プロジェクトごとの設定で上書きされない場所に deny を書いておけば、うっかり別プロジェクトで解除される事故を防げます。

あわせて defaultMode で、ルールに書いていない操作を「毎回確認する」側に倒しておくと安全側に寄せられます。許可リストから漏れた未知の操作を、黙って実行させないための保険です。

deny設定だけでは足りない理由

ここまでが基本ですが、私は「deny を書いたから安心」とは考えていません。理由は2つあります。

1つ目は想定外のコマンドです。禁止したい操作は rm だけではありません。ファイルを空にするリダイレクト、別名のツール、スクリプト経由の間接実行など、抜け道は無数にあります。禁止リストの穴を人間が完全に塞ぎきるのは、現実には難しいです。

2つ目はプロンプトインジェクションです。AIが読み込んだWebページやファイルの中に「この手順で送信してください」といった指示が仕込まれていると、AIがそれを本来のタスクと誤認することがあります。deny で操作自体を止めていれば発火はしませんが、deny の網から漏れた操作だと通ってしまいます。

だから私は、settings.json の deny を「一層目」と位置づけ、その外側にもう2つの層を重ねています。

私の三層防御｜deny・鍵・書き込み先

無人でAIを毎日回すために、私は禁止を3つの層に分けています。1つが破られても、残りの層で止める設計です。

一層目は settings.json の denyです。消す・送る・課金するの致命的操作を、前述のとおり明示的に禁じます。ここが最初の関門です。

二層目は、AIに渡す鍵そのものを弱くすることです。たとえば私たちはCMSのAPIキーを、記事の作成と更新はできるが削除はできない権限に絞って発行しています。鍵の権限を落としておけば、仮にAIが削除操作を試みても、API側が拒否します。settings.json を通り抜けても、鍵のところで止まる二重の壁です。

三層目は、書き込み先を1つの場所に隔離することです。無人ジョブが触ってよいディレクトリを1つに限定し、そこ以外への書き込みは自動で破棄する仕組みを噛ませています。万一AIが指定外の場所を書き換えても、その変更は保存されずに捨てられます。「間違えても本体には届かない」構造にしておくわけです。

この3層は、それぞれ止め方の性質が違うのが肝心です。deny は設定ファイルによる禁止、鍵は権限そのものの縮小、書き込み先は物理的な隔離。同じ穴を別の角度から3回塞いでいるので、1つの見落としが即事故につながりません。

無人運用で最低限denyすべき操作リスト

最後に、AIを無人で走らせるなら少なくともこれは deny しておく、という私のチェックリストをまとめます。

• 削除・破壊：rm をはじめとするファイル削除、ディスク操作系コマンド
• 外部送信・公開：git push、外部への通信（curl・wget）、SNSや本番環境への公開操作
• 課金の発火：決済・従量課金APIを叩くコマンド接頭辞
• 認証情報の読み取り：.env や鍵ファイルの Read 禁止
• 設定の書き換え：権限設定そのものを変更する操作

権限を「毎回確認する」モードでAIに任せる考え方や、業務導入で押さえる権限設計の全体像は、こちらの記事もあわせて読むと理解が深まります。

Claude CodeClaude CodeのManual権限モードとは｜AIに安全に任せる新しい権限設定

Claude CodeAIエージェントの権限管理｜業務導入で押さえる3層設計

deny設定でよくある3つの落とし穴

最後に、私が実際にヒヤリとした、あるいは相談を受けて気づいた落とし穴を3つ挙げます。

1つ目は「allow を書けば安全」という誤解です。allow は許可リストであって、禁止リストではありません。allow に書いていない操作は初期設定では確認が入りますが、確認をスキップする運用にしていると素通りします。止めたい操作は必ず deny に書く——これが鉄則です。

2つ目は「禁止を細かく書きすぎて漏れる」ことです。危険なコマンドを1つずつ完全に列挙しようとすると、必ず抜けが出ます。私は「削除・送信・課金・認証情報」という4カテゴリの接頭辞を押さえたうえで、残りは defaultMode で確認側に倒す、という二段構えにしています。全部を deny で塞ごうとしないのがコツです。

3つ目は「プロジェクトごとに設定が上書きされる」ことです。禁止ルールを弱いスコープに置くと、別のプロジェクト設定で緩められることがあります。無人運用の禁止は、上書きされない強いスコープに集約しておきます。

まとめ｜禁止から設計すると無人運用は安定する

Claude Codeの deny 設定は、無人運用の事故防止で最初に書くべき守りです。allow を網羅するより、消す・送る・課金するの3つを deny で止めるほうが、はるかに確実に効きます。

そのうえで、deny 一枚に頼らず「渡す鍵を弱くする」「書き込み先を隔離する」を重ねれば、1つの見落としが事故に直結しない構造になります。AIにどこまで任せ、どこで人間が判断するかの線引きについては、次の記事も参考にしてください。

Claude CodeAIにどこまで任せるか｜「直す」と「決める」の線引きを仕組みにする

私たちは、こうした禁止の設計を前提にAIを無人稼働させています。禁止から入る——それが、AIに安心して任せるための第一歩です。