結論：Anthropicは2026年8月5日、Claude Enterprise向けに「Inference Hooks（推論フック）」をベータ公開しました。これはユーザーが送るすべてのプロンプトを、組織が用意した自前の「AIセキュリティサーバー」へ転送し、allow（許可）かdeny（拒否）の判定を受けてから初めてモデルへ渡す仕組みです。対象はclaude.ai・Claude Cowork・そしてClaude CodeのCLIセッションを横断する1本のフックで、従来Claude Code単体にしかなかったクライアント側フック（PreToolUse等）の限界を、組織全体の推論経路で埋める設計になっています。
- 要点1：プロトコルはStandard Webhooks仕様に準拠したHTTPS POST。会話の transcript（テキスト・ツール呼び出し・添付ファイルの抽出テキスト）を送り、5秒（設定可能・1〜10,000ms）以内に
{"action":"allow"}または{"action":"deny", "deny_reason":"..."}を返す必要がある - 要点2：いきなり本番ブロックにする必要はない。Shadow mode（判定だけ受けて一切ブロックしない）→ロールアウト率（0〜100%で検査対象を絞る）→Enforce（本番適用）という3段階の安全な導入パスが公式に用意されている
- 要点3：2026年8月時点でBedrock・Google Cloud経由のClaudeは対象外、画像・添付ファイルの生バイトは送信されない、Platform（API直利用）組織はスコープ外——という制限があり、「全部を検査できる」わけではない
対象読者：Claude Codeを組織導入している情シス・セキュリティチーム、DLP/SIEMベンダーとの統合を検討するPM・テックリード
今日やること：自組織がClaude Enterpriseプランかどうかを確認し、Bedrock/Google Cloud経由の利用がないか（対象外のため）、Netskope・Palo Alto Networks・Proofpoint・Zscalerなど既存DLPベンダーがInference Hooks統合に対応済みかを確認する
「Claude Codeに社外秘のソースコードやAPIキーを貼り付けたら、その内容はどこまで組織側で検知できるのか」——法人のClaude Code導入を支援していると、情シス・セキュリティチームから必ず出てくる質問です。これまでの答えは「Claude Code単体のクライアント側フック（PreToolUse等）でBashコマンドや特定ツール呼び出しをブロックすることはできるが、claude.aiのチャットやCoworkでの利用までは横断的にカバーできない」という、やや歯切れの悪いものでした。
2026年8月5日、Anthropicはこの隙間を埋める新機能「Inference Hooks（推論フック）」をClaude Enterprise向けにベータ公開しました。本記事では公式ドキュメント（platform.claude.com）と公式ブログを一次情報として、仕組み・最小構成のverdictサーバーの作り方・段階的な導入手順・DLPベンダー統合の選択肢を、実装者視点で整理します。2026年8月時点で確認できた事実を基準にしており、確認できなかった点は「未確認」と明記します。
Inference Hooksとは何か——Claude Enterpriseの新しいリアルタイムDLP
Inference Hooksは、Claude Enterprise組織が指定したHTTPS エンドポイント（AIセキュリティサーバー）へ、推論が実行される直前に会話のtranscriptを送り、許可/拒否の判定を仰ぐ仕組みです。判定はAnthropic側のサーバーで完結するため、ユーザーの端末には何もインストールする必要がありません。公式ドキュメントは主なユースケースとして次の4つを挙げています。
- DLP（データ損失防止） — transcriptをDLPスキャナに転送し、規制対象データや機密情報を含むプロンプトを拒否する。「最も一般的な導入」と公式ドキュメントが明記
- リアルタイムのtranscriptアーカイブ — 常に
allowを返しつつ、受信したフレームを記録する。Compliance APIのポーリング方式に代わるpush型の代替 - プロンプトのテレメトリ — 利用実態を「使われた瞬間」に計測する
- ポリシーエンジン — モデルの許可リスト、プロジェクト単位の制限、稼働時間帯の制御など独自ルールを推論前に強制する
現時点でフックイベントはpromptの1種類のみです。応答（レスポンス）側での検査は「将来のイベントとして計画中」と明記されており、2026年8月時点では未実装です。
何が変わったのか——Claude Code独自フックとの違い
Claude CodeにはこれまでもPreToolUse・PostToolUse等のクライアント側フックがあり、settings.jsonにマッチャーとハンドラーを書くことでBashコマンド実行前に検証スクリプトを挟めました（PreToolUseのdenyはbypassPermissionsや--dangerously-skip-permissionsより先に評価されるため、権限モードを迂回しても止められる設計です）。Inference Hooksはこれとは別のレイヤーで動く、組織横断の仕組みです。
| 比較軸 | Claude Codeのクライアント側フック（既存） | Inference Hooks（新規・2026-08-05〜） |
|---|---|---|
| 動作場所 | ユーザーの端末（settings.jsonで設定） |
Anthropicのサーバー上（組織全体で一元設定） |
| 対象範囲 | そのClaude Codeセッションのツール呼び出しのみ | claude.ai・Claude Cowork・Claude Codeを横断する1本のフック |
| ユーザー側の関与 | 個々の開発者が.claude/settings.jsonを書ける（回避されうる） |
組織管理者が一元設定。エンドユーザーは変更できない |
| 検査対象 | ツール呼び出し（Bash・Edit等）の入力 | 会話transcript全体（テキスト・ツール呼び出しと結果・添付抽出テキスト） |
| 必要プラン | Claude Code全プランで利用可 | Claude Enterprise限定（ベータ） |
公式ブログは「これまでインラインでの強制はClaude Codeのクライアント側フックに限られており、Claude Enterpriseの他のサーフェスには同種の仕組みがなかった」という趣旨で、Inference Hooksをその隙間を埋めるものと位置づけています。両者は排他ではなく併用が前提で、Claude Codeのローカルフックは「その端末でのツール実行を即座に止める」用途に、Inference Hooksは「組織のどのサーフェスからでも、機密データがモデルに渡る前に止める」用途に向いています。
リクエストの中身とverdictスキーマ
AIセキュリティサーバーが受け取るリクエストは、次のようなJSONです（公式ドキュメントのサンプルを一部簡略化）。
{
"type": "prompt",
"request_id": "req_abc123",
"tenant_id": "11111111-1111-1111-1111-111111111111",
"actor": {
"type": "user",
"id": "user_01AbCdEfGhIjKlMnOpQrStUv",
"email_address": "[email protected]"
},
"source": { "application": "claude-code" },
"session_id": "22222222-2222-2222-2222-222222222222",
"model": "claude-sonnet-4-5",
"messages": [
{
"role": "user",
"content": [{ "type": "text", "text": "この社内APIキーを使ってテストして" }]
}
],
"metadata": {}
}source.applicationにはclaude-aiとclaude-codeという既知の値があり（他の値も将来追加されうるため未知の値を理由に拒否してはいけない、と明記）、Claude Codeからのリクエストかどうかをこのフィールドで判別できます。ただし公式ドキュメントは「これはあくまで参考情報であり、セキュリティ上の信頼境界として単独で使うべきではない」と釘を刺しています。messagesにはツール呼び出し（tool_use）とその結果（tool_result）も含まれるため、MCPコネクタ・スキル・プラグイン経由でのツール実行結果も検査対象に入ります。一方でシステムプロンプト・ツール定義・Claudeの内部的な思考過程は一切送信されません。
AIセキュリティサーバー側は、HTTP 200と次のいずれかのJSONを返します。
// 許可
{ "action": "allow" }
// 拒否（ユーザーに表示される理由付き）
{
"action": "deny",
"deny_reason": "このプロンプトには顧客の決済カード情報が含まれている可能性があります。",
"reference_id": "scan_01HXPT4R9V"
}deny_reasonは最大500文字でユーザーにそのまま表示されます。reference_idは自分側のスキャン結果と突き合わせるための識別子で、Compliance APIの監査ログ（inference_hooks_request_denied）に記録されますがユーザーには見えません。200以外のステータスを返すと「拒否」ではなく「webhook失敗」として扱われる点に注意が必要です——失敗時の挙動は次段で説明する「失敗ハンドリング」設定に従います。
最小構成のverdictサーバーを作る
公式ドキュメントはPython・TypeScript・Go・Java・C#・PHP・Ruby向けに、常にallowを返すだけの最小サーバー実装を公開しています。動作確認用のPython版は次の通りです（http.serverのみで動く標準ライブラリ実装）。
# Run with: python server.py
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
class VerdictHandler(BaseHTTPRequestHandler):
protocol_version = "HTTP/1.1"
def do_POST(self):
# transcriptは数MBになりうるので必ず読み切る
self.rfile.read(int(self.headers.get("Content-Length", 0)))
verdict = b'{"action": "allow"}'
self.send_response(200)
self.send_header("Content-Type", "application/json")
self.send_header("Content-Length", str(len(verdict)))
self.end_headers()
self.wfile.write(verdict)
ThreadingHTTPServer(("", 8000), VerdictHandler).serve_forever()これを公開https://URL（TLS終端のリバースプロキシやトンネル経由）で公開し、組織管理者がエンドポイントとして登録・Test connectionを実行すれば、最初の疎通確認が完了します。ただし公式ドキュメントは「このサーバーは署名なしのリクエストも含めて全部受け入れてしまうので、本番でEnforceする前に必ず署名検証を追加すること」と明記しています。
署名検証——Standard Webhooksを正しく実装する
リクエストにはStandard Webhooks仕様に沿った3つのヘッダー（webhook-id / webhook-timestamp / webhook-signature）が付き、署名は{webhook-id}.{webhook-timestamp}.{生のbodyバイト列}に対するHMAC-SHA256です。公式ドキュメントが「検証バグの9割はここで起きる」と指摘するポイントは2つあります。
import base64, hashlib, hmac, time
TOLERANCE_SECONDS = 300
def verify(secret, headers, body: bytes) -> bool:
lowercased = {k.lower(): v for k, v in headers.items()}
message_id = lowercased.get("webhook-id")
timestamp = lowercased.get("webhook-timestamp")
signatures = lowercased.get("webhook-signature")
if not (message_id and timestamp and signatures):
return False # 未署名 = Anthropicからのリクエストではない
if abs(time.time() - int(timestamp)) > TOLERANCE_SECONDS:
return False # リプレイ or 時計ズレ
# secretは "whsec_" プレフィックスを外し、標準base64（URL-safeではない）でデコード
key = base64.b64decode(secret.removeprefix("whsec_"))
payload = f"{message_id}.{timestamp}.".encode() + body
expected = b"v1," + base64.b64encode(hmac.new(key, payload, hashlib.sha256).digest())
return any(hmac.compare_digest(expected, s.encode()) for s in signatures.split())特に注意すべきは①JSONパース前の生バイト列に対してHMACを計算すること（再エンコードすると署名が一致しなくなる）、②署名鍵は標準base64アルファベット（+と/）でデコードすること（URL-safeデコーダを使うと鍵の値に+や/が含まれる場合に誤った鍵バイト列になる）の2点です。署名鍵は初回保存時に一度だけ表示され、以後は再取得できません（ローテーションのみ可能）。
導入手順——Shadow modeから本番Enforceまで
いきなり全社ブロックを始めると、DLPポリシーの誤検知で業務が止まりかねません。公式ドキュメントは3段階の安全な導入パスを明示しています。
| ステップ | 設定 | 挙動 |
|---|---|---|
| 1. Shadow mode | Enforce verdicts=ON、Mode=Shadow mode | AIセキュリティサーバーは判定を返すが、実際には誰もブロックされない。本番トラフィックに対してポリシーをチューニングする段階 |
| 2. ロールアウト率 | Requests inspected (%) を0〜100の間で調整 | 検査対象のリクエストを段階的に増やす。会話は1ターンごとに抽選されるため、同じ会話が一部だけ検査されることもある |
| 3. 本番Enforce | Mode=Block the request / Allow the request | 実際にdeny判定をブロックする。設定反映まで約1分 |
「失敗ハンドリング（Failure handling）」の設定も重要です。AIセキュリティサーバーが落ちている・タイムアウトした場合にBlock the request（fail closed）を選べば安全側に倒れますが、サーバー障害＝全社のClaude利用停止という重いトレードオフになります。Allow the request（fail open）は可用性を優先しますが、検査が抜ける時間帯が生まれます。判定タイムアウトは1〜10,000msの範囲で設定でき、デフォルトは5,000ms。Anthropicは接続失敗時に100ms後の再試行を1回だけ行い、それでも応答がなければ「webhook失敗」として扱われます。
また、サーバーの連続失敗が続くとサーキットブレーカーが作動し、Enforceが自動的に停止（=以後は問い合わせなしでFailure handling設定が全リクエストに適用）される点も運用上おさえておく必要があります。復旧にはサーバー修復後、管理者が手動でEnforceを入れ直す必要があります。
DLPベンダー統合の選択肢
Inference Hooksはオープンなwebhookプロトコルなので、既存のDLP/SASE製品を流用するか、自前で構築するかを選べます。
| 選択肢 | 向いているケース | 備考 |
|---|---|---|
| Netskope | 既にNetskopeでSaaS全体のDLPを運用中 | 他ツールと同じレポーティング基盤に集約できる |
| Palo Alto Networks | 既存のセキュリティスタックがPalo Alto中心 | 同上 |
| Proofpoint | メール/情報漏洩対策の既存契約がある | 同上 |
| Zscaler | ゼロトラストネットワークをZscalerで統一 | 同上 |
| 自前構築（in-house） | 独自の分類ロジック・社内システムとの突合が必要 | 本記事のPython/TypeScriptサンプルが出発点になる。運用の全責任を自組織が負う |
公式ブログでは大手通信企業BandwidthのVP of Information Security、Andrew Grimmett氏のコメントとして「Inference Hooksは、何がClaudeに流れているかをリアルタイムで検査するチェックポイントを追加してくれる。モデルが実際に見る前に。これによって、コントロールを失わずにAI活用のスピードを上げられる」という趣旨の導入事例が紹介されています（Bandwidth以外の具体的な業種別導入事例は2026年8月時点で確認できていません）。
現状の制限と対象範囲——何が検査されないか
「全部見られる」わけではない点を正確に理解しておく必要があります。公式ドキュメントが明記する制限は次の通りです。
- 画像・添付ファイルの生バイトは送信されない — 添付は抽出テキスト（メタデータ・OCR結果等）のみが送られるため、画像だけのスクリーンショット等は検査対象外
- 判定はallow/denyの2択のみ — プロンプトの書き換え・マスキング（レダクション）はサポートされていない
- Platform組織（API直利用）はスコープ外 — Claude Enterpriseのユーザー向けサーフェス（claude.ai・Cowork・Claude Code）が対象で、API経由の直接利用は対象外
- Amazon Bedrock・Google Cloud経由は非対応 — Inference HooksはAnthropic直契約のClaude Enterprise向け機能で、クラウド経由提供では利用できない
- Voiceモードは対象外、タイトル生成等の付随リクエストも送信されない
導入時に起きやすい詰まりどころ
❌ 「denyをHTTPエラーステータス（4xx/5xx）で表現する」
⭕ deny判定は必ずHTTP 200＋{"action":"deny", ...}のJSONボディで返す。200以外は「拒否」ではなく「webhook失敗」として扱われ、Failure handling設定（block/allow）に従ってしまう
❌ 「JSONにパースしてから再シリアライズした文字列でHMACを計算する」
⭕ 受信した生のバイト列に対してそのままHMACを計算する。整形・キー順序の変更・エンコーディングの違いだけで署名が一致しなくなる
❌ 「本番のnginx/Expressのデフォルト設定（client_max_body_size 1mやExpressのexpress.json()の100kB上限）のままエンドポイントを公開する」
⭕ transcriptは添付込みで最大10MBまで届きうる。ボディサイズ上限を引き上げないと、大きめの会話は「拒否」ではなく「サーバー側の受信失敗」となり、Allow the request設定なら無検査のまま素通りしてしまう
❌ 「署名鍵をローテーションした瞬間に旧鍵の検証コードを削除する」
⭕ ローテーション直後は旧鍵で署名されたリクエストが最大1分程度届き続ける。切り替え時は新旧両方の鍵で検証を試みる実装にしておく
今後の見通しと関連記事
2026年8月時点でInference Hooksはベータであり、フィールド名やリクエスト形状は一般提供（GA）までに変更されうると公式ドキュメントに明記されています。現時点で確定しているイベントはprompt（推論前）のみで、レスポンス側の検査は「将来のイベントとして計画中」とされていますが、具体的な提供時期は2026年8月時点で公式に明言されていません。
Claude Codeの法人導入における権限設計・データ保持・MCP監査など、Inference Hooks以外の全体的なセキュリティ論点はClaude Code法人導入セキュリティ完全チェックリストで扱っています。組織全体でのモデル利用制限・スキル統制といったガバナンス設計はClaude Code全社ガバナンス｜利用モデルとスキル統制を参照してください。Inference Hooksの検査対象にはMCPコネクタ経由のツール呼び出しも含まれるため、自作MCPサーバーを運用している場合はMCP新仕様7/28対応ガイドもあわせて確認しておくと、検査対象になるツール呼び出しの範囲を正確に把握できます。
よくある質問（FAQ）
まとめ：今日から始める3つのアクション
- 今日やること：自組織がClaude Enterpriseプランか、Bedrock/Google Cloud経由でないかを確認し、Inference Hooksの適用範囲に入っているかを把握する
- 今週中：既存のDLP/SASEベンダー（Netskope・Palo Alto Networks・Proofpoint・Zscaler等）がInference Hooks統合に対応しているか問い合わせる。未対応なら本記事のPythonサンプルで最小サーバーを立て、Shadow modeで疎通確認する
- 今月中：Shadow modeで自組織の実トラフィックに対してポリシーをチューニングし、誤検知率を確認した上でロールアウト率を段階的に上げていく
参考・出典
- Inference hooks（概要） — Claude Platform公式ドキュメント（2026年8月参照）
- Configure Inference hooks（設定手順） — Claude Platform公式ドキュメント（2026年8月参照）
- Develop an Inference hooks integration（エンドポイント実装仕様） — Claude Platform公式ドキュメント（2026年8月参照）
- Inference hooks: inline data loss prevention for Claude Enterprise — Anthropic公式ブログ（2026年8月5日公開）
- Hooks reference — Claude Code公式ドキュメント（クライアント側フックとの比較用・2026年8月参照）
- Claude Code changelog — Claude Code公式チェンジログ（2026年8月参照）
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆。
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。
