Claude大規模障害まとめ｜2026年7月29-30日のダウンと529 Overloadedエラーの意味・対処法

2026年7月29日から30日にかけて、AnthropicのClaudeで全モデル規模の障害が2日連続で発生し、多くのユーザーに 529 Overloaded エラーが表示されました。両日のインシデントはAnthropic公式ステータスページ上でいずれも「Resolved（解決済み）」となっており、2026年7月31日時点でclaude.ai・Claude API・Claude Code・Claude Coworkはすべて復旧しています。

この記事で扱う範囲は次のとおりです。

• 7月29日・30日に何が起きたのか（公式ステータスページの分単位タイムライン／日本時間併記）
• 529 Overloaded の公式定義と、429・500 との違い
• 529が出たときに効く対処と、まったく意味がない対処
• Claude Codeでのリトライ制御・モデル切り替えの具体手順
• 次の障害を最速で検知するための通知設定
• 業務のクリティカルパスにClaudeを置いてよいケース／避けたほうがよいケース

Claudeを日常業務で使っている方、Claude CodeをCIや開発フローに組み込んでいる方、社内でAIツールの可用性リスクを説明する必要がある方に向けた内容です。

529は「自分のせい」ではないが、待つ以外の逃げ道もある

押さえるべきポイントは3つです。

1. 529 Overloadedはサービス側の過負荷を示すエラーで、利用者のアカウント・APIキー・コードの問題ではありません。 Anthropic公式のAPIエラーリファレンスにも「529エラーは全ユーザーにまたがる高トラフィック時に発生しうる」と明記されています。
2. 上位プランに課金しても529は回避できません。 キャパシティは全ユーザー共通のため、Pro・Maxに変更しても解決しません。プラン変更で改善余地があるのは429（レート制限）のほうです。
3. 待つだけが選択肢ではありません。 容量はモデルごとに管理されているため、Claude Codeでは /model による切り替えが公式に推奨される回避策です。ただし7月30日のように全モデルが同時に落ちる局面では、この手も効きません。

Claude自体の全体像を確認したい方は「Claudeとは？機能・料金・使い方を解説」もあわせてご覧ください。

2026年7月29日の障害｜全モデルでエラー率上昇（約1時間41分）

出典: Anthropic公式サイト

1日目の障害は、日本時間では7月30日の深夜〜早朝にあたり、日本のビジネスアワーへの直撃は回避されました。

公式ステータスページに掲載されたインシデント「Elevated errors across all models」（インシデントID: q2kg8n613kr3）の推移は以下のとおりです。

• エラー率上昇の実質継続時間：約1時間41分（19:45〜21:26 UTC）
• インシデント全体（検知〜解決宣言）：約2時間47分

この日はDowndetectorへの報告も集中しました。GV WireやIBTimesなど複数メディアの報道によれば、報告件数は2,000件を超え、ピーク時には5,000件超に達したとされています。さらに報道では、報告のおよそ半数がClaude Code関連だったとされており、チャット利用よりも開発ワークフローへの影響が目立った障害でした（数値はDowndetector経由の二次情報のため、参考値として扱ってください）。

2026年7月30日の障害｜モデル間を移動する「波状障害」（約4時間51分）

出典: Claude公式サイト

2日目は日本時間14:57〜19:48と、日本のビジネスアワーを直撃しました。しかも単純な一括ダウンではなく、復旧と再燃を繰り返しながら障害がモデル間を移動する展開になっています。

インシデント「Elevated errors across many models」（インシデントID: fsh2zzzl2c4l）の影響コンポーネントとして、公式は claude.ai / Claude API（api.anthropic.com） / Claude Code / Claude Cowork を明記しています。

継続時間は約4時間51分で、前日より長期化しました。

「Opus 5 → Sonnet 5 → Fable 5 → 全モデル」という推移が意味すること

