Claude CodeのHooks機能とは？設定方法と活用パターンを徹底解説

Claude CodeのHooks（フック）は、Claude Codeのライフサイクル上の特定タイミングで自動実行されるユーザー定義のルール群です。プロンプトでの「お願い」と違い、設定したルールは100%確実に実行されます。
2026年6月時点の公式リファレンスでは、30種のライフサイクルイベントと5種のハンドラタイプ（command/http/mcp_tool/prompt/agent）が提供されており、AsyncハンドリングやPlugin Marketplace連携も加わって、機能の自動化基盤としての位置づけが一段強まりました。

本記事では、Hooks機能の基本概念から30種のライフサイクルイベント体系、5つのハンドラタイプの使い分け、具体的な設定手順、6つの実用パターン、セキュリティ対策、料金体系、そしてケース別の導入判断とPlugin Marketplaceでの配布運用までを、2026年6月時点の公式ドキュメントに基づいて徹底解説します。

✅2026年6月9日、AnthropicがMythos-class初の一般公開モデル「Claude Fable 5」を発表しました。Opus 4.8の上位に位置する新最上位モデルの詳細はこちら。
▶︎Claude Fable 5とは？Mythos 5との違いや料金、使い方を解説

Claude CodeのHooks機能とは

Claude CodeのHooks（フック）は、Claude Codeのライフサイクル上の特定タイミングで自動実行されるユーザー定義のルール群です。

Anthropic公式ドキュメントでは「Claude Codeの動作に対して決定論的な制御を提供し、LLMに実行を選択させるのではなく、特定のアクションが常に実行されることを保証する」機能と説明されています。

「ファイルを編集した後に必ずフォーマッターを実行する」「機密ファイルへの書き込みをブロックする」「すべてのBashコマンドをログに残す」といったルールを、プロンプトで毎回お願いするのではなく、設定ファイルに一度書いておくだけで自動化できる仕組みです。

「お願い」を「ルール」に変える設計思想

Hooksの最大の特徴は、決定論的な動作保証にあります。

プロンプトでの指示はLLMの判断に依存するため、忘れたり無視されたりする余地が残ります。一方、Hooksで設定したルールは対応するイベントが発生するたびに必ず実行されるため、人間側の指示忘れやLLMの判断揺れを排除できます。

つまり、Hooksは開発ワークフローの「お願い」を「ルール」に変える役割を担っています。この違いは、特にチーム開発やセキュリティ要件が厳しい環境で大きな意味を持ちます。

Claude Code内でのHooksの位置づけ

Claude Codeには、Hooks以外にもAIエージェントの挙動を拡張・制御する仕組みが複数用意されています。それぞれ役割が異なるため、混同しないよう整理しておきます。

以下の表で、Claude Codeにおける主要な拡張機構の位置づけを整理しました。

HooksとAgent Skillsの違いは、確実性の質にあります。

Skillsは「モデルが必要と判断したら呼び出す」仕組みのため、呼び出されない可能性が残ります。一方、Hooksは「イベントが発生したら必ず実行される」仕組みなので、セキュリティガードレールや品質ゲートのような「絶対に外れてはいけないルール」に向きます。

2026年版で大きく拡張された3つのポイント

Hooksは2026年に入ってから大きく機能拡張されており、初期リリース時点の情報では仕様を捉えきれません。直近の主な進化を整理します。

• 30種のライフサイクルイベントが提供
  公式リファレンスで確認できる2026年6月時点のイベントは30種で、PostToolBatch・MessageDisplay・FileChanged・InstructionsLoaded・Elicitation などが用意されています。並列ツール呼び出しの完了検知や、メッセージ表示への介入といった制御点も扱えます。
  
  

• ハンドラタイプが3種から5種に拡張
  従来の command・prompt・agent に加え、HTTPエンドポイントにJSONをPOSTする http 型、既接続のMCPサーバーのツールを呼び出す mcp_tool 型が追加されました。社内Webhookや既存MCP資産との連携が一段やりやすくなっています。
  
  

• Plugin Marketplaceによる配布が公式化
  公式のPlugin機構を使えば、Hooks・Skills・Subagents・MCPサーバーをまとめて配布できます。社内専用Marketplaceを構築して、検証済みHooksをチームに横展開する運用も広がっています。

これらの変化により、Hooksは単なる「自動フォーマット用の便利機能」から、組織レベルの統制とエージェント連携を支える基盤機能へと位置づけが変わっています。

Hooksが解決する4つの開発現場の課題

このセクションでは、AIコーディングを業務に取り込むときに繰り返し起きる課題と、Hooksがそれぞれにどう効くのかを整理します。

