PaPoo
cover

「Claude、落ちてる?」を素早く見分けるための非公式ダッシュボード

Claudeを使っていて「なんか遅い」「エラーが返ってくる」と感じたとき、まず気になるのは自分の環境が悪いのか、それともClaude側で障害が起きているのか、ですよね。
その切り分けを手早くやるためのサイトが Claude Status です。名前からしてかなり直球で、役割もそのまま。Claude.ai、Claude API、Claude Code の状態を見て、いま何が起きているのかをまとめてくれます。

ただし、これは Anthropic公式ではない というのが大事なポイントです。ここ、地味だけどかなり重要だと思います。便利な非公式サイトって、使い勝手は良くても「どこまで信じていいの?」が曖昧になりがちですが、このサイトはそのあたりをかなり丁寧に線引きしています。公式の status.claude.com を「正本」として扱い、このページはそれを読み取ったうえで、コミュニティ報告や独自の latency 計測を足している、という立て付けです。

先に要点だけ

ただの“障害情報サイト”ではないところが面白い

Claude Status の面白さは、単に「落ちているかどうか」を表示するだけじゃない点です。ページ上部の banner が緑なら全体は概ね正常、赤くなれば公式の incident が出ている、というわかりやすい構造になっています。
そのうえで、個別コンポーネントごとの状態が並びます。たとえば Claude.ai の Web Interface、Claude Console、Claude API、Claude Code CLI Tool、Claude Cowork、Claude for Government まで見える。一般ユーザーには全部は要らないかもしれませんが、開発者や業務利用者にはかなりありがたい粒度です。

特に見ていて面白いのは、​​「Claude全体が死んでいる」わけではなく、APIだけ、あるいはClaude Codeだけ不調 というケースがちゃんと見えること。こういうとき、体感だけだと「全部だめだ」と思い込んでしまいがちですが、実際には一部の経路だけ落ちていることがあるんですよね。サービスが大きくなるほど、この“部分障害”の見分けが大事になります。

公式情報に、ユーザーの声を足しているのが強い

このサイトの説明を読むと、Anthropicの公式 Statuspage API を使いながら、​コミュニティの outage report17か国からの global latency probes を組み合わせているとあります。
latency はざっくり言うと「反応の速さ」です。ここでは time-to-first-byte、つまり「最初の1文字目が返ってくるまでの時間」を見ているようなものだと思えばよいです。要するに、完全に落ちていなくても「妙に重い」「待たされる」という兆候を拾うわけです。

これが地味に効きます。公式ステータスはどうしても慎重なので、障害として確定するまで少し時間がかかることがあります。一方でユーザー側は、その前から「なんかおかしい」と感じる。
このズレを埋めるのがコミュニティ報告です。公式が“確定”する前の、現場のざわつきを見られるのは便利ですし、実務ではむしろこっちのほうが役に立つ場面も多いと思います。

右側のライブフィードが、妙に人間くさい

ページには Live Community Feed があり、直近の報告が時系列で流れます。
たとえば「API error」「401で認証できない」「ECONNRESETで接続できない」「filesystem tool が死んでいる」みたいな、かなり生々しい声が並びます。

この手のフィードは、ただのデータ一覧よりずっと実用的です。
というのも、同じ“障害”でも、実際には症状がぜんぜん違うからです。認証が通らないのか、接続が切れるのか、特定ツールだけ壊れているのか。エラー文をそのまま見られると、「自分だけ?」の判断がかなり早くなります。

個人的には、こういう生の報告が見えるサイトは好きです。きれいに整ったステータス表だけだと、現場の困り方がぼやけてしまうんですよね。ユーザーの生声があると、サービスの不調が「現象」として見えてきます。

過去の障害履歴も、かなりしっかり載っている

Historical Events には、7月下旬の障害履歴がずらっと並んでいます。
内容を見ると、Sonnet 5、Opus 4.8、Haiku 4.5、Claude Code、Enterprise SSO など、かなり広い範囲で「elevated errors」、つまりエラー率の上昇が起きていたことがわかります。

