使っていたAIが急に使えなくなる理由はなぜか｜中小企業のAI調達リスクとベンダー依存の備え方

昨日まで普通に使えていた生成AIが、ある朝とつぜん開かない。画面が真っ白になる、ログインできない、あるいは「このサービスは終了しました」と表示される。
こうした場面は、もう珍しいことではなくなりました。

大事なのは、慌てて全部を乗り換えることでも、逆に「うちは大丈夫」と何もしないことでもありません。止まる前に何を備え、止まったら何日で代替へ切り替えるかを、先に決めておくことです。
この記事では、生成AIが急に使えなくなる仕組みと、中小企業が現実的にできる調達リスクの減らし方を、判断軸と手順の形でまとめます。

急に使えなくなったAIは「障害」か「終了」か

「使ってるAIが急に使えない、なぜ」と感じたとき、最初にやることは原因の切り分けです。同じ「使えない」でも、数分で戻るものと、二度と戻らないものが混ざっているからです。
ここを取り違えると、対応がまるごとずれます。

まず切り分ける順番

原因は大きく分けて、サービス側の障害、自社の通信トラブル、アカウントや利用上限の問題、そしてサービス自体の終了の4つです。
見る順番を決めておくと、数分で当たりを付けられます。

確認する順番	見る場所	そうだった時の動き
サービス側の障害か	公式ステータス・公式X	復旧を待ち、急ぎは代替へ一時退避
自社の通信か	他サイトが開くか	回線・社内ネットワークを確認
アカウントか	支払い・利用上限・ログイン	請求や上限、権限を見直す
サービス終了か	公式お知らせ・規約改定通知	移行を実行(下記タイムライン)

多くのケースは上の3つ、つまり障害・通信・アカウントのどれかで、これらは待つか設定を直せば戻ります。問題は4つ目で、ここだけは時間をかけるほど不利になるため、早く気づくほど打ち手が増えます。

生成AIが「終わる」4つの類型

恒久的に使えなくなるパターンは、整理すると4つの類型に分けられます。どれも予兆の出方が違うので、自分が使っているサービスがどれに当たりやすいかを知っておくと監視しやすくなります。

• モデル廃止: 使っていたモデルが退役し、後継へ自動で切り替わる(予兆=公式の廃止予定ページ・事前通知)
• 事業撤退: 採算や戦略転換でサービスごと終了(予兆=機能更新の停止・新規受付停止・公式発表)
• 買収・統合: 別の会社に吸収され、提供条件やブランドが変わる(予兆=買収報道・提供主体の変更告知)
• 規制・提供条件の変更: 規約改定や地域提供の見直しで使い方が変わる(予兆=規約改定通知・当局の動向)

実際に起きた「終わり」

これは想像の話ではありません。たとえばOpenAIは、動画生成サービスのSoraについて2026年3月24日に提供終了を告知し、アプリとWeb版を2026年4月26日に、APIを2026年9月24日に終了しました。
報道や解説では1日あたり約100万ドル(約1.5億円)規模の運用費がかかっていたとされ、人気と採算が釣り合わなかった撤退の例として語られています。

出典: OpenAI Help Center「Soraの提供終了について知っておくべきこと」

画像生成でも同じことが起きています。Googleは画像生成のImagen 4(standard/ultra/fast)を2026年8月17日に終了予定とし、後継のGemini 3.1 Flash Imageへの移行を案内しています。
モデルの退役はもっと頻繁で、主要ベンダーは旧モデルを定期的に引退させており、ChatGPTでのモデル退役と自動切替のように、表示が変わるだけでなく既存の使い方に影響が出ることもあります。

なぜ生成AIは突然終わるのか

「終売 終了 どうする」と検索する前に、なぜ生成AIがこれほど終わりやすいのかを押さえておくと、予兆の読み方が変わります。理由は技術と事業の両面にあります。

モデルには寿命があり、廃止予定が公式に組み込まれている

