ClaudeのInference hooksとは — プロンプトを推論前に検査・遮断する仕組み

Inference hooksとは何か

Inference hooksは、Claude Enterprise組織が管理する全プロンプトを、推論が始まる前に自社のAIセキュリティサーバーへ転送し、許可か拒否かの判定を受けてから処理を進める機能です。ユーザーがプロンプトを送信すると、Anthropicは会話のトランスクリプトをHTTPS POSTで組織が指定したエンドポイントへ送り、判定(verdict)を待ちます。拒否と判定されたリクエストはモデルへ届きません。

セキュリティ・コンプライアンス部門がデータポリシーをインラインで強制するための機能で、判定ロジック自体は各組織またはそのセキュリティベンダーが実装します。フックはAnthropicのサーバー上、クライアントを離れてモデルが動く前の地点で走るため、ユーザーの端末に何かをインストールする必要がなく、対象となる全リクエストに一律で適用されます。Claude Enterprise組織向けのベータ機能で、有効化にはorganization:manage権限が要ります。

フックイベントはpromptの1種類のみが提供されています。統治対象の推論リクエストごとに、推論が始まる前に1回発火します。応答側の検査は将来のイベントとして計画段階にあります。

Inference hooksはどう動くか

判定の往復は次の4ステップで進みます。

1. ユーザーが統治対象の画面(claude.ai、Cowork、Claude Codeなど)でプロンプトを送信する
2. AnthropicがAIセキュリティサーバーへHTTPS POSTを送る。リクエストボディには会話のトランスクリプトが入り、組織が署名シークレットを生成した後は各リクエストがStandard Webhooks仕様に沿って署名される
3. AIセキュリティサーバーが内容を評価し、組織が設定した判定タイムアウト(既定5秒)以内にverdictを返す
4. allowなら推論はそのまま進む。denyならリクエストは拒否され、ユーザーには2つの部分からなるブロックメッセージが表示される — AIセキュリティサーバーがdeny_reasonフィールドで返した理由と、管理者が設定した定型メッセージ(連絡先や例外申請先など)だ

判定そのものは{"action": "allow"}のような小さなJSONオブジェクトです。AIセキュリティサーバーが受け取るのはユーザーに見えている範囲(トランスクリプトのテキスト、ツール呼び出しと結果、添付ファイルから抽出したテキスト)に限られ、生のファイルバイト列や画像バイト列、システムプロンプト、Anthropic内部のコンテキストは一切含まれません。Anthropicはプロンプトや応答の内容自体を保存せず、判定・タイムスタンプ・リクエストIDといったメタデータだけを記録します。

AIセキュリティサーバーが到達不能・エラー・タイムアウトのいずれかに陥った場合の扱いは、組織のfailure handling設定が決めます。ブロックするか、検査なしで通すかのどちらかです。

フックがどこに刺さるかは、単純な1往復の会話だけを想像すると見誤ります。公式ドキュメントが例に挙げるのは、CoworkからClaudeがO365のツールも呼び出すリクエストです。この例では検査点が2箇所あります。ユーザーのプロンプトが届いた地点と、O365ツールの実行結果が返ってきた地点です。どちらもAIセキュリティサーバーとの判定のやり取りを1回ずつ発生させます。つまりInference hooksは「ユーザーが最初に打った文章」だけでなく、エージェントがツールを呼んで得た結果も、次の推論に進む前に同じ仕組みで検査対象にします。ツール結果に機密情報が混ざって戻ってきた場合でも、そこで一度止められる設計です。

どんな用途に使われているか

公式ドキュメントは4つのユースケースを挙げています。

• データ損失防止(DLP): トランスクリプトをDLPスキャナーへ転送し、規制対象データや機密区分データを含むプロンプトを拒否する。最も一般的な導入パターン
• リアルタイムのトランスクリプトアーカイブ: 到着したトランスクリプトをその場でアーカイブし、常にallowを返す。Compliance APIをポーリングする代わりのプッシュ型の代替手段
• プロンプトのテレメトリ: 利用の瞬間にClaudeの使われ方を計測する
• ポリシーエンジン: モデルの許可リスト、プロジェクト単位の制限、業務時間内制御など、推論前に自組織のルールを強制する

