Claude Code fallbackModel完全ガイド｜529オーバーロードを越える

この記事の結論（3行まとめ）

• v2.1.166（6月6日）で fallbackModel が追加。プライマリが529で落ちたら最大3モデルへ自動切替できる
• 切替は「ターンスコープ」かつ「通知付き」。次のメッセージでは再びプライマリから試す
• 落とし穴はサイレントな品質劣化と、認証・課金エラーは救わない設計。チェーンの末尾に置くモデル選びが運用の肝

---

Frequent HTTP 529 Overloaded errors occurring during active Claude Code sessions on a Claude Max plan, which is supposed to have priority access. This is causing significant workflow disruption.

2026年3月27日、Claude CodeのIssue #39767に投稿者 @AMBR0SI0 がこう書き込んだ。優先アクセスを謳うMaxプランで、Sentry・Vercel・Supabase・PlaywrightなどのMCPサーバーを走らせていると、ほぼ毎日のように529 Overloadedで作業が止まるという内容だった。本文末尾には要望が添えられている。要約すると「--fallback-model フラグが --print モードでしか効かないのを直してほしい。settings.json に fallbackModel を書ければSonnetでも動き続けられるのに」。

その要望は2か月半後、v2.1.166として実装された。2026年6月6日。Week 24のClaude Codeリリースノートに、こうある。

fallbackModel configures up to three fallback models tried in order.

たった一行のリリースだが、影響は大きい。Claude Codeを業務で使っている人の多くが、529の前で何度も手を止めてきたからだ。

本記事は、fallbackModelの仕組みを公式ドキュメントから読み解き、現場の運用に必要な勘所をPMの視点で整理する。

529 Overloadedはなぜ消えなかったのか

「最優先プラン」でも刺さる現実

529 Overloadedは、Anthropic側のキャパシティ不足を意味する。クライアントの設定ミスではなく、容量側で受け切れないときに返るエラーだ。

Claude API・Claude Codeの2026年における529インシデントは、ofox.aiの障害記録によれば、3月2日・3月18日・3月19日・6月2日に大規模なものが観測されている。なかでも3月18日の障害は「3時間以上、ステータスページが monitoring 表示のまま、現場では純粋な529が返り続けた」と報告されている。

Issue #39767 の投稿者は Max プランで、Sentry・Vercel・Supabase・PlaywrightといったMCPサーバーを並走させていた。並列ツール呼び出しが多いと、長尺の会話の途中で529が刺さる確率が一気に上がる。Max プランの優先トラフィック契約は、容量自体が枯渇した場合の保証にはならない。

リトライでは救えない

「リトライすればいいのでは」と思うかもしれないが、答えはNoだ。

tokenmix.aiの529戦略記事は、最大4回・指数バックオフ・ジッター付きのリトライを推奨しつつ、長尺の障害ではリトライ単独では救えないとしてフェイルオーバーの併用を勧めている。3時間続く障害下で同期的にリトライし続けても、課金される失敗トークンが積み上がるだけだからだ。

ofox.aiの記録では、6月2日の障害時に「小規模チームがClaudeから他社モデルへ数秒以内に切り替えた」事例が紹介されている。ユーザー側からは障害がほとんど見えなかったという。これがフェイルオーバーの威力だ。

問題は、Claude Codeにはそのフェイルオーバー機構が長らく組み込まれていなかった点にある。--fallback-model フラグ自体は前から存在したが、--print（非インタラクティブ実行）でしか効かなかった。普段使うインタラクティブセッションでは、529が来たらキャンセルして手動でモデルを切り替える以外になかった（Claude Code週次50時間制限の議論でも、可用性の話題はくり返し問題になっていた）。

v2.1.166で何が変わったか

「Fallback Model Chains」の3行

公式モデル設定ドキュメントの “Fallback model chains” 節を読むと、設計思想がはっきり書かれている。

When the primary model is overloaded, unavailable, or returns another non-retryable server error, Claude Code can switch to a fallback model instead of failing the request. Authentication, billing, rate-limit, request-size, and transport errors never trigger a switch; those follow their normal retry and error handling.

要点は3つ。

