Claudeの障害を確認する方法｜落ちた時に業務を止めない手順

「Claudeが返ってこない」「Claude Codeがエラーばかり出す」——作業の途中でこうなると、まず疑うのは自分の環境です。

結論から言うと、確認は「公式ステータスページ → 公式アナウンス → 自分側の切り分け」の3ステップに固定するのが一番速く、一番確実です。順番を決めておかないと、障害の日に限って設定を触ってしまい、復旧後に別の不具合を抱え込みます。

株式会社Fyveは、Claudeを業務の中核に据えて毎日無人でジョブを走らせています。この記事では2026年8月24日に実際に起きた障害を教材にして、確認の手順と、落ちている間に業務を止めないための備えを、私が実際にやっている形でお伝えします。

結論：Claudeが落ちたかは3ステップで確認する

迷ったときに毎回同じ順番で動けるように、確認手順は3つに固定します。所要時間は慣れれば1分ほどです。

• ステップ1：公式ステータスページを見る — status.claude.com を開く。ログイン不要で、claude.ai・API・Claude Code・Cowork がコンポーネント別に色分けされています
• ステップ2：公式アナウンスを見る — ステータスページの掲示は障害発生から十数分〜数十分遅れることがあります。その空白を埋めるのが公式SNSと、実際に返ってきているエラーコードです
• ステップ3：自分側かを切り分ける — 別の経路（Web版とAPI、別モデル、別ネットワーク）で1回だけ試す。ここで初めて自分の環境を疑います

大事なのはステップ3を最後に置くことです。多くの人は逆順にやります。再インストール、設定の書き換え、キャッシュ削除——それを全部やった後にステータスページを見て「最初から向こうが落ちていた」と気づく。この順番だと、復旧後に自分で壊した設定が残ります。

2026年8月24日に実際に起きたこと

手順の話だけだと実感が湧かないので、直近の実例で見ていきます。Anthropicの公式ステータスページに記録されているインシデント「Elevated errors for multiple models」です。

公式に記録されたタイムライン

以下はすべて status.claude.com の掲示に基づく時刻です。日本時間（JST）を併記します。

ここで2つ、実務上とても重要なことが読み取れます。

ひとつめは、実影響の開始（04:50 UTC）と、最初の掲示（05:06 UTC）に16分の差があること。つまり「ステータスページが緑だから自分の問題だ」と判断できるのは、落ち始めてから15分以上経った後だけです。落ちた直後の十数分は、ステータスページは当てになりません。

ふたつめは、「解決」の掲示（08:30 UTC）と、実際にエラーが止まった時刻（07:36 UTC）にも1時間近い差があること。復旧の掲示を待って作業を再開すると、実際にはもっと早く動かせたはずの1時間を失います。逆に言えば、掲示より先に自分で1回試してみる価値があるということです。

日本時間で見ると、この障害は月曜の13:50〜16:36、つまり平日の午後をまるごと直撃しています。夜間の障害とは重みが違います。

影響を受けたもの・受けなかったもの

公式が影響ありとして挙げたコンポーネントは次の4つです。

• claude.ai（Web版チャット）
• Claude API（api.anthropic.com）
• Claude Code
• Claude Cowork

一方、Claude Console と Claude for Government は影響対象に含まれていませんでした。この「含まれていないもの」の情報は見落とされがちですが、切り分けには使えます。Consoleにはログインできるのに API が返らないなら、それは自分のネットワークやアカウントの問題ではなく、モデル側の問題だと分かるからです。

対象になったモデルは、公式の掲示によれば Claude Mythos 5・Claude Fable 5・Claude Opus 5・Claude Opus 4.8 でした。つまり「別のモデルに切り替えれば動く」という回避が効きにくい、広い範囲の障害だったということです。

「529 Overloaded」が返ってきたときの意味

この日、利用者が多く目にしたのは 529 Overloaded というエラーでした。各社の報道でも同じエラーコードが報告されています。

529は「あなたのリクエストが間違っている」ではなく「受け側が今さばききれていない」という意味のコードです。ここを理解しているかどうかで、その後の行動が変わります。

• 4xx系（400・401・403・429）：多くは自分側に原因がある。リクエストの形、認証、権限、レート制限。設定を見直す価値がある
• 5xx系（500・503・529）：受け側の問題。設定をいじっても直らない。待つか、経路を変えるかの2択

529が出ているのに設定を触り始めるのは、時間の無駄であるだけでなく、有害です。復旧した後に「なぜか動かない」が残ります。

同じ日に、別のログイン障害が2件起きていた

もうひとつ見落としやすいのが、8月24日にはモデルのエラー障害とは別に、ログイン系のインシデントが2件記録されていることです。

