基盤モデルが突然止まったらどうするか ー AI主権とBCPがコールセンターの論点になった
2026年6月12日、米商務省がAnthropicの先端モデル（Fable 5・Mythos 5）を輸出管理の対象とし、これに依存していた企業が一斉にアクセスを絞られた。措置は月末に解除され、7月1日に全面復旧したが、IBMの2026年調査はこの約3週間の空白を、単一のAIモデルの上に基幹業務を組んだすべての企業にとっての運用リスクの実例として記録している。コンタクトセンター（コールセンター）も例外ではない。一次応対の自動化を1つのLLMに寄せた瞬間、そのモデルが止まれば電話もチャットも道連れになる。基盤モデルが突然使えなくなったとき、自社のセンターは何分で代替に切り替えられるのか。私の立場を先に言えば、AI主権とBCP（事業継続計画）は、もう情報システム部門の専門論ではなく、センター運営そのものの設計要件になった。
1. コールセンターのAI依存は、もう数字で見える段階に入った
まず、依存の深さが定量的に見え始めた。IBM Institute for Business Valueが2026年2〜4月に世界の経営層1,000人へ行った同調査によれば、主要なAIベンダーやモデルの切り替えが難しいと答えた企業は71%、自社のAI依存関係を完全に把握できていると答えた経営層はわずか9%だった。さらに、AIスタック全体で最も強い制御を持つ組織は、AI起因の混乱から守れる営業利益が他社より55%多く、経営層の72%は「複数のAIベンダーを維持できるなら20%のコスト増を受け入れる」と回答している。柔軟性に対価を払う意思は、すでに数字として存在する。
比較対象を置くと相場観がつかみやすい。この構図は、かつて語られたクラウドやCRMのベンダーロックインとよく似ている。ただし決定的に違うのは、乗り換えの難しさが「移行工数」だけでなく「外部要因で突然止まる」側に寄っている点だ。輸出管理という一夜の政策判断でアクセスが消える種類のリスクは、従来のSaaS移行論には無かった。異変はすでに稼働率にも出ている。Wall Street Journalが報じた稼働率では、ある大手モデルベンダーのAPI稼働率は90日間で98.95%と、確立したクラウド事業者が掲げる99.99%を下回っていた。数字だけ見れば小さな差だが、昼夜を問わず動き続ける一次応対に置き換えると、月に数時間の「AIが応答しない時間帯」が構造的に生まれる計算になる。
2. なぜ単一LLM依存は起きるのか ー 「止まる理由」は3層ある
なぜセンターは1つのモデルに寄ってしまうのか。理由は単純で、API1本で組み始められる手軽さにある。最初はPoCとして1社のモデルで応答フローを作り、そのモデル固有の言い回しや出力形式にプロンプトとRAG（社内文書を検索して回答に使う仕組み）を最適化していく。使い込むほど、他社モデルへ移した時に応答品質が揃わなくなり、乗り換えコストが静かに積み上がる。電力を1系統からしか引いていない工場が、停電に丸ごと弱くなるのと同じ構造だ。
そのうえで、AIが「止まる理由」は1層ではない。第一に、輸出管理・地政学のような政策要因。第二に、インフラ層の障害だ。2025年11月18日のCloudflareの大規模障害では、設定不具合を起点にChatGPTやSoraを含む多数のサービスが同時に落ちた。モデル自体が健全でも、その手前のネットワークやゲートウェイが倒れれば応対は止まる。第三に、商業条件の変更。料金体系の転換やプラン改定で、昨日まで前提だったコストや利用枠が変わることもある。センターにとって重要なのは、これらが「モデルの賢さ」とは無関係に発生し、賢いモデルを選んでも消えないという点だ。
3. 継続性を設計する型 ー フェイルオーバー・リージョン・出口
ここまでの整理を、センターで使える型に落とすと3つになる。
型1: 抽象化層とmulti-LLMフェイルオーバー。アプリとモデルの間にルーティング層を1枚挟み、429（レート制限）や5xx（サーバーエラー）、モデル不可用を検知したら別プロバイダへ自動で流す。複数プロバイダのフェイルオーバー設計の考え方では、単一のプロバイダ・単一のリージョン・単一の経路に依存しないことが前提になる。効く理由は明快で、どこか1層が倒れても応対が全滅しないからだ。ただし、この型はタダではない（詳細は4章で自己反証する）。
型2: multi-region・ソブリンクラウド。モデルの冗長化だけでなく、データの所在地とリージョンの冗長性も継続性の一部になる。CCaaS大手のNiCEは2026年7月1日、CXoneをAWS European Sovereign Cloudへ拡張したと発表した。これはAWSが欧州域内で運用する独立クラウドで、データレジデンシーと運用主権を要件とする公共・金融・医療向けに位置づけられている。
インフラがどこにあるかは、もう調達書類の奥に埋もれた話ではない。CX TodayがNiCE World Londonの取材で指摘したように、それはCX AIの購買判断そのものに組み込まれ始めている。国内センターにとっても、EU顧客対応やグローバル製品の採用が絡む場面では、モデルの精度より先にデータの置き場所を問う流れがここから来る。
型3: 撤退時データ返還と可搬性の契約。継続性は、平常時の冗長化だけでなく「出口」でも決まる。AIベンダーの契約チェックリストが筆頭に挙げるのは、データ可搬性の「範囲」だ。多くの契約は解約時に「顧客データ」の書き出しを約束するが、問題はその定義にある。埋め込みや検索インデックス、会話の履歴、エージェントに蓄積した記憶といった、運用の中で積み上がったデータほど、明示的に、あるいは契約の沈黙によって対象外にされがちだという。同チェックリストは、システムが運用中に生成した顧客固有の状態を、派生形・中間形まで含めて「顧客データ」と定義し直すことを修正要求の基本形として求めている。会話ログ・要約・学習させたナレッジが返ってこなければ、乗り換えの自由は絵に描いた餅になる。
4. 見立て ー センター選定の質問が「賢さ」から「止まった時」へ移る
ここからは私の見立てとして書く。2026年後半のコールセンターAI選定では、問うべき質問が変わる。「このAIは賢いか」「解決率は何%か」に加えて、「止まったとき何分で代替に切り替わるか」「撤退時に会話ログとナレッジは、どの形式で何日以内に返ってくるか」が、契約前のチェック項目に並ぶ。継続性を語れないベンダーは、規制産業のセンターから順に選外になっていくと見る。
もっとも、この見立てには反証がある。冗長化はタダではない。モデルを複数持てば、応答トーンや要約の癖がモデルごとに違い、同じ問い合わせでもKPIがばらつく。プロンプトとRAGを二重にメンテし、品質評価も二重化する運用コストがかかる。IBM調査で72%が20%のコスト増を許容すると答えたとはいえ、利益率の薄いセンター運営でそれを丸ごと負担できるかは別の問題だ。だから現実解は「全部を冗長化する」ではない。本番の一次応対や録音要約のように、止まると顧客対応が直接止まる業務に冗長化を絞り、社内向けの分析やレポート生成のように多少止まっても困らない業務は単一構成のまま残す。この仕分けができて初めて、AI主権は投資として成立する。
まとめ
第一に、輸出管理による約3週間のアクセス停止、90日で98.95%という稼働率、大規模インフラ障害の連鎖という3つの実例が、単一LLM依存の継続性リスクを可視化した。第二に、AIが止まる理由は政策・インフラ・商業条件の3層にまたがり、モデルの賢さを選んでも消えない。第三に、対策の型はmulti-LLMフェイルオーバー・ソブリンクラウド・撤退時データ返還の3つで、冗長化に値する業務を仕分けることが投資成立の条件になる。あなたのセンターは、基盤モデルが明日の朝に止まったとき、何分で切り替わり、撤退時に何日で自社のデータを取り戻せる契約になっているだろうか。
注記: 本記事の事実関係は2026年8月3日時点で各出典URLを確認したものです。稼働率・調査数値は報道・調査機関の公表値に基づく整理であり、ベンダーの継続性能力を優劣評価するものではありません。個別の契約・BCP設計は専門家への相談を推奨します。見立てのパートは筆者個人の見解です。
出典
- IBM「IBM Study: Limited Control and Rising Dependencies Leave Enterprises Exposed in the Age of AI」
- BusinessWire「NiCE Extends Its AI-Powered Customer Experience Solution to AWS European Sovereign Cloud」
- Amazon Web Services「European Digital Sovereignty」
- CNBC「Cloudflare says outage that hit X, ChatGPT and other sites is resolved」
- The Decoder「The AI industry is running out of compute, with outages, rationing, and rising GPU prices」
- CX Today「NiCE World London 2026: Sopra Steria, AWS and CX AI Trust」
- Maxim AI「Failover Routing Strategies for LLMs in Enterprise AI Applications」
- AgentMode AI「AI vendor exit clauses: the 2026 procurement red-flag checklist」
この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。
