【実測】Claudeの障害は28日で50回｜公式記録を全部数えて分かった、止まりやすい時間帯と「自分のせい」の見分け方

Claudeが急に遅くなったり、応答が返らなくなったりしたとき、最初に疑うのは自分の設定ではないでしょうか。私もずっとそうでした。ところが公式の障害記録を28日分すべて数えてみたら、その期間だけで50件の障害が記録されていました。この記事では、集計して分かった実際の数字と、止まりやすい時間帯、そして「自分のせいか、向こうのせいか」を30秒で切り分ける方法をまとめます。

きっかけは「私の設定が悪いのでしょうか」という質問だった

2026年8月5日の夕方、Claudeで大きな障害が起きました。私はその日の15時すぎに記事を1本公開したばかりで、告知の投稿をした直後に応答が返らなくなりました。

最初に思ったのは「さっきまで動いていたのに、何か触ったかな」でした。設定ファイルを見返して、権限まわりを疑って、ひととおり自分を疑ってから、ようやく公式のステータスページを開きました。そこには障害の告知が出ていました。自分は何も悪くなかったのです。

その後、Xで障害の情報を投稿したところ、無料版を使っている方から質問が届きました。急いで書類を作っている最中で、障害を受けていないClaudeはあるのか、という内容でした。困っているのは自分だけではなかったわけです。

さらに分かりやすい反応がありました。私が普段書いている記事の告知投稿は、だいたい100回から400回ほど表示されます。ところがこの日の障害情報の投稿は、1本目が4,312回、2本目が6,142回表示されました。10倍以上です。それだけ多くの人が「Claudeが動かない」と検索して、答えを探していたということになります。

そこで気になりました。この障害は特別な事故だったのか、それとも普段からそれなりの頻度で起きていて、私たちが気づいていないだけなのか。感覚で語っても仕方がないので、公式の記録を数えることにしました。

公式の障害記録を28日分、1件残らず数えた

Claudeには公式のステータスページがあります。status.claude.com がそれで、過去の障害が発生時刻・復旧時刻・影響を受けたサービス・深刻度つきで残っています。会員登録もログインも不要で、誰でも見られます。

このページは人が読む用の画面ですが、同じ内容が機械で読める形式でも公開されています。今回はそちらを使って、直近に記録されていた50件をすべて取得しました。対象になった期間は2026年7月9日から8月5日までの28日間です。

集計するときに、ひとつだけ注意した点があります。障害は同時に複数走ることがあるので、それぞれの継続時間を単純に足すと二重に数えてしまいます。実際、単純合計だと128時間になりました。これは明らかに実態より大きい数字です。そこで、重なっている時間帯をひとつにまとめて、実際に「何かが起きていた時間」がどれくらいだったかを計算し直しました。

また、Officeアドインの提供状況のように、モデルそのものとは関係のない周辺機能の記録が1件混ざっていました。これは45時間という長さで全体を大きく歪めるため、本体サービスの集計からは外しています。数字を大きく見せたいなら残しておいたほうが派手ですが、それでは実態を伝えられません。

結果は50件、実質71時間、28日のうち19日は何かが起きていた

集計した結果がこちらです。

・記録された障害は28日間で50件

・本体サービスに関わるものだけで49件

・重なりを除いた実質の障害時間は71.1時間

・これは期間全体の10.7%にあたる

・何らかの障害が記録された日は19日（28日中）

いちばん驚いたのは最後の行です。28日のうち19日、つまり3日のうち2日は、公式が何らかの異常を認識していたことになります。私は毎日Claudeを使っていますが、そのうち気づいていたのは数えるほどでした。

深刻度の内訳も見ておきます。公式は障害に4段階のラベルを付けていて、内訳は次のとおりでした。

・critical（重大）が3件

・major（大）が12件

・minor（小）が32件

・none（影響なしの記録）が3件

3分の2はminorです。つまり「全員がまったく使えなくなる」種類の障害はむしろ少数で、多くは一部のリクエストでエラー率が上がる、応答が遅くなるといった形で現れます。だからこそ気づきにくく、自分の設定を疑ってしまうわけです。

重大に分類された3件は、7月22日の0時35分から164分、同じ日の2時40分から23分、7月30日の4時49分から167分でした。いずれも日本時間の深夜から早朝にかけてで、寝ている間に始まって寝ている間に終わっています。

止まりやすいのは日本時間の22時台と夕方

次に、障害が始まった時刻を日本時間に直して分布を見ました。はっきりした偏りが出ました。

いちばん多いのは22時台で7件です。続いて3時台と23時台が5件、16時台と17時台が4件ずつでした。逆に、日本の午前9時から14時までの時間帯はほとんど記録がありません。朝から昼にかけて始まった障害は、28日間で2件だけでした。

