最新AIニュース
Claude Code hooksで危険コマンドを止める安全な自動化HowTo
← 記事一覧に戻る
Claude CodehooksAI開発HowToMCPSkills

Claude Code hooksで危険コマンドを止める安全な自動化HowTo

約 12 分
Claude Codeでhooksを使い、危険なBash操作を止めながら編集後の確認を自動化する手順を整理します。settings.jsonの最小構成、PreToolUseとPostToolUseの使い分け、MCPやSkillsと組み合わせるときの確認点まで、実務で導入しやすい形で説明します。
編集方針: 公開情報と参考文献をもとに要点を整理し、記事末尾に確認できる出典を掲載しています。
ポストシェア送る

Claude Codeを日常の開発に入れると、ファイル編集、Bash実行、テスト、整形までまとめて任せたくなります。ただし、git reset --hard、git push --force、広い削除コマンド、秘密情報を含むファイルへの不用意なアクセスまで許してしまうと、レビュー前に取り返しがつきにくくなります。

この記事では、Claude Codeのhooksを使って「任せてよい作業」と「止める作業」を分ける方法をHowTo形式で整理します。ゴールは、Claude Codeを縛りすぎることではありません。差分、ログ、権限を人間が確認できる状態にしながら、繰り返し作業だけを安全に自動化することです。（出典: Hooks reference）

まず作る構成

最初に、設定ファイルとhookスクリプトの置き場所を決めます。いきなり複雑な仕組みにせず、プロジェクト内で見える場所に置くのがポイントです。

project-root/
└── .claude/
    ├── settings.json
    └── hooks/
        ├── block-dangerous-commands.sh
        └── check-edited-files.sh

役割は次のように分けます。

ファイル 役割 最初に入れる内容
.claude/settings.json hookのイベントとコマンドを登録する PreToolUseとPostToolUse
block-dangerous-commands.sh 危険なBashを止める 強制pushや広い削除の検知
check-edited-files.sh 編集後の確認を走らせる format、lint、差分確認

Claude Codeのhooksには複数のイベントがあります。実務で最初に使いやすいのは、ツール実行前に止められるPreToolUseと、編集後に確認を走らせるPostToolUseです。コミュニティでも、PostToolUseで整形を走らせる、PreToolUseで危険操作を止める、といった運用が話題になっています。（出典: Reddit）

Step 1：PreToolUseで危険なBashを止める

まず、危険操作を止めるhookを作ります。最初から完璧なセキュリティルールを作る必要はありません。明確に止めたいコマンドだけを対象にします。

#!/usr/bin/env bash
set -euo pipefail

payload="$(cat)"
command="$(printf '%s' "$payload" | jq -r '.tool_input.command // ""')"

if printf '%s' "$command" | grep -E 'git push --force|git reset --hard|rm -rf /|rm -rf \\.' >/dev/null; then
  echo "Blocked dangerous command: $command" >&2
  exit 2
fi

exit 0

ここで重要なのは、止める対象を広げすぎないことです。たとえばrmを全部止めると、通常の一時ファイル削除まで止まります。最初は「強制push」「hard reset」「広すぎる削除」のように、人間の確認なしでは危ない操作に絞ります。

PreToolUseはツール呼び出し前に実行されるため、危険なBashを実行前にブロックできます。hookの終了コードやJSON出力の扱いは公式リファレンスで確認できます。（出典: Hooks reference）

Step 2：settings.jsonにhookを登録する

次に、.claude/settings.jsonへhookを登録します。Bash実行だけに反応させたいので、matcherを絞ります。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/block-dangerous-commands.sh"
          }
        ]
      }
    ]
  }
}

この段階で確認することは3つです。

  • 通常のgit statusやnpm testは通るか。
  • git reset --hardのような危険操作だけ止まるか。
  • ブロック理由がstderrに出るか。

Claude Codeに依頼するなら、次のように範囲を明確にします。

対象ファイル: .claude/settings.json と .claude/hooks/block-dangerous-commands.sh
変更範囲: Bash実行前に危険コマンドを止めるPreToolUse hookを追加する
制約: 既存設定は消さない。ブロック時は理由をstderrに出す
確認観点: git statusは通り、git reset --hard と git push --force は止まるか

Step 3：PostToolUseで編集後の確認を自動化する

危険操作を止められたら、次は編集後の確認です。PostToolUseは、Claude Codeがファイルを編集した後に実行できます。公式ガイドでも、編集後に自動整形を走らせる例が紹介されています。（出典: Automate workflows with hooks）