1. 救う対象は「容量・到達性・予期せぬサーバー側エラー」だけ。認証・課金・レート制限・リクエストサイズ・トランスポートは救わない。これは設計の選択だ。「構成や課金の問題は黙って隠してはいけない」という意図で、サイレント失敗を避ける方向に寄せている。

2. 通知付き。切り替わるとき、Claude Codeは「フォールバックしました」という旨のメッセージをCLIに出す。サブエージェント実行中でも親エージェントが状況を認識できるよう設計されている。

3. ターンスコープ。「ターン」とは「ユーザーが1つメッセージを送り、Claudeが1つ応答を返す」1往復のこと。フォールバックは現在のターンだけ有効で、次のユーザーメッセージでは再びプライマリから試す。これは過去にあった「障害中にHaikuに落ちた挙句、回復してもずっとHaikuのまま」というアンチパターンを避けるための仕様だ。

設定の書き方

まず claude --version で v2.1.166以降であることを確認する。古ければ claude update でアップグレードする。

settings.json（macOSなら ~/.claude/settings.json、プロジェクト個別なら .claude/settings.json）に書く例（永続化）。

{
  "model": "opus",
  "fallbackModel": ["sonnet", "haiku"]
}

CLIで一時的に指定する例。

claude --fallback-model sonnet,haiku

エイリアス（sonnet・haiku・opus・default・best）でもフル名（claude-sonnet-4-6 等）でも書ける。"default" はアカウントごとの推奨モデルに展開される。

--fallback-model フラグは settings.json の fallbackModel よりも優先される。チェーン上限は3つで、4つ以上書いても黙って無視される。

allowlistと衝突したら黙って落とされる

availableModels を組織で設定している場合、チェーン内のモデルがallowlistに無いと「読み込み時点で黙ってドロップされる」。これは知らないとハマる挙動だ。

例えば管理者が "availableModels": ["sonnet", "haiku"] と設定している状態で、ユーザーが fallbackModel: ["opus", "sonnet", "haiku"] と書いても、実際には sonnet → haiku の2段チェーンとして解釈される。CLI起動時の警告は出るが、本人が気付かないうちに「思っていたチェーンと違うチェーン」で動くリスクがある。

エンタープライズで運用する人は、availableModels と fallbackModel を必ず突き合わせること。

落とし穴：サイレントな品質劣化

Issue #19468 が突きつけた問題

fallbackModelの仕様を見たとき、私が真っ先に思い出したのは2026年1月20日に投稿されたIssue #19468だった。タイトルは「[BUG] Systematic Model Degradation and Silent Downgrading in Claude Code」。

このIssueは複数のサイレント格下げパターンを並べている。「Opus上限到達でSonnetに勝手に切り替わる」「再認証でモデルが下がる」「settings.json で指定したモデルが無視されてHaikuで起動する」。

寄せられたコメントには厳しい言葉が並ぶ。

“Canceled my subscription yesterday.”

“Just downgraded from Max X20 to Max X5, not worth it paying more.”

“The coding suggestions are significantly worse.”

このIssueは「not planned」でクローズされている。Anthropicは公式に「サイレント格下げをやめます」とは明言しなかった。だがv2.1.166のfallbackModelは、ある意味でこのIssueに対する公式回答とも読める。

つまりこういうことだ：「黙って格下げするのではなく、明示的にユーザーが書いたチェーンの範囲内で格下げする。切り替わったら通知する。次のターンでは戻す」。

それでも残る問題

ただし、fallbackModelで救えない問題はまだある。

第一に、品質差は通知の対象外。OpusからSonnetに落ちたとき、Claude Codeは「フォールバックしました」とは言うが、「コード品質が落ちる可能性があります」とは言わない。長いリファクタリング作業の途中でOpus → Haikuまで降りたら、出力されるコードの品質はガクッと下がる。コーディング中の人間が違和感に気付くまで、低品質コードが書かれ続ける。

第二に、ターン単位だからこそ起きる「揺れ」。次のメッセージで再びプライマリを試すので、Opusが復活した瞬間に元に戻る。これは原則として歓迎すべき挙動だが、長尺の作業ではOpus・Sonnet・Haikuの間を行ったり来たりして、出力スタイルやコメントの書き方が会話の中で揺れる現象が起きうる。

