Claude障害は7月7日朝に何が起きたか【Claude Codeログイン影響も確認】

2026年7月7日の朝、Claude.aiへ入りにくい、Claude Codeでログインできない、と感じた人は少なくなかったはずです。業務でClaudeを使っている会社では、たった数十分でも「これは自社PCの問題なのか、Claude側の障害なのか」を切り分けるだけで手が止まります。

公式Statuspageを確認すると、7月7日朝(JST)に該当する本件は、UTCでは2026年7月6日19時18分から20時5分まで記録された「Elevated errors on Claude.ai」です。日本時間では、7月7日4時18分から5時5分にあたります。

Claude障害は7月7日朝に何が起きたか

7月7日朝のClaude障害を追う時に、まず注意したいのは時刻です。ClaudeのStatuspageはUTC表記なので、日本時間の朝に見えた障害が、公式ページでは前日の7月6日として並びます。

公式のIncident Reportでは、2026年7月6日19時18分(UTC)にClaude.aiのエラー増加を調査中と記録されました。
日本時間では7月7日4時18分です。その後、19時28分(UTC)の更新で、Claude.aiへの影響に加えて、Claude CodeでClaude.ai OAuthログインができない影響もあると説明されています。

19時46分(UTC)には修正が適用され、Claude.aiとClaude CodeのOAuthログイン周辺の回復を監視中になりました。20時5分(UTC)にResolvedとなり、日本時間では7月7日5時5分に解消した形です。

出典: Claude Status「Elevated errors on Claude.ai」(英語)

つまり、7月7日朝のClaude障害は「Claude.aiにエラーが出た」「Claude Codeのログインにも一部影響した」という2段で理解すると、社内への説明がぶれません。朝の作業開始前に気づいた会社では、ちょうど始業前の確認時間帯と重なり、原因の切り分けに迷いやすい時間帯でした。

Claude Codeログイン影響はどこまで確認されたか

Claude Codeログイン影響について、公式に確認できる表現は限定的です。Statuspageには、Claude CodeでClaude.ai OAuthを使ったログインができない影響がある、と記録されています。ここから「Claude Codeの全機能が止まった」とまでは言えません。

実務上は、この違いを押さえるだけで初動が変わります。既存セッションが動いている人、再ログインだけ失敗する人、Claude.ai自体に入れない人、APIだけが失敗する人では、取るべき対応が違うからです。ログイン不可に見える時ほど、まず公式StatuspageでClaude.aiとClaude Codeの両方を見て、自社の端末や組織設定の問題と切り分けてください。

過去のClaude障害時の初動は、Claude障害でAI業務が止まった時の対応でも詳しく整理しています。今回の7月7日朝のClaude障害では、特に「OAuthログインへの影響」という表現を押さえておくと、社内で余計な再インストールや認証情報削除を始めずに済みます。

7月7日のClaude障害を同日午後のSonnet 5障害と混同しない

7月7日のClaude障害を調べる時は、同じ日の別インシデントも混ざりやすいところです。日本時間の7月7日午後には、Claude Sonnet 5のElevated errorsも記録されました。こちらはUTCで7月7日6時58分から7時37分、日本時間では15時58分から16時37分にあたります。

日本時間	公式タイトル	主な影響	見方
7月7日4時18分から5時5分	Elevated errors on Claude.ai	Claude.ai、Claude CodeのClaude.ai OAuthログイン	朝の本命インシデント
7月7日15時58分から16時37分	Elevated errors on Claude Sonnet 5	claude.ai、Claude API、Claude Code、Claude Cowork	同日午後の別件
7月8日5時2分から8時46分	Elevated errors for some models	主にClaude Fable 5、claude.ai、API、Code、Cowork	翌朝にかかる別件
7月9日4時7分から6時4分	Degraded performance for Claude Code on the web…	Claude Code on the Web、Cowork Remote、Claude Tagなど	Claude Code系の別件

出典: Claude Status「Elevated errors on Claude Sonnet 5」(英語)

出典: Claude Status「Elevated errors for some models」(英語)

出典: Claude Status「Degraded performance for Claude Code on the web, Cowork Remote, Claude Tag, and Claude Code Review sessions」(英語)

社内共有では「7月7日のClaude障害」とまとめたくなりますが、朝のClaude.ai障害、午後のSonnet 5障害、翌朝にかかる一部モデル障害は分けて説明したほうが安全です。APIが失敗したのか、Claude.ai画面が不安定だったのか、Claude Codeの認証で止まったのかによって、再発時の備えも変わります。

Claude障害時に会社で最初に確認する3点

Claude障害が疑われる時、最初に見る場所を決めておくだけで、現場の混乱はかなり減ります。ここでのポイントは「サービス側」「自社側」「作業状態」を同時に見ないことで、順番を決めてひとつずつ潰します。

1つ目は、Claude Statusでclaude.ai、Claude API、Claude Codeのどこに影響が出ているかを見ることです。
社内の誰かひとりが確認し、SlackやChatworkなどの社内チャンネルへ「公式障害あり」「公式障害なし」「確認中」のどれかで共有します。

2つ目は、自社環境の切り分けです。会社のネットワーク、SSO、ブラウザ、VPN、端末制限で止まっている場合もあるため、複数人が同じ症状ならサービス側、1人だけなら自社環境を先に見ます。

3つ目は、途中作業の保存状態です。Claude Codeでファイル編集中だった場合、手元の差分、未保存のメモ、手動で進めた作業を分けます。ここを曖昧にしたまま復旧後に再開すると、古い生成物で上書きする事故が起きかねません。社内AIが遅い、止まる時の見方は、社内AIが遅い・止まる原因もあわせて確認すると整理しやすくなります。

Claude障害後に代替AIへ切り替える前の業務継続ルール

Claude障害が起きると、すぐChatGPTやGeminiへ切り替えたくなります。短い調べ物や一般的な文章の下書きなら、それで十分な場面もあります。
ただし、顧客情報、契約書、社内の未公開資料、ソースコードを扱う業務では、代替AIへの切り替えをその場の判断だけで進めないほうが安全です。

最初に決めるべきなのは、止めてよい業務、人が引き取る業務、代替AIへ回せる業務の3分類です。顧客返信や納期回答のように外部へ影響するものは人が文章を確定し、社内メモの要約や公開情報の調査なら代替AIへ回しやすい領域になります。

Claudeが落ちてる時の代替先選びは、Claudeが落ちてる時に代替AIへ切り替えるべきかで扱っています。今回の7月7日朝のClaude障害から学ぶなら、代替AIリストより先に「何を入れてはいけないか」を社内ルールにすることが重要です。

もうひとつ見落としやすいのが契約管理です。障害時に各部署が勝手に別ツールへ登録すると、あとで契約、権限、データ保管場所が見えなくなります。AIツールの契約や権限の整理は、AIツールの契約棚卸しのように、平時に済ませておくほうが現場は動きやすくなります。

7月7日朝のClaude障害そのものは短時間でResolvedになりました。しかし、業務でAIを使う会社にとっては、数十分の停止でも「誰が確認し、どこまで待ち、何を代替へ回すか」が問われます。復旧時間を自社でコントロールすることはできません。だからこそ、停止時の判断手順は自社で持っておく必要があります。

FAQ