5. Hooks と自動化 — 運営者が忘れたときにシステムが覚えていること

これは Alice Way シリーズの第5回だ。第4回 Skills and slash commands では、繰り返しの意図操作を一行の名前に凝縮した。この投稿は、もう半分について — 運営者が名前を呼び出さなくても手順を発火させることについて書く。

0. Hook は忘れやすい意図をシステムに外注する

運営者は忘れる。昨日の決定、新しいセッションを開く直前の状態、「完了」を報告する直前に走るはずだった検証 — 一日に一度は簡単に。

Skill はこの忘れの一部をブロックする — 名前を呼べば手順が走る。しかしその呼び出し自体が忘れられれば、Skill は発火しない。一言の名前でさえ浮かばない瞬間がある。

Hook はその瞬間をカバーする。運営者の意識に依存せず、特定のイベントに対してシステムが自動的に手順を発火させる。 それは運営者の意図の一部をシステムに委ねる行為だ。

委ねる価値があるものには制約がある。「忘れてはいけないが忘れやすい」「条件が自動判断できるほど明確」「発火の瞬間がイベントに固定できる」。この投稿は、その委任の基準と実際の Hook の記録だ。

Hook の仕組み自体は Anthropic Claude Code の hooks システムから借用している。この投稿はその仕組みをどのように活用するかの記録であり、発明ではない。

1. 意識が飛ぶ瞬間がある

運営者が最もよく忘れるのは、手順が難しいからではない。その手順が、注意が別のところにある瞬間に割り込まなければならないからだ。

これらのすべてで、運営者の意図は他のところにある。「忘れるな」という原則はこれを防げない。システムレベルで発火しなければならない。

Hook が発火の装置だ。意識が飛んだ瞬間に割り込んで、手順を強制する。

2. Skill と Hook の境界

この二つは混同されやすい。核心的な違いは一点 — 誰が呼ぶかだ。

Skill は「これをやれ」という運営者の決断が必要だ。Hook はそれなしに発火する。だから Hook の最大の価値は — 運営者が決断しなかった瞬間でも手順が保証されること。

同じ手順を両方の形で公開することもできる。/verify は直接 slash command として呼び出せるし、「完了」報告の直前に Hook として自動発火もできる。運営者の意識的な呼び出し = Skill、システムの自動発火 = Hook — 同じ手順への二つの入口。

3. 格上げ基準 — どの手順が Hook になるか

すべての手順が Hook になるべきではない。以下の5つすべてをパスしたものだけが自動発火の権利を得る。

3.1 スキップのダメージが大きく、スキップしやすい

Hook には認知コストがある — システムが運営者の知らないうちに何かをする。そのコストを正当化するには、スキップのダメージが十分に大きくなければならない。検証なしのプッシュ、メモリ同期なしで始まるセッション — これらは損失がすぐ現れる。Hook の領域だ。

利便性レベルの手順は Hook ではなく Skill に留まる。

3.2 発火条件が明確なイベント

Hook は特定のイベントに紐づく。「セッション開始」「tool use 前」「出力送信前」「セッション終了」— そういったもの。イベントが曖昧 — 「いい感じのとき」— なら Hook にならない。

3.3 判断が自動で下せる

Hook が発火したら、何をすべきかが自動的に判断できなければならない。「変更がリントを通れば OK、通らなければブロック」— 明確な分岐。追加の運営者判断が必要な手順は、Hook ではなく Skill 呼び出しを通す。

3.4 失敗が安全

Hook が失敗しても、システム全体が壊れてはならない。Hook は運営者の意識の外で動くため、失敗はすぐに気づかれない。だから失敗の影響は分離されていなければならない。

3.5 出力がシグナル

Hook の結果は運営者に一行として届く。「OK」「ブロック」「警告」のような明確なシグナル。長い出力や曖昧な出力は、Hook を運営者の視野のノイズにする。

4. 実際のローテーションの Hook

毎日頼っている Hook の一部。

4.1 SessionStart — セッション開始時

セッションが始まった瞬間、メモリ同期状態を一行で出力する。「Memory sync: current」または「Memory sync: 5 min old — refresh needed.」運営者はその一行を読んで即座に判断する。

この Hook がなければ — 運営者は毎回意識的に「メモリは最新か」を確認しなければならない。意識が他のことに向いているとき、確認は忘れられて作業がそのまま始まる。そして古い状態のまま決定が下される。

4.2 PreToolUse — 危険なコマンドの直前

rm -rf、強制プッシュ、破壊的な SQL などの特定コマンドの直前に発火する。ユーザー確認を求めるか、ポリシー違反でブロックする。

