Claude大規模障害まとめ｜7月29-30日の世界規模ダウン〜10月の障害履歴と529 Overloadedエラーの意味・対処法【2026年最新】

2026年7月29日・30日のClaude大規模障害は全モデル規模のエラーが2日続いたもので、どちらもすでに解決済みです（2026年10月6日時点の公式ステータスは「All Systems Operational（全システム正常）」）。障害中に多く表示された 529 Overloaded はAnthropic側の一時的な過負荷を示すエラーで、アカウントやAPIキー、コードの問題ではないため、status.claude.com で障害を確認し、数分待って再試行するか別のモデルに切り替えるのが正しい対処です。

ただし、8月以降も公式インシデントは月に10件を超えるペースで出ており、529への備えは今も必要です。

この記事でわかること

• 529 Overloadedが出たときに、いま何をすればよいか（30秒で確認する手順）
• 529の公式定義と、429・500・400など似たエラーとの違い
• Claude Codeでの表示内容、/model での切り替え、リトライ設定（環境変数）
• 効かない対処と、むしろ逆効果になる対処
• 2026年7月29日・30日の障害の経緯（公式ステータスページの時刻を日本時間で併記）
• 2026年8月〜10月の主な障害履歴と、重大度の読み方
• 業務でClaudeを使う人・チームが用意しておくべきこと

想定読者：いま529が出て困っている方、Claude CodeをCIや開発フローに組み込んでいる方、社内でAIツールの可用性リスクを説明する立場の方。

529 Overloadedが出たら今すぐやること｜30秒チェックと4つの手順

529が出たら、まず「Anthropic側の障害か」を確認し、障害中なら連打せずに待つか、モデルを切り替えます。 プラン変更・再ログイン・APIキーの再発行では直りません。

30秒でできる確認

1. status.claude.com を開く：画面上部にインシデントが出ていないか確認します
2. 自分が使っている経路の行を見る：公式は claude.ai / Claude Console（platform.claude.com） / Claude API（api.anthropic.com） / Claude Code / Claude Cowork / Claude for Government に分けて状態を表示しています
3. インシデント本文で対象モデルを確認する：「Opus 5のみ」「全モデル」など、どのモデルで問題が起きているかが書かれていることが多いです

インシデントが出ていれば待つしかない状況、出ていなければ自分側（回線・プランの上限・設定）の問題を疑います。Bedrock・Google Cloud・Microsoft Foundry経由でClaudeを使っている場合は、Claude Code公式ドキュメントの案内どおり、各クラウドのステータスページも確認してください。

4つの対処手順

手順3の切り替え先は、2026年10月時点の現行モデルである Claude Opus 5.5 / Claude Sonnet 5.5 / Claude Fable 5.1 / Claude Haiku 4.5 から、障害の出ていないものを選びます。それぞれの特徴は「Claude Opus 5.5とは」「Claude Sonnet 5.5とは」「Claude Fable 5.1とは」で解説しています。なおHaiku 4.5は、公式のモデル一覧で「2026年10月15日以降に提供終了の可能性」と案内されています。常用の退避先にするなら、提供状況を確認してからにしてください。

手順4の代替先を選ぶときは、「ClaudeとChatGPTの違い」「ClaudeとGeminiの違い」を参考にしてください。

ステータスページ自体が開けないとき

2026年8月14日には、証明書の問題で status.claude.com そのものに約3時間アクセスできない障害（JST 16:58〜19:53）が起きました。こうしたときのために、次の確認手段も持っておくと安心です。

• 公式ステータスのメール・SMS通知（事前に登録が必要）
• RSSフィード：https://status.claude.com/history.rss
• JSON API：https://status.claude.com/api/v2/summary.json（Atlassian Statuspageの標準API）

Downdetectorなどの非公式監視サイトやSNSは公式より早く反応することがありますが、一次情報ではありません。最終的な判断には公式ステータスを使ってください。

529 Overloadedエラーとは｜公式定義と429・500との違い

