Claude Codeのフック（hooks）の使い方｜2つの実例と落とし穴【2026年版】
目次
Claude Codeに「これだけはしないで」と伝えても、たまに破られます。CLAUDE.mdに書いた、手順書にも書いた、それでも起きる。原因はAIの性格ではなく、文章で頼むという方式そのものの限界です。AIはその場の状況やツールの出力に引っ張られて、書かれたルールより目の前の指示を優先することがあります。
そこで出番になるのがフック（hooks）です。フックは、AIが「やるかどうか」を判断する前に、決まった時点で必ず動く処理です。当社は営業・マーケの定型業務をClaude Codeで回していて、フックは2本だけ入れています。実行の前に止める1本と、作業の終わりに残す1本です。
この記事は、その2本を34日間運用した記録です。入れて効いたこと、入れても黙って止まったこと、そして「全部フックにすれば安心では？」への答えまで書きます。
この記事の要点
- フックは「頼む」仕組みではなく「必ず起きる」仕組み。破られたら実害が出る操作だけに使う
- 当社のフックは2本。実行前に止める（ブラウザの切り替えと、選ばせる質問）と、作業終了時に変更を残す（自動コミット）
- 自動コミットは9月14日〜10月17日の34日で418回動き、757回は「他の作業が触っている途中かもしれない」ファイルを次回に回した
- フックも黙って止まる。当社は約10時間・59回連続で自動コミットが失敗し、ログに残るだけで誰も気づかなかった
- 最初の1本は「実害が出たことがある禁止」から。予防のために増やすと、速度が落ちるうえ、どれが効いているか分からなくなる
フックとは｜AIの判断を通らずに決まった時点で動く処理
フックは、Claude Codeの動きの決まった時点に、こちらが用意した処理を差し込む仕組みです。 AIに「確認してね」と頼むのではなく、その時点が来たら処理そのものが走ります。AIが忘れても、読み飛ばしても、関係ありません。
設定は設定ファイル（settings.json）に書きます。全プロジェクト共通の設定、プロジェクト単位の設定、個人用の設定の3つの置き場所があり、「どの時点で」「どのツールのときに」「何を実行するか」の3つを指定します。主な時点は次のとおりです（仕様の正本はAnthropicの公式ドキュメント［Hooks reference］https://docs.claude.com/en/docs/claude-code/hooks ）。
| 時点 | いつ動くか | 向いている使い方 |
|---|---|---|
| ツール実行の前 | AIがツールを呼ぶ直前 | 禁止操作を止める・危ない引数を弾く |
| ツール実行の後 | ツールが終わった直後 | 書き換えたファイルの整形・検査 |
| 指示を受けたとき | 人が入力を送った直後 | 前提情報（日付など）の差し込み |
| 作業を終えるとき | AIが応答を終える直前 | 変更の保存・後片付け |
| 開始時 | 会話を始めたとき | 環境の確認 |
止める仕組みはシンプルです。ツール実行の前のフックが「止める」の合図を返すと、その操作は実行されず、フックが書いたメッセージがAIに返ります。 AIはそのメッセージを読んで、別のやり方に切り替えます。だからメッセージには「何がだめか」だけでなく「代わりに何をすればいいか」まで書くのがコツです。
CLAUDE.md・手順書・フックの分担｜「頼む」と「必ず起きる」
3つは置き換えではなく、役割分担です。 当社で落ち着いた分け方はこうです。
| 仕組み | 性質 | 向いているもの |
|---|---|---|
| CLAUDE.md | 頼む（判断の基準を渡す） | 言葉選び、保存場所の伝え方、なぜそうするかの理由 |
| 手順書・スキル | 頼む（順番を渡す） | 記事の公開、商談前のリサーチなど決まった流れ |
| フック | 必ず起きる | 破られると人の作業や顧客に実害が出る禁止、取りこぼすと困る後片付け |
ここで大事なのは、フックに移したルールもCLAUDE.mdから消さないことです。CLAUDE.mdに「なぜ止めているか」が書いてあれば、AIはフックに止められる前に自分で避けますし、止められたときも正しい代わりの手を選べます。CLAUDE.md側の書き方はClaude CodeのCLAUDE.md書き方｜3つの置き場所と、書いても守られないものにまとめています。
実例1：実行の前に止める｜ブラウザの切り替えと「選ばせる質問」
1本目は、2026年9月12日に入れた「実行前に止める」フックです。 対象は2つの操作だけです。
1つ目は、ブラウザ操作の切り替え。当社はブラウザを複数のアカウントで使い分けていて、Claude Codeから切り替えの操作を呼ぶと、開いているすべてのブラウザに接続確認の画面が出ます。代表が仕事でブラウザを使っている最中にこれが出ると、その場で手が止まります。
2つ目は、「どのブラウザを使いますか」とこちらに選ばせる質問です。CLAUDE.mdには「名前で1回で決める。選ばせる質問はしない」と書いていました。それでも、ブラウザの一覧を返すツールの出力に「全部並べてユーザーに選ばせてください」という一文が混ざっていると、AIはそちらに従って質問してしまう。書いたルールより、目の前のツール出力が勝ったわけです。
フックの作りは2段構えです。
- 設定ファイル側で、ツール名で絞る。 対象の2つのツールのときだけフックが呼ばれる。他の操作には一切かからないので、全体の速度は落ちない
- フックの中で、中身を見て判定する。 質問のツールでも、ブラウザの選択に関係する質問だけを止める。関係ない確認まで止めると、必要な質問ができなくなる
止めたときに返すメッセージには、正しい手順を1行で書きました。「名前から識別子を引いて、選択は1回だけ。つながっていなければ何もせず止まって報告する」。止めるだけだとAIは別の抜け道を探しにいきますが、代わりの手を渡すと素直にそちらへ行きます。
実例2：作業の終わりに残す｜34日で418回動いた自動コミット
2本目は、9月14日に入れた「作業の終わりに変更を残す」フックです。 作業を終えるたびに、残った変更を自動でコミットし、GitHubへ送るところまで行います。
きっかけは、変更のコミット忘れが続いたことです。AIに「最後にコミットして」と頼むとだいたいはやりますが、長い作業の最後やエラーが出た日には抜けます。
運用して分かった難しさは、同時に動いている別の作業を巻き込むことでした。当社は定時で動くタスクと、人と対話しながらの作業が同じフォルダで並行して動きます。終わった作業が「残っている変更を全部コミット」すると、隣でまだ編集途中のファイルまで半端な状態で確定させてしまう。
そこで、コミットの対象を分けました。
| ファイルの種類 | 扱い | 理由 |
|---|---|---|
| この作業（と、その作業が呼んだ下請けのAI）が編集したファイル | すぐにコミット | 作業の記録から誰が触ったか確実に分かる |
| それ以外 | 5分以上触られていないものだけコミット | 他の作業の編集途中を巻き込まない |
| GitHub側の変更と同じファイル | 中止して手元を残し、通知を出す | 機械が勝手に混ぜると、どちらかの変更が消える |
実績は、9月14日から10月17日までの34日間で、作業終了時のコミットが418回。そのうち、「他の作業が触っている途中かもしれない」として次回に回したことが757回ありました。この757回が、巻き込み事故を起こさずに済んだ回数の上限です。
1つ、作ってから気づいた限界があります。フックが「この作業が編集した」と判定できるのは、ファイル編集のツールを通した変更だけです。コマンドで書き換えたファイルは記録に残らないので、「他の作業の変更」として5分待ちに回ります。ここはフックでは埋められないので、コマンドで書き換えたものは自分でコミットする、とCLAUDE.mdに書いて補っています。
「全部フックにすれば安心では？」への答え
おすすめしません。 文章のルールが破られた経験があると、何でもフックで縛りたくなります。当社も一度そう考えましたが、増やすと3つ困ることが出ます。
- 遅くなる。 フックは対象の時点が来るたびに必ず走ります。対象を広く取るほど、すべての操作に待ち時間が乗る
- AIが必要な判断までできなくなる。 「この質問は止める」を広く書くと、本当に聞くべき確認まで止まる。実例1で中身を見て絞ったのはこのためです
- どれが効いているか分からなくなる。 止められたとき、どのフックのどの条件で止まったかを追う手間が、フックの数だけ増える
当社の線引きは、「実際に破られて、人の作業か顧客に実害が出たことがある禁止」だけをフックにするです。予防のためのフックは入れません。顧客へのメールの二重送信や、同じ投稿の二重公開のように、業務の手順の中で確認すべきものは、フックではなくその業務の処理の中にチェックを置いています（設計の考え方はClaude Codeは危険か｜実際に起きた4つの事故と、機械で止める設計）。フックは「Claude Codeそのものの操作」に効く仕組みなので、業務ごとのルールを全部ここに集めると、かえって見通しが悪くなります。
フックも黙って止まる｜10時間・59回の失敗から決めたこと
フックを入れたら安心、ではありません。 当社では、フックと同じ処理を10分ごとに回している定時の自動コミットが、10月1日の夕方から翌朝4時半すぎまで、約10時間・59回連続で失敗していました。原因は、コミット対象に「もう管理されていないファイル」が1件混ざり、そのたびにコミット全体が弾かれていたことです。
問題は失敗そのものより、誰も気づかなかったことです。この仕組みは「失敗しても本体の作業を止めない」ように作っていて、通知を出すのは「人が判断しないと直らない失敗」（GitHub側との衝突など）だけでした。コミットの失敗は記録ファイルに書かれるだけ。止まらない作りにした結果、止まっていることも見えなくなっていたわけです。
もう1つ、作ってから分かったことがあります。フックは設定ファイル単位でしか効きません。 当社は人と対話する作業と定時のタスクで別の設定を使っていて、作業終了時のフックは前者にしか入れていません。定時タスクの変更は、10分ごとの別の仕組みで拾う形にしています。「フックを入れた」と思っていても、別の設定で起動したAIには効いていないことがあります。
さらに、全プロジェクト共通の設定に入れたフックは、git管理していないフォルダで作業を終えたときにも呼ばれます。当社の記録では、そうした「対象外なので何もしない」行が951行たまっていました。害はありませんが、本当の失敗が埋もれます。
ここから決めたことは3つです。
- フックの記録は、週に1回「失敗の行だけ」を数える。 成功と対象外の行は数えない
- 同じ失敗が続いたら知らせる。 1回の失敗は流してよいが、連続は止まっているのと同じ
- どの設定にどのフックが入っているかを1か所に書いておく。 「入れたつもり」を防ぐ
最初の1本の入れ方｜実害が出た禁止から
最初の1本は、「CLAUDE.mdに書いたのに破られて、困ったこと」から選びます。 頭で考えた予防策ではなく、実際に起きたことです。
- 実害が出た禁止を1つだけ選ぶ。 「人の作業が止まった」「消えた」「外に出た」のどれかが起きたもの
- ツール名で対象を絞る。 すべての操作にかけない。対象のツールのときだけ呼ばれるようにする
- 止めるときは、代わりの手を1行で返す。 「だめ」だけだと、AIは別の抜け道を探す
- 記録を週に1回だけ見る。 止めた回数と失敗した回数を数え、効いているか・黙って止まっていないかを確かめる
2本目を足すのは、1本目が効いていると確認できてからで十分です。当社は34日たった今も2本のままですが、その2本で「人の作業が止まる」「変更が消える」の2つはほぼ起きなくなりました。浮いたのは時間というより、作業の途中で割り込まれず、商談の準備や顧客対応に集中できる時間です。
よくある質問
Q. Claude Codeのフックとは何ですか？
Claude Codeの動きの決まった時点（ツールを実行する前、実行した後、作業を終えるときなど）に、こちらが用意した処理を必ず走らせる仕組みです。AIに頼むのではなく、時点が来れば処理そのものが動くので、AIが忘れたり読み飛ばしたりしても効きます。設定ファイルに「どの時点で・どのツールのときに・何を実行するか」を書いて使います。
Q. CLAUDE.mdとフックはどう使い分ければいいですか？
判断の基準や理由はCLAUDE.md、破られると実害が出る禁止や取りこぼすと困る後片付けはフック、と分けます。フックに移したルールも、CLAUDE.mdには「なぜ止めているか」を残しておくと、AIが止められる前に自分で避けるようになります。
Q. フックで操作を止めると、AIはどうなりますか？
その操作は実行されず、フックが返したメッセージがAIに渡ります。AIはそれを読んで別の方法を探すので、メッセージには「何がだめか」に加えて「代わりにどうするか」を1行で書いておくのが効果的です。代わりの手がないと、別の抜け道を試そうとします。
Q. 作業の終わりに自動でコミットするフックは危なくないですか？
同時に別の作業が動いていなければ問題になりにくいですが、並行して動く場合は、他の作業の編集途中まで確定させてしまう危険があります。当社は「その作業が編集したファイルはすぐ」「それ以外は5分以上触られていないものだけ」「GitHub側と同じファイルが変わっていたら中止して知らせる」の3つに分けて運用しています。
Q. エンジニアでなくてもフックは設定できますか？
できます。設定ファイルへの記述と、短い判定の処理を用意するだけなので、Claude Code自身に「この操作を止めるフックを作って」と頼めば形になります。ただし、作ったあとに本当に止まるか・関係ない操作まで止めていないかを、わざと対象の操作をさせて一度確かめてください。当社も最初は確認してから運用に入れています。
---
執筆・監修：佐々木 優希（AIリモートワーカー代表／上場企業 営業統括 兼 AI責任者）
自社の営業・マーケ業務をClaude Codeで運用しており、本記事の回数・日付・失敗の記録はすべて自社の運用記録（自動コミットの記録ファイル・設定ファイル）に基づいています。