Inference hooksのRecent errorsを逆引き — DlpWebhookエラー7種

Inference hooksの設定ページにあるRecent errorsには、DlpWebhookTimeoutError · webhook_errorのような一行が並びます。末尾のカテゴリはwebhook_errorかrelay_errorの2種類で、エラー名は全部で7種類です。この記事は、画面に出た名前から原因と直し先を引くための逆引き表です。

Recent errorsは、Inference hooksの「エンドポイント健全性パネル」に載る項目の1つです。各エントリには失敗した時刻・エラー種別・カテゴリが入り、リクエストの本文やエンドポイントURLは含まれません。一覧に残るのは直近10件の失敗で、最後の失敗から1時間たつと空になります。原因を直した直後も、1時間は古いエラーが表示され続けます。

仕組みの全体像はInference hooksとは、パネルのほかの項目やShadow modeは設定手順の記事にまとめています。

まずカテゴリで自社側かAnthropic側かを切り分ける

カテゴリは、直す場所を決める最初の分岐です。

webhook_errorは、エンドポイント側の問題か、エンドポイントまでの接続の問題を指します。自社のAIセキュリティサーバー、DNS、証明書、ネットワーク設定、設定ページのURLが調査の対象です。

relay_errorは、Anthropicのシステム内部で起きた失敗を指します。このとき自社のサーバーには、たいてい接続していません。サーバーのログに痕跡がないのにrelay_errorだけが増えている場合、サーバー側を調べても原因は見つかりません。

エラー名はDlpWebhookで始まりますが、DLP(情報漏えい防止)専用の機能という意味ではありません。パネルに出る名前がこの接頭辞を持っている、というだけです。

7種のエラーを原因から引く

次の表は、エラー名・カテゴリ・原因・サーキットブレーカーへの加算をまとめたものです。

最後の列は後で使います。

TimeoutError: verdictが間に合っていない

設定したPrompt verdict timeout (ms)の中にverdictが返らなかった失敗です。設定できる範囲は1〜10,000msで、初期値は5,000msです。この時間はやり取り全体にかかる予算で、超えた応答は「サーバーに届かなかった」場合と同じ扱いになります。

見る場所は2つです。サーバーの処理時間と、タイムアウトの設定値です。判定に外部APIや大きなモデルを使うサーバーは、応答が遅くなりやすい構成です。サーバーが確実に返せる最短の値に設定する、というのが設定画面の趣旨です。単に値を大きくして症状を消す使い方は、ユーザーの待ち時間をそのまま延ばします。

StatusError: 200以外は、拒否ではなく失敗になる

AIセキュリティサーバーが200以外のステータスを返した失敗です。リダイレクトは追跡されず、失敗として数えられます。

実装でやりがちなのは、拒否したいときに403を返すことです。拒否は、200の本文に"action": "deny"を入れて表現します。エラーステータスで拒否を伝えると、拒否にならず失敗として扱われ、Failure handlingの設定が適用されます。

もう1つの典型がリダイレクトです。HTTPからHTTPSへの転送、末尾スラッシュの正規化、wwwの付け替えなどが原因で、ロードバランサーやWAFが301・302を返すと、このエラーになります。設定したURLが最終的な宛先でなければなりません。

ResponseError: 200でも本文が不正なら失敗

200は返っているのに、本文が有効なverdictでない場合です。次のような場合が含まれます。

• actionがallowでもdenyでもない値になっている
• 本文がJSONとして解析できない
• 本文が圧縮されている(読み取られるのは非圧縮の本文のみ)
• 本文が64 KiBを超える

Anthropicが読み取るのは、応答本文の先頭64 KiBまでです。通常のverdictは数百バイトで足りるので、64 KiBを超えるのはデバッグ出力やHTMLのエラーページを本文に混ぜているケースがほとんどでしょう。一方、deny_reasonが500文字を超えても、拒否は切り捨てられるだけで有効なまま扱われます。長さが原因で拒否が失敗に変わることはありません。

TransportError: つながらなかった、または途中で切れた

接続が完了せず、完全な応答が届かなかった場合です。ホスト名が解決できない、解決先がprivateアドレスだった、接続が拒否・リセットされた、TLSハンドシェイクが失敗した、といった原因がここに入ります。Anthropic側のネットワーク問題も、このエラーとして現れることがあります。

自社側で見るなら、次の順です。

1. 公開DNSでホスト名が引けるか確認する。
2. 証明書が公開CAの信頼ストアで検証できるか確認する(自己署名・社内CA・中間証明書の欠落は失敗の定番です)。
3. 443番がインターネットから開いているか確認する。

エンドポイントの要件には、ホストがIPv4アドレスを持つことも含まれます。IPv6だけで公開しているホストには、Anthropicがつなげません。

DisallowedAddressErrorとBlockedError: URLの設定ミス

この2つは、リクエストを送る前にURLの形で弾かれる失敗です。

DisallowedAddressErrorは、URLのホストがprivate・内部のIPアドレス、IPv6アドレス、localhostのいずれかである場合に出ます。ここで注意したいのは、ホスト名がprivateアドレスに解決される場合は、このエラーではなくTransportErrorになる点です。URLにIPアドレスを直接書いたときがDisallowedAddress、ドメイン名を書いて解決先が内部だったときがTransport、と覚えると切り分けやすくなります。

