要点

  • Haiku 4.5の major 障害は7月21日13:04:35から16:38:26 UTC まで続き、最初の監視移行後に再度「特定済み」へ戻った。
  • 複数モデルの critical 障害は実際の高エラー時間を15:28から16:26としたが、記録の閉鎖は18:18だった。
  • 17:40から18:03には文書作成や Claude の作業機能に別の critical 障害が起きた。
  • 22日08:34から09:00には Opus 4.1で API と Claude Code の minor 障害があった。
  • 共通原因、影響人数、エラー率、地域、補償は公表されていない。

Haiku 4.5の履歴で注目すべきは、停止時間そのものより状態の逆戻りだ。Anthropic は13:22に修正を適用して監視へ移ったが、14:44に再び問題を特定済みとした。最初の改善は持続しなかった。

この事実は、顧客側の復旧確認が必要であることを示す。一方、同日に開かれた他のインシデントを同じ原因だと断定する材料にはならない。

複数モデル障害には二つの時間がある

複数モデルの critical 記録は15:35に始まった。最終更新では、利用者が高いエラーを経験した時間を15:28から16:26と明記している。しかし、ページが解決済みになったのは18:18だ。

58分は後から特定された利用者影響の窓であり、約2時間44分は調査、修正、監視、閉鎖までの管理時間である。全時間を連続停止と呼べば過大になり、58分だけを見れば復旧確認の不確実性を落とす。

対象は claude.ai、API、Claude Code、Cowork だった。Haiku と時間が重なるものの、それだけでバックエンドの共通障害を証明できない。

作業環境はモデルとは別に止まる

17:40には、文書作成、Cowork Remote、Claude Code、Web 版 Claude Code、Claude Tag、Claude Design などに影響する critical 障害が始まった。17:51に監視、18:03に解決となった。

この短い記録は、推論と周辺ワークフローを分けて監視する必要を示す。モデルが応答しても、遠隔環境が開かない、文書が作れない、ツール実行が進まないなら業務は完了しない。

翌朝の Opus 4.1では、08:34に問題を特定し、08:45に監視へ移り、09:00に API と Claude Code の minor 障害を解決した。

四件をひとつの重症度に足せない

major 一件、critical 二件、minor 一件を合計して全体の深刻度とすることはできない。利用者数、失敗率、地域、データ損失、サービスクレジットがない以上、全顧客への損害も算定できない。

明確なのは運用上の負担だ。キューを止め、小規模な試行で復旧を確認し、別モデルや別事業者へ切り替えるか判断する必要がある。Haiku の逆戻りは、一度の成功ではなく安定観測期間を置く理由になる。

今後、Anthropic が共通依存関係を示す事後報告を出せば分析は更新できる。現時点の結論は、モデルと作業機能で障害が集中したが、公開情報は四つの時計をひとつの技術原因へ結んでいない、という範囲にとどまる。

出典