第三に、429エラーは救わない。プランのレート制限に当たって出る429は、fallbackModelの対象外だ。Maxプランでも週次制限・5時間ウィンドウ制限がある以上、Opusの上限に達した人は「fallbackで救われるはず」と勘違いしないほうがいい（参考: Claude Code週次50時間制限）。容量側の障害（529）と利用枠側の制限（429）は、エラーコードも対処も別物だと押さえておくのが安全だ。

PMとしてこう設定する

私が個人で使うClaude Codeの settings.json には、現在こう書いている。

{
  "model": "opus",
  "fallbackModel": ["sonnet"]
}

Haikuまで降ろさないのは意図的だ。設計レビューや複雑なリファクタリングの途中でHaikuに落ちたら、出てくる成果物のレビュー負荷が一気に上がる。「止まらないけど後で書き直す」より「止まって自分が判断する」を選ぶ。なお、Opus 4.8とHaiku 4.5の入出力単価は公開料金で大きく差があるため、Sonnetを中継させると無音で課金が下がる効果もある（詳細はAnthropic公式料金表で確認のこと。料金は予告なく変更されうる）。

CIや夜間バッチでClaude Codeを呼び出すラインでは別の設定にしている。

{
  "model": "sonnet",
  "fallbackModel": ["haiku"]
}

CIで動くのはテストの自動修復やコメント追加のような単純タスクだ。Haikuに降りても致命傷にならない範囲のものだけ、Haikuで救うと割り切る。

判断のポイントは「失敗の見え方をどう設計したいか」だ。fallbackModelは「無音で続ける」装置になりがちなので、何を妥協するかを意識的に書く必要がある。

関連機能との組み合わせ

fallbackModelは単独で使うより、v2.1.169で追加された--safe-mode や、3月から提供されているAuto Mode、5月のAgent View と組み合わせると効果が高い。

特にAuto Modeでサブエージェントが大量に並列実行されている時、fallbackModel が無いと一部の子エージェントだけが529で落ちて、親が「成功扱い」で結果を吸い上げる悲劇が起きる。Auto Mode + Agent Team + fallbackModel の3点セットが、2026年6月時点での「壊れにくい構成」だ。

まとめ：fallbackModelは「銀の弾丸」ではない

整理する。

fallbackModelが解決すること：

• 529 Overloadedによるセッション中断
• 一時的なモデル到達不能
• 予期せぬサーバー側非リトライエラー
• 明示的に承認したモデル範囲での自動切替

fallbackModelが解決しないこと：

• 認証エラー、課金エラー
• レート制限（429）
• リクエストサイズ超過
• ネットワーク・トランスポート障害
• 品質劣化への可視性

「fallbackを書いたから安心」ではなく、「どこまで品質を妥協できるかを書面化する仕組み」と捉えるのがちょうどいい。Anthropicが容量の問題に正面から答えたこのアップデートを、設定ファイルにきちんと書き込むかどうかで、6月以降のClaude Code体験はだいぶ変わる。

Claude Codeを業務利用している人は、settings.json を開いて fallbackModel を1〜2行追加するところから始めるのが手早い。書く手間に対して、529の遭遇時に得られる継続性のリターンは大きい。

---

免責事項

本記事は2026年6月18日時点の公開情報をもとに執筆した。Claude Codeのバージョン・設定仕様・モデル名・料金は頻繁に更新されるため、最新情報はClaude Code公式ドキュメントを確認してほしい。記載した実例・引用は出典記事の内容を要約・編集したものであり、原文の細部とは異なる場合がある。fallbackModel を有効にしたうえで本番ワークロードに適用する際は、自組織のコンプライアンス・予算上限・品質基準と照らし合わせて判断すること。本記事の内容に基づく運用上の損害について筆者は責任を負わない。

「Claude」「Claude Code」「Anthropic」は Anthropic, PBC. の商標である。「Sentry」「Vercel」「Supabase」「Playwright」「Bedrock」「Vertex AI」「Foundry」その他本記事中の製品名・サービス名は、各社の商標または登録商標である。