AIコーディングの利便性は飛躍的に上がりましたが、実務に組み込もうとすると次の4つが必ず壁になります。Hooksは、いずれもプロンプト依存を脱して仕組み側で解決する道具になります。

• 手動の繰り返し作業
  ファイル編集のたびにフォーマッターやリンターを叩く必要がある。プロンプトで「prettierを実行して」と毎回頼んでも忘れられる。PostToolUseフックなら、Edit/Writeの直後に必ずフォーマッターが走るため、依頼自体が不要になる。
  
  

• セキュリティの不確実性
  .envファイルやpackage-lock.json、本番デプロイ用設定のような「AIに触らせたくないファイル」を確実に守る手段がない。プロンプトで「触らないで」と書いても、複雑なタスクの途中で無視される。PreToolUseフックで終了コード2を返せば、ツール呼び出し自体をブロックできる。
  
  

• チーム全体のルール統一
  コーディング規約・コミット前検査・命名規則をメンバー全員に徹底させるのは難しい。個人の設定漏れやプロンプトの書き方のばらつきが品質のムラにつながる。プロジェクト設定（.claude/settings.json）にHooksを書いてGit管理すれば、リポジトリをクローンした全員に同じルールが配布される。
  
  

• 監査・ログの不足
  AIが実行したコマンドや変更履歴が残らず、後追いの調査やコンプライアンス対応が難しい。PreToolUseでBashコマンドをログファイルに追記するフックを1つ仕込むだけで、すべてのコマンドが時系列で記録される。

これら4つはどれも「プロンプトをいくら整えても根本解決しない」課題です。AIに頼むこと自体を諦め、仕組み側でルール化するというHooksの発想が効くポイントが、まさにここにあります。

実務観察として、Hooksをまず1つ導入したチームの多くは「導入後すぐに体感が変わる」と評価しています。最初の1本はファイル編集後の自動フォーマット、または機密ファイルの保護から始めるのが現実的です。

2026年版の30種のライフサイクルイベント

このセクションでは、Claude Code Hooks公式リファレンス（英語版・日本語版）に基づく2026年6月時点の30種のライフサイクルイベントを、用途別に5つのグループへ分けて整理します（日本語版はタイミングによって英語版より追加イベントの反映が遅れる場合があるため、英語版で最新仕様を併せて確認するのが安全です）。

イベント数が多く見えますが、グループで捉えれば「どのタイミングで何ができるか」が把握しやすくなります。

セッション・ターン単位のイベント

セッションの開始・終了や、ユーザーが1ターンの会話を投入・完了するタイミングで発火するイベント群です。

SessionStartは特に応用範囲が広いイベントです。2026年版では reloadSkills: true を返すと、フックがインストールしたSkillsを同セッション内で再認識させられるようになりました。

ツール呼び出しループ内のイベント

ツール実行の前後に挟まる、最も使用頻度が高いイベント群です。

2026年版で追加された PostToolBatch は、Claude Codeが複数ツールを並列実行したあとに発火するため、まとめてログを残したい場合に便利です。

エージェント・タスク関連のイベント

サブエージェントの起動・停止やタスク管理に関わるイベント群です。

サブエージェントを多用する設計では、SubagentStartとSubagentStopをペアで監視することで、サブタスクごとの実行時間や成果を追跡できます。

非同期・状態変化のイベント

ファイル変更・設定変更・ディレクトリ変更など、能動的なツール呼び出しとは別軸で発火するイベント群です。

MessageDisplayは2026年版で追加されたイベントで、画面に表示されるテキストだけを差し替えられます。transcriptに保存される内容やClaude側が次のターンで参照する文脈は元のままで変更できないため、純粋に「表示レイヤーのフィルタ」として位置づけて使うのが正しい運用です。社外秘ワードの表示マスキングのような用途には使えますが、Claudeに渡る情報そのものを止めたい場合はPreToolUseやUserPromptSubmitなど別イベントで制御する必要があります。

MCP連携イベント

MCP（Model Context Protocol）サーバーとの対話で発火するイベント群です。

MCP経由で外部サービスと連携する構成では、Elicitationを使って人間の確認ステップを自動化したり、応答内容をログに残したりする運用が現実的です。

頻出イベントの詳細——PreToolUse・PostToolUse・Stop

30種すべてを覚える必要はありません。実務でまず使うのは、以下の3つです。

PreToolUse は、ツールが実行される直前に発火する「ガードレール」用のイベントです。終了コード2を返すとツール呼び出しが即座にブロックされ、Claudeにブロック理由をフィードバックできます。機密ファイルの保護や危険コマンドの検証に最適です。マッチャーで Bash・Write・Edit・Read などのツール名を指定でき、正規表現にも対応します。