この推移は実務上とても重要です。Claude Codeの公式ドキュメントでは、529が繰り返し出る場合の対応として「容量はモデルごとに追跡されるため、/model で別のモデルに切り替えて作業を続ける」ことが案内されています。実際、特定モデルが混雑しているとき、Claude Codeが「Opusが高負荷なので /model でSonnetに切り替えてください」といったメッセージを出す仕様も公式に記載されています。

7月30日の障害は、この前提が効く時間帯と効かない時間帯の両方があったケースでした。

• 15:26〜17:33頃：エラーが特定モデルに偏っていたため、/model での退避が有効に働きやすい局面
• 17:33〜19:03頃：全モデルにエラーが再拡大したため、モデル切り替えでは逃げられない局面

つまり「モデルを切り替えれば必ず動く」わけではなく、まずステータスページで“いま落ちているのがどのモデルか”を確認してから切り替えを判断するのが正しい順序になります。各モデルの特性は「Claude Opus 5とは」「Claude Sonnet 5とは」「Claude Fable 5とは」で整理しています。

同日にはOpus 4.8の別インシデントも発生

同じ7月30日には、「Degraded performance on Claude Opus 4.8」（インシデントID: kqjy03gs895j）も記録されています。13:43 UTCに調査開始、14:24 UTCに解決（日本時間22:43〜23:24、約41分）で、7月30日だけで公式インシデントが2件以上発生した計算になります。対象モデルの詳細は「Claude Opus 4.8とは」を参照してください。

529 Overloadedエラーとは何か｜公式定義とエラーコード早見表

出典: Claude Platform Docs - Claude API errors

529 Overloaded は、AnthropicのAPIが一時的に過負荷状態にあることを示すエラーです。公式のAPIエラーリファレンスでは overloaded_error として定義され、「APIが一時的に過負荷状態です」と説明されています。あわせて「529エラーは、APIが全ユーザーにまたがる高トラフィックを経験しているときに発生することがあります」という注記も置かれています。

エラーレスポンスは次のような形状で返ります。

{
  "type": "error",
  "error": {
    "type": "overloaded_error",
    "message": "..."
  },
  "request_id": "req_011CSHoEeqs5C35K2UUqR7Fy"
}

すべてのレスポンスには request-id ヘッダーが付与されます。サポートに問い合わせる際はこのIDを添えるよう、公式が案内しています。

エラーコード別｜誰の問題か・自分で直せるか

障害時に最も混乱しやすいのが、似たコードの取り違えです。公式のHTTPエラーコード定義をもとに、実務判断に必要な3点（誰の問題か／自分で直せるか／正しい対処）で整理しました。

「Maxプランにすれば529は直る」は誤解

529と429の混同は、不要な課金判断につながるという点で実害があります。529はサービス全体のキャパシティ飽和であり、個々のアカウントの上限とは無関係です。したがって上位プランに変更しても529は回避できません。

さらにClaude Codeの公式ドキュメント（日本語版）には、529はユーザーの使用制限としてカウントされず、クォータを消費しない旨が明記されています。障害中に何度もリトライしてしまった場合でも、529で返ってきた分については使用量への影響を過度に心配する必要はないという理解でよいでしょう。

一方、429が頻発している場合はプランや利用設計の見直しに意味があります。プラン別の上限や料金は「Claudeの料金プラン」「Claude Codeの料金」「Claude Maxプランの解説」で確認できます。

529はセキュリティインシデントではない

「Claudeが落ちた＝不正アクセスがあったのでは」と不安になる方もいますが、529は可用性の問題であり、情報漏えいや不正アクセスを示すものではありません。今回の障害についても、Anthropicからデータ消失や情報漏えいに関する報告は出ていません（「消失しない」と断定はできませんが、公式の報告は確認されていません）。Claudeのセキュリティ設計全般は「Claudeのセキュリティ」で解説しています。

Claude Codeへの影響が大きかった理由

出典: GitHub - anthropics/claude-code

