推論が始まる前にプロンプトを検問する──Claude Enterprise向けInference hooksの仕組み

社内のセキュリティチームが「Claudeに何を投げているか」を事後にチェックするだけでなく、投げる前に止めたい——という要望に応える機能が、2026年8月5日にClaude Enterprise向けベータとして公開された。「Inference hooks」という名前のこの機能を、公式ドキュメント（platform.claude.com/docs/en/manage-claude/inference-hooks）と、実装向けの技術リファレンス（inference-hooks-endpoint）で確認した。

3行まとめ

1. フックは「プロンプト送信時」だけでなく、エージェントがツールを呼んだ後の「ツール結果が返ってきた時」にも発火する。公式の例（Cowork＋O365ツール）では、1回のやり取りの中で2回検問が入る図が示されている
2. 通信の失敗時の挙動は厳格に切り分けられている。接続失敗時のみ100ms後に1回だけ再試行し、タイムアウト・失敗はそのまま「deny」にはならず組織の失敗時設定に委ねられる。失敗が続くとサーキットブレーカーが作動し、手動で有効化し直すか、設定を変えないまま自動復旧が成立するまで検問が止まる
3. Anthropicはプロンプト・応答の中身自体を保存せず、判定結果・タイムスタンプ・リクエストIDといったメタデータのみを記録する、と明記されている

• ユーザーがプロンプトを送るたびに、Anthropicが組織のAIセキュリティサーバーへ会話トランスクリプトをHTTPS POSTし、許可（allow）／拒否（deny）の判定を待ってから推論を実行する
• サーバーが見るのはユーザーに見えているテキスト・ツール呼び出し・添付ファイルから抽出したテキストのみ。生の画像・ファイルバイト、システムプロンプトは一切送られない
• 現時点でフックされるイベントはprompt（推論前）のみ。応答側（レスポンス）を止める仕組みは「今後予定」とされ、まだ存在しない

仕組み：Anthropicのサーバー上で完結する検問

Inference hooksが動く場所がまず特徴的だ。ドキュメントは「フックはAnthropicのサーバー上で、クライアントを離れた後・モデルが動く前に実行されるため、ユーザーのデバイスに何もインストール・デプロイせずに、すべての対象リクエストへ一律に適用される」と説明している。つまり、Claude Codeでも、claude.aiのWeb版でも、Coworkでも、同じ1つのフックが組織のEnterprise契約全体に効く。

処理の流れは次の通りだ。

1. ユーザーが対象サーフェス上でプロンプトを送信
2. Anthropicが組織のAIセキュリティサーバーへHTTPS POST（本文に会話トランスクリプト）。署名はStandard Webhooks仕様に準拠し、組織が生成した署名鍵で検証できる
3. AIセキュリティサーバーが内容を評価し、既定5秒（組織が設定可能）以内に判定を返す
4. allowなら推論続行。denyならリクエストは拒否され、ユーザーには「AIセキュリティサーバーが返したdeny_reason」＋「管理者が設定した常設メッセージ（連絡先や例外申請先など）」が表示される。常設メッセージが未設定なら組み込みの既定文言が使われる

拒否は組織のActivity Feed（コンプライアンス機能）にも記録される。

公式ドキュメントには、Cowork上でO365ツールも呼ぶリクエストを例にした流れ図があり、実際には検問が1回だけでなく複数回入りうることが分かる。「フックされるのは図のステップ1（プロンプトが届いた時点）とステップ5（ツールの実行結果が返ってきた時点）で、それぞれがステップ2・6でAIセキュリティサーバーとの検証のやり取りを生む」という説明があり、エージェントがツールを呼んで結果を受け取るたびに、それも新たな推論リクエストとして検問対象になる、という理解になる。イベント種別としては今もpromptの1種類のみだが、1つの会話の中で発火するタイミングは1回とは限らない、という点は当初の確認より正確に理解できた。

検証結果（verdict）自体は小さなJSONオブジェクトで、{"action": "allow"}のようにアクションを返す形式だと明記されている。deny側にはユーザー向けの理由（deny_reason、最大500字）を含める。

サーバーが見えるもの・見えないもの

セキュリティ機能である以上、「何が送られるか」が最大の関心事になる。公式の記述はこうだ。