PostToolUse は、ツールが正常完了した直後に発火する「後処理」用のイベントです。ファイルの自動フォーマット、変更内容のログ記録、テスト実行などに使います。2026年版では hookSpecificOutput.updatedToolOutput を返すことで、ツール出力そのものを書き換えてClaudeへ渡せるようになりました。

Stop は、Claudeが応答を終えようとするタイミングで発火するイベントです。Prompt型と組み合わせれば、「本当にすべてのタスクが完了したか」をLLMに評価させ、不十分なら作業を続行させられます。stop_hook_active フラグを確認しないと無限ループに陥るリスクがある点だけ注意が必要です。

5つのハンドラタイプの使い分け

このセクションでは、Hooksに登録できる5種のハンドラタイプを使い分けの観点で整理します。

ハンドラタイプは「フックがイベントに対してどう応答するか」を決める仕組みです。同じPreToolUseでも、ローカルでシェルコマンドを叩くのか、社内Webhookに投げるのか、LLMに判断させるのかで運用設計が変わります。

以下の表で、5種のハンドラタイプの特性を整理しました。

5種のうち、command と prompt・agent は元から提供されていましたが、http と mcp_tool は2026年版で追加されたタイプです。社内システムやMCP経由の既存資産との接続が一段やりやすくなっています。

command型——ローカル実行の最速ルート

最も基本的で多用されるタイプです。シェルコマンドや任意のスクリプトをローカルで実行し、stdoutやexit codeで結果を返します。

{
  "type": "command",
  "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/validate.sh",
  "args": ["--strict"],
  "timeout": 60
}

args を指定するとExec形式（シェルを介さない直接実行）になり、スペースや特殊文字を安全に扱えます。args を省略するとShell形式（sh -c 経由）になり、リダイレクトやパイプを使えます。セキュリティ面ではExec形式が推奨です。

http型——社内Webhookと外部システム連携

2026年版で追加された、HTTPエンドポイントにイベントJSONをPOSTで送るタイプです。

{
  "type": "http",
  "url": "http://localhost:8080/hooks/pre-tool-use",
  "timeout": 30,
  "headers": {
    "Authorization": "Bearer $MY_TOKEN"
  },
  "allowedEnvVars": ["MY_TOKEN"]
}

社内のセキュリティスキャナーや承認ワークフローシステムと連携したい場合、http型でAPIを呼ぶだけで済みます。allowedEnvVars で環境変数のホワイトリストを明示する設計のため、シークレットの誤露出を防ぎやすい構造です。

mcp_tool型——MCP資産の流用

これも2026年版で追加されたタイプで、既に接続済みのMCPサーバーのツールをフックから呼び出せます。

{
  "type": "mcp_tool",
  "server": "my_server",
  "tool": "security_scan",
  "input": {
    "file_path": "${tool_input.file_path}"
  },
  "timeout": 120
}

${tool_input.file_path} のようにフック入力JSONの値を置換できるため、ファイル編集をフックでセキュリティスキャンに回す、といった連携を最小コードで実装できます。既存のMCPサーバー資産がある組織では、http型より優先される選択肢です。

prompt型——LLMによる文脈判断

決定論的なルールでは判定できない「文脈判断」が必要な場面で使うタイプです。デフォルトはHaikuモデルが呼び出され、model フィールドで上位モデルに切り替えられます。

{
  "type": "prompt",
  "prompt": "Is this bash command safe to execute? Command: $ARGUMENTS",
  "model": "claude-haiku",
  "timeout": 30
}

「このコマンドは安全か」「タスクは本当に完了しているか」といった、人間の判断が必要な領域を自然言語で記述できるのがprompt型の強みです。

agent型——複数ステップの自律検証

サブエージェントを生成し、ツール呼び出しを伴うマルチターンの検証を行うタイプです。実験的機能のため変更可能性がある点には留意が必要です。

{
  "type": "agent",
  "prompt": "Verify that all tests pass",
  "timeout": 60
}

テスト実行・コードレビュー・複雑な品質ゲートのように、複数ステップで動かないと結論が出ない検証はagent型の独壇場です。実行コストは最も高いため、本当に必要な場面に限定するのが定石です。agent型とSubagentsは内部的に同じ仕組みを共有しています。

Hooksの設定方法とJSON構文

このセクションでは、Hooksを実際に設定する手順を、保存場所・設定UI・JSON直書き・マッチャー・終了コードの順で解説します。

設定ファイルの保存場所——6箇所と階層

Hooks設定は6箇所に保存でき、配布範囲とGit共有可否によって使い分けます。