理由を考えると自然な結果です。日本時間の22時は、アメリカ西海岸の朝6時から7時にあたります。夕方16時台から18時台は、向こうの深夜から早朝です。開発や運用の作業が動く時間帯と、利用者が一気に増える時間帯が、日本の夜に重なっているわけです。

ここから実用的な結論がひとつ出ます。締め切りが決まっている重い作業を、日本時間の夜に持ってこないことです。私はこれまで、静かで集中できるからという理由で夜に大きな処理を回していました。データを見たあとは、時間のかかる作業を朝に寄せるようにしています。朝の時間帯は、少なくとも過去28日間ではほとんど障害が記録されていません。

いちばん巻き込まれるのはClaude Code

障害がどのサービスに影響したかも集計しました。1件の障害が複数のサービスに影響することがあるので、合計は50件を超えます。

・Claude Code が41件

・claude.ai（ブラウザ版）が39件

・Claude API が37件

・Claude Cowork が36件

・Claude Console が21件

Claude Codeが最多でした。これは意外なようで、理屈が通っています。Claude Codeは1回の作業でモデルに何十回もリクエストを投げるため、エラー率が少し上がっただけでも、どこかの1回に当たる確率が高くなります。ブラウザで1問1答している人が気づかない程度の不調でも、Claude Codeで長い作業をしている人には途中で止まる形で現れます。

「Claude Codeだけ調子が悪い気がする」という感覚には、数字の裏付けがありました。使い方が悪いわけではありません。

8月5日の7時間、何が起きていたのか

きっかけになった8月5日の障害について、公式の記録を時系列で並べます。すべて日本時間です。

・16時05分、原因を特定し修正作業を開始と告知。対象はMythos 5、Fable 5、Opus 5、Sonnet 5の4モデル

・18時13分、修正作業を継続中と更新

・22時08分、修正を適用し、回復を監視中と更新

・23時14分、解決

発生から解決まで7時間9分でした。28日間の記録のなかで3番目に長い障害です。影響範囲はclaude.ai、Claude API、Claude Code、Claude Coworkの4つすべてに及びました。

ここで注目したいのは、対象モデルの一覧にHaiku 4.5が入っていないことです。つまりこの日に限っては、モデルをHaikuに切り替えれば作業を続けられた可能性が高いということになります。有料プランならモデルを選べるので、これは実際に使える回避策でした。

もうひとつ、記録を見て気づいたことがあります。この障害が解決する23分前、22時51分に別の障害が始まっていました。今度はOpus 5だけを対象にしたもので、こちらは23時34分に解決しています。ようやく直ったと思った直後にまた別の不調が出ていたわけで、あの夜に「まだ変だ」と感じた人の感覚は正しかったことになります。

「自分のせい」を30秒で切り分ける

ここからが実用パートです。応答が返らないとき、最初にやるべきなのは設定を見直すことではなく、公式の状態を確認することです。

いちばん簡単なのは、ステータスページをブラウザで開くことです。ブックマークしておけば10秒で終わります。全部正常なら「All Systems Operational」と表示されます。

Claude Codeを使っているなら、ターミナルから1行で確認することもできます。

# いまClaudeに障害が出ていないか調べる
curl -s https://status.claude.com/api/v2/status.json

# 正常なときに返ってくる内容
{"status":{"indicator":"none","description":"All Systems Operational"}}

# サービスごとの状態を見る
curl -s https://status.claude.com/api/v2/components.json

実行すると、いまの状態が短い英語で返ってきます。私がこの記事を書いている時点では「All Systems Operational」でした。サービスごとの状態も同じ方法で確認できます。

コマンドを覚えるのが面倒なら、Claude Codeにそのまま日本語で頼んでも構いません。「status.claude.comを見て、いまClaudeに障害が出ていないか教えて」と伝えれば、調べて日本語で返してくれます。ただし障害が重い時間帯はClaude Code自体が応答しないことがあるので、その場合はブラウザで開くのが確実です。

もう一歩進めるなら、ステータスページの通知を購読しておく方法があります。ページ右上から登録でき、メールのほか、SlackやTeams、RSSでも受け取れます。障害が始まった時点で通知が届くので、原因を探して時間を溶かすことがなくなります。私は8月5日に30分ほど自分の設定を疑って過ごしましたが、通知を入れていればその30分は不要でした。

止まったときにできる3つのこと

切り分けが済んで「向こうの障害だ」と分かったあと、できることは3つあります。

ひとつめは、モデルを替えることです。8月5日のように、特定のモデルだけが対象になっている障害は珍しくありません。公式の告知には対象モデルが必ず書かれているので、そこに載っていないモデルへ切り替えれば作業を続けられる可能性があります。

ただし万能ではありません。同じ28日間の記録には、7月21日の22時4分から214分にわたってHaiku 4.5でエラーが増えた記録もありました。軽いモデルなら常に安全、ということはないわけです。避難先も落ちるときは落ちます。

