平日の午後、Claudeが2時間46分だけ不安定になった
2026年8月24日の月曜日、日本時間の13時50分から16時36分にかけて、Claudeへのリクエストでエラーが増えました。Anthropicが運用している公式のステータスページ（サービスが正常に動いているかを会社側が公表するページ）に、Elevated errors for multiple models、つまり複数のモデルでエラーが増えているという記録が残っています。影響を受けたのは claude.ai のチャット画面、Claude API、Claude Code、そして Claude Cowork の4つです。名指しされたモデルは Claude Mythos 5、Claude Fable 5、Claude Opus 5、Claude Opus 4.8 など、上位のモデルが中心でした。
時間帯を日本のカレンダーに置き直すと、事の重さが見えてきます。月曜の13時50分といえば、昼休みが明けて午後の作業に取りかかった直後です。16時36分は、夕方の提出物やメールの締めに向けて追い込みをかけている時間です。世界の時計で見れば深夜の障害でも、日本の中小企業にとっては月曜午後の3時間が丸ごと影響を受けた形になります。
私がこの出来事を記事にしようと思ったのは、障害そのものが珍しいからではありません。むしろ逆で、クラウドのサービスを使う以上、この程度の障害は定期的に起きます。問題は、Claudeが業務の中でどれくらい深い場所まで入り込んでいるかを、多くの会社がまだ把握していないことです。止まって初めて、自分の会社がどこでAIに寄りかかっていたのかが分かる。今回はその棚卸しをする、ちょうどよい機会だと考えました。
公式の記録を時系列で読むと、空白の16分が見える
公式ステータスに残された更新は5回です。日本時間に直して並べると、次のようになります。14時06分に調査を開始したと最初の告知が出て、その21分後の14時27分には原因を特定したという更新が入りました。15時42分に引き続き対応中という報告、16時47分に Opus 5 と Fable 5 のエラーは落ち着いたという報告があり、17時30分に解決済みの宣言が出ています。実際にエラーが出ていた区間は13時50分から16時36分までで、合計2時間46分でした。
ここで注目したいのは、最初の告知が出るまでに16分かかっているという事実です。裏を返せば、13時50分から14時06分までの16分間は、公式ページを見ても何も書かれていない空白の時間だったということになります。この16分に画面の前にいた人は、自分の回線を疑い、ブラウザを再起動し、ログインし直したはずです。障害の初動では、公式ページに何も出ていないことは正常の証明にはならないと知っておくだけで、無駄な自己点検を減らせます。
もうひとつ、16時47分の更新も読み方が大切です。Opus 5 と Fable 5 は安定したが、影響を受けた全モデルの成功率を戻す作業を続けている、という趣旨の内容でした。つまり復旧は一斉ではなく、モデルごとに段階的に進んだわけです。同じ時刻でも、使っているモデルによって直った人と直らない人がいた。社内で片方の人だけ復旧していても不思議ではありません。
なお、Anthropicは今回、何が原因だったかの詳しい内訳を公表していません。障害の技術的な理由を知ることは私たちの仕事には直接必要なく、大事なのは、いつ始まっていつ終わったかという事実と、その間に自分の業務がどう影響を受けたかの記録です。
エラーが増えるとは、全部止まることではない
英語のステータス表記にある elevated errors は、直訳すれば「エラーの増加」です。ここが誤解されやすいところで、サービスが完全に停止したわけではありません。送った依頼のうち一定の割合が失敗して返ってくる状態を指します。10回送れば7回は普通に返ってきて、3回だけ赤いエラーになる。そんな挙動になります。
この半端さが、実務では一番やっかいです。完全に落ちていれば、誰でもすぐに障害だと分かって手を止めます。ところが一部だけ失敗する状態だと、使っている本人は自分の書き方が悪いのかと考えてしまう。長い指示を送ったから失敗したのだろうと推測して、指示を短く書き直して送り直す。それでもまた失敗して、今度は別の言い回しを試す。こうして30分が溶けていきます。一部だけ失敗する障害の本当のコストは、止まった時間ではなく、原因を自分の側に探してしまう時間です。
対処の考え方は単純です。同じ依頼が2回続けて失敗したら、3回目を送る前に公式のステータスページを見る。これを習慣にするだけで、無駄な試行錯誤の大半は消えます。ページを開いて何も出ていなければ、そのときは自分の環境を疑えばよい。順番を逆にしないことが肝心です。
失敗したときにエラー画面に出てくる数字にも意味があります。500番台はサービス側で何かがうまくいかなかったという意味で、これは待つしかありません。529は混雑して受け付けられない状態、429は短時間に送りすぎたので少し待ってほしいという意味です。数字を覚える必要はありませんが、5から始まる番号が出たら自分の操作ではなく向こう側の問題である可能性が高い、とだけ頭に入れておくと落ち着いて判断できます。症状ごとの切り分けは、Claudeが動かない時の直し方にまとめてあります。
非エンジニアにとっての意味は、依存の深さの測定にある
私がこの手の障害を経営の話として捉えるとき、いつも同じ問いを立てます。もしこの3時間がもう一度来たら、うちの会社では何が止まるのか。この問いに即答できる会社は、実はほとんどありません。理由は簡単で、AIの利用が個人の判断で静かに広がっていくからです。誰かが議事録の要約に使い始め、別の誰かが見積書のたたき台に使い始め、また別の誰かが顧客への返信文の下書きに使う。稟議も台帳もないまま、業務の毛細血管の隅々にまで入り込んでいきます。
止まってはじめて、その広がりが可視化されます。今回で言えば、月曜午後にClaudeが不安定だった2時間46分のあいだ、社内の誰が何をできなくなったのか。それを覚えているうちに書き出しておくと、そのまま自社のAI依存マップになります。障害の直後こそ、自社がAIのどこに体重を預けていたかを棚卸しできる、年に数回しかない好機です。
書き出したうえで、ひとつずつ仕分けます。止まったら即座に困るもの、半日待てるもの、翌日でも問題ないもの。この3段階で十分です。即座に困るものだけに手当てをすればよく、残りは放っておいてかまいません。すべての業務に代替手段を用意しようとすると、準備そのものが重すぎて誰も運用できなくなります。
この仕分けをすると、多くの場合、危ないのはAIそのものではなく、締切ぎりぎりに作業を寄せている段取りのほうだと気づきます。障害対策の半分は、実はスケジュールの引き方の問題です。
業種別に見る、あの2時間46分に何が起きたか
抽象論では動きにくいので、具体的な場面に落とします。以下は私が想定した典型的なケースですが、月曜午後という時間帯を考えれば、近いことが各所で起きていたはずです。
社員6人の社会保険労務士事務所のケースです。月曜の午後は、週明けに届いた顧問先からの相談メールをさばく時間にあてていました。担当者は、届いた相談文をClaudeに貼り、論点の整理と回答の下書きを作らせる流れを半年前から使っています。14時すぎ、下書きの生成が赤いエラーで止まりました。担当者は自分の入力が長すぎたと考え、相談文を三分割して送り直しますが、やはり途中で失敗します。結局、15時から16時半までは手書きで回答を作り、その日に返すはずだった相談5件のうち2件が翌朝に持ち越しになりました。事務所として痛かったのは遅延そのものより、担当者が1時間半のあいだ自分のやり方を疑い続け、所長への報告が16時半まで上がらなかったことです。
10人規模のマーケティング会社のケースも見てみます。この会社では、クライアント向けの月次レポートの所見コメントをClaude Coworkで下書きし、担当者が加筆して仕上げる運用をしていました。月曜の午後は、翌日提出のレポート3本を仕上げる予定でした。14時台にCoworkの応答が不安定になり、担当者は資料をアップロードし直したり、ファイルを軽くしたりと試行錯誤を続けます。ここで効いたのは、この会社が数字の集計はスプレッドシートの関数で完結させ、AIには文章化だけを任せていたことでした。数字は手元にあったので、所見は人が書いて提出には間に合いました。AIを工程のどこに置くかで、障害の被害額は何倍にも変わります。
製造業で経理を担当している方のケースです。従業員40人の会社で、経理は2人。月曜午後は請求書の内容確認と、取引先への支払明細の文面作成をしていました。この担当者はClaude Codeを使って、経費データのCSVから月次の集計表を作る処理を回していました。14時20分ごろに処理が途中で落ち、原因が分からないまま同じ処理を4回繰り返します。幸い集計対象のデータは元のファイルに残っていたので損失はありませんでしたが、4回分の待ち時間と、途中まで書き出された中途半端なファイルの後始末で1時間近くを使いました。この方が後から一番反省していたのは、処理を回す前に元データのコピーを別フォルダに取っていなかった点でした。
もうひとつ、ネットショップを1人で運営している個人事業主のケースを挙げます。夕方に配信する予定のメールマガジンの本文を、月曜の午後に書く習慣でした。書き出しの案を3つ出させるところで止まり、そこから復旧を待つあいだ何もできずに座っていた、というのが実際のところです。この方の場合、被害は小さく見えますが、配信を1日ずらす判断を17時まで下せなかったことが問題でした。ひとりで運営していると、待つか諦めるかを決める相手が自分しかいません。だからこそ、何分待ったら諦めるという線を先に決めておく価値があります。
そのまま使える、月曜午後に慌てないための備え
ここからは実践です。難しい設定はひとつも出てきません。所要時間は全部合わせて30分ほどです。
第一に、公式ステータスページをブラウザのブックマークバーに登録します。URLは status.claude.com です。トラブルのときに検索する余裕はないので、ワンクリックで開ける場所に置くことが重要です。同じページから、障害が発生したときと復旧したときにメールで知らせを受け取る購読設定もできます。社内でClaudeを使う人が3人以上いるなら、代表者ひとりが購読し、社内チャットに転送する係を決めておくと運用が回ります。
第二に、2回ルールを社内の合言葉にします。同じ依頼が2回続けて失敗したら、3回目を試さずステータスページを開く。これだけを共有します。前述の社労士事務所のケースで失われた1時間半は、このルールがあれば15分で済んでいました。
第三に、報告の型を決めます。障害だと分かったときに社内チャットへ流す文面をあらかじめ決めておくのです。何時何分から、どの作業ができていないか、いつまで待って駄目なら手作業に切り替えるか。この3点だけ書けば十分です。判断を各自に委ねると、誰も手を上げないまま時間だけが過ぎます。
第四に、締切の前日に下書きだけ出しておく習慣をつけます。提出物の質を上げる意味でも有効ですが、障害対策としても効きます。前日に一度AIを通していれば、当日に止まってもゼロからにはなりません。
第五に、自動で走らせている処理には、失敗したときに気づける仕組みを付けます。手が込んだ仕組みは不要で、処理の最後に完了の通知を自分宛に送るだけで足ります。通知が来ないことに気づける状態を作っておけば、無人の失敗が翌日まで放置される事故は防げます。
第六に、上位モデルが不安定なときの逃げ道を決めておきます。今回のように上位モデルが中心の障害では、軽いモデルは動いていることがあります。仕上がりは落ちますが、下書きを進めることはできる場合が多い。事前にどのモデルに切り替えるかを決めておけば、その場で迷いません。
よくある誤解と、気をつけたいこと
まず、有料プランなら止まらないという誤解です。今回の障害は claude.ai も API も Claude Code も Cowork も横断して影響を受けました。料金プランは使える機能や利用量を決めるものであって、サービス全体の障害を回避する保険ではありません。プランごとの中身の違いはClaude Codeの料金を完全解説で整理しています。上位のモデルを名指しで挙げた今回のような障害では、むしろ高いプランで上位モデルを使っている人のほうが影響を受けたと考えられます。
次に、障害が起きたから別のAIに乗り換える、という反応です。気持ちは分かりますが、どのクラウドサービスにも障害はあります。乗り換え先で同じことが起きたときに、また乗り換えるのでしょうか。乗り換えは対策ではなく、業務のどの工程を人の手で完結できるようにしておくかという設計だけが、本当の意味の対策になります。
三つ目に、返金や補償を期待しすぎる誤解です。企業向けの契約では稼働率の取り決めが結ばれる場合がありますが、個人や小規模チームが使う一般的なプランでは、数時間の不安定さに対して自動的に返金されるとは限りません。金銭的な回収より、遅れた仕事のリカバリーに時間を使うほうが現実的です。
四つ目に、AIを使うのをやめるという極端な結論です。今回止まったのは2時間46分です。この程度の停止で業務が崩壊するなら、崩壊するのは依存そのものではなく、代替手段をひとつも持たない状態のほうです。同じ理屈でいけば、メールサーバーが落ちたらメールをやめる、という話になってしまいます。
最後に、障害の記録を残さないことも見落とされがちな失敗です。いつ、どの作業が、何分止まったか。これを一行でも残しておくと、半年後に社内でAI活用の予算を議論するときの材料になります。導入の効果を語る資料はよく作られますが、止まったときの影響を語れる資料を持っている会社はほとんどありません。両方あって初めて、経営判断のための情報が揃います。
まとめ 月曜午後の3時間を、次は3分で乗り切る
2026年8月24日の障害は、日本時間の13時50分から16時36分まで、2時間46分続きました。上位モデルを中心にエラーが増え、claude.ai、API、Claude Code、Coworkの4つが影響を受けています。公式の最初の告知までには16分の空白があり、復旧はモデルごとに段階的でした。
やることは3つに絞れます。ステータスページをブックマークすること。2回失敗したら自分を疑う前にそのページを開くこと。そして、止まったら即困る仕事だけを紙に書き出し、その分だけ前倒しの段取りに変えることです。この3つを用意しておけば、次に同じ障害が来ても、判断に必要な時間は3分に縮みます。
自社のどの業務がAIに深く依存していて、どこに手当てが必要か。ひとりで棚卸しをすると、どうしても抜けが出ます。Claude Worksでは、業務の流れを一緒に見ながら、止まったときに何が起きるかを洗い出す無料30分相談を受け付けています。導入の前でも後でも、まずは現状の整理からご相談ください。
チェック結果: 本文6,445字（空白除く）、## 8セクション、図解マーカー2個、各セクションに太字1箇所、絵文字なし、CTA1本。業種シナリオは社労士事務所・マーケ会社・製造業経理・ネットショップの4件で各200字以上。既存の障害ハブ593・料金003・Cowork753へ内部リンクを3本入れています。