Your AI security server sees what the user sees: transcript text, tool calls and their results, and text extracted from attachments. It never receives raw file or image bytes, system prompts, or Anthropic-internal context.

（AIセキュリティサーバーが見るのは、ユーザーに見えているものと同じ：トランスクリプトのテキスト、ツール呼び出しとその結果、添付ファイルから抽出したテキスト。生のファイル・画像バイト、システムプロンプト、Anthropic内部のコンテキストは一切受け取らない）

この設計の裏返しとして、現在の制限事項に「添付はメタデータと抽出テキストのみで表現され、画像のみのコンテンツ（文書のスクリーンショットなど）は検査されない」とある。テキスト化できない画像内容をDLP（データ損失防止）ルールで捕まえたい場合、この機能単体では不十分だという点は押さえておく必要がある。また、判定は許可／拒否の二択で、プロンプトの書き換えや部分的な削除（レダクション）はサポートされていない。

サーバーが落ちていたら？ロールアウトの安全弁

自前サーバーが応答しない・エラーを返す・タイムアウトした場合の挙動は、組織側の「failure handling」設定で決まる。ブロックするか、検査なしで通すかを選べる。いきなり全社ブロックに倒すリスクを避けるための段階導入も用意されており、ドキュメントには「シャドーモード（実トラフィックの判定だけ観察し何もブロックしない）」「ロールアウト率（対象リクエストの一部だけ検査）」「除外（特定ロールのメンバーを対象外に）」の3つの調整弁があると記載されている。

通信の失敗時、Anthropicは「拒否」に倒さない

技術リファレンス「Develop an Inference hooks integration」を確認すると、通信の失敗時の挙動がかなり厳密に設計されていることが分かった。まず検証タイムアウトは1〜10,000ミリ秒の範囲で組織が設定でき、デフォルトは5,000ミリ秒（接続・TLSハンドシェイク・リクエスト・レスポンスの全体を含む予算）。再試行は「接続そのものに失敗した場合のみ」100ミリ秒後に1回だけ行われ、同じwebhook-idと署名を使い回す。AIセキュリティサーバーが一度でも応答すれば、その後の再試行は発生しない。

重要なのは、タイムアウト・500系エラー・パース不能なレスポンスなどの「webhook failure」が、それ自体ではdenyに変換されない、と明記されている点だ。

"A webhook failure never becomes a deny; instead, your organization's failure handling setting decides whether the affected request is blocked or proceeds without inspection."

（webhookの失敗が、それ自体でdenyになることはない。代わりに、組織の失敗時設定が、そのリクエストをブロックするか検査なしで通すかを決める）

失敗が続くと「サーキットブレーカー」が作動し、Anthropicは組織のサーバーへの問い合わせ自体を止め、以降の全リクエストに失敗時設定がそのまま適用される。復旧の経路は2つある。ひとつは管理者がサーバーを直してから「Enforce verdicts」を手動でオンに戻す方法。もうひとつは自動復旧で、公式ドキュメントは「The breaker can also reset on its own. Starting 10 minutes after the trip, Anthropic tests whether your server has recovered: at most about once per minute, one request from your organization's normal traffic is sent to your server for inspection」（ブレーカーは自前でも戻る。トリップの10分後から、多くても毎分1回、組織の通常トラフィックの中の1リクエストが検査のためにサーバーへ送られる）と説明している。正当な判定が返ればブレーカーは戻り、検問が再開する。ただし自動復旧が働くのは Inference hooks の設定をトリップ以降変更していない場合に限られる（2026年9月4日に公式ドキュメントを取得して確認）。作動のたびにActivity Feedへinference_hooks_circuit_breaker_trippedという記録が1件残るが、ブレーカーが作動している間はリクエストごとの個別記録は残らない、という仕様もある。

サーバーへのリクエストは160.79.106.0/24という送信元IPレンジから届くと明記されており、ファイアウォールでの許可リスト設定に使える。ただしドキュメントは「このブロックはInference hooks以外のAnthropicの送信トラフィックも含むため、署名検証の代わりにはならない」とも注記している。

管理画面での設定手順とエンドポイント要件

