2026年10月25日、AnthropicのClaudeステータスページに2件のエラー事象が記録された。1件目の影響時間は協定世界時06:05から06:35（北京時間14:05から14:35）、2件目は協定世界時08:08から08:29（北京時間16:08から16:29）で、いずれも同日中に解決済みとされた。
10月25日午前に何が起きたか
1件目の影響範囲が最も広かった。ステータスページは協定世界時06:14に調査中の記録を出し、Claude Mythos 5.1、Claude Fable 5.1、Claude Opus 5.5、Claude Sonnet 5.5、Claude Haiku 5.5へのリクエストでエラー率が上昇しているとした。その後の更新ではSonnet 5.5の原因を特定し、修正を展開して回復の監視に入ったとされた。影響を受けたのはclaude.ai、Claude API、Claude Code、Claude Coworkの4サービスで、いずれも部分障害と表示された。Claude ConsoleとClaude for Governmentは正常を維持した。
2件目は範囲が狭く、Claude Fable 5.1のリクエストエラーに集中し、記録された影響時間は約21分で、同日中に解決した。10月25日のステータス更新に、2件の具体的な原因の説明はなかった。
影響はチャット画面だけではない
注目すべきは、影響を受けた入口の顔ぶれである。claude.aiだけでなく、Claude API、Claude Code、Claude Coworkが同時に不調になれば、コーディング、自動化フロー、カスタマーサポートや文書処理といった下流の製品も止まる。一般ユーザーにとっては1回の失敗に見えても、Claudeを本番フローに組み込んだチームにとっては、1回の失敗が大量のタスク中断につながり、しかも画面に分かりやすいエラーメッセージが出るとは限らない。
これが孤立した1日でもない。ステータス記録によると、10月24日にも解決済みのエラー事象が複数あった。1件ごとの時間は短くても、連続すれば、次に送るリクエストがまた障害の時間帯に当たるのか、ユーザーは判断できない。
短い障害がなぜ重要か
モデルを評価するとき、人はまずベンチマークの点数や機能一覧を見がちで、信頼性は後回しになりやすい。10月25日の出来事は、モデルがワークフローの一部になった時点で、可用性そのものが製品能力だと示した。ステータスページに表示された90日間の稼働率は99.6%前後で、それでも短時間の利用不能は残る。たまにチャットを使う人には数分の不便だが、時間単位で納品するチームには、緊急時計画に書き込むべき変数になる。
報告の透明性も同じくらい重要である。Anthropicのステータスページは調査、特定、修正、監視、解決までの時間軸をすべて示したため、ユーザーは問題が自分のアカウントやネットワーク、プロンプトではなく、提供者側にあると判断できた。透明性が障害を消したわけではないが、ユーザー自身の切り分け時間は短くなった。
ユーザーとチームは今どうすればよいか
一般ユーザーが同じようなエラーに遭ったら、切り分けの前にステータスページを確認するとよい。複数サービスが同時に部分障害と表示されていれば、提供者側の問題である可能性が高く、アカウントやネットワークを変えたり、同じ長いプロンプトを繰り返し送ったりしても解決しない。回復を待ってから再試行する方が手間が少ない。
Claudeを本番フローで使うチームは、今回を訓練と捉えるべきである。失敗したリクエストは間隔を空けて自動再試行し、重要なタスクには代替モデルやキューを用意し、失敗を黙って捨てるのではなく、最終ユーザーに明確に伝えるとよい。次にステータスページにエラーが出たら、自分のコードを調べる前に、提供者側の広範な問題かどうかを確認する。
短い障害自体はモデルが悪くなった証拠ではない。次に見るべきは2点である。同じような事象が連続して起きるかどうか、そしてAnthropicが後日原因を説明するかどうかだ。1回の速い回復は安心材料だが、繰り返しこそが信号になる。