今回の障害でClaude Codeの話題が突出したのは、作業が中断されるダメージがチャット利用より大きいためです。

チャットであれば「もう一度送る」で済みますが、Claude Codeはファイル編集・テスト実行・コミットといった一連の作業をエージェントが継続する使い方が中心です。途中でAPIが応答しなくなると、実行中のタスクが中断され、作業状態の把握からやり直しになります。CIやスケジュール実行に組み込んでいる場合は、ジョブの失敗としてパイプライン全体に波及します。

依存度の高さを示すデータもあります。Pragmatic Engineerによる15,000人規模の調査では、AIエージェントを使う開発者の約71%がClaude Codeを主要ツールとして挙げたと報告されています。またMicrosoft Researchの分析では、Claude Code利用者は非利用者に比べておよそ24%多くプルリクエストをマージしているという結果も示されています。いずれも二次情報のため断定はできませんが、「開発フローの中核に入り込んでいるツールが数時間止まる」というインパクトを説明する材料にはなります。

Claude Code自体の機能や使い方は「Claude Codeとは」「Claude Code使い方ガイド」で整理しています。

今すぐできる対処法【個人・チャット利用者編】

529が表示されたとき、個人利用でやるべきことは次の4ステップです。上から順に実行してください。

1. status.claude.com で公式のインシデント有無を確認する

最初にやるべきは「自分の問題か、Anthropic側の問題か」の切り分けです。公式ステータスページはコンポーネント単位（claude.ai／Claude API／Claude Code／Claude Cowork／Console など）で状態を表示するため、自分が使っている経路が落ちているかをピンポイントで確認できます。インシデントが掲載されていれば、それは待つべき事象です。

2. 数分おいてから再試行する（連打しない）

公式は5xx系エラーに対して指数バックオフでの再試行を推奨しています。1秒間隔の連打は輻輳を悪化させるだけで、復旧を早めることはありません。数分単位で間隔を空けるのが現実的です。

3. 別のモデルに切り替える

チャットのモデル選択やClaude Codeの /model で、混雑していないモデルへ移ります。容量はモデル単位で管理されているため、特定モデルだけが不調な局面ではこれが最も速い回避策になります。

4. 締め切りが迫っている作業は別ツールへ退避する

全モデルが落ちている局面では、待つ以外の手はありません。原稿・調査・要約といった作業は他の生成AIで代替できます。代替候補の比較は「ClaudeとChatGPTの違い」「ClaudeとGeminiの違い」が参考になります。

やっても意味がない対処（よくある誤り）

障害時に時間を無駄にしないため、529には効かない対処も明示しておきます。

今すぐできる対処法【開発者・法人編】

出典: Claude Code Docs - Troubleshooting

APIやClaude Codeを業務システムに組み込んでいる場合は、障害を「その場でしのぐ」だけでなく、設計で吸収する発想が必要です。

1. Claude Codeのリトライ挙動を環境変数でチューニングする

Claude Codeは529を画面に表示する前に、すでに複数回のリトライを行っています。この挙動は公式ドキュメントに記載された環境変数で調整できます。

障害が長期化しても無人ジョブを落としたくない場合は CLAUDE_CODE_RETRY_WATCHDOG=1 が有効です。ただしリトライを長く回すほど、ジョブの実行時間とコストは増える点に注意してください。対話的に使う開発者のローカル環境では、むしろリトライを短くして早く失敗させ、手動でモデルを切り替えたほうが待ち時間は短くなります。

なお、v2.1.198以降では529発生時にリトライのカウントダウンの下にステータス確認先が表示され、v2.1.185以降ではストリームが20秒無応答になると「Waiting for API response…」の表示が出ます。この表示はまだ失敗ではないため、慌てて中断する必要はありません。

CI環境や無人実行の設計は「Claude CodeとGitHub Actions連携」「Claude Codeのルーティン運用ガイド」、リトライとコストの関係は「Claude Codeのコスト最適化」で補足しています。