最小例は次のような考え方です。

#!/usr/bin/env bash
set -euo pipefail

payload="$(cat)"
file_path="$(printf '%s' "$payload" | jq -r '.tool_input.file_path // empty')"

case "$file_path" in
  *.ts|*.tsx|*.js|*.jsx)
    npx prettier --write "$file_path"
    ;;
esac

ただし、全ファイルに対して重いテストを走らせるのは避けます。編集のたびに長時間のテストが走ると、Claude Codeの作業が遅くなり、失敗時の原因も追いにくくなります。

おすすめは次の分担です。

  • PostToolUse: 対象ファイルだけformatする。
  • Stop: 最後にlintやテストをまとめて実行する。
  • 人間: 最終的なgit diffとログを確認する。

Step 4：Skillsに確認手順を切り出す

hookは「自動で実行する処理」です。一方、Skillsは「Claude Codeに使わせる作業手順」です。両方を混ぜると管理しづらくなります。

たとえば、リリース前確認の観点はhookではなくSkillにします。SKILL.mdのdescriptionは、ClaudeがいつSkillを使うか判断する材料になります。（出典: Agent Skills）

.claude/
└── skills/
    └── release-check/
        └── SKILL.md

---
name: release-check
description: リリース前に差分、テスト、設定、公開影響を確認するSkill
---

# リリース前確認

## 入力
- 対象ブランチ
- 変更目的
- 確認してほしいファイル

## 手順
1. 差分を要約する。
2. テスト不足を確認する。
3. 本番影響がある変更を分ける。
4. 人間が判断すべき点を列挙する。

## 出力形式
- 変更概要
- リスク
- 確認コマンド
- 反映前の確認点

hookで止めるのは、機械的に危険だと判断できる操作です。Skillに書くのは、状況を読んで判断してほしい確認観点です。この分担を守ると、Claude Codeの挙動を追いやすくなります。

Step 5：MCPは読み取り中心から始める

MCPを使うと、Claude Codeは外部ツールや社内データに近づけます。便利ですが、最初から広い権限を渡すと、hookだけでは守れない範囲が増えます。Claude CodeのMCP設定では、プロジェクトルートの.mcp.jsonを使う構成が紹介されています。（出典: Connect Claude Code to tools via MCP）

最初に決めることは次の3つです。

接続するツールを決める
  ↓
読み取りだけで始める
  ↓
対象リポジトリやディレクトリを限定する
  ↓
ログと差分を人間が確認する
  ↓
必要な範囲だけ書き込みを許可する

MCPを使うときの注意点は、秘密情報を設定ファイルに直接書かないことです。公式ドキュメントでは、.mcp.jsonで環境変数展開を使い、チームで共有しやすくしつつ、APIキーの実値を避ける方法が示されています。（出典: Connect Claude Code to tools via MCP）

人間が確認するリスト

最後に、人間が見る場所を固定します。ここが曖昧だと、hookとSkillを入れても「何となく安全そう」で終わります。

  • git diffで変更範囲が依頼どおりか。
  • hookが止めたコマンドと理由がログに残っているか。
  • MCPの接続先と権限が必要最小限か。
  • .env、トークン、接続文字列が差分に入っていないか。
  • formatやlintの失敗をClaude Codeが無視していないか。
  • 戻す手順が分かる単位でコミットできるか。

Claude Codeに任せてよいのは、差分作成、対象ファイルだけの整形、確認コマンドの実行、ログ要約です。人間が止めるべきなのは、権限拡大、秘密情報の扱い、本番デプロイ、破壊的なGit操作です。

まず入れるならこの順番

最初の導入順は、次の形が扱いやすいです。

  1. .claude/settings.jsonを作る。
  2. PreToolUseで危険なBashだけ止める。
  3. PostToolUseで対象ファイルだけformatする。
  4. リリース前確認をSkillに切り出す。
  5. MCPは読み取り中心で接続する。
  6. 最後に人間が見る差分、ログ、権限を固定する。

この順番なら、Claude Codeをいきなり全自動化するのではなく、危ない操作を止めながら少しずつ作業範囲を広げられます。hookは安全装置、Skillは作業手順、MCPは外部接続、と分けて考えるのが実務では一番管理しやすいです。

参考文献

Hooks reference Automate workflows with hooks Agent Skills Connect Claude Code to tools via MCP Claude Code user FAQ Reddit: Claude Code hooks

関連記事

← 記事一覧に戻る