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

Inference hooksとは何か

Inference hooksは、Claude Enterprise組織の統治対象プロンプトを、推論の前に自社のAIセキュリティサーバーへ転送する機能です。許可か拒否かの判定を受けてから処理が進み、拒否と判定されたリクエストはモデルへ届きません。

AIセキュリティサーバーとは、組織またはそのセキュリティベンダーが運用するHTTPSサービスです。判定ロジックは各組織が実装し、Anthropic側は会話のトランスクリプトを送って判定を待つだけです。

フックはAnthropicのサーバー上で、クライアントを離れてモデルが動く前の地点で走ります。ユーザーの端末に何かを配る必要がなく、対象リクエストには一律で適用されます。

フックイベントは2種類です。promptは統治対象の推論リクエストごとに、推論の前に1回発火します。tool_callは、Claudeの応答にツール呼び出しが含まれるとき、実行の前に発火します。組織が「Validate tool calls」をオンにしている場合だけで、新しい設定では初期状態でオンです。

Claude Codeのhooksとは何が違うか

名前は似ていますが、別の仕組みです。Claude Codeのhooksは、各自の環境で動くシェルコマンドやHTTPエンドポイントなどを、セッションの節目に呼び出す機能です。設定した人の範囲で効きます。

Inference hooksは、Anthropicのサーバーが推論の前に組織のAIセキュリティサーバーを呼びます。端末に何も入れず、Claude Enterprise組織の統治対象リクエストすべてに効き、設定できるのはOwnerとPrimary ownerだけです。Claude Codeのセッションも統治対象の1つで、開発者個人の設定では外せません。

送信ボタンを押してから応答までに何が起きるか

判定の往復は4ステップです。

判定そのものは{"action": "allow"}のような小さなJSONです。拒否の場合は、次の形で理由と任意のreference_idを返します。

{
  "action": "deny",
  "deny_reason": "カード番号を含むため送信できません。該当部分を削除してください。",
  "reference_id": "scan_01HXPT4R9V"
}

deny_reasonは500字を超えると切り詰められます。reference_idは50字以内の自社用の識別子で、ユーザーには表示されず、拒否の記録(inference_hooks_request_denied)に残ります。自社システムの検査記録とActivity Feedの拒否記録を突き合わせる鍵に使えます。

拒否を知らせるためにエラーステータスを返してはいけません。HTTP 200以外、または解釈できない本文はすべて「Webhook失敗」で、拒否として扱われません。その場合の挙動は組織の失敗時設定が決めます(後述)。

ツールの実行結果も検査点になる

フックが刺さる場所は、1往復の会話だけを想像すると見誤ります。公式ドキュメントの例は、CoworkからClaudeがO365のツールも呼ぶリクエストです。検査点はプロンプトが届いた地点、Claudeがツールを呼ぶ地点、ツールの結果が返ってきた地点の3つです。ツール呼び出しの地点が検査されるのは「Validate tool calls」がオンのときで、1回の応答に含まれる呼び出しは1つの判定でまとめて扱われます。

エージェントがツールを呼んで得た結果も、次の推論に進む前に同じ仕組みで検査されます。ツール結果に機密情報が混ざって戻ってきても、そこで一度止められます。

実際にサーバーへ届くトランスクリプトでは、ツール結果はuserロールのtool_resultブロックとして現れます。tool_nameも付くので、特定のツールの結果だけを条件にする判定も書けます。

何が検査され、何が検査されないか

AIセキュリティサーバーが受け取るのは、ユーザーに見えている範囲です。テキスト、ツール呼び出しとその結果、添付ファイルから抽出したテキストが含まれます。

含まれないものは次のとおりです。

• 生のファイルバイト列と画像バイト列(添付はメタデータと抽出テキストだけ)
• システムプロンプトとツール定義
• Anthropic内部のコンテキストとClaudeの隠れた推論
• 会話タイトル生成のような付随的リクエスト

音声モードのプロンプトとツール呼び出しはサーバーに送られますが、ごく一部のツール呼び出しは送られません。拒否された場合も通話は汎用エラーで終わることが多く、deny_reasonは表示されません。音声の統制をフック1本に頼らないのが公式の注意です。

画像だけのコンテンツ、たとえば文書のスクリーンショットは検査されません。画像の添付はfile_nameとtextがnullのブロックで届きます。DLPの網羅性を語るときは、この穴を前提にします。

