Claude Code Hooksとは？AIルールを強制する設定方法【2026】

Claude Code に必ず守らせたいルールを CLAUDE.md やプロンプトだけに書くと、モデルが毎回の試行で従うかどうかは不安定になります。許可の範囲と必須のチェックは、ランタイムが毎回確実に評価する仕組みに移す必要があります。

📑目次

1. プロンプトではルールを強制できない
2. テクノロジー現場で権限ルールを先に閉じる
3. Hooksで非交渉ルールを毎回実行する
4. ガイドとセンサーを分ける
5. 最初の1週間で入れるチェックリスト
6. よくある質問
7. まとめ

CLAUDE.md はガイド、権限ルールはできることの上限、Hooks は毎回確実に動くセンサーです。技術の現場で事故につながる操作は先に deny / ask で閉じ、残った非交渉ルールだけを PreToolUse / PostToolUse / Stop に置きます。

公式ドキュメントの読み順

公式の Configure permissions は、プロンプトや CLAUDE.md が「何を試みるか」を形作っても許可範囲は変えない、と分けています。

強制したいなら、Hooks reference と Automate actions with hooks の側を先に読みます。

---

プロンプトではルールを強制できない

指示とランタイムの層

毎回必ず実行したい処理を指示文に残すと、守られなかった瞬間に品質ゲートが消えます。指示ファイルはモデルに従ってもらうことを期待する仕組みであり、権限と hook はランタイムが確実に評価します。

公式の permissions は、CLAUDE.md が許可の範囲を勝手に広げたり狭めたりしないよう明記しています。独立した解説でも、同じ役割分担が示されています。

• Blake Crosley は、lint / format / security check のように必ず走らせたい処理は hook へ置き、プロンプトは実行を保証しないと対比しています。
• Vibehackers は CLAUDE.md を advisory と呼び、おおむね 80% 追従という二次観察を置いたうえで、force-push 禁止や編集後 lint のような非交渉事項には足りないとしています。

80% は公式数値ではなく二次報告なので、設計の根拠には「毎回実行されるか」だけを使います。

---

機械判定を品質ゲートにする

かあくんの Interface 2026年9月号レビュー は、別の AI レビューではなくテストや静的解析などの機械判定を品質ゲートにせよ、と整理しています。読者判断は明確です。「毎回必ず」が要件なら、プロンプトに残しません。

CLAUDE.md に残してよいものと、機械側に移すべきものは次のとおりです。

• 文体や優先順位は CLAUDE.md で足ります。
• 秘密ファイルの読み取り禁止、破壊的 git、出荷前テストは機械側へ移します。

CLAUDE.md の書き分けは、別記事の CLAUDE.md設計パターン も参照できます。

---

テクノロジー現場で権限ルールを先に閉じる

評価順と導入手順

hook を増やす前に、できること自体を絞ります。公式の評価順は deny → ask → allow です。最初に一致した規則が勝ち、狭い allow は広い deny の例外になりません。Bash(aws *) を deny したうえで Bash(aws s3 ls) を allow しても、広い deny が先に勝ちます。

導入は、次の順序で進めるのが安全です。

1. /permissions で現行ルールと由来ファイルを確認する。
2. 破壊的 git、削除、本番デプロイを scoped deny または ask にする。例は Bash(rm *) です。裸の Bash deny はツール自体を文脈から外します。ツールは残し、危険な呼び出しだけ止めたいなら specifier 付きにします。
3. 秘密ファイルは Read(./.env) を deny する。追加ディレクトリはファイルアクセスだけ増えます。hook の探索範囲は cwd の .claude/ と user / managed です。

---

権限モードと永続承認

権限モードも、できることの上限を変えます。

• default / manual は初回確認
• acceptEdits は作業ディレクトリ内の編集と一部ファイル操作を自動承認
• plan は読み取り中心
• auto は分類器
• dontAsk は事前許可以外を拒否
• bypassPermissions はプロンプトを飛ばします

bypass でも rm -rf / と rm -rf ~ は回路遮断が残ります。一方で .git や .claude への書き込み確認は bypass で飛びます。コンテナや VM 向けであり、通常の開発マシンでは既定にしない方が安全です。managed settings の permissions.disableBypassPermissionsMode で bypass / auto を封じられます。