• 16:02〜16:08 UTC（日本時間 8/25 01:02〜01:08）：claude.ai へのログインでエラー。Claude Code も影響対象
• 20:00〜20:08 UTC（日本時間 8/25 05:00〜05:08）：claude.ai へのアクセス・ログインでエラー。サブスクリプション経由での Claude Code のログインを含む

どちらも6〜8分の短時間で収束しています。ここから分かるのは、「Claudeの障害」はひとつの塊ではないということです。モデルが返らない障害と、ログインできない障害は原因も持続時間も別物で、対処も変わります。ステータスページを見るときは、大きな1件だけを見て安心せず、その日のインシデント一覧を見る癖をつけてください。

なお、この障害の技術的な原因について、Anthropicは公式には開示していません。「なぜ起きたか」を待っても答えは出ないので、「起きたときにどう動くか」を自分の側で決めておくほうが実務的です。

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →↓

①公式ステータスページ status.claude.com の読み方

コンポーネント単位で見る

status.claude.com はサービス全体をひとつのランプで表しているわけではありません。claude.ai・API・Claude Code・Cowork・Console がそれぞれ独立して状態を持っています。

ここを押さえておくと、「自分が使っている経路だけが落ちている」パターンに気づけます。実際、8月24日のログイン障害は claude.ai と Claude Code に限定されていました。API を直接叩いている処理は無事だったということです。

見るときの順番はこうです。

• 1. 自分が使っている経路のコンポーネントを最初に見る（Claude Codeユーザーなら Claude Code の行）
• 2. その日のインシデント一覧を見る。複数件ある日がある
• 3. インシデントの詳細を開いて、対象モデルと対象コンポーネントを確認する

通知を購読して「先に気づく」

ステータスページは見に行くものではなく、通知を受け取るものにしておくと運用が楽になります。status.claude.com はメール・Slack・Microsoft Teams・Webhook・RSS/Atom フィードでの購読に対応しています。

私の場合は、チームのチャットに障害通知が流れるようにしています。理由は単純で、「おかしいな」と思ってからページを開くまでの数分が一番無駄だからです。先に通知が来ていれば、その数分を切り分けではなく段取りの組み直しに使えます。

この「先に気づく仕組みを作る」という発想自体は、Claudeに限った話ではありません。Microsoft側の同じ考え方は別記事で整理しています。

Copilotの障害・稼働状況を確認する方法

②ステータスページに出ていないときの読み方

一番判断に困るのが「明らかに調子が悪いのに、ステータスページは全部緑」という状態です。ここには3つのパターンがあります。

パターン1：まだ掲示されていない

先ほど見たとおり、8月24日の障害でも実影響の開始から最初の掲示まで16分ありました。落ち始めの十数分はステータスページに何も出ません。「出ていない＝正常」ではなく「出ていない＝まだ分からない」と読みます。

この時間帯の判断材料になるのは、エラーコード（529なら受け側）と、他の利用者の報告です。各社の報道によれば、8月24日の障害でも Downdetector への報告のうち Claude Code に関するものが最も多く挙がっていました。

パターン2：全体障害ではなく部分的な劣化

全リクエストが失敗するわけではなく、「たまに失敗する」「極端に遅い」という劣化はステータスページに載らないことがあります。この場合、体感では「なんか今日は調子が悪い」としか分かりません。

判断のコツは失敗率を数えることです。10回試して1〜2回落ちるなら受け側の劣化を疑います。10回試して10回とも同じ場所で落ちるなら、それは自分側の問題です。「なんとなく重い」で止めず、回数で見るだけで精度が上がります。

パターン3：本当に自分側の問題

ステータスページも緑、他の人も困っていない、別経路では動く——この場合は自分側です。Claude Code固有のトラブル（インストール、認証、動作品質の劣化）はパターンが決まっているので、別記事に対処法をまとめています。

Claude CodeClaude Codeが動かない・雑になった時の対処法｜エラー別解決とthinking budget設定【2026年版】

③障害か自分側かを見分ける手順

切り分けは、次の4つを上から順に1回ずつ試すだけです。全部やっても3分かかりません。

• 別の経路で試す：Claude Code が落ちるなら claude.ai を開く。逆も同じ。両方落ちるならサービス側の可能性が高い
• 別のモデルで試す：特定モデルだけの障害は珍しくありません。ただし8月24日のように4モデル同時のケースもあるので、これだけで判断しない
• 別のネットワークで試す：社内ネットワークのプロキシやファイアウォールが原因のことがあります。スマートフォンのテザリングで1回試すのが早い
• エラーコードを読む：5xxなら受け側、4xxなら自分側。これが一番速い判定材料です

