管理推論フック

推論フックを設定する

Copy page



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

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

始める前に

次のものが必要です。

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

推論フックをセットアップする

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

• オフ： 判定を適用するがオフの場合、AIセキュリティサーバーには一切接続されず、プロンプトは検査されません。
• シャドウ： 判定を適用するがオンで、モードがシャドウモードに設定されている場合、AIセキュリティサーバーはプロンプトを受信して判定を返しますが、何もブロックされません。
• 適用中： 判定を適用するがオンで、モードがリクエストを許可するまたはリクエストをブロックに設定されている場合、拒否判定によってリクエストがブロックされます。

以下の手順では、新しい設定をオフから適用中の状態にします。

1. 1

   組織で推論フックを許可する

   claude.ai > 組織設定 > データとプライバシーに移動し、推論フックセクションを見つけます。組織に対して許可するをオンにします。

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

2. 2

   推論フックの設定ページを開く

   引き続きデータとプライバシーで、推論フックセクションを開いて推論フックの設定ページに移動します。このページは設定ナビゲーション内の独立した項目ではなくデータとプライバシーの下に配置されているため、パンくずリストにはデータとプライバシー / 推論フックと表示されます。エンドポイントを保存するまで、ページにはプロンプトがまだ検査されていないという警告が表示され、判定を適用するはエンドポイントが必要バッジ付きでオフのままです。

3. 3

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

   設定をクリックしてエンドポイントを設定するダイアログボックスを開き、エンドポイント URLを入力します。これは判定リクエストを受信するhttps:// URLです。https:// URLのみが受け付けられます。

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

4. 4

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

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

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

5. 5

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

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

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

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

   よくある失敗結果：

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

6. 6

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

   障害時の処理の下でモードを設定し、AIセキュリティサーバーに到達できない場合や判定がタイムアウトした場合の動作を選択します。

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

   ドロップダウンメニューの3番目のオプションであるシャドウモードは、障害ポリシーではなくロールアウト用のツールです。シャドウモードを参照してください。

   次に、プロンプト判定タイムアウト（ms）を設定します。1〜10,000msで、デフォルトは5,000msです。この時間枠はやり取り全体をカバーし、これより遅い判定はサーバーに到達できない場合と同様に扱われるため、サーバーが確実に満たせる最小の値を設定してください。

   このセクションの変更は、変更するたびに保存されます。最初の保存時のデフォルトはリクエストを許可すると5,000msです。

7. 7

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

   ロールアウトの下で検査対象リクエスト（%）を設定すると、AIセキュリティサーバーを立ち上げている間、リクエストの一定割合に対して検査を実行できます。値の範囲は0〜100で、100ではすべてを検査し、0では検査がオフになります。

   各リクエストは会話ターン全体に対して一度だけ抽選されるため、1つの会話がターンをまたいで部分的に検査される場合があります。サンプリングされた割合に含まれないリクエストは、障害時の処理がリクエストをブロックに設定されている場合でも、検査なしで処理されます。

8. 8

   「判定を適用する」をオンにする

   最初は誰もブロックせずにライブトラフィックに対する判定を評価するには、適用をオンにする前にモードをシャドウモードに設定します（手順6）。シャドウモードを参照してください。

   判定を適用するをオンにすると、管理対象のすべてのプロンプトについて、ClaudeがAIセキュリティサーバーの判定に従うようになります。その後、障害処理の選択内容が再表示されるダイアログボックスで確認します。変更がすべてのAnthropicサーバーに反映されるまで約1分かかります。すでに処理中のリクエストは以前の設定のまま完了します。オフにすると、同じく約1分以内にAIセキュリティサーバーへのプロンプト送信が停止します。設定は保持されます。

   判定を適用するの下にあるValidate tool callsは、Claudeの各応答に含まれるツール呼び出しもAIセキュリティサーバーに送信し、実行前にその判定を待ちます。ツール呼び出しフレームを参照してください。新しい設定ではデフォルトでオンになっています。判定を適用するがオフの間は効果がなく、判定を適用すると同様に、変更がすべてのAnthropicサーバーに反映されるまで約1分かかります。

シャドウモード

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

シャドウモードを使用するには、障害時の処理の下でモードをシャドウモードに設定し、判定を適用するをオンにしてプロンプトがAIセキュリティサーバーに送られるようにします。有効な間、設定ページにはシャドウモード — ブロックなしバッジが表示されます。シャドウモードを終了するには、モードをリクエストを許可するまたはリクエストをブロックに戻します。適用がオンになっていれば、判定が再び適用されます。

除外設定

Who is inspected（検査対象）の下でLimit by role（ロールで制限）をオンにすると、メンバーが推論フックの対象外となるロールを選択できます。これらのロールのプロンプトはAIセキュリティサーバーに送信されません。除外できるのは組織が作成したカスタムロールのみで、組み込みロールは選択肢に表示されません。プレースホルダーに除外するロールを選択と表示されているロールセレクターでロールを選択し、各ロールを持つユーザーはロール管理ページ（ロールを管理）で管理します。除外の変更にはID管理権限が必要です。リストはデフォルトで空であり、除外されたロールがない場合、Inspect（検査）がOnly selected roles（選択したロールのみ）に設定されていない限り、管理対象のすべてのリクエストが検査されます。

除外はユーザーのインタラクティブセッションに適用されます。除外リストへの変更は、組織のアクティビティフィードにロール権限の変更（rbac_role_permission_addedおよびrbac_role_permission_removed）として記録されます。

選択したロールのみを検査する

Who is inspectedセクションのすべての項目は、1つのスイッチLimit by roleの背後にあります。スイッチをオンにすると、InspectはEveryone except excluded rolesの状態で始まり、上述のとおりその下で除外ロールを選択します。

