ChatGPT障害に企業はどう備えるか｜生成AI依存業務のBCP設計

ChatGPTは高い稼働率を誇るサービスですが、完全に障害がゼロというわけではありません。個人利用であれば「しばらく待つ」で済みますが、業務プロセスにChatGPTを組み込んでいる企業にとって、障害は生産性の低下やサービス提供の遅延に直結するリスクです。本記事では、ChatGPTの障害発生の実態を踏まえ、企業として押さえておきたい事業継続（BCP）の視点を整理します。

ChatGPTの障害はどの程度の頻度で起きているか

まず、ChatGPTの稼働実態を客観的な数値で把握しておくことが、リスク評価の出発点になります。

稼働率の実態

OpenAI公式のステータスページによると、直近（2026年6月〜9月）の稼働率は、APIが99.94%、ChatGPT本体が99.63%程度となっています。数字だけを見ると非常に高い水準ですが、99.63%という稼働率は、月換算で数時間程度、何らかの障害や機能不全が発生していることを意味します。また、障害には「全ユーザーに影響する大規模障害」と「特定の機能・特定のユーザー層に限定された障害」があり、後者の方が発生頻度としては多い傾向にあります。例えば、無料ユーザーのみに影響する障害や、特定の推論モデルのみでエラー率が上昇する障害など、利用しているプランやモデルによって影響の有無が変わるケースも珍しくありません。なお、公式ページには、この稼働率はあくまで全体の平均値であり、個別ユーザーが実際に体感する可用性は契約しているプランや利用しているモデルによって異なる場合があるという注記もされています。稼働率の数値は公表期間によって変動するため、最新の状況はOpenAI公式のステータスページで確認することをおすすめします。

復旧までの時間の目安

過去の障害事例を見ると、小規模な機能障害は1〜2時間程度、中規模な障害は3〜6時間程度、大規模な障害では半日程度の復旧時間を要することがあります。例えば2025年6月には、ホストOSの定期アップデートに伴うネットワーク管理サービスの再起動が原因で、ChatGPTのエラー率がピーク時で約35%まで上昇し、API可用性も約75%低下するという、グローバル規模の障害が発生しました。この障害は発生から解決まで約15.5時間を要しており、一つのシステム変更が長時間にわたる広範な影響を及ぼしうることを示す代表的な事例といえます。障害発生時に影響を受けるコンポーネント（機能単位）は、ChatGPT、API、Codexなど複数に及ぶことがあり、公式のインシデント報告では「影響を受けたコンポーネント数」という形で範囲の広さが記録されています。

障害情報を早期に把握する体制

障害発生時に素早く状況を把握できるかどうかが、業務への影響を最小限に抑える鍵になります。

OpenAI Statusページの監視

OpenAIは公式のステータスページ（status.openai.com）で、ChatGPT・API・Codexといった各サービスの稼働状況をリアルタイムに公開しています。緑色の「All Systems Operational」であれば正常稼働、オレンジであれば一部機能の低下、赤であれば深刻な障害を意味します。ChatGPTのUI自体は稼働していてもAPIだけが不調というケースもあるため、自社が利用している経路（Web版か、API経由の自社システム組み込みか）に応じて、該当する項目を確認する習慣が重要です。企業によっては、このステータスページの変化を自動的に検知し、社内のチャットツールに通知する仕組みを構築しているケースもあります。ステータスページ下部の「Incident History」では、過去のインシデントの発生原因や影響を受けたコンポーネント、復旧までの経緯が記録として残っているため、自社の障害対応方針を検討する際の参考資料としても活用できます。

SNS・サードパーティの監視サービスの補完的な活用

公式ステータスページの更新が実際の障害発生から遅れて反映されることもあるため、SNS上での言及状況や、障害報告を集計するサードパーティの監視サイトをあわせて確認することも有効です。同じ症状を報告する投稿が短時間に多数集まっていれば、全体的な障害である可能性が高いと判断できます。逆に、報告がごく少数であれば、自社の通信環境やアカウント側の問題である可能性を疑う材料になります。こうした複数の情報源を組み合わせることで、障害かどうかの切り分けにかかる時間を短縮できます。

社内エスカレーションフローの整備

障害を検知した際、誰が状況を確認し、誰に報告し、どのタイミングで代替手段への切り替えを判断するのかという役割分担を、あらかじめ決めておくことが望まれます。特に、ChatGPTを組み込んだ業務システムを顧客向けに提供している場合は、顧客への影響が及ぶ前に、社内での状況共有と対応方針の決定を迅速に行える体制が不可欠です。

生成AI依存業務のリスクを洗い出す

障害への備えを検討する前提として、自社のどの業務がどの程度ChatGPTに依存しているかを可視化しておく必要があります。

業務停止インパクトの棚卸し

社内の各部署でChatGPTを使っている業務を洗い出し、それぞれの業務がChatGPTなしでどの程度の期間・影響で継続可能かを評価します。例えば、社内文書のドラフト作成のように、代替手段（人力での作業）にすぐ切り替えられる業務であれば、数時間の障害が発生しても業務への影響は限定的です。一方、カスタマーサポートのチャットボットやAPI経由で自社サービスに組み込んでいる機能のように、ChatGPTの可用性がそのままサービス品質に直結する業務は、優先的にリスク対策を検討すべき対象になります。

障害時の代替手段の準備

生成AIへの依存度が高い業務については、障害時にどのような代替手段を取るかをあらかじめ決めておくことが有効です。具体的には、一時的に手動運用へ切り替える手順の整備、あるいは後述する複数ベンダーのAIサービスを併用し、片方に障害が発生しても業務を継続できる構成を検討することが考えられます。特に顧客向けサービスに組み込んでいる場合は、障害発生時にユーザーへどのようなメッセージを表示するか、あらかじめ準備しておくことも重要です。