出典: Claude Platform Docs - API errors

529は overloaded_error という種類のエラーで、公式ドキュメントでは「APIが一時的に過負荷になっている」と定義されています。 さらに「529は、すべてのユーザーにまたがってAPIのトラフィックが多いときに発生することがある」と注記されています。つまり、個人の設定や契約の問題ではありません。

APIから返るエラーは次のような形式です。

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

すべてのレスポンスには request-id ヘッダーが付き、エラー本文にも request_id が入ります。サポートに問い合わせるときは、このIDを添えるよう公式が案内しています。

エラーコード別｜原因・自分で直せるか・対処法

障害時によく起きるのが、似たエラーの取り違えです。2026年10月時点の公式エラー一覧をもとに、「原因はどこか」「自分で直せるか」で整理しました。

429には注意が必要です。 公式によると、支出上限に達して返る429には retry-after ヘッダーが付かず、上限が解除されるまで何度送っても失敗し続けます。また組織の利用量が急に増えた場合、「acceleration limits（急増を抑える制限）」で429が返ることもあり、公式はトラフィックを徐々に増やすよう案内しています。

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

529は全ユーザー共通の処理能力が足りなくなった状態なので、Pro・Maxなど上位プランに変えても避けられません。プランを見直す意味があるのは、429（自分のアカウントの上限）が頻発する場合です。

使用量の心配も基本的には不要です。Claude Codeの公式エラーリファレンスには「529は使用上限ではなく、クォータ（利用枠）にカウントされない」と書かれています。障害中に何度も再試行してしまっても、529で返った分は使用量を気にしなくてよい、という理解で問題ありません。

プランごとの上限は「Claudeの料金プラン」「Claude Codeの料金」「Claude Maxプランの解説」「Claude Codeの週間上限」で確認できます。

529は情報漏えいなどのセキュリティ事故ではない

529は「サービスが応答しにくい」という可用性の問題で、不正アクセスや情報漏えいを意味するものではありません。7月29日・30日の障害についても、Anthropicからデータの漏えい・消失の報告は出ていません。

ただし、障害の種類によっては送信内容が保存されないこともあります。9月29日の障害では、公式が「14:00〜14:59 UTC（JST 23:00〜23:59）に送信された一部のメッセージは保存されていない可能性がある」と明記しました。長い文章や重要な指示は、送る前に手元にコピーしておくと安全です。生成AIのセキュリティ全般は「生成AIのセキュリティ対策」で解説しています。

Claude Codeで529が出たときの表示と対処

出典: GitHub - anthropics/claude-code

Claude Codeは529を画面に表示するまでに、すでに最大10回の自動リトライを済ませています。 そのため529が表示された時点で、少し待って再実行するか、/model でモデルを切り替えるのが基本の対応になります。

ファイル編集・テスト・コミットを続けて行うClaude Codeは、チャットより途中で止まったときのダメージが大きくなります。7月29日の障害では、IBTimes UKの報道によるとDowndetectorへの報告が2,000件を超え、そのおよそ半数がClaude Code関連でした（Downdetector経由の二次情報のため参考値）。Claude Code自体の基本は「Claude Codeとは」で解説しています。

表示されるメッセージ別の意味とやること

Claude Code公式のエラーリファレンス（2026年10月時点）に載っている主な表示をまとめました。

529なのか使用上限なのかを見分けたいときは、/usage（プランの上限とリセット時刻）や /status（使っている認証情報）で確認できます。セットアップ全体の問題を調べるときは /doctor を使います。

/model で切り替えるときの注意点

公式によると、Claude Codeの処理能力はモデルごとに管理されているため、/model での切り替えが最も手軽な回避策です。ただし注意点が2つあります。

• キャッシュがリセットされる：モデルを切り替えるとプロンプトキャッシュが使えなくなり、会話全体をキャッシュなしで読み直します。長い会話では使用量・コストが一時的に増えます
• 全モデルが落ちていると効かない：7月29日の障害や、7月30日の17:33〜19:03（JST）のように全モデルでエラーが出ている間は、どこに切り替えても状況は変わりません