チーム導入の起点はプロジェクト設定です。.claude/settings.json にHooksを書いてGitにコミットすれば、リポジトリをクローンした全員に同じルールが配布されます。

ローカル設定（.claude/settings.local.json）は個人用の通知設定やデバッグ用フックを置く場所で、コミット対象から外れます。組織レベルで全社強制したいルールは、管理ポリシー設定に置くのが正解です。

/hooks メニューは確認用——追加・編集はJSON直接編集が正規ルート

Claude Code内で /hooks スラッシュコマンドを叩くと、現在登録されているHooksをイベント別・マッチャー別に一覧できます。公式の使い始めガイドでは、この /hooks メニューは読み取り専用（read-only）の確認用UIと位置づけられており、フックの追加・変更・削除には対応していません。

新規のHooksを設定するには、~/.claude/settings.json・.claude/settings.json・.claude/settings.local.json のいずれかに hooks ブロックを直接書く（次節のJSON設定ファイル例を参照）か、Claudeに対して「PostToolUseで〜するフックを .claude/settings.json に追加してほしい」と依頼する形になります。

設定後は /hooks を開いて以下を確認するのが定石の運用です。

1. 該当イベント（例: PostToolUse）にフックが登録されているか
2. マッチャーが想定どおりか（例: Edit|Write）
3. ハンドラタイプとコマンドが正しく入っているか

「対話的に追加できると勘違いして編集ボタンを探し続ける」のはよくある詰まりポイントです。/hooks は確認窓口・JSONは編集窓口、と最初に切り分けておくと迷いません。

JSON設定ファイルの直接編集

複数ルールを一括管理したい場合や、テンプレートをコピーして横展開したい場合は、設定ファイルを直接編集します。以下は、TypeScriptファイルを編集・新規作成した直後にPrettierを自動実行する設定例です。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | { read file_path; if echo \"$file_path\" | grep -q '\\.ts$'; then npx prettier --write \"$file_path\"; fi; }"
          }
        ]
      }
    ]
  }
}

このアプローチの利点は2つあります。1つは複数フックの一括管理ができること、もう1つは設定ファイルをそのままGitに含められるため、レビュー対象として履歴を残せることです。

マッチャーの指定方法

マッチャーは「どのツール呼び出しでフックを発火させるか」を決める制御点です。指定パターンは以下のとおりです。

マッチャーは大文字小文字を区別するため、Write と write は別ツール扱いです。意図しない発火を避けるため、正確なツール名は公式ドキュメントで確認するのが安全です。

終了コードの意味——0・2・その他

フックの実行結果は終了コード（exit code）でClaude Codeに伝わります。3パターンの挙動を覚えれば、フック設計時に迷うことはありません。

• 終了コード 0
  正常終了。stdoutにJSONを出していれば、その内容がClaudeに渡されます。JSONが空ならフックは何もしなかったものとして処理が続行されます。
  
  

• 終了コード 2
  ブロッキングエラー。stderrの内容がClaudeへのフィードバックとして渡されます。PreToolUseならツール呼び出しがブロックされ、UserPromptSubmitならプロンプト処理がキャンセルされる、といった具合に、イベントごとに「拒否」の意味で動きます。
  
  

• 終了コード 1, 3以上
  非ブロッキングエラー。stderrの最初の行が通知として表示され、処理自体は続行されます。例外として、WorktreeCreateだけは0以外でworktree作成が失敗します。

セキュリティガードレールを作るときは、終了コード2を意図的に使うのが定石です。「機密ファイルへの書き込みを検知したら2を返してブロック」「Claudeにブロック理由を伝える」という流れで、安全側に倒した運用ができます。

実用6パターン——自動フォーマットから並列処理まで

このセクションでは、現場で繰り返し使われるHooksの設定パターンを6つ紹介します。公式のhooks-guideに掲載されている例を中心に、2026年版で追加されたPostToolBatch活用も含めています。

パターン1: ファイル編集後の自動フォーマット

最初に設定すべき定番です。Claude Codeがファイルを編集・作成するたびに、自動的にフォーマッターを実行します。

使用イベントはPostToolUse、マッチャーはEdit|Writeです。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | { read file_path; if echo \"$file_path\" | grep -q '\\.ts$'; then npx prettier --write \"$file_path\"; fi; }"
          }
        ]
      }
    ]
  }
}

stdinから受け取るJSONからファイルパスを抽出し、拡張子が .ts の場合のみPrettierを実行する設定です。Goなら gofmt、Pythonなら black というように、言語ごとのフォーマッターに差し替えるだけで他言語にも応用できます。

