Claudeの送信を推論前に止める8手順

結論：後追い監査ではなく、推論前のallow・denyに使う

読者の具体的な困りごとは、DLPやCompliance APIで後から違反を見つけても、機密promptがmodelへ届く前に誰が止めるのか説明できないことです。この記事を読むと、shadow、段階rollout、fail-open、fail-closedを業務影響から選び、公開前の停止条件を決められます。

次の行動：停止対象、許容遅延、security server障害時の動作、例外承認者を一行ずつ書いてください。この4点がないままendpointだけ接続すると、誤検知か障害のどちらかで現場が止まります。

Inference hooksが検査する範囲と提供条件

2026年8月11日時点でInference hooksはClaude Enterprise組織向けbetaです。設定にはclaude.aiのorganization:manage permissionが必要で、組み込みのAdmin、Owner、Primary ownerと、同permissionを持つcustom roleが操作できます。一つのhookがclaude.ai、Cowork、Claude Codeのgoverned requestを横断して扱います。Claude Platform組織、Amazon Bedrock、Google Cloud、voice modeは対象外です。

現行eventはpromptです。userが送信すると、Anthropicはconversation transcriptをHTTPS POSTでsecurity serverへ送り、verdictを待ちます。transcriptにはtext、tool callとresult、添付から抽出されたtextが含まれます。一方、raw file、raw image、system prompt、Anthropic内部contextは送られません。画像だけに機密情報があるscreen shotは検査できないため、画像入力を別policyで止める必要があります。

denyされたrequestはmodelへ到達せず、userにはsecurity serverのdeny_reasonと管理者が設定した案内が表示されます。denyはActivity Feedにも記録されます。ただしverdictはallowかdenyだけで、promptの一部を消す、置換する、maskして送ることはできません。redactionが必要ならclient側の前処理と組み合わせます。

shadow・fail-open・fail-closedを5軸で比較する

1. 利用者への影響：shadowはdenyを返してもblockせず、userにも表示しません。policyの精度を現行trafficで測る最初の状態です。
2. 障害時の可用性：fail-openはsecurity serverがtimeoutやerrorでも未検査で推論へ進みます。低risk業務には向きますが、未検査件数を必ず記録します。
3. 機密性：fail-closedはverdictを得られないrequestを止めます。規制情報には強い一方、security server障害がClaude全体の停止になります。
4. 対象率：Requests inspectedは0〜100%です。conversation単位ではなく各requestが一度sampleされるため、同じconversation内でも検査済みと未検査が混在し得ます。
5. 例外：custom roleはexclusionにできますが、machine credential trafficは常に検査されます。例外を恒久運用にせず、期限とownerを付けます。

「最も安全そうだからfail-closed」では判断が足りません。問い合わせ下書きとproduction障害対応では、止まった時の損失が違います。データ分類と業務継続性を同じ表に置き、blockが妥当な領域だけを選びます。

Inference hooksを導入する8手順

1. promptを公開・社内・機密・規制対象へ分け、denyする条件と具体例を10件ずつ用意します。
2. security serverをpublicにrouteできるHTTPS port 443へ置き、redirectなし、HTTP 200、正しいverdict JSONを返すようにします。
3. Organization settingsのData and privacyでAllow for your organizationを有効にします。この操作だけではinspectionは始まりません。
4. endpoint URLと最大16件のcustom headerを登録し、Test connectionでallow・denyの両方を確認します。URL変更時はheader valueが消えるため再入力します。
5. 初回save時に一度だけ表示されるsigning secretをsecret managerへ保管し、Standard Webhooks署名の検証を実装します。
6. ModeをShadow mode、Requests inspectedを小さい割合にし、誤検知、見逃し、p95 latency、endpoint errorを一週間測ります。
7. timeoutを1〜10,000msの範囲で決めます。defaultは5,000msです。実測p99とnetwork余裕を超える値を置き、遅すぎる判定は失敗として扱います。
8. 対象率を段階的に100%へ上げ、業務classごとのfail-open・fail-closedをrelease会議で承認してからEnforce verdictsを切り替えます。

設定反映には約1分かかり、flight中のrequestは旧設定で完了します。切替時刻の前後で同じtest promptを送り、security serverのrequest ID、Activity Feed、user側表示を突合してください。

本番切替前のチェックリスト

• deny条件ごとにtrue positive・false positiveのtestがある
• raw imageが検査されないことをinput ruleで補っている
• signatureのtimestampとreplayを検証する
• header valueをlogへ残さない
• timeoutとretryの合計が予算内である
• fail-open時の未検査requestを数える
• fail-closed時の連絡先と解除ownerが決まっている
• circuit breaker tripの通知を受け取る
• secret rotationの即時cutoverを訓練する
• custom role exclusionに期限がある

endpoint health panelはbest-effortです。zero failures表示だけを正常証拠にせず、自社serverのavailability、Anthropicからのsigned request、synthetic testの三つを監視します。failureが続くとcircuit breakerがtripし、serverは呼ばれなくなります。その後は選択したfailure handlingがinspection対象requestすべてへ適用されるため、fail-closedでは全員が止まる可能性があります。

Inference hooksはinline制御、Compliance APIは事後監査です。どちらか一方ではなく、denyのrequest IDをActivity Feedと自社logでjoinし、「何を止め、何を通し、誰が例外を認めたか」を残します。

よくある質問と次の行動

正式な対象範囲と制限はAnthropic公式Inference hooks概要、endpoint、shadow、timeout、circuit breakerは公式Configuration、deny記録は公式Activity Feedで公開直前にも確認してください。

全体の導入条件はClaude企業security checklist、送信禁止分類は入力してはいけない情報、事後の証跡設計はClaude Code監査logへつなげます。Miraigentの無料診断では、対象data、deny rule、failure handling、例外ownerを一枚の導入判定へ整理します。