管理推論フック

Inference hooksを設定する

Copy page



Claude Enterprise組織でInference hooksを許可し、AIセキュリティサーバーを接続して、適用、障害時の処理、ロールアウトを制御します。

Inference hooksは、組織からのプロンプトを、選択した「AI security server」（AIセキュリティサーバー）に送信します。そして、Claudeが処理する前に、各リクエストを許可または拒否の「verdict」（判定）が返るまで保留します。このページでは、機能の有効化、サーバーの接続、適用の制御について順を追って説明します。Inference hooksの概要と使用すべき場面については、Inference hooksの概要を参照してください。AIセキュリティサーバー自体を構築するには、Inference hooks統合を開発するを参照してください。

始める前に

次のものが必要です。

• claude.aiでのorganization:manage権限。この権限を持つのはOwnerロールとPrimary ownerロールのみで、Adminロールにはありません。
• 判定リクエストを受け付けるAIセキュリティサーバーのHTTPSエンドポイント。ポート443のhttps:// URLで、パブリックにルーティング可能なホスト上にあり、リダイレクトなしで到達できる必要があります。リバーストンネルのホスト（ngrokや同様のトンネルサービス）はサポートされていません。Anthropicのネットワークポリシーによってブロックされるためです。トンネル経由でテストせず、自分が管理するドメインでサーバーをホストしてください。ホスティング要件の全体、およびサーバーの構築方法と署名付きリクエストの検証方法については、Inference hooks統合を開発するを参照してください。

Inference hooksをセットアップする

適用状態は3つあります。

• off：Enforce verdictsがオフの状態です。AIセキュリティサーバーには一切接続されず、プロンプトは検査されません。
• shadow：Enforce verdictsがオンで、ModeがShadow modeに設定された状態です。AIセキュリティサーバーはプロンプトを受信して判定を返しますが、何もブロックされません。
• enforcing：Enforce verdictsがオンで、ModeがAllow the requestまたはBlock the requestに設定された状態です。拒否判定が出るとリクエストはブロックされます。

以下の手順では、新しい設定をoffからenforcingへ移行します。

1. 1

   組織でInference hooksを許可する

   claude.ai > Organization settings > Data and privacyに移動し、Inference hooksセクションを見つけます。Allow for your organizationをオンにします。

   これをオンにすると、Inference hooksの設定ページが利用可能になります。同時に、Enforce verdictsは常に強制的にオフになります。そのため、機能を許可しただけで検査が始まることはありません。以前に適用がオンだった設定であっても、最後の手順でEnforce verdictsを再びオンにするまでは検査されません。

2. 2

   Inference hooksの設定ページを開く

   引き続きData and privacyで、Inference hooksセクションを開いてInference hooksの設定ページに移動します。このページは設定ナビゲーションの独立した項目ではなく、Data and privacyの下にあります。そのため、パンくずリストはData and privacy / Inference hooksと表示されます。エンドポイントを保存するまで、ページにはプロンプトがまだ検査されていないという警告が表示されます。また、Enforce verdictsはオフのままで、Requires endpointバッジが付きます。

3. 3

   エンドポイントを設定する

   ConfigureをクリックしてSet up endpointダイアログを開き、Endpoint URLを入力します。これは判定リクエストを受信するhttps:// URLです。受け付けられるのはhttps:// URLのみです。

   この時点でダイアログが求めるのはこれだけです。カスタムリクエストヘッダーは手順5で、障害時の処理は手順6で設定します。Nextをクリックして保存します。エンドポイントを保存すると、ボタンの表示はEditに変わります。

4. 4

   署名シークレットを保管する

   最初の保存時に、Webhookの「signing secret」（署名シークレット）が生成され、一度だけ表示されます。Nextをクリックする前に、シークレットをコピーして安全に保管してください。シークレットは後から取得できず、ローテーションすることしかできません。

   AIセキュリティサーバーは、このシークレットを使用して、受信するすべてのリクエストの署名を検証します。これには次の手順の接続テストも含まれます。検証手順については、署名を検証するを参照してください。

