Destructive Command Guard（dcg）とは｜AIエージェントの危険コマンドを実行前ブロック

Destructive Command Guard（Dicklesworthstone/destructive_command_guard・通称 dcg・GitHubスター5,081）は、AIコーディングエージェントの「暴走コマンド」を、シェルに届く一歩手前でブロックするためのRust製フックです。AIに仕事を任せていて背筋が凍った経験はないでしょうか。テストが通らないのを直そうとしたエージェントが、おもむろに git reset --hard HEAD~5 を叩き、午前中ずっと書いていた未コミットの変更が一瞬で消える。あるいは「不要な生成物を消しますね」と言いながら rm -rf ./src を実行する——。dcgはまさにこの種の事故を、実行される前に止めるために作られています。

この記事の主題は2つあります。1つ目は、dcgが実際にどう危険コマンドを止めるのか——PreToolUseフックの仕組みと、90を超えるパック、そして「既定ではどこまで守るのか」という実務的な線引きを、編集部が本物のバイナリを動かして検証した結果です。2つ目は、このプロジェクトのライセンスが標準的なMITではないこと。正式名称は「MIT License (with OpenAI/Anthropic Rider)」で、OpenAIとAnthropicには一切の権利を与えず、学習・評価（eval）での利用まで禁じるという、いま話題になりやすい「反AIベンダー条項」が付いています。誤解されやすい箇所なので、原文を読んで「誰が何をできて、誰が何を禁じられるのか」を正確に整理します。

まずは、dcgを実際にインストールして git reset --hard HEAD~5 をブロックさせた様子から。

なお、Claude Code そのものの設定・フック・CLAUDE.md・本番運用の全体像は Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き にまとめています。本記事はその「安全フック」の一角を深掘りする位置づけです。

Destructive Command Guard（dcg）とは — AIエージェントの暴走コマンドを実行前に止める

dcgは、AIコーディングエージェントが提案したシェルコマンドを、実際に実行される前に評価し、破壊的だと判断したら止めるための小さなRust製プログラムです。作者の Jeffrey Emanuel 氏（GitHub: Dicklesworthstone）は、もともとこれを「AIエージェントは便利だが、ときどき数時間分の未コミット作業を破壊するコマンドを走らせる」という問題意識から、Python製の単純なフックとして書き始めました。初期のRust移植を Darin Gordon 氏（Dowwie）が担い、その後 Emanuel 氏がパックシステム・ヒアドキュメント走査・文脈分類などを大幅に拡張して現在の形になっています。

公式READMEは問題と解決をこう要約しています。問題：AIエージェント（Claude・Codex・Gemini・Copilotなど）は、ときに git reset --hard・rm -rf ./src・DROP TABLE users のような壊滅的なコマンドを実行し、数秒で作業を破壊する。解決：dcgは、それらを実行「前」に横取りしてブロックし、明快な説明とより安全な代替を返す高性能フックである、と。

ここで大事なのは、dcgがエージェント本体を置き換えるものでも、賢いAIレビュアーでもないという点です。dcgは決定論的なパターンマッチャーで、正規表現＋構文解析でコマンドを判定するだけ。だからこそサブミリ秒で動き、判断がブレず、モデルの気分に左右されない。「AIの暴走をAIで止める」のではなく、「AIの暴走を機械的なルールで止める」ツールだと理解すると位置づけが掴めます。

dcgはどう動くのか — PreToolUseフックがシェルの手前で横取りする

現代のコーディングエージェントの多くは「フック」という拡張点を持っています。エージェントがツール（Bashコマンドなど）を実行する直前に、外部プログラムへコマンド内容を渡し、その返り値で実行を許可するか拒否するかを決められる仕組みです。Claude Code ではこれを PreToolUse フック（ツール実行前フック）と呼びます。dcgは、この仕組みを使ったAIエージェント向けの安全フックの代表格で、rm -rf の防止をはじめとする破壊的コマンドのブロックに特化しています。

dcgはこのPreToolUseフックとして登録されます。Claude Codeなら ~/.claude/settings.json に、Bash ツールにマッチする dcg コマンドを1つ足すだけ。エージェントが git reset --hard を実行しようとすると、Claude Codeはまず dcg にそのコマンドを渡し、dcgが「deny（拒否）」を返せば、コマンドはシェルに届く前に止まります。

実機で dcg にフック入力（Claude Codeが渡すのと同じJSON）を食わせると、返ってくるのはこういう構造化データです（抜粋）。

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "BLOCKED by dcg ... git reset --hard destroys uncommitted changes. Use 'git stash' first.",
    "ruleId": "core.git:reset-hard",
    "packId": "core.git",
    "severity": "critical",
    "allowOnceCommand": "dcg allow-once 713809"
  }
}

