Opus 5.5のreasoning_extraction拒否とfallback設計

Claude Opus 5.5は、生物学・サイバーセキュリティに加えてreasoning_extractionという新しいカテゴリで応答を拒否します。Claude Opus 5から移行する実装者にとって、この3つ目のカテゴリは挙動が特殊です。他のカテゴリと違い、reasoning_extractionの拒否はサーバー側のfallbackで自動的に再試行されません。何が発火条件で、なぜ再試行されないのか、fallbackをどう設計すれば拾えるのかを公式ドキュメントに基づいてまとめます。

Opus 5.5の安全分類器は何を見ているか

Opus 5.5は生物学・サイバーセキュリティ・reasoning extractionの3種類の安全分類器を実行します。Claude Opus 5から移行する場合、このうち生物学とreasoning extractionが新しく追加されたカテゴリです。サイバーセキュリティの分類器はOpus 5から引き続き動いています。

stop_reasonとstop_detailsを軸に見ると、Claude APIの拒否カテゴリは次の5種類に整理されています。この一覧はClaude Opus 5.5・Claude Opus 5・Claude Fable 5・Claude Fable 5.1に共通の枠組みで、Opus 5.5の公式ガイドが名前を挙げているのはこのうちbio・cyber・reasoning_extractionの3つです。

拒否はエラーではありません。HTTPステータスは200のまま返り、stop_reasonが"refusal"になり、contentは空配列になります。stop_details.categoryにどのカテゴリが発火したかが入り、explanationには表示用の説明文が入りますが、この文言は変わる可能性があるため分岐条件には使いません。拒否がこの5カテゴリのどれにも当たらないときは、categoryとexplanationの両方がnullになります。これは値の欠落ではなく、正常な応答として恒常的に返る値です。分岐は常にstop_reasonが"refusal"かどうかで行い、stop_detailsの中身に依存させないのが公式の推奨です。

reasoning_extractionはどんな依頼で発火するか

reasoning_extractionは、モデルに内部の推論過程をそのまま応答テキストへ書き出させようとする依頼を対象にします。典型的には、thinkingを無効化していた時代のOpus 5向けプロンプトに残った「考えた過程を答えの中に書いてください」という指示です。

Opus 5.5はthinkingを常時オンにしていて無効化できません。かつてthinking無効で運用していた実装が、代わりに応答本文へ推論を書き出させる指示をプロンプトに残していると、この指示自体が拒否の対象になり得ます。公式ガイドが挙げる対処は、そうした指示を削除し、display: "summarized"を設定して、要約された推論をthinkingブロックから読む方法に切り替えることです。

拒否時の応答は次のような形で返ります(explanationの文言とusageの数値は応答の形を示す例示です)。

{
  "content": [],
  "stop_reason": "refusal",
  "stop_details": {
    "type": "refusal",
    "category": "reasoning_extraction",
    "explanation": "This request was declined because it asked the model to reproduce its internal reasoning in the response text."
  },
  "usage": {
    "input_tokens": 380,
    "output_tokens": 0
  }
}

explanationの文言はそのまま採用せず、categoryが"reasoning_extraction"かどうかで分岐するのが公式の推奨です。この応答が来た時点で、リトライすべきはモデルではなくプロンプト側だという点が、他のカテゴリとの最大の違いになります。

reasoning_extractionだけfallbackで再試行されない

Claude APIには拒否を別モデルで自動的に再試行する仕組みが3つあります。fallbacks: "default"を付けるとAnthropicが推奨するモデルへ自動的に再試行するserver-side fallback(ベータ)、SDKに組み込まれたクライアント側ミドルウェア、そして自前で実装する手動リトライです。

bioやcyberの拒否は、server-side fallbackの既定モード(fallbacks: "default")で、そのカテゴリに対してAnthropicが推奨する別モデルへ自動的に再試行されます。推奨fallback先のモデル名はModels APIでは公開されておらず、応答のmodelフィールドとusage.iterations内のfallback_messageエントリで確認します。

一方reasoning_extractionはこの自動再試行の対象から外れています。公式の移行ガイドは「server-side fallbackはreasoning_extractionで拒否されたリクエストを再試行しない。その拒否はそのまま呼び出し元に返る」と明記しています。Opus 5.5のプロンプトガイドも同じ例外を「reasoning_extractionの拒否だけは、server-side fallbackが再試行せずそのまま返す」と説明しています。推奨fallbackが存在しないカテゴリでは拒否がそのまま返るという一般原則の、具体例がこのカテゴリです。

この違いは監視の設計に直結します。fallbacks: "default"を設定してさえいれば拒否は自動で救われる、という前提で監視を組んでいると、reasoning_extractionの拒否だけはfallback_messageエントリが付かずに素通りします。stop_reasonが"refusal"になった件数と、usage.iterationsにfallback_messageが現れた件数の差分を見て、埋まらない差分の中にreasoning_extractionが混じっていないかを確認する必要があります。

