目次
- 3時間の沈黙が突きつけた問い
- 何が起きたのか：2024年6月4日のタイムライン
- 推論負荷の構造的な脆さ
- クラウド帯域というもう一つのボトルネック
- 容量設計の実務：4つの論点
- ベンダーSLAの読み方と落とし穴
- 編集部の所感：止まる前提の設計へ
- まとめ
3時間の沈黙が突きつけた問い
2024年6月4日、米国西海岸時間の早朝、ChatGPT・API・Playgroundが同時に応答を停止した。OpenAI公式ステータスページ（status.openai.com）によれば、障害は午前6時51分（PT）に検知され、復旧までおよそ3時間を要した。世界中の企業ユーザーが、生成AIに依存した業務フローの脆さを同時に突きつけられた瞬間である。
この障害は、サービス単体の不具合として処理すべきではない。編集部の取材では、影響を受けた国内SaaS企業の運用担当者から「カスタマーサポート用のチャットボットが全社停止し、コールセンターに着信が集中した」「請求書OCRワークフローが詰まり、月次締めが半日遅延した」といった証言が複数寄せられた。生成AIが基幹業務の一部として組み込まれた現在、ベンダー側の障害は即座に自社のオペレーション停止に転化する。
Gartnerは2024年の調査で、生成AIを本番業務に組み込んでいる企業の比率を55%と報告している（Gartner, 2024年5月発表）。PoC段階を脱した企業ほど、単一ベンダーへの依存度が高まる構造的リスクを抱えている。AI導入の意思決定責任者にとって、2024年夏の障害は「容量設計」と「フォールバック設計」を経営アジェンダに引き上げる契機となった。
何が起きたのか：2024年6月4日のタイムライン
OpenAIが公開した障害レポートをもとに、事実関係を時系列で整理する。
- 6月4日 06:51 PT：ChatGPT、API、Playgroundの3サービスで「Elevated errors」が検知される
- 6月4日 07:33 PT前後：影響範囲が「major outage」に格上げ、ほぼ全リクエストが失敗する状態に
- 6月4日 09:50 PT前後：段階的な復旧を確認、サービス再開
- 影響時間：約3時間（OpenAI公式声明、status.openai.com 履歴より）
OpenAIは障害の原因について「インフラストラクチャの問題」と説明したが、詳細な技術的内訳は限定的にしか公表されていない。同社のステータスページでは、過去12か月で複数回の大規模障害が記録されており、2024年だけでも複数のmajor outageが発生している。
注目すべきは、ChatGPT（コンシューマー向け）とAPI（法人向け）が同時に停止した点である。同一インフラ上に両者が相乗りしている構造が示唆され、企業ユーザーにとっては「コンシューマー需要のスパイクが法人SLAに波及するリスク」が顕在化した。Microsoft Azure OpenAI Service経由で利用する企業は、Azure側の冗長構成によって一部影響が緩和されたケースもあったが、OpenAI本体のモデル推論に依存する以上、根本的な独立性は確保しにくい。
Uptime Instituteの2024年版グローバルデータセンター調査では、重大な障害の55%が10万ドル以上の損失をもたらし、16%は100万ドル超に達したと報告されている。3時間の停止が経営インパクトに直結する時代に、AI推論サービスもまた例外ではなくなった。
推論負荷の構造的な脆さ
なぜ生成AIサービスは止まりやすいのか。編集部の取材と公開情報を突き合わせると、推論負荷の特性そのものに構造的な脆さがあることが見えてくる。
第一に、GPU資源の非弾力性である。CPUベースのWebサービスはオートスケールで秒単位の需要変動を吸収できるが、NVIDIA H100やA100クラスのGPUは調達リードタイムが長く、瞬間的なスケールアウトが難しい。NVIDIAの2024会計年度決算では、データセンター向け売上が前年比217%増の475億ドルに達した（NVIDIA, 2024年2月発表）。需要が供給を恒常的に上回る市場では、ベンダー側も計画キャパシティの限界で運用せざるを得ない。
第二に、コンテキスト長の増大によるメモリ圧迫である。GPT-4 Turboの128Kトークン、Claude 3の200Kトークンなど、長文コンテキストへの対応が標準化したことで、1リクエストあたりのGPUメモリ消費量が急増した。同時実行可能なリクエスト数（バッチサイズ）が減り、ピーク時の待ち行列が伸びやすい構造になっている。
第三に、マルチテナント環境のノイジーネイバー問題である。SemiAnalysisの分析によれば、推論サービスのコスト効率はバッチ処理に大きく依存し、特定顧客の大規模ジョブが他テナントのレイテンシを劣化させる事例が報告されている。企業向けプランで「優先処理」を謳うサービスも、根本的な物理リソース制約からは逃れられない。
国内のあるFinTech企業のCTOは、編集部の取材に対し「PoC段階では1日あたり数千リクエストだったものが、本番では10万リクエストを超えた。レート制限と429エラーへの対応設計を最初から組み込んでおくべきだった」と振り返る。429 Too Many Requestsは生成AI運用における最頻出エラーの一つであり、容量設計の前提として組み込まれるべきものだ。
クラウド帯域というもう一つのボトルネック
推論GPU以上に見落とされがちなのが、クラウド間の帯域コストである。RAG（検索拡張生成）構成では、ベクトルDB・LLM API・アプリケーションサーバーが異なるリージョン・異なるベンダーに分散することが多く、データ転送量が想定を超えるケースが頻発している。
AWSの公開価格表では、リージョン間データ転送が1GBあたり0.02ドル、インターネット向けエグレスは1GBあたり0.09ドル（最初の10TB）と設定されている（AWS料金, 2024年時点）。RAGで長文コンテキストをLLMに送信し、結果を返す往復が積み重なると、月間データ転送費がコンピュートコストを上回る事例も珍しくない。
a16zが2023年に公開した分析「The Economic Case for Generative AI」では、生成AIサービスの粗利率が従来SaaSの60-80%に対して50-60%にとどまる構造を指摘している。帯域コストとGPU従量課金が利益率を圧迫する構造は、自社プロダクトでAIを提供する企業にとっても他人事ではない。
加えて、障害時のフェイルオーバートラフィックが帯域を一気に押し上げる点も見過ごせない。プライマリのLLMベンダーが落ちた瞬間、セカンダリへの切り替えで突発的なリクエスト集中が発生し、セカンダリ側のレート制限に抵触するという二次災害が、2024年の障害でも観測された。容量設計はプライマリ単体ではなく、フォールバック先を含めたエコシステム全体で見積もる必要がある。
容量設計の実務：4つの論点
ここからは、編集部が複数の導入企業への取材を通じて整理した、容量設計の実務的な論点を4つ提示する。
1. ピーク係数の現実的な見積もり
業務系AIアプリケーションのトラフィックは、月次締め・四半期決算・キャンペーン期間などに集中する。平均値ではなくピーク値の3〜5倍を想定したキャパシティ計画が現実的である。OpenAIのレート制限はTier制で段階的に引き上げられるため、ピーク到達前のTier昇格申請が必須となる。
2. マルチベンダー・マルチモデル戦略
OpenAI・Anthropic・Google・Azure OpenAIなど、複数ベンダーへの分散はリスク低減の基本である。ただし、プロンプトの互換性は完全ではなく、モデル切り替え時の品質劣化を許容できるかが論点となる。重要度の低いタスクから順に切り替えるティアード・フォールバック設計が有効だ。
3. キャッシュとプリコンピュート
頻出クエリのキャッシュ、ベクトル検索結果のプリコンピュート、プロンプトテンプレートの固定化により、推論回数そのものを削減する。Anthropicのプロンプトキャッシング機能では、キャッシュヒット時のコストが最大90%削減されると公表されている。
4. 障害時の業務継続シナリオ
LLMが完全停止した場合の業務継続手順を、机上演習レベルで準備する。「ルールベースへの一時切り替え」「人手対応への切り戻し」「ユーザー向けメンテナンス通知の自動化」など、運用フローの整備がSLA以上に重要だ。
ベンダーSLAの読み方と落とし穴
主要ベンダーのSLAを比較すると、「99.9%」という数値が業界標準となっているが、その内訳には注意が必要だ。
Azure OpenAI ServiceのSLAでは、月間稼働率99.9%を下回った場合の返金クレジットが規定されているが、これはサービス料金の25-100%の返金であり、業務停止による逸失利益を補償するものではない。3時間の停止で発生する売上機会損失と返金クレジットは桁が違う。
また、SLAの計算除外条項として「不可抗力」「ユーザー側の構成エラー」「ベータ機能」などが列挙されており、実際にクレジット適用される範囲は限定的だ。編集部が確認した範囲では、過去のmajor outageでSLAクレジットが自動付与されたケースは稀であり、企業側からの申請が必要となる運用が一般的である。
調達担当者は、SLA数値よりも以下の項目を契約交渉時に確認すべきだ。
- 複数リージョン展開の可否と追加コスト
- キャパシティ予約（Provisioned Throughput）の最小単位と価格
- 障害通知のSLA（検知から通知までの時間）
- データレジデンシーと障害時の越境ルーティング許容範囲
Anthropicは2024年にProvisioned Throughputに相当する優先処理オプションを企業向けに拡充しており、ピーク需要への備えとして検討に値する。
編集部の所感：止まる前提の設計へ
取材を通じて編集部が痛感したのは、「AIは止まる」という前提が経営層に十分浸透していない現実である。クラウドが止まる、ネットワークが落ちる、データセンターが障害を起こす——インフラ運用の常識として受容されてきたリスク認識が、生成AIサービスに対してはまだ更新されていない。
McKinseyが2024年に公表したAI導入の現状調査では、生成AIを利用している組織は65%に達したが、AI関連リスクに対する正式なガバナンスを整備しているのは18%にとどまった。容量設計・障害対応・ベンダーリスク管理は、技術部門だけでなく経営企画・法務・調達を含む横断的な体制で検討すべきテーマである。
2024年夏の3時間は、生成AIが「実験」から「インフラ」へ移行する過渡期に起きた象徴的な障害だった。次の障害は確実に来る。問題はそのときに「想定外でした」と説明するか、「想定内でした」と報告できるかの違いだ。容量設計は、その分水嶺に位置する経営判断である。
まとめ
- 2024年6月4日のOpenAI障害は約3時間、ChatGPT/API/Playgroundが全世界で停止した
- 推論負荷はGPU資源の非弾力性、長文コンテキスト、マルチテナント構造により本質的に脆い
- クラウド帯域コストとフェイルオーバートラフィックが二次的なボトルネックを生む
- 容量設計はピーク係数、マルチベンダー、キャッシュ、業務継続シナリオの4軸で組み立てる
- SLA「99.9%」の返金は逸失利益を補償しない。契約交渉では複数リージョン・キャパシティ予約・障害通知SLAを確認する
- 「AIは止まる」を経営の前提に据えた組織が、次の障害を「想定内」に変えられる
関連記事
- AI導入失敗回避ジャーナル（無料購読） — 週次配信
- 無料相談を予約 — 編集部があなたのAI導入をサポート