意外に知られていませんが、AIモデルにはあらかじめ寿命が設計されています。たとえばAnthropicは、モデルの状態をActive・Legacy・Deprecated・Retiredの4段階で管理し、廃止(Deprecated)の時点で推奨後継モデルと退役日を割り当てます。
そして公開モデルについては退役の少なくとも60日前に通知すると明言しています。

出典: Anthropic公式ドキュメント「Model deprecations」(英語)

裏を返せば、退役日を過ぎたモデルへのリクエストは失敗します。つまり「終わり」はサービス側の事故ではなく、最初から運用に組み込まれた仕組みなのです。
これは中小企業にとって、悪い話ばかりではありません。終わる時期がある程度わかるなら、公式の廃止予定を見にいけば予兆を先回りで拾えるということでもあります。

採算・競争・規制という3つの力

事業の側にも、終了を後押しする力があります。1つ目は採算で、先のSoraのように、利用者が多くても運用コストに見合わなければ畳まれます。
2つ目は競争で、提供主体が大手に吸収されたり、料金や条件が一方的に変わったりします。

3つ目は規制です。公正取引委員会は2026年4月16日に生成AIに関する実態調査報告書ver.2.0を公表し(ver.1.0は2025年6月)、クラウドとの抱き合わせや、巨大IT企業によるアクセス制限が競争上の懸念になりうると整理しました。
利用者の選択肢が狭まる構造そのものに、国の監視が入り始めているということです。

出典: 公正取引委員会「生成AIに関する実態調査報告書ver.2.0について」(2026年4月16日)

こうした値上げや条件変更への備えは、ベンダーの選び方そのものとも関わります。AIベンダー選定で見直すべき判断軸のように、「乗り換えにくさ」を契約前に意識しておくことが、後の選択肢を守ります。

自社は今「1社依存」か、調達リスクの自己診断

「AIの1社依存は危ない」と言われても、自社が依存しているのかどうかは意外と見えていません。まずは現状を棚卸しして、依存の度合いを具体的に測るところから始めます。

依存度を測る観点

診断は30分もあれば足ります。やることは、社内で使っているAIサービスを全部書き出し、それぞれにどの業務がどれだけ乗っているかを印で付けるだけです。
見落としやすいのが、社員が個人契約で使っているシャドー利用なので、経費やカード明細も合わせて確認します。

• 使っているAIを全部書き出す(無料・個人契約・拡張機能も含める)
• 各サービスに乗る業務を基幹・補助・お試しの3段階で印付け
• 1つ止まると複数の基幹業務が同時に止まるサービスを特定する
• そのサービスに入れている機密データの種類を書き添える

「1つ止まると複数の基幹業務が止まる」サービスが見つかったら、そこが調達リスクの中心です。全社のAIを一度に二重化する必要はなく、まずはこの一点に対策を絞れば、限られた人手でも守りを固められます。
自社で整理しきれないときは、AI経営手帖の無料相談で棚卸しの観点だけでも一緒に並べると、論点がはっきりします。

「縛られている資産」と「持ち出せる資産」の棚卸し

ベンダーロックインとは、特定のベンダーの仕組みに深く依存して、他社へ乗り換えるのが難しくなる状態を指します。中小企業で問題になるのは大がかりなシステムよりも、日々ためているプロンプトや会話履歴、業務ナレッジが特定のAIの中に閉じ込められている状況です。

そこで、自社の資産を「特定AIに縛られている資産」と「いつでも持ち出せる資産」に分けて眺めてみます。会話履歴やプロンプトは持ち出せる形にしておけば、サービスが終わっても価値が残ります。
この線引きが、調達リスクを下げる第一歩になります。

止まる前に握っておく契約・通知期間・データ返還

終了に強い会社は、止まってから動くのではなく、契約や運用の段階で「終わるとき」を想定した条件を先に握っています。ここは個人プランか法人契約かで打ち手が変わります。

