Claude Codeでコードを書いてもらうと、毎回フォーマットをかけ忘れる。 自分でフォーマッタを当てるのを忘れて、そのままコミットしてしまう。 何度も同じミスを繰り返していて、正直、自分がイヤになる。
公式ドキュメントを読み直していたら、「Hooks」という機能のページがあった。
どうやらこれは、僕の代わりにClaudeが"必ずやって欲しいこと"を毎回やってくれる仕組みだ。
僕の場合、自分の記事執筆でClaude Codeにコードを書かせるのは、ならして週に2〜3回。 そのうち 半分くらいはフォーマットをかけ忘れる。つまり月換算で月4〜6回、後からフォーマッタを手で当て直している計算になる。1回につき30秒〜1分としても、月に数分〜10分程度は、雑に溶かしている。
金額にすれば知れているが、財務経理20年の僕からすると「決まった作業を毎回忘れる」こと自体がストレスだった。
僕はまだHooksを導入していない。だからこの記事は「試した」話ではなく、「公式ドキュメントで調べて、仕組みを理解した」記事だ。 Anthropic公式のAutomate workflows with hooksとHooks referenceを読んで、僕なりにまとめ直した。
そもそもHooks（フック）は何をする機能なのか
公式の定義を僕なりに要約するとこうなる。
ユーザーが事前に決めた処理を、Claude Codeのライフサイクルの特定ポイントで確定的に走らせる仕組み。
ポイントは「確定的に」という部分だ。 Claudeに「フォーマットかけといてね」とお願いする方式だと、かけ忘れることがある。 でもHooksで登録しておけば、Claudeの判断に関係なく必ず走る。
これは財務経理20年の僕にとって、かなり刺さる考え方だった。 「任意の作業」と「必ずやる作業」は分けて管理する。仕訳のチェックと同じ発想だ。
公式が挙げているイベントの種類
どのタイミングでフックが走るのかは、公式のHooks referenceに一覧表がある。 数え始めたら、ゆうに20を超えるイベントが並んでいた。正直、最初に見たときは多すぎてめまいがした。
僕が「使いそうだな」と思ったものだけ拾い出すと、こんな感じだ。
| イベント | いつ動くか |
|---|---|
SessionStart |
セッションを始めた・再開した時 |
UserPromptSubmit |
僕がプロンプトを送信した直後 |
PreToolUse |
Claudeがツールを使う直前 |
PostToolUse |
ツール使用が成功した直後 |
Notification |
Claudeが通知を送る時（入力待ちなど） |
Stop |
Claudeが応答を終えた時 |
SessionEnd |
セッションが終了する時 |
全部使う必要はない。
まずは PostToolUse（ツール使用の後）と Notification（通知時）の2つだけで、十分に仕事は変わる。
公式が一番最初に例示しているのは「通知」だった
ドキュメントの冒頭のチュートリアルで、公式がいちばん最初に作らせるのが 通知フック だ。 ClaudeがユーザーのOKを待っているときに、デスクトップ通知を出す、というもの。
設定ファイル（~/.claude/settings.json）に、どのイベントで・何を・どう表示するか を書いておくだけ。
具体的な書き方は公式ドキュメントのチュートリアルにそのまま載っている。中身を自分で確認してから自分の設定に反映する、という順番を守ればOKだ。
これだけで、Claudeが入力待ちになった瞬間にMacの通知センターからお知らせが飛んでくる。
僕のように、ながら作業でClaudeを回している人間にとっては、地味に効く。 「気づいたらClaudeが30分止まってた」を防げるのは大きい。 仮に1回あたり15〜30分の気づき遅れが1日2回あるとして、月20営業日で月10〜20時間相当の機会損失——あくまで上限寄りの仮試算だが、時給2,000円換算で月2〜4万円分の可能性があると考えると、通知フックの価値が見えてくる。実態は自分の作業スタイルによるので、まず1週間、気づき遅れの時間を雑に測ってから判断するのが一番安全だ。
次に公式が例示するのが「自動フォーマット」
僕がいちばんやりたかったやつが、ちゃんと2番目の例として載っていた。
仕組みはこうだ。
- タイミング：
PostToolUse（ツール使用後） - 対象：
EditかWrite（ファイル編集系のツール）が使われたとき - 動作：編集対象のファイルにフォーマッタを自動で当てる
これが動き出せば、僕のようにフォーマットのかけ忘れで悩んでいた人間は、仕組みの側で解決される設計だ。
matcherというフィールドで どのツールの時に動くか を絞り込めるのがいい。
全ツールで動かすと、Read（ファイルを読んだだけ）の時にもフォーマットが走って無駄になる。
編集系だけにスコープを絞れる。
設定ファイルをどこに置くかで、効く範囲が変わる
ここは経理的に、いちばん面白かった。 公式の表を引くとこうなっている。
| 場所 | 効く範囲 | チームで共有できるか |
|---|---|---|
~/.claude/settings.json |
自分の全プロジェクト | 共有できない（自分のマシンだけ） |
.claude/settings.json |
そのプロジェクト | 共有できる（リポジトリにコミット可能） |
.claude/settings.local.json |
そのプロジェクト | 共有できない（gitignoreされる） |
（Automate workflows with hooks「Configure hook location」より）
通知みたいに"僕個人の都合" は、~/.claude/settings.json（ユーザー設定）に書く。
プロジェクトのルール（フォーマットを揃える等） は、.claude/settings.json（プロジェクト設定）に書いてリポジトリに入れる。
自分のマシンでだけ試したい実験 は、.claude/settings.local.json に書いてgitignoreに任せる。
この3階層は、うちの会社の「共通マスタ／個別設定／個人メモ」の発想と全く同じだった。 設計した人、たぶん経理の人の気持ちが分かる人だと思う。
僕が一番気をつけたいと思った点
Hooksは便利だけど、自分のマシンで処理を走らせる機能だ。 設定した内容がそのまま自動で動くので、「何を仕込むか」は自分で責任を持って選ぶ必要がある。
公式のHooks referenceには、組織管理者側でフックの使用範囲を制限できる設定も用意されている、という記述がある。それだけ「仕込むものは慎重に選んでください」という前提が公式にも強くある、ということだ。
僕のマイルールはこうしておく。
- 他人の設定をコピペするときは、何をする設定なのかを必ず自分で理解してから入れる
- 影響範囲が大きそうな処理は、最初は入れない
- 最初は
~/.claude/settings.json（個人）だけで小さく試し、慣れてからプロジェクトに広げる
「確定的に走る仕組み」だからこそ、最初に仕込んだものが毎回走る。 ここを甘く見ないほうがいい、というのが公式からのメッセージだと受け取った。
まとめ：Hooksは「Claudeに忘れない仕事をさせる」ための仕組み
- Hooksは、Claude Codeのライフサイクルの特定タイミングで、ユーザーが事前に決めた処理を自動実行する仕組み
- 公式が最初の例として挙げているのは通知と自動フォーマットの2つ
- 設定は3階層（ユーザー／プロジェクト／ローカル）で、効く範囲を分けられる
- 自分のマシンで動く以上、仕込む内容は毎回自分で理解してから
僕が最初に入れるのは、公式チュートリアルのままの 通知フック にする。 それで一ヶ月まわしてみて、「自動フォーマット」を次に入れる。
大事なのは一度に詰め込みすぎないこと。 フック一つ入れて、挙動を確かめて、次を入れる。 この順番を飛ばすから、ツールが壊れた時にどこから壊れたか分からなくなる。
経理の仕組み作りと、全く同じ話だ。
今日の5分アクション：最初の通知フックを入れてみる
ここまで読んだら、あとは公式チュートリアルの順番通りに動くだけでいい。 所要時間5分で、最初の1個が入る。
- エディタで
~/.claude/settings.jsonを開く（なければ新規作成） - 公式ドキュメントの 通知フックのサンプル を中身を読んで納得してから自分の
settings.jsonに反映 - Claude Codeを起動（すでに起動中なら再起動）
/hooksと打って、Notificationフックが一覧に出ることを確認- わざとClaudeに「ファイル作って」など、承認ダイアログが出るお願いをして、通知が鳴れば成功
もしmacOSで通知が鳴らない場合は、通知権限の設定を見直す必要がある。 公式ドキュメントに システム設定 > 通知 側で許可を入れる手順が載っている(Automate workflows with hooks)。ここで詰まった人は、そちらを参照。
出典（すべて�nthropic公式）
コメント