permissionDecision: "deny" がエージェントに「このコマンドは実行させない」と伝え、permissionDecisionReason に人間・エージェント双方が読める理由が入ります。severity（重大度）や ruleId（どのルールに当たったか）、allowOnceCommand（どうしても実行したいときの一時解除コマンド）まで返る点が親切です。

対応エージェントは幅広いが、強制力には濃淡がある

dcgの強みは「1つの仕組みで多くのエージェントを守れる」ことです。ただし、フックの実装はエージェントごとに違うため、どこまで確実にブロックできるか（強制力）には差があります。公式READMEの記述をもとに整理します。

Cursor が「アドバイザリ（勧告）」に留まるのは、Cursorのアーキテクチャ上、MCPだけではツール呼び出しそのものを阻止できないためです。ここは statewright など他のガードレール系ツールと同じ制約で、Cursorではモデルがルールを無視する余地が残る点は正直に押さえておくべきです。

「grepの検索文字列」と「本当に実行するrm」を見分ける

dcgが単なる grep と決定的に違うのは、文脈を読むことです。rm -rf という文字列がコマンドに含まれていても、それが「実行される rm」なのか「grep の検索対象という単なるデータ」なのかを区別します。実機で確かめた挙動がこれです。

さらに厄介な python -c "os.remove(...)" や bash -c "git reset --hard" のようなインラインスクリプト・ヒアドキュメントも、dcgは三段構えのパイプラインで中身を覗きに行きます。速度を殺さないために、まず超高速な正規表現でヒアドキュメントの兆候だけを検知（Tier 1）、該当したら中身を抽出（Tier 2）、最後に tree-sitter による構文木マッチで危険パターンを判定（Tier 3）する構成です。bash -c "..." の中がさらにシェルスクリプトなら、内側のコマンドを取り出して再帰的に評価します。

何をブロックするのか — 90超のパックと、既定の守備範囲という落とし穴

dcgは危険コマンドのパターンを「パック」という単位でカテゴリ分けしています。実機で dcg packs を数えると、登録されているパックは92（READMEの宣伝文句は「50+」）。データベース、Kubernetes、Docker、AWS/GCP/Azure、Terraform/Pulumi/Ansible、シークレット管理、CI/CD、メッセージング、監視、決済、検索エンジン、バックアップ、DNS、メール——と、実運用で「これを間違って消したら終わり」という領域をほぼ網羅しています。

ただし、ここに最も誤解されやすい落とし穴があります。

有効化は ~/.config/dcg/config.toml にパックIDを並べるだけです。カテゴリID（例 database）を書けば配下の全サブパック（database.postgresql・database.mysql …）が一括で有効になります。

# ~/.config/dcg/config.toml
[packs]
enabled = [
  "database.postgresql",  # DROP TABLE / TRUNCATE を止める
  "kubernetes",           # kubectl delete namespace など一括
  "containers.docker",    # docker system prune を止める
  "cloud.aws",            # aws ec2 terminate-instances を止める
  "infrastructure.terraform",  # terraform destroy を止める
]

エージェントごとに「信頼度プロファイル」を切ることもできます。Claude Codeには広めの許可リストと少なめのパックを、素性の知れないエージェントには追加パックと許可リスト無効化を——といった具合に、disabled_packs・extra_packs・additional_allowlist で調整できます。組織固有の内製ツール向けに、YAMLでカスタムパックを書いて追加することも可能です。

「MIT + OpenAI/Anthropic Rider」を正確に読む

ここが、この記事でいちばん慎重に書くべき箇所です。誤読すると「使えないツール」と誤解しかねないので、原文（LICENSEファイル）を読んだうえで、許可と禁止を正確に切り分けます。

まず事実確認から。dcgのライセンスは、ファイル冒頭が MIT License (with OpenAI/Anthropic Rider) で始まります。GitHubはこのライセンスを標準のどれとも判定できず、NOASSERTION（Other） と表示します。READMEのバッジは正直に License: custom と掲げ、末尾の License 節も「Custom source license based on MIT with an OpenAI/Anthropic rider」と自称しています。つまり作者は「これはMITだ」と偽ってはいません。素の標準MITではないが、その事実を隠してもいない——ここは、以前に扱った Square UI解説｜shadcn/uiレイアウト20種を実機デモで全検証｜MITから独自ライセンスへ が「open-source表記のまま再配布を禁じていた」のとは性格が違う点として、公平に押さえておきます。

肝心の「Rider（追加条項）」の中身です。原文を要約するとこうなります。

