Claude障害の確認方法と対処法 使えない原因・エラー別の解決手順と復旧の目安

Claudeが応答しない、ログインできない、途中でエラーが出て止まる。こうした症状に直面したとき、まず知りたいのは「自分だけの問題なのか」という一点です。

障害であれば待つのが正解で、環境側の問題であれば自分で直すしかありません。判断を誤ると、直せるものを待ち続けたり、直しようのないものを延々と調べ続けたりすることになります。最初の切り分けが、無駄な時間を減らす分かれ目です。

本記事では、障害かどうかの判定から症状別の対処、障害が起きる原因と復旧までの目安、障害ではないケースの見分け方、そして業務を止めないための動き方までを順に整理します。

確認したいポイント	結論	詳細
Claudeで障害が起きているか調べるには？	公式の稼働状況ページを見る	status.claude.comで各サービスの状態が公開され、障害中は該当箇所に異常表示が出ます。
Claudeの障害はなぜ起きる？	利用集中や更新時の不具合が主因	需要のピークやモデル更新、認証基盤の不調など、原因はいくつかの系統に分かれます。
復旧までどれくらいかかる？	多くは1時間前後で解消	短いものは20分前後、複数モデルにまたがる事象では数時間かかる例も記録されています。
ログインできない原因は？	認証側の障害か環境側の問題	公式ページが正常ならブラウザのキャッシュや社内ネットワークの制御を疑います。
エラーが出て止まる場合は？	エラー番号で原因を切り分ける	429は自分側の上限超過、500と529はサービス側の事象で、対処の方向が変わります。
障害中は待つべきか切り替えるべきか？	影響の大きさと見込みで判断	業務が止まるなら代替へ、後回しにできるなら復旧を待つという線引きが実務的です。
障害ではないのに使えない理由は？	利用上限や環境側の要因	プランの枠切れ、拡張機能の干渉、支払い状態の不備などが代表的な原因になります。
再発への備えで最優先は？	代替手段と連絡経路の事前決定	止まる前提で切り替え先と社内周知の方法を決めておけば、混乱を最小限に抑えられます。

この記事でわかること

• Claudeの障害が起きているかを短時間で判定する方法
• ログインできない・応答が止まるなど症状別の原因と対処
• 障害が発生する主な原因と、復旧までにかかる時間の目安
• 障害ではないのに使えないときに確認すべき4つの箇所
• 障害中に業務を止めないための動き方と再発への備え

AIを業務に組み込む前に体制を整えたい方へ ネクストスケールは、生成AI・AIエージェントの導入設計から社内定着までを一気通貫で支援しています。障害時の運用ルールを含めた実務設計からご相談いただけます。 ▶ AI活用の無料相談を予約する

Claudeの障害が疑われるときに最初にすること

原因の候補は、サービス側の障害、アカウントの状態、手元の環境という3系統に分かれます。上から順に確認していけば、数分で答えにたどり着けます。

公式の稼働状況ページで事実を確認する

Anthropicは、Claude関連サービスの稼働状態を公開しています。claude.ai、Claude API、Claude Code、Claude Coworkなど区分ごとに状態が示され、障害が起きていれば該当箇所に異常表示が出ます。（参照：Claude Status 公式ページ）

ここで確認すべきは、自分が使っている経路の欄です。チャット画面は正常なのにAPI経由の処理だけ失敗する、Claude Codeだけ動かないといった状況は実際に起こります。全体表示だけを見て判断すると、原因を取り違えます。

表示される時刻はUTC表記です。日本時間に直すには9時間を足す必要があるため、履歴を読むときは時差を意識しないと発生時刻を誤って把握します。

履歴には解決までの経過も残ります。障害が終わった後で「あの時間帯に何が起きていたか」を確認できるため、社内報告の根拠としても使えます。

障害と自分側の問題を見分ける目安

公式ページが正常を示しているのに使えない場合、原因は手元にある可能性が高くなります。判断材料になるのは、別の端末や別の回線で同じ症状が出るかどうかです。

スマートフォンの回線では動くのに社内のWi-Fiでは動かないなら、ネットワーク側が原因です。どの環境でも同じように失敗するなら、アカウントの状態かサービス側を疑う流れになります。

障害の規模を把握する

障害と判明したら、次に見るのは影響範囲です。特定のモデルだけなのか、複数のモデルにまたがっているのか、認証まわりまで含むのかで、取れる手段が変わります。

