ストリーミングの拒否

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



APIレスポンスの形式

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

{
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": "Hello.."
    }
  ],
  "stop_reason": "refusal"
}



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

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-4-8",
    ) 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レスポンスとして到着するため、エラー率のみに基づいて構築された監視では検出されません。拒否を独自のシグナルとして追跡してください。
• 新しいモデルはより詳細な情報を返します。 Claude Fable 5では、拒否には拒否の背後にあるポリシーカテゴリを識別するstop_detailsオブジェクトも含まれます。完全なレスポンス形式については、拒否とフォールバックを参照してください。
• 別のモデルで再試行します。 拒否されたリクエストを同じモデルに再送信すると、通常は再び拒否されます。コンテキストをリセットするだけでなく、サーバーサイドフォールバック、SDKミドルウェア、または手動での再試行を使用してフォールバックモデルで再試行し、再試行を自分で構築する場合はフォールバッククレジットを引き換えてください。
• バッチ結果で拒否を確認します。 Message Batch内の拒否されたリクエストは、エラー結果としてではなく、stop_reason: "refusal"を含む成功結果として返されます。
• stop_reasonで処理を一元化します。 APIは引き続きstop_reason: "refusal"を中心に拒否処理を統合していくため、モデル固有の動作ではなくstop reasonに基づいて分岐してください。



次のステップ