claude-fable-5を呼び出したのに、応答のmodelフィールドがclaude-opus-4-8になっていることがあります。これはバグではありません。リクエストが安全分類器に引っかかり、Fable 5が拒否したため、別モデルが代わりに処理した状態です。実装では、この挙動を「まれな例外」ではなく、明示的に扱うべきコードパスとして設計します。
このアーキテクチャの背景は、Fable 5の安全対策に関する解説で説明しました。この記事では、実装に必要なポイントに絞って、次の内容を扱います。
- リルートが発生する条件
-
response.modelでフォールバックを検出する方法 - ベータ版の
fallbacksパラメータでサーバー側リトライを有効にする方法 - 本番前に拒否・フォールバック経路をテストする方法
Fable 5が一部のリクエストをリルートする理由
Claude Fable 5には、受信リクエストを事前に確認する安全分類器があります。分類器は主に次の領域を監視します。
- サイバーセキュリティ
- 生物学・化学
- モデル蒸留
分類器がトリガーされると、Fable 5はそのリクエストを拒否します。Claudeの消費者向けインターフェースでは、代わりにClaude Opus 4.8が処理し、ユーザーにもその旨が表示されます。
APIでは、復旧処理はアプリケーション側の責任です。そこでfallbacksパラメータ、またはクライアント側のリトライ処理を設計します。
分類器は固定ではありません。6月の一時停止後、Anthropicは報告された脱獄技術に対して分類器を再学習させました。更新版は試行の99%以上をブロックします。Fable 5は、新しい分類器が導入された2026年7月1日に再展開されました。
サービス停止中に統合を止めていた場合は、Fable 5復活ハブでタイムラインと変更点を確認できます。
分類器はモデル内部ではなく、モデルの手前に配置されています。Claude Mythos 5は分類器のない同じモデルで、アクセスはProject Glasswing参加者に限定されています。Fableのセッションの95%以上ではフォールバックは発生せず、その場合のFable 5の性能はMythos 5と実質的に同じです。詳しくはFable 5とMythos 5の違いを参照してください。
リルートがアプリに与える影響
Fable 5とOpus 4.8はどちらも高性能なモデルですが、実装上は完全互換として扱うべきではありません。
Fable 5は、100万入力トークンあたり10ドル、100万出力トークンあたり50ドルで、1Mトークンのコンテキストウィンドウと128Kの最大出力を持ちます。Opus 4.8には独自の料金体系と動作特性があります。最新仕様はモデルの概要で確認してください。
Fable 5向けに調整したプロンプトは、Opus 4.8では次のように変わる可能性があります。
- 出力の長さが変わる
- フォーマットが微妙に変わる
- ツール呼び出しのパターンが変わる
- コスト計算の対象モデルが変わる
影響度はユースケースによって異なります。
通常のチャットや一般的な生成では問題になりにくい。
Opus 4.8の回答で十分なケースが多く、セッションの95%以上ではフォールバックも発生しません。評価や固定パイプラインでは重要。
特定モデルのベンチマーク中にサイレントなリルートが起きると、評価データが汚染されます。構造化抽出でも、モデル差が出力形式に影響する可能性があります。コスト帰属とコンプライアンスでは記録が必要。
フォールバック後の出力は、実際に応答したモデルのレートで課金されます。出力ごとに生成モデルを記録すべきチームもあります。分類器の対象領域に近いプロダクトでは特に重要。
セキュリティツールやライフサイエンス関連のワークロードでは、偽陽性が他領域より多くなる可能性があります。フォールバック処理をファーストクラスのコードパスとして扱いましょう。
プログラムでフォールバックを検出する
信頼できるシグナルは、Messages API応答のmodelフィールドです。
claude-fable-5に送信したのに、応答のmodelがclaude-opus-4-8であれば、リルートされています。この検出にベータ機能は不要です。
同時に、次のフィールドも必ず確認します。
-
model: 実際に応答を生成したモデル -
stop_reason: 完全拒否されたかどうか -
usage: 入出力トークン数。コスト帰属に使う
実装例です。
response = client.messages.create(
model="claude-fable-5",
max_tokens=16000,
messages=[{"role": "user", "content": prompt}],
)
if response.stop_reason == "refusal":
# フォールバックなしで拒否された場合、利用可能なコンテンツはない
handle_refusal(response)
elif not response.model.startswith("claude-fable-5"):
# Fable 5以外のモデルが応答した
logger.info(
"fallback served_by=%s in=%d out=%d",
response.model,
response.usage.input_tokens,
response.usage.output_tokens,
)
else:
# 通常どおりFable 5が応答した
handle_success(response)
ポイントは、response.contentを読む前にstop_reasonを確認することです。拒否されたレスポンスはHTTP 200でも返るため、ステータスコードだけでは判定できません。
APIの初期設定から始める場合は、Claude Fable 5 APIの使用方法に関するガイドで基本呼び出しを確認し、その後に上記の判定処理を追加してください。
fallbacksパラメータを使う
フォールバック設定がない場合、拒否されたAPIリクエストはそこで停止します。ユーザーには回答が返らず、リトライ処理はアプリ側で実装する必要があります。
fallbacksパラメータを使うと、このリトライをサーバー側に移動できます。Fable 5が拒否した場合、APIは同じ呼び出し内で指定したモデルに同じリクエストを再実行し、その応答を返します。
この機能はClaude APIおよびAWS上のClaude Platformでベータ版として提供されており、Anthropicの拒否とフォールバックのページで文書化されています。利用にはベータヘッダーでのオプトインが必要です。ローンチ時点でサポートされるフォールバック先はclaude-opus-4-8のみです。
response = client.beta.messages.create(
model="claude-fable-5",
max_tokens=16000,
betas=["server-side-fallback-2026-06-01"],
fallbacks=[{"model": "claude-opus-4-8"}],
messages=[{"role": "user", "content": prompt}],
)
print(response.model) # リルートされた場合は claude-opus-4-8
課金の考え方は次のとおりです。
- 出力生成前に拒否されたFable 5リクエストは課金されない
- フォールバックモデルが応答した場合、そのモデルの通常料金で課金される
- 同じ回答に対して二重課金されるわけではない
検出方法は通常時と同じです。必ずresponse.modelで実際に応答したモデルを記録します。
注意点もあります。
-
fallbacksはBatches APIでは拒否される - Amazon Bedrock、Google Vertex AI、Microsoft Foundryでは利用できない
- これらの環境ではクライアント側リトライが必要
- フォールバックモデルも拒否した場合、最終応答は
stop_reason: "refusal"になる
そのため、fallbacksを有効にしていても、拒否ブランチは削除しないでください。
ハンドリングポリシーを決める
検出とリトライは実装上のメカニクスです。重要なのは、フォールバックが発生したときにプロダクトとしてどう扱うかです。
主な方針は3つあります。
1. Opusの回答をそのまま受け入れる
チャット、アシスタント、一般的なエージェントに向いています。
実装方針はシンプルです。
if response.stop_reason == "refusal":
show_refusal_message()
elif response.model != "claude-fable-5":
log_fallback(response)
show_answer(response)
else:
show_answer(response)
ユーザーはエラーではなく、1回の往復で回答を得られます。
2. 変更したリクエストでリトライする
モデルの一貫性がレイテンシより重要なパイプラインに向いています。
ただし、同じプロンプトをFable 5に再送信するだけでは意味がありません。一度分類器に拒否されたリクエストは、再び拒否される可能性が高いためです。
代替案は次のいずれかです。
- プロンプトを再構成してトリガー領域から離す
- ジョブ全体をOpus 4.8にルーティングする
- 人間レビュー用キューに入れる
3. ユーザーに提示する
次のケースに向いています。
- 顧客がFable 5の利用を明示的に期待している
- コンプライアンス上、生成モデルの開示が必要
- ユーザーに再実行可否を選ばせたい
UIでは、少なくとも次を表示できるようにします。
- 実際に応答したモデル
- 再実行できるかどうか
- 完全拒否された場合の説明
どの方針を選んでも、フォールバック率は必ず計測してください。ゼロに近い率ならプラットフォーム全体のベースラインと一致します。数パーセントを超える場合は、プロンプトが分類器の対象領域に触れている可能性があるため、早めに見直す価値があります。
本番前に拒否パスをテストする
フォールバック処理は、手元のデモでは動いても、本番で数週間後に壊れるタイプのコードです。拒否は設計上まれなので、実ユーザーが分類器をトリガーするまで待っていると、ログ、リトライ、UIの不備に気づくのが遅れます。
本番前に、拒否・フォールバック経路を意図的にテストしましょう。
Apidogを使う場合の手順は次のとおりです。
- Claude Messagesエンドポイントを定義する
- APIキーを環境変数に保存する
- エッジケースプロンプトのテストシナリオを作る
- 良性のコントロールプロンプトも含める
- 応答ボディの
modelとstop_reasonをアサートする - CIまたはスケジュール実行に組み込む
テストで確認すべき条件は次のようになります。
control prompt:
model == "claude-fable-5"
stop_reason != "refusal"
edge case prompt:
model == "claude-opus-4-8" または stop_reason == "refusal"
分類器の対象に近いセキュリティ関連・生物関連のプロンプトと、決してリルートされるべきではない良性のプロンプトをセットにしておくと、挙動の変化を検出しやすくなります。
Anthropicが分類器を再学習した場合、たとえば7月1日の再展開前後のような変更があった場合でも、テストスイートがあれば、エッジケースが想定どおり処理されているかを短時間で確認できます。
よくある質問
fallbacksパラメータは追加料金がかかりますか？
いいえ。出力が生成される前に拒否されたリクエストは課金されません。フォールバックモデルが応答した場合は、そのモデルの通常のトークン単価で課金されます。同じ回答に対して二重に課金されることはありません。
セキュリティ関連のプロンプトは常にフォールバックをトリガーしますか？
いいえ。分類器が対象にするのは、サイバーセキュリティ、生物学・化学、モデル蒸留における有害なリクエストであり、トピックそのものではありません。
多くのセキュリティエンジニアリング作業は影響を受けずに通過します。全セッションの95%以上ではフォールバックは発生しません。ただし、対象領域に近い場合は偽陽性が起こり得るため、テストとログ計測が重要です。
6月の一時停止中にFable 5の使用をやめました。戻っても安全ですか？
はい。7月1日の再展開により、再学習された分類器が稼働しており、API表面は変更されていません。Fable 5 APIへの切り替えガイドでは、再有効化の手順を説明しています。復帰時にfallbacksパラメータを追加するチームも多いです。
まとめ
Fable 5のリルートはインシデントではなく、設計上の挙動です。実装では次を必ず行いましょう。
- すべての呼び出しで
response.modelを確認する -
stop_reason == "refusal"の分岐を残す - 必要に応じて
fallbacksを有効にする - Opus 4.8が応答した場合のプロダクト方針を決める
- フォールバック率をログで追跡する
- 本番前に拒否・フォールバック経路をテストする
Apidogでエッジケーススイートを作成し、modelとstop_reasonをアサートして、CIまたはスケジュール実行に組み込んでください。Apidogをダウンロードすれば、次回のデプロイ前に拒否スイートを実行できます。
Top comments (0)