Claude Enterprise に Inference hooks：モデルに渡る前に自社サーバーが検査する

要約

Anthropic が 2026-08-05、Claude Enterprise 向けに「Inference hooks」をベータ提供しました。名前は控えめですが、企業導入の観点では今週いちばん実務に効く発表です。

やっていることは単純です。すべての推論リクエストが、モデルに届く前に組織のセキュリティサーバーを経由します。セキュア WebSocket 接続で内容が送られ、サーバーが allow / deny を返します。判定が返るまで Claude は処理を進めません。公式の表現では「Your server returns a verdict — allow or deny — and Claude only proceeds once it has one」です。

重要なのは、検査対象がユーザーのプロンプトだけではないことです。ツール呼び出しの応答も、モデルに渡る前に検査されます。エージェント的な使い方が広がると、社内システムから取り込んだデータや外部から取得した内容がモデルのコンテキストに流れ込みます。入口だけを見ていても防げない領域に、検査点が置かれた形です。

これまで企業が取ってきた対策は、大きく 2 つでした。1 つは利用ガイドラインで「機密情報を入力しない」と決めること。もう 1 つはネットワーク側の DLP で、後から検知することです。前者は運用が人の注意力に依存し、後者は流出してから気づくことになります。Inference hooks は、モデルに届く前に止めるという第 3 の位置に検査点を置きます。

既存の DLP 資産も活かせます。Netskope、Palo Alto Networks、Proofpoint といったベンダーの基盤と統合でき、独自実装も可能です。すでに DLP ポリシーを整備している組織なら、判定ロジックを一から作り直す必要はありません。

展開方法が現実的に設計されている点も見逃せません。シャドーモード（判定はするが遮断しない）で影響を観測してから、ロール単位の除外や割合ベースの段階展開で広げていけます。タイムアウト値と障害時ポリシー（fail open / fail close）も設定可能です。「全社一斉に有効化して業務が止まる」という事故を避けられる作りになっています。

適用範囲は組織全体で、Claude chat、Claude Code、Claude Cowork、MCP 接続ツールをカバーします。製品ごとに個別の連携を組む必要がありません。提供はベータで、対象は Claude Enterprise です。

何が変わったか

• すべての推論リクエストをモデル到達前に組織のサーバーが検査し、allow / deny を返せるようになった
• 判定が返るまで Claude は処理を進めない（同期的な遮断）
• 検査対象にユーザープロンプトだけでなくツール呼び出しの応答も含まれる
• Netskope / Palo Alto Networks / Proofpoint などの既存 DLP 基盤と統合できる。独自実装も可能
• シャドーモード（判定のみ・遮断なし）で影響を事前観測できる
• ロール単位の除外、割合ベースの段階展開に対応
• タイムアウト値と障害時ポリシー（fail open / fail close）を設定できる
• Claude chat / Claude Code / Claude Cowork / MCP 接続ツールを組織全体で一括カバー（製品ごとの個別連携が不要）
• 提供形態は Claude Enterprise 向けのベータ

業務インパクト（一般企業向け）

Claude の全社導入が止まっている企業の多くは、機能ではなく**「機密情報が入力されたときに止められない」という一点**で止まっています。ここに公式の答えが出た、というのが今回の意味です。

情シス・セキュリティ部門の観点では、稟議の論点が変わります。これまでは「利用ガイドラインを整備し、教育で徹底する」という、実効性を問われると弱い説明をせざるを得ませんでした。Inference hooks があれば、「モデルに渡る前に自社のポリシーで遮断する」という技術的な統制を提示できます。監査対応でも、判定ログが自社側に残る構成は説明しやすいはずです。

ただし、新しい負担も発生します。最大のものは判定サーバーが Claude 利用のクリティカルパスに入ることです。このサーバーが落ちたときに何が起きるかは、fail open（通す）か fail close（止める）かの設定次第で正反対になります。fail close にすればセキュリティは保たれますが、判定サーバーの障害がそのまま全社の Claude 停止になります。fail open なら業務は続きますが、その間は無検査です。この判断はセキュリティ部門だけでは決められず、業務側と合意しておく必要があります。

レイテンシも論点です。すべてのリクエストが同期的に検査を通る以上、判定にかかる時間はそのまま体感速度に乗ります。タイムアウト値の設定はセキュリティと使用感のトレードオフで、シャドーモードで実測してから決めるのが妥当です。

導入手順としては、シャドーモードで数週間動かし、「実際にどれだけの deny 候補が出るか」を見るところから始めるのが安全です。ここで想定より遥かに多くの検知が出るなら、ポリシーが厳しすぎるか、あるいは現在すでにそれだけの情報が流れているということです。どちらの結論でも、有効化前に知っておく価値があります。

なお、これは Claude Enterprise の機能です。Team プランなどで運用している組織では、プラン変更を含む検討になります。ベータ段階でもあるため、本番の統制手段として依存する前に、提供条件を確認しておくべきです。

副業・個人活用視点

個人利用者が直接使う機能ではありませんが、支援側の立場では大きな案件材料になります。

企業向けに Claude 導入を支援している場合、これまで最後に残る宿題はほぼ必ず「機密情報の扱い」でした。ここに技術的な回答が用意されたことで、提案の構成が変わります。「導入して使い方を教える」だけでなく、「Inference hooks の判定サーバーを設計・実装し、シャドーモードで検証してから段階展開する」という工程を提案に含められます。実装を伴う分、単価も期間も変わります。

判定サーバー自体は難解なものではありません。WebSocket で受けて、ポリシーに照らして allow / deny を返す構成です。既存 DLP との統合が要らない中小規模なら、自前実装で十分に成立します。ここは個人・小規模チームでも十分に受けられる規模の仕事です。

もう一つの使いどころは、現状把握のコンサルティングです。シャドーモードは「遮断せず判定だけする」モードなので、実質的に「自社で今どんな内容が AI に入力されているか」を可視化する道具になります。ポリシー策定の前段として、この観測だけを切り出した小さな案件にできます。いきなり統制を入れるより受け入れられやすく、その結果が次の提案の根拠にもなります。

注意点として、扱う対象が機密情報そのものであるため、支援する側の責任範囲を契約で明確にしておく必要があります。判定ロジックの不備が情報流出につながる構造なので、「実装は支援するがポリシーの最終決定と責任は顧客側」という線引きは事前に文書化しておくべきです。技術的な面白さで踏み込みすぎない方がよい領域です。