この記事でわかること
- Claude Code Hooks（AI操作の前後に差し込まれるゲート・チェックポイント）が「内部統制の実装手段」になる理由
- AI事業者ガイドラインv1.2 が要求する「誰が決めたか・誰が見ていたか・誰が止めるか」を Hooks でどう具体化するか
- 自社で AI Agent ガバナンスを小さく立ち上げる3ステップ（棚卸し → 1つ導入 → 振り返って展開）
Claude Code Hooks とは何か
Claude Code Hooks は、Anthropic が提供する AI コーディングツール Claude Code に組み込まれた、ライフサイクル制御の仕組みです。公式ドキュメントは Hooks を 「Claude Code のライフサイクルの特定の時点で自動実行される、ユーザー定義のシェルコマンド・HTTP エンドポイント・LLM プロンプト」 と定義しています。
仕組みはシンプルです。AI Agent がツールを呼び出したり、ユーザーがプロンプトを送信したり、セッションが開始されたりする「特定の時点」で、自社が用意したスクリプトや外部サービスを差し込めます。差し込まれた処理は、AI の動作を 許可・拒否・修正 したり、監査ログを残したり、追加のコンテキストを注入したりできます。
Hooks の発火点は、AI Agent の活動を「外部にアクションを取る瞬間」「利用者から指示を受けた瞬間」「セッションの境界」の3層で押さえられるよう配置されています。
- AI が外部にアクションを取る前後: PreToolUse Hook がファイル編集・コマンド実行・外部API呼び出しの直前に介入し、PostToolUse Hook が実行結果を直後に捕捉する
- 利用者が指示を出した瞬間: UserPromptSubmit Hook が、利用者の指示そのものを記録・改変できる
- セッションの境界: SessionStart / SessionEnd / Stop Hook が、セッション開始時の統制ルール注入や、終了・応答完了時のまとめ検査を担う
これらの介入ルールは、組織のガバナンスポリシーを宣言する1枚のテキストファイル（.claude/settings.json）に集約され、開発チーム全員へ自動的に適用されます。誰が・いつ・どの統制を追加したかという変更履歴も自動で残るため、規制対応や内部監査の説明資料としてそのまま流用できます。
なぜ内部統制の実装手段なのか
よくある見方： Hooks は開発者の生産性を上げる便利機能である 実態は： Hooks は AI 操作の前後に判定ゲートを差し込む、攻めるための内部統制の実装手段である
この読み替えが効くのは、Hooks の発火点が 「AI が外部環境にアクションを取る瞬間」 と一致しているからです。本番システムへの接続、機密データの取り扱い、外部APIの呼び出し——内部統制が「ここを通すか判定したい」と求める瞬間に、Hooks は自動的に判定ゲートを開きます。判定ロジックを宣言しておけば、それ以外の領域では AI Agent を業務の深い層まで踏み込ませられます。
Hooks のこの仕組みは、内部統制の言葉に翻訳すると次の3つの機能と対応します。
- 事前統制（プリベンティブ・コントロール）: PreToolUse で危険操作を遮断し、許可された操作だけを通す
- 発見統制（ディテクティブ・コントロール）: PostToolUse で実行結果をログに残し、後から検査できるようにする
- 是正統制（コレクティブ・コントロール）: Stop で最終検査を走らせ、想定外の変更を差し戻す
J-SOX（日本版企業改革法に基づく財務報告内部統制）や ISO 27001（情報セキュリティの国際規格）が要求してきた統制の3類型を、AI Agent の実行ライフサイクルに沿って ファイルレベルで宣言的に具体化できる 標準インターフェースとして、Hooks は注目されています。攻めの AI 活用と統制の両立は、こうした実装基盤が揃ったことで、組織の意思決定の早さに従う形で進められるようになりました。
v1.2 が要求する責任設計との接続
2026年3月、総務省・経済産業省は AI事業者ガイドライン第1.2版を公表しました。詳細は AI事業者ガイドラインv1.2 が示した"AI Agent責任者"の議論 に整理していますが、論点は3つの問いに集約されます。
- 誰が決めたのか
- 誰が見ていたのか
- 誰が止めるのか
ガイドラインはこの3つの問いに 「組織として答えよ」 と要求するところまでで、答え方そのものは各社の設計に委ねられています。Hooks は、3つの問いを 実装レイヤから補強する 道具として読めます。
1. 「誰が決めたのか」を UserPromptSubmit で記録する
UserPromptSubmit Hook を使えば、「どの利用者が・どんな指示を出したか」をすべて社内の監査基盤に記録できます。プロンプトの内容を改変したり、業務外の指示を差し戻したりすることも可能です。記録が残ることで、AI を使った判断の起点を組織として説明できるようになり、利用者にもより踏み込んだ使い方を任せられます。
2. 「誰が見ていたのか」を PostToolUse で監査基盤に流す
PostToolUse Hook で、AI が実行したコマンド・編集したファイル・連携した外部システムを逐一外部のログ基盤（SIEM＝セキュリティ監視基盤、データレイク＝横断的なログ集約基盤、など）に転送できます。監視責任者は、自分のダッシュボードで AI Agent の挙動を継続的に追えるようになり、リスクの兆候を早期に拾って次の活用判断に反映できます。
3. 「誰が止めるのか」を PreToolUse のキルスイッチで担保する
PreToolUse Hook は、事実上の キルスイッチ として機能します。ガイドライン別添でいう緊急停止権限を、特定の AI 操作ごとに分散して持たせる設計が可能です。たとえば「本番データベースへの書き込み」だけは外部の承認サーバーへ HTTP 経由で問い合わせ、業務責任者の応答を待つ、という運用も Hooks の HTTP ハンドラで実装できます。止める仕掛けが整うほど、それ以外の領域では AI Agent に思い切った行動を任せられます。
ガイドラインが指す「責任設計」は、組織図と権限規程の見直しだけでは完結しません。AI が実際にアクションを取る瞬間に、その権限規程が機能する仕掛けが要る——その仕掛けを、Hooks は標準化されたインターフェースで提供しています。
自社で実装に踏み出す3つのステップ
AI事業者ガイドラインv1.2 が継承するアジャイル・ガバナンス（改善を重ねながら統制の仕組みを更新し続ける考え方）の精神に沿うと、Hooks の導入も「最初から全体を設計しよう」とせず、現場で動く統制を一つずつ増やしていく順序が現実的です。
1. 現実的に組み込める統制ポイントを棚卸しする
最初のステップは、「自社の AI Agent 運用のうち、どの操作なら今すぐ Hook で押さえられそうか」を棚卸しすることです。
全社の内部統制を一気に再設計する必要はありません。既存の業務プロセスのうち「ここで AI が暴走したら困る」と直感的に言える操作を3〜5個ほどリストアップするところから始めれば十分です。本番DBへの書き込み、機密ディレクトリへの編集、外部送信を伴うコマンド——止めたい操作と止めたい理由を、業務側の言葉でメモしておきます。
業務部門・情報システム部門・内部監査部門の3者で短時間ですり合わせ、「最初の1〜2個」だけ Hook の対象に絞り込むのが、立ち上げを軽くするコツです。
2. 小さく一つから導入し、運用に乗せる
第二のステップは、棚卸ししたリストから最も実害が大きく・かつ実装が単純な1つを選び、まず Hook で押さえることです。
最初は PreToolUse で単純なブロックルールを一つ追加するだけでよく、複雑なロジックを書き込む必要はありません。あわせて運用側の最低限の決まりも一つだけ用意します。「この設定を変更したい場合は誰の承認が必要か」を1行決めておけば、設定変更の記録と承認証跡が自動的に積み上がる足場ができます。
統制が一つ動き出すと、「ここまで縛れているなら、こちらの活用は任せても大丈夫」という会話が業務側と始まります。守りの強化が、攻めの選択肢を広げる流れへ繋がる第一歩がここです。
3. 学んだことを次の統制ポイントへ展開する
第三のステップは、導入した Hook の運用実績を振り返り、棚卸ししたリストの次の候補へ展開することです。
振り返りは月次の短時間ミーティングで十分です。「何回ブロックしたか」「過剰なブロックで業務が止まらなかったか」「想定外の通過がなかったか」の3点を確認すれば、Hook 設定をどう微調整するかが見えてきます。Hook の運用が定着してきたら、管理者が承認した Hook 群だけを全社へ強制適用する運用へ段階的に移行できます。
組織として AI に与えてよい権限の境界を、テキストファイルで宣言的に定義できる——これは、従来のアクセス制御の延長として、AI Agent の挙動範囲まで一貫した透明性で扱えるようになる転換点です。統制ポイントが増えるほど、AI に任せられる業務領域も広がる——これが「攻めるための内部統制」の実装イメージです。
アクションチェックリスト
| アクション | 内容 |
|---|---|
| 統制ポイントの棚卸し | 自社の AI Agent 運用で「動かす前に判定したい」操作を3〜5個リストアップする |
| 最初の1つを Hooks で実装 | リストから最も実害の大きい1つを選び、PreToolUse の単純なブロックルールを .claude/settings.json に追加する |
| 月次振り返りで次へ展開 | ブロック・通過実績を業務部門・監査担当と振り返り、次の統制ポイントへ Hook を広げる |
自社の AI Agent 運用に内部統制をどう組み込むか。既存の統制プロセスや権限規程との接続論点を整理し、攻めの AI 活用と両立する運用に乗せるところまで個別に支援します。
あわせて読みたい
FAQ
Q: Hooks は Claude Code 以外の AI Agent でも同じ考え方で使えますか？
Hooks という名前と仕様は Claude Code 固有のものです。ただし「AI Agent のライフサイクルの特定時点に外部処理を差し込む」という設計思想は、他社の AI Agent プラットフォームでも同等の機能が用意されつつあります（プロンプト前処理・ツール呼び出し前フィルタ・実行後ログ転送など）。自社で AI Agent ガバナンスを設計するときは、「使うプラットフォームが Hooks 相当の仕組みを公式に提供しているか」 を選定基準の一つに加える視点が有効です。
Q: 既存の J-SOX や ISO 27001 の統制プロセスと Hooks 運用はどう接続しますか？
既存の統制プロセスを置き換えるのではなく、統制対象に AI Agent の自律アクションを追加する 形で接続するのが現実的です。J-SOX のキーコントロール一覧に「Hooks による事前ブロックが正常に機能していること」を統制項目として追加し、PostToolUse Hook が出力するログを内部監査部門のサンプリング対象に含める——という運用が、既存の統制資産を生かしながら AI Agent 特有の論点を上乗せする道筋になります。Hooks 設定ファイル自体の変更管理を、既存の構成管理プロセスに組み込む発想も同じ流れです。
Q: 中小企業でも Hooks 運用を始める価値はありますか？
あります。Hooks 設定はテキストファイル1枚から始められるため、立ち上げの初期コストは低く抑えられます。「本番データベースへの書き込みは常にブロックする」「機密ファイルを含むディレクトリへの操作はログに残す」といった最低限のルールを .claude/settings.json に書き込むだけでも、AI Agent 導入時の事故リスクを大きく下げられます。組織規模に応じて、承認体制や監査基盤との接続を段階的に整えていく順序で問題ありません。