ふたつめは、作業を分けて保存しておくことです。長い処理を1回で走らせている最中に止まると、それまでの中間成果ごと失うことがあります。区切りのいいところでファイルに書き出しておけば、復旧後に途中から再開できます。これは障害対策というより、そもそも長い作業を任せるときの基本です。

みっつめは、時間をずらすことです。前述のとおり、障害の記録は日本時間の夕方から深夜に集中しています。締め切りのある作業なら、夜に粘るより翌朝に回したほうが、結果的に早く終わることがあります。

そして、どの方法もうまくいかないときは、待つのが正解です。28日間で記録された49件のうち、半数以上は1時間以内に解決していました。復旧を待つあいだに設定を書き換えて、あとから元に戻せなくなるほうが損害は大きくなります。

なお、ステータスページが正常を示していて、それでも動かない場合は自分側の問題ということになります。その場合の対処は、症状別にまとめたエラー逆引き図鑑のほうが役に立ちます。

この数字を大げさに受け取らないための但し書き

ここまでの数字は、そのまま「28日のうち71時間はClaudeが使えなかった」という意味ではありません。誤解されやすいところなので、はっきり書いておきます。

正確には「公式が何らかの異常を認識し、記録していた時間」です。内訳の3分の2はminor、つまり一部のリクエストでエラー率が上がったり応答が遅くなったりする状態で、多くの人はその時間帯も普通に使えています。実際、私も19日のうち大半は何も気づかずに作業していました。

また、同時に走った障害の重なりを除かずに単純合計すると128時間になりますが、これは同じ時間を二重三重に数えた数字です。この記事では重なりをまとめて71.1時間としています。集計の仕方でここまで印象が変わるので、障害時間を見かけたときは何をどう数えた数字なのかを確認したほうがいいと思います。

そのうえで、私が受け取った結論はこうです。Claudeは3日に2日は何かしら調子が悪く、その多くは私たちが気づかない程度の不調である。だから「今日は何か変だ」と感じたとき、それは気のせいでも自分のせいでもない可能性が十分にある。まず外を確認してから、自分を疑えばいい。

この考え方は、以前書いた記事とも重なります。Claude Codeを4か月使って分かった限界をまとめたとき、失敗の半分は道具の限界ではなく自分の確認不足でした。今回はその逆で、自分のせいだと思い込んで確認していなかったケースです。どちらも、確認の順番を間違えると時間を失うという点では同じでした。

よくある質問

無料プランでも障害の影響は同じですか

障害はモデルとサービス単位で発生するので、プランによる差はありません。ただし有料プランならモデルを切り替えられるぶん、特定モデルだけの障害を回避しやすくなります。無料プランで急ぎの作業をしていて止まった場合は、復旧を待つか、別の手段に切り替えることになります。プランごとの違いは料金完全ガイドにまとめてあります。

障害中にエラーが出たぶん、利用量は減りますか

エラーで応答が返らなかったリクエストの扱いは公式に明記されていません。心配な場合は、設定画面の使用量表示で障害の前後を見比べておくと、実際にどう扱われたかを確認できます。

ステータスページに何も出ていないのに調子が悪いときは

公式の記録に載るのは、ある程度の規模で観測された異常です。ごく一部の利用者にだけ出ている不調は載らないことがあります。その場合は、いったんセッションを新しくする、モデルを替える、時間を置くという順で試すのが早いです。それでも直らないなら、自分の設定やネットワークを疑う番になります。

障害の通知はどこで登録できますか

ステータスページの右上にある購読ボタンから登録できます。メール、SMS、Slack、Teams、Webhook、RSSに対応しています。毎回ページを見に行くより、通知を受け取るほうが確実です。

まとめ

公式の障害記録を28日分すべて数えた結果、記録された障害は50件、重なりを除いた実質の障害時間は71.1時間、何かが起きていた日は28日のうち19日でした。障害は日本時間の22時台と夕方に偏っていて、いちばん巻き込まれやすいのはClaude Codeです。

大事なのは数字そのものより、順番だと思っています。応答が返らないときは、設定を見直す前にステータスページを見る。向こうの障害だと分かったら、対象外のモデルに替えるか、時間をずらすか、待つ。この順番を決めておくだけで、8月5日に私が溶かした30分は使わずに済みます。

Claudeが動かない日は、これからも定期的にやってきます。そのときに落ち着いていられるように、ステータスページをブックマークしておくことをおすすめします。

あわせて読みたい関連記事：

AIの最新情報をリアルタイムで受け取りたい方へ

Xで@ai_hack_dxとして、Claude Codeの新機能や障害情報、非エンジニアでも使える実践的な活用法を毎日発信しています。今回のような障害が起きたときも、いち早く速報と復旧情報をお届けしています。よろしければフォローして、最新情報を受け取ってください。

https://x.com/ai_hack_dx