生成AIを企業へ導入するとき、「どのモデルが最も優秀か」が議論の中心になりやすい。だが、検索支援や文書作成を越えて、受注、顧客対応、審査、調達、開発、サプライチェーンへAIが組み込まれるほど、先に問うべきことが変わる。
このAIを明日止めても、業務は安全に続けられるか。
これはAIを使わないための問いではない。AIを深く使い続けるための設計要件である。本記事ではこれを、モデル選択の能力に対してAIを外せる力、すなわち退出可能性（exit capability）と呼ぶ。
日本IBMが2026年8月に公表したIBV調査では、日本の回答者の89%が、ベンダー、AIモデル、インフラにまたがるAIの依存関係を十分に把握できていないと答え、69%が主要なAIベンダーやモデルの切り替えは難しいと答えた。これはIBMによる調査であって業界全体の確定値ではないが、依存関係の可視化と変更可能性が実務課題になっていることを示す材料である。日本IBMの調査発表
AIは「アプリ」から業務の配線へ変わる
社内文書の要約だけなら、AIが止まっても人が原文を読むことで仕事を続けられる。この段階のAIは、生産性を補助するツールである。
しかし利用が広がると、構造は変わる。
顧客のメール・音声・Web入力
↓
ワークフロー / エージェント
├─ 生成モデル
├─ 埋め込みモデル
├─ ベクトル検索
├─ 社内検索
├─ CRM・ERP・チケット
└─ ID・認可・監査
↓
業務記録・外部送信・更新処理
この状態では、AIは画面上の便利機能ではなく、業務プロセスを接続する配線の一部になる。すると、生成モデルだけを見ても意味がない。埋め込み、検索、ツール呼び出し、データ保存、認証、提供リージョン、契約、モデル更新までを、ひとつの依存グラフとして扱う必要がある。
まず分けるべきは「止まる」と「壊れる」である
AI依存には、少なくとも二種類の障害がある。
| 種類 | 例 | 従来監視だけでは見えにくい点 |
|---|---|---|
| 可用性の障害 | API停止、リージョン障害、レート制限、モデル廃止 | HTTP 5xxや遅延で検知できるが、後続業務への影響を別途追う必要がある |
| 意味的な障害 | モデル更新後の判定変化、出力形式の崩れ、ツール選択の変化 | APIがHTTP 200を返し続けても、業務上は誤作動する |
たとえば契約書の一次判定で、同じ入力がモデル更新前には「要法務確認」、更新後には「問題なし」となることがある。インフラの健全性だけを見ていれば正常だが、業務の判断品質は壊れている。
そのためAIには、可用性監視に加えて、代表的な入力を定期実行する評価と、業務KPIの監視が必要になる。
モデル・設定の変更
↓
Golden datasetによる回帰評価
↓
出力形式・根拠・安全性・費用・遅延の確認
↓
限定リリース
↓
業務KPIと例外率の監視
↓
基準逸脱時はロールバックまたは人手経路へ
「AIが応答した」ことではなく、「期待する品質と統制のもとで業務が進んだ」ことを可用性の条件にする。
APIを差し替えられても、業務を移せるとは限らない
あるモデルのAPIを別ベンダーのAPIへ置き換えられることと、移行後も業務品質を保てることは別だ。同じプロンプトでも、モデルが変われば出力内容、拒否のされ方、構造化出力、ツール選択、長文の扱い、レイテンシ、コストが変わる。
AIの可搬性は、次のように定義した方が実用的である。
業務品質、安全性、費用、権限境界を許容範囲に保ちながら、モデルまたは提供者を変更できること。
移行時に評価する対象は、チャットの流暢さだけではない。
- プロンプト、ワークフロー、RAG検索の再現性
- JSONなど構造化出力の妥当性
- ツール呼び出しの回数、引数、停止条件
- 個人情報・機密情報の送信先と保持条件
- 高影響判断での見逃し・誤検知
- 料金、遅延、利用上限、リージョン
- 監査ログと出力の追跡可能性
この評価資産を持たずに「代替モデルがあります」と言っても、実際には切り替えを試せない。
マルチベンダーは、代替可能性があって初めて冗長化になる
部門ごとに異なるAIを導入している企業は多い。しかし、営業が使うAIをマーケティングのAIへ、障害時に直ちに切り替えられないなら、それは冗長化ではない。依存先が増えているだけである。
IBMのグローバル調査では、回答組織の73%が意図的なマルチベンダー環境だと説明した一方、独立した部門判断や地域事情がベンダー多様化の大きな要因だったとされる。IBMの原発表
ここで目指すべきはmultiple vendorsではなく、重要な業務におけるinterchangeable pathsである。
業務アプリケーション
↓
AI Gateway / Policy Gateway
├─ データ分類・利用目的の確認
├─ モデル選定・費用上限・リージョン判定
├─ ツール実行の承認・宛先検証
└─ 実行記録の発行
↓
├─ 主系モデル
├─ 代替モデル
└─ AIを使わない縮退経路
Gatewayは万能の抽象化層ではない。すべてを共通APIへ押し込めれば、各モデルの強みや安全機能を捨てることにもなる。重要なのは、どの業務能力を共通化するか、どこでベンダー固有機能を許すか、その固有機能を失ったときの代替策は何かを明示することである。
「AIを外せる」を4種類のExitに分解する
退出可能性を一つの言葉で扱うと、対策が曖昧になる。設計レビューでは、少なくとも次の四つを分ける。
| Exit | 何を外すか | 代表的な確認 |
|---|---|---|
| Model Exit | モデル | 同じ業務テストで代替モデルが基準を満たすか |
| Vendor Exit | API、SDK、提供基盤 | データ、プロンプト、ログ、評価資産を移せるか |
| Infrastructure Exit | クラウド、リージョン、実行環境 | データ所在地、鍵、ネットワーク、運用手順を移せるか |
| AI Exit | AI処理そのもの | ルール、人手、読み取り専用などで業務を継続できるか |
最後のAI Exitが最も重要である。代替モデルに替えても、規制、広域障害、品質低下、セキュリティ上の停止判断により、AI全体を使えない場合があるからだ。
たとえば融資審査の補助AIなら、通常はAIで一次整理し、担当者が確認する。AI停止時には従来ルールと担当者の手順へ戻す。処理量や所要時間は落ちるが、審査を誤って自動確定せず、業務を続けられる。
これはAIを使わないことではなく、安全に縮退運転することである。
AI-BCPでは、人手へ戻す経路もテストする
AIのBCPは、障害時の連絡先リストでは終わらない。どの依存が失われたときに、どの能力を、どの品質で残すかを決める必要がある。
| 想定シナリオ | 最低限の確認 | 望ましい縮退策 |
|---|---|---|
| 主系LLM APIの停止 | 業務の停止範囲、切替時間、未処理データ | 代替モデルまたは担当者キューへ振り分ける |
| 埋め込み・検索の停止 | 根拠取得なしの回答を防げるか | 検索機能を停止し、原文参照または手動検索へ戻す |
| モデル品質の劣化 | 回帰評価・例外率で検知できるか | 旧版へロールバックし、高影響処理を人手確認へ切り替える |
| 料金・上限の急変 | 予算超過前に検知できるか | 低リスクの定型処理を小型モデル・バッチ処理へ寄せる |
| 提供地域・契約条件の変更 | 利用者、データ、業務への影響を把握できるか | 許可された環境へ移行するか、対象業務を停止・手作業化する |
この訓練では、フェイルオーバー先が「存在する」だけでは不十分だ。実際に代表入力を流し、権限、出力、データ整合性、監査ログ、利用者への表示、人手キューの処理能力まで確認する。切替先が未検証なら、それは復旧手段ではなく仮説にすぎない。
依存関係をAI版CMDBとして管理する
AIの依存は、モデル名の一覧だけでは管理できない。各業務について、少なくとも以下を紐付ける。
業務能力
└─ アプリケーション / エージェント / ワークフロー
├─ モデル・バージョン・提供者・リージョン
├─ 埋め込み・ベクトルDB・検索・データ保存先
├─ プロンプト・評価セット・ガードレールの版
├─ 呼び出せるツール・権限・承認者
├─ データ分類・保持・削除・契約条件
├─ SLO・費用上限・業務KPI
└─ 代替経路・縮退手順・責任者・最終訓練日
この台帳は、MLOpsだけの仕事ではない。構成管理、変更管理、調達、セキュリティ、データガバナンス、事業継続をつなぐITサービス管理の対象である。
特にエージェントは、回答だけでなくツールを使って下流システムを操作する。モデルを止めること、ツール実行を止めること、既に開始した処理を取り消すことを別々に扱い、外部への書き込みはモデルの文章ではなくポリシー層で許可・拒否する。
設計レビューで聞くべき10の質問
AIシステムのレビューで「精度は何%か」だけを問うべきではない。次の質問に答えられるかを確認したい。
- このAIが停止すると、どの業務能力がどの時点で止まるか。
- モデル、提供者、リージョン、AI全体を外す場合、それぞれの復旧経路はあるか。
- 代替経路は本番相当の代表入力でいつ検証したか。
- モデル更新による意味的な品質低下を、何で検知するか。
- プロンプト、検索、ツール、評価のどこにベンダー固有の依存があるか。
- データ、ログ、評価資産、鍵を別環境へ移せるか。
- 代替時にもデータ所在地、最小権限、承認、監査の条件を満たすか。
- AIなしで続ける場合の処理量、責任者、待ち行列、利用者への説明は決まっているか。
- 高影響の外部送信・更新を、AIの出力だけで実行できないようにしているか。
- Exit Planを最後に演習したのはいつか。
結論：Exit Capabilityは、新しいAIを入れる能力でもある
特定モデルへ強く結び付いた組織は、障害や価格変更に弱いだけではない。より良いモデルや新しい提供形態が登場しても、移行コストが高く、試せない。
反対に、依存を可視化し、評価資産と縮退経路を持つ組織は、必要なときに安全にモデルを外せる。そして同じ力で、新しいモデルを限定的に試し、根拠を持って採用できる。
AIを外せる力は、防御のためだけの能力ではない。変化の速いAIを、業務の責任境界を守りながら使い続けるための競争力である。
参照したURL
- IBMスタディ: AI主権の重要性が高まる中 コントロール不足と依存関係が企業リスクを増大 | 日本IBM
- IBM Study: Limited Control and Rising Dependencies Leave Enterprises Exposed in the Age of AI | IBM
作成日: 2026-09-02