1つのモデルに限定された事象であれば、別のモデルへ切り替えることで作業を続けられる場合があります。全モデルに及ぶ事象や認証の障害では切り替えが効かないため、待機か代替サービスへの移行という判断になります。

影響範囲は履歴の記載からも読み取れます。どのサービスが対象として明記されているかを見れば、自社で使っている経路が含まれるかどうかを判断できます。記載のないサービスは、その時点では正常に動いている扱いです。

関連記事：Claude APIの料金｜モデル別の単価と月額の試算方法・コストを抑える4つの仕組み

症状別に見る原因と対処

同じ「使えない」でも、症状によって疑うべき箇所は違います。よくある5つのパターンに分けて確認していきます。

ログインできない

認証基盤の不調は、実際に記録されている障害の型です。ログイン試行が通らない事象と、モデルへのリクエストが失敗する事象が同時に発生した例もあります。

公式ページに該当する記載がなければ、ブラウザのキャッシュとCookieの削除、シークレットウィンドウでの試行、別ブラウザでの確認という順に進めます。外部サービス連携でログインしている場合は、連携元の状態も確認対象に入ります。

複数人で同じ症状が出ているかどうかも判断材料になります。同じ組織の別の担当者が問題なく使えているなら、原因は個人の環境かアカウントの状態に絞り込めます。

応答が返らない・途中で止まる

画面は開くのに応答が返らない、生成が途中で止まるという症状は、完全な停止ではなく性能低下の段階でよく現れます。動いてはいるため障害と気づきにくいのが厄介な点です。

公式ページで性能低下の表示が出ていれば、待つ以外の対処はありません。表示がない場合は、長い指示を分割する、添付する資料の量を減らすといった負荷を下げる工夫で改善することがあります。

生成の途中で止まる場合は、処理の区切り方も見直す余地があります。1回の依頼で扱う範囲を狭くすると、途中で失敗しても影響が限定され、再開もしやすくなります。

エラーが出て中断する

エラー番号が表示される場合、それが最も強い手がかりになります。429は自分のアカウントがリクエスト上限に達した状態、500はサービス内部の予期しないエラー、529は利用集中による一時的な過負荷を意味します。

429であればリクエストの間隔を空け、同時に走らせる処理を減らします。500と529はサービス側の事象のため、待ち時間を段階的に延ばしながら再試行するのが基本の対応です。コードや設定を見直しても解決しません。

再試行の間隔にも工夫が要ります。失敗した直後に連打すると混雑を助長するため、待ち時間を徐々に延ばし、少しばらつきを持たせる方式が推奨されます。同時に走らせる処理の数を一時的に絞ることも効果があります。

サーバー側の事象で失敗したリクエストは、利用枠を消費しない扱いになっています。障害中に何度か試したことで枠を無駄にしたのではないかという心配は、基本的に不要です。

Claude Codeだけ動かない

コンポーネントは独立して状態が管理されています。チャット画面が問題なく使えていても、Claude Codeの欄だけ異常表示になっているケースがあります。

公式ページが正常であれば、確認先は手元の設定です。認証情報の期限切れ、設定ファイルの記述ミス、バージョンの不整合といった要因が典型的です。エラーが出た時点で表示前に自動で再試行が行われている仕様のため、メッセージが見えた段階では既に何度か試された後だと考えて差し支えありません。

特定のモデルだけ使えない

処理の容量はモデルごとに管理されています。上位モデルが混雑していても、別のモデルなら通ることがあるのはそのためです。

履歴を見ると、特定モデルだけを対象にした障害が繰り返し記録されています。業務で使うモデルを1つに固定していると、この型の障害に弱くなります。代わりに使えるモデルを普段から決めておくと復旧を待たずに済みます。

切り替え先を決めるときは、品質の差も把握しておきます。処理の内容によっては下位モデルでも十分な場合があり、事前に試しておけば障害時に迷わず選べます。

AI活用の運用設計まで相談したい方へ ツール選定から社内ルール整備、障害時の切り替え手順づくりまで、実務に落とし込む形でご支援します。現場が迷わない体制を一緒に設計します。 ▶ AIコンサル・AX伴走支援の内容を見る

関連記事：Anthropic Academyとは？無料で学べるClaude公式コースの内容と始め方

Claudeの障害はなぜ起きるのか

公開されている履歴を読むと、障害の原因はいくつかの型に整理できます。傾向を知っておくと、発生時の見通しが立てやすくなります。

利用の集中による容量不足

最も多いのが、リクエストの集中でサービスが受け切れなくなる型です。新しいモデルが公開された直後や、利用が重なる時間帯に発生しやすくなります。