Inference hooksとCompliance APIの違い

どちらもClaude Enterprise組織のセキュリティ・法務・コンプライアンス部門向けの機能ですが、作動するタイミングと呼び出す方向が逆です。

リクエストがモデルへ届く前に止めたいならInference hooks、起きたことを事後に監査したいならCompliance APIを使う住み分けです。実際の運用では、Inference hooksでインライン遮断を行いながら、遮断されなかった分をCompliance APIで事後追跡する組み合わせも成立します。設定変更や拒否・サーキットブレーカー作動の履歴はActivity Feedに記録され、監査ログの見方で扱っているEnterprise組織の変更履歴と同じ仕組みで追跡できます。

導入前に知っておくべき制限事項

公式ドキュメントが明記する制約は3つです。

• 添付ファイルはメタデータと抽出テキストで表現され、生のファイル・画像バイト列は送られません。そのため画像だけのコンテンツ(文書のスクリーンショットなど)は検査対象外になります
• 判定はallowかdenyの2択で、プロンプトの書き換えや部分的なマスキングはサポートされません
• Platform組織(Claude PlatformでのAPIアクセス)は対象外です

可用性の面でも押さえておくべき点があります。1つのフックが、claude.ai・Cowork・Claude Codeセッション全体を横断して統治します。ウェブ・デスクトップ・モバイルアプリ・CLIのどこで実行していても対象です。Amazon BedrockやGoogle Cloud経由のClaudeでは利用できません。会話タイトル生成のような付随的なリクエストは送られず、システムプロンプトやツール定義も対象に含まれません。音声モードもカバー対象外です。

「統治対象のリクエスト」という線引きも実務では重要です。検査に回るのはユーザーの会話を進める推論リクエストそのものだけで、その裏でClaudeが内部的に発行する補助的な呼び出しは対象外です。この切り分けのおかげで、AIセキュリティサーバー側は本来検査すべき会話の中身だけを見ればよく、システム側の雑多な呼び出しまで処理する必要がありません。判定を返すロジックを設計する側にとっては、対象範囲が狭く定義されていることそのものが実装コストを下げる要因になります。

設定にはorganization:manage権限が必要で、組み込みのAdmin・Owner・Primary ownerロールがこれを持ちます。Team/Enterpriseの権限ロール一覧ではUser・Admin・Owner・Primary ownerの違いを整理しています。

段階的な導入をどう設計すべきか

Inference hooksの設計で目を引くのは、初日から全員をブロックしなくてよいロールアウトの仕組みが最初から用意されている点です。Shadow modeは生トラフィックに対して判定だけを走らせブロックはしない状態、ロールアウト率は検査対象を選んだ割合に絞る仕組み、除外設定は特定ロールのメンバーを完全に対象外にする仕組みです。この3つを組み合わせれば、ポリシーが安定するまで実運用のトラフィックで検証してから、初めて強制に切り替えられます。

これは裏を返せば、Inference hooksを「入れただけ」では何も守られないということでもあります。組織単位で機能を有効化しても、Enforce verdictsは常に自動でオフになる設計です。エンドポイントを設定し、テストし、失敗時の挙動を選び、ようやく検査が始まります。管理者側の具体的な操作はShadow modeとサーキットブレーカーの設定手順で、AIセキュリティサーバー自体の実装はverdict応答とWebhook署名検証で扱っています。DLPスキャナーやポリシーエンジンをまだ持たない組織にとっては、この機能そのものより先に「何を拒否すべきか」の判定ロジックを用意する作業の方が重くなるはずです。

まとめ

Inference hooksは、Claude Enterprise組織がプロンプトを推論前に自社サーバーで検査し、その場でallow/denyを返せるようにする機能です。DLP・アーカイブ・テレメトリ・ポリシー強制の4用途で使われ、事後監査のCompliance APIとは作動タイミングと呼び出し方向が逆です。添付ファイルの生バイトは送られず、判定はallow/denyの2択のみ、Platform組織は対象外という制約があります。セキュリティ・コンプライアンス担当者が導入を検討するなら、まずShadow modeで実トラフィックの判定結果を確認してから強制に切り替える設計になっている点を押さえておくとよいでしょう。