5. 5

   リクエストヘッダーを追加して接続をテストする

   署名シークレットのダイアログでNextをクリックすると、エンドポイントのダイアログが再び開きます。今度は次の2つのコントロールが追加されています。

   • Custom request headers： すべての判定リクエストとともに送信される静的ヘッダーで、最大16個まで設定できます。AIセキュリティサーバーはこれを使って呼び出し元を認証できます。
     • ヘッダーの値は暗号化して保存され、二度と表示されません。保存後に表示されるのはヘッダー名のみです。
     • 値は書き込み専用のため、ヘッダーへの変更を保存するには、すべての値を再入力する必要があります。
     • エンドポイントURLを変更すると、保存されているヘッダー値はすべて消去されます。これにより、認証情報が新しい送信先に送られることはありません。URLを変更した後は、値を再入力してください。
     • ヘッダー名には標準的なHTTPトークン文字を使用し、_ではなく-を使う必要があります。
     • ヘッダー名は予約済みの名前と重複してはいけません。予約済みの名前には、Content-*やHostなどのリクエストフレーミングヘッダー、プロキシヘッダーとCookieヘッダー、X-Forwarded-*などのクライアントアドレスヘッダー、webhook-*署名ヘッダー、X-Anthropic-*プレフィックスが含まれます。
     • 値は印字可能なASCII文字である必要があります。
   • Test connection： Claudeは、合成テストプロンプトを送信します。送信先は、保存済みの値ではなく、フォームに現在入力されているURLとヘッダーです。そのため、テストの前に保存済みのヘッダー値を再入力してください。成功すると、AIセキュリティサーバーがテストプロンプトに対して許可と拒否のどちらの判定を返したかが結果に表示されます。これにより、適用を開始する前に、すべてを拒否するデフォルト設定に気付くことができます。

   Saveをクリックして、入力したヘッダーを保存します。

   よくある失敗結果：

   結果	確認事項
   URL rejected	URLが構造チェックに失敗しました。ポート443のhttps:// URLを使用してください。
   Private or internal IP	ホストがプライベートアドレスまたは内部アドレスに解決されます。パブリックにルーティング可能なホストを使用してください。
   Timeout	AIセキュリティサーバーがタイムアウト内に判定を返しませんでした。
   Transport error	DNS解決、TLSハンドシェイク、または接続が失敗しました。
   Non-200 status	AIセキュリティサーバーが200以外のステータスで応答しました。判定はHTTP 200で返す必要があります。リダイレクトは追跡されず、失敗として扱われます。
   Unparseable response	AIセキュリティサーバーは応答しましたが、本文が有効な判定ではありません。
   Signing secret required	組織に署名シークレットがないため、テストが署名なしで送信されることになります。Request signingの下にあるGenerate secretをクリックしてから、再度テストしてください。

6. 6

   障害時の処理とタイムアウトを選択する

   Failure handlingの下でModeを設定します。これにより、AIセキュリティサーバーに到達できない場合や判定がタイムアウトした場合の動作を選択します。

   • Block the request： AIセキュリティサーバーが判定を返せない場合に推論を停止します（「fail closed」（フェイルクローズ））。
   • Allow the request： 検査なしでリクエストをモデルに進めます（「fail open」（フェイルオープン））。

   ドロップダウンの3つ目のオプションであるShadow modeは、障害時のポリシーではなく、ロールアウトのためのツールです。シャドウモードを参照してください。

   次に、Prompt verdict timeout (ms)を設定します。範囲は1〜10,000msで、デフォルトは5,000msです。この時間枠はやり取り全体に適用されます。これより遅い判定は、サーバーに到達できない場合と同じ扱いになります。そのため、サーバーが確実に満たせる最小の値を設定してください。

   このセクションの変更は、変更した時点で保存されます。最初の保存時のデフォルトはAllow the requestと5,000msです。

7. 7

   ロールアウト率を選択する

   Rolloutの下でRequests inspected (%)を設定します。これにより、AIセキュリティサーバーを立ち上げている間、一定の割合のリクエストに対してのみ検査を実行できます。値の範囲は0〜100です。100ではすべてが検査され、0では検査がオフになります。

   抽選は、会話のターン全体に対して1回だけ行われます。そのため、1つの会話の中で、検査されるターンとされないターンが混在することがあります。抽出された割合に含まれないリクエストは、検査なしで処理されます。これは、障害時の処理がBlock the requestに設定されている場合でも同じです。

