要点
- Opus 4.8と Haiku 4.5の事象は13:37:28Z から15:23:37Z まで続いた。
- Haiku 4.5は Opus 4.8より先に回復し、第一事象の終了よりも早く正常化した。
- Sonnet 5の独立した事象は15:24:05Z に始まり、わずか28秒後で、16:12:32Z に終了した。
- 両記録は claude.ai、Console、API、Claude Code、Cowork を影響対象として挙げた。
- Anthropic は共通原因、影響利用者数、エラー率、データ消失、サービスクレジットを公表していない。
運用担当者にとって重要なのは、ステータスが「解決済み」に変わった瞬間ではなく、保留していた仕事をいつ安全に戻せるかである。第一事象の終了から第二事象の開始まで28秒しかなければ、合成リクエストを何回か流し、待ち行列を段階的に開く時間すら十分ではない。顧客の体験は、ほぼ連続した不確実性になり得る。
それでも事故分析は、体験の連続性と事象の同一性を分けなければならない。Anthropic は二つの ID、異なるモデル範囲、別々の開始・終了時刻を記録した。近い時刻と共通の製品名だけから、一つの欠陥が三モデルを順番に襲ったと結論づけることはできない。
第一事象はモデルごとに違う回復を示した
Opus/Haiku 事象は13:37:28Z に minor として開始された。Anthropic は問題を特定した後、Haiku 4.5は回復した一方、Opus 4.8では高いエラーが続いていると更新した。15:06:53Z に監視段階へ移り、15:23:37Z に解決済みとなった。
この順序は、単一の「Claude 稼働」フラグより情報量が多い。モデルを選べるクライアントなら、Haiku に小さな試験トラフィックを送り、適合する仕事だけを先に戻せる。Opus が必要なタスクは、別経路へ送るか、待機を続ける必要がある。全モデルを同じヘルス領域にまとめると、部分復旧の機会と残存リスクの両方が見えなくなる。
対象として列挙されたのは claude.ai、Console、API、Claude Code、Cowork である。広い一覧は、各画面の全リクエストが失敗したという意味ではない。minor という分類も利用者数を表さない。公開記録にはエラー率、地域、失敗したジョブ数、キューの長さがないため、影響規模を逆算できない。
解決後の確認時間を第二事象が奪った
Sonnet 5の記録は15:24:05Z に始まり、15:36:57Z に原因特定段階、16:12:32Z に解決となった。影響分類は同じく minor で、五つの接点も同じだった。構造化 API のミリ秒時刻から、第一事象との間が28秒であることを確認できる。
この精密な時間境界は、因果関係を精密にするものではない。Opus の修復が Sonnet のエラーを起こした、あるいは問題がモデル間を移動したとは書かれていない。共通原因も示されていない。二記録を一つにまとめれば、モデルの違いを消し、供給元が述べていない診断を追加することになる。
適切な表現は限定的である。複数の Claude モデルに依存する顧客は、信頼を再構築する時間がほぼないまま、隣接したエラー記録に直面した。その事実だけでも復旧設計を見直すには十分であり、架空の単一原因は必要ない。
キューを開く前に独立した観測が要る
本番利用者は、ページ遷移より厳しい復旧条件を置ける。実際に使うモデル、インターフェース、地域へ連続した合成リクエストを送り、成功が一定期間続いてから少量ずつトラフィックを戻す。再試行には上限を設け、冪等キーを維持し、意味上の置き換えが可能な仕事には別モデルまたは別供給元を準備する。
ヘルス状態のキーは、少なくともモデルと接点を含むべきだ。さらに、ツール呼び出し、長いコンテキスト、対話、バッチでは回復確認の方法が異なる。短い API 要求が成功しても、Claude Code の長時間処理や Cowork のタスクが正常とは限らない。
Haiku が先に回復し、Opus の事象が閉じ、直後に Sonnet の事象が開いた。こうした変化は、供給元の緑表示が復旧判断の一入力にすぎないことを示す。顧客側のエラー率、遅延、キュー年齢、完了率が、実務の復旧を決める。
同じ五つの接点は同じ原因を証明しない
共通する製品一覧は、モデル固有の問題が同じ利用経路を通じて見えることを示す可能性がある。しかし、裏側が一つの故障だったとは示さない。状態ページの分類方法や共通の配信面が一覧の重複を生んだ可能性もあり、公開情報だけでは選べない。
今回の二事象は、BTW が以前の締切で扱った四記録より後に発生した。新しい再発シグナルではあるが、以前の事象まで一つの長期障害へ合成する根拠ではない。再発は冗長化を強める理由になる一方、根因の断定にはならない。
公表されていない数字が結論の上限になる
Anthropic は共通原因、影響利用者数、要求失敗率、地域差、データ消失、SLA クレジットを公表していない。このため、契約上の可用性や容量不足を計算できず、全体の事業損失も推定できない。
測れるのは、第一記録が約一時間46分、間が28秒、第二記録が約48分という運用上の並びである。ステータスページは供給元が採用した事象の単位を伝える。実際の仕事を再開できる時刻は、顧客自身のプローブ、ルーティング、キュー制御が決めなければならない。