Claude Inference hooks（推論フック）とは｜社内DLPと3つの死角

「会社に強制されるAI利用に抵抗する最良の手段は、機密資料をAIに食わせることのセキュリティ懸念を持ち出すことだ」。2026年7月30日、Aftermathが匿名の労働者たちに聞き取ったAI強制利用への抵抗術のひとつだ（Aftermath, Luke Plunkett, 2026年7月30日。以下、英語ソースからの引用はいずれも筆者訳）。同じ記事には「実際の作業は自分でやったうえで、意味のない長々としたプロンプトを大量に作ってダッシュボードの利用実績だけ立てた」という証言も並ぶ。推奨できる話ではないが、現場の温度としては生々しい。

その「セキュリティ懸念」という盾が通用しなくなる方向の一手が打たれた。2026年8月5日、AnthropicはClaude Enterprise向けにInference hooks（推論フック）のベータ提供を開始した（Anthropic, 2026年8月5日）。社員が送信したプロンプトを、モデルに届く前に会社のサーバーが検査して通すか止めるかを決める仕組みだ。メールやファイル共有で使われてきたDLP（Data Loss Prevention、情報漏洩防止）の関門を、AIへの入力の直前に置いたと考えるとわかりやすい。

先に断っておくと、自分はClaude Enterprise契約者ではないので、この機能を実際に動かして試したわけではない。以下は公式ドキュメント3ページと発表記事を読み込んだうえでの整理だ。ただ、公開されている仕様がかなり詳細だったので、記事や要約では落ちている実装上の落とし穴がいくつも見えた。

個人契約のPro・Maxは対象外だが、「自分は個人契約だから無関係」とも言い切れない。客先常駐や業務委託でクライアントのEnterpriseアカウントを使っているなら、そこで打ったプロンプトはクライアントのサーバーを経由することになる。Claude Codeが社内DBやツールから引いてきた戻り値まで含めてだ。

Inference hooks（推論フック）とは: 「後から監査」から「送る前に止める」へ

Anthropicは2026年5月にCompliance APIの統合パートナー28社を発表している。あちらは事後の可視化だった。Compliance API 28社統合の記事で書いたとおり、CrowdStrikeやOktaのダッシュボードにClaudeの会話ログを流し込む設計だ。

その限界については、統合パートナーのProofpoint自身が自社ブログで言及している。2026年5月のCompliance API連携では可視化はできたが「機密データは依然として送信され、モデルに処理されていた」と書いている（Proofpoint, 2026年8月5日）。漏れたあとで気づく仕組みでしかなかったわけだ。

Inference hooksはその手前に割り込む。両者の違いは公式ドキュメントの比較表がわかりやすい。

	Inference hooks	Compliance API
作用するタイミング	推論の実行前（インライン）	事後
やること	リクエストごとに許可/拒否	会話・ファイル・ユーザーの取得と監査
通信の向き	Anthropicが組織のサーバーを呼ぶ	組織側がAnthropicのAPIを呼ぶ

出典: Claude Platform Docs, Inference hooks

肝は「フックがAnthropic側のサーバーで動く」点だ。クライアント端末に何かをインストールする必要がない。つまりCLIのClaude Codeだろうがデスクトップアプリだろうがブラウザだろうが、1つの設定で等しくかかる。

Inference hooksの仕組み: 5秒以内に「通す／止める」をJSON 1個で返す

ここは実装担当向けの節だ。導入可否を判断したいだけなら、下の表の数字だけ拾えばいい。

技術的にはシンプルなWebhook（あるイベントが起きたときに指定URLへ自動でデータをPOSTする仕組み）だ。ユーザーがプロンプトを送ると、Anthropicが組織の指定したHTTPSエンドポイントへPOSTを投げる。ボディには会話のトランスクリプトが入り、Standard Webhooks仕様のHMAC-SHA256署名（共有鍵で計算する改ざん検知用の署名。検証することで確かにAnthropicから来たと確認できる）が付く。ヘッダはwebhook-id / webhook-timestamp / webhook-signatureの3つだ。

