依存は説明されないまま深まる
ベンダーへの依存は、契約書に書かれた条件よりも、手元に何が残っているかで決まります。そして依存が深まっていく過程は、たいてい説明されません。
依存に関する情報は、提案の段階では出てきにくい性質があります。売る側にとって不利な情報であることに加え、提供側も上流の条件を把握していない場合があるためです。だから確認は買う側から行う必要があります。
型1 ― ロックインのリスクを軽視させる説明
依存の懸念を伝えたときに返ってくる説明の型を並べ、それぞれの確認方法を示します。
| 返ってくる説明 | 確認する質問 |
|---|---|
| 「標準的な仕組みなので移行は容易です」 | 移行の際に必要な作業を一覧で示してもらえますか |
| 「データはいつでも取り出せます」 | 取り出せる形式と、取り出しにかかる作業を具体的に教えてください |
| 「他社製品にも対応しています」 | 対応している範囲(全機能か一部か)と、切り替え時の再検証の範囲は |
| 「オープンな技術を使っています」 | 追加学習したモデルや調整した設定は持ち出せますか |
| 「そのような事例は聞いたことがありません」 | 移行を行った顧客の作業内容を確認できますか |
いずれも技術的な質問ではなく、作業の内容を具体的に示せるかを問う質問です。示せる場合、その内容が移行費用の見積もりになります。示せない場合、移行の難易度は不明として扱う必要があります。
型2 ― 「うちは潰れません」という安心材料
事業継続性についての説明が、根拠を伴わない形で行われることがあります。確認すべきなのは事業者の主張ではなく、確認可能な情報です。
- 事業の実態 ― 提供している事業の内容、公表されている顧客数や実績。
- 資本と提携の状況 ― 主要な出資者、提携先。上場企業であれば公開情報が確認できます。
- 基盤の所在 ― モデルを自社開発しているか、他社のモデルを再提供しているか。
- サポートの実績 ― 問い合わせへの応答実績、障害時の連絡手段。
- 終了時の措置 ― サービス終了時のデータ返還と移行支援が契約に書かれているか。
3番目が最も見落とされます。利用しているサービスの内側で、別の事業者のモデルがそのまま使われている構成は各所で見られます。この場合、事業者自身が健全でも、上流の値上げ・廃止・仕様変更がそのまま影響します。
加えて、上流の条件が変わった場合の責任の扱いを契約で確認してください。上流に起因する変更を事業者の責任外とする規定が含まれている場合、リスクは実質的に自社が負います(表の網羅版 第17章「ベンダー・契約管理」)。
型3 ― モデル廃止・値上げのリスクを契約時に説明しない
AIサービスでは、モデルの世代交代が定期的に起こります。障害より高い頻度で発生する変化です。
契約時に確認すべき項目を挙げます。いずれも規約または個別契約に記載されるべき事項です。
| 項目 | 確認すること | 示されない場合の意味 |
|---|---|---|
| モデル廃止の通知期間 | 何日前に通知され、移行期間はどれだけか | 短期間での対応を求められる可能性 |
| バージョン固定の可否 | 使用するモデルのバージョンを固定できるか | 更新で出力が変わるリスクを常に負う |
| 仕様変更の通知 | 同じモデル名のままの更新も通知されるか | 変化に気づく手段が自社の検証だけになる |
| 料金改定の通知期間 | 何日前に通知され、改定時に解約できるか | 値上げを受け入れるしかない状態 |
| 機能廃止の扱い | 使用中の機能が廃止される場合の措置 | 業務の再設計が必要になる |
3行目が実務では最も影響します。モデル名を固定していても、内部の更新で出力が変わることがあります。通知がない場合、気づく手段は検証セットの定期実行だけになります(表の網羅版 第14章「テスト・品質保証」)。
型4 ― 独占的な条項を忍ばせる
契約書に、他の事業者のサービスを併用できない条項が含まれている場合があります。表現は穏当なことが多く、見落としやすい項目です。
確認すべき条項の性質を挙げます。
- 競合するサービスの併用を制限する条項
- 本サービスを主たる手段として使用することを求める条項
- 最低利用量の設定(実質的に他への切り替えを困難にする)
- 長期契約と引き換えの値引き(切り替えの自由度が下がります)
- データの独占的な利用に関する条項
これらの条項があると、リスク分散の設計(重要な処理だけ二重化する等)が契約上できなくなります。値引きの条件として提示された場合は、分散の必要性と天秤にかけて判断します。
依存の懸念について、次の3点が確認できない場合は、依存の度合いに対してリスクが釣り合っていない可能性があります。(1) データを取り出せる形式と手順。(2) モデル廃止時の移行期間の長さ。(3) サービス終了時の措置。いずれも技術の話ではなく契約の話であるため、提案を受けている段階で照会しても差し支えありません。答えられない場合、その事業者自身が上流の条件を把握していない可能性があります。
型5 ― 深い依存を「統合の利点」として語る
依存が深まる構成には、実際に利点があります。統合された環境では設定が簡単で、機能間の連携も滑らかです。この利点は本物です。
問題は、利点だけが説明され切り替えの費用が示されないことです。判断には両方が必要です。
確認は次の形になります。
- 「この構成にすると、切り替える場合の作業はどう変わりますか」
- 「標準的な形式で使う構成と比べて、どの機能が追加されますか」
- 「その追加機能は、当社の用途で必要ですか」
3問目は自社で判断する内容です。追加機能が実際に必要であれば、依存の段階を上げることは正当な選択です。問題は、必要性を検討せずに深い構成を選ぶことです。
二年目の十一月下旬、朝凪精機に「コネクトAIアシスト」の更新の案内が届き、約4割の値上げが提示されました。乗り換えを検討したところ、1年近い運用で作ったテンプレート約300本、社内ナレッジをどう分けて登録したかの記録、営業部の過去の提案書で追加学習した朝凪専用モデルの設定が、提供元の管理画面にしか残っていないことが判明します。情報システム課の森の見積もりでは、テンプレートを写して確かめるだけで一人ではひと月で終わらず、社内の時間を金額に直すと値上げ分の1年ぶんを超えました。結果として1年の短期更新で値上げを受け入れることになり、次の契約に向けて、テンプレートと検証用の質問集を自社の共有フォルダで管理する作業を始めました。交渉の余地は、契約条件ではなく手元に何が残っているかで決まっていました。
この場面は網羅物語之巻 第8章「乗り換えられない」に出てきます。
買う側から確認する ― 導入時の5項目
提案の段階では依存の情報が出にくいため、買う側から確認します。所要は短時間です。
- データを取り出せる形式と手順 ― 導入時に確認する。終了が決まってからでは手遅れです。
- モデル廃止・仕様変更・値上げの通知期間 ― 規約に記載があるかを見る。
- バージョン固定の可否 ― できない場合、検証セットの定期実行が必須になります。
- そのサービスが他社モデルの再提供かどうか ― 上流の変更の影響を受けます。
- 独占的条項の有無 ― 分散の設計が可能かを決めます。
あわせて、自社側で移行可能な資産を手元に残しておくことが最も確実な対策になります。プロンプト、検証セット、参照文書、設定値。これらを事業者の管理画面だけに置かないことです(表の網羅版 第13章「AIシステムのアーキテクチャ設計」)。