この型は特定のモデルから始まり、対応の過程で別のモデルへ波及することがあります。1つが回復した直後に別のモデルでエラーが増える経過が記録された例もあり、全体が落ち着くまで時間がかかる傾向があります。

利用が世界規模で集中する時間帯は、日本の業務時間と必ずしも一致しません。海外の稼働時間と重なる時間帯に不安定になりやすい傾向があるため、重要な処理の実行時刻をずらす工夫も有効です。

モデルの更新に伴う不具合

新しいモデルの提供開始や既存モデルの更新は、環境の変化を伴います。変更の直後に特定モデルだけ応答エラーが増える事象は、履歴のなかで繰り返し見られる型です。

業務で使う環境では、公開直後の最新モデルにすぐ全面移行しない運用が安全側の選択になります。一定期間は従来のモデルも使える状態を残しておくと、影響を受けにくくなります。

移行の判断は、実際の作業で試してから下すのが確実です。数日から数週間ほど並行して使い、品質と安定性を確かめたうえで切り替えれば、初期の不具合に巻き込まれるリスクを下げられます。

認証基盤や上流インフラの問題

ログインが通らない、複数のサービスで同時に不調が出るという場合、原因はモデルではなく認証や共通基盤にあります。影響範囲が広くなりやすい型です。

この型ではモデルの切り替えが効きません。認証そのものが通らなければ、どのモデルを選んでも結果は同じだからです。復旧を待つか、別のサービスへ移るかの二択になります。

影響が複数のサービスに同時に及んでいる場合は、この型を疑います。チャット画面もAPIもClaude Codeも同時に不調であれば、個別のモデルではなく共通部分に原因があると考えるのが自然です。

障害と提供停止の違い

技術的な不具合とは別に、事業上の判断でサービスの提供が止まる場合もあります。2026年6月には、Anthropicが一部の最上位モデルについて米国の輸出管理への対応を理由にアクセスを一時停止し、7月1日に再開しています。

この種の停止は稼働状況ページの障害履歴とは別の枠組みで告知されます。使えなくなった理由が技術的な障害なのか、提供方針の変更なのかで、待つ意味があるかどうかは変わります。公式の発表もあわせて確認する必要があります。

関連記事：Claudeのアーティファクトとは？使い方と作れるもの・共有方法をまとめて解説

復旧までどれくらいかかるのか

待つか切り替えるかの判断には、復旧までの見通しが要ります。公開されている履歴から、おおよその傾向は読み取れます。

直近の記録から見る所要時間

2026年7月から8月にかけての記録を見ると、単一モデルの性能低下は調査開始から解決まで20分から40分程度で収まっている例が目立ちます。1時間前後で解決するケースが最も多い水準です。

複数のモデルにまたがる事象では時間が延びます。全モデルに影響が及んだ事象で解決まで3時間近くを要した例や、断続的に再発しながら5時間以上続いた例も記録されています。

これらは過去の傾向であり、次の障害に当てはまる保証はありません。目安として持ちつつ、業務への影響が大きい場合は復旧を待たない前提で動くほうが安全です。

時間帯によっても体感は変わります。日本時間の深夜から早朝は海外の稼働時間と重なるため、同じ規模の障害でも復旧の告知が届くまでに間が空くことがあります。

復旧の進み方を読む

履歴の更新は段階を追って記録されます。調査中、原因特定、修正の実施、監視中、解決という流れで、どの段階にあるかによって残り時間の見通しは変わります。

調査中の段階が続いているうちは、終わりが読めません。原因特定や監視中まで進んでいれば、そう遠くない時点で解決する可能性が高まります。更新の間隔そのものも判断材料になります。

解決の告知が出た後も、しばらくは様子を見る余地があります。監視中から解決へ移った直後は動作が安定しきっていないことがあり、重い処理を一斉に流すのは避けたほうが無難です。

待つか切り替えるかの判断基準

判断軸は、その作業が止まることで何が困るかに置くと整理しやすくなります。締め切りのある業務や顧客対応に関わる処理は、待つ選択肢を取りにくい領域です。

後回しにできる作業であれば、待って再開するほうが結果的に早く済みます。切り替えには設定変更や品質確認の手間がかかるため、影響の小さい作業まで切り替えると、かえって時間を失います。

判断を都度考えていると時間を失います。「顧客対応に関わるものは即座に切り替え、社内向けは30分待って再判断する」といった基準を先に決めておくと、迷わず動けます。