設定側の公式ドキュメント「Configure Inference hooks」を確認すると、有効化までの具体的な手順と要件も分かった。まず、AIセキュリティサーバーとして使えるエンドポイントには制約がある。ポート443のhttps://URLで、公開到達可能なホストである必要があり、リダイレクトなしで到達できることが求められる。ngrokのようなリバーストンネル型のサービスは、Anthropicのネットワークポリシーでブロックされるため使えず、「トンネル越しにテストせず、自分が管理するドメイン上にサーバーを立てること」と明記されている。

有効化は「off（未検査）」「shadow（判定は返すがブロックしない）」「enforcing（denyでブロック）」の3状態を順に進む設計で、組織単位で機能をオンにしただけでは検査は始まらず、必ず最後に管理者が明示的に「Enforce verdicts」をオンにする必要がある。エンドポイント設定時には「Test connection」機能があり、実際にテスト用のプロンプトを送ってallow/denyの判定が返るかを確認できる。この時点でAIセキュリティサーバー側がまだ「すべて拒否」がデフォルトの実装になっていた場合、有効化前にそれが判明する。署名用のシークレットは初回保存時に一度だけ画面に表示され、その後は取得できず、ローテーションのみ可能という運用になっている。

有効化後は、設定画面の監視パネルで「Endpoint status（Healthy/Tripped/Not enforcing/Not configured）」「Failures per minute（直近2分間の平均）」「Block rate（ロールアウト率100%未満の間のみ表示）」「Circuit breaker tripped」「Recent errors（タイムスタンプ・エラー種別・一行の理由のみ、リクエスト内容やエンドポイントURLは含まれない）」を確認できる。ただしこのパネルは「ベストエフォート」であり、Anthropic側がカウンターを読み取れない場合はエラーではなく「失敗ゼロ」と表示されるため、パネルが健全に見えることが即サーバーの健全性の証明にはならない、という注記もあった。

Compliance APIとの役割分担

似た機能に「Compliance API」があるが、動く方向とタイミングが逆だ。公式ドキュメントの比較表を確認すると、次のように整理されている。

両者は競合ではなく、リアルタイム遮断と事後監査の役割分担として使う設計だ。公式ドキュメントはInference hooksの具体的な用途として、①DLP（データ損失防止、「最も一般的な導入」と明記）、②リアルタイムのトランスクリプトアーカイブ（常にallowを返しつつ記録するだけの、Compliance APIをポーリングする代わりのプッシュ型手法）、③プロンプトのテレメトリ計測、④モデルの許可リスト・プロジェクト単位の制限・稼働時間帯の制御といったポリシーエンジン、の4つを挙げている。

対象範囲の制約

Inference hooksが効くのはClaude.ai・Cowork・Claude Codeを横断した「1つのフック」で、Amazon BedrockやGoogle Cloud経由のClaudeには効かない。プラットフォーム組織（Claude Platform経由のAPIアクセス）も対象外。会話タイトル生成のような付随的なリクエストや、システムプロンプト・ツール定義は送信対象に含まれず、ボイスモードもカバーされないと明記されている。導入にはorganization:manage権限（組み込みのAdmin・Owner・Primary owner、またはこの権限を持つカスタムロール）が必要だ。

AIセキュリティサーバーを自前で立てて検証したわけではない

• 本記事は公式ドキュメント（概要ページ・技術リファレンス）の記述を情報源としている。自分でAIセキュリティサーバーを模したエンドポイントを立てて検問の挙動を再現する作業は本記事の範囲外とした
• 「5秒のタイムアウトが実運用でどの程度厳しいか」「シャドーモードで観察した判定と実ブロック後の判定にどれだけ差が出るか」「サーキットブレーカーが実際にどれくらいの失敗回数・期間で作動するか」は、公式に書かれた仕様の域を出ない
• 署名検証（Standard Webhooks仕様に準拠）の具体的な実装手順、リクエストボディの完全なJSONスキーマ（promptフレームの全フィールド）までは、本記事では踏み込まなかった。技術リファレンスにはこれらの詳細な章があることは確認している
• この記事の執筆時点でQiitaには関連する実装寄りの記事が1本先行して存在することを確認しており、本記事は仕組み全体の整理に重点を置いている

関連記事: Claude Code / Claude APIの2026年8月の変更点まとめ / MCPとは / Claude Codeがエラーで動かない時の切り分け手順

感想・指摘はコメント欄へ。