第4章 フックと権限 — 破りようがない強制力

CLAUDE.md(第1章)は「読んでもらう約束」でした。lint と CI(第2章)は「コードに対する機械チェック」でした。この章のフック(hooks)と権限(permissions)は、AI の行動そのものに効く仕掛けです。

公式ドキュメントはこう区別しています — CLAUDE.md の指示は助言(advisory)、フックは決定的(deterministic)。つまり、CLAUDE.md は忘れられたり解釈がぶれたりする可能性が残りますが、フックは条件を満たせば必ず実行されます。「毎回・例外なく・絶対に」が必要なルールの置き場所です。

どちらも .claude/settings.json に書きます(プロジェクトに置けばチームで共有、settings.local.json なら自分だけ)。

フック — AIの行動に自動処理を割り込ませる

フックは「Claude Code が特定の行動をした瞬間に、決めておいたスクリプトを自動実行する」しくみです。代表的なタイミング:

タイミング いつ動く 使いどころ
PreToolUse AI がツール(コマンド実行・ファイル編集など)を使う直前 危険な操作のブロック、事前チェック
PostToolUse ツールを使った直後 編集のたびに lint / 整形を自動実行
Stop AI が作業を終えて手を止めるとき 「テストが通るまで終わらせない」ゲート

実例: コミット前に全チェックを強制する

MulmoClaude で実際に使われている設定(実物)です。AI が git commit を実行しようとすると、その前に整形チェック・lint・型チェック・ビルド・テストが自動で走り、1つでも失敗するとコミット自体がブロックされます。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "if": "Bash(git commit *)",
            "command": "yarn format --check && yarn lint && yarn typecheck && yarn build && yarn test",
            "timeout": 300,
            "statusMessage": "Pre-commit checks (format/lint/typecheck/build/test)..."
          }
        ]
      }
    ]
  }
}

なぜこれが効くのか:

  • CLAUDE.md に「コミット前にテストを回すこと」と書いても、AI がうっかり飛ばす可能性はゼロではありません。フックなら物理的に忘れられない
  • 壊れたコードがコミット履歴に入らないので、「どこから壊れたか」を探す時間が消える
  • 人間が手でコミットするときの pre-commit フック(husky など)の、Claude Code 版だと思えばOKです

ほかの使い道

  • 「ファイルを編集するたびに、そのファイルだけ ESLint を走らせる」(第2章の lint を、コミット時よりさらに手前で効かせる)
  • 「migrations/ フォルダへの書き込みを常にブロックする」(触ってはいけない聖域を守る)

💡 フックの設定は Claude Code 自身に頼んで書かせるのが早いです: 「ファイル編集のたびに eslint を実行するフックを書いて」。設定の確認は /hooks コマンドでできます。

権限 — AIができる操作の範囲を絞る

Claude Code は標準では、システムを変更しうる操作(ファイル書き込み、コマンド実行など)のたびに人間へ確認を求めます。安全ですが、毎回「許可」をクリックするのは大変です — そして確認疲れで何も読まずに許可し続けるようになったら、確認の意味がありません。

そこで、安全と分かっている操作だけを事前許可します:

{
  "permissions": {
    "allow": [
      "Bash(yarn test)",
      "Bash(yarn test *)",
      "Bash(yarn lint)",
      "Bash(yarn typecheck)"
    ]
  }
}

これで AI はテスト・lint・型チェックをテンポよく回せるようになり、危険になりうる操作(削除、push、インストールなど)は引き続き人間の確認が挟まります。

考え方は最小権限の原則です:

  • 「全部許可」にしない。権限は狭いほど、事故ったときの被害範囲(blast radius)が小さい
  • 読み取り専用・何度実行しても害がない操作から許可していく
  • 「これも毎回許可を求められて面倒だな」と感じたものを、1つずつ吟味して追加する

使い分けまとめ — 約束・チェック・強制

ここまでの部品の関係を整理します。

手段 性質 向いているルール
CLAUDE.md(第1章) 約束(助言。破られることもある) 行動・手順・判断が要るルール
lint / 型 / テスト / CI(第2章) コードのチェック(コードに対して機械的) 機械で判定できるコードのルール
フック・権限(この章) 行動の強制(破りようがない) 「毎回・例外なく」が必要な操作ルール

新しいルールを思いついたら、下の段に置けるものほど下に置く(強制できるものは強制する)のが基本方針です。CLAUDE.md に書いたルールが繰り返し破られるようなら、それはフックか lint に「格上げしろ」というサインです。

合わせて読む