サーバー側が返すのはこれだけでいい。

{ "action": "allow" }

止めるときはこうなる。

{
  "action": "deny",
  "deny_reason": "このプロンプトにはカード情報が含まれている可能性があります。",
  "reference_id": "scan_01HXPT4R9V"
}

deny_reasonはそのままユーザーに表示される文面で、上限500文字。reference_idはActivity Feed（組織の監査ログ画面）のinference_hooks_request_deniedイベントに記録され、自社ログとの突合に使う。ユーザーには見えない。

運用面のパラメータは公式ドキュメントに明記されている（Claude Platform Docs, Develop an integration）。

項目	値
判定タイムアウト	1〜10,000ms（既定5,000ms、接続・TLS・往復すべて込み）
リトライ	接続失敗時のみ100ms後に1回だけ。応答が返った時点で再送なし
リクエストボディ上限	10MB（トランスクリプトは切り詰めずに送られる）
レスポンス読み取り上限	64KiB、圧縮不可、リダイレクト追従なし
送信元IP	160.79.106.0/24
判定の種類	allow / deny の二値のみ

HTTP 200以外、あるいはパースできないボディは「拒否」ではなく「Webhook失敗」として扱われる。エラーステータスでdenyを表現する実装は事故のもとだ。

送られるもの・送られないものの線引きも明確だ。

• 送られる: 会話本文、ツール呼び出しとその結果（tool_use / tool_result）、添付ファイルから抽出したテキスト、ファイル名・MIMEタイプ・サイズ、ユーザーIDとメールアドレス、モデル名
• 送られない: システムプロンプト、ツール定義、Claudeの内部推論、ファイルや画像の生バイト、Anthropic内部のコンテキスト、会話タイトルの自動生成リクエスト

ツール結果がtool_resultブロックとして検査対象に入る点は実務上大きい。MCP実践ガイドで扱ったような社内DBへの接続を組んでいる場合、その戻り値も会社のサーバーを通る計算になる（ドキュメントはMCPに個別言及していないが、ツール結果一般の扱いとしてそう読める）。

死角1: 初期設定は「検査サーバーが落ちたら素通り」

ここからが要注意だ。

失敗時の扱いにはBlock the request（fail closed、判定が取れないなら止める）とAllow the request（fail open、判定が取れなくても通す）の2択があり、公式ドキュメントには「初回保存時の既定値はAllow the requestと5,000ms」と書かれている（Claude Platform Docs, Configure Inference hooks）。検査サーバーが落ちていれば素通りする側に倒れるのが初期状態だ。

そこに10MBの上限が効いてくる。トランスクリプトは切り詰められずに送られるため、長い会話に大きな添付が乗ればボディはあっさり数MBに達する。ドキュメントはご丁寧にこう警告している。nginxのclient_max_body_sizeは既定1MB、Expressのexpress.json()は既定100kB。上限を超えたボディの拒否はWebhook失敗としてカウントされ、fail open設定なら「その大きいプロンプトほど検査されずにモデルへ届く」。

さらにロールアウト率の挙動も同じ方向を向いている。Requests inspected (%)を100未満に設定すると、抽選から漏れたリクエストは検査されずに通る。しかもこれは失敗時の扱いをBlock the requestにしていても変わらない。

失敗が続けばサーキットブレーカー（連続エラー時に自動で回路を切る安全装置）が作動し、管理者が手動で解除するまで検査そのものが止まる。fail openのままならその停止期間中は全社のプロンプトが無検査で通る。「一度も止まらない前提」ではなく「止まったときに誰がどれくらいで気づくか」で設計する必要がある。

死角2: 画像DLPは効かない。スクリーンショットは検査されない

公式ドキュメントの「Current limitations」に率直な但し書きがある。

添付ファイルはメタデータと抽出テキストとして表現され、生バイトは送信されない。したがって「画像のみのコンテンツ、たとえば文書のスクリーンショットは検査されない」。

