結論｜拒否は 9 月から一部が課金される、fallback はベータで実装できる
Claude API (Messages API) の安全拒否は、2026 年 9 月時点の仕様として一部カテゴリが課金対象になりました。これまで「出力が始まる前の拒否は無料」と説明されていたところに、bio・frontier_llm・reasoning_extraction の 3 カテゴリだけ例外が加わっています。あわせて、拒否時に別モデルへ自動で振り替える server-side fallback がベータとして提供されています。
本記事は Messages API を直接叩く実装が対象です。Claude Code がセキュリティ関連の作業を断る挙動や、依頼文の書き方で拒否を避ける工夫は別レイヤーの話で、Claude Code のセキュリティ作業拒否への対処で扱っています。claude.ai のチャット画面上の表示についても本記事の対象外です。
補足
この記事は Refusals and fallback と Fallback credit の公式ドキュメントを 2026 年 9 月 25 日に確認して整理しています。実 API の呼び出しによる検証や、削減率・レイテンシの実測は行っていません。
課金ルールの変更は Claude API・Amazon Bedrock・Claude Platform on AWS・Google Cloud・Microsoft Foundry の全プラットフォームに適用されます。まずは拒否がどう返るかから確認します。
拒否は HTTP 200 の成功レスポンスで返る
安全分類器がリクエストを止めたとき、レスポンスは HTTP エラーになりません。ステータスは 200 で、stop_reason が "refusal" になります。content は空になり、拒否の理由は stop_details に入ります。
FIXIT拒否されたら、それってエラーなんじゃないの？
Kanameいいえ、HTTP は 200 です。stop_reason が refusal になるだけで、通信自体は成功しています。
stop_details の主な項目は次のとおりです。
category: 拒否の分類 (cyber/bio/frontier_llm/reasoning_extraction/general_harms、またはnull)explanation: 拒否理由の説明文、またはnull
category と explanation がどちらも null になる場合があります。これはレスポンスが壊れているのではなく、公式ドキュメントが示す正常な値です。分類を特定できない、または理由を開示しない拒否がこの形で返ってきます。
次は、レスポンス構造の要点だけを抜き出した簡略化した例です (実際のフィールド順序・付随情報は省略しています)。
{
"model": "claude-opus-5",
"content": [],
"stop_reason": "refusal",
"stop_details": {
"category": "bio",
"explanation": null
}
}注意
拒否は HTTP 200 で返るため、エラー率 (4xx / 5xx の比率)
だけを見ている監視は拒否の発生に気づけません。stop_reason: "refusal"
の発生率は別のメトリクスとして集計してください。
9 月の変更で変わったのは、拒否の「返り方」ではなく「課金のされ方」です。
課金ルールの全体像 — 5 カテゴリと出力前・ミッドストリームの違い
拒否の課金は、拒否のタイミングとカテゴリの組み合わせで決まります。2026 年 9 月時点のルールを整理すると、次のとおりです。
| カテゴリ | 出力前の拒否 (2026 年 9 月時点) | ミッドストリームの拒否 |
|---|---|---|
cyber | 無料 | 課金 (入力 + 出力済み) |
bio | 課金 | 課金 (入力 + 出力済み) |
frontier_llm | 課金 | 課金 (入力 + 出力済み) |
reasoning_extraction | 課金 | 課金 (入力 + 出力済み) |
general_harms | 無料 | 課金 (入力 + 出力済み) |
null (分類なし) | 無料 | 課金 (入力 + 出力済み) |
ポイントは 2 つです。1 つ目は、出力が始まる前の拒否でも bio・frontier_llm・reasoning_extraction の 3 カテゴリだけは課金される点。2 つ目は、生成の途中で分類器が作動した (ミッドストリームの) 拒否は、カテゴリを問わずそれまでの入力トークンと出力済みトークンが通常料金で課金される点です。
公式ドキュメントは、この変更の理由を「セーフガードを大規模に回避しようとする試みを妨げるため」と説明しています。あわせて、課金対象になっているのは誤検知率が低いと測定されているカテゴリであり、今後の測定結果によって対象カテゴリが変わりうるとも明記しています。つまり、この 3 カテゴリという区分は固定ではありません。
FIXIT9 月から急に課金されるようになったカテゴリがあるって、ちょっと理不尽じゃない？
公式は誤検知率が低いカテゴリだけを課金対象にしたと説明しています。
Kaname運用に乗せるなら、対象カテゴリが今後も変わりうる前提で見ておくとよいです。
正確な発効時刻 (UTC のどの時点からか) や、誤ブロックされた場合の返金・異議申し立て手続きは、公式ドキュメントに記載がありません。国内の技術情報サイトでは 2026 年 9 月下旬の変更として報告されていますが、Anthropic 公式ドキュメント自体の記載は「2026 年 9 月時点」という表現に留まります。日時を根拠に社内へ説明する場合は、この粒度を超えて言い切らないようにしてください。
なお、自社のClaude Fable 5.1 の変更点まとめは、2026 年 9 月 2 日の公開時点で「出力が始まる前の拒否は課金されません」と記載しています。これは本記事が扱う 9 月の変更より前の情報であり、現時点では bio・frontier_llm・reasoning_extraction の 3 カテゴリについて不正確です。同記事を参照する場合は、課金に関する記述だけは本記事のルールを優先してください。
server-side fallback を試す
安全分類器が拒否したとき、代替モデルへの再試行をアプリ側で書く代わりに、API 側に任せられるのが server-side fallback です。ベータのため、専用のヘッダーとパラメータが要ります。
fallback のきっかけになるのは安全分類器による拒否だけです。要求したモデルでのレート制限・過負荷・サーバーエラーは、代替モデルへ振り替わらずにそのまま返ってきます。
fallbacks パラメータには 2 つの指定方法があります。
"default": 拒否カテゴリに応じて Anthropic が推奨する代替モデルへ自動で振り分ける (推奨の代替先が無いカテゴリは拒否のまま返る)- 明示リスト (最大 3 モデル): 試したい順にモデルを並べる
ベータヘッダーはバージョンによって対応範囲が異なります。
| ベータヘッダー | 対応する fallbacks の指定 |
|---|---|
server-side-fallback-2026-07-01 | "default" と明示リストの両方 |
server-side-fallback-2026-06-01 | 明示リストのみ ("default" 非対応) |
最小構成の例です。
curl 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": 4096,
"messages": [
{"role": "user", "content": "この設計案のリスクを洗い出してください。"}
],
"fallbacks": "default"
}'Python (SDK のベータ名前空間) では次のように渡します。
import anthropic
client = anthropic.Anthropic()
response = client.beta.messages.create(
model="claude-opus-5-5",
max_tokens=4096,
betas=["server-side-fallback-2026-07-01"],
messages=[
{"role": "user", "content": "この設計案のリスクを洗い出してください。"}
],
fallbacks="default",
)明示リストにしたい場合は、各要素を {"model": ...} のオブジェクトにして、試したい順に並べます。次は公式ドキュメントの例と同じく、Claude Fable 5 の代替先に Claude Opus 4.8 を指定する形です。
response = client.beta.messages.create(
model="claude-fable-5",
max_tokens=4096,
betas=["server-side-fallback-2026-07-01"],
messages=[
{"role": "user", "content": "この設計案のリスクを洗い出してください。"}
],
fallbacks=[{"model": "claude-opus-4-8"}],
)リストに入れられるのは、要求モデルが許可した代替先だけです。許可された代替先の一覧は、ベータヘッダーを付けたときに Models API の各モデルの allowed_fallback_models で確認できます。各要素では max_tokens・thinking・output_config・speed をその試行だけ上書きできます。"default" モードはClaude Opus 5 の変更点まとめでも取り上げています。
Message Batches API では fallbacks を使えません。バッチ内の該当項目はエラー結果になります。公式ドキュメントが示すバッチでの拒否対策は、結果から拒否された項目を集め、複数ターンの履歴から Claude Fable 5.1 / Claude Fable 5 の thinking ブロックを取り除いたうえで、代替モデルに新しいバッチか直接のリクエストとして出し直す手順です。
fallback のレスポンスを読む
fallback が実際に発生すると、レスポンスの構造が変わります。確認する箇所は 3 つです。
- トップレベルの
model: 最終的に応答したモデル content内のfallbackブロック:from.model(元のモデル) とto.model(振り替え先)usage.iterations:type: "message"とtype: "fallback_message"のエントリ
公式ドキュメントの例 (Claude Fable 5 が出力前に拒否し、Claude Opus 4.8 が引き継いだ場合) から、要点だけを抜き出して簡略化したものです。
{
"model": "claude-opus-4-8",
"content": [
{
"type": "fallback",
"from": { "model": "claude-fable-5" },
"to": { "model": "claude-opus-4-8" }
},
{ "type": "text", "text": "Hi! How can I help you today?" }
],
"usage": {
"input_tokens": 412,
"output_tokens": 264,
"iterations": [
{
"type": "message",
"model": "claude-fable-5",
"input_tokens": 535,
"output_tokens": 0
},
{
"type": "fallback_message",
"model": "claude-opus-4-8",
"input_tokens": 412,
"output_tokens": 264
}
]
}
}トップレベルの usage は、返ってきたメッセージを生成した試行の分だけです。拒否された試行のトークンも usage.iterations の message エントリに記録されます。課金されるかどうかは前述のカテゴリのルールに従い、usage.iterations が試行ごとの課金の記録になります。
どのモデルへ振り替わるか、そして sticky routing
fallbacks: "default" を使ったとき、実際にどのモデルへ振り替わるかは公式ドキュメント上「非公開・モデルごとに設定」とされています。カテゴリと振り替え先の対応表は API 向けに公開されていません。
参考情報として、claude.ai のチャット UI 向けに書かれた Anthropic Help Center の記事には代表的な組み合わせが載っています。自社のClaude Opus 5.5 の変更点まとめでもこの表を引用しました。ただし、この表は API の fallbacks パラメータの仕様書ではなく、別ソースの参考情報です。API の仕様として確認できるのは、推奨の代替先が無いカテゴリでは振り替えずに拒否のまま返る、という点までです。
fallback が発生すると、同じ会話で以降に fallbacks を付けて送るリクエストは sticky routing の対象になります。要求したモデルを実行せず、前回応答した fallback モデルへ直接送られます。判定には会話プレフィックスのハッシュと応答したモデルが使われ、約 1 時間・組織スコープで保持されます。会話の内容自体は保存されず、ベストエフォートの挙動です。
sticky routing で直接送られたターンでは、そのターンで拒否したモデルが無いため、content に fallback ブロックが付きません。次のターンで急にモデルが変わったように見えたら、usage.iterations に fallback_message エントリがあり、要求したモデルの message エントリが無いこと、あわせてトップレベルの model で判定してください。
SDK ミドルウェアと手動リトライを使い分ける
server-side fallback は Claude API のベータ機能で、Amazon Bedrock・Google Cloud・Microsoft Foundry では使えません。これらのプラットフォームでは、SDK 側のミドルウェア (BetaRefusalFallbackMiddleware と BetaFallbackState) を使ってクライアント側で同等の再試行を実装します。SDK ミドルウェアはどのプラットフォームでも使えます。対応した正確な SDK バージョン番号は、本記事の執筆時点で公式のリリースノートから単一の版を特定できなかったため、導入前に各言語 SDK の変更履歴で確認してください。
自前でリトライを書く場合の手順は、次の 3 ステップです。
stop_reason === "refusal"を検知するmodelを代替モデルに変えて、同じリクエストを再送する (このとき後述の fallback credit を使うと、キャッシュ書き込みの割増分を抑えられます)- 複数ターンの会話では、以降のターンも元のモデルに戻さず代替モデルを使い続ける
SDK ミドルウェアと server-side fallback はどちらも fallback credit を自動で適用します。手動でリトライを書く場合だけ、次章の手順が必要です。
自前実装を fallback credit で直す
プロンプトキャッシュはモデルごとに分かれています。自前で別モデルへ再送すると、最初のモデルでキャッシュ済みだった会話のプレフィックスを、新しいモデルのキャッシュへ一から書き込むことになります。キャッシュ書き込みは読み込みより高額です。fallback credit は、この再送をはじめから新しいモデルで会話していた場合と同じ料金で請求し、キャッシュ作成の割増分をキャッシュ読み込みの料金に付け替えます。
なお、fallback credit で消えるのは再送側の割増分だけです。fallback のきっかけになった拒否は、ミッドストリームの拒否か課金対象カテゴリの拒否であれば、再送とは別に課金されます。
fallback-credit-2026-07-01 ヘッダーを付けてリクエストすると、拒否時の stop_details に次の 2 つが追加されます。fallback-credit-2026-06-01 と server-side-fallback-2026-07-01 のヘッダーでも同じ項目が返ります。クレジットが無い拒否では、どちらも null です。
fallback_credit_token: 再送時に使うトークンfallback_has_prefill_claim: 再送時のリクエストの形を決める真偽値
再送の手順は次のとおりです。
- 拒否されたリクエストの本文をもとに、
modelを代替モデルへ変える - トークンをトップレベルのパラメータ
fallback_credit_tokenに入れる fallback_has_prefill_claimがtrueなら、拒否された応答のcontentをそのまま assistant メッセージとしてmessagesの末尾に 1 つ足す。代替モデルは拒否された位置から続きを生成し、完了済みのサーバーツール呼び出しは再実行されないfallback_has_prefill_claimがfalseなら、リクエスト本文を変えずに再送する- 再送にも同じ
fallback-credit-2026-07-01ヘッダーを付ける (ヘッダーが無いとトークンを使えない)
代替モデルは、拒否したモデルに許可された代替先である必要があります。公式ドキュメントでは、Claude Fable 5.1 と Claude Fable 5 の代替先として Claude Opus 4.8 (claude-opus-4-8) と Claude Opus 5 (claude-opus-5) が挙げられています。
トークンは拒否から 5 分で失効します。取り消しや照会の API は無く、ステートレスに扱われます。再送するリクエストでは、次の項目を完全一致させる必要があります。
| 区分 | 項目 |
|---|---|
| 完全一致が必要な項目 | system / messages / tools / tool_choice / thinking / cache_control、使う場合は output_config / mcp_servers / context_management / container |
| 変更してよい項目 | model / max_tokens / stop_sequences / temperature / top_p / top_k / stream / metadata / service_tier |
fallback_has_prefill_claim が true のときに assistant メッセージを 1 つ足す形だけは、messages の一致の例外です。本文に加えて anthropic-beta ヘッダーもそろえる必要があります。ただし、fallbacks パラメータを外すのに合わせて server-side-fallback-* ヘッダーを外すのは不一致に数えられません。
一致条件を満たさない再送は 400 エラーで拒否されます。キャッシュ料金の付け替えを受けるには、フィールドとヘッダーを変えずにモデルだけ差し替える、という制約を守ってください。適用されたかどうかは、再送の usage で cache_creation_input_tokens が減り、cache_read_input_tokens が同じ量だけ増えているかで確かめられます。
fallback credit は Claude API・Amazon Bedrock・Claude Platform on AWS・Google Cloud・Microsoft Foundry のベータとして提供されます。Message Batches の拒否では、このトークン自体が発行されません。
使えるプラットフォームを確認する
3 つの機能は、提供範囲がそれぞれ異なります。表にまとめると次のとおりです。
| 機能 | Claude API | Claude Platform on AWS | Amazon Bedrock | Google Cloud | Microsoft Foundry | Message Batches API |
|---|---|---|---|---|---|---|
| 拒否の課金ルール | 適用 | 適用 | 適用 | 適用 | 適用 | 適用 (課金ルールは同じ) |
| server-side fallback | 利用可 (ベータ) | 明記なし | 利用不可 (SDK ミドルウェアで代替) | 利用不可 (SDK ミドルウェアで代替) | 利用不可 (SDK ミドルウェアで代替) | 利用不可 (エラー結果) |
| fallback credit | 利用可 (ベータ) | 利用可 (ベータ) | 利用可 (ベータ) | 利用可 (ベータ) | 利用可 (ベータ) | 発行されない |
Claude Platform on AWS については、Refusals and fallback のページは server-side fallback の提供可否を明記していません。Fallback credit のページには、Claude API と Claude Platform on AWS では server-side-fallback-2026-07-01 ヘッダーを付けると Models API で allowed_fallback_models が見られる、という記載があります。利用する場合は、事前に自社の環境で動作を確かめてください。
複数クラウドで運用している、または将来的に運用する可能性がある場合は、server-side fallback をベータのまま前提にしないほうが安全です。Bedrock・Google Cloud・Microsoft Foundry へ展開する予定があるなら、最初から SDK ミドルウェアで実装しておくと書き直しが要りません。
どの方式を選ぶか
ここまでの内容を、選択の流れとして整理します。
flowchart TD
A[安全分類器の拒否を別モデルで自動的に再試行したい] --> B{利用しているプラットフォームは?}
B -->|Claude API| C[server-side fallback の fallbacks パラメータ]
B -->|Amazon Bedrock / Google Cloud / Microsoft Foundry| D[SDK ミドルウェア BetaRefusalFallbackMiddleware]
B -->|Message Batches API| E[拒否された項目を集め、代替モデルで出し直す]
C --> F{既存の再試行実装を活かしたい?}
D --> F
F -->|はい、キャッシュ作成の割増分を抑えたい| G[自前の再試行に fallback credit を組み込む]
F -->|いいえ、丸ごと任せたい| H[fallback credit の自動適用のまま運用する]server-side fallback も SDK ミドルウェアも、内部では fallback credit を自動で使います。自前で fallback credit のリトライを書くのは、両方とも使えない環境か、リトライの条件を細かく制御したい場合に限られます。
運用で見落としやすい点
公式ドキュメントの Common pitfalls に沿って、見落としやすい点を 3 つ挙げます。
- 拒否は HTTP 200 で返るため、エラー率だけを見張る監視では素通りします。
stop_reasonの集計を別に持つ必要があります。 - サブエージェントの呼び出しには
fallbacksパラメータが伝播しません。オーケストレーターで設定しても、個々のサブエージェント呼び出しには個別に設定が要ります。 - リトライの予算はターン単位やセッション単位ではなく、リクエスト単位で考える必要があります。エージェントとそのサブエージェントのように、1 ターンの中で複数の拒否が起こりえます。
コツ
監視ダッシュボードに stop_reason の分布を必ず出してください。refusal
の比率が急に増えたときに気づけるかどうかは、この指標を最初から持っているかで決まります。
FIXIT の運用 — Claude API のセーフガード設計とコスト管理をどう支援しているか
長時間稼働するエージェントや SaaS のバックエンドで Claude API を直接叩く実装では、拒否の検知・課金の見え方・フォールバックの方針をセットで設計します。個々のカテゴリをすべて自前で判定するのではなく、公式のルールに沿って「どこまでを API に任せ、どこから人が判断するか」を先に線引きしておくと、課金カテゴリが見直された際の手直しを小さくできます。
AI 駆動開発のクリエイティブスタジオ FIXIT では、AI エージェント開発でこうしたセーフガードまわりの設計や、拒否・フォールバックを含めた評価ハーネスの組み込みをご相談いただけます。難所の判断だけを人やレビューに寄せ、定型的な監視や再試行の仕組み化を進める体制づくりを支援しています。社内の実装詳細そのものではなく、業務要件に合わせた設計からの伴走です。
拒否の課金ルールとフォールバックの実装方式は、今後の測定結果次第で変わりうる仕様です。次に確認すべきことは、自社が使っているプラットフォームで server-side fallback が使えるか、使えないなら SDK ミドルウェアか手動実装のどちらを選ぶかを決めることです。コスト全体の設計はLLM コスト最適化の解説も参照してください。
拒否とフォールバックの扱いを自社の実装に落とし込む際の相談は、お問い合わせから承っています。