Claude障害の確認方法 — ステータスページの使い方

Claudeの稼働状況はどこで確認できるか

Claudeの障害・パフォーマンス低下はstatus.claude.comで確認できます。旧URLのにアクセスすると、このドメインへ自動的にリダイレクトされます。ブックマークは新URLに更新しておくと迷いません。

このページはAtlassian社のStatuspageというサービスの上に構築されています。表示は6つのコンポーネントに分かれます。

Claude Codeが単独のコンポーネントとして分離されているのがポイントです。claude.aiは正常でもClaude Codeだけ障害が出ている、あるいはその逆というケースが実際にあります。CLIでエラーが出たら、まずこのコンポーネント単位の表示を見る習慣をつけておくと切り分けが速くなります。

各コンポーネントの状態は次の5段階で表示されます。

ページ上部には全体サマリーが1行で出ます。個別コンポーネントを確認しなくても、この1行だけで「今Claude全体に何か起きているか」が分かる設計です。各コンポーネントの下には過去90日分の稼働状況が日別の帯グラフで表示され、いつ・どのくらいの時間、状態が悪化していたかを視覚的に遡れます。

インシデントは4段階で進行する

障害が発生すると、ステータスページには単発の告知ではなく時系列の更新が並びます。実際の過去インシデントを追うと、進行は次の4段階を踏むのが基本パターンです。

すべてのインシデントがこの4段階をきっちり踏むわけではなく、軽微な事象は"Investigating"から直接"Resolved"に飛ぶこともあります。重要なのは、"Monitoring"の表示が出た時点ではまだ「様子見」であり、完全復旧の確約ではないという点です。本番運用でリトライを再開するタイミングは、"Resolved"の更新を待つのが安全側の判断になります。

見落としやすいのが時刻表記です。ページ全体のタイムゾーンはUTC(協定世界時)固定で、日本時間ではありません。インシデントの開始・更新時刻を社内のログと突き合わせるときは、9時間を足してJSTに変換する一手間が必要です。

計画メンテナンスはインシデントとは別枠で管理されています。事前に予定されたメンテナンスがあれば「Scheduled Maintenance」として個別に告知され、突発的な障害の一覧とは混ざりません。予定が入っていないときはこの欄自体が空になります。

個人の利用上限とサービス障害を混同しない

「Claudeが使えない」と感じたとき、原因は大きく2つに分かれます。サービス側の障害と、自分のアカウントの利用上限です。この2つは対処法がまったく違うので、まず切り分けます。

利用上限に達した場合は、Claude Codeなら「5時間ごとの利用枠を使い切りました」のようなメッセージが出ます。これは既存のClaude Codeの利用上限が扱う話で、ステータスページを見ても「Operational」としか出ません。上限のリセット時刻はClaude制限の回復を参照してください。

一方、API応答自体が返らない・極端に遅い・529や500系のエラーが連発するなら、サービス側の問題を疑ってステータスページを確認します。429エラーとoverloaded_errorの違いや、それぞれの回復までの目安はClaude rate limit(レート制限)エラーの対処にまとめています。本記事はエラーの意味そのものではなく、「今まさに障害が起きているかどうかを外部から確認する手段」に絞って扱います。

過去のインシデント履歴を遡って確認する

ステータスページには過去のインシデント記録も残ります。トップページの下に表示される日別の履歴に加え、/historyページでは月単位のインシデント一覧を遡れます。

「昨日の夜、応答が遅かったのは自分の環境の問題だったのか、Claude側の障害だったのか」を後から確認したいときはここが唯一の記録です。CI・監視ダッシュボードのログと突き合わせる用途にも使えます。

RSS・Atomフィードでも同じ履歴を購読できます。

curl -s https://status.claude.com/history.atom

自動監視に組み込みたい場合は、Statuspage共通のAPIエンドポイントも公開されています。

curl -s https://status.claude.com/api/v2/summary.json | jq '.status, .components'

このエンドポイントはJSON形式でコンポーネントごとの状態と進行中のインシデントを返します。社内の監視Botやダッシュボードに定期ポーリングで組み込めば、Slack通知より前に自前のアラートを鳴らせます。認証は不要です。