判定はallowかdenyの2択です。プロンプトの書き換えや部分的なマスキングはできません。Platform組織(Claude PlatformでのAPIアクセス)は対象外です。

1つのフックが、claude.ai・Cowork・Claude Code・Claude Tagのセッションを横断して統治します。ウェブ、デスクトップ、モバイル、CLI、Slackのどこで動かしても対象です。

トランスクリプトは切り詰められずに届きます。長い会話に大きな添付が付くと、リクエストボディも大きくなります。プロトコル上の上限は64 MiBで、実際にはコンテキストウィンドウのおかげで10 MB程度に収まります。

ここに落とし穴があります。nginxのclient_max_body_sizeの既定値は1 MB、Expressのexpress.json()は100 kBです。受け側がボディを拒否するとWebhook失敗になり、失敗時に「通す」設定なら、大きなプロンプトほど未検査でモデルに届く可能性があります。

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

公式ドキュメントが挙げる用途は4つです。

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

アーカイブ用途では、判定を先に返してから保存する構成が勧められています。自社サーバーの保存処理がユーザーの待ち時間に乗らないためです。

Compliance APIとの使い分け

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

リクエストがモデルへ届く前に止めたいならInference hooks、起きたことを事後に監査したいならCompliance APIです。両方を併用して、インライン遮断と事後追跡を分担させる構成も成立します。

フックの設定変更・拒否・サーキットブレーカーの作動はActivity Feedに記録されます。Feedの扱いは監査ログの見方にあります。ただしサーキットブレーカー作動の記録はCompliance APIが有効な組織だけで残ります。

拒否されたユーザーは会話をどう続けるか

見落とされやすいのが拒否後の挙動です。リクエストには会話の全体が含まれるので、拒否された発言は以降のすべての送信にも含まれます。サーバーがトランスクリプト全体を評価する実装なら、後続のリクエストも拒否され続けます。

続けるには、拒否された内容を、アプリが次に送る内容から取り除きます。Claude Codeが再読み込みするファイルも対象です。方法は画面ごとに違います。

• claude.ai(Claude Desktopとモバイルを含む): 拒否された発言、またはそれ以前の発言を編集します。訂正文を新しい発言として送ってもだめです。ウェブとDesktopでは、編集すると添付ファイルが再送されるため、添付を外す操作が要ります。新しいチャットでも続けられます
• Claude Code: /rewindで内容が最初に入ったプロンプトを選びます。求められたら「Restore conversation」を選び、入力欄に戻ったプロンプトを編集するか消します。/clearなら最初からやり直せます
• Cowork: 最新の発言なら編集します。ファイルや過去の発言に原因がある場合は「New task」を選びます。「Restart from here」は発言をそのまま再送するので、拒否は解消しません
• Claude Tag: Slackで該当発言を編集(返信なら削除)してから、@Claude !restartを単独で送ります

claude.aiには別の注意点があります。フックが拒否したメッセージも会話に残ります。フックのシステム自体はプロンプトや応答の本文を保存せず、判定・タイムスタンプ・リクエストIDなどのメタデータだけを持ちます。会話本文は各Claude製品が自分のデータ保持ルールで保管します。

管理者がdeny_reasonを書く側に立つなら、何を消せば通るのかを伝える文面にしておくと、このやり取りが短くなります。公式ドキュメントも、スキャナーのコードだけを返さず、削除すべき内容の種類を書くよう勧めています。

初日から全員を止めない3つの状態

Inference hooksには、段階的に強制へ進めるための仕組みが最初から入っています。設定画面の「Enforce verdicts」と「Mode」の組み合わせで、3つの状態が決まります。

Shadow modeでは、サーバーが拒否した場合も、到達できなかった場合も、すべてのリクエストがモデルに進みます。実トラフィックで判定のブレを確認してから、強制へ切り替える使い方です。

三つ目の調整軸がロールアウト率です。「Requests inspected (%)」を0〜100で設定し、100なら全件、0なら検査オフです。リクエストごとの抽選は会話のターン単位で1回なので、1つの会話が部分的に検査されることもあります。抽選から外れたリクエストは、失敗時設定が「Block the request」でも検査なしで通ります。