8. 8

   Enforce verdictsをオンにする

   最初は誰もブロックせずに、実際のトラフィックで判定を評価したい場合があります。その場合は、適用をオンにする前にModeをShadow modeに設定してください（手順6）。シャドウモードを参照してください。

   Enforce verdictsをオンにすると、管理対象のすべてのプロンプトについて、ClaudeはAIセキュリティサーバーの判定に従うようになります。オンにしたら、ダイアログで確認します。ダイアログには、選択した障害時の処理が改めて表示されます。

   変更がすべてのAnthropicサーバーに反映されるまで、約1分かかります。すでに処理中のリクエストは、以前の設定のまま完了します。オフにすると、同じく約1分以内に、プロンプトはAIセキュリティサーバーに送信されなくなります。設定は保持されます。

シャドウモード

「shadow mode」（シャドウモード）では、何もブロックせずに、実際のトラフィックに対してフックを実行します。AIセキュリティサーバーは、適用時とまったく同じように、管理対象のプロンプトを受信して判定を返します。ただし、何もブロックされません。サーバーが拒否した場合や到達できない場合でも、すべてのリクエストはモデルに進み、エンドユーザーには何も表示されません。適用を開始する前に、組織の実際のトラフィックに合わせてポリシーを調整するために使用してください。

シャドウモードを使用するには、Failure handlingの下でModeをShadow modeに設定します。次に、Enforce verdictsをオンにして、プロンプトがAIセキュリティサーバーに送られるようにします。シャドウモードが有効な間、設定ページにはShadow mode — not blockingバッジが表示されます。シャドウモードを終了するには、ModeをAllow the requestまたはBlock the requestに戻します。適用がオンであれば、判定は再び適用されます。

除外

Exclusionsの下で、Inference hooksの対象外とするロールを選択します。選択したロールのメンバーのプロンプトは、AIセキュリティサーバーに送信されません。

• 除外できるのは、組織が作成したカスタムロールのみです。組み込みロールは選択肢に表示されません。
• ロールはロールセレクターで選択します。セレクターのプレースホルダーにはSelect roles to excludeと表示されます。
• 各ロールを誰が持つかは、ロール管理ページ（Manage roles）で管理します。
• 除外設定を変更するには、ID管理の権限が必要です。
• リストはデフォルトで空です。除外するロールがない場合、管理対象のすべてのリクエストが検査されます。

除外は、ユーザーの対話型セッションに適用されます。マシン認証情報で認証されたトラフィックは、常に検査されます。除外リストへの変更は監査証跡に記録されます。

ブロック時のカスタムメッセージ

Custom blocked prompt messageの下で、最大500文字のカスタムテキストを設定できます。このテキストは、AIセキュリティサーバーがリクエストを拒否したときにエンドユーザーに表示されるエラーに追加されます。通常は、連絡先や例外の申請先を記載します。

最終的なメッセージは、次の順で構成されます。

1. AIセキュリティサーバーがリクエストごとに返すdeny_reason（存在する場合）
2. 空行
3. このカスタムテキスト

カスタムテキストが設定されていない場合は、管理者に連絡するようユーザーに案内する組み込みのデフォルトメッセージが使用されます。追加メッセージを完全にオフにして、ユーザーにdeny_reasonのみを表示することもできます。

AIセキュリティサーバーを監視する

Inference hooks設定ページのエンドポイントヘルス領域には、次の情報が表示されます。

• Endpoint status： Healthy、Tripped、Not enforcingのいずれかです。エンドポイントを保存する前はNot configuredと表示されます。
• Failures per minute： 過去2分間のWebhook失敗数の平均です。
• Block rate： AIセキュリティサーバーの判定に占める拒否の割合です。ロールアウト率が100未満の間に表示されます。
• Circuit breaker tripped： ブレーカーが作動したことがある場合、最後に作動した日時です。
• Recent errors： 各エントリは、タイムスタンプ、エラーの種類、1行の理由のみに絞られています。エントリにリクエストの内容やエンドポイントURLが含まれることはありません。

このパネルはベストエフォートで提供されます。Anthropicがカウンターを読み取れない場合、パネルはエラーを表示する代わりに、失敗ゼロ・エラーなしと表示します。そのため、パネルが正常に見えても、それだけではAIセキュリティサーバーが正常である証拠にはなりません。

