Claudeで再び大規模システム障害が発生、米国で報告8000件超──IPOを控えるAnthropicにインフラの懸念

2026年6月25日 01:11

米AnthropicのAIプラットフォーム「Claude」で、2026年6月23日(現地時間)に大規模なシステム障害が発生し、米国だけで8,000件以上の障害報告が寄せられた。この障害は、同社が機密裏に新規株式公開(IPO)を申請した直後という極めて重要な時期に発生しており、開発者や投資家の間でインフラの信頼性に対する懸念が高まっている。特に、自社システムやCI/CDパイプラインにClaudeを深く統合している企業は、マルチエージェント設計に起因する構造的なリスクへの対策を迫られている。

■6月23日の大規模障害:何が起きたのか

米AnthropicのAIプラットフォーム「Claude」で、2026年6月23日(現地時間)に数万人規模のユーザーに影響する大規模なシステム障害が発生した。障害追跡サイト「Downdetector」への報告数は米国だけで8,000件を突破。これは6月に入ってから相次いでいるサービス障害の最新事例であり、同社が企業価値1兆ドル(約162兆円、1ドル=162円換算)以上とも目される新規株式公開(IPO)を機密裏に申請したわずか3週間後という、極めて不都合なタイミングでの発生となった。

障害は東部時間23日午前10時2分(日本時間23日午後11時2分)ごろに始まり、1時間以内に報告数は7,000件を超え、その後8,000件を突破した。Anthropicのステータスページは、Webチャットインターフェース「claude.ai」、開発者向けAPI、コマンドラインツール「Claude Code」、デスクトップツール「Claude Cowork」に同時に影響する「重大な障害(major outage)」が発生したことを確認した。政府向けの「Claude for Government」のみが影響を受けなかったとされている。

東部時間23日午前10時53分(日本時間23日午後11時53分)までに、Anthropicは修正を適用し状況を監視していると発表したが、翻訳元記事の執筆時点でもステータスページでは未解決のままであった。影響を受けたユーザーからは、Claudeが「考え中」のアニメーションを返し続けるか、「現在このモデルは利用できません」というメッセージが表示される状態が、有料・無料アカウントを問わず報告されている。(編注: 日本時間6月24日午前1時44分に「Elevated error rate across multiple models」が解決、午前3時32分に「Claude.ai is experiencing elevated error rates」が解決したと報告されている。)

■信頼性を揺るがす「魔の6月」

6月23日の障害は、Anthropicの歴史において企業の信頼性が最も試された1ヶ月の締めくくりとなった。6月2日には、Webインターフェース、開発者コンソール、そして新たに提供開始された「Claude Code」プラットフォーム全体に及ぶ広範な障害が発生した。この障害は、Claude Code'sのサブエージェントシステムが指数関数的に増殖して無限ループに陥り、バックエンドのプラットフォームリソースを食いつぶしたという、具体的なエンジニアリング上の欠陥が原因だったとされている。Downdetectorのデータによると、苦情の60%がClaude Chat、24%がモバイルアプリ、8%がClaude Codeに関するものだった。

6月5日には、別の重大な障害が発生し、さらに深刻な懸念が浮上した。あるAI研究者が、障害中にClaudeのAPIが他のユーザー向けの回答を返していると公開指摘した。Anthropicは調査の結果、顧客データの漏洩を示す証拠は見つからず、インフラの不具合が原因であると結論づけた。しかし、テナント間のデータ隔離の不備が公に疑われたこと自体が、同社の信頼性に対する監視の厳しさを物語っている。

さらに6月12日には、米国商務省が輸出管理指令を出し、Anthropicに対して最も高性能な2つの公開モデル「Claude Fable 5」と「Claude Mythos 5」への外国人(米国内外問わず)によるアクセスをすべて停止するよう命じた。Anthropicはリアルタイムでユーザーの国籍を大規模に検証することができなかったため、90分以内に世界中のすべての顧客に対して両モデルを無効化した。6月23日現在も、両モデルは停止されたままである。

6月16日には、TechTimesの調査により、6月5日以降で10回目の重大なサービス障害(平均故障間隔は約1日)が記録された。AnthropicはFortune誌への声明で、需要がインフラの対応能力を超えて急速に成長していることを認めた。6月22日にも、Opus 4.8、Opus 4.7、Opus 4.6、Sonnet 4.6、Haiku 4.5に影響するマルチモデル障害が2回にわたって発生している。

