トラブルシューティング
Claude Fable 5 エラー早見表
動かない Fable 5 連携のほぼすべては 5 つの障害パターンで説明できます。ステータスコードから自分のケースを見つけて、修正手順に従ってください。
30 秒でわかる要点
529 は Anthropic 側の容量の問題で、リトライで対応します。429 はあなたのスループットが Fable 5 専用のレート制限プールを超えたもので、このプールは Opus や Sonnet より小さく設定されています。400 はリクエスト本文か、組織のデータ保持設定が原因です。拒否はそもそもエラーではなく、HTTP 200 で stop_reason が refusal として返るため例外は発生しません。404 はモデル ID の誤りか、アカウントから claude-fable-5 に到達できないことを意味します。
529 overloaded_error
Anthropic のプラットフォームが全顧客規模で容量に達しています。あなたのアカウントでもクォータでもなく、バックオフ以外に手はありません。
429 rate_limit_error
Fable 5 専用のプールで、毎分のリクエスト数・入力トークン・出力トークンのいずれかを超えました。retry-after ヘッダーが待つべき秒数を正確に示します。
400 invalid_request_error
多くは temperature や thinking budget など Fable 5 が廃止したパラメータ、あるいは組織のデータ保持設定が必須の 30 日を下回っているケースです。
stop_reason: refusal
安全性分類器がリクエストを拒否し、HTTP 200 を返しました。stop_details.category を読めばどのポリシー領域が反応したかがわかります。
404 not_found_error
モデル ID が誤っているか、アカウント・ワークスペース・プラン・Claude Code のバージョンから claude-fable-5 に到達できません。
Fable 5 のレート制限
利用ティアごとの RPM・ITPM・OTPM の数値、キャッシュ読み取りが計算をどう変えるか、上限引き上げの申請方法をまとめています。
Fable 5 の壊れ方が違う理由
Opus 4.8 や Opus 5 から移行したときに驚く点のほとんどは、この 4 つの構造的な違いで説明がつきます。
拒否は成功レスポンスです
Fable 5 にはリクエストを拒否できる安全性分類器が組み込まれています。拒否は HTTP 200 で返り、stop_reason は refusal、stop_details オブジェクトが付きます。エラー率のダッシュボードにも try/except にも引っかからないため、本番では警報ではなく「空のレスポンス」として現れます。
受け付けるパラメータの範囲が狭くなっています
temperature、top_p、top_k にデフォルト以外の値を渡すと 400 が返ります。assistant プリフィルも 400 です。thinking の disabled 指定も、budget_tokens による手動指定も 400 になります。SDK のリクエスト型は後方互換のためこれらのフィールドを定義したままなので、型チェックは通り、実行時に API 側で拒否されます。
Fable 5 は独自のレート制限プールを持ちます
レート制限はモデルごとに個別に適用され、Fable 5 のプールは Opus 5 よりかなり小さくなっています。Start ティアでは Fable 5 が毎分 500,000 入力トークン・100,000 出力トークンなのに対し、Opus 5 は 2,000,000 と 400,000 です。Opus では一度も 429 にならなかったトラフィックが、Fable 5 では即座に制限に達することがあります。
一部の 400 と 404 は組織レベルの問題です
Fable 5 は 30 日間のデータ保持を必須とし、ゼロデータ保持では利用できません。保持設定がこの要件を満たしていない組織では、リクエスト本文の内容にかかわらずすべてのリクエストが 400 になります。管理者が設定したモデル許可リストも同じく「全部通らない」形で現れます。
この順序で対処する
リトライ処理を書く前に、障害を分類してください。分類を誤ったリトライは、無駄な課金か設定バグの隠蔽につながります。
1. ステータスコードと error type を読む
API のエラー本文には必ず error.type と request_id が含まれます。429 は rate_limit_error、529 は overloaded_error、400 は invalid_request_error、404 は not_found_error です。request_id は必ずログに残してください。Anthropic のサポートが調査に使える唯一の手がかりです。
3. retry-after を守り、指数バックオフする
429、500、504、529 は指数バックオフでリトライし、retry-after ヘッダーが示す秒数以上は必ず待ってください。それより早いリトライは定義上失敗します。400、401、403、404 はリトライ不要です。同じリクエストは同じ結果になります。
2. 200 のたびに stop_reason で分岐する
content を読む前に stop_reason が refusal かどうかを確認してください。content 配列が空であることから推測してはいけませんし、文言が安定しない stop_details.explanation をパースするのも避けてください。正当な拒否でも category と explanation は null になり得ます。
4. フォールバックモデルを組み込み、発火を確認する
サーバーサイドの fallbacks パラメータは安全性分類器による拒否でしか発火しません。Fable 5 での 429、529、500 はそのまま返されるため、容量起因のフォールバックは自分で実装する必要があります。