ストリーミング拒否の処理

Claude 4モデル以降、ClaudeのAPIからの「streaming」（ストリーミング）レスポンスは、ストリーミング分類器が潜在的なポリシー違反を処理するために介入した場合に stop_reason: "refusal" を返します。この安全機能は、リアルタイムストリーミング中のコンテンツコンプライアンスの維持に役立ちます。

APIレスポンス形式

ストリーミング分類器がAnthropicのポリシーに違反するコンテンツを検出すると、APIは次のレスポンスを返します。

{
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": "Hello.."
    }
  ],
  "stop_reason": "refusal",
  "stop_details": {
    "type": "refusal",
    "category": "cyber",
    "explanation": "This request was declined because it could enable cyber harm."
  }
}

イベントストリームでは、stop_details は stop_reason とともに message_delta イベントで届きます。

拒否後のコンテキストのリセット

stop_reason: refusal を受け取った場合、続行する前に会話コンテキストをリセットする必要があります。拒否を引き起こしたターンを削除または言い換えるか、会話履歴を完全にクリアすることができます。リセットせずに続行しようとすると、拒否が継続して発生します。

実装ガイド

アプリケーションでストリーミング拒否を検出して処理する方法は次のとおりです。

client = anthropic.Anthropic()
messages = []


def reset_conversation():
    """Reset conversation context after refusal"""
    global messages
    messages = []
    print("Conversation reset due to refusal")


try:
    with client.messages.stream(
        max_tokens=1024,
        messages=messages + [{"role": "user", "content": "Hello"}],
        model="claude-opus-5-5",
    ) as stream:
        for event in stream:
            # message delta で拒否（refusal）が返されていないか確認します
            if event.type == "message_delta":
                if event.delta.stop_reason == "refusal":
                    reset_conversation()
                    break
except Exception as e:
    print(f"Error: {e}")

現在の拒否タイプ

APIは現在、拒否を3つの異なる方法で処理しています。

ベストプラクティス

• 拒否を監視する： エラー処理に stop_reason: refusal のチェックを含めます
• 自動的にリセットする： 拒否が検出されたときに自動的にコンテキストをリセットする処理を実装します
• 別のモデルにフォールバックする： サーバーサイドフォールバックまたはSDKミドルウェアを設定し、拒否をユーザーに表示する代わりに、拒否されたリクエストが別のClaudeモデルで再試行されるようにします
• 手動再試行時にフォールバッククレジットを利用する： 再試行を自分で構築する場合は、拒否のフォールバッククレジットトークンを渡して、再試行でプロンプトキャッシングのコストを二重に支払わないようにします
• カスタムメッセージを提供する： 拒否が発生した際のUX向上のために、ユーザーフレンドリーなメッセージを作成します
• 拒否パターンを追跡する： 拒否の頻度を監視して、プロンプトの潜在的な問題を特定します

移行に関する注意事項

この機能が最初にリリースされたときに拒否処理を構築した場合、または既存の統合に追加する場合は、次の点を確認してください。

• 拒否はエラーではなくレスポンスです。 拒否は stop_reason: "refusal" を持つ成功したHTTP 200レスポンスとして届くため、エラー率のみに基づく監視では検出されません。拒否は独自のシグナルとして追跡してください。
• 拒否には構造化された詳細が含まれます。 すべてのモデルにおいて、拒否には、拒否の背景にあるポリシーカテゴリを識別する stop_details オブジェクトも含まれます。完全なレスポンスの形式については、拒否とフォールバックを参照してください。
• 別のモデルで再試行してください。 拒否されたリクエストを同じモデルに再送信すると、通常は再び拒否されます。コンテキストをリセットするだけでなく、サーバーサイドフォールバック、SDKミドルウェア、または手動再試行を使用してフォールバックモデルで再試行し、再試行を自分で構築する場合はフォールバッククレジットを利用してください。
• バッチ結果の拒否を確認してください。 Message Batch内で拒否されたリクエストは、エラー結果ではなく、stop_reason: "refusal" を持つ成功結果として返されます。
• 処理を stop_reason に集約してください。 APIは引き続き拒否処理を stop_reason: "refusal" に集約していくため、モデル固有の動作ではなく停止理由で分岐してください。

次のステップ