このパターンの利点は、フォーマッター実行忘れがゼロになることです。プロンプトで「フォーマットもお願い」と毎回依頼する必要がなくなるため、開発のテンポも改善します。

パターン2: 機密ファイルの保護

.envファイルやpackage-lock.json、.git/ ディレクトリのような「AIに触らせたくないファイル」への書き込みをブロックするパターンです。

使用イベントはPreToolUse、マッチャーはEdit|Writeです。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "python3 -c \"import json, sys; data=json.load(sys.stdin); path=data.get('tool_input',{}).get('file_path',''); sys.exit(2 if any(p in path for p in ['.env', 'package-lock.json', '.git/']) else 0)\""
          }
        ]
      }
    ]
  }
}

終了コード2を返すことで、Claudeに対してツール呼び出し自体をブロックしつつ、理由をフィードバックします。Claude側はブロック理由を受け取って別のアプローチを試みます。

実務的には、保護対象のリストをプロジェクト固有の設計に合わせて拡張するのがおすすめです。.aws/credentials・.kube/config・secrets/ ディレクトリなど、組織ごとの「絶対に触らせない場所」を全部書いておきます。

パターン3: Bashコマンドの監査ログ

コンプライアンスやデバッグのために、Claude Codeが実行するすべてのBashコマンドをファイルに記録するパターンです。

使用イベントはPreToolUse、マッチャーはBashです。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.command' >> ~/.claude/bash-command-log.txt"
          }
        ]
      }
    ]
  }
}

監査要件のある業務では、このログがそのままインシデント対応の証跡になります。タイムスタンプを足したい場合は echo \"$(date -Iseconds) $(jq -r '.tool_input.command')\" に拡張すれば対応できます。

パターン4: SessionStartでの環境変数とSkillsリロード

セッション開始時に必要な環境変数を読み込み、最新のSkillsを再スキャンするパターンです。2026年版で追加された reloadSkills: true の挙動を活かします。

公式ドキュメントによると、SessionStart Hooksでは CLAUDE_ENV_FILE という環境変数にアクセスでき、このファイルに書いた変数はセッション内のすべてのBashコマンドで参照可能になります。

#!/bin/bash
if [ -n "$CLAUDE_ENV_FILE" ]; then
  echo 'export NODE_ENV=production' >> "$CLAUDE_ENV_FILE"
  echo 'export DATABASE_URL=postgresql://localhost/dev' >> "$CLAUDE_ENV_FILE"
fi

# Skillsディレクトリを再スキャンさせる
echo '{"hookSpecificOutput": {"reloadSkills": true}}'
exit 0

nvmでのNode.jsバージョン切り替え、プロジェクト固有の環境変数設定、社内Skillsのバージョン更新を一気に反映する用途に向きます。

パターン5: Stop Hookでのタスク完了判定

Prompt型を使い、Claudeが応答を終える前に「本当にすべてのタスクが完了したか」をLLM自身に評価させるパターンです。

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "prompt",
            "prompt": "You are evaluating whether Claude should stop working. Context: $ARGUMENTS\n\nAnalyze the conversation and determine if:\n1. All user-requested tasks are complete\n2. Any errors need to be addressed\n3. Follow-up work is needed\n\nRespond with JSON: {\"ok\": true} to allow stopping, or {\"ok\": false, \"reason\": \"your explanation\"} to continue working.",
            "timeout": 30
          }
        ]
      }
    ]
  }
}

このパターンでは、Haiku（または model フィールドで指定した上位モデル）が会話文脈を読み解いてタスク完了度を判定します。

ただし、stop_hook_active フラグを確認しないと「終わらせない判定→再評価→終わらせない判定」の無限ループに陥るため、フック側で必ずチェックを入れる設計が必要です。

パターン6: PostToolBatchで並列処理のサマリーを残す

2026年版で追加されたPostToolBatchを使った、並列実行のサマリーパターンです。Claudeが複数ツールを並列実行した直後にまとめてログを記録できます。

{
  "hooks": {
    "PostToolBatch": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "jq -c '{batch_id: .batch_id, tool_count: (.tools | length), duration_ms: .duration_ms}' >> ~/.claude/batch-log.jsonl"
          }
        ]
      }
    ]
  }
}

並列実行は単一ツールのログでは捉えにくい挙動を含むため、バッチ単位でサマリーを残しておくと、後追いのパフォーマンス分析や挙動再現が容易になります。

セキュリティと運用上の注意点

このセクションでは、Hooksを安全に運用するための注意点と、公式が推奨するセキュリティ対策を整理します。

公式が明示するセキュリティリスク

Hooks公式リファレンスでは、フックのセキュリティについて以下の免責事項が明記されています。

