Hooks（フック）　お願いではなく強制する

一行でいうと

特定のタイミングで、Claudeの判断に関係なく必ず実行される処理です。ツールを使う前後、会話の開始時、終了時などに割り込ませます。

お願いは消えることがありますが、Hooksのゲートは必ず通ります。

CLAUDE.mdとの決定的な違い

CLAUDE.mdは「お願い」、hooksは「強制」です。ここが本レッスンの核心です。

公式ドキュメントは、CLAUDE.mdや自動メモリについてこう書いています。

Claude treats CLAUDE.md files and auto memory as context, not enforced configuration. （ClaudeはCLAUDE.mdや自動メモリを、強制される設定ではなく、文脈として扱う）

つまり、CLAUDE.mdに何を書いても、それはお願いです。読んでくれるし、たいてい守ってくれる。でも「必ず」ではない。hooksは違います。Claudeが何を考えていようと実行されます。

破られて困るルールは、CLAUDE.mdではなくhooksに書く。これが実務上の鉄則です。

どこに割り込ませられるか

主なタイミングを挙げます。

PreToolUseで止められるのが強力です。危険なコマンドを実行しようとした瞬間に、仕組みとして遮断できます。

下の3つは、あとから加わったイベントです。ConfigChangeはsettingsやSkillsのファイルが変更された瞬間に発火し、変更の監査ログに使えます。CwdChangedはClaudeが作業ディレクトリを移動した瞬間に発火し、direnvのようなディレクトリ依存の環境変数を読み直すのに向きます。FileChangedは監視対象ファイルの変更で発火しますが、matcherに書くのはファイル名の正規表現ではなく、そのままの文字列一致です。正規表現のつもりで書くと、狙ったファイルで発火しません。

実際の使い道

典型的な使い道はこの4つです。

削除コマンドを実行する前に止める（破壊操作のガード）
ファイルを書いた直後に、型チェックを自動で走らせる
特定フォルダへの書き込みを、常にブロックする
会話の終わりに、その日の作業ログを自動保存する

2つ目が「検証ループ」の自動化そのものです。書いたら必ず検査が走る状態にしておけば、確かめる手間が仕組みに置き換わります。

ここまでの例は、すべてシェルコマンドを実行するhookでした。判断が要る場面では、コマンドの代わりにAIモデルに判定させる型も選べます。

type: promptを指定すると、既定でHaikuモデルが状況を判定し、yes/noのJSONだけを返します。Stopイベントで使うと、こういう流れになります。

$
Check if all tasks are complete. If not, respond with reason.
Haikuが状況を判定し、完了していればok: true、未完了ならok:
falseとreason（残っている作業）を返す。reasonの文面がそのままClaudeへの次の指示として渡り、作業が続く。

判断はもう一段踏み込ませることもできます。type: agentを指定すると、1回のモデル呼び出しではなく、ファイルを読んだりコマンドを実行したりできるサブエージェントを生成して検証させます。既定のタイムアウトは60秒、最大ターン数は50です。ただし、ここは公式ドキュメントがはっきり線を引いている場所です。

Agent hooks are experimental... For production workflows, prefer command hooks. （agent hookは実験的な機能です。本番のワークフローでは、command hookを使うことを推奨します）

判断力の高さに惹かれて、本番の検証をagent hookに任せきりにしないこと。今のところ確実に効かせたい場面は、command hookを軸に据えるのが安全です。

よくある誤解と罠

罠1: 終了コードを間違えると止まり続ける

hooksの世界では、終了コード2がブロッキングエラーです。ここを取り違えると、意図せず全部の操作をブロックし続ける状態になります。最初は「止める」フックより「記録する」フックから始めるのが安全です。

罠2: hooksで何でも縛ろうとする

強制は確実ですが、融通が利きません。縛りすぎると、AIの良さ（想定外の経路を見つける力）が死にます。

線引きの目安はこうです。不可逆なもの・事故になるものだけhooksへ。それ以外は文脈で伝える。

罠3: CLAUDE.mdに書いたから安心だと思う

いちばん危ないのがこれです。「機密情報を書かない」のような絶対に守らせたいルールを、お願いのレイヤーだけに置いておくのは弱い。仕組みで塞げるものは塞ぐ。

罠4: hooksを入れれば効率が上がる、という期待

hooksは「破らせない」ための仕組みであって、必ずしも作業を速くする道具ではありません。Flask/Jinjaの作者であるArmin Ronacherは、実務でhooksを使い込んだ末にこう書いています。

効率が上がった実感がなくても、hooksが仕事をしていないとは限りません。破壊的な操作を止め続けている、機密情報を含むフォルダへの書き込みを塞ぎ続けている。それ自体が、hooksの本来の役割です。生産性を底上げする道具として期待すると、その期待とはずれます。

使いどころ

最も効くのは、職業上の一線を仕組みで守る場面です。

• 特定フォルダ（機密情報を扱いうる場所）への書き込みを常時ブロック
• 外部送信を伴う操作の前に、必ず確認を挟む
• 記事を書き換えたら、自動でファクトチェック用のスクリプトを走らせる
• 作業終了時に、その日の変更点を自動で記録する

1つ目が最重要です。職業上の一線は、意志ではなく仕組みで守る。指差呼称を手順に組み込むのと同じ発想です。

今日のまとめ

• hooksは、Claudeの判断に関係なく必ず走る仕組み
• CLAUDE.mdは「お願い」、hooksは「強制」。破られて困るルールはhooksへ
• 縛りすぎない。不可逆なもの・事故になるものだけを仕組みで塞ぐ

次は、その「お願い」の側の主役、CLAUDE.mdです。