なお最新モデルを使うには、Claude Codeのバージョンも新しくしておく必要があります。公式のモデル一覧では、Opus 5.5はv2.1.280以降、Sonnet 5.5はv2.1.284以降が必要とされています。障害中に慌ててアップデートしなくて済むよう、普段から最新にしておきましょう。キャッシュとコストの関係は「Claude Codeのコスト最適化」で詳しく扱っています。

リトライ動作を環境変数で調整する

出典: Claude Code Docs - Troubleshooting

Claude Codeのリトライ動作は、公式ドキュメントに載っている環境変数で調整できます。

使い方の目安は次のとおりです。

• CI・夜間バッチなど人がいない実行：CLAUDE_CODE_RETRY_WATCHDOG=1 を設定すると、数時間の障害でもジョブを落とさずに済みます。ただし、その分だけ実行時間は延びます
• 手元で対話しながら使う場合：CLAUDE_CODE_MAX_RETRIES を減らして早めにエラーにし、手動で /model を切り替えたほうが待ち時間は短くなります
• セッションを閉じてしまった場合：claude --resume または --continue で会話を再開できます

CIでの設定は「Claude CodeとGitHub Actionsの連携」、定期実行の設計は「Claude Codeのルーティン運用ガイド」もあわせてご覧ください。

効かない対処・逆効果な対処

529はAnthropic側の問題なので、自分の環境をいじる対処はほぼ効きません。 障害中に時間を無駄にしないよう、よくある誤りをまとめました。

再ログインには特に注意してください。9月29日の障害ではSSOやSign in with Appleでのログインができなくなり、公式が「サインイン中の方はサインアウトしないでください」と呼びかけました。障害中に一度ログアウトすると、復旧まで再ログインできなくなる場合があります。

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

出典: Anthropic公式サイト

7月29日の障害は、全モデルでエラー率が上がった約1時間41分の障害で、公式の重大度は最も高い「critical」でした。 日本時間では7月30日の早朝（04:45〜06:26）にあたり、日本の業務時間には重なりませんでした。

公式インシデント「Elevated errors across all models」の経過は次のとおりです。

• エラー率が上がっていた時間：約1時間41分（19:45〜21:26 UTC）
• 調査開始から解決宣言まで：約2時間47分

BleepingComputerは、Anthropicが世界規模の障害を認めた一方で、根本原因や復旧見込みは明らかにしなかったと報じています。この障害はClaudeのAPIを使う他社のツールにも影響しました。

2026年7月30日の障害｜モデルを移りながら続いた障害（約4時間51分）

出典: Claude公式サイト

7月30日の障害は日本時間14:57〜19:48の約4時間51分続き、日本の平日午後を直撃しました。 まとめて止まるのではなく、あるモデルが回復すると別のモデルでエラーが出る、という形で障害が移っていったのが特徴です。

公式インシデント「Elevated errors across many models」（重大度：major）の影響範囲は、claude.ai / Claude API / Claude Code / Claude Cowork です。

Opus 5 → Sonnet 5 → Fable 5 → 全モデル、という流れからわかること

この日は、モデルの切り替えが効いた時間帯と、効かなかった時間帯の両方がありました。

• 15:26〜17:33頃（JST）：エラーが特定のモデルに偏っていたため、/model での切り替えが効きやすかった
• 17:33〜19:03頃（JST）：全モデルにエラーが広がり、切り替えでは避けられなかった

「モデルを替えれば必ず動く」わけではありません。ステータスページでいまどのモデルが落ちているかを確認してから切り替えるのが正しい順番です。当時の対象モデルについては「Claude Opus 5とは」「Claude Sonnet 5とは」「Claude Fable 5とは」で解説しています。

7月30日〜31日の関連インシデント

公式ステータスページには、同じ時期にほかのインシデントも記録されています。