また、Failures per minuteはすべての失敗をカウントします。これには、サーキットブレーカーを作動させないネットワークエラーやDNSエラーも含まれます。そのため、Circuit breaker trippedが空のままでも、この値が高くなることがあります。

サーキットブレーカー

AIセキュリティサーバーに起因するWebhookの失敗が続くと、「circuit breaker」（サーキットブレーカー）が作動し、適用が停止します。サーバーには接続されなくなり、検査対象のすべてのリクエストにFailure handlingの選択が適用されます。Block the requestを選択している場合、ブレーカーがリセットされるまで、組織のユーザーはブロックされます。ブレーカーが作動すると、claude.aiの通知センターで管理者にも通知されます。

各作動は、組織のActivity Feedにもinference_hooks_circuit_breaker_trippedアクティビティとして記録されます。これにより、セキュリティチームやベンダーは、すでに運用している監視の仕組みで作動時にアラートを出せます。たとえば、フィードを取り込むSIEMなどです。アクティビティは、影響を受けたリクエストごとではなく、作動ごとに1件記録されます。記録するには、組織でCompliance APIが有効になっている必要があります。Compliance APIをセットアップするを参照してください。

復旧するには、サーバーを修正してからEnforce verdictsを再びオンにして、ブレーカーをリセットします。

ブレーカーは自動的にリセットされることもあります。作動から10分後以降、Anthropicはバックグラウンドでサーバーにテストリクエストを送信し、サーバーが復旧したかどうかを確認します。確認の頻度は最大で約1分に1回で、ユーザーのリクエストは使用されません。サーバーが有効な判定（許可または拒否）で応答すると、ブレーカーはリセットされ、適用が再開されます。それ以外の場合、ブレーカーは作動したままで、確認が続けられます。

自動復旧が実行されるのは、作動以降にInference hooksの設定が変更されていない間のみです。作動後にInference hooksの設定を変更すると、確認は停止し、ブレーカーは自動的にリセットされなくなります。これには署名シークレットのローテーションも含まれます。その場合は、サーバーを修正したらEnforce verdictsを再びオンにしてください。

また、自動復旧が適用されるのは作動時のみです。自分でEnforce verdictsをオフにした場合、再びオンにするまで適用はオフのままです。

署名シークレットをローテーションする

署名シークレットを置き換えるには、Request signingの下にあるRotate secretをクリックします。組織にまだシークレットがない場合、同じボタンはGenerate secretと表示され、最初のシークレットを作成します。

ローテーションは即時に切り替わります。

• 新しいシークレットが生成され、一度だけ表示されます。
• 古いシークレットは取得できなくなります。
• 両方のシークレットで署名されるリクエストはありません。そのため、頼りにできる重複期間はありません。

ローテーション後も、以前のシークレットで署名されたリクエストが短時間届くことがあります。AIセキュリティサーバーでの切り替えの処理方法については、署名を検証するを参照してください。

監査証跡

Inference hooksのアクティビティは、組織のActivity Feedに記録されます。記録される内容は次のとおりです。

• 設定の変更
• 拒否
• サーキットブレーカーの作動
• 障害時の処理の設定に従って検査なしで処理されたリクエスト

サーキットブレーカーが作動している間は、リクエストごとのInference hooksアクティビティは記録されません。その期間については、作動アクティビティがフィード上の記録となります。拒否の記録には識別子が含まれており、各拒否を自社システム内の対応する記録と結び付けることができます。

Inference hooksをオフにする

オフには2つのレベルがあります。

• Enforce verdictsをオフにする（Inference hooks設定ページ）：約1分以内に、組織からのプロンプトはAIセキュリティサーバーに送信されなくなります。すでに処理中のリクエストは、以前の設定のまま完了します。設定ページは引き続き利用できるため、AIセキュリティサーバーの作業中に適用を一時停止する場合に使用してください。
• Allow for your organizationをオフにする（Data and privacy設定）：プロンプトは検査されなくなり、再びオンにするまでInference hooksの設定は利用できなくなります。どちらの場合も、エンドポイントの設定、カスタムヘッダー、署名シークレットは保持されます。再びオンにすると、Enforce verdictsは強制的にオフになり、作動中のサーキットブレーカーはクリアされます。準備ができたら、適用を再びオンにしてください。

次のステップ