永続 Bash 承認は、Claude Code v2.1.211 以降、git ルートの .claude/settings.local.json に保存されます。ホームがリポジトリルートの場合や非 git では起動ディレクトリへ落ちます。個人例外をチーム共有ファイルに混ぜないための境界です。

---

先に実行不能にする操作

Data Studios は、権限を読み取り・編集・コマンドの least-privilege なフィードフォワード制御と呼びます。破壊的 git / 削除 / デプロイは deny または承認必須と整理しています。

技術チームが先に決めるべきなのは「どのコマンドを会話で相談するか」ではなく、「どの操作を実行不能にするか」です。

---

Hooksで非交渉ルールを毎回実行する

権限で閉じたあとに残る「毎回やらねば事故になる」処理だけを hook にします。公式ガイドは hook を、LLM が選ぶのではなく、特定の操作を必ず行う決定論的な制御だと定義しています。イベントは次の3つの層です。

• セッションごと: SessionStart / SessionEnd
• ターンごと: UserPromptSubmit / Stop / StopFailure
• ツールごと: PreToolUse / PostToolUse

最小の4ステップ

最小の構成は、次の4つの手順です。

1. プロジェクト共有なら .claude/settings.json に hooks を書き、/hooks で登録を確認する。メニューは読み取り専用で、追加・変更は JSON 編集です。
2. PreToolUse の matcher を Bash、if を Bash(rm *) のようにし、危険コマンドは JSON deny または exit 2 で止める。
3. PostToolUse の matcher を Edit|Write にし、lint / format を走らせる。失敗は Claude に返して即修正させます。
4. Stop hook、または既存 CI で format / lint / build / test を出荷条件にする。Takumi の ハーネス比較 は、Spotify Honk が stop hook でこれらを回し、1つでも落ちたら PR を開かない、という二次事例を紹介しています。自前で同じ製品を再現する必要はなく、「通らなければ出さない」だけを真似します。

---

終了コードとタイムアウト

終了コードを取り違えると、危険な操作が通ってしまいます。

• exit 0 は承認ではなく「決定なし」です。有効な JSON がなければ通常の権限フローへ進みます。
• コード単独でブロックできるのは exit 2 です。
• exit 1 などの他コードは、有効 JSON がなければ非ブロックエラーとして続行します。
• ポリシー強制には exit 2、または PreToolUse の permissionDecision: "deny" を使います。
• 複数 hook の優先度は deny > defer > ask > allow です。

数値も、運用に大きく影響します。

• command / http / mcp_tool の既定 timeout は 600 秒
• UserPromptSubmit は 30 秒
• agent hook は 60 秒で最大 50 tool turns
• SessionEnd は全体 1.5 秒（設定で最大 60 秒）
• Notification の permission_prompt は約 6 秒無入力
• idle_prompt は応答後約 60 秒無入力

時間のかかる lint を UserPromptSubmit に置くと、タイムアウトで空振りします。

---

制約と未信頼リポジトリ

制約は、次の3つを覚えるだけで十分です。

• PostToolUse は実行済み操作を取り消せません。阻止は PreToolUse です。
• PreToolUse の deny / exit 2 は bypassPermissions でも有効です。逆に hook の allow は settings の deny / ask を越えません。
• 未レビュー clone を claude -p するとフォルダが trusted 扱いになり、.claude/settings.json の hook が即走ります。--bare か disableAllHooks を先に検討します。

ユーザー設定だけ disableAllHooks: true にしても、プロジェクト設定が上書きできます。managed hook は managed 側でも無効化しない限り残ります。

---

イベントと向き先

イベントと送り先の対応は次のとおりです。

イベント	向き先	失敗時の扱い
PreToolUse	破壊コマンド、保護パス編集の阻止	exit 2 または JSON deny で実行前に止める
PostToolUse	Edit / Write 後の lint / format	実行済みは取り消せない。結果をモデルへ返す
Stop	出荷前の test / build	失敗なら応答完了を止め、CI と役割分担する
UserPromptSubmit	入力時点の短い検査	既定 30 秒。重い処理は置かない

出典：Hooks reference、Hooks guide（2026年8月時点）