まず組織の一部で推論フックを試すには、Limit by roleをオンにし、InspectをOnly selected rolesに設定して、開いたダイアログボックスでロールを選択します。それ以降は、カスタムロールに設定され、かつ選択したロールが割り当てられているメンバーのみが検査されます。ユーザーやオーナーなど、他のロールに設定されているメンバーは、選択したロールが割り当てられていても検査されません。オーナーまたはプライマリオーナーに設定されている場合は、自分自身も含まれます。切り替える前に、除外ロールをすべて削除してください。組織は除外と選択ロールのどちらか一方を使用し、両方を使用することはできません。切り替え後は、Inspectの下にあるロールセレクターでロールを追加または削除します。全員の検査に戻すには、Limit by roleをオフにします。確認すると、すべての除外ロールが削除され、Only selected rolesがオフになります。

Only selected rolesが設定されている間：

• 機能アクセスがすべての機能またはすべて一般提供中であるカスタムロールも、他のロールと同様に、選択した場合にのみ対象となります。
• カスタムロールに設定されたメンバーのうち、選択したロールが割り当てられているメンバーがいない場合、どのメンバーも検査されません。
• APIキーで行われたリクエストやSlackでのClaude Tagの会話など、メンバーが関与しないリクエストは検査されません。

Inspectの変更と検査対象ロールの変更は、組織のアクティビティフィードに記録されます。

カスタムブロック済みプロンプトメッセージ

カスタムブロック済みプロンプトメッセージの下で、AIセキュリティサーバーがリクエストを拒否したときにエンドユーザーに表示されるエラーに追加される、最大500文字のカスタムテキストを設定します（通常は連絡先や例外の申請先など）。最終的なメッセージは、AIセキュリティサーバーのリクエストごとのdeny_reason（存在する場合）、空行、そしてこのテキストの順になります。カスタムテキストが設定されていない場合は、管理者に連絡するようユーザーに案内する組み込みのデフォルトが使用されます。追加メッセージを完全にオフにして、ユーザーにdeny_reasonのみを表示させることもできます。

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

推論フック設定ページのエンドポイントヘルス領域には、以下が表示されます。

• エンドポイントのステータス： Healthy、Tripped、適用停止中、またはエンドポイントが保存される前の未設定。
• 1 分あたりの失敗数： 過去2分間のWebhook失敗数の平均。
• ブロック率： AIセキュリティサーバーの判定に占める拒否の割合。ロールアウト率が100未満の間に表示されます。
• サーキットブレーカーが作動しました： サーキットブレーカーが作動したことがある場合、最後に作動した日時。
• 最近のエラー： 各エントリには、失敗が発生した日時、エラータイプ、カテゴリが表示されます。カテゴリは、エンドポイントまたはエンドポイントへの接続に問題がある場合はwebhook_error、Anthropicのシステム内部で失敗した場合はrelay_errorです。DlpWebhookStatusErrorエントリには、AIセキュリティサーバーが返したHTTPステータスと、Anthropicが送信したリクエスト本文のサイズ（HTTP 413 · 1.3 MBなど）も表示されることがあります。エントリにリクエスト内容やエンドポイントURLが含まれることはありません。リストには直近10件の失敗が保持され、最後の失敗から1時間後にクリアされます。

最近のエラーのエラータイプの意味は次のとおりです。

シャドウモードでは、どのエラーもサーキットブレーカーのカウント対象になりません。

このパネルはベストエフォートです。Anthropicがカウンターを読み取れない場合、パネル自体のエラーではなく、失敗ゼロ・エラーなしと表示されます。そのため、パネルが正常に見えることだけでは、AIセキュリティサーバーが正常であることの証明にはなりません。1 分あたりの失敗数は、サーキットブレーカーを作動させることのないネットワークエラーやDNSエラーを含むすべての失敗をカウントするため、サーキットブレーカーが作動しましたの欄が空のままでも高い値になる場合があります。

サーキットブレーカー

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

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

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

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

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

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

リクエスト署名の下にあるシークレットをローテートをクリックして、署名シークレットを置き換えます。組織にまだシークレットがない場合、同じボタンはシークレットを生成と表示され、最初のシークレットを作成します。ローテーションは即時切り替えです。新しいシークレットが生成されて一度だけ表示され、古いシークレットは取得できなくなり、両方のシークレットで署名されるリクエストは存在しないため、頼れる重複期間はありません。

以前のシークレットで署名されたリクエストが、ローテーション後も短時間届く可能性があります。AIセキュリティサーバーが切り替えをどのように処理すべきかについては、署名を検証するで説明しています。

監査証跡

推論フックのアクティビティは、組織のアクティビティフィードに記録されます。設定の変更、拒否、サーキットブレーカーの作動、および判定を取得できなかったために検査なしで処理されたリクエストが対象です。最後の種類は、判定を適用するがオンでモードがリクエストを許可するの場合にのみ記録されます。その理由は、endpoint_timeout、AIセキュリティサーバーの呼び出しにおけるその他の問題の場合はendpoint_error、Anthropic側の失敗の場合はinternal_errorです。リクエストをブロックまたはシャドウモードでは、失敗したリクエストは個別に記録されません。サーキットブレーカーの自動復旧は、どのモードでも記録されません。サーキットブレーカーが作動している間は、リクエストごとの推論フックアクティビティは記録されません。作動アクティビティが、その期間に関するフィードの記録となります。拒否の記録には、各拒否を自社システム内の対応する記録と結合できる識別子が含まれます。

推論フックをオフにする

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

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

次のステップ