2. SDKの自動リトライを前提に、独自実装を重ねすぎない

公式SDKは、接続エラー・レート制限・5xx系サーバーエラーといった一時的な失敗を、既定で2回まで指数バックオフでリトライします。retry-after ヘッダーがある場合はそれを尊重する仕様です。各クライアントで最大リトライ回数の変更や無効化も可能です。

自前のリトライ処理を上に重ねると、実際の試行回数が想定の数倍に膨らむことがあります。まずSDKの既定挙動を把握したうえで調整してください。エラー判定はメッセージ文字列のマッチではなく、SDKが提供する型付き例外をcatchする方法が公式に推奨されています。

3. サーキットブレーカーとフォールバックを用意する

エンドユーザー向けサービスにClaudeを組み込んでいる場合、障害時に「エラー画面のまま固まる」のが最も避けたい状態です。開発コミュニティで広く共有されている実務パターンとしては、次のような設計があります（公式仕様ではなく一般的な設計手法です）。

• 連続して529が返ったら一定時間リクエストを止める（サーキットブレーカー）
• 停止中はキャッシュ済みの応答、簡易ロジック、またはメンテナンス表示にフォールバックする
• リトライ間隔は1〜2秒以上から始め、指数的に広げる

4. 長時間・大量処理は同期リクエストで投げない

504（タイムアウト）対策としても有効ですが、障害多発期には特に重要です。公式は長時間リクエストに対してストリーミングのMessages APIとMessage Batches APIの利用を案内しています。バッチであれば結果をポーリングで取得できるため、ネットワークが一時的に不安定でも作業がやり直しになりにくくなります。

5. 経路の冗長化を検討する（ただし万能ではない）

Anthropicは直APIのほかに、Claude Platform on AWS、Google CloudのAgent Platform、Microsoft Foundry経由での提供形態を公式に用意しています。接続先を分けておけば、特定経路の障害時に切り替えられる可能性があります。

ただし注意点があります。今回のようにモデル基盤側でエラーが発生している場合、経由するクラウドを変えても回避できるとは限りません。この点についてAnthropicの公式見解は確認できていないため、「経路を分ければ確実に落ちない」とは考えないでください。AWS経由の構成は「Claude Platform on AWS」で解説しています。

障害を最速で検知する方法｜通知購読の設定

障害時に最も価値があるのは「落ちていると早く知ること」です。公式ステータスページ（Atlassian Statuspage基盤）は、インシデントの作成・更新・解決時に通知を送る購読機能を標準で備えています。

チームで使うなら、Slackまたは Teamsの共有チャンネルに流す設定を1つ作っておくだけで、「Claudeが落ちてる？」という問い合わせがチャットに乱立する状況を防げます。Webhookを使えば、インシデント発生時に社内の障害対応フローを自動起動することも可能です。

なお公式が案内する確認先は status.claude.com です。旧ドメイン（status.anthropic.com 等）や非公式の監視サイト、SNSの投稿は速報性で先行することがありますが、一次情報として扱うのは公式ステータスページのみにしてください。

復旧したかを自分で確認する手順

1. status.claude.com を開き、自分が使っているコンポーネントの行（claude.ai／Claude API／Claude Code／Claude Cowork）を確認する
2. インシデントのステータスが Monitoring ではなく Resolved になっているかを見る
3. 短いプロンプトで1回だけ試す（いきなり長時間の重い処理を投げない）

Resolved表示後もレイテンシの上昇が残ることがあります。7月29日のケースでも、Monitoring期間を挟んでから解決宣言に至っています。復旧直後に大量のジョブを一斉に再投入しないのが安全です。

今回の障害は異常だったのか｜2026年7月の発生頻度と背景

7月29-30日の障害は単発の事故ではなく、7月後半に集中した一連の障害の一部と見るのが実態に近いです。