公式が出す「予兆」を監視する

前述のとおり、終了の多くは突然に見えて、実は公式ページで事前に告知されています。やるべきことはシンプルで、四半期に1回、使っているAIの廃止予定ページやリリースノート、公式お知らせを点検する運用を作ることです。
API連携している場合は、後継モデルの案内が出ていないかも合わせて確認します。

この点検を仕組みにしておくと、退役日の通知が来てから慌てる事態を避けられます。監視は担当を1人決めて、カレンダーに四半期の予定として入れておくだけで十分です。
継続的に見る体制があるかどうかが、終了への強さを分けます。

SaaS・API契約で確認する出口条項

法人契約や代理店経由で導入しているなら、契約や規約の出口の条件を確認しておきます。最低限おさえたいのは次の4点です。

確認する項目	なぜ大事か
終了の事前通知期間	何日前に知らせてくれるかで移行の余裕が決まる
データ返還の形式	CSVなど汎用形式で出せないと取り戻せない
移行の猶予・代替措置	終了後の引っ越し期間があるか
入力データの学習利用	機密の扱いとオプトアウトの可否

個人や小規模で月額プランを使っている場合は、規約は一方的に決まる前提で考えます。
その場合は条項を変える交渉より、エクスポートと代替先の確保という自衛に振り切るほうが現実的です。SLA(稼働率の保証)は目安として見つつ、過度に頼らない姿勢が安全です。

なお、データを汎用形式で取り戻せない契約は、それ自体がロックインです。導入前に「終わるときにデータをどう返してもらえるか」を一度確認しておくと、後の選択肢が大きく変わります。

ベンダーに縛られない資産の持ち方

調達リスクを根本から下げるのは、結局のところ「サービスが終わっても自社に残る資産」をどれだけ持っているかです。会話・プロンプト・業務ナレッジを、特定のAIに閉じ込めないようにします。

会話・データのエクスポート手順

主要なチャットAIには、公式のエクスポート機能があります。難しい作業ではなく、設定画面から数分で実行できます。

• ChatGPT: 設定(Settings)からデータコントロール(Data controls)を開き、データをエクスポート(Export data)を実行。登録メールに届くダウンロードリンクの有効期限は24時間
• Claude: 設定(Settings)からプライバシー(Privacy)を開き、Export dataを実行。Web版とデスクトップ版で操作でき、モバイルアプリからは不可

出典: OpenAI Help Center「How do I export my ChatGPT history and data?」(英語ページあり)

注意したいのは、終了告知が出てからではアクセスできる期間が限られる点です。エクスポートは「いつでもできる」と後回しにしがちですが、重要な会話やナレッジは平時に定期的に取得しておくのが安全です。
月初に取得する、と決めておくだけでも違います。

プロンプトとナレッジを「モデル中立」で持つ

よく使うプロンプトを、AIのメモリ機能の中だけに溜めていませんか。その持ち方だと、そのAIが終わった瞬間に資産も消えます。
そこで、プロンプトは社内のドキュメントやスプレッドシートに台帳化して、どのAIでも使える形で持っておきます。

ここで知っておきたいのが、乗り換え時に同じプロンプトがそのまま通用するとは限らない点です。AIはモデルごとに設計や反応のクセが違うため、同じ指示文でも出力が変わります。だからこそ、プロンプトは丸ごと流用するのではなく、新しいモデル向けに微調整する前提で持っておくと移行がスムーズです。
業務ナレッジそのものも、AIの出力に頼り切らず、判断基準や手順を一次資料として残しておくと、どのツールに乗り換えても土台が崩れません。

1社に賭けない設計、マルチベンダーとAPI抽象化の現実解

「複数のAIを併用すれば安心」とよく言われますが、全業務で常に複数を並行させるのは、中小企業には運用負荷が重すぎます。大切なのは、どこまで二重化し、どこは使い分けで足りるかを見極めることです。