この4つで「サービス側だ」と判定できたら、そこで手を止めます。再インストールも設定変更もしません。障害中に環境を触るのは、火事のときに家具の配置を変えるようなものです。

落ちている間に業務を止めないための備え

ここからが本題です。確認手順を固定しても、落ちている事実は変わりません。大事なのは落ちる前にどう備えておくかです。私が実際にやっていることを3つお伝えします。

無人ジョブは「落ちても流し直せる」形にしておく

私は毎日決まった時刻に、無人でAIのジョブを走らせています。記事の執筆、情報収集、定型の集計といった処理です。人が見ていない時間帯にも動くので、サービス障害と正面衝突する確率が一番高いのがこの領域です。

実際、8月24日の障害は日本時間の13:50〜16:36。この時間帯にジョブが走っていれば、途中で確実に落ちます。

ここで私が採っている方針は、「途中から再開できるようにする」ではなく「いつ落ちても最初から流し直せるようにする」です。途中再開の仕組みは、状態の保存と復元を正確に作り込む必要があり、個人や小規模チームの運用では作り込みのコストに見合いません。それより、同じジョブを2回走らせても結果が壊れない形（冪等な形）にしておくほうが、はるかに堅くなります。

具体的には次のような設計です。

• 途中の成果物を本番に書き込まない。最後まで通ったものだけを反映する
• 「もう処理済みか」を毎回確認してから進む。二重投稿・二重登録が起きない形にする
• 失敗したジョブは黙って消えない。失敗した事実を必ず通知に残す

この考え方は障害対策としてだけでなく、長時間タスク全般に効きます。詳しくは別記事で書きました。

Claude CodeAIの長時間タスクは"落ちても流し直せる"設計にする

経路を2つ持っておく

8月24日の障害では、claude.ai も Claude Code も API も同時に影響を受けました。同じベンダーの中で経路を分けても、この規模の障害には効きません。

そのうえで現実的な備えは、次の2段構えです。

• 同一ベンダー内の切り替え：モデルを1つに固定しない。特定モデルだけの障害・劣化はこれで回避できます。ただし今回のような複数モデル同時のケースには効きません
• ベンダーをまたいだ切り替え：業務上「絶対に止められない処理」だけ、別のベンダーでも動く形にしておく。全部を二重化する必要はありません

ここで大事なのは「全部を二重化しない」という割り切りです。二重化にはコストがかかります。止まっても翌日に回せる仕事まで二重化すると、費用と保守の手間だけが増えていきます。私は「今日中に外部へ出す必要があるものだけ」に絞っています。

APIを使っているなら、529は「設計で受け止める」

API経由でClaudeを組み込んでいる場合、529はいつか必ず来るものとして扱います。来ない前提のコードは、障害の日にまとめて壊れます。

受け止め方の基本は次の3点です。

• 指数バックオフで待つ：失敗するたびに待ち時間を倍にしていきます（1秒 → 2秒 → 4秒 → 8秒）。等間隔でリトライすると、混雑している受け側にさらに負荷をかけることになり、復旧を遅らせます
• 待ち時間にばらつきを足す：複数の処理が同じ秒数で待つと、復旧の瞬間に全部が同時に殺到します。待ち時間に少しランダムな幅を持たせるだけで、これを避けられます
• リトライの上限を決める：無限にリトライすると、2時間46分の障害の間ずっと回り続けます。回数か総時間で必ず打ち切り、打ち切ったことを通知に残すのが大事です

ここで一番やってはいけないのが、失敗を黙って握りつぶすことです。エラーを無視して次へ進む作りにしていると、障害の日に「何も起きなかったように見えるが、実際には何も処理されていない」という最悪の状態になります。落ちたことは、必ず見える場所に残してください。

締切のある仕事ほど、時間を前に寄せる

これは仕組みではなく段取りの話ですが、効果はいちばん大きいかもしれません。

AIに任せる仕事のうち締切があるものは、締切の直前ではなく、余裕を持った時刻に走らせる。1〜3時間の障害はそれなりの頻度で起きるので、締切の3時間前に始めていれば、落ちても引き直せます。締切の30分前に始めていたら、その日は詰みます。

実際8月24日の障害は2時間46分でした。この長さを「起こりうる普通のこと」として段取りに織り込んでおくかどうかで、当日の被害がまったく変わります。

チームで使っている場合、最初にやるのは「共有」

ひとりで使っているときと、チームで使っているときでは、障害時の動き方が変わります。チームの場合、全員が同時に同じ切り分けを始めてしまうのが最大の無駄だからです。

「Claudeが変だ」と気づいた人が、社内のチャットに次の3つだけ書く。これを習慣にするだけで、被害はかなり減ります。