ここで興味深いのは、完全停止というより “エラーが増えている”状態 が多いことです。
これ、実運用では意外と厄介です。全部が真っ黒に止まるより、少しだけ失敗率が上がるほうが、原因の切り分けが難しいからです。ユーザーは「たまに失敗する」「リトライすると通る」と感じ、運営側も一発で障害と断定しにくい。こういうグレーゾーンを拾ってくれるのはありがたい。

また、Claude Code 系では「MCP filesystem が落ちている」「tool にアクセスできない」といった話も出ています。MCP は、AI が外部ツールやデータに接続するための仕組みの一種です。ここが不調だと、チャット自体は動いても、ファイル操作や連携機能がダメになる。つまり「Claudeは見えているのに仕事にならない」状態になりやすい。これ、使っている人ほど嫌なやつです。

「遅いだけ」のときに見る場所がちゃんとある

FAQ で案内されている通り、Claude が遅いときは、まず latency panel を見ればいい、という設計になっています。
ここで重要なのは、​遅さは障害の前触れ になりやすいことです。サービスが完全に死ぬ前に、応答がもっさりし始めることはよくあります。だから「エラーが出てないから大丈夫」とは言い切れない。

ただし、ページ側でもちゃんと釘を刺しています。公式状態も問題なさそうなら、重いプロンプトや長い agent loop が原因かもしれない、と。
この一文はかなり実践的です。体感の遅さって、つい全部サービス側のせいにしたくなるんですが、実際はユーザー側の処理が重いだけということもあります。AI相手だと、モデルの遅さと自分の使い方の重さが混ざるので、切り分けが本当に面倒なんですよね。

公式ページとの距離感がちょうどいい

このサイトの立ち位置は、かなりうまいと思います。
公式ではない。でも、公式のデータに乗っかっている。しかもコミュニティ報告と latency を足して、公式だけでは見えない温度感を出している。

こういう中間地点の情報源は、実はすごく価値があります。
公式サイトは確かに正確ですが、どうしても“確定情報”しか載らない。逆にSNSは早いけれど雑音も多い。Claude Status は、その真ん中あたりを狙っていて、見やすさと早さのバランスがいい。私はこのタイプのサイト、かなり実用的だと思います。

もちろん、最終確認は公式の status.claude.com でやるべきです。ここは記事でも明記されています。
でも、日常的に「今どうなってるの?」を知りたいなら、Claude Status のほうが見やすい場面は多そうです。

使う場面を想像すると、かなり納得感がある

たとえば、仕事中に Claude Code が急に接続エラーを返し始めたとします。
そのとき、まず自分のAPI keyを疑うのは自然ですが、それだけで何分も溶かすのはもったいない。Claude Status を開けば、全体障害なのか、Claude Code だけなのか、あるいは自分だけなのかの当たりをつけられます。

この“当たりをつける”という行為は、地味ですが本当に大きいです。
障害対応って、原因究明そのものよりも、まず「自分のせいか、外のせいか」を早く分けるのが大事なので。ここが速いと、無駄な再ログインや設定見直しを減らせます。

こういうサイトがあると、サービスの見え方が変わる

AIサービスって、見た目は静かでも裏側ではけっこう繊細です。モデル、認証、API、Web UI、外部ツール連携が複雑につながっているので、ちょっとした不具合が「使えない」に見えやすい。
Claude Status は、その複雑さをユーザー向けに単純化してくれる存在です。しかも単純化しすぎず、ちゃんと詳細も残しているのがいい。

個人的には、こういう“観測の道具”が増えるのは歓迎です。
サービスそのものを直接改善するわけではないけれど、利用者のストレスを確実に減らしてくれるからです。特に業務で使う人にとっては、障害の有無を確認するまでの数分が、そのまま作業効率に響きます。


参考: Is Claude Down? | Claude Status - Real-Time Outage & Uptime Monitor

同じ著者の記事