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 Sonnet 5.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になります。これは値の欠落ではなく、正常な応答として恒常的に返る値です。

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
  }
}

displayの既定値はOpus 5.5では"omitted"で、何も付けないとthinkingブロックの中身は空のまま返ります。推論を読みたいときは明示的に"summarized"にします。

reasoning_extractionだけserver-side fallbackが再試行しない

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

bioやcyberの拒否は、server-side fallbackの既定モード(fallbacks: "default")で、そのカテゴリに対してAnthropicが推奨する別モデルへ自動的に再試行されます。既定モードの振り分け先はモデルごとには公開されていないため、実際にどのモデルが答えたかは応答のmodelフィールドとusage.iterations内のfallback_messageエントリで確認します。

一方reasoning_extractionはこの自動再試行の対象から外れています。公式の移行ガイドは「server-side fallbackはreasoning_extractionで拒否されたリクエストを再試行しない。その拒否はそのまま呼び出し元に返る」と明記しています。Opus 5.5のプロンプトガイドも同じ例外を「reasoning_extractionの拒否だけは、server-side 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つまでモデルを自分で指定するリストも渡せます。名前を指定するときは、betaヘッダーを付けたModels APIのallowed_fallback_modelsに載っているモデルだけが選べます。モデルを名前で指定した場合も、server-side fallbackはreasoning_extractionの拒否を再試行しません。

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

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

課金は拒否のカテゴリで分かれ、出力が始まる前の拒否でも対象になるかどうかが変わります(下の図)。課金の有無にかかわらずcontentは空で、トークン数はusageに載り、レート制限には算入されます。この課金ルールはBedrockなどを含む全プラットフォームで共通です。

fallbackが働いた場合も、きっかけになった拒否が上の課金対象カテゴリか途中拒否であれば、その分とfallback側のリクエストの両方が課金されます。fallback creditは、fallback側のプロンプトキャッシュ書き込みを二重に払わないための返金で、拒否そのものの課金は消しません。課金対象のカテゴリは、誤検知率の計測に応じて変わる可能性があると公式が書いています。

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

Message Batches APIでOpus 5.5を使う場合、fallbacksパラメータ自体が対応していません。バッチのリクエストにfallbacksを含めると、そのアイテムはerroredな結果になります。バッチではserver-side fallbackが使えないため、拒否分は自分で抜き出して再送します。

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

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

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

bioとcyberにはfallbackという救済策があります。reasoning_extractionはserver-side fallbackの対象外です。推論を読みたい用途には、要約された推論をthinkingブロックから読む代替経路が既に用意されているため、対処はプロンプトの修正です。

まとめ

Opus 5からの移行では、課金と監視の両方でreasoning_extractionをcyberと別枠で扱うことになります。reasoning_extractionはserver-side fallbackで再試行されず、出力前でも課金されるためです(課金はbioも同じ)。

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