企業でAIを使うとき、これまで統制の主戦場は「出力の監査」——誰が何を生成したかを後から追える状態にすることだった。ログを残し、コンプライアンスAPIで引き出し、監査する。だが、この設計には構造的な穴がある。機密データがモデルに渡ってしまった後では、いくら記録が残っていても情報はすでに外部の推論に流れている。
2026年8月5日、Anthropicが公開した Inference hooks（推論フック） は、この穴を正面から塞ぎにいく機能だ。プロンプトがモデルに届く前に、企業自身のサーバーへ会話内容を送り、allow（許可）か deny（拒否）の判定を受け、拒否ならモデルには一切渡さない。統制の制御点が「事後の監査」から「推論の直前」へと物理的に移動する。
homulaはエンタープライズ向けのAIエージェント・インテグレーターとして、まさにこの「AIをどこで止め、どこで通すか」という制御点の設計を日々扱っている。今回の推論フックは、その制御点がベンダー側にも実装され始めたことを示す象徴的な一手だ。本稿では一次情報をもとに仕組みを正確に整理し、企業が実務で何を判断すべきかを掘り下げる。
推論フックとは何か——「入口」に検査ゲートを置く
推論フックは、Claude Enterprise 組織が「AIセキュリティサーバー」（組織またはセキュリティベンダーが運用するHTTPSサービス）を経由させることで、すべての統制対象プロンプトを推論の前に検査できる仕組みだ。重要なのは、この検査がAnthropicのサーバー上で、リクエストがクライアントを離れた後・モデルが動く前に走ること。ユーザーの端末に何かをインストールする必要はなく、対象サーフェス全体に一律で適用される（Anthropic公式ドキュメント）。
具体的な流れは次のとおりだ。
| ステップ | 何が起きるか |
|---|---|
| ① ユーザーがプロンプト送信 | 統制対象サーフェス（claude.ai / Cowork / Claude Code）で送信 |
| ② Anthropicが検査を要求 | 会話トランスクリプトを署名付きHTTPS POSTで自社サーバーへ送る（Standard Webhooks準拠で送信元を検証可能） |
| ③ 自社サーバーが判定 | 既定5秒のタイムアウト内に許可/拒否を返す |
| ④ 判定を適用 | allowなら推論続行。denyなら拒否し、理由付きのブロック表示。拒否は組織のActivity Feedに記録 |
判定は小さなJSONで返す。
{ "action": "allow" }
拒否の場合は、ユーザー向けの理由（deny_reason）を添える。自社サーバーが受け取れるのは「ユーザーが見ているもの」——トランスクリプトのテキスト、ツール呼び出しとその結果、添付ファイルから抽出したテキストだけだ。生のファイル/画像バイト、システムプロンプト、Anthropic内部のコンテキストは渡されない。検査に必要な範囲に絞られている点は、プライバシーと実装容易性の両面で理にかなっている。
そして、企業にとって一つの設計上の分岐点がある。自社サーバーが到達不能・エラー・タイムアウトのとき、リクエストをブロックするか（fail-closed）、**無検査で通すか（fail-open）**を設定で選ぶ。これは可用性とセキュリティのトレードオフそのもので、規制業種ほど前者を、業務停止を避けたい現場ほど後者を選びたくなる。ここを組織方針として明文化できているかが、導入の成否を分ける。
「事後監査」から「事前遮断」へ——制御点が推論の直前に移った
推論フックの本質は、機能の派手さではなく制御点の位置にある。Anthropic自身、これを既存のCompliance APIと対比して説明している。
| 推論フック | Compliance API | |
|---|---|---|
| いつ効くか | 推論の前（インライン） | 事後 |
| 何をするか | 各リクエストをリアルタイムで許可/拒否 | 活動・チャット・ファイル等を取得して監査・書き出し |
| 呼ぶ方向 | Anthropicが自社サーバーを呼ぶ | 自社がAnthropicのAPIを呼ぶ |
つまり、監査（事後）と遮断（事前）は排他ではなく役割分担だ。だが実務上のインパクトは大きく違う。事後監査は「起きたことを説明できる」だけで、機密の流出そのものは止められない。推論フックは「起きる前に止める」ため、DLP（データ損失防止）の観点では初めて“予防”の位置に立てる。Anthropicもドキュメントで、最も一般的な用途としてDLP——「トランスクリプトを自社のDLPスキャナーへ転送し、規制・機密情報を含むプロンプトを拒否する」——を挙げている。
この「入口で止める」発想は、homulaが過去に論じてきたエージェント統制の潮流とも一致する。ツール単位の承認ゲートや意図の照合による制御が「エージェントが何をするか」を止める設計だったのに対し、推論フックは「そもそもモデルに何を見せるか」を止める設計だ。制御点は、出力から入力へ、事後から事前へと確実に前進している。
何が“まだできない”か——正確に把握する
新機能で最も危険なのは、できることを過大評価して統制の穴を見落とすことだ。推論フックは強力だが、現時点の制約を正確に押さえておく必要がある。
Anthropicのローンチ告知は「すべてのプロンプトとtool call応答を検査できる」と広めに表現しているが、技術ドキュメントによれば、今日発火するのは prompt イベントのみ。応答側（モデル出力やツール呼び出しの結果）の検査は「今後のイベント」として計画中の段階だ。入口は守れても、出口の検査はこれからという理解で設計すべき。
一次情報から確認できる主な制約は次のとおり。
- 判定は許可/拒否の二択。プロンプトの書き換えやマスキング（機密部分だけ黒塗りして通す、といった再編集）はサポートされない。
- 添付はメタデータと抽出テキストのみ。画像だけの内容——たとえば機密書類のスクリーンショット——は検査対象外になる。OCR前提の漏洩経路は別途塞ぐ必要がある。
- 対象外の経路がある。Amazon Bedrock / Google Cloud 経由、音声モード、会話タイトル生成などの付随リクエストは送られない。システムプロンプトとツール定義も送信対象に含まれない。
- プラットフォーム組織（API経由）は対象外。ベータはClaude Enterprise向けで、設定には
organization:manage権限が要る。
これらは「使えない」という否定ではなく、「推論フックだけでDLPが完結するわけではない」という設計上の前提だ。画像経路・出力側・非対象サーフェスをどう補完するかを、導入時にセットで描く必要がある。
DLPベンダー連携と「ゲートウェイ化」する市場
推論フックの現実的な強みは、自社が使っている既存のDLP基盤にそのまま向けられる点にある。Anthropicは、ローンチ時点で Netskope・Palo Alto Networks・Proofpoint・Zscaler といった主要ベンダーとの連携を挙げ、内製のセキュリティサーバーを指す構成も可能だとしている。実際、ZscalerやProofpointは、既存のDLPポリシーを推論前のチェックに持ち込む統合を相次いで発表した。1製品ごとにエージェントを入れるのではなく、組織で一度設定すれば全サーフェスに効くという単一の適用層に価値がある。
この動きは、Claudeに閉じた話ではない。同じ8月、Snowflakeも Black Hat 2026 で Cortex AI Gateway を発表し、MCPサーバーやツール呼び出しに対して「誰が要求し、どの権限を持ち、その操作が許されるか」を集中的に統制する仕組みを打ち出した（Snowflake公式、VentureBeat）。モデルベンダーは自社サーフェスに検査フックを埋め込み、データ基盤ベンダーは横断的なゲートウェイを立てる——「AIとツールの間に検査ゲートを置く」という設計が、業界全体で一斉に標準化しつつあるというのが、この2つの発表を並べたときに見える構図だ。
homulaの観点——「ベンダーのフックに乗る」か「自社の統制層を持つ」か
では、日本企業は何をどう判断すべきか。homulaが現場で繰り返し見てきた論点は、突き詰めると一つに収れんする。制御点をベンダー任せにするのか、自社の統制層として持つのかだ。
推論フックのようなベンダー提供のフックは、導入が速く、対象サーフェスに一律で効く。まず有効化すべき「一次防衛線」として優れている。一方で、前述のとおり出力側・画像経路・非対象サーフェスには穴が残り、しかも守れる範囲はそのベンダーの製品内に限られる。実際の企業は Claude だけでなく、複数のLLM・n8nやDifyのワークフロー・社内システムを横断してエージェントを走らせる。ベンダーごとのフックを継ぎ接ぎしても、組織全体で一貫した統制にはならない。
homulaが提供する Agens Control は、この「自社の統制層」を担う設計思想でつくられている。承認フロー・DLP・5年分の監査ログ・RBAC を、特定のモデルやツールに縛られずに横断して効かせる。推論フックが「入口の一次検査」なら、Agens Control は「組織全体で誰が何をどこまでできるか」を束ねる統制の背骨だ。両者は競合しない——ベンダーのフックを一次防衛線として使いつつ、その上位に自社の一貫した統制層を重ねるのが、現実的な勝ち筋になる。
導入の順序も明快だ。まず Agens のようなMCP基盤で「どのツールに、どのエージェントが、どの権限で触れるか」を一元化し、次に推論フック等のベンダー機能を一次検査として組み込み、最後に DLP・監査・承認を自社ポリシーとして横断適用する。この土台があれば、次に来る「出力側の検査」や「新しいゲートウェイ」も、既存の統制層に差し込むだけで済む。個別のフックを追いかけ続ける消耗戦から抜けられる。
まとめ——制御点は前進した。だが“継ぎ接ぎ”では守れない
- Anthropicの推論フックは、AIデータ統制の制御点を事後監査から事前遮断へ動かした。機密がモデルに届く前に、自社サーバーで許可/拒否を判定できる。
- ただし現状は
promptイベントのみで、出力側の検査は計画段階。画像経路・非対象サーフェス・書き換え不可といった制約も正確に押さえる必要がある。 - Snowflakeの Cortex AI Gateway と併せて見ると、「AIとツールの間に検査ゲートを置く」設計が業界標準になりつつある。
- 日本企業が取るべきは、ベンダーのフックを一次防衛線として活用しつつ、その上位にモデル・ツール横断で一貫した自社の統制層を持つこと。継ぎ接ぎのフックは、組織全体の統制にはならない。
制御点がどこにあるべきかは、もう「監査で後から追える」では足りない。「入口で止め、全社で一貫して統制できる」かどうかが問われている。homulaは、その統制層の設計から運用・内製化までを一気通貫で支援する。
AIの制御点を「継ぎ接ぎ」から「一貫した統制層」へ——自社に最適な設計を、まずは無料相談で整理しませんか。