プロンプトを、モデルに届く前に自社のサーバで止める

Anthropic の Inference hooks（ベータ、Claude Enterprise 向け）は、ユーザーが送ったプロンプトを推論が始まる前に自組織が運用する HTTPS サーバへ回し、allow か deny の判定を待つ仕組みである。

Anthropic のドキュメントによる。フックは Anthropic 側のサーバで動くため、利用者の端末に入れるものは無い。

仕様で押さえておく点

送られるのは会話の転記である。 ツール呼び出しとその結果、添付から抽出したテキストも含む。ただし生のファイルや画像のバイト列、システムプロンプト、Anthropic 内部の文脈は送られない。

判定は5秒（既定）以内に返す必要がある。 署名は Standard Webhooks 仕様に従う。

サーバが落ちたときの挙動は選べる。 到達不能・エラー・タイムアウトのとき、要求を止めるか、検査なしで通すかを組織の設定で決める。

判定は allow か deny の二択で、書き換えや伏字はできない。 deny の場合、サーバが返した理由と管理者が設定した定型文が利用者に表示され、拒否は Activity Feed に記録される。

段階導入の仕掛けもある。shadow モードは実トラフィックで判定を観測するだけで何も止めない。ロールアウト率で検査対象の割合を絞れる。特定ロールを除外もできる。

生成AI導入で最後まで残る論点は「機密が外に出ないか」である。 これまでの答えは利用ガイドラインと事後の監査で、どちらも「出た後」の話だった。Inference hooks は出る前で止める位置にある。

決めることが3つある。

落ちたときにどちらへ倒すか。 ここが設計の核である。止める側に倒せば安全だが、自社サーバの障害がそのままClaudeの全停止になる。 通す側に倒せば可用性は保たれるが、その間は検査が効かない。可用性とポリシーのどちらを上に置くかを、先に決めて文書に残す。

書き換えができないことを前提に組む。 伏字にして通す、という運用は取れない。通すか止めるかしかないので、判定ロジックは粗くなりがちである。過検知が多いと現場が使わなくなる。shadow モードで実トラフィックを見てから閾値を決めるのが順当になる。

画像だけの content は検査できない。 生のバイト列が送られないため、文書のスクリーンショットは中身を見られない。 ここは仕様上の穴として認識しておく必要がある。

稟議に書くなら「推論前に自社サーバで遮断できる。ただし判定は二択で、画像は対象外。障害時の挙動は選択制」の3行になる。 できることだけ書くと、運用開始後に穴の説明を求められる。