• 何が落ちているか（例：Claude Code からのリクエストが529で失敗する）
• 公式の掲示はどうなっているか（例：status.claude.com にインシデントが出ている／まだ出ていない）
• どうするか（例：AIを使う作業は一旦止めて、他の作業に回す）

3つめが特に重要です。「止まっています」だけを共有すると、各自が勝手に再インストールや設定変更を始めます。方針まで含めて共有して初めて、無駄な作業と余計な事故を止められます。

あわせて決めておきたいのが、「その日にAIなしで進められる仕事」をあらかじめ用意しておくことです。障害が起きてから代替作業を探すと、結局その日は何も進みません。AIを前提にした業務フローを組むなら、AIが止まった日の受け皿もセットで持っておく——これは仕組みではなく運用ルールの話ですが、実際に効きます。

復旧後にやること

復旧の掲示を見たら、すぐ元の作業に戻りたくなりますが、先に2つだけ確認します。

• 障害中に走ったジョブの結果を点検する：途中で落ちたものが中途半端な成果物を残していないか。特に外部へ投稿・送信する処理は必ず見ます
• 障害中に自分が触った設定を戻す：切り分けの過程で何か変更したなら、それを元に戻してから再開します。障害と無関係な不具合を後日引きずるのは、たいていこれが原因です

そのうえで、私は「今回どこで気づいたか」を1行だけ記録に残すようにしています。通知で気づけたのか、作業が止まってから気づいたのか。これを何回か記録すると、通知の設定を足すべき場所が具体的に見えてきます。

よくある質問

ステータスページが緑なのにエラーが出ます。どちらを信じればいいですか

エラーコードを優先してください。5xx（500・503・529）が返っているなら、掲示がなくても受け側の問題である可能性が高いです。8月24日の障害でも、最初の掲示が出るまでに16分かかっています。

障害中にモデルを切り替えれば動きますか

特定モデルだけの障害なら有効です。ただし8月24日は Mythos 5・Fable 5・Opus 5・Opus 4.8 の4つが同時に対象でした。切り替えは試す価値はあるが、当てにはできないという位置づけです。

Claude Code だけが落ちることはありますか

あります。8月24日のログイン障害は claude.ai と Claude Code が対象で、API は対象に含まれていませんでした。コンポーネント別に状態を見る意味はここにあります。

復旧の掲示を待ってから作業を再開すべきですか

待つ必要はありません。8月24日は実際にエラーが止まった時刻（07:36 UTC）と「解決」の掲示（08:30 UTC）に1時間近い差がありました。掲示より先に、軽いリクエストを1回だけ投げて確かめるほうが早いです。

まとめ

Claudeが落ちたと感じたときの動き方を、あらためて整理します。

• 確認は3ステップに固定する：公式ステータスページ → 公式アナウンスとエラーコード → 自分側の切り分け。この順番を崩さない
• ステータスページには時間差がある：8月24日の障害では、実影響の開始から最初の掲示まで16分、実際の収束から「解決」掲示まで約1時間の差があった
• エラーコードが最速の判定材料：5xx（529を含む）は受け側、4xxは自分側。529が出ているときに設定をいじらない
• その日のインシデントは1件とは限らない：8月24日はモデルのエラー障害に加えて、ログイン障害が別に2件記録されていた
• 備えは「流し直せる設計」「絞った二重化」「前倒しの段取り」の3点：全部を二重化しようとしないことがコツ

障害そのものは避けられません。避けられるのは、障害の日に自分の環境を壊してしまうことと、締切の直前にAIへ仕事を投げていたせいで打つ手がなくなることです。この2つは、確認手順と段取りを先に決めておくだけで防げます。

株式会社Fyveでは、こうしたAIの業務運用——止まったときにどう動くか、どこまで自動化してどこに人を残すか——の設計から実装・運用までを月額で伴走支援しています。すでにAIを業務に入れていて「落ちたときが怖い」という段階の方も、ぜひご相談ください。

専属AI活用顧問サービス

参考にした情報源

• Anthropic 公式ステータスページ「Elevated errors for multiple models」（incidents/vgz5psbjmt1h）2026年8月24日付インシデント（時刻・対象モデル・対象コンポーネント・解決掲示）
• Anthropic 公式ステータスページ「Errors logging into Claude.ai」（incidents/w43j3xmngxgj）「Issues logging into Claude.ai」（incidents/n0rlp126qf8g）2026年8月24日付インシデント（ログイン障害2件の時刻・対象）
• Cyber Security News「Anthropic's Claude AI Suffers Another Outage With Elevated Errors」2026年8月24日付（529 Overloaded・影響対象外のコンポーネント・原因非開示の確認）
• Notebookcheck「Claude faces another outage as errors hit multiple models」2026年8月24日付（二次情報として内容を照合）