社員が業務でClaudeを使うようになると、情報システム部門に一つ厄介な問いが立つ。「顧客のカード番号や未公開の決算数字を、誰かがうっかりプロンプトに貼っていないか」を、どこで止めるのか。これまでClaude側でこの手の検査ができたのは、各自のマシンで動くClaude Codeのクライアントフックだけだった。ブラウザのチャットやCoworkから送られる文章には手が届かない。
Anthropicが8月5日にベータ公開したinference hooksは、この検査の場所を「利用者の端末」から「Anthropicのサーバー」へ動かす仕組みだ。有効にすると、claude.ai・Cowork・Claude Codeのどこから来た推論リクエストも、モデルが動く直前に組織の指定したサーバーへ一度送られ、allow（通す）かdeny（弾く）の判定を待つ。端末に何かをインストールする必要はなく、組織で一度設定すれば全ての経路にかかる。
判定を出すのは自前のHTTPSサーバー
動きはシンプルなWebhookだ。ユーザーがプロンプトを送ると、AnthropicがあなたのAIセキュリティサーバーにHTTPS POSTを投げる。ボディには会話のトランスクリプトが入っていて、サーバーはそれを審査し、既定で5秒（設定範囲は1〜10000ms）以内に小さなJSONを返す。
{ "action": "allow" }
弾くときは理由を添える。deny_reasonはそのままユーザーに表示されるので、スキャナの内部コードではなく「何を消せばいいか」を書けとエンドポイントのドキュメントは釘を刺している。
{
"action": "deny",
"deny_reason": "このプロンプトにはカード情報が含まれている可能性があります。",
"reference_id": "scan_01HXPT4R9V"
}
ここで地味だが大事な設計判断がある。拒否であってもHTTPステータスは200を返さなければいけない。500やタイムアウトは「拒否」ではなく「Webhook失敗」として扱われ、判定そのものが成立しなかったことになる。失敗時にリクエストをブロックするか素通しするかは組織の設定で決まり、素通し（fail-open）にしていると検査を抜けたプロンプトがそのままモデルに届く。
送られてくるボディの中身は、ユーザーが画面で見ているものと同じだ。テキスト、ツール呼び出しとその結果、添付ファイルから抽出したテキスト。逆に、システムプロンプト、ツール定義、Claudeの内部推論、ファイルの生バイトは含まれない。だから画像だけのスクリーンショットに書かれた機密は検査できない、という限界もはっきり明記されている。リクエストはこんな形をしている。
{
"type": "prompt",
"actor": { "type": "user", "email_address": "alice@example.com" },
"source": { "application": "claude-ai" },
"model": "claude-sonnet-4-5",
"messages": [
{ "role": "user",
"content": [{ "type": "text", "text": "この決算資料を要約して" }] }
]
}
「ツールの応答も検査する」は、まだ半分本当
発表記事や一部の報道は「ClaudeがMCPやスキル、プラグイン経由でツールを呼ぶと、その応答がモデルに届く前に検査される」と書いている。ここは一次資料を突き合わせると、いまの実装より少し先の姿を語っている。
ドキュメントは明確だ。
Today the only hook event is
prompt, which fires once per governed inference request, before inference begins. Response-side enforcement is planned as a later event.
つまり現時点でフックが発火するイベントは「プロンプト送信時」の一種類だけ。ではなぜ「ツールの応答が検査される」と言えるかというと、過去のツール実行結果（tool_resultブロック）はトランスクリプトに積まれた状態で次の推論時に一緒に送られてくるからだ。前のターンでツールが返した中身も審査対象にはなる。ただし、ツールが結果を返したその瞬間に、モデルが読む前へ割り込んで止める専用イベントはまだない。マーケティングの言い回しと実装の粒度がずれている典型で、導入を検討するなら「今できること」はドキュメントのpromptイベントで測るのが正しい。
署名とタイムアウト、そして踏みやすい地雷
正当性の検証は独自方式ではなくStandard Webhooksに準拠している。webhook-id・webhook-timestamp・webhook-signatureの3ヘッダで、署名は{id}.{timestamp}.{生ボディ}に対するHMAC-SHA256。ドキュメントが警告しているハマりどころが二つあって、署名検証はJSONをパースする前の生バイトに対して行うこと、そして署名鍵（whsec_の後ろ）は標準base64でデコードすること。URLセーフなデコーダを使うと鍵バイトがずれて全滅する。リクエスト元IPは160.79.106.0/24に固定されているが、これは許可リストの補助であって署名検証の代わりにはならない、とも書かれている。
運用面で見落としやすい点を表にした。
| 項目 | 仕様 | 実務上の注意 |
|---|---|---|
| 判定タイムアウト | 既定5秒／1〜10000ms | 全リクエストに往復が上乗せされる。事前に負荷試験を |
| リトライ | 接続失敗時のみ100ms後に1回だけ | 応答が返った後は再送されない |
| ボディ上限 | 最大10MB | nginxのclient_max_body_size(既定1MB)やExpressのexpress.json()(既定100kB)だと弾かれ、fail-open設定なら未検査で通過 |
| 判定の種類 | allow / deny のみ | プロンプトの一部だけ伏せ字にする再編集はできない |
比較用に、Anthropicは既存のCompliance APIとの違いも整理している。inference hooksは「推論の前に、リアルタイムで通す/弾く」、Compliance APIは「起きたことを後から監査・エクスポートする」。前者は事前ゲート、後者は事後ログという役割分担だ。
現場のエンジニアとしてどう見るか
面白いのは、これがモデルの賢さではなくガバナンスの配管の話だという点だ。SaaSにデータを渡す前の関門を、ベンダーのサーバー側で標準化した。NetskopeやZscalerといった既存のDLP製品を裏側にそのまま挿せる設計で、Webhookという枯れた形に落とし込んだのは素直に良い判断だと思う。
一方で、全リクエストに同期的な往復が挟まる以上、あなたのサーバーの応答速度がそのまま組織全員の体感レイテンシになる。5秒待たされて弾かれるくらいなら、と現場が別ツールへ逃げる未来も容易に想像できる。10MBの本文をデフォルト設定のリバースプロキシが黙って落とし、fail-openと組み合わさって検査を素通りさせる事故も、いかにも起きそうだ。allow/denyの二択で伏せ字が使えないのも、運用してみると硬すぎると感じる場面が出るだろう。導入するなら、まずshadowモード（判定を観測するだけでブロックしない）で本番トラフィックの分布を眺め、拒否率とレイテンシを測ってからEnforce verdictsを入れる、という順序を強く勧めたい。なお対象はClaude Enterpriseのベータで、Amazon BedrockやGoogle Cloud経由は対象外、設定にはorganization:manage権限が要る。