この Hook の価値は — 「本当にこれを意図しているか」と立ち止まらせる瞬間をシステムが強制することだ。高速に流れる実行を一瞬断ち切るのが目的だ。

4.3 PreToolUse → /verify の自動発火

「完了」報告の直前にリント・ビルド・テストを自動実行する Hook。運営者が「終わった」と書こうとした瞬間に、システムが割り込んで検証を強制する。失敗すれば報告はブロックされる。

運営者の安堵の瞬間（「これで終わりだ」）が最も危険だ。Hook はその安堵に一拍置かせる。

4.4 Stop — セッション終了時

セッションが終わろうとした瞬間、作業ログが更新されているか、HANDOFF に次セッションが必要な情報が含まれているかを確認する。何かが欠けていれば運営者にアラートする。

この Hook がなければ — 運営者は「完了」状態でそのまま閉じる。次のセッションは失われたコンテキストの上で始まる。

4.5 積み重なった効果

これらはそれぞれ単体では小さな手順だ。しかし積み重なった効果は大きい — システムが毎日5〜6個の、運営者の意識が飛ぶ瞬間を埋める。運営者の意図は決断だけに集中でき、「絶対に省いてはいけない手順」はシステムが保持する。

5. 設計原則

Hook 設計で収束したもの。

5.1 短く、速く

Hook は運営者のフローを断ち切る。短くなければフローが壊れる。1秒を超える Hook は非同期で実行するか、明確な進行状況を表示する。運営者が「なぜ止まっているんだ」と思い始めたら、Hook の価値はマイナスになる。

5.2 出力は一行

Hook が終わったとき、運営者が見るのは一行。詳細ログは別ファイルへ。「Memory sync: current」「Verification passed: 3 tests OK」「Blocked: 2 lint errors」— その形。

5.3 失敗を分離する

Hook の失敗は本作業を壊してはならない。メモリ同期が失敗しても、セッションは（警告とともに）始まる。検証 Hook が失敗しても、報告はブロックするが作業は生き続ける。

5.4 バイパス可能

ときに運営者が意図的に Hook をスキップしたい場合がある — デバッグや緊急の作業など。明示的なバイパスオプションが存在しなければならない。バイパスはログに記録されるが、ブロックはされない。

5.5 べき等性

同じイベントが二度発火しても同じ結果になるか、少なくとも壊れないこと。Hook は自動発火するので、イベントの重複配信は避けられない。

6. Hook にしないもの — 落とし穴

格上げ基準の裏面。

6.1 運営者の判断を置き換える

「このように見えるコードを自動修正する」Hook は危険だ。自動修正はしばしば意図と異なる方向に進む。Hook は通知とブロックまでにする。自動修正は運営者が Skill を呼び出したときに行う。

6.2 頻繁に発火しすぎる

キーストロークごと、ファイル保存ごとに発火する Hook はノイズになる。イベントの自然な頻度は少なくとも分単位であるべきだ。秒以下の発火は運営者のフローを壊す。

6.3 長い出力

一つの Hook が 30 行のログを発火させると、本作業の出力が埋まる。長い情報はファイルへ。コンソールにはシグナルの一行だけ。

6.4 本作業を壊す失敗

Hook の失敗が本作業の破壊につながれば、運営者は Hook をオフにする。一度オフになると、永遠にオフのままだ。だから失敗の分離は譲れない。

7. Skill と Hook の組み合わせ

第4回 — Skills §5 のネットワーク効果は、Hook が加わることでもう一段階拡張する。

同じ手順を両方の形で公開する：

このように対にすることで — 運営者が意識しているときは Skill、意識が飛んでいるときは Hook — 同じ手順がどちらの場合も保証される。判断権限は運営者に残り、安全網はシステムが持つ。

ダウンロード — settings.json サンプル

この投稿で紹介したフック構成（SessionStart / UserPromptSubmit / PreToolUse / PostToolUse）と許可・拒否リストを一つのファイルにまとめたもの。<project-root> を自分のプロジェクトに合わせて書き換える。

shasum -a 256 settings.json
# expected: 60b5bf7fec33f92d9ddcc6ab4696747df6bb3dab14e8287b696d45fbd6c1abde

8. 一つの原則に圧縮する

Hook 設計の核心は一文に圧縮できる。

「運営者が忘れやすい手順だけをシステムが自動発火させる。それ以外はすべて運営者が呼び出す Skill として残す。」

これが成立するとき、Hook は運営者の意図の負荷を軽減する安全装置になる。壊れるとき、Hook は運営者の意図を横取りするノイズになる。

次の投稿では、一つのエージェントがすべてをやるのではない構造 — Multi-Agent 委任、すなわち何を他の協働者に渡して何を自分でやるか — を扱う。