Claude Codeが2時間47分止まった日。フリーランスが障害に備えてやるべきこと
2026年7月29日19:49〜22:36 UTC(日本時間30日朝)、Claude全体で529エラーが多発する障害が発生。年初から155件の障害が報告される中、Claude Code依存で仕事してるフリーランスがステータス監視・こまめなコミット・セッション設計で備える具体策を整理する。
エンジニアのゆとです。
7月30日の朝、寝起きでXを開いたら「Claude落ちてる」「529エラーで草」みたいなポストがタイムラインを埋めてた。慌ててステータスページを見に行ったら、案の定インシデントが記録されてた。日本時間の明け方に、世界中でClaudeがまとめて不安定になってたらしい。
自分はその時間帯たまたま寝てたから実害はなかったけど、正直ゾッとした。もしあれが平日の昼、納期前でClaude Codeにガッツリ作業を任せてる最中だったらと考えると、笑い事じゃない。この記事では、何が起きたかの事実整理と、フリーランスとして障害に備えるために実際にやってることを書く。
何が起きたか
ステータスページの記録を見る限り、時系列はこうだ。
- 19:49 UTC（日本時間30日 4:49）：調査開始。複数モデルでエラー率上昇を検知
- 20:33 UTC（同 5:33）：原因は「複数モデル全体でのエラー上昇」と特定
- 21:38 UTC（同 6:38）：大部分のモデルで改善を検出
- 22:36 UTC（同 7:36）：完全復旧
拘束時間としては2時間47分。エラーの中身は「Request Failed With 529 Overloaded」。サーバー側がリクエスト量をさばききれてないときに返す、いわゆる過負荷エラーだ。Downdetectorには2,000件を超える報告が集まって、そのうち約半分がClaude Code関連だったという報道もある。作業中にセッションが止まって、トークンだけ消費して成果が残らない、という一番きついパターンに巻き込まれた人が相当数いたはずだ。
これは「たまたま」じゃない。2026年の障害を数えてみた
今回の件を調べてて気になったのが「今年、何回目だ？」という点。ざっと拾えただけでもこれだけ出てくる。
- 6月2日：サブエージェント機能のバグに絡んだ、比較的深刻な障害
- 7月6日：複数モデルにまたがる障害、約2時間
- 7月22日：17:22 UTC発生、17:57 UTCに公式が認知
- 7月25日：21:36 UTC発生、約52分で復旧
- 7月29日：今回の2時間47分
さらに踏み込むと、2026年に入ってから報告された障害は155件にのぼるという集計もある。この数字がすべて「使い物にならないレベルの障害」というわけじゃなくて、軽微なものも含まれてると思う。それでも、Claude Codeを主力の開発環境にしてる身としては無視できない頻度だ。
これは「Anthropicのインフラが弱い」という話というより、「AIコーディングツールへの依存度が上がった分だけ、障害の影響範囲も広がってる」という構造の問題だと理解してる。急成長してるサービスにインフラの拡張が追いついてない状態が続いてる、というのが実態に近いんじゃないかと思う。
フリーランスにとって、なぜこれが特に痛いか
会社員なら「今日はAI使えないんで手が止まってます」で許される空気があるかもしれない。フリーランスだとそうはいかない。納期は納期だし、クライアントに「Claudeが落ちてたので」と言い訳しても、向こうからすれば知ったことじゃない。
自分がこの1年でClaude Codeに寄せてる作業の割合を考えると、障害が起きた瞬間に生産性が半分以下になる自覚がある。しかも厄介なのは、障害の発生タイミングを選べないこと。今回みたいに寝てる間ならまだいいけど、平日の日中、クライアントとの定例前の追い込みで起きたら普通にきつい。
実際にやってる備え
大げさな対策は必要ないと思ってる。障害自体はこちらでコントロールできないので、「起きた前提でどう被害を最小化するか」に絞って考えるのが現実的だ。自分がやってるのは次の4つ。
1. ステータスページを購読する
まずstatus.claude.comをメールかSlack連携で購読しておく。障害が起きたことにXのタイムライン経由で気づくのと、通知で先に気づくのとでは、対応の初動が変わる。特に「これはClaude側の問題で、自分の環境や書いたコードのせいじゃない」と即座に判断できるのが大きい。原因切り分けに時間を溶かさずに済む。
2. 作業単位を細かく切って、こまめにコミットする
障害でセッションが吹き飛んでも、直前までの作業がgitに残っていれば被害は最小限で済む。Claude Codeに大きなタスクを一気に投げっぱなしにするより、意味のある単位で区切ってコミットを挟む方が、障害耐性の面でも実は理にかなってる。セッションが途中で切れたときの引き継ぎ方は、以前
3. 並列で動かしてる作業はworktreeで分離しておく
複数タスクを同時に走らせてるとき、1つのセッションがフリーズや障害に巻き込まれても、他のworktreeで動いてる作業まで巻き添えにならない構成にしておくと安心感が違う。
4. 「今すぐClaude Codeが使えない」を想定したToDoを1個だけ持っておく
全部の作業をAI前提で組んでしまうと、障害中は完全に手が止まる。ドキュメント整理、テストケースの洗い出し、レビュー待ちのPRの確認など、「Claude Codeが要らない作業」を常に1つストックしておくと、障害中も手ぶらで待つ時間を減らせる。ツールを完全に乗り換える必要はないけど、逃げ道を1本持っておく発想として、
障害中にやらないほうがいいこと
これは自分が過去に痛い目を見た話でもあるけど、エラーが出た瞬間に何度もリトライを繰り返すのはあまり得策じゃない。529は「今は捌ききれてません」という信号なので、短い間隔で叩き続けても状況は変わらない。むしろクライアント側でリクエストが詰まって復旧が遅れる可能性すらある。ステータスページで「調査中」と出てる間は、素直に別の作業に切り替えるのが結果的に早い。
似たような「Claude Codeの調子がおかしい」系の症状でも、インフラ障害じゃなくてコンテキストの自己中毒が原因のケースもある。両者は対処法が全然違うので、症状の見分け方は
結局、依存をやめる話じゃない
念のため言っておくと、この記事は「AIコーディングツールに頼るのをやめよう」という話じゃない。生産性で得てるものの方が圧倒的に大きいのは自分自身が一番わかってる。ただ、便利なものほど止まったときの落差がでかい、というだけの話だ。
道具に依存すること自体は悪くない。依存してることを自覚して、止まったときの動き方だけ決めておく。それだけで、次にまた529が出たときの精神的なダメージはだいぶ軽くなると思う。
