要約
- Anthropic は
q2kg8n613kr3を重大度「critical」とし、claude.ai、Claude API、Claude Code、Claude Cowork を当初「major outage」に変更した。 - 7月29日19:45から21:26 UTC まで全 Claude モデルでエラー率が上昇したと後に説明しており、症状の時間は101分だった。
- 公開記録は19:49:45に始まり、22:36:20の解決まで約171分続いた。101分は症状、171分は調査と確認を含むライフサイクルである。
- 21:38には大半のモデルが回復中だったが、リクエストと遅延はなお高かった。22:20の監視移行で四製品が通常運転に戻った。
- 原因、エラーコード、総リクエスト数、最終失敗率、顧客・地域別影響、緩和策、データ完全性、事後報告は公表されていない。
- 同時間帯の GitHub Copilot 障害は外部モデル提供者を名指ししておらず、Anthropic との因果関係を示す証拠にはならない。
四つの入口が同じ色に変わった
最初の更新で、claude.ai、直接 API、Claude Code、Cowork の四コンポーネントは「operational」から「major outage」へ同時に移った。20:33 UTC、Anthropic は複数モデルでエラー上昇を起こす問題を特定したと説明した。単一画面の不具合や一つの作業ツールだけの障害としては扱えない広さである。
21:38には大半のモデルで回復が見え始めたものの、リクエストとレイテンシーが高い状態は残った。四コンポーネントはそろって「partial outage」に下がる。22:20にすべてが通常運転へ戻り、監視段階に入った。16分後に解決が宣言された。
この同期は、顧客がどの入口を選んでも共通の運用領域に触れていた可能性を示す。しかし、共有のモデル提供基盤、ルーティング、依存サービス、リリース、あるいはステータスページ上の分類方法のどれが原因かは分からない。状態の同期はアーキテクチャ図ではない。
モデル障害と周辺システム障害は同義ではない
タイトルは「全モデル」としたが、モデルの重みや生成内容に欠陥があったとは書いていない。リクエストは推論に届く前に失敗することも、ストリーミングの途中で切れることもある。Claude Code や Cowork では、セッション、ツール実行、遠隔環境などモデル呼び出し以外の層が増える。
したがって、公開事実は「全モデルにまたがる高いエラー率」と「四製品面の状態変化」である。出力破損、データ喪失、情報流出、安全制御の不全を加える根拠はない。反対に、それらがなかったとも断定できない。Anthropic はデータ完全性やセキュリティについて結論を記していない。
顧客側の切り分けには、モデル、製品面、リクエスト形式、ツール利用、ストリーミングの有無を分けた計測が必要になる。短い API 呼び出しの成功だけで、長い Claude Code セッションの回復を証明することはできない。
「critical」と「全モデル」には分母がない
重大度の「critical」は緊急対応を促す分類であり、失敗率や顧客数ではない。「全モデル」もカタログ上の広さを示すが、各モデルの全リクエストが失敗したという意味ではない。Anthropic 自身も「高いエラー率」「大半のモデルが回復」「全モデルで成功率が回復」という段階的な表現を使った。
公開されていない数字は多い。総リクエスト数、初回失敗数、再試行後の最終失敗数、ピークと平均の率、影響を受けた組織と地域、API と各アプリの配分がない。このため、契約上の可用性、業務停止量、経済損失を外部から計算できない。
広い事故が必ず深い事故とは限らない。逆に、割合が小さくても高価値の自動処理に集中すれば事業影響は大きくなる。ステータス分類だけでは、この二つを区別できない。
二つの時計を混ぜると復旧を誤読する
公開ページは19:49:45 UTC に開かれた。後の監視更新は、実際に観測したエラー上昇を19:45から21:26までとした。これは101分で、ページ作成より約5分早く始まる。
一方、解決は22:36:20である。公開ライフサイクルは約171分となり、調査、特定、部分回復、監視、確認を含む。171分すべてを高エラー時間と数えると、最終更新の境界と矛盾する。
101分だけを書くのも不十分だ。21:26以降も Anthropic は直ちに解決とはせず、22:20までコンポーネントを部分障害に置いた。その後も16分間監視した。顧客の再開判断にとって、症状が終わった時刻と安定を確認した時刻は別々の情報である。
再試行は利用者の見え方と供給者の件数をずらす
Anthropic の通常の API 文書は、500を内部エラー、529を一時的な過負荷として説明する。公式 SDK は接続エラー、レート制限、5xx など一時障害を標準で2回、指数バックオフ付きで再試行する。本件の記録は HTTP コードを示さず、過負荷とも述べていないため、これを原因説明には使えない。
それでも再試行の仕様は、必要な分母を明らかにする。一つの業務操作が初回に失敗し、再試行で成功すれば、利用者には遅延として見える。供給者には複数のリクエストとして見え、アプリには成功一件と記録されるかもしれない。逆に同時再試行が増えれば、元の業務需要より試行量が大きくなる。
21:38の「リクエストと遅延が高い」という説明だけでは、どの現象か選べない。業務操作数、総試行数、再試行数、最終失敗数を分離し、文書化された request ID を保存して初めて、個別の失敗を事故と照合できる。
緑色の後に実作業で回復を証明する
提供者が通常運転へ戻っても、滞留ジョブを一斉に解放する必要はない。利用中のモデル、コンテキスト長、ストリーミング、ツール構成を再現した少数の合成テストを行い、段階的にトラフィックを戻す。最終エラー率、遅延、キューの古さ、業務完了率を監視する。
冪等性も復旧条件になる。応答だけが失われ、外部操作が実行済みなら、無制限の再試行は二重処理を生む。代替モデルや別の提供者へ振り替える場合も、品質、価格、コンテキスト、ツール、安全特性、データ経路が変わる。どの仕事を迂回させ、どれを待たせるかを平時に決めておく必要がある。
四つの入口が同時に影響された事故では、単一の「Claude 正常」フラグは粗すぎる。顧客の実際の仕事が完了したかどうかが、最終的な回復判定になる。
GitHub との時間一致は提供者名にならない
GitHub は20:07 UTC に Copilot の AI モデル提供者に関する別のインシデントを開いた。特定または外部のモデル提供者へのリクエストでエラーが増え、一部利用者が失敗や性能低下を経験し得ると説明した。21:51には外部提供者の問題が解決し、Copilot トラフィックが回復したとした。
時間は Anthropic の101分窓と重なる。しかし GitHub は提供者名、モデル一覧、技術原因を公表していない。一つの製品が複数提供者を利用することも、同時刻に独立した障害が起きることもある。時間相関だけで Anthropic を GitHub の未記名提供者と断定してはならない。
この比較から言えるのは、モデル依存が下流サービスの障害として現れ得るということだけだ。因果を結ぶには、提供者名または双方を接続する技術証拠が必要である。
次の報告には率、層、是正措置が要る
現在の記録は、重大度、全モデル範囲、四製品面、段階的回復、二つの時間軸を提供した。次の事後報告では、ピークと平均の最終エラー率、初回と再試行後の差、影響地域と組織、製品面ごとの症状が必要になる。
さらに、失敗した層、緩和や切り戻しの内容、再発を減らす制御を説明すべきだ。データ完全性、安全性、セキュリティについても明示的な結論が必要で、沈黙を無害の証明として扱うことはできない。
本件は誇張しなくても重大である。全モデルと四つの入口にまたがるエラーが101分観測され、公開対応は解決まで約171分続いた。どこで現れ、いつ緑に戻ったかは分かる。何件の業務が最終的に失敗し、なぜ起きたかは分からない。その分母の欠如こそ、AI 基盤の信頼性を評価する際の中心的な問題である。