事業継続・ベンダー依存リスク管理

動き始めてから効いてくる論点

本章で扱うのは、導入時には見えにくく、稼働してから効いてくるリスクです。使っているAIサービスが停止したら業務はどうなるか。モデルが廃止されたら何が必要になるか。値上げされたら断れるのか。

これらは技術の問題ではなく、依存の設計の問題です。そして依存は、便利さと引き換えに増えていきます。何も設計しなければ、依存は自然に深まります。

本章は第17章(ベンダー・契約管理)と対になります。本章がリスクの構造と技術的な備え、第17章が契約上の手当てを扱います。

ベンダーロックインの構造

ロックインは「乗り換えられない状態」を指しますが、実際には段階があります。自社がどの段階にいるかを把握することが最初の作業です。

段階が上がるほど乗り換えの費用が増えます。重要なのは、段階を上げることが常に悪いわけではない点です。独自機能を使うことで効果が大きく上がるなら、それは正当な選択です。問題は、段階を上げていることを認識せずに進むことです。

意識的に管理する方法

• 抽象化の層を1つ挟む ― AIの呼び出しを自社のコードで包み、モデルやサービスの指定を1箇所にまとめます。切り替えの作業量が大きく下がります(第13章)。
• プロンプトと検証セットを自社で保持する ― これらは移行可能な資産です。ベンダー側の管理画面だけに置かないようにします。
• データの取り出し方法を導入時に確認する ― 取り出せる形式と、それにかかる作業を把握しておきます。
• 依存の段階を記録する ― どのサービスがどの段階かを一覧にし、年1回見直します。

サービス障害時の事業継続計画

クラウドのAIサービスは、障害で停止することがあります。停止時間はSLAで一定水準が保証されますが、保証は「起きない」ことではなく「起きたときに利用料が返る」ことです(第17章)。業務を止めない設計は自社側で行う必要があります。

停止時の影響を分類する

すべての処理に同じ備えは不要です。影響で分類します。

1番目の区分に入る処理では、手作業への切り替え手順が実際に動くかを確認しておく必要があります。手順書があっても、担当者が実行できなければ機能しません。年1回でも訓練を行う価値があります。

設計上の具体的な備え

• タイムアウトと再試行 ― 応答がない場合の待ち時間と再試行回数を決めます(第4章)。
• 縮退運転 ― AIが使えない場合に、簡易な処理(定型文の返信、ルールベースの判定)に切り替える経路を用意します。
• キューによる滞留 ― 処理を待ち行列に入れ、復旧後に順次処理する構成にします。
• 状態の把握 ― サービスの稼働状況を確認する経路(提供元の稼働情報)を運用手順に含めます。
• 通知 ― 障害が起きたときに誰に通知されるかを決めます(第13章)。

モデル廃止・仕様変更・値上げへの対応

クラウドのAIサービスでは、モデルの世代交代が定期的に起こります。これは障害より高い頻度で発生する変化です。

3つの変化と、それぞれの備え

実務で最も影響が大きいのは2番目です。モデル名を固定していても、内部の更新で出力が変わることがあります。これに気づく方法は1つで、検証セットを定期的に流して結果の変化を見ることです(第14章)。この仕組みがないと、精度の低下に数か月気づかない状態になります。

移行の作業量を事前に把握する

モデルを変更する際に必要な作業は、決まっています。導入時に一覧化しておくと、実際の移行時に判断が速くなります。

1. 検証セット(業務の実データと期待する出力の組)で新モデルを評価する
2. プロンプトの調整(モデルによって効く指示が違う)
3. 出力形式の差異への対応
4. 費用の再計算(トークンの数え方が違う場合がある)
5. 応答時間の再確認(既存のタイムアウト設定に収まるか)
6. 本番反映と、一定期間の並行運用

1番目の検証セットが存在しないと、移行の是非を判断できません。検証セットは、モデル移行の際に最も価値を持つ資産です。

複数モデル・マルチクラウド運用による分散

依存を分散させる手段ですが、費用と複雑さが増えるため、目的を明確にして採用します。

分散が有効な場合

• 処理の種類ごとにモデルを分ける ― 定型処理は小さいモデル、複雑な判断は推論モデル。費用最適化と分散が同時に進みます(第2・13章)。
• 業務の重要度で分ける ― 停止が許されない処理だけ、代替経路を確保します。
• データの機密度で分ける ― 機密度の高い処理は自社環境、それ以外はクラウド(第1章)。

分散が過剰になる場合

• すべての処理に代替経路を用意する(検証の工数が2倍になります)
• 複数のサービスを同時に呼び出して結果を比較する(費用が倍増します)
• 目的を決めずに「マルチクラウドにする」(複雑さだけが増えます)

実務的な判断は、停止が許されない処理を特定し、そこだけ二重化することです。全体を二重化する必要はありません。

ベンダーの事業継続性の見極め

提供元そのものが継続するかという問題です。AI関連は新しい事業者が多く、この観点が必要になります。技術的な性能とは別に確認する項目を挙げます。

• 事業の実態 ― 提供している事業の内容、顧客数、公表されている実績。
• 資本と提携の状況 ― 主要な出資者、提携先。上場企業であれば公開情報が確認できます。
• 基盤の所在 ― モデルを自社開発しているのか、他社のモデルを再提供しているのか。後者の場合、上流の変更の影響を受けます。
• サポート体制 ― 問い合わせの経路と応答実績。障害時の連絡手段。
• 終了時の措置 ― サービス終了時のデータ返還・移行支援が契約に書かれているか(第17章)。

とくに3番目は見落とされます。特定のAIサービスが、実際には別の事業者のモデルを再提供している構成は珍しくありません。この場合、上流の値上げ・廃止・仕様変更が、そのまま影響します。契約前に構成を確認してください。

依存の管理を運用に乗せる

最後に、継続的に管理するための最小限の仕組みを挙げます。年1回の見直しで足ります。

1. 使用しているAIサービスの一覧を作る ― 部署ごとに独立して契約している場合、一覧が存在しないことがあります(第12章のシャドーIT)。
2. 各サービスの依存段階を記録する ― 前掲の5段階のどこにあるか。
3. 停止時の影響区分を記録する ― 即時に業務が止まるか、当日中でよいか、数日待てるか。
4. 検証セットの有無を確認する ― ない処理には作る。移行と品質監視の両方に使えます。
5. 契約上の要点を一覧にする ― データ取り出し、移行期間、終了時措置、値上げの通知期間。
6. 年1回、代替候補の費用を確認する ── 交渉の材料にもなります。

この6項目は、規模の大小に関わらず作れます。一覧が存在すること自体が、依存の無自覚な深まりを防ぎます。