7月29日から31日まで、3日続けて公式インシデントが出ていたことになります。さらに直前の7月25日〜27日にも、Opus 5を中心にmajor 3件・minor 3件のインシデントが続いていました。Opus 4.8については「Claude Opus 4.8とは」をご覧ください。

2026年8月〜10月の主な障害履歴｜その後も続く障害

7月末の障害後も、Claudeの公式インシデントは8月に25件、9月に13件記録されています。 重大度major以上は8月・9月ともに8件で、日本の業務時間に重なったものも少なくありません。

公式インシデントの件数（重大度別）

公式ステータスページのAPIで取得できた直近50件（2026年7月25日〜10月5日）を集計しました。

重大度の読み方：公式ステータスページ（Atlassian Statuspage）は、インシデントに critical / major / minor / none の4段階の重大度を付けています。各段階の厳密な定義はAnthropicから公表されていませんが、実際のインシデントを見ると、critical は広い範囲でサービスがほぼ使えない状態、major は主要な機能やモデルでの大きな障害、minor は一部のモデルの性能低下や短時間のエラー、none は情報提供に近いもの、と捉えると読みやすくなります。7月29日と8月17日はcriticalでした。

主な障害の一覧（日本時間）

8〜10月の記録では、最新のFable 5.1や、限定提供のMythos 5.1でのエラーが目立ちます。業務で使う場合は、障害時に退避するモデルをあらかじめ決めておくと慌てずに済みます。Mythosについては「Claude Mythosとは」、Coworkについては「Claude Coworkとは」で解説しています。

「障害が原因だが529ではない」ケースもある

すべての障害で529が出るわけではありません。8〜10月には、次のような529以外の症状も記録されています。

• ログインできない（8/5、8/17、8/25未明、9/29）：認証まわりの障害。再ログインを繰り返さず、復旧を待つ
• 残高不足でAPIが失敗する（10/2）：自分では購入済みでも、クレジットの反映が遅れて失敗した。課金系のエラーが出たら、まずステータスを確認する
• Windows版Coworkだけが動かない（9/10〜9/15）：原因はAnthropicでもユーザーでもなくOSの更新。公式によると、再起動や再インストールでは直らなかった
• 上流クラウドの障害（8/29）：Claude Code on the webなど、特定の機能だけが止まる

「自分の設定がおかしいのでは」と思ったときも、まずステータスページを確認するのが近道です。

障害の原因と補償はどうなっているか

7月29日・30日の障害について、Anthropicは根本原因を公表していません（2026年10月6日時点）。 公式ステータスページは「複数モデルでエラー率が上がった」という事象の説明にとどまっており、事後報告（ポストモーテム）も確認できていません。

報道では、Anthropicが過去の障害について「需要が計算資源を上回った」と説明したことがあると伝えられています（IBTimes UK）。ただしこれは7月29日・30日の原因として説明されたものではないため、「キャパシティ不足が原因だった」と言い切ることはできません。8月29日の上流クラウドや9月のWindows更新のように、過負荷以外が原因の障害もあります。

補償（SLAクレジット・返金）についても、公式の一般向けの制度は確認できません。 障害時の課金や返金について気になる場合は、request_id を添えてサポートに問い合わせてください。法人契約で可用性の保証が必要な場合は、契約条件を個別に確認する必要があります。

開発者・法人向け｜障害に備えるための5つの対策

APIやClaude Codeを業務システムに組み込むなら、障害はその場でしのぐものではなく、仕組みの側で吸収するものと考えるべきです。 8月・9月だけでmajor以上が16件あったことを考えると、「落ちることがある」前提で作っておくのが現実的です。

1. 公式SDKの自動リトライを前提にする

公式SDKは、接続エラー・レート制限・5xx系エラーを既定で2回、指数バックオフでリトライし、retry-after ヘッダーがあればそれに従います。回数は max_retries（TypeScript・Javaなどは maxRetries）で変更・無効化できます。自前のリトライ処理を重ねると、実際の試行回数が想定の何倍にも膨らむので注意してください。