・Restricted Parties（制限対象） とは、OpenAI, L.L.C.／Anthropic, PBC／それぞれの関連会社（議決権50%超などで支配関係にある企業）／および、これらのために・利益のために・指示のもとに動く者（役員・従業員・委託先・代理人など）を指す。
・これら Restricted Parties には、このライセンス上いかなる権利も付与しない。Jeffrey Emanuel 氏の書面による事前許可がない限り、Restricted Party への許諾は無効。
・Restricted Party に対して／のために、ソフトウェアや派生物を提供・開示・配布・ホスティング・アクセス提供してはならない。
・ここでいう「use（利用）」には、コピー・改変・実行・ベンチマーク・テスト・解析・インデックス化、およびデータセット・訓練コーパス・評価（eval）ハーネス・機械学習パイプラインへの取り込みが明示的に含まれる。
・Riderは派生物にも及び、再配布時はこのRiderを改変せず同梱しなければならない。違反すると許諾は自動的に終了する。

言い換えると、これは明確な「反AIベンダー」ライセンスです。狙いは「OpenAIとAnthropicが、この安全ツールを自社に取り込んだり、学習・評価データにしたりすること」を封じること。皮肉が効いているのは、dcgはまさにClaude Code（Anthropic）やCodex（OpenAI）にフックとして噛ませて使うツールなのに、そのライセンスは当のAnthropic・OpenAI本体を締め出している点です。

では、あなたはどうなのか。ここが最重要です。

一点だけ、正確を期すために。標準MITは Open Source Initiative の定義（The Open Source Definition）を満たしますが、dcgのRiderは「特定の主体（OpenAI・Anthropic）を差別し」「利用分野（学習・eval）を制限する」ため、OSDの第5項・第6項（人・集団や利用分野を差別しない）に抵触します。したがって厳密には『オープンソース』ではなく、『ソースアベイラブル（source-available）』と呼ぶのが正確です。とはいえ、繰り返しになりますが、99%の利用者にとっての実挙動はMITと変わりません。（本記事は一般的な説明であり、法的助言ではありません。判断に影響する場面では自社の法務にご確認ください。）

dcgは使えるのか — ライセンス・活性度・バス係数・fail-openの正直な評価

「自分のエージェント環境に入れるべきか」を判断するために、良い点と、正直に受け止めるべき点を並べます。

良い点は明快です。導入が数分で済み、1つの仕組みでClaude Code・Codex・Geminiなど複数のエージェントを守れる。Rust製で体感遅延がほぼない。パックが実運用の勘所を広く押さえていて、危険度・ルールID・安全な代替まで返すので、ブロックされたエージェントが「なぜ止まったか」を理解して自分で軌道修正しやすい。開発も活発（最終コミット2026-07-15）です。

一方で、正直に受け止めるべき点が3つあります。

① バス係数がほぼ1。 contributors API実測でコミットの98%超が作者1人（1,762件）、他は dependabot ボットの8件のみ。初期移植は Darin Gordon 氏 が担いましたが、現状は事実上ソロプロジェクトです。ただしdcgは「フックとして薄く噛ませる」性質上、上流が止まっても手元のバイナリと設定は動き続けます。ランタイムやサーバー製品ほど「保守停止＝自分のシステム停止」に直結しない点は、多少の緩和材料です。

② v0.6.x（pre-1.0）。 31リリースを重ねていますが、まだ1.0前です。パックIDや設定スキーマ、出力フォーマットが破壊的に変わる可能性は織り込んでおくべきで、フックコマンドやCI連携を作り込む場合はバージョンをピン留めするのが無難です。

③ fail-open は「安全網」であって「完全な防壁」ではない。 これが最も重要な誤解ポイントです。dcgは解析がタイムアウト・パース失敗した場合、ブロックせずに通す（fail-open）設計です。理由は「正当なコマンドを誤ってブロックする方が、危険なコマンドを1つ見逃すより業務を止める」という思想。さらに DCG_BYPASS=1 や dcg allow-once <code> といった意図的な回避手段も用意されています。公式ドキュメント自身、Codex連携の注記で「モデルはスクリプトをディスクに書き出してフックベースのブロックを迂回でき、unified_exec の全経路を捕捉できるわけでもないので、完全な強制境界ではなくガードレールとして扱うべき」と明記しています。つまりdcgは、うっかり事故（誤爆）を強力に防ぐ一方、悪意や執拗な回避に対する堅い境界ではない。多層防御の一枚として捉えるのが正しい使い方です。

なお高セキュリティ環境向けに、DCG_FAIL_CLOSED=1（パース不能な入力はブロック）や、ヒアドキュメント解析の fail-closed 化といった厳格モードへの切り替えは用意されています。用途に応じて締めることは可能です。

既存の代替と何が違うのか — ネイティブ権限 / statewright との比較

「Claude Code には最初から Bash の許可/拒否ルールがあるのに、なぜ別ツールが要るのか」——これは当然の疑問です。結論から言えば、目的とレイヤーが違います。