社内展開の判断材料をお探しの方へ 生成AIの業務活用や社内ルール整備の進め方をまとめた資料をご用意しています。 稟議や社内説明の材料としてそのままお使いいただけます。 ▶ お役立ち資料をダウンロードする

障害ではないのに使えない場合

公式ページが正常を示しているのに動かないケースも珍しくありません。確認すべき箇所は4つに絞られます。

利用上限に達している

プランごとに定められた利用枠を使い切ると、一定時間は新しい依頼を受け付けなくなります。これは障害でもエラーでもなく、仕様どおりの動作です。

枠は時間の経過で回復するため、待てば再び使えるようになります。業務で頻繁に到達するようであれば、プランの見直しか、処理の分散を検討する段階にあると考えられます。

上限に近づいていることは、事前に把握できる場合があります。表示される残量や警告に注意を向けておけば、作業の途中で急に止まる事態を避けられます。

ブラウザや拡張機能の影響

画面が正しく表示されない、ボタンが反応しないといった症状は、ブラウザ側に原因があることがあります。広告ブロックやセキュリティ系の拡張機能が通信を妨げている場合も含まれます。

切り分けは簡単です。シークレットウィンドウで開いて正常に動くなら、拡張機能かキャッシュが原因だと特定できます。該当する拡張機能を一時的に無効化して確認する流れになります。

アプリ版を使っている場合は、再起動と更新の確認が先です。古いバージョンのまま動かし続けていると、仕様変更に追いつけず不具合が出ることがあります。

社内ネットワークの制御

企業環境では、セキュリティ製品による通信制御が影響することがあります。新しく導入されたフィルタリングや、更新された許可リストの影響で特定の宛先だけ通らなくなる事例は少なくありません。

自宅の回線では動くのに社内では動かないという状況であれば、この可能性が濃厚です。個人で調べても解決しない領域のため、情報システム部門への確認が近道になります。

VPNを経由している環境でも同様の症状が出ます。接続先を切り替えて試すと、どこで止まっているかの見当がつきます。

アカウントや支払いの状態

支払い方法の期限切れや、組織で管理しているアカウントの権限変更が原因になることもあります。個人では気づきにくい種類の要因です。

管理画面でアカウントの状態を確認し、請求まわりに問題がないかを見ます。組織で契約している場合は、管理者側で設定が変更されていないかの確認も必要になります。

この種の要因は、症状が突然現れるのが特徴です。前日まで問題なく使えていたのに急に使えなくなった場合は、技術的な原因を探る前に契約や権限の状態を確認するほうが早く解決します。

障害中に業務を止めないための動き方

障害そのものは避けられませんが、業務が止まる時間は工夫で短くできます。発生時に取るべき行動を3つに整理します。

影響範囲をすぐ把握する

最初にすべきは、社内のどの業務が止まっているかの把握です。AIを組み込んだ処理が複数ある場合、影響を受けるものと受けないものが混在します。

資料作成のように担当者が個別に使っている業務は、影響が限定的です。予約対応や問い合わせ処理のように顧客と接する業務が止まると、外部への影響が即座に発生します。優先順位はこの違いで決まります。

予約業務の自動化と停止時の影響については、AIエージェントで予約業務を自動化｜仕組み・メリット・活用事例・導入の進め方で整理しています。

把握を素早く済ませるには、事前の整理が欠かせません。どの業務でどのサービスを使っているかの一覧が手元にあれば、確認は数分で終わります。用意がなければ、聞いて回るところから始めることになります。

社内向けの業務でも、締め切りが迫っている作業は影響が大きくなります。単純な業務分類ではなく、そのタイミングで何が困るかで判断する姿勢が必要です。

資料作成業務をAIに任せている場合の全体像は、AIエージェントで資料作成を自動化｜仕組み・おすすめツール・活用事例を解説が参考になります。

問い合わせ対応の負荷を下げる

障害時に最も負荷がかかるのは、状況を聞かれる立場の担当者です。同じ質問が各所から届き、本来の復旧対応に手が回らなくなります。

先手を打って全社に第一報を出すことが、結果的に問い合わせを減らします。発生の第一報、状況更新、復旧報告の3種類を定型文として用意しておけば、判断に迷わず短時間で発信できます。

問い合わせ対応そのものを効率化する考え方は、AIエージェントのコールセンター活用とは？導入メリット・事例・始め方を解説で解説しています。