第三者の稼働監視サービスStatusGatorの集計によれば、2026年7月下旬のClaude関連インシデントは次のように記録されています。

7月24日から30日までの7日間で10件という頻度です。ただしStatusGatorの集計単位や継続時間は公式ステータスページの記録と完全には一致しません（7月29日を公式は「エラー率上昇が約1時間41分、インシデント全体で約2時間47分」としています）。厳密な数値は公式値を、傾向の把握にはStatusGatorをという使い分けが適切です。

原因は公表されていない

Anthropicは7月29日・30日の障害について技術的な根本原因（RCA）を公表していません（2026年7月31日時点）。公式ステータスページの記載は「複数モデルにまたがるエラー率の上昇」という事象説明にとどまっています。「キャパシティ不足が原因だった」と断定する解説を見かけることがありますが、それは公式の説明ではありません。

背景として言えるのは、Anthropicが以前から計算資源の逼迫に言及してきたという事実です。2026年4月には「Claudeへの需要は前例のない速度で伸び、特にピーク時にインフラが引き伸ばされている」「計算資源は業界全体の制約であり、AmazonやGoogleとの提携拡大を含めて急速にスケールさせている」といった趣旨のコメントが出ています。CEOのDario Amodei氏も自社を計算資源の制約下にあると公言してきました。

ただし、これらは今回の障害の原因としてAnthropicが説明したものではありません。あくまで背景要因として捉えてください。

また、キャパシティ以外の要因で障害が起きた例もあります。2026年6月2日の障害は、Claude Codeのサブエージェント機構のバグが原因とされています。「Claudeの障害＝常に過負荷」ではない点も押さえておくとよいでしょう。

Claudeを業務のクリティカルパスに置いてよい人／避けたほうがよい人

障害の頻度を踏まえたうえで、どこまでClaudeに依存してよいかの判断材料を整理します。

クリティカルパスに置いても問題が小さい人

• 作業のタイミングを自分でずらせる方：数時間の遅延が許容できる原稿作成・調査・分析などの用途
• 代替手段を併用している方：ChatGPTやGeminiなど別系統のツールにアカウントを持ち、切り替えて作業を継続できる体制がある
• モデル切り替えを使いこなせる方：/model で退避できるため、部分障害時のダウンタイムを短縮できる
• 通知を購読済みのチーム：Slack／Teams連携で状況をすぐ共有でき、無駄な調査時間が発生しない
• バッチ処理中心の運用：Message Batches APIを使い、実行時刻に幅を持たせられる設計になっている

依存を避ける、または設計を見直したほうがよい人

• 秒単位のリアルタイム応答が必須のサービス：エンドユーザーの画面が直接止まる構成は、フォールバックなしでは危険です
• 人手の代替手段がまったくない業務：AIが止まると業務そのものが停止する場合、手動フローの維持が必要です
• 締め切り直前にしか作業できない方：数時間の障害が致命傷になります。バッファのある進行に変えるほうが確実です
• 単一経路・単一モデルに固定している開発チーム：モデル指定をハードコードしていると、部分障害時に退避できません
• 可用性のSLAを顧客に約束している事業者：障害時の補償・SLA条件について公式の一般公開情報は確認できていないため、契約内容を個別に確認する必要があります

法人利用のリスク管理全般は「Claude Codeのセキュリティガイド」「AIエージェントのセキュリティ対策」もあわせて参照してください。チーム利用の実務は「Claude Coworkとは」で解説しています。

よくある質問（FAQ）

Q1. 529エラーが出たとき、使用量（クォータ）は消費されますか？

Claude Codeの公式ドキュメント（日本語版）には、529はユーザーの使用制限としてカウントされない旨が明記されています。一方で429（レート制限）は自分のアカウントの上限に到達した状態なので扱いが異なります。画面に出たコードが529なのか429なのかを確認したうえで、使用量を気にするかどうかを判断してください。