• Hooksはシステム上で任意のシェルコマンドを自動的に実行する
• 設定したコマンドの結果については、ユーザーが単独で責任を負う
• 悪意のある、あるいは不適切に書かれたHooksはデータ損失やシステム損害を引き起こし得る
• Anthropicはhook使用から生じるいかなる損害についても責任を負わない

つまり、Hooksは強力な機能である一方で、設定ミスや悪意あるスクリプトの混入には十分な注意が必要です。プロジェクト設定をGit共有する運用なら、フック設定はコードレビューと同じ粒度でレビューに乗せるのが原則になります。

公式が推奨する5つのベストプラクティス

公式ドキュメントでは、以下のベストプラクティスが推奨されています。

• 入力を検証・サニタイズする
  stdinから受け取るJSONを盲目的に信頼せず、想定外の値に対する処理を実装する。
  
  

• シェル変数を常にクォートする
  $VAR ではなく "$VAR" を使い、スペースを含むパスでのエラーを防ぐ。
  
  

• パストラバーサルをブロックする
  ファイルパスに .. が含まれていないかを検証し、意図しないディレクトリへのアクセスを防止する。
  
  

• 絶対パスを使用する
  スクリプトの参照にはフルパスを指定する。プロジェクト内スクリプトには $CLAUDE_PROJECT_DIR 変数を活用する。
  
  

• 機密ファイルへのアクセスを避ける
  フック内で .env や .git/、APIキーファイルを読み取らないよう設計する。

「シェル変数をクォートする」「絶対パスを使う」のような基本は、シェルスクリプト全般のルールと同じです。Hooksだから特別に必要というわけではなく、シェル運用の基本がそのまま当てはまります。

スナップショット機構による設定改ざん対策

Claude Codeには、セッション中のフック改ざんを防ぐ仕組みが組み込まれています。

セッション開始時にHooksのスナップショットを取得し、セッション中はそのスナップショットに基づいて動作します。セッション中にフック設定が外部から変更された場合は警告が表示され、/hooks メニューでレビューが必要になります。同じくClaude Code側のセキュリティ機構であるClaude Code Securityと組み合わせることで、AIコーディングの安全領域が一段広がります。

この仕組みにより、悪意あるフック変更が現在のセッションに即座に影響することを防いでいます。Git経由で配布されたフックを「セッション開始時に固定する」前提で運用できるため、長時間のクラウドセッションでも改ざんリスクを最小化できます。

エンタープライズ向け管理機能

組織レベルでHooksを統制したい場合、managed settings（管理ポリシー設定）のトップレベルに allowManagedHooksOnly: true を設定することで、ユーザー設定・プロジェクト設定・ローカル設定のフックを無効化し、管理者承認済みのフックのみを実行させられます。allowManagedHooksOnly は managed settings 専用のキーで、ユーザー設定やプロジェクト設定側に書いても効きません。

{
  "allowManagedHooksOnly": true
}

disableAllHooks と組み合わせれば、特定のチームでフックを完全に止めることも可能です。例外として、managed settings の enabledPlugins で plugin@marketplace ID を明示的に有効化したプラグインのHooksは読み込み対象になります。社内Marketplaceを立てて、enabledPlugins に承認済みプラグインIDを並べる運用にすれば、「承認済みフックは横展開・それ以外は禁止」という統制が実現します。

デバッグと動作確認の手順

Hooksが正しく動作しているかを確認する手順として、公式ドキュメントでは以下が推奨されています。

1. /hooks コマンドでHooksの登録状態を確認する
2. JSON設定の構文が正しいかを検証する
3. フックコマンドを手動で実行してテストする
4. スクリプトに実行権限があるかを確認する
5. claude --debug で詳細なログを確認する

特に、新しいフックを追加したときは、本番運用に乗せる前にテスト環境で十分に動作確認してから配布するのが定石です。チーム導入時は「最初にCIで動かして問題なかったらメインリポジトリへマージ」という運用が現実的です。

料金体系とプラン依存性

このセクションでは、Hooksに関連する料金体系を整理します。

Hooks自体に追加料金は発生しません。 HooksはClaude Codeの標準機能として含まれており、設定や利用にあたって個別の課金はかからない設計です。

ただし、Hooksを使うにはClaude Code本体が使えるプランへの加入が前提です。2026年6月時点のプラン構成は以下のとおりです。

個人開発者ならPro、フルタイムでClaude Codeを使う開発者ならMax 5x、複数プロジェクトをヘビーに回す開発者ならMax 20xという段階的な選択が現実的です。チーム導入はTeam Standardが入口、エンタープライズ要件があるならEnterpriseへ移行します。各プランの利用制限や枠の使い切り方はClaude Codeの利用制限と対処法に詳しいので、ヘビーユース前提なら一読しておくと運用設計が楽になります。

