Claude Code の Permissions 設計を本気で書く — AIエージェントによるDB削除事故を防ぐローカル設定パターン

はじめに

最近「AIコーディングエージェントに任せていたら本番DBを削除された」という事故がしばしば話題になります。

Claude Code を実務で使い倒している立場としては、こうした事故は設定でかなり防げる と感じています。

本記事では、Claude Code の permissions 設定をベースに、破壊的操作を未然に防ぐローカル設定パターン を整理します。

対象読者:

• Claude Code を実務で使い始めた人
• AIエージェントの暴走を恐れて全 confirm ありで使ってる人（=本当の脅威にむしろ気付きにくくなる）
• DB / Git / クラウドリソース操作を AI に任せ始めたい人

設定ファイルの全体像

Claude Code は ~/.claude/settings.json（ユーザー設定）と .claude/settings.json（プロジェクト設定）から permissions を読みます。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git status)",
      "Bash(git diff:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(npm publish:*)"
    ]
  }
}

3つのリストの意味：

• allow: 確認なしで実行
• ask: 実行前に毎回ユーザーに確認
• deny: そもそも実行を拒否

ポイントは 「allow を絞る」 ことではなく、「deny で絶対やってほしくないものをハードガード、ask で迷うものを段階化」 することです。

パターン1: 破壊的Bashの deny

これは全プロジェクト共通でやっておきたい鉄板。

{
  "permissions": {
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(rm -rf /)",
      "Bash(sudo rm:*)",
      "Bash(:(){ :|:& };:)",
      "Bash(dd if=:*)",
      "Bash(mkfs:*)",
      "Bash(shred:*)"
    ]
  }
}

:* は引数を含む全パターンに対応するワイルドカード。rm -rf から始まるあらゆるパターンを deny にします。

これを ~/.claude/settings.json に書いておくと、プロジェクトを切り替えても確実にガードがかかる。

パターン2: Git の戻せない操作だけ ask に上げる

Git は通常運用での操作（status / diff / add / commit）はサクサク動かしたい。一方で push --force や branch -D は事故ると戻せません。

{
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git log:*)"
    ],
    "deny": [
      "Bash(git push --force:*)",
      "Bash(git push -f:*)",
      "Bash(git reset --hard:*)",
      "Bash(git branch -D:*)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(git rebase:*)",
      "Bash(git checkout:*)"
    ]
  }
}

--force は完全に deny。普通の push は ask。これだけで「履歴をぶっ壊された」事故はかなり減ります。

パターン3: DBのDDL/DELETE系をMCPサーバ単位でガード

DB に関しては、MCPサーバ経由での操作になるケースが増えています。Claude Code の MCP 連携でも permissions で個別ツール単位の制御ができます。

{
  "permissions": {
    "allow": [
      "mcp__supabase__list_tables",
      "mcp__supabase__execute_sql"
    ],
    "deny": [
      "mcp__supabase__apply_migration"
    ],
    "ask": [
      "mcp__supabase__execute_sql"
    ]
  }
}

ここで重要なのは apply_migration のような「スキーマを変える」系を deny に入れる こと。

execute_sql は読み取りクエリにも使うので allow したい一方、DELETE / DROP / TRUNCATE が混じる可能性もあります。安全寄りに振るなら ask に置いて毎回プレビューする運用が良いです。

パターン4: 本番接続情報を環境変数で分離する

設定上のガードに加えて、そもそも本番に接続できる状態でAIエージェントを起動しない のが最終防衛線です。

# 開発DBで起動
DATABASE_URL=postgres://localhost/dev claude

# 本番接続が必要な作業はAIなしで人間がやる
DATABASE_URL=postgres://prod-host/prod psql

.envrc や direnv でディレクトリ単位に環境変数を分離しておけば、Claude Code を起動した時点で 本番に手が届かない 状態を作れます。

パターン5: hooks で実行前ログを残す

hooks を使うと、各ツール実行の前後に任意のコマンドを差し込めます。事故った時の証跡を残すのに有効です。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"$(date) $CLAUDE_TOOL_NAME $CLAUDE_TOOL_INPUT\" >> ~/.claude/exec.log"
          }
        ]
      }
    ]
  }
}

PreToolUse はツール実行直前に走るフックなので、実行されたコマンドが全部ログに残る。何か起きた時の事後検証用に効きます。

まとめ

Claude Code の事故を防ぐローカル設定パターン:

1. deny で破壊的Bashをハードガード（rm -rf / mkfs / shred）
2. Git の force系を deny、push を ask に
3. MCPサーバの DDL系を deny / DML系を ask
4. 本番接続情報を環境変数で分離（そもそも届かない）
5. PreToolUse hook で実行ログを残す（事後検証）

「AIエージェントが暴走した」と言われる事故の多くは、設定段階で防げる範囲 にあります。

---

この記事は現役CTOがClaude Codeを実務で使う中での運用ノウハウです。

関連: 教材で手を動かして学ぶ

• まず無料で試したい方: 教材の体験版を GitHub で配布中（git clone してすぐ動かせます） → https://github.com/ayies128/next-ai-camp-trial
• 全20セッション完全版＋メンタリング → https://menta.work/plan/20251
• YouTubeチャンネル → https://www.youtube.com/channel/UC1rXVD9WYsQPQEWZyd-A1KA/