顧客リストをExcelで添付すれば抽出テキストが検査対象になるが、同じ画面をスクショして貼れば検査を通り抜ける。悪意がなくても起こる。エラー画面をスクショで貼るのは開発者の日常動作だ。

判定が二値である点も同じ系統の制約だ。書き換えやマスキングはサポートされていない。「この行だけ伏せて通す」ができないので、ポリシーを厳しくすれば正当な業務まで止まり、緩めれば漏れる。

そして現時点でフックが発火するイベントはpromptだけだ。ツール結果は次のプロンプトフレームにtool_resultとして乗るので検査自体は受ける。だが独立した応答側イベント、つまりモデルの出力そのものを止める機能は、公式ドキュメント上「後日のイベントとして計画中」の段階にある（Anthropic, 2026年8月5日）。

死角3: API・Bedrock・音声モードにはかからない

適用範囲の穴も整理しておく。

対象	状態
claude.ai / Cowork / Claude Code（Web・デスクトップ・CLI）	対象
Claudeプラットフォーム（API）組織	対象外
Amazon Bedrock / Google Cloud（Vertex AI）経由	対象外
音声モード	対象外
会話タイトルの自動生成など付随リクエスト	対象外

BedrockやVertex AI経由でClaudeを使っている組織は、この機能では守れない。Claude PlatformとBedrockの違いでも触れたとおり、同じClaudeでも経路が変わればガバナンス機能の適用範囲は変わる。

除外設定にも制限がある。Inference hooksの適用から外せるのは組織が作成したカスタムロールだけで、組み込みロールは選択肢に出てこない。役員だけ外す、といった運用をしたければ先にカスタムロールを切る必要がある。なおロール判定ができなかった場合は、素通りではなくリトライ可能なエラーとして失敗する側に倒れる設計になっている。

使う側からは何が変わるか

ブロックされたユーザーが見るのは、サーバーが返したdeny_reasonと管理者設定の定型文だ。ドキュメントは「スキャナのコードを出すのではなく、何を消せばいいのかを書け」と実装者に釘を刺している。ここを雑にすると、社員は理由のわからない壁に毎日ぶつかることになる。

そもそもClaude Enterpriseで「見られていない会話」を期待するのが筋違いだ、という指摘はすでにある。Hack-Log氏は2026年4月20日のnote記事で、incognitoモードについてこう書いている。「incognito モードは『サイドバーに履歴を残さない』機能であって、『組織のログから消す』機能ではありません」。UI上で履歴が隠れるだけで、Compliance APIのエクスポート対象からは外れない（note, Hack-Log, 2026年4月20日）。Inference hooksはその前提を変えるものではなく、可視化のタイミングを事後から事前に動かしたものと読める。

一方で、承認済みツールなら安心という空気そのものがリスクだという見方もある。Inspect-DataのMichael Avdeevは2026年3月19日の記事で、ChatGPTをブロックしても社員は承認済みAIに同じデータを貼るだけだと指摘し、こう書いた。「契約書をAIの要約機能に放り込む前の、あのためらいの一瞬。消えた。これは承認済みだから」（Inspect-Data, Michael Avdeev, 2026年3月19日）。

背景: シャドーAIの実測値

なぜAnthropicがここに投資するのか。会社の管理外でAIが使われる、いわゆるシャドーAIの実測値を並べると輪郭が見える。

• サイバーセキュリティクラウド（2026年5月・国内会社員300名）: 67%が業務で生成AIを利用。そのうち約15%が企業管理外で使うシャドーAI状態（全体の約1割）
• Cyberhaven Labs（2026年2月・222社の分析）: AIへの入力の39.7%が機密情報を含む
• IBM『2025年データ侵害コスト調査』: シャドーAI利用が多い組織は侵害コストが約67万ドル上振れ、侵害の20%がシャドーAI起因

（出典: 上記3件はいずれもクラウドネイティブ, シャドーAI調査まとめ, 2026年5月が引用した各社公表値。一次資料は各調査機関の発表を参照）