発信の際は、確定している事実と未確定の見込みを分けて書きます。復旧時刻を安易に約束すると、遅れた場合に信頼を損ないます。公式ページの記載をそのまま引用する形が、最も誤解を生みにくい伝え方です。

代替手段に切り替える

切り替え先を障害発生後に探し始めると、判断だけで時間を消費します。用途ごとに次善の選択肢を事前に決めておくことが、実質的な備えになります。

中小企業庁が示す事業継続の考え方でも、業務に不可欠なシステムが使えない場合の代替方法を用意しているかが、確認すべき項目のひとつとして挙げられています。AIサービスも、この対象に含まれる時代になりました。（参照：中小企業庁「中小企業BCP策定運用指針」）

切り替え先の候補は、用途と求める品質によって変わります。文章作成のように代替が効きやすい業務と、独自に構築した処理のように代替が難しい業務では、準備の重さも違ってきます。

選択肢を比較する視点は、AIエージェントプロダクトの比較と選び方｜種類・活用事例・導入のポイントを解説にまとめています。

止まらない仕組みまで含めて設計するなら 再試行やモデル切り替えを織り込んだAIシステムの設計・開発をご支援します。 既存システムとの連携や運用保守までまとめてご相談いただけます。 ▶ AIシステム開発のサービス内容を見る

再発に備える体制づくり

障害は一度きりの出来事ではありません。次に備える作業は、落ち着いている時期にしか進められません。

障害の記録を残して傾向をつかむ

発生日時、症状、影響を受けた業務、復旧までの時間を記録に残しておくと、自社にとっての実害が数字で見えてきます。感覚ではなく事実に基づいて対策を判断できるようになります。

記録が溜まると、対策の優先順位も明確になります。年に数回しか影響がない業務に手厚い備えを用意する必要はなく、頻繁に止まって困る業務から順に手を打てば投資は無駄になりません。

記録は社内の合意形成にも役立ちます。対策に予算が必要な場面で、実際に何回止まり何時間の遅れが出たかを示せれば、判断は通りやすくなります。

依存度の高い業務から対策する

どの業務がどのサービスに依存しているかを一覧にしておくと、影響範囲を即座に判断できます。棚卸しは平時にしかできない作業です。

依存度が高い業務ほど、代替手段の整備や処理の冗長化に投資する価値があります。自社の環境で処理を動かす構成に切り替える選択肢も、費用と手間を比較したうえで検討する余地があります。

別基盤を検討する際の費用感については、Difyの料金プランを比較｜無料の範囲・クラウドとセルフホストの違いと選び方が判断材料になります。

投資の重さは段階に応じて決めます。試用の段階では確認手順を決めるだけ、部門展開では代替手順の文書化、基幹業務での利用では仕組みとしての冗長化というように、依存度に見合った水準に揃えると無理がありません。

対応できる担当者を増やす

手順書を用意しても、実際に判断するのは現場の担当者です。切り分けの順序を体で覚えている人が複数いるかどうかで、復旧までの時間は変わります。

特定の担当者に知識が偏っていると、その人が不在の時間帯に障害が起きた場合に対応が止まります。エラーの意味と確認の順序だけでも共有しておけば、初動の質は大きく変わります。

費用をかけずに学ぶ手段を探している場合は、AI研修 無料｜公的機関10種類と「実質ほぼ無料」を助成金75%で作る方法も選択肢になります。

訓練の機会は意図的に作る必要があります。実際の障害を待つのではなく、切り替え手順を年に一度でも試しておけば、設定が古いままだったといった問題を平時に見つけられます。

まとめ

Claudeが使えないときは、公式の稼働状況ページで事実を確認し、自分が使っている経路の状態を見るところから始めます。全体表示だけで判断すると、原因を取り違えます。

症状ごとに疑うべき箇所は異なります。ログインの不調は認証まわり、応答が止まる症状は性能低下、エラー番号が出る場合は429と500・529で対処の方向が分かれるという整理を持っておくと、初動が速くなります。

復旧までの時間は、単一モデルの事象なら1時間前後、複数モデルにまたがる事象では数時間かかることもあります。影響が大きい業務については、復旧を待たずに代替へ切り替える判断が現実的です。

備えとして先に決めておくべきは、切り替え先と社内への連絡方法の2つです。この2点が決まっているだけで、次に障害が起きたときの混乱は大きく減ります。

AI活用の体制づくりを一緒に進めるなら ネクストスケールは、AI研修から開発・運用支援までを一貫して提供しています。 導入して終わりではなく、使われ続ける状態をつくるところまで並走します。 ▶ サービスについて問い合わせる