エラーの判定は、メッセージの文字列ではなくSDKの型付き例外をcatchする方法が公式に推奨されています。ストリーミング（SSE）では、200の応答が返った後にエラーが起きることもあるため、その処理も別に用意しておく必要があります。

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

エンドユーザー向けのサービスで最も避けたいのは、エラー画面のまま固まる状態です。公式の仕様ではありませんが、一般的には次のような作り方がよく使われます。

• 529が続けて返ったら、一定時間リクエストを止める（サーキットブレーカー）
• 止めている間は、キャッシュ済みの応答・簡単な処理・メンテナンス表示に切り替える
• 復旧後に大量のジョブを一度に流し直さない

3. 長い処理・大量処理はストリーミングかBatches APIで

公式は、時間のかかるリクエスト（特に10分を超えるもの）にはストリーミングのMessages APIかMessage Batches APIを勧めています。バッチなら結果をあとから取りに行けるので、障害が多い時期でもやり直しが減ります。

4. 通知を購読して「落ちた」ことをすぐ知る

公式ステータスページでは、インシデントの発生・更新・解決時に通知を受け取れます。

Slack・Teamsの共有チャンネルに流す設定を1つ作っておくだけで、「Claude落ちてる？」という問い合わせが社内に乱立するのを防げます。8月14日のようにステータスページ自体が開けない場合に備えて、メールやRSSなど別の経路も用意しておきましょう。

5. 提供経路を複数用意する（ただし万能ではない）

Claudeは、Anthropic直接のAPIに加えて、Claude Platform on AWS・Amazon Bedrock・Google Cloud・Microsoft Foundryからも使えます。複数の経路を用意しておけば、特定の経路だけの障害なら切り替えられる可能性があります。

ただし、モデル自体でエラーが起きている場合に、別のクラウド経由なら避けられるという公式の説明はありません。「経路を分ければ落ちない」とは考えないでください。AWS経由の構成は「Claude Platform on AWS」で解説しています。セキュリティ面の整備は「Claude Codeのセキュリティガイド」もあわせて確認してください。

復旧したかを確かめる手順

1. status.claude.com で、自分が使っている経路の行が正常に戻っているか確認する
2. インシデントが「Monitoring（経過観察）」ではなく「Resolved（解決）」になっているか確認する
3. まず短いプロンプトを1回だけ送ってみる。いきなり重い処理は送らない

7月29日も、エラーが収まってから解決宣言まで約1時間かかっていました。復旧直後は応答が遅れやすいため、ジョブを一斉に流し直すのは避けたほうが安全です。

Claudeを業務の要に置いてよい人・慎重にすべき人

8月・9月だけでmajor以上の障害が16件あったことを踏まえると、Claudeにどこまで頼ってよいかは使い方によって分かれます。

業務の中心に置いても影響が小さい人

• 作業のタイミングをずらせる人：数時間遅れても困らない資料作成・調査・分析が中心
• 代わりのツールを持っている人：ChatGPTやGeminiなどにもアカウントがあり、すぐ切り替えられる
• モデルの切り替えに慣れている人：/model で退避でき、一部のモデルだけの障害なら止まる時間を短くできる
• 通知を購読済みのチーム：Slack・Teamsで状況をすぐ共有でき、原因探しに時間を取られない
• バッチ処理が中心の運用：Message Batches APIなどで、実行時刻に余裕を持たせている

依存を避けるか、作り方を見直したほうがよい人

• 即時の応答が必須のサービス：ユーザーの画面がそのまま止まる構成は、フォールバックなしでは危険
• 人手での代替手段がない業務：AIが止まると業務そのものが止まるなら、手作業の手順を残しておく
• 締め切り直前にしか作業できない人：日本の平日昼間の障害（7/30、8/24、9/22など）も起きている。余裕のある進め方に変えたほうが確実
• モデル名を固定で書き込んでいる開発チーム：設定で切り替えられないと、一部のモデルだけの障害でも止まる
• 顧客に稼働率を保証している事業者：Anthropicの公式な補償制度は確認できないため、契約内容を個別に確認する必要がある

