Claude Code Hooksは、Claude Codeの判断に任せるだけではなく、特定のタイミングでシェルコマンドや検証処理を必ず実行するための仕組みです。2026年時点では、フォーマット、テスト、通知、危険操作のブロック、MCP連携、非同期処理までカバーでき、チームでClaude Codeを導入するうえで重要な安全装置になっています。本記事では、Hooksの基本構造から実務で使いやすい設定例までを、既存ワークフローに組み込む前提で整理します。
Claude Code Hooksとは:開発フローを自動化する仕組み
Hooksは、Claude Codeがファイルを編集した後、ツールを使う前、セッションを開始したとき、ユーザー入力を待っているときなど、ライフサイクル上のイベントに反応して実行されるコマンドです。たとえば、ファイル編集後にPrettierを走らせる、Bash実行前に本番環境向けのコマンドを検査する、作業完了時に通知する、といった自動化ができます。LLMに「忘れずに実行して」と依頼するのではなく、設定として実行される点が最大のメリットです。
HooksはCLAUDE.mdとは役割が異なります。CLAUDE.mdはClaude Codeにプロジェクトの文脈や方針を伝えるためのコンテキストで、Hooksは実際の処理を発火させる自動化レイヤーです。たとえば「保存後にlintを実行する」はHooks、「lintが失敗したらまず変更箇所に近い原因を確認する」はCLAUDE.mdに書く、という分け方が実務では扱いやすいです。
Hooksの設定方法:settings.jsonの構造と記述ルール
HooksはClaude Codeのsettings.jsonにhooksブロックとして定義します。設定ファイルには、組織管理、コマンドライン、プロジェクトローカル、共有プロジェクト、ユーザー設定といった複数のスコープがあり、優先順位も決まっています。チームで共有したいHooksは.claude/settings.json、個人だけの通知やローカル補助は~/.claude/settings.jsonまたは.claude/settings.local.jsonに置くのが基本です。
設定はイベント名、matcher、hooks配列の3層で考えると理解しやすくなります。イベント名はPostToolUseやPreToolUse、Notificationなどの発火タイミング、matcherは対象ツールや条件、hooks配列は実行するコマンドです。既存のsettings.jsonに追加する場合は、hooksキー全体を置き換えず、イベント名を兄弟要素として追加します。JSONの構文エラーはClaude Codeの起動やHook実行に影響するため、jqなどで検証してから共有しましょう。
イベント種類の詳細:PreToolUse・PostToolUse・Notification
PreToolUseは、Claude Codeがツールを実行する直前に発火します。危険なBashコマンド、外部送信、特定ファイルへの書き込みなどを検査する用途に向いています。たとえば本番DBを更新するwranglerコマンド、rm -rf、secretsを含むファイルの表示など、チームとしてブロックしたい操作を検出できます。Claude Code側の権限設定と組み合わせると、うっかり操作への防御が厚くなります。
PostToolUseは、ツール実行後に発火します。ファイル編集後のformatter、lint、型チェック、生成JSONのスキーマ検証など、結果に対する機械チェックに向いています。Notificationは、Claude Codeがユーザー入力や承認を待っているときに通知する用途で便利です。長い作業中にターミナルを見続ける必要がなくなり、承認待ちで作業が止まる時間を減らせます。
実用例1:ファイル保存時の自動フォーマット
もっとも導入しやすいHookは、EditやWriteの後にformatterを実行するPostToolUseです。フロントエンドならPrettier、Pythonならruff format、Goならgofmtのように、言語ごとの標準ツールを使います。ポイントは、Hookに複雑な判断を詰め込みすぎないことです。対象ファイルのパスを取り出し、該当するformatterだけを実行し、失敗したらClaude Codeにわかる形でエラーを返す。このシンプルな構成が一番安定します。
チーム導入時は、formatter Hookを共有プロジェクト設定に入れる前に、CIと同じバージョンのツールを使っているか確認します。ローカルだけで整形結果が変わると、不要な差分が増えます。package managerやlockfile、Pythonの仮想環境、monorepoのサブパッケージ位置まで含めて、実行コマンドを固定しておくとトラブルを避けやすくなります。
実用例2:テスト自動実行とフィードバックループ
テスト自動実行は便利ですが、すべての編集で全テストを走らせると遅くなります。PostToolUseで変更ファイルの種類を見て、近い単体テストだけを実行する、あるいはStop hookで作業終了時にまとめて実行する構成が現実的です。Claude Codeに返す出力は短く、失敗したテスト名、エラーメッセージ、再実行コマンドに絞ると、次の修正が速くなります。
実用例3:セキュリティチェックの自動化
セキュリティ用途では、PreToolUseで危険操作を止め、PostToolUseで静的解析を走らせる二段構えが有効です。たとえば、環境変数や秘密鍵を含むファイルの読み取り、外部URLへの送信、権限の広いクラウド操作を検出します。Claude Code自体にも権限モード、ネットワーク承認、サンドボックス、信頼確認などの保護がありますが、プロジェクト固有のリスクはチーム側のHookで補うべきです。
特にMCPサーバーや外部Webコンテンツを扱うプロジェクトでは、プロンプトインジェクション対策として「外部から取得した内容をそのままコマンドに渡さない」「生成されたSQLやシェルを人間またはHookで確認する」ルールを設けます。Hookは万能ではありませんが、既知の危険パターンを確実に止める最後の確認ポイントになります。
実用例4・5:デプロイ自動化とコードレビュー通知
デプロイ自動化では、Claude Codeから直接本番反映させるより、Hookでステージング検証、差分要約、承認待ち通知を行う形が安全です。たとえば特定ブランチでStop hookが発火したら、lint、test、buildを実行し、結果をSlackやGitHubに投稿する構成です。本番デプロイはCI/CD側に任せ、Claude Codeは準備と検証に集中させると、権限設計が明確になります。
コードレビュー通知では、PR作成前に差分の要約、影響範囲、テスト結果、残タスクをHookで整形できます。レビュー担当者にとって必要な情報が毎回そろうため、AIが生成した変更でも確認しやすくなります。Hookから外部サービスに送信する場合は、チャンネル、宛先、含めてよい情報を事前に決め、秘密情報や顧客データが混ざらないようにしましょう。
Slash Commandsとの連携でさらに効率化
Slash Commandsは、.claude/commands/にMarkdownファイルを置いて、よく使うプロンプトや作業手順をコマンド化する機能です。Hooksと組み合わせると、/reviewでレビュー観点を統一し、PostToolUseでlintを実行し、Stop hookでレビュー結果を要約する、といった一連の流れを作れます。人間が毎回説明する部分をSlash Commandsに、必ず実行したい検証をHooksに分けると、チーム全体で再現性のあるワークフローになります。
導入のコツは、小さく始めてログを見ることです。最初からすべてを自動化すると、失敗時の原因が追いにくくなります。まずformatter、次に単体テスト、次に危険操作のブロック、最後に通知やレビュー連携へ広げると安定します。Claude Code Hooksは、AIコーディングを「その場の会話」から「チームで運用できる開発プロセス」に変えるための実用的な土台です。