特定のAIサービスを日々の業務に深く組み込むほど、そのサービスが止まったとき、あるいは料金や仕様が変わったときの影響は大きくなります。これは新しい話ではなく、クラウドサービス全般で以前から指摘されてきた「ベンダーロックイン」の問題です。生成AIの場合、業務への組み込み方によっては、この依存が一段と強くなりやすい面があります。この記事では、実際に起きた障害の事例と、企業幹部への調査データをもとに、この構造を整理します。

何が起きたか — 2025年6月のChatGPT大規模障害

2025年6月10日、ChatGPT、動画生成サービスのSora、APIを含むOpenAIの複数のサービスで、世界規模の障害が発生しました。海外メディアの報道によると、障害は米国東部時間の未明に始まり、応答が返ってこない、サーバーエラーが出るといった不具合が世界各地のユーザーから報告されました。OpenAIが修正を適用し復旧を確認するまでには10時間以上を要しています（出典：The Register「OpenAI experiencing global ChatGPT, Sora system degradation」、TechCrunch「ChatGPT is having a partial outage」、OpenAI公式ステータスページ）。

この障害そのものは、その後復旧しています。しかし、この一件は、業務のさまざまな場面でChatGPTやOpenAIのAPIを組み込んでいた企業にとって、「自社がコントロールできない外部要因で、業務が一時的に止まりうる」ことを具体的に示す出来事になりました。

調査データが示す依存の実態

複数サービスを連携させる自動化ツールを提供するZapierが、米国企業の経営幹部500人を対象に実施した調査があります。同社の発表によると、回答者の74%が、主要なAIベンダーへの依存について「日常業務に支障が出る」または「完全に依存している」と回答しました。この74%の内訳は、主要機能に支障が出るとした47%と、業務の大部分またはほぼすべてを特定のAIベンダーに依存しているとした27%の合計です。

同じ調査で注目すべきなのは、実際に別のAIプラットフォームへの移行を試みた企業のうち、スムーズに移行できたのは42%にとどまり、残る58%は「失敗した、あるいは想定よりはるかに多くの手間がかかった」と回答している点です。一方で、経営幹部の89%が「4週間以内に別のベンダーへ移行できる」と考えていました。実際の移行経験と見通しのあいだに差がある、という結果になっています（出典：Zapier公式ブログ「AI Vendor Lock-In Survey」https://zapier.com/blog/ai-vendor-lock-in-survey/ ）。

なお、この調査を実施したZapierは、複数のサービスを組み合わせて使う自動化ツールを販売している事業者であり、ベンダー依存のリスクを示すことに商業上の利害があります。独立した第三者調査ではない点は割り引いて読む必要があります。

なぜ起きるか

ベンダーロックインが起きやすい理由は、生成AIならではの事情がいくつか重なっています。

一つ目は、AIへの指示文（プロンプト）や、AIの出力を前提に組んだ業務フロー・社内ツールが、特定のサービスの挙動に最適化されてしまうことです。あるAIサービス向けに細かく調整したプロンプトや連携の仕組みは、別のサービスにそのまま移せるとは限りません。

二つ目は、社内のデータや過去のやり取りの蓄積が、特定のサービスのプラットフォーム内に閉じてしまうことです。ChatGPTのカスタムGPTや、特定のAIプラットフォーム上に構築した社内アプリケーションなどは、そのプラットフォームを離れると作り直しが必要になる場合があります。

三つ目は、こうした依存の度合いを、導入時点では正確に見積もりにくいことです。上記の調査でも、多くの企業が「いざとなれば乗り換えられる」と考える一方で、実際に移行を試みた企業では想定より手間がかかったという回答が多数を占めていました。

中小企業でも起こりうるか

起こり得ます。むしろ、複数のAIベンダーを並行して検証・比較する余力がない中小企業のほうが、一つのサービスに一本化しやすく、結果として依存度が高まりやすい面があります。

見積書の作成、問い合わせ対応、社内文書の下書きなど、複数の業務プロセスに一つの生成AIサービスを組み込んでいる場合、そのサービスに障害が起きる、あるいは値上げや仕様変更があったときの影響は、業務全体に及びます。バックアップの手段がなければ、障害の間は該当業務が完全に止まってしまう可能性があります。

避けるには

ベンダーロックインのリスクを完全になくすことは難しいものの、次の点を押さえておくと、依存による影響を小さくできます。

まず、AIサービスが止まった場合に、その業務を一時的にどう回すかを、あらかじめ決めておくことです。完全に自動化する前の、人の手による代替手順を残しておくと、障害時の影響を抑えられます。

次に、業務上重要な処理については、特定のサービスに固有の機能へ過度に依存しない設計を心がけることです。汎用性の高い形でプロンプトやデータを管理しておけば、将来的に別のサービスへ移行する際の負担を減らせます。

また、契約しているAIサービスの障害情報を確認できるステータスページを事前に把握しておき、障害発生時にすぐに状況を確認できるようにしておくことも、実務上の備えになります。

自社で確認すべきこと

自社の業務の中で、特定のAIサービスが止まった場合に、完全に停止してしまう業務がないかを洗い出してみてください。該当する業務があれば、そのサービスが数時間から半日程度使えなくなった場合の代替手順を、簡単でよいので用意しておくことをおすすめします。

あわせて、「今のAIサービスから別のサービスに乗り換えるとしたら、どのくらいの時間と手間がかかるか」を一度具体的に考えてみてください。上記の調査結果を踏まえれば、実際に試みると想定より難航する可能性は見込んでおいたほうがよさそうです。