- Claude Code にユーザー定義のフック機能が導入され、LLM の選択に依存せず、アプリの動作をより正確かつ反復的に制御できる
- 通知のカスタマイズ、コードの自動フォーマット、コマンドログの追跡など、さまざまな自動化が可能
- コマンド実行の前後、通知発生時、応答完了時などで動作し、設定ファイルを通じてプロジェクト・ユーザー・エンタープライズレベルで管理できる
- 設定ファイルの構造と matcher 方式により、特定のツール呼び出し時点に特定のフックだけを実行できる
- 入力は JSON フォーマットで渡され、出力は exit code または JSON で結果やフィードバックを制御する
- フックはシェルコマンドをユーザーのフル権限で自動実行するため、セキュリティと安全性への注意が必要
紹介
- Claude Code のフック(hook)は、コード実行ライフサイクルの各段階で自動実行されるカスタムシェルコマンド
- これにより、LLM が任意に実行するのではなく、毎回一貫した自動化が可能になる
-
主な活用例
- 通知: 入力待ち時にユーザーへカスタム通知を提供
- 自動フォーマット: ファイル編集後に
prettier または gofmt を自動実行
- ロギング: 実行されたコマンドを記録・集計し、追跡やデバッグに活用
- フィードバック: コードベースのルールに合わないコード生成時に自動でフィードバックを提供
- カスタム権限: 機密ディレクトリや本番ファイルへの変更をブロック
- プロンプトではなくシステムコードとして動作するため、毎回決定的に実行される → 自動化の信頼性が向上
- フックはユーザーのフル権限でシェルコマンドを直接実行するため、安全性の検証が必要。
設定例
- 例: Claude が Bash コマンドを実行する前に毎回ログを残すようフックを登録
1. /hooks コマンドでフック設定メニューに入り、PreToolUse イベントを選択
2. Bash matcher を追加(Bash コマンドにのみ適用)
3. フックコマンドを登録して保存(User settings の場所を選ぶと全プロジェクトに適用)
4. /hooks で設定を確認するか、~/.claude/settings.json でファイルを直接確認可能
設定構造
- フックはmatcher を基準にグループ化され、matcher ごとに複数のフックを配列で持てる
- 例: 単一文字列(完全一致)、正規表現、空欄ならすべてのイベントに適用
- 設定ファイルの種類
~/.claude/settings.json: ユーザー全体の設定
.claude/settings.json: プロジェクト設定
.claude/settings.local.json: ローカル(非共有)設定
- エンタープライズポリシー設定
主なフックイベント
- PreToolUse: ツール呼び出し前に実行し、必要に応じて実行をブロック可能(主な matcher: Bash, Write, Edit, Grep など)
- PostToolUse: ツール実行直後、同じ matcher をサポート
- Notification: 通知送信時に実行
- Stop: 応答完了後に実行
matcher の例
Task: エージェント作業
Bash: シェルコマンド
Glob: ファイルパターンマッチ
Grep: 内容検索
Read: ファイル読み取り
Edit, MultiEdit: ファイル修正
Write: ファイル書き込み
WebFetch, WebSearch: Web 作業
入出力形式
- 入力: stdin で JSON を渡す(セッション情報、イベントごとのデータを含む)
- 例: PreToolUse には tool_input を含み、PostToolUse には tool_response が追加される
- 出力:
- exit code 0: 正常実行、stdout はユーザーに表示
- exit code 2: ブロック、stderr が Claude へフィードバックとして渡される(PreToolUse ではツール実行をブロック)
- その他のコード: エラー、stderr のみユーザーに表示
- 高度な制御: stdout に JSON を返した場合、
"continue" false や "decision": "block" などで詳細なフロー制御が可能
MCP ツールとの統合
- Model Context Protocol(MCP)ベースのツールもサポートし、特別な命名パターン(
mcp____)により選択的にターゲティングできる
セキュリティ上の推奨事項
- フックにはシステムの任意コマンド実行のリスクがあるため、入力値検証、パスチェック、機密ファイルの除外、絶対パスの使用などの安全ルールが必須
- 設定変更は即時反映されず、セッション開始時のスナップショットを使用し、外部変更時には警告を表示
実行環境とデバッグ
- 各フックは最大 60 秒制限、並列実行、現在の作業ディレクトリ・環境で動作
/hooks で設定確認、コマンドの直接テスト、exit code・出力チェックなどでデバッグ可能
- 実行過程と結果は transcript モード(Ctrl-R)で確認できる
4件のコメント
Windows版も作ってください……
WSLを使ってください
私のPCのスペックが低いせいか、WindowsのWSLではClaude Codeを使った一部の作業(例: プロジェクトのビルド、ローカルWebサーバーの実行など)があまりにも遅いです。
その作業だけ手動でWSLの外で実行する方法もありますが、面倒ですし制約もあるので、Gemini CLIが出てからはWindowsではClaude Codeの代わりにGemini CLIを中心に使っています。
Hacker Newsの意見
Claude Code Opus 4がファイル末尾に改行を付けない癖のせいで、かなりもどかしく感じていた。
新しいフックを試すたびにclaudeを再起動する必要があるので、セッション内で編集を続けられるスクリプトを使う方がずっと効率的だった。
このスクリプトはCファイルとシェルスクリプトにはフォーマッタを適用し、それ以外のファイルには不足している改行だけを補う。
ClaudeのようなAIは問題を適切に分割するのが苦手で、妙なやり方で作業しようとすることもあるので、上のフック例のようにJSONファイルをディスクに保存してパスだけ取り出してから再保存し、そのパスをsave-hook.shに渡す形に何度も直した。
10分で欲しいものはできたが、一度に大きなステップをやらせようとして無駄にした時間の方が長かった。
AIが開発者を置き換えるという話を耳にするが、こうしたフックを誰が設定し、新機能を提案するのかは依然として人間の役目だ。
こうしたツーリングに関する作業は、AIが自力でこの発想にたどり着いて別のAIに適用できる水準まで進化しない限り、今後も存在し続けるだろう。
木工の比喩で言えば、今は手工具から電動工具へ移る転換点だと思う。
基本を理解している人ほど道具をうまく扱えるが、いまや手で繊細に作る代わりにテーブルソーで素早く作業する段階であり、効率は上がる一方で危険も増すかもしれないという話だ。
コンバインのような農機が登場して農業の仕事を置き換える、という主張に似ている。
すべての人員が単に機械のオペレーターへ移行するだけだ、という話に説得力があるだろうか。
自動化ツールであれ、それが農業であれAIであれ、単純な置き換えだけが価値ではないという見方だ。
有名な「亀の上の地球」の話のように、AI登場のあとには「ではそのAIを誰が管理するのか?」という議論を無限に繰り返せる。
すでにClaude CodeにCLAUDE.mdを自分で更新させる事例もあり、自身のフックまで修正させることもまったく不可能ではない。
ただし、ジュラシック・パークのように「それは本当にやるべきなのか」という問いが抜け落ちがちなのは興味深い。
AIが開発職を減らすという意見も、では誰がフックを設定するのかという疑問も、どちらも正しい。
技術の進歩は雇用の増減だけに単純化できず、仕事をなくす一方で新しい仕事も生み出すという事実を強調している。
実際のところ、大半の人にとってこういう作業は開発ではなく、保守やDevOpsのような仕事だと思う。
SaaS製品でもコードそのものより運用に関わる作業が多く、HN利用者が考える本格的な開発とは少し違う。
今回の機能追加は本当に楽しみだ。
フックはエージェントのコンテキストエンジニアリングや実行時の性能検証で重要な役割を果たしそうだ。
エンタープライズのコンプライアンスや挙動監視など、さまざまな場面へ拡張できる。
AnthropicがGitHub Issueでの提案をすぐにサポートしたのも印象的だった。
関連Issueリンク
こういう機能は今後すべてのコーディングエージェントに普及する必殺技になると思う。
この機能が良いと感じるのは、CLAUDE.mdで迂回せずに複雑なコマンド実行制御ルールを直接書けるからだ。
たとえば、
docker compose exec django python manage.py test
のようなコマンドは許可し、
docker compose exec django python manage.py makemigrations
のようなコマンドはブロックできる。
この機能はMCPサーバーそのものとして動いた方がもっと良かったのではと思う。
フックをあらかじめ決められた名前のmcpツールとして用意しておき、エージェントが自動でフックを発見して内部実装を知らなくてもmcpサーバーを再利用したり、別のエージェントで使い回したりできる構図を想像している。
Claude CodeはCLAUDE.mdファイルの指示やコードベースの重要な内容をよく忘れるので、頻繁に思い出させる必要がある。
今回のアップデートでこの問題が直るのではないかと期待している。
ClaudeがCLAUDE.mdを読んで「22秒、2.6kトークン…」
「おっしゃる通りです!」という反応になる。
フックの例をいくつか共有する。
フック作成とワークフロー自動化の例の記事
Claude CodeがCursorと同等のレベルで、コード修正後のlintや型チェック支援を備えるようになったのはうれしい。
Cursorにもこの機能が入ってほしい。
今は応急処置として複数のルールを組み合わせてある程度しのいでいる。
今回の機能で、これまで存在していた大きな機能差が埋まると思う。
Claude Codeのコミット生成のやり方のせいで通常のGit hooksの大半が動作せず、CLAUDE.mdを通じてQlty CLIでコード整形を自動化するよう指示する裏技を使っていたが、Claudeがそれを一貫してうまく実行できなかったのが残念だった。
今回の変更で、より決定的な結果が得られる。
現時点ではhook可能なイベントは限られているが、今後はGit commitやpushイベントも簡単にフックできるようになるのではと期待している。
Qlty CLI GitHubリンク
ちなみにClaudeはJavaを非常によく扱う。
私のスタイルガイドやインデントの好みまで正確に把握していて、Javaコードの再フォーマットが不要なほど完璧に合わせてくる。
JavaDocまで精密に整えてくれるので驚いた。
おそらく大規模エンタープライズJavaコードの学習量が膨大だったのだろう。
なぜ通常のgit hooksがclaude codeで正しく動かないのか気になる。
Huskyとlint-stagedは正常に動いたが、Pre Commit Hooksは動かなかった。
私の短い理解では、この機能はcontextを消費せず、MCPのようにいつ実行するかをClaudeが決める仕組みでもなく、各ツール利用に対してユーザーが直接指定する自動動作の仕組みだ。