fallbackをどう設計するか

置かれている環境によって、選ぶべき方式が変わります。

curl --fail-with-body -sS https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: server-side-fallback-2026-07-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 1024,
    "fallbacks": "default",
    "messages": [{"role": "user", "content": "..."}]
  }'

fallbacksには既定モードの文字列"default"の代わりに、最大3つまでモデルを自分で指定するリストも渡せます。ただしserver-side fallbackはreasoning_extractionで拒否されたリクエストを再試行せず、その拒否はそのまま呼び出し元に返ります。この場合はプロンプト側の修正が唯一の対処になります。

fallbacksパラメータは、そのリクエスト自身の拒否にしか働きません。ツール実行の内側でサブエージェントが別にモデルを呼び出している場合、その呼び出しにはfallbacksが伝播しないため、サブエージェントごとに個別のfallback設定が必要です。リード側のエージェントだけにfallbacks: "default"を付けて安心していると、サブエージェントの呼び出しで起きたreasoning_extraction以外の拒否まで素通りしてしまいます。

fallbackが一度成立した会話には、sticky routingという仕組みが働きます。fallback先のモデルが応答したことは組織スコープでおよそ1時間保存され、同じ会話の後続ターンは元のモデルを試さず直接fallback先へ送られます。毎ターン同じカテゴリで拒否されるはずのリクエストに課金し続けるのを避ける設計ですが、保存はベストエフォートなので、元のモデルが再び試される可能性を前提にコードを書く必要があります。

課金は拒否が発生した時点で分かれます。出力が始まる前の拒否は課金されず、トークン数はusageに記録されるだけです。ストリーミング中に途中まで出力してから拒否された場合は、その分の入出力トークンが通常の料率で課金されます。

Message Batches APIではfallbackがそもそも使えない

Message Batches APIでOpus 5.5を使う場合、fallbacksパラメータ自体が対応していません。バッチのリクエストにfallbacksを含めると、そのアイテムはerroredな結果になります。同期リクエストと違い、server-side fallbackもSDKミドルウェアもバッチには効きません。

バッチの中で拒否されたリクエストは、result.typeが"succeeded"のままstop_reasonが"refusal"になって返ります。バッチの拒否はfallback_credit_tokenも発行されないため、後から自分でfallback creditを使ったリトライを組むこともできません。拒否されたアイテムを別モデルへ回すには、結果から拒否分を抽出し、複数ターンの履歴があればFableやOpus 5.5のthinkingブロックを取り除いてから、新しいバッチか同期リクエストとして再送する必要があります。reasoning_extractionで拒否された場合はモデルを変えても状況は変わらないため、再送する前にプロンプトから推論を書き出させる指示を取り除きます。

生物学とサイバーは同じ枠組み、reasoning_extractionは別枠

生物学の分類器はClaude Fable 5.1と同じ安全策です。日常的な健康・教育に関する質問は影響を受けず、生命科学分野の業務で分類器が支障になる場合はLife Sciences Verification Programへの申請が案内されています。サイバーセキュリティの分類器は、ソースコードの脆弱性を見つける作業自体は許可し、高リスクなデュアルユースのサイバー活動だけを対象にしています。

この2つのカテゴリは、fallbackという救済策が用意された上での話です。reasoning_extractionだけは、そもそも救済策の対象外という一段違う位置付けになっています。要約された推論をthinkingブロックから読むという代替の取得経路が既に用意されているため、この依頼だけは弱いモデルへ逃がすのではなく、プロンプトの書き直しを促す設計だと読めます。

まとめ

Claude Opus 5から移行する場合、bioとreasoning_extractionという2つの新しい拒否カテゴリを想定します。bioとcyberはserver-side fallbackの既定モードやSDKミドルウェアで自動的に別モデルへ再試行できます。reasoning_extractionはこの自動再試行の対象外で、拒否がそのまま呼び出し元に返ります。

対処の要点は、応答本文に推論をそのまま書き出させる指示がプロンプトに残っていないかの確認です。残っていれば削除し、display: "summarized"を設定してthinkingブロックから要約された推論を読む経路に切り替えます。監視を組むときは、stop_reasonが"refusal"になった件数とusage.iterationsのfallback_message件数の差分を見て、reasoning_extractionのような「fallbackで救われない拒否」が埋め込まれていないかを確認してください。

安全分類器による拒否そのものへの向き合い方は、Batch APIの拒否は成功扱いになる落とし穴やClaude Fable 5.1のrefusal誤検知を防ぐプロンプトの書き方でも扱っています。Claude Code経由で拒否に遭遇した場合の表示や対処は「Usage Policy refusal」とはにまとめています。Opus 5.5全体の料金や破壊的変更はClaude Opus 5.5とはを参照してください。