Proofpoint自身の『2026 AI and Human Risk Landscape Report』も、世界の企業のほぼ9割がAIアシスタントをパイロット段階から先へ進めた一方、42%がAI関連の不審な、または確認済みのインシデントを経験したと報告している（Proofpoint, 2026年8月5日）。導入率が先に走り、統制が後追いしている構図だ。

Anthropicにとっては、AIセキュリティのスタートアップ群が担ってきた制御レイヤーを自社製品の内側に取り込む動きでもある（TNW, 2026年8月5日）。Unite.AIによれば、Check Pointが数日前にプロンプト検査をファイアウォール側へ載せたのに対し、Anthropicはプロバイダ側に置いた（Unite.AI, 2026年8月5日）。どちらが標準になるかは、まだ決着していない。

Inference hooks導入の判断: 自分ならこうする

PMとして評価すると、Inference hooksは「CISOに却下されるAI」を「CISOが管理できるAI」に寄せる部品として筋がいい。端末側に何も入れずに全サーフェスへ一律にかかる設計は、配布と例外管理のコストを大きく下げる。Claude Codeのようにローカルで動くツールまで同じ設定で覆えるのは、端末側にエージェントを配布するタイプのDLPとは異なるアプローチだ。

なお検査サーバーの自社実装は必須ではない。Proofpointは発表と同日にInference hooks対応を公表しており、既存のDLP製品側でこのWebhookを受ける選択肢がある。すでに検査ポリシーの資産を持っている組織なら、ゼロから書くより既存製品に寄せるほうが早い。逆にポリシーが未整備なら、実装より先にそちらを作る話になる。

そのうえで、自分が導入側の立場ならこの順で進める。

1. シャドーモードから始める。ライブトラフィックに対して判定は走るが何もブロックしない。実トラフィックで誤検知率を測ってから本番に上げる
2. 失敗時の扱いを最初に決める。既定のfail openのまま「入れた」と報告するのは、統制としては入っていないのと大差ない。ただしfail closedにするなら、検査サーバーの落ち方がそのまま全社の作業停止になる。検査サーバーの可用性目標（年間何分まで止まってよいか、障害検知から復旧まで何分で戻すか）を先に決めて、その数字に責任を持てる体制があるかで選ぶ
3. ボディ上限を10MBに合わせる。リバースプロキシの既定値のまま置くと、大きいプロンプトだけが検査から漏れる
4. deny_reasonの文面を先に書く。何を消せば通るのかが書かれていないブロックは、抜け道探しを誘発するだけだ

導入しない判断もある。会話内容を丸ごと自社サーバーに流すということは、その保管・アクセス制御・保持期間の設計責任を自社が引き受けるという意味だ。Anthropicから守る代わりに、自社のログ基盤が新しい機密の集積地になる。監査要件が具体的にないなら、Compliance APIによる事後監査で足りる組織のほうが多いはずだ。

---

関連記事

• Accenture × Claude: 企業セキュリティ運用にAIを組み込む
• マッキンゼー「Lilli」20ドル突破事件: 承認済みAIの内側の穴
• AgentJacking: Sentry MCP経由でClaude Code・Cursorが乗っ取られる
• 日本企業の生成AI導入が「信頼の壁」で止まる理由

---

本記事の情報は2026年8月7日時点のものです。Inference hooksはベータ機能であり、Anthropicの公式ドキュメントにも「フィールド名、リクエスト形状、ヘッダーは正式提供前に変更される可能性がある」と明記されています。仕様・既定値・提供範囲は変更される場合があるため、実装前に必ず公式ドキュメントの最新版を参照してください。英語の公式ドキュメントおよび海外記事からの引用は、いずれも筆者による日本語訳です。記載した調査数値は各調査機関の公表値であり、調査時期・対象・サンプル数が異なる点にご留意ください。また本記事は情報提供および筆者個人の見解を目的としたものであり、特定製品の導入・不導入や具体的なセキュリティ設定を推奨するものではありません。実際の設定は自社のリスク評価と社内規程に基づき、責任者の判断で決定してください。Claude、AnthropicはAnthropic PBCの商標です。その他の製品名・サービス名は各社の商標または登録商標です。