中小企業のマルチAI併用

調達のスタンスは、おおむね4つに整理できます。運用負荷・止まりにくさ・向く相手といった軸で並べると、自社に合うものが見えてきます。

スタンス	運用負荷	止まりにくさ	向く相手
1社集中	低い	低い	補助業務中心・お試し
用途別の使い分け	中	中	多くの中小企業
重要業務だけ二重化	中〜高	高い	基幹にAIが入る会社
API抽象化＋OSS併用	高い	高い	内製開発がある会社

現実的な落としどころは、重要業務だけを二重化し、それ以外は用途別に使い分ける形です。文章作成はこのAI、要約は別のAI、と分けておけば、1社が止まっても全滅は避けられます。
どのAIを主軸にして何を補完に回すかは、マルチAI時代の用途別の使い分けで整理した考え方が役立ちます。

API抽象化レイヤーとOSS・ローカルの位置づけ

自社システムにAIを組み込んでいる場合は、別の対策が要ります。特定ベンダーのAPIに直結していると、モデルの廃止や退役のたびにコード改修と障害が発生するからです。
ここで使えるのが、複数のAIを共通の窓口で扱えるAPI抽象化レイヤーです。LiteLLMやOpenRouterのような仕組みを挟むと、アプリのコードを大きく変えずにモデルを差し替えたり、障害時に別モデルへ切り替えたりできます。

機密度が極端に高い業務だけは、外部に出さないオープンソースやローカルのモデルも選択肢に入りますが、これは万能の安全装置ではありません。手段の自由度と、それを支える人手や体制が釣り合っているかを見たうえで選ぶのが現実解です。

終わると言われた日からの行動計画、AI版BCPと切替タイムライン

ここまでの備えを、いざ終了や大規模な障害が起きたときの動き方に落とし込みます。
災害に備える事業継続計画(BCP)と同じ発想で、2027年に向けた中長期の構えまで整理します。

終了発表から停止までの行動タイムライン

終了が発表されてから実際に停止するまでには、ふつう一定の猶予があります。その時間を、行き当たりばったりではなくあらかじめ決めた手順で使うことが、業務継続のカギになります。

タイミング	やること
発表当日	影響する業務を特定し、データをエクスポート、代替候補を1〜2個に絞る
数日以内	代替候補で同じ業務が回るか、重要プロンプトで最小テスト
1〜2週間以内	社内に「次はこれを使う」を周知し、簡易マニュアル化
終了日まで	データと履歴を全回収し、新サービスへ完全移行

1つ落とし穴があります。先のSoraのように、アプリの終了日とAPIの終了日が別になっていることがある点です。自社がどの経路で使っているかで締め切りが変わるので、必ず自分の使い方に対応する終了日を確認してください。
同じモデルでも、利用する経路によって終了日が違う場合があります。

2027年に向けた最小構成のAI-BCP

生成AIの入れ替わりは2027年に向けても続く見通しで、モデルの退役や提供条件の変更は、これからも定期的に起こると考えておくのが自然です。
とはいえ、中小企業が大がかりな計画を作る必要はありません。最小構成のAI版BCPを、年単位で少しずつ整えれば十分です。

• 依存業務の棚卸しを年1回更新し、基幹業務に乗るAIを把握する
• 会話・プロンプト・ナレッジをモデル中立な形で外部保管する
• 重要業務の代替候補を1つ決め、年に一度は実際に切り替えを試す
• 止まった時の行動タイムラインを手順書にし、担当を決めておく

この発想は、国が中小企業向けに用意している事業継続力強化計画とも重なります。これは経済産業大臣が認定する、取り組みやすい簡易版のBCPで、災害時に何をするかを先に決めておく仕組みです。
同じように、「使っているAIが止まったら何をするか」を一枚にまとめておくだけでも、いざという時の動きが大きく変わります。

出典: 中小企業庁「事業継続力強化計画」

FAQ