Claude Codeのネイティブなパーミッションは「このコマンド（パターン）を許可/拒否するか」をエージェントごと・手動で決める仕組みで、grep の検索文字列とインラインスクリプトの中身までは見ません。dcgはエージェント横断の1設定で、90超のキュレーション済みパックを持ち、文脈解析とヒアドキュメント走査まで行い、ブロック時に安全な代替を提示します。守る対象も方法も別物です。

もう一つ、当サイトで既に解説している Statewright完全解説｜Rust製状態機械ガードレールがSWE-bench 2→10/10に変えた理由 とも、しばしば混同されますが機構が異なります。statewrightは状態機械でフェーズ（planning→implementing→testing）ごとに「呼べるツールそのものを制限」してエージェントの迷走を抑える設計。dcgは個々のコマンドを実行前にブロックする設計。前者は「そもそも危険な操作をさせない土俵づくり」、後者は「危険なコマンドが来た瞬間の水際ブロック」で、併用しても競合しません。

導入と確認 — コピペで動かし、効いているか確かめる

導入は数分です。公式の推奨はワンライナーのインストーラで、プラットフォームを自動判別してビルド済みバイナリを取得し、検出したエージェントのフックまで設定します。

# Linux / macOS / WSL：バイナリ取得＋対応エージェントのフック自動設定
curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh" | bash -s -- --easy-mode

インストーラを使わず手動でClaude Codeだけに噛ませたい場合は、~/.claude/settings.json に以下を足して Claude Code を再起動します（dcg はPATH上に置く）。

{
  "hooks": {
    "PreToolUse": [
      { "matcher": "Bash", "hooks": [ { "type": "command", "command": "dcg" } ] }
    ]
  }
}

Codex CLI（0.125.0+）は ~/.codex/hooks.json に同型の PreToolUse/Bash を、Gemini CLI は ~/.gemini/settings.json に BeforeTool/run_shell_command を設定します（インストーラは検出して自動でやってくれます）。

導入したら、「本当に入っているか・効いているか」を自分の環境で確認しておきましょう。以下はすべて破壊的操作を伴わない読み取り専用コマンドです。

# 1) フックが正しく配線されているか診断（Claude設定・パック・スモークテスト）
dcg doctor

# 2) Claude Code のフック設定に dcg が入っているか
grep -n "dcg" ~/.claude/settings.json

# 3) 実行せずに「このコマンドはブロックされるか」を判定
dcg test "git reset --hard HEAD~5"     # → BLOCKED
dcg test 'grep -r "rm -rf" .'          # → ALLOWED（文脈解析）

# 4) なぜブロックされたか、根拠と代替をトレース表示
dcg explain "rm -rf ./build"

# 5) いま有効なパックの一覧（既定は core.git / core.filesystem / system.disk の3つ）
dcg packs

dcg doctor は「binary in PATH」「Claude Code settings」「hook wiring」「pattern packs」「smoke test」などを順に点検し、問題があれば具体的な直し方を提示します。もしブロックが厳しすぎる場面が出たら、DCG_BYPASS=1 <コマンド>（その1回だけ全解除）、dcg allow-once <コード>（ブロック時に表示される短いコードで一時解除）、dcg allowlist add <ルールID> -r "理由"（恒久的な許可）と、段階的な逃がし方が用意されています。

まとめ — Destructive Command Guard（dcg）を入れるべきか

Destructive Command Guardは、「AIエージェントに手を動かさせるほど、git reset --hard や rm -rf の事故確率が上がる」という現実に対する、シンプルで効果の高い保険です。Rust製で速く、Claude Code・Codex・Geminiなどに1つの仕組みで噛ませられ、既定の3パックだけでも「最も復旧不能な事故」を実行前に止めてくれる。導入は数分、確認コマンドも揃っている——個人・少人数チームなら、入れて損はほぼありません。

同時に、過大評価は禁物です。fail-openと回避手段がある以上、これはうっかり事故を防ぐ安全網であって、悪意ある回避を封じる完全な防壁ではない。実質1人開発（バス係数≈1）でpre-1.0という現実、そしてライセンスが標準MITではなく「反AIベンダーRider」付きのソースアベイラブルである点も、企業導入なら社内審査に載せるべきです。とはいえ、その線引きさえ理解すれば、あなたが使う分には実質MITで自由——「何ができて、何を過信してはいけないか」を掴んだうえで、多層防御の一枚として組み込むのが、dcgの一番賢い使い方です。

参照ソース

・destructive_command_guard（Dicklesworthstone 公式リポジトリ） — スター・リリース・コミット等の実測、README全文
・LICENSE（MIT License with OpenAI/Anthropic Rider） — 本記事のライセンス解説はこの原文に基づく
・Claude Code Hooks 公式ドキュメント — PreToolUseフックの仕様
・The Open Source Definition（Open Source Initiative） — 第5項・第6項（差別禁止）
・Jeffrey Emanuel｜元になったPythonフックのセットアップ手順 — dcgの起源