送信してから気づく、を止める仕組み
生成 AI の社内導入で、いちばん解きにくいのが「送ってはいけないものが送られる」問題です。ログを見れば分かりますが、分かった時点では既に送信が終わっています。
Anthropic が Claude Enterprise 向けに提供を始めた Inference hooks は、ここに手を入れる機能です。2026 年 8 月 5 日にベータとして公開されました。
仕組みは単純です。公式の説明を引きます。
Every inference request routes through a signed WebSocket connection to a security server. Before the model starts generating, Claude sends the prompt and its surrounding context to your server.
モデルが生成を始める前に、プロンプトとその周辺の文脈が組織側のサーバーへ送られ、判定を受けます。 許可されれば進み、拒否されれば止まります。事後のログではなく、事前の関門です。
何が変わるか
これまでの統制は、大きく 2 つの形しかありませんでした。
| 従来の手段 | 効き方 |
|---|---|
| 利用の可否を決める | 使わせるか、使わせないかの二択 |
| 事後にログを見る | 起きたことは分かるが、止められない |
Inference hooks が埋めるのは、その中間です。使わせたうえで、危ないものだけを止める。 これが技術的に可能になった、というのが今回の変化になります。
自分なら、この差は導入判断そのものを変えると見ています。「全面禁止か全面許可か」の議論が長引く組織は多くありますが、その二択でしか考えられないのは、中間の手段が無かったからです。
対象は chat だけではない
実務で効いてくるのは、対象範囲です。公式には次のように書かれています。
Inference hooks apply to Claude Enterprise surfaces, including tool calls made through MCP connectors, skills, and plugins
対象は chat、Claude Code、Claude Cowork など Enterprise の各サーフェスを横断します。加えて、MCP コネクタやスキル、プラグイン経由のツール呼び出しも含まれます。
ここが重要です。実際の事故は、人が打ち込んだ文字よりも、ツールが取ってきた内容 から起きます。社内のデータベースを読むコネクタ、ファイルを読むツール、外部サービスを叩くプラグイン。これらが返した内容がそのままモデルへ渡ります。
人の入力だけを検査する仕組みでは、この経路は素通りします。そこまで含めて判定に回せる設計になっている点が、他の対策と違うところです。
注意
「チャットに機密を貼らないよう教育している」だけでは、ツール経由の経路は塞がりません。むしろ、そちらのほうが量が多く、本人にも見えていません。
既存の DLP をそのまま使える
判定を行うのは、組織側のサーバーです。公式には連携先として次が挙げられています。
- Netskope
- Palo Alto Networks
- Proofpoint
- Zscaler
- 自前で構築したセキュリティサーバー
既に社内で DLP を運用しているなら、その検査ルールを流用する形になります。 生成 AI 向けに別のルール体系を立ち上げる必要はありません。この点は、稟議を通す側から見ると通しやすい構造です。
逆に言えば、接続しただけでは何も止まりません。 判定のロジックは組織側が持ちます。ここを勘違いすると、「入れたのに漏れた」という話になります。止める基準を決めるのは、あくまで自社です。
DLP をまだ持っていない組織の場合は、順番が逆になります。先に何を止めたいかを決め、それを判定できる仕組みを用意してから接続する形です。
いきなり止めない
導入で失敗するとすれば、最初から拒否で入れるパターンです。正当な業務が止まると、その日のうちに撤回されます。
用意されている段階の仕組みは次のとおりです。
| 機能 | 使いどころ |
|---|---|
| shadow mode (常に許可) | まず何が引っかかるかを観測する |
| ロールベースの除外 | 特定の職種・チームを対象外にする |
| 割合指定のロールアウト | 一部の利用者から順に広げる |
| 失敗時の扱い・タイムアウト | 検査サーバーが落ちたときの挙動を決める |
順番としては、次のようになります。
- shadow mode で観測する。 止めずに、何が判定に引っかかるかだけを見ます
- 誤検知を潰す。 業務上正当なものが引っかかっていれば、ルールを直します
- 一部から止め始める。 割合指定かロール指定で、狭い範囲に適用します
- 範囲を広げる。 問い合わせが増えなければ、対象を増やします
1 番を飛ばさないでください。実際のプロンプトを見ないかぎり、どのルールが誤検知するかは分かりません。 机上で組んだルールは、必ずどこかで正当な業務を止めます。
検査サーバーが落ちたらどうするか
見落とされがちですが、決めておく必要があるのが失敗時の扱いです。検査サーバーが応答しないとき、通すのか止めるのか。
通す設計なら業務は止まりませんが、その間は検査が効きません。止める設計なら安全ですが、検査サーバーの障害がそのまま業務の停止に直結します。
どちらが正しいかは、扱っている情報の性質で決まります。ただ、決めていない状態がいちばん悪いです。 障害が起きてから慌てて判断すると、たいてい業務を優先して通す側に倒し、そのまま戻し忘れます。
FIXIT
DodaiFIXITDodai私物の端末から別のサービスへ貼る経路は残ります。そこはルールの仕事です。
止めたあと、使う人に何が見えるか
技術の話とは別に、決めておく必要があるのが利用者への見え方です。止まったことだけが伝わって理由が分からないと、問い合わせが増えます。
最低限、次の 3 つが伝わる形にしてください。
- 止まったこと自体
- どういう種類のものが引っかかったか
- 業務上必要な場合、誰に相談すればよいか
3 番が抜けると、利用者は迂回路を探し始めます。 私物端末や別のサービスへ流れる動きは、たいていここから起きます。統制を強めた結果、見えない経路が増えるという逆転が起きうる部分です。
例外を認める窓口を用意しておくのが実務的です。申請の手間があっても、経路が見えているほうが管理としては健全です。
塞がる経路と、残る経路
導入の前に、整理しておくべきことがあります。この仕組みで塞がるのは、Claude Enterprise を通る送信だけです。
| 経路 | Inference hooks の効果 |
|---|---|
| 業務端末から Claude Enterprise | 検査が効く |
| Claude Code からツール経由の読み取り | 検査が効く |
| 私物端末から別サービスへ貼り付け | 効かない |
| メールや外部ストレージへの持ち出し | 効かない |
下 2 行が残ります。ここは技術ではなく、利用ルールと教育の領域です。技術的な統制は入口を絞るものであって、ルールを置き換えるものではありません。
導入後に「もう対策済み」と説明してしまう組織を見ますが、それは正確ではありません。塞がった経路と残った経路を書き出しておくと、次に手を入れる場所も見えます。社内ルールの側は 生成 AI 情報漏洩対策と社内利用チェックリスト に整理しています。
検査を挟むと遅くなるか
生成の前に外部のサーバーへ問い合わせる以上、応答までの時間は伸びます。どの程度かは、自社の検査サーバーの速さで決まります。 仕組みの側ではなく、繋いだ先の性能の話です。
ここで効いてくるのがタイムアウトの設定です。長く待てば検査は確実になりますが、待たされた分だけ体感が悪くなります。短くすれば快適ですが、時間内に返らない判定が増えます。
実務では、まず shadow mode の期間に応答時間を実測する のが確実です。止めない状態でも問い合わせは飛ぶので、そこで分布が取れます。机上で秒数を決めるより、実測してから決めるほうが早く落ち着きます。
コツ
応答時間は平均ではなく、遅いほうの裾を見てください。平均が速くても、10 回に 1 回待たされる状態は「遅い」と受け取られます。
なお、体感の悪化は静かに効きます。あからさまに止まるより、少し遅い状態が続くほうが、使われなくなる原因になります。 導入後しばらくは、利用量が落ちていないかも見ておいてください。
稟議で聞かれること
セキュリティ部門や法務に説明するとき、聞かれる点はだいたい決まっています。先に答えを用意しておくと早く進みます。
「送られる内容はどこまでか」。 プロンプトと、その周辺の文脈です。生成が始まる前の段階で送られます。
「判定は誰がするのか」。 組織側のサーバーです。Anthropic 側が内容を判断して止めるのではなく、自社のルールで判定します。
「既存の製品は使えるのか」。 主要な DLP 製品との連携が示されています。自前構築も可能です。
「止まったときに業務はどうなるのか」。 失敗時の扱いを設定で決められます。ここは事前に決めておく項目です。
「まず試せるのか」。 shadow mode があるので、止めずに観測から始められます。
段階的に導入できることが示せると、話は通りやすくなります。「全面適用しかない」と受け取られると、決裁は止まります。
何を止めるルールにするか
接続しても、判定の中身が無ければ何も起きません。最初に入れるルールとして現実的なのは、次の 3 種類です。
| 種類 | 例 | 誤検知のしやすさ |
|---|---|---|
| 形が決まっているもの | 個人番号・クレジットカード番号・鍵の形式 | 低い |
| 社内で定義済みの機密区分 | 文書の区分ラベル、特定の識別子 | 中程度 |
| 文脈で判断するもの | 「未公開の案件名が含まれる」など | 高い |
上から順に入れてください。 形が決まっているものは判定が確実で、誤検知もほとんど出ません。ここだけでも、事故として大きいものは拾えます。
いちばん下は、入れたくなりますが後回しが無難です。文脈での判断は誤検知が多く、業務を止めた回数が増えると、仕組みそのものへの信用が落ちます。 上 2 つが安定して回るようになってから足すのが順当です。
なお、鍵やトークンの形式は最優先で入れる価値があります。ツールが設定ファイルを読んでそのまま渡す経路は現実に存在し、本人にも見えていません。
ベータであることの扱い
現時点ではベータ提供です。本番のガバナンスをこの仕組みだけに寄せるのは、まだ早いと考えます。
理由は 2 つあります。1 つは、仕様が変わりうること。もう 1 つは、障害時の挙動について自社での実績がまだ無いことです。
現実的な位置づけは、既存の統制に足す層 です。今あるルールや教育を減らさずに重ねる形にしておけば、仕様が変わっても足元は崩れません。逆に、これを理由に既存の統制を緩めると、変更があったときに一気に穴が開きます。
検証としては、まず対象を絞った環境で shadow mode を回し、応答時間と誤検知の傾向を自社のデータで掴むところまでを目標にするのが妥当です。
いつ検討するか
すべての組織にいま必要な機能ではありません。判断の軸は 2 つです。
1 つは、Claude Enterprise を使っているか。この機能は Enterprise 向けです。他のプランでは対象外なので、まず契約形態の確認から始まります。
もう 1 つは、ツール経由で社内データを読ませているか。チャットで質問するだけの使い方であれば、優先度はそこまで高くありません。コネクタやスキルで社内システムに繋ぎ始めた段階から、検討する価値が出てきます。
全社展開の全体像は Claude Code 全社導入 完全ガイド にまとめています。ガバナンス設計の一部として、この機能をどこに置くかを考えるのが実務的です。
順序としては、利用範囲を決め、ルールを文書にし、そのうえで技術的な統制を足す のが崩れません。逆に、技術を先に入れてルールを後回しにすると、何を止めるべきかが決まらないまま設定だけが残ります。社内規程の作り方は AI 就業規則の改定ポイントと社内ルール雛形 を参照してください。
まとめ
- Inference hooks は、生成が始まる前にプロンプトと文脈を組織側のサーバーへ送り、判定を受ける仕組み
- chat・Claude Code・Claude Cowork を横断し、MCP コネクタやスキル経由のツール呼び出しも対象になる
- 判定するのは組織側。既存の DLP 製品を流用でき、自前構築もできる
- shadow mode で観測してから、範囲を絞って止め始める。いきなり拒否で入れない
- 検査サーバーが落ちたときに通すか止めるかは、事前に決めておく
- 塞がるのはこの経路だけ。私物端末や別サービス経由は、ルールと教育の領域として残る
- 現時点ではベータ。既存の統制を置き換えるのではなく、上に重ねる層として扱う