Prompt型・Agent型Hooksの利用枠消費

決定論的な command・http・mcp_tool 型は、Claude Codeのモデル呼び出しを介さないためプラン枠を消費しません。一方、prompt型と agent型 は内部的にClaudeモデルへのAPIコールが発生するため、プランの利用枠を消費します。

• prompt型: デフォルトでHaikuモデルが呼び出されるため、上位モデルより消費は軽い。ただし発火頻度が高いと積み上がる
• agent型: 複数ステップで動くため、prompt型より消費は大きい。テストやレビューのような重い検証に絞って使うのが原則

実務的には、ガードレール用途はcommand型で固め、文脈判断が必要な箇所だけprompt型を使い、複雑な検証にだけagent型を使うという「軽い順に積み上げる」設計が、コストと精度のバランスを取りやすい構成です。

最新の料金情報は、公式の料金ページで確認してください。

【関連記事】
Claude Codeの料金プラン完全ガイド｜利用制限・支払い方法・確認方法を解説【2026年5月版】

ケース別の導入判断とPlugin Marketplace連携

このセクションでは、Hooks導入の現実的な進め方をケース別に整理し、公式のPlugin Marketplaceを使った社内配布運用も合わせて解説します。

「便利そうだけど何から始めればいいか分からない」というのは、Hooksに限らずAIツール導入で最も多い詰まりポイントです。AI総研の導入支援現場でも、最初の1本をどう選ぶかで定着率が大きく変わる肌感があります。

個人開発者の場合——最初に設定すべき2つ

個人開発者がProプラン+CLIでClaude Codeを使う場合、まず設定すべきは以下の2つです。

1. PostToolUseでファイル編集後の自動フォーマット（パターン1相当）
2. PreToolUseで機密ファイルの保護（パターン2相当）

この2本だけで、AIコーディングの体験が一段変わります。フォーマッターを叩く手間がゼロになり、.env を誤って書き換える事故も防げます。~/.claude/settings.json または .claude/settings.local.json にhooksブロックを書き、登録状態は /hooks メニューで確認するという流れで、20分もあれば設定できる作業量です。

中規模チームの場合——プロジェクト設定でGit共有

5〜30名規模の開発チームでは、プロジェクト設定（.claude/settings.json）にフックを集約してGit管理するのが定石です。

具体的な始め方の例は以下のとおりです。

• 個人開発フェーズで定着した「自動フォーマット」「機密ファイル保護」をプロジェクト設定に昇格させる
• 言語別フォーマッター（Prettier、gofmt、black、rubocop等）をリポジトリのフォーマット規約に合わせて統一する
• コミット前のリンター実行・テスト実行をPostToolUse + agent型で組み込む
• .claude/settings.local.json を .gitignore に入れ、個人用のデバッグ・通知フックは各自で管理する

プロジェクト設定をPull Request単位でレビューすることで、フック追加が「セキュリティ運用の変更」として記録に残ります。後からトラブルがあったときに「いつ誰が追加したフックか」を追える運用が、チーム規模が大きくなるほど効いてきます。チーム・組織展開の進め方はClaude Codeの企業導入ガイドで詳述しています。

エンタープライズの場合——管理ポリシー＋Plugin Marketplace

100名以上の組織や、コンプライアンス要件が厳しい業務に組み込む場合は、管理ポリシー設定とPlugin Marketplaceを併用します。

• 管理ポリシー設定で allowManagedHooksOnly: true を有効化
  ユーザー設定・プロジェクト設定のフックを禁止し、組織承認済みのフックだけを実行させる
  
  

• 社内専用Plugin Marketplaceを構築
  Hooks・Skills・Subagents・MCPサーバーをまとめて配布できる仕組み。検証済みプラグインだけがリストに載るため、品質統制が効く
  
  

• 管理フックでBashコマンドの監査ログを強制
  パターン3相当のフックを管理レベルで強制し、すべての開発端末で同じログ仕様にする
  
  

• PreToolUseで本番リポジトリへの直接アクセスを禁止
  組織固有の保護対象（本番DBスキーマ、機密設定ファイル等）への書き込みを管理レベルでブロック

この組み合わせなら、「個人開発者の自由度を残しつつ、組織として守らせたいルールは確実に守らせる」という二段構えの統制が実現します。コンプライアンス監査が必要な業務でも、フック設定そのものが統制エビデンスとして機能します。

Plugin MarketplaceでHooksを配布する運用——Cybozu kintoneチームの事例