Claude Codeの状態だけを機械的に抜き出したい場合は、jqでコンポーネント名を絞り込みます。

curl -s https://status.claude.com/api/v2/summary.json | \
  jq '.components[] | select(.name=="Claude Code")'

進行中のインシデントにはshortlinkという短縮URLが個別に付いています。社内のSlackチャンネルに共有するときは、長いインシデントページのURLよりこの短縮リンクのほうが貼りやすく、リンクプレビューも安定します。

障害の通知を6つの方法で受け取る

ページを毎回見に行かなくても、更新があったときに通知を受け取れます。ステータスページ右上の「Subscribe to Updates」から、次の6つの方法を選べます。

チームでClaude Codeを本番のCI/CDに組み込んでいるなら、SlackかWebhookでの購読が実用的です。個々のメンバーがそれぞれメール登録するより、チャンネルに1本流すほうが「誰かが見ているはず」という抜け漏れを防げます。

Claude Codeで障害の疑いがあるときにまず確認する手順

ステータスページを開く前に、Claude Code側でもできる切り分けがあります。/doctorを実行するとインストール・設定・拡張機能・コンテキスト使用量を自動チェックし、修正可能な問題は確認の上で適用を提案します。MCPサーバーの接続状態は/mcpで個別に確認できます。ローカル環境の設定ミスは、この2つのコマンドで大半が炙り出されます。

それでも解決しないエラー(API Error: 5xx、529 Overloaded、429など)が出た場合に、初めてステータスページで外部要因を疑う、という順序が効率的です。ローカルの設定を疑わずにいきなり外部障害を疑うと、実は自分のANTHROPIC_API_KEYが失効していただけ、というような単純な原因を見落とします。

よくある質問

ステータスページで「Operational」なのにClaude Codeが動かないのはなぜですか

ステータスページはAnthropic側のインフラの状態を示すものです。ローカルのネットワーク設定、プロキシ、ファイアウォール、期限切れのAPIキーなど、利用者側の環境要因はステータスページには反映されません。この場合は/doctorとネットワーク設定を先に確認します。

障害情報はどのくらいの頻度で更新されますか

インシデント発生中は数十分から数時間おきに更新が入るのが一般的です。更新のたびに購読先(メール・Slack等)に通知が飛びます。更新間隔自体に固定の規定はなく、状況の進展に応じて発信されます。

Claude ConsoleとAPIが別コンポーネントなのはなぜですか

Claude Console(platform.claude.com)は管理画面そのもので、Claude API(api.anthropic.com)はモデルへのリクエストを処理する基盤です。管理画面だけが重い、あるいはAPI応答だけが遅い、という状況が別々に起こり得るため、コンポーネントが分離されています。

障害中にリトライを繰り返すとアカウントに悪影響がありますか

公式ドキュメントは障害そのものへの過度なリトライについて言及していませんが、529 Overloadedや429は短時間の連続リトライがかえって回復を遅らせる場合があります。指数バックオフを挟んだリトライ、またはステータスページの更新を待ってからの再実行が無難です。

障害が起きているのに何も通知が来ないのはなぜですか

購読していないチャネルには通知は届きません。メール・SMS・Slack・Teams・RSS/Atom・Webhookはそれぞれ個別に購読の手続きが必要で、ステータスページを開くだけでは自動的に通知登録はされません。まずどれか1つでも購読済みか確認します。

Claude for Governmentのコンポーネントも同じページで確認できますか

確認できます。ステータスページには政府機関向け提供である「Claude for Government」も独立したコンポーネントとして表示されます。他のコンポーネントとは別の基盤で動くため、状態が異なることがあります。

計画メンテナンス中はどう表示されますか

突発的な障害とは別枠の「Scheduled Maintenance」として告知されます。予定されているメンテナンスがない期間は、この欄自体が表示されません。メンテナンスの実施中は対象コンポーネントの状態が「Under Maintenance」になりますが、これは障害ではなく予定された作業なので、慌てて原因調査を始める必要はありません。ステータスページを開いてこの表示を見つけたら、対応中の障害ではなく計画済みの一時停止だと判断してよいということです。