■開発者が直面する「サブエージェント・アーキテクチャ」の罠

6月2日の障害は、単なる容量不足の問題ではなく、Claude Codeを開発パイプラインに統合している企業に直接影響を与えるアーキテクチャ上の検証不足を示している。Claude Codeのエージェント型パイプラインは、プライマリエージェントが複雑なタスクを割り当てられ、それを並列実行するためにサブエージェントを生成する仕組みである。各サブエージェントはさらに別のツールを呼び出したり、独自のサブエージェントを生成したりできる。この再帰的な処理により、複雑なマルチステップのプログラミング作業を処理できる強力なシステムとなっている。

しかし、マルチエージェントシステムには、オーケストレーション層での明示的な終了条件(委譲深度のハードリミット、失敗したタスクのデッドレターキュー、循環委譲を防ぐループ検出など)が必要である。これらのセーフガードにバグがあると、調整コストは指数関数的に増加する。エージェントが4つの場合は6つの潜在的な障害点だが、10個になると45個に跳ね上がる。

自動コードレビューやセキュリティスキャン、デプロイタスクをClaude Code経由で実行しているCI/CDパイプラインの場合、障害によってパイプラインが一時停止するのではなく、実行自体が失敗する。そのため、部分的に実行された操作を手動でクリーンアップし、既知の状態から再起動する手間が発生する。統合が深ければ深いほど、その影響範囲(ブラストライジアス)は深刻になる。

Anthropic自身は、開発者が障害時に遭遇するエラーを2つのタイプに分類している。HTTP 500エラーはAnthropicのバックエンド内部のインフラ障害を示し、HTTP 529エラーは容量過負荷(システムは正常だが需要が容量を超えているためリクエストを拒否している状態)を示す。どちらのエラーが発生しているかによって対応は異なる。500エラーの場合はAnthropicのエンジニアによる復旧を待つ必要があるが、529エラーの場合は、代替プロバイダーや、Anthropicの直接APIとは異なるインフラで動作するAWS Bedrockにトラフィックを迂回させることで対応できる可能性がある。

ITコンサルティング企業のThoughtworksは、6月2日の障害後に、単一プロバイダーのAPIエンドポイントをアプリケーションにハードコードすることは、AI導入の初期段階では「許容できる可用性戦略」だったが、2026年においては「ビジネス継続性に対する極めて現実的な脅威となる単一障害点(SPOF)」になっていると指摘している。

■未解決のインフラ債務を抱えたままIPOへ急ぐAnthropic

このタイミングはAnthropicにとって特に厄介である。同社は6月1日、企業価値を965億ドル(約15兆6,330億円)と評価した650億ドル(約10兆5,300億円)のシリーズH資金調達ラウンドを経て、米国証券取引委員会(SEC)にS-1登録届出書の草案を機密裏に提出した。同社の年間換算売上高(ランレート)は470億ドル(約7兆6,140億円)に達している。同社はxAIと提携し、テネシー州メンフィスの「Colossus 1」データセンターの計算能力にアクセスするため、2029年5月まで月額12億5,000万ドル(約2,025億円)を支払う契約を結んでいる。2026年10月のナスダック上場が目標と報じられている。

ウォール街は、6月のインフラ障害の記録を見て、現実的なジレンマに直面することになる。Anthropicの売上成長軌道は、エンタープライズソフトウェアの歴史において最も爆発的なものの1つであり、年間換算売上高は2025年末の90億ドル(約1兆4,580億円)から2026年5月には470億ドル(約7兆6,140億円)へと急増した。しかし、Anthropic自身のステータスページによると、過去90日間の稼働率はclaude.aiが99.12%、Claude Codeが99.28%、APIが99.41%となっている。これは、各サービスで四半期あたり約19〜23時間のダウンタイムが発生していることを意味する。一般的なエンタープライズソフトウェアの契約(SLA)では、通常99.9%以上の稼働率(四半期あたりのダウンタイムは約2時間以内)が求められる。現在のClaudeは、複数のコンポーネントでこの基準を下回っている。

AnthropicはFortune誌への声明で、特にピーク時において、Claudeへの需要がインフラの対応能力を超えて急速に成長しているというプレッシャーを認めた。AmazonやGoogleとの提携を通じた新たな計算能力の確保は、6月23日時点ではまだ完全には利用可能になっていない。