BlockedErrorは、URLがhttps://で443番のものではない、または解析できない場合です。リクエストは送られていません。http://や:8443付きのURL、スキームを書き忘れたURLが典型です。

どちらも設定を保存し直せば直ります。ngrokのようなリバーストンネルのホストは、Anthropicのネットワークポリシーで遮断されるため、検証にも使えません。自分で管理するドメインにサーバーを置く必要があります。

RelayError: サーバーを調べても見つからない

Anthropic内部で起きた失敗で、AIセキュリティサーバーには通常つながっていません。自社側で打てる手はほぼなく、サーバーのアクセスログに該当時刻のリクエストがないことを確認できれば、それが裏付けになります。

ブレーカーに数えるエラーと数えないエラー

サーキットブレーカーは、AIセキュリティサーバーに起因するWebhook失敗が続くと作動し、強制を止めます。作動中はサーバーに接続せず、全リクエストにFailure handlingが適用されます。Block the requestの組織では、リセットされるまでユーザーがブロックされます。

表の最後の列が示すように、すべてのエラーがブレーカーに数えられるわけではありません。

• 数える: Timeout・Status・Response・DisallowedAddress
• 数えない: Transport・Blocked・Relay

この区別から、Recent errorsの見方が1つ決まります。Transportだけが大量に出ている間は、ブレーカーが作動しないまま失敗が積み上がります。パネルのFailures per minuteは数えない種類も含めて数えるため、Circuit breaker trippedが空のまま高い値を示すことがあります。逆に、TimeoutやStatusが続くとブレーカーは作動します。

Shadow modeでは、どのエラーもブレーカーに数えられません。本番投入前にここでRecent errorsを観察すれば、ブロックの危険を負わずに失敗の種類を洗い出せます。

作動後の復旧は、サーバーを直してからEnforce verdictsを入れ直す方法です。作動から10分後以降は、Anthropicが約1分に1回までテスト要求を送り、有効なverdictが返ればブレーカーは自動で戻ります。ただし、作動後に設定を1つでも変えると、署名シークレットのローテーションを含め、自動復旧は止まります。詳細はサーバー側の設計をまとめた記事にもあります。

設定画面の接続テスト結果とエラー名の対応

エンドポイントの設定ステップには、接続テストの結果表があります。名前は違いますが、指している原因はRecent errorsのエラーとよく重なります。

テストで通っていたのに本番トラフィックでRecent errorsが出る場合は、テストにない条件が効いています。テストでは小さな本文しか送られないため、本番で会話履歴が長くなり本文が大きくなった場合や、負荷で処理が遅れてTimeoutになる場合は、テストで再現しないことがあります。

パネルが静かでも健全とは限らない

Recent errorsは、ベストエフォートの表示です。Anthropicがカウンタを読めない場合は、エラー自体を出さず、失敗0件・エラーなしと表示します。つまり、空の一覧はサーバーが健全であることの証明になりません。

もう1つの記録先が、組織のActivity Feedです。Allow the requestかつEnforce verdictsがオンのとき、verdictを得られず検査なしで通ったリクエストが記録されます。理由は次の3種類です。

• endpoint_timeout: タイムアウト
• endpoint_error: サーバー呼び出しのそれ以外の問題
• internal_error: Anthropic側の失敗

Block the requestとShadow modeでは、失敗したリクエストは個別に記録されません。Activity Feedの理由とRecent errorsのエラー名が1対1で対応するかは、Inference hooksの設定ページに記載がありません。Activity Feedの記録を外部で集める手順は、Compliance APIの概要が扱っています。

症状からの確認順

パネルを開いたときの確認順は、次のとおりです。

1. カテゴリを見る。relay_errorだけならサーバーを調べず、様子を見る。
2. webhook_errorなら、エラー名ごとに直し先を決める(BlockedとDisallowedAddressはURL、TransportはDNS・証明書・ポート、StatusとResponseはサーバーの応答、Timeoutは処理時間)。
3. ブレーカーに数えるエラーが続いているなら、Circuit breaker trippedの日時を確認する。
4. 直した後は、1時間は古いエントリが残る前提で、新しいエントリが増えないことを見る。

サーバーの応答は、手元から確かめることもできます。例えば次のようにステータス・リダイレクト先・本文サイズを出せます。

curl -sS -o /dev/null -X POST \
  -H 'Content-Type: application/json' -d '{}' \
  -w '%{http_code} %{redirect_url} %{size_download}\n' \
  https://security.example.com/verdict

これはステータス・リダイレクト・応答サイズの確認用の例で、署名検証を実装したサーバーなら、署名なしのリクエストは拒否されます。出力の最初の値が200以外ならStatusの原因候補、2つ目の値が空でなければリダイレクトが起きています。

まとめ

Recent errorsの読み方は、カテゴリで自社側かAnthropic側かを分け、エラー名で直す場所を決め、ブレーカーに数えられる種類かで緊急度を測る、という3段階です。数えられないTransportが静かに積み上がるケースと、空のパネルを健全とみなせないケースが、見落としの主な落とし穴になります。