プラン別の補償・SLAの違い

契約しているプランによって、障害時の補償やサポート体制には違いがあります。

個人向けプランでの障害時対応

OpenAI公式のステータスページやインシデント報告には、障害発生時にユーザーへクレジットや返金を付与する旨の記載は確認されていません。公式に明記されているのは、稼働率はあくまで全体の平均値であり、個別ユーザーが実際に体感する可用性は契約プランや利用モデルによって異なる場合がある、という点です。過去に個別の障害対応としてクレジットが付与されたという情報も一部で見聞きすることがありますが、これは契約上保証されたSLA（サービス品質保証）ではなく、公式情報として体系的に確認できるものではない点に留意が必要です。API利用については、実際の利用量に基づく従量課金のため、障害で使えなかった分の課金は基本的に発生しませんが、それ以上の補償が保証されているわけではありません。障害時の補償に関する正確な取り扱いは、契約時にOpenAIの利用規約や契約条件を確認することをおすすめします。

Enterprise向けSLAの有無

大規模組織向けのEnterpriseプランでは、優先サポートや、より手厚いサービス保証が提供される場合があります。ミッションクリティカルな業務でChatGPTへの依存度が高い企業は、契約プランごとのサポート内容・補償条件を事前に確認し、必要に応じてEnterpriseへの移行や、OpenAIとの個別契約交渉も選択肢として検討する価値があります。

複数ベンダーでのAI活用によるリスク分散

特定の生成AIサービス1つに業務を全面的に依存する構成は、そのサービスに障害が発生した際の影響を大きくしてしまいます。ChatGPTに加えて、他のAIベンダーのサービスも併用できる設計にしておくことで、片方に障害が発生してももう片方で業務を継続できる、可用性の高い構成を実現できます。特にAPI経由で自社システムに組み込んでいる場合は、システム側で複数のAIプロバイダーへ切り替え可能な設計にしておく、いわゆるマルチベンダー構成を検討する企業も増えています。

ただし、複数ベンダーを併用する場合は、それぞれのサービスでデータの取り扱いポリシーが異なる点に注意が必要です。障害対応のためだけに、セキュリティ要件を満たしていないサービスへ切り替えることのないよう、平時のうちに複数の選択肢を評価・承認しておくことが重要です。あわせて、モデルごとに出力の傾向や得意分野が異なるため、緊急時の切り替え先として選定したサービスが、通常時に使っているChatGPTと同等の品質でその業務をこなせるかどうかも、事前の検証段階で確認しておくべきポイントです。こうした準備を平時から進めておくことで、障害発生時に慌てて代替手段を探すのではなく、あらかじめ検証済みの選択肢へ落ち着いて切り替えられる体制を整えられます。

よくある質問（FAQ）

Q. ChatGPTの障害はどのくらいの頻度で起きていますか？

OpenAI公式のステータスページによると、直近期間の稼働率はChatGPT本体で99.63%程度、APIで99.94%程度とされており、月換算で数時間程度、何らかの障害や機能不全が発生している計算になります。全ユーザーに影響する大規模障害よりも、特定の機能やユーザー層に限定された障害の方が発生頻度としては多い傾向にあります。稼働率は公表時期によって変動するため、最新の数値は公式ステータスページで確認してください。

Q. 障害が発生しているかどうかはどこで確認できますか？

OpenAI公式のステータスページ（status.openai.com）で、ChatGPT・APIなど各サービスの稼働状況をリアルタイムに確認できます。あわせて、SNSでの投稿状況や、障害報告を集計するサードパーティサイトも参考になります。

Q. 障害でChatGPTが使えなかった場合、補償はありますか？

OpenAI公式のステータスページやインシデント報告には、障害発生時のクレジット付与や返金について明確に記載されたものは確認されていません。公式に示されているのは、稼働率が全体平均であり、個別ユーザーの体感可用性は契約プランや利用モデルによって異なりうるという注記のみです。API利用分については、使えなかった分の課金は発生しませんが、それ以上の補償については契約条件を個別に確認することをおすすめします。

Q. 顧客向けサービスにChatGPTを組み込んでいる場合、何を準備すべきですか？

障害検知時のエスカレーションフロー、代替手段への切り替え手順、そして障害発生時にユーザーへ表示するメッセージなどを、あらかじめ準備しておくことが望まれます。特にAPI経由での組み込みは、Web版とは別に障害状況を確認する必要があります。

Q. 複数のAIベンダーを併用することにリスクはありますか？

可用性の観点ではリスク分散になりますが、ベンダーごとにデータの取り扱いポリシーが異なるため、障害時にセキュリティ要件を満たさないサービスへ切り替えてしまわないよう、平時のうちに複数の選択肢を評価・承認しておくことが重要です。

Q. 過去にはどのような障害事例がありましたか？

例えば、ホストOSの定期アップデートに伴うネットワーク管理サービスの再起動が原因で、ChatGPTのエラー率が最大約35%まで上昇し、APIの可用性も大きく低下するグローバル規模の障害が発生し、解決まで約15.5時間を要した事例があります。障害の影響範囲は、ChatGPT・API・Codexなど複数のコンポーネントに及ぶことがあり、公式のインシデント報告で確認できます。

まとめ

ChatGPTの稼働率は高い水準にあるものの、完全にゼロリスクではないため、業務での依存度に応じたBCP設計が企業には求められます。

まずは自社でChatGPTに依存している業務を洗い出し、障害発生時の影響度と代替手段の有無を確認するところから始めてみてください。