よくある質問（FAQ）

Q1. 「529 Overloaded」と出たら、どのくらい待てばよいですか？

決まった時間はありません。短時間で収まることもあれば、7月30日のように5時間近く続くこともあります。目安として、ステータスページにインシデントが出ている間は、数分〜十数分おきに1回試す程度にとどめ、Resolvedになってから本格的に再開するのが無駄のない方法です。

Q2. 529がずっと出るのにステータスページは正常です。どうすればいいですか？

ステータスへの反映には時間差があります。まず数分待ってから再確認してください。それでも正常表示のまま529が続くなら、/model で別のモデルを試す、Claude Codeを最新版にする、Bedrockなど他の経路を使っている場合はその経路のステータスを見る、の順で切り分けます。続く場合は /feedback かサポートに、request IDを添えて報告してください。

Q3. 障害中に送ったAPIリクエストに料金はかかりますか？

529でエラーになったリクエストの課金・返金について、公式の一般向けの説明は確認できていません。Claude Code（サブスクリプション利用）については、529はクォータにカウントされないと公式に書かれています。API利用で気になる場合は、request_id を添えてサポートに問い合わせてください。

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

7月29日・30日の障害では、データ消失の公式報告はありません。ただし9月29日の障害では「一部のメッセージが保存されていない可能性がある」と公式が明記しました。障害が起きているときは、重要な入力を送る前にコピーを取っておき、出力もこまめに手元に保存しておくと安全です。

Q5. 過去の障害履歴はどこで見られますか？

status.claude.com の履歴ページで、過去のインシデントと計画メンテナンスを確認できます。インシデントごとに固有のURLがあり、更新の経過も残るため、社内の障害報告書にそのまま使えます。StatusGatorなどの外部サービスでも履歴は見られますが、集計方法が違うため公式の数字とは一致しないことがあります。

Q6. Claude以外のAIツールに乗り換えたほうがいいですか？

障害の多さだけを理由に主力ツールを変えるのは早計です。乗り換え先のサービスでも障害は起こりえますし、使い慣れたワークフローを作り直す手間もかかります。現実的なのは、主力のClaudeは続けつつ、代わりのツールを1つ使える状態にしておくことです。比較には「ClaudeとChatGPTの違い」が参考になります。

まとめ

• 529 Overloaded はAnthropic側の一時的な過負荷。アカウント・APIキー・プランの問題ではなく、再ログインや上位プランへの変更では直らない
• まずstatus.claude.comを確認し、障害中なら連打せず待つ。一部のモデルだけの障害なら /model での切り替えが効く（キャッシュのリセットに注意）
• 2026年7月29日（critical、約1時間41分）と30日（major、約4時間51分）の障害はすでに解決済み。30日は日本の平日午後に、モデルを移りながら続いた
• 8月以降も障害は続いている。8月25件・9月13件の公式インシデントがあり、8/17のcritical、9/29のログイン障害とメッセージの未保存など、529以外の症状もある
• 備えとしては、通知の購読（メール・Slack・RSS）、Claude Codeのリトライ設定、SDKのリトライとフォールバックの設計、代わりのツールの用意が効果的

根本原因が公表されていない以上、ユーザー側にできる最も確実な対策は、落ちることがある前提で使い方を設計しておくことです。

関連記事

• Claudeの全体像を知りたい方：「Claudeとは」
• Claude Codeの基本：「Claude Codeとは」「Claude Codeのオートモードとは」
• 料金と上限：「Claudeの料金プラン」「Claude Codeの料金」
• 現行モデル：「Claude Opus 5.5とは」「Claude Sonnet 5.5とは」
• 代わりのツールの検討：「ClaudeとChatGPTの違い」「ClaudeとGeminiの違い」