Q2. 障害中に送ったAPIリクエストの課金はどうなりますか？

現時点で、障害時のリクエストに対する課金・返金・クレジット補填のポリシーについて、Anthropicの公式な一般公開情報は確認できていません。気になる場合は、レスポンスに含まれる request_id を添えてサポートに問い合わせるのが確実です。

Q3. 会話履歴やプロジェクトのデータは消えますか？

今回の障害は可用性（サービスが応答しない）の問題であり、データ消失に関する公式の報告は出ていません。ただし「絶対に消えない」と断定はできないため、重要な出力は都度手元に保存しておく運用が安全です。

Q4. Claudeが落ちているのか、自分の回線の問題なのかを見分けるには？

まずstatus.claude.comでインシデントの有無を確認します。公式にインシデントが出ていなければ自分側の可能性が高いため、別ネットワーク（スマホのテザリング等）での接続、VPN・プロキシの一時オフ、別ブラウザでの確認という順で切り分けてください。エラーコードが529なら基本的にサービス側、401なら認証、429なら自分のアカウントの上限が疑われます。

Q5. 過去の障害履歴はどこで確認できますか？

status.claude.com には過去のインシデント履歴と計画メンテナンスが掲載されています。各インシデントには固有のIDが振られており、更新の時系列も残るため、事後の報告書作成にそのまま使えます。第三者サービスのStatusGatorでも履歴を確認できますが、集計方法が異なるため公式値と数字が一致しない点に注意してください。

Q6. Claude Codeで「Waiting for API response」と出たら、すぐ中断すべきですか？

すぐに中断する必要はありません。v2.1.185以降のClaude Codeでは、ストリームが20秒無応答になるとこの表示が出る仕様で、この時点ではまだ失敗が確定していません。リトライのカウントダウンが進むかどうかを見てから判断してください。

Q7. 障害が頻発するなら、別のAIツールに乗り換えるべきですか？

障害の頻度だけを理由に主力ツールを変える判断は早計です。生成AI各社は総じて需要増によるキャパシティ制約を抱えており、乗り換え先でも同種の障害は起こりえます。現実的な対策は、主力を維持しつつ代替手段を1つ用意しておくことです。比較検討には「ClaudeとChatGPTの違い」が参考になります。

まとめ

2026年7月29日〜30日のClaude障害は、公式ステータスページ上でいずれも解決済みとなっており、2026年7月31日時点でclaude.ai・Claude API・Claude Code・Claude Coworkは復旧しています。7月29日はエラー率上昇が約1時間41分、7月30日は約4時間51分で、後者は日本のビジネスアワーを直撃し、モデル間を移動する波状の障害となりました。

実務面で押さえるべきポイントは次の3点です。

• 529 Overloadedはサービス側の過負荷であり、再ログインやAPIキー再発行、上位プランへの課金では解決しない
• 容量はモデル単位で管理されるため、部分障害なら /model での切り替えが有効。全モデル障害時は待つか代替手段に逃がす
• 次に備えるなら、ステータスページのSlack／Teams／Webhook通知の購読と、リトライ・フォールバックの設計が最も効果が大きい

Anthropicは今回の障害の根本原因を公表していません。憶測で原因を断定するより、落ちる前提でワークフローを設計しておくことが、現時点でユーザー側にできる最も確実な対策です。

関連記事

• Claude全体の機能や料金を確認したい方は「Claudeとは？機能・料金・使い方を解説」
• Claude Codeの基本を知りたい方は「Claude Codeとは」「Claude Code使い方ガイド」
• 課金判断を整理したい方は「Claudeの料金プラン」「Claude Codeの料金」
• セキュリティ観点を確認したい方は「Claudeのセキュリティ」「AIエージェントのセキュリティ対策」
• 代替ツールを検討したい方は「ClaudeとChatGPTの違い」「ClaudeとGeminiの違い」
• クラウド経由での構成を検討する方は「Claude Platform on AWS」