既存の Claude Hooks 活用ガイド は自動化の幅を扱っています。本記事は「どの層に何を置くか」と、最初の1本を間違えないことに絞ります。リポジトリ解析で hook 候補を出したい場合は Claude Code Setup 公式プラグイン も起点になります。提案をそのまま採用せず、非交渉だけ残します。

---

ガイドとセンサーを分ける

短い約束は CLAUDE.md、手順は Skills、完了の判定は hook / テスト / linter です。全部を指示ファイルに書くと、モデルが要約した瞬間に非交渉ルールが抜け落ちます。

層の対応

PALO IT は、次のように対応付けています。

• CLAUDE.md を always-on guide
• Skills を条件付き guide
• Hooks を sensor

guides は書く前の誘導、sensors は完了の判定です。検証ゲートはモデルが推論で迂回できない仕組みなので、force-push の禁止やテスト省略の禁止は hook 側に置きます。かあくんの整理も同じで、CLAUDE.md を百科事典にせず、lint / test の自動実行は hook に置き、結果をモデルへ戻して修正させます。

判断基準は1行です。「守られなかったら事故になる」なら hook。「守った方がきれい」なら CLAUDE.md。

層	役割	強制力	向くもの
CLAUDE.md / プロンプト	ガイド	モデル任せ	文体、優先順位、説明の粒度
権限ルール	フィードフォワード	ランタイム強制	読取 / 編集 / コマンドの許可範囲
Hooks	センサー / ゲート	毎回実行	lint、保護パス、破壊コマンド、出荷前テスト

出典：Hooks reference、Configure permissions、PALO IT（2026年8月時点）

---

最初の1週間で入れるチェックリスト

全部を hook にすると、遅い検査と誤検知で開発が止まります。最初の1週間は、非交渉のものだけを機械化します。

• ✓ deny / ask で破壊的 git・削除・秘密ファイルを先に閉じる
• ✓ PreToolUse で保護パスと危険 Bash を exit 2 にする
• ✓ PostToolUse で Edit / Write 後の lint / format を返す
• ✓ Stop hook または CI で test / build を出荷条件にする
• ✓ .claude/settings.json を共有し、個人例外は settings.local.json に置く
• ✓ managed hook と disableAllHooks の上書き関係を確認する
• ✓ 未レビュー clone では --bare または hooks off で起動する

次にやることは、1本ずつ追加していくことです。

1. /permissions を見る
2. deny / ask を1件追加する
3. PreToolUse を1本入れる
4. PostToolUse lint を1本入れる
5. Stop か CI の出荷ゲートを決める

最初から agent hook や HTTP hook を増やしません。

---

よくある質問

CLAUDE.md に「必ず lint」と書けば十分ですか

十分ではありません。公式は指示と許可を分け、必須実行は hook 側です。独立ソースも、プロンプトは保証せず hook が実行を保証すると対比しています。

---

bypassPermissions なら hook も無効ですか

無効ではありません。PreToolUse の deny / exit 2 は bypass でもブロックします。逆に hook の allow は、settings の deny / ask を緩めません。

---

exit 1 で危険コマンドを止められますか

多くのイベントでは止められません。コード単独のブロックは exit 2 です。exit 1 は、有効 JSON がなければ非ブロックエラーです。

---

hook はどこに置きますか

チーム共有は .claude/settings.json、個人は .claude/settings.local.json、全マシンは ~/.claude/settings.json、組織は managed policy です。plugin の hooks/hooks.json と skill / agent フロントマターにも置けます。

---

PostToolUse で危険操作を取り消せますか

取り消せません。阻止は PreToolUse です。Post は事後の lint やフィードバック向きです。

---

関連記事:

• CLAUDE.md設計パターン｜個人・チーム・モノレポで使い分ける構成と肥大化対策
• Claude CodeとCodexの設定同期｜CLAUDE.mdとAGENTS.mdのズレを防ぐ
• Claude Code利用分析の選び方｜公式Analyticsとローカル分析

まとめ

権限でできることを先に閉じ、残った非交渉ルールだけ hook にします。CLAUDE.md はガイドのまま残し、機械判定を品質ゲートにします。

今日やることは4つです。

1. /permissions を開く
2. 破壊操作を deny / ask にする
3. PreToolUse を1本入れる
4. Edit / Write 後の lint を PostToolUse に置く

出荷ゲートは Stop か既存 CI の、通らなければ出さない側へ寄せます。