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

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",
    ) as stream:
        for event in stream:
            # メッセージデルタで拒否をチェック
            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"を中心に拒否処理を統合しているため、モデル固有の動作ではなく停止理由で分岐してください。



次のステップ