Plugin Marketplaceは、Hooks・Skills・Subagents・MCPサーバーをまとめて配布できる仕組みで、社内専用Marketplaceを立てて検証済みアセットをチームに横展開する企業が増えています。

2026年2月時点のCybozu kintoneチーム公開事例では、2025年10月にClaude CodeのPlugin機構が追加されたあと年末年始にチーム専用Marketplaceを構築し、Claude Code経由のIssue作成数が2025年の月平均約50件から2026年に入って月換算約80件ペースまで増加したと報告されています。

社内Marketplaceで配布する代表的なフック構成は以下のとおりです。

• 言語別フォーマッター連携フック（PostToolUse）
• 本番リポジトリ直接編集の禁止フック（PreToolUse）
• コミットメッセージ規約チェック（PreToolUse + prompt型）
• 社内通知ハブへのSlackポストフック（Notification、http型）

個別のフック設計を各開発者に任せるよりも、検証済みのフックをMarketplaceで横展開する方が、配布スピードも品質も上がります。組織で導入を進めるなら、最初のフェーズで「社内Marketplaceの土台」を作ってしまうのが、現実的な遠回りに見えて最短ルートになります。

Hooksで培った自動化の発想を業務全体のAI化に広げる

AI業務自動化ガイドで組織的なAI導入を設計

Hooksで開発ワークフローを「お願い」から「ルール」に変える発想は、Microsoft 365を起点とした業務自動化にもそのまま応用できます。AI業務自動化ガイドでは、Copilot ChatからCopilot Studio・AI Agent Hubまでの段階的な導入設計と、経費精算・請求書処理・申請業務など部門別のBefore/After付きユースケースを220ページで体系的に解説しています。

▶ 無料でダウンロード

Hooksで培った自動化の発想を業務全体のAI化に広げる

Hooksで開発ワークフローを「お願い」から「ルール」に変える経験は、業務プロセス全体のAI化を設計するときの考え方そのものです。コードの自動フォーマットや機密ファイル保護で得た発想は、経費精算や請求書処理、申請業務のように現場で繰り返される定型業務にもそのまま応用できます。

AI総合研究所の「AI業務自動化ガイド」では、Microsoft 365 CopilotからCopilot Studio・AI Agent Hubまでの段階的な導入設計と、部門別のBefore/After付きユースケースを220ページで体系的に解説しています。Hooksで培った発想を組織全体の自動化に広げる実践資料として活用ください。

Hooksで培った自動化の発想を業務全体のAI化に広げる

AI業務自動化ガイドで組織的なAI導入を設計

Hooksで開発ワークフローを「お願い」から「ルール」に変える発想は、Microsoft 365を起点とした業務自動化にもそのまま応用できます。AI業務自動化ガイドでは、Copilot ChatからCopilot Studio・AI Agent Hubまでの段階的な導入設計と、経費精算・請求書処理・申請業務など部門別のBefore/After付きユースケースを220ページで体系的に解説しています。

▶ 無料でダウンロード

まとめ

本記事では、Claude CodeのHooks機能について、2026年6月時点の最新仕様で解説しました。要点を改めて整理します。

• HooksはAIコーディングの「お願い」を「ルール」に変える仕組みで、設定したルールは決定論的に100%発火する点がプロンプト指示との決定的な違い
  
  

• 2026年6月時点で30種のライフサイクルイベントと5つのハンドラタイプ（command/http/mcp_tool/prompt/agent）が提供されており、社内Webhook連携やMCP資産との接続も実装しやすくなった
  
  

• 設定は6箇所の保存場所から選べる。個人ならローカル設定、チームはプロジェクト設定でGit共有、エンタープライズは管理ポリシーで統制という三段構えが定石
  
  

• 実用パターンの第一歩は自動フォーマットと機密ファイル保護。この2本だけでAIコーディングの体感が一段変わる
  
  

• Hooks自体に追加料金はかからず、Claude Codeのプラン枠内で完結。Plugin Marketplace経由で社内配布する運用が、2026年に入って広がっている

導入を検討するなら、まず ~/.claude/settings.json または .claude/settings.local.json に個人用フックを1〜2本書いて効果を体感し、その後に .claude/settings.json へ昇格させてチーム共有する流れが現実的です。組織レベルで導入する場合は、社内Marketplaceの構築まで含めて設計しておくと、長期運用での負荷が大きく下がります。

より詳しい仕様やイベント一覧については、公式ドキュメント（Hooksリファレンス（日本語）・Hooks reference（英語）、フックの使い始め）をあわせて参照してください。日本語版は反映タイミングにより英語版より追加イベントの掲載が遅れる場合があるため、最新仕様は英語版も併せて確認するのが安全です。