目次
生成AIは、いまや文章作成・コーディング・調査・要約まで日々の作業に深く食い込んでいる。便利になるほど、ある問いが重くなる——「もし明日、そのAIが使えなくなったら？」。これは机上の不安ではない。2026年6月、登場からわずか3日で最上位モデルが全ユーザー停止になる出来事が実際に起きた。
本記事では、AI依存リスクとは何か、どんな形で「使えなくなる」のか（6類型）、そして個人と本番システムの両面で、いつ止まっても困らないための具体的な備え方を整理する。前提知識がなくても読めるように書き、後半は開発者向けの冗長化設計まで踏み込む。
単一のAIに頼り切らない
— 「止まる前提」で設計すれば、止まっても困らない
1つのモデルに全依存
停止・廃止・値上げ・品質変化が起きた瞬間、業務がそのまま止まる「単一障害点」。
予測ではなく設計で守る
「いつ止まるか」を当てるのではなく、「止まっても切り替わる」形にしておく。
代替・冗長化・自衛
代替モデルの用意、データとプロンプトの自分側保管、切替手順の事前準備。
1. AI依存リスクとは？——「便利すぎる」ことの裏側
AI依存リスクとは、特定のAIサービスやモデルに業務・生活を強く依存した結果、それが使えなくなった／変わった／高くなったときに大きな打撃を受ける状態を指す。怖いのは「AIが間違える」ことより、むしろ「昨日まで動いていたAIが、今日は手元にない」という不連続だ。
クラウド経由の生成AIは、便利な反面、提供のオン/オフが自分の手の外にある。あるメディアはこれを「あなたのAIベンダーは、いまや単一障害点（single point of failure）だ」と表現した。電気や水道のように当たり前に使えると思っていたものが、規制・経営判断・障害で一夜にして止まりうる——これがAI時代の新しい依存リスクだ。
💡 ポイント：依存そのものが悪いわけではない。問題は「代わりがない」依存。代替手段を1つ持つだけで、リスクは「致命傷」から「不便」へと格下げできる。
2. 実際に起きた：Fable 5・Mythos 5が一夜で消えた
2026年6月12日、Anthropicは最上位モデルClaude Fable 5とMythos 5へのアクセスを全ユーザーで停止した。米政府の輸出管理命令への対応で、両モデルは6月9日に公開されたばかり——登場からわずか3日での全面停止だった。アプリ・API・クラウド経由を問わず、無料・有料の区別もなく「どの入口からも使えない」状態になった。
この記事の執筆時点（2026年6月下旬）でも両モデルは停止が続いている。Anthropicの幹部は6月中旬に「近日中に再開する」と述べたが、公式ステータス上はまだ復旧しておらず、再開時期は流動的だ。詳しい経緯は Fable 5・Mythos 5 利用停止の記事 にまとめている。
🚨 この出来事の教訓：止まったのは「品質が悪かったから」ではない。規制という、性能とは無関係の理由で、最高性能のモデルが一夜で消えた。つまりどんなに優秀なAIでも、停止リスクはゼロにできない。
Fable 5は氷山の一角だ。実は2026年は、各社が旧モデルを次々に退役（リタイア）させた年でもある。停止・廃止は「特別な事件」ではなく、AIを使う以上つきあい続ける常態のリスクになりつつある。
3. 依存リスクの6類型
「AIが使えなくなる」と一口に言っても、起き方はさまざまだ。備えを考える前に、まずどんな形で困るのかを6つに分けて押さえておく。
① 突然の停止
規制・安全保障・法的トラブルなどで、予告なく提供が止まる。Fable 5が典型。最も対策が間に合いにくい。
② モデルの廃止（退役）
新モデルへ移行するため旧モデルが計画的に終了。事前通知はあるが期限が来れば必ず止まる。指定し続けると動かなくなる。
③ 値上げ・課金体系の変更
料金改定・無料枠の縮小・プラン廃止。サービスは生きているのに採算が合わなくなり使えなくなるパターン。
④ 品質の変化・無断変更
同じモデル名でも挙動が変わる／安全制限が強まる。「昨日のプロンプトが今日は通らない」。気づきにくいのが厄介。
⑤ 障害・レート制限・BAN
サーバー障害、使用量上限、アカウント停止。一時的でも、その瞬間は確実に止まる。
⑥ ベンダーロックイン
特定社の独自機能・形式に深く合わせ込み、他社へ移れない状態。①〜⑤が起きたときの「逃げ場」を自分で塞いでしまう。
①〜⑤は「外から降ってくる」リスク、⑥は「自分で作り込んでしまう」リスクだ。前者は完全には防げないが、⑥を避けておくだけで、いざというときの被害は大きく減る。
4. まず「自分の依存度」を測る
備えの第一歩は、買い物ではなく棚卸しだ。専門家の助言も「まず自社のAI依存の連鎖を冷静に洗い出すこと」で一致している。次の3つを書き出してみると、自分（または自社）の依存マッピングができる。
何に依存しているか
どのサービス・どのモデルを、どの作業で使っているか。アプリ・API・組み込み機能を全部リストアップ。
止まると何が困るか
「これが無いと回らない」作業と「無くても何とかなる」作業を仕分ける。重要度×代替の難しさで優先順位を。
無くなったらどうするか
各依存に「代わりの手」を1つ決めておく。別モデル・手作業・一時停止のどれで凌ぐかを先に決める。
このとき大事なのは、「最高性能が必要な作業」と「そこそこで十分な作業」を分けること。多くの日常業務は最上位モデルでなくても回る。最上位に頼るのは本当に必要な一部だけにしておくと、その一部が止まったときの影響範囲が小さくなる。
5. 個人ユーザーの備え（5つ）
システムを作らない一般ユーザーでも、今日からできる備えがある。要は「AIに預けっぱなしにしない」習慣だ。
代替を1つ持っておく
普段Claudeなら、ChatGPTやGeminiの無料枠も触っておく。いざというとき「使い方が分かる代わり」が1つあるだけで安心感が違う。
成果物は自分側に保存する
大事な出力やチャット履歴は、サービス内に置きっぱなしにせずローカルやドキュメントに残す。サービスが止まれば、中の履歴ごと見られなくなることがある。
効くプロンプトを「資産」として残す
うまくいったプロンプトはメモにストック。多くは別のAIでもほぼそのまま使える。財産は「AIの中」ではなく「自分の手元」に貯める。
「AI無しでもできる」を保つ
最終判断・事実確認・文章の良し悪しを見抜く力は自分に残す。AIに任せきりにしないことが、止まったときの最大の保険になる。
機密は預けない・分散する
業務の核心情報を1社にすべて流し込まない。入力時の注意を守り、止まっても・漏れても困らない範囲で使う。
6. 本番システム・開発者の備え（冗長化設計）
AIをサービスやアプリに組み込んでいる場合、備えは「習慣」から「設計」へ上がる。鍵は「特定モデルにハードに結びつけない」こと。以下は効果の大きい順に並べた実践だ。
(1) 抽象化レイヤ（LLMゲートウェイ）を挟む
アプリから各社APIを直接叩くのではなく、間に共通の入口（ゲートウェイ）を1枚かませる。こうすると、モデルの切替が設定変更だけで済む。代表的な選択肢は次の通り。
LiteLLM
自前ホスト型。ゼロ・ベンダーロックインを重視する人向け。フォールバック連鎖やリトライ、タイムアウトを細かく設定でき、データ主権も保てる。運用は自分持ち。
OpenRouter
1つのAPIキーで多数のモデル・プロバイダにアクセス。インフラ管理が不要で、モデル配列を渡せば順に試すフォールバックも簡単。試作・評価に向く。
コード側でプロバイダを抽象化するライブラリ。アプリのコードを変えずにモデルを差し替えられる。Web/アプリ開発との相性が良い。
✅ 移行は意外と軽い：主要なゲートウェイは「OpenAI互換API」を備えるものが多く、多くの場合変えるのは接続先URLとAPIキーだけ。既存コードはほぼそのまま動く。今のうちに1枚かませておくのが、最もコスパの良い保険だ。
(2) フォールバック連鎖を組む（ただし必ずテスト）
「第一候補が落ちたら第二候補、それも駄目なら第三候補」と自動で切り替わる連鎖を定義しておく。多くのゲートウェイはモデル名ごとにフォールバック先・リトライ・タイムアウトを設定できる。
⚠️ 落とし穴：フォールバックは「必要になる前に試す」こと。設定したつもりで実は発火しない・静かに失敗する構成は、フォールバックが無いより悪い（障害に気づけない）。平時に意図的に主モデルを止めて、ちゃんと切り替わるか確認しておく。
(3) 層を分ける——AIは「外せる部品」にする
システムを2つの層に分けて考える。AIに置き換えてはいけない部分を、AIから独立させておくのがコツだ。
下書き・要約・提案
AIが止まっても、ここが無いだけ。生産性は落ちるが業務は続けられる、という設計にする。
データ・台帳・業務システム
自分の管理下に置き、外部AIに依存させない。AIが消えても本業のデータと処理は生き続ける。
(4) ローカルLLMという最後の砦
クラウドが全滅しても手元で動くローカルLLMを1つ用意しておくと、ネットワーク障害・API停止・規制のいずれにも効く。最高性能ではなくても、「最低限ここまではAI無しにならない」というラインを自分の中に持てる。機密データを外に出せない用途とも相性が良い。
(5) 復旧手順書（プレイブック）を1枚作る
いざ止まったとき、慌てて調べ始めると復旧が遅れる。「主モデルが落ちたら → このコマンドで代替へ切替 → 関係者へこの文面で連絡」という手順を1枚にまとめておくだけで、復旧までの時間（MTTR）が「数日」から「数時間」へ縮む。年に一度は実際に切替訓練をしておくと、いざというとき確実に動く。
7. ベンダー選びのチェックポイント
そもそもどのサービスを選ぶかの段階で、依存リスクは大きく変わる。性能や価格だけでなく、「止め方が誠実か」を見ておきたい。各社の廃止ポリシーには差がある。
⏳ 廃止の事前通知期間
公開モデルの廃止前に、どれだけ猶予をくれるか。Anthropicは60日以上、OpenAIは正式版で6ヶ月以上の事前通知を掲げる。ただしプレビュー版は2週間程度と短いこともあり、試験版への依存は要注意。
🔔 変更の透明性
仕様変更・制限をユーザーに見える形で告知するか。「黙って品質を下げる」運用は依存先として危険。告知・移行ガイド・ステータスページの整備状況を見る。
🗄️ 退役後の救済
退役したモデルへの配慮があるか。例えばAnthropicはモデルの重みを長期保存し、退役後も一部モデルを申請ベースで利用可能にすると表明している。こうした姿勢は移行の安心材料になる。
📌 注意：通知期間やポリシーは各社とも改定される。導入前に必ず公式の「モデル廃止（deprecation）」ページで最新値を確認すること。本記事の数値は2026年6月時点の目安だ。
まとめ
AI依存リスクへの備えは、3行に集約できる。
- 現実だと知る：Fable 5の例が示すとおり、最高性能のAIでも規制・経営・障害で一夜にして止まりうる。停止・廃止は常態のリスク。
- 予測ではなく設計で守る：「いつ止まるか」を当てるのは無理。「止まっても切り替わる／困らない」形にしておくのが正解。代替を1つ、抽象化レイヤを1枚、復旧手順を1枚。
- 資産は自分側に：データ・プロンプト・判断力を「AIの中」ではなく「自分の手元」に貯める。⑥ベンダーロックインを避けるだけで、いざというときの逃げ場が残る。
AIは強力な道具だが、道具は時に手元から消える。消えても本業が止まらないように設計しておく——それが、AIを安心して深く使い込むための土台になる。
FAQ
Q. 結局、どのAIを使うのが一番安全ですか？
A. 「1社だけ」を選ぶ発想自体がリスクです。安全なのは特定のサービスではなく、いつでも別のAIに切り替えられる状態です。普段使いを1つ決めつつ、代替を最低1つ触れる状態にしておくのが現実的な最適解です。
Q. 個人で趣味に使うだけでも備えは必要ですか？
A. 軽くで十分です。最低限「大事な成果物はローカルに保存」「効いたプロンプトはメモに残す」の2つだけでも、サービスが止まったときの損失をほぼ防げます。本格的な冗長化は仕事で使う場合の話です。
Q. モデルの「廃止（deprecation）」と「停止」は違うのですか？
A. 廃止は新モデルへ移行するための計画的な終了で、通常は数十日〜数ヶ月の事前通知があります。一方Fable 5のような停止は予告なく突然起こりえます。前者は移行で対処、後者は冗長化で備える、と切り分けると分かりやすいです。
Q. 複数のAIに対応すると、コストや手間が増えませんか？
A. 抽象化レイヤ（LLMゲートウェイ）を1枚挟めば、対応コストは大きく下がります。多くがOpenAI互換APIなので、切替は接続先とキーの変更程度。常時2社を動かすのではなく、「いつでも切り替えられる」準備だけしておけば、平時の手間はほぼ増えません。
Q. ローカルLLMがあればクラウドAIは要らない？
A. 役割が違います。ローカルLLMは性能で最上位のクラウドに及ばないことが多いですが、「絶対に止まらない最後の砦」として価値があります。普段はクラウド、非常時はローカル、という二段構えが現実的です。