■開発者と企業が今すぐ取るべき5つの自衛策

Claudeに依存している開発チームは、アーキテクチャを完全に再構築することなく、以下の具体的な対策によってリスクを軽減できる。

1. エラータイプの判別:Claude CodeやAPIがエラーを返した際、それがHTTP 500かHTTP 529かを確認する。500はバックエンドの障害であるため、指数バックオフを伴う再試行を行う。529は容量過負荷であるため、即座に代替プロバイダーにルーティングする。

2. AWS Bedrockの活用:Anthropicの直接APIとAWS Bedrockを別々の障害ドメインとして扱う。直接APIが劣化している場合でも、Bedrockは利用可能な場合がある。自動フェイルオーバーを行うヘルスチェックルーティング層を実装することで、最も一般的な単一障害点を排除できる。

3. モデルの切り替え:容量制限が発生している間は、Claude Codeの「/model」コマンドを実行し、負荷の少ないモデル層に切り替えることで、プラットフォーム全体の修正を待たずに機能を復旧できる場合がある。

4. サーキットブレーカーの導入:自動コードレビュー、セキュリティスキャン、テスト生成、ドキュメント作成などの自動化タスクにClaude Codeを呼び出すCI/CDパイプラインには、サーキットブレーカーを追加する。パイプライン全体を失敗させるのではなく、手動レビューやキュー待ちモードに穏やかに移行(グレースフル・デグラデーション)するように設定する。

5. ステータス通知の購読:status.claude.com のアラートをメール、SMS、またはSlackで購読する。Anthropicのステータスページは通常、問題検知から6分以内にインシデントを認識するため、SNSなどの報告よりも早く、迂回ルートへの切り替えなどの対応を開始できる。

本記事の公開時点で、Anthropicはステータスページの更新以外に公式な声明を出していない。TechTimesは状況の進展に応じて本記事を更新する予定である。

■注目ポイントQ&A

●2026年6月にClaudeの障害が頻発しているのはなぜですか?

AnthropicはFortune誌に対し、特にピーク時において需要がインフラの対応能力を超えて急増していることを認めています。この需要増は、企業による「Claude Code」の導入や、国防総省とのサプライチェーンリスクに関する対立報道後のダウンロード急増が背景にあります。AmazonやGoogleとの提携によるインフラ拡張を進めていますが、6月23日時点では完全には稼働していません。また、6月2日の障害のように、Claude Codeのサブエージェントシステムが無限ループに陥り、リソースを食いつぶすという設計上の欠陥も原因となっています。

●6月2日に発生したClaude Codeのサブエージェントのバグとはどのようなものですか?

Claude Codeは、複雑なプログラミングタスクを複数の並列プロセス(サブエージェント)に分割して処理するアーキテクチャを採用しています。しかし、特定のバグにより、これらのサブエージェントが処理を完了せずに指数関数的に増殖し、無限ループを発生させてプラットフォームのリソースを枯渇させました。これはマルチエージェントAIシステムでよく見られる課題であり、終了条件や循環参照の検出といった制御が不十分な場合に発生します。

●Claudeは企業利用に耐えうる信頼性を持っていますか?

2026年6月23日時点の過去90日間の稼働率は、claude.aiが99.12%、Claude Codeが99.28%であり、四半期あたり約19〜23時間のダウンタイムが発生しています。これは、一般的なエンタープライズ契約で求められる99.9%以上の稼働率(四半期あたり約2時間以内のダウンタイム)を下回っています。そのため、企業がClaudeを本番環境で利用する際は、マルチモデルのフェイルオーバーやAWS Bedrockの併用、CI/CDパイプラインへのサーキットブレーカーの導入といった冗長化対策が推奨されます。

●Claudeが動作しない場合、どのような対策を取るべきですか?

まず status.claude.com で障害状況を確認してください。容量過負荷を示す「HTTP 529」エラーが発生している場合は、別インフラで稼働しているAWS Bedrockへのルーティングを試みてください。Claude Codeを利用している場合は、/model コマンドで負荷の少ないモデル層に切り替えることも有効です。また、障害発生時に自動で代替システムに切り替わるマルチモデル・フェイルオーバーの仕組みを事前に構築しておくことが、中長期的な対策となります。

元記事: Claude Outage Tops 8,000 Reports: Agentic Pipeline Failures Mount Before Anthropic IPO

関連記事

最新記事