除外設定では、特定ロールのメンバーを対象外にできます。選べるのは組織が作成したカスタムロールだけで、組み込みロールは選べません。除外リストの変更にはidentity management権限が必要です。除外が効くのはユーザーの対話セッションまでです。マシン認証情報で動くトラフィックは常に検査されます。

「入れただけでは何も守られない」点にも注意が要ります。「Allow for your organization」をオンにしても、「Enforce verdicts」は必ずオフに戻ります。エンドポイントを保存し、接続テストを通し、最後に「Enforce verdicts」をオンにして初めて検査が始まります。反映までは1分ほどかかり、処理中のリクエストは古い設定のまま終わります。

具体的な操作はShadow modeとサーキットブレーカーの設定手順に、AIセキュリティサーバー側の実装はverdict応答とWebhook署名検証にあります。

サーバーが落ちたとき、ブロックか通過か

AIセキュリティサーバーが到達不能・エラー・タイムアウトに陥ったとき、リクエストを止めるか通すかは、失敗時設定が決めます。判定タイムアウトは1〜10,000msで、既定は5,000msです。タイムアウト枠は接続・TLS・リクエスト・応答の全体にかかります。

初回保存時の既定は「Allow the request」と5,000msです。何も変えないままオンにすると、フェイルオープンで始まります。DLPとして使う組織は、この既定値を意識して選び直す必要があります。

AIセキュリティサーバー側に起因する失敗が続くと、サーキットブレーカーが作動します。Anthropicはサーバーへの送信をやめ、失敗時設定を全リクエストに適用します。「Block the request」なら、ブレーカーが戻るまで組織の全員が止まります。作動すると、管理者にはclaude.aiの通知センターで知らせが届きます。

復旧は2通りです。サーバーを直してから「Enforce verdicts」をオンに戻して手動でリセットするか、自動復旧を待ちます。自動復旧は作動の10分後から、多くても1分に1回程度、合成のテストリクエスト(source.applicationがconfig-test)を送って確認します。有効な判定が返れば、allowでもdenyでもブレーカーが戻ります。

設定を1つでも変えると、自動復旧は止まります。署名シークレットのローテーションも含まれます。Anthropicが再送するのは接続の確立に失敗したときの1回だけで、100ms後です。応答が返った後の再送はありません。

遅延にも注意が要ります。強制中は、サーバーの往復時間が組織内のすべての統治対象リクエストに上乗せされます。大きな組織へ広げる前に、負荷試験を済ませておくのが無難です。

導入前に確認する前提条件

設定画面は、claude.aiの「Organization settings」の「Data and privacy」にあります。権限はorganization:manageで、持つのはOwnerとPrimary ownerだけです。Adminロールでは設定できません。ロールごとの違いは権限ロール一覧にまとまっています。

エンドポイントには次の条件があります。

• ポート443のhttps://URLで、公開ルーティング可能なホストにあること
• 証明書が公開CAの信頼ストアで検証できること
• リダイレクトなしで応答すること(リダイレクトは失敗扱い)
• ngrokなどのトンネルサービスは使えない(Anthropicのネットワークポリシーが遮断する)

送信元IPは160.79.106.0/24で、Anthropicの公開アウトバウンドIP範囲に含まれます。許可リストを作る場合は、同じページのインバウンド範囲ではなくアウトバウンド側を許可します。ただしこのブロックにはInference hooks以外のAnthropic発のトラフィックも載るので、署名検証の代わりにはなりません。

認証用に、固定のカスタムヘッダーを最大16個まで付けられます。値は暗号化して保存され、保存後は名前しか表示されません。1つ変えると、全ヘッダーの値の再入力が必要です。エンドポイントのURLを変えると、保存済みの値はすべて消えます。認証情報が新しい宛先へ送られないようにするためです。

「Test connection」は、フォームに入っている現在のURLとヘッダーに対して合成プロンプトを送ります。結果にはallowとdenyのどちらが返ったかが出ます。何でも拒否する初期実装を、強制の前に見つけられます。

まとめ

Inference hooksは、止める権限を自社のサーバーに持たせる代わりに、そのサーバーの可用性と既定値の選び方まで運用の責任に入れる機能です。判定ロジックの前に、失敗時設定、ボディサイズの上限、画像だけの添付が素通りする点を決めておきます。段階導入にはShadow modeが向きます。