AI開発発注の失敗図鑑｜ベンダー・モデルロックインと出口戦略の不在という失敗

AI開発の発注では、「今いちばん性能が高いモデル」「今いちばん使いやすいクラウド」を選び、その上に業務システムを一気に組み上げてしまうことがある。立ち上がりは速いが、半年後・一年後に、API仕様の変更、提供終了、利用条件や価格体系の見直し、より良い選択肢の登場といった外部要因に直面したとき、抜け出せなくなる。これがベンダー・モデルロックインという失敗である。

本連載では、PoC、データ品質、運用、見積、開発会社選びといった論点を扱ってきた。本記事はその延長線上で、技術依存・移行性・API廃止や値上げへの備えという軸に絞り、生成AIの出口戦略をどう設計するかを発注者の視点で整理する。なお、特定企業の値上げや提供終了を断定するものではなく、AIプラットフォーム全般に共通する一般的なリスクとして扱う。

結論：AI開発は「最良の1社」より「乗り換えられる構造」で発注する

AI開発の発注では、最良のモデルやクラウドを選ぶこと以上に、後から乗り換えられる構造で作ることが、長期のコストとリスクを左右する。GXOがロックインの観点で見るのは、特定ベンダー・特定LLM・特定クラウドへの依存度と、出口戦略の有無である。

• モデルやAPIは数か月単位で進化・改廃される前提で、差し替え可能な層を設けて設計する
• 自社データ・プロンプト・評価データ・ログは、自社が持ち出せる形式で手元に残す
• 「いま動くか」だけでなく、「値上げ・廃止・乗り換え時に何が起きるか」を発注前に確認する
• 出口戦略（別モデル・別ベンダーへ移る手順とコスト）を、契約と設計の両方に書いておく

最良の1社に深く密着するほど、価格交渉力も移行の自由度も下がる。発注時点で出口を設計しておくことが、ロックインを避ける最大の対策である。

なぜベンダー・モデルロックインが起きるのか

立ち上がりの速さが依存を深める

生成AIは、特定ベンダーのSDKやマネージドサービスに乗ると、認証・推論・ベクトル検索・ログまで一気通貫で組める。短期間で動くものが作れる反面、そのベンダー固有の機能やデータ形式に業務ロジックが密着していく。気づいたときには、アプリケーションのあちこちに特定APIの呼び出しやレスポンス形式の前提が埋め込まれ、別の選択肢へ移すこと自体が一つの開発プロジェクトになっている。

「今いちばん」を固定の前提にしてしまう

モデルの性能・価格・利用条件は短い周期で変わる。発注時点での「いちばん良いモデル」を恒久的な前提に置くと、より安く高性能な選択肢が出ても活かせず、逆に利用条件や価格体系が見直された際に身動きが取れなくなる。AIの世界では、半年前の最適が今日の最適とは限らない、という前提を設計に織り込む必要がある。これは作って終わりにせず、モデルの陳腐化・再学習を計画する観点とも地続きの論点である。

データとプロンプトを「相手側」に預けてしまう

蓄積した会話ログ、評価データ、ファインチューニング用データ、設計したプロンプト群は、AIシステムにおける重要な資産である。これらが特定サービスの内部にしか存在せず、標準的な形式で持ち出せない状態だと、乗り換えのたびに資産を作り直すことになる。資産が相手側にあるほど、交渉でも移行でも不利になる。

出口戦略を契約・設計に書いていない

多くの発注では「どう作るか」は詳細に詰める一方、「どうやめるか・どう移すか」は曖昧なまま進む。提供終了や大幅な値上げ、品質低下が起きたときに、別モデル・別ベンダーへ移る手順とコストが誰にも分からない。出口の不在は、平時には問題に見えないが、外部環境が変わった瞬間に高いスイッチングコストとして表面化する。

ロックインが起きやすい3つのレイヤー

ロックインは「ベンダー」という一語で語られがちだが、実際は複数のレイヤーで別々に起きる。レイヤーごとに依存度と対策を分けて見ると、過剰な不安にも油断にも陥らずに判断できる。

3つのレイヤーは独立しており、すべてをゼロ依存にする必要はない。重要なのは、それぞれの依存を「意識して選んだ依存」にすることである。なんとなく1社に寄ったのか、評価したうえで許容したのかで、後の打ち手はまったく変わる。データ層の持ち出しやすさは、特にデータ基盤の設計とあわせて発注前に整理しておきたい。

ロックインを避ける設計と発注の考え方

差し替え可能な「抽象化層」を設ける

アプリケーションからモデルやAPIを直接呼ぶのではなく、間に薄い抽象化層（共通インターフェース）を挟む。業務ロジックは抽象化層に対して話し、どのモデル・どのベンダーを使うかは設定で切り替えられるようにする。これにより、モデルを差し替えても業務ロジックを書き換えずに済み、複数モデルの併用や段階的な移行が現実的になる。過剰な作り込みは不要だが、「呼び出し口を1か所に集める」だけでも移行性は大きく上がる。

評価データを自社資産として持つ

モデルを乗り換えられる構造にしても、乗り換えた先で品質が出るかを確認できなければ意味がない。自社の業務に即した評価データ（想定質問と期待される回答、合否基準）を手元に整備しておくと、別モデルへ切り替えても同じ物差しで合否を判定できる。評価データは出口戦略の中核であり、これがあるかどうかで「乗り換え可能」が言葉だけか実態を伴うかが分かれる。AI導入の入口でこの物差しを設計しておくことは、AI導入可否のアセスメントの段階で前倒しできる作業でもある。

データ・プロンプト・ログを持ち出せる形で残す

会話ログ、プロンプト、評価データ、設定情報は、特定サービス専用の形式に閉じ込めず、標準的なデータ形式で自社側にも保持する。発注時に「これらのデータを、いつでも、追加費用なく、標準形式で取り出せるか」を確認しておく。持ち出せないデータは、実質的に相手の資産であり、ロックインの源泉になる。

出口戦略を発注前に言語化する

出口戦略とは、別モデル・別ベンダーへ移ると決めたときに、何を、誰が、どの順番で、どれくらいの期間と費用で行うかを、あらかじめ書き出しておくことである。完璧な手順書である必要はないが、「移行に必要なデータ」「依存している固有機能」「想定スイッチングコスト」の3点を把握しているだけで、外部環境の変化に冷静に対応できる。出口の有無は、平時の価格交渉力にも効いてくる。

マルチモデル・段階移行を前提に設計する

最初から複数モデルを使い分ける必要はないが、「いつでも増やせる・差し替えられる」状態にしておくと、用途ごとの最適化や、特定モデルの不調時の切り替えがしやすくなる。生成AIの実装そのものを、こうした移行性を前提に設計できるかは、生成AI・AI開発の実装を任せる相手を選ぶ際の重要な観点である。レガシー資産を含む基幹システムと連携する場合は、既存システムの刷新・移行の進め方ともあわせて検討するとよい。

発注前に確認すべきこと（チェックリスト）

発注前に、ロックイン耐性と出口戦略について、開発会社へ具体的に確認する。抽象的な「大丈夫です」ではなく、手順とコストで答えられるかを見る。

• モデル・APIは差し替え可能な抽象化層を介して呼ぶ設計になっているか
• 特定ベンダー固有の機能に、業務ロジックがどの程度密着するか説明できるか
• 会話ログ・プロンプト・評価データ・設定を、標準形式で追加費用なく取り出せるか
• 自社の業務に即した評価データを、自社資産として整備・保持できるか
• 別モデル・別ベンダーへ移る場合の手順・期間・概算コスト（スイッチングコスト）を示せるか
• API仕様変更や提供終了が起きた場合の通知・移行支援が契約に含まれているか
• 利用条件・価格体系が見直された場合に、契約や設計上どう対応できるかを整理しているか
• データの保管場所・持ち出し経路・保存期間が、セキュリティ要件と整合しているか
• 出口戦略（移行に必要なデータ・依存機能・想定コスト）が文書化されているか
• 投資判断として、移行リスクを含めた費用をシステム開発の稟議・ROI診断の観点で説明できるか

これらに具体的に答えられる開発会社は、ロックインを意識した設計ができている可能性が高い。逆に、すべてを「問題ない」で済ませる場合は、依存度を発注者側で確認しておきたい。開発会社の見極めそのものは、開発会社選びで見るべき7項目もあわせて参照してほしい。

GXOに相談する前に整理しておくとよい情報

相談をスムーズにするために、次の情報を整理しておくと、現状の依存度と出口戦略の論点を素早く把握できる。

• 対象業務と、そこで使っているモデル・API・クラウドの構成（分かる範囲で）
• 蓄積しているデータの種類（会話ログ・評価データ・プロンプトなど）と、その保管場所
• それらのデータを取り出せるか、取り出した経験があるか
• 現在の月額費用（API・クラウド・運用）と、その内訳が把握できているか
• 過去に経験した仕様変更・値上げ・品質変化と、そのときの対応
• 乗り換えを検討したことがあるか、その際に何が障害になったか
• 経営として、どの程度のスイッチングコストまでなら許容できるか

これらが完全にそろっていなくても問題ない。むしろ、どこが把握できていないかが分かること自体が、出口戦略を設計する出発点になる。依存構造の棚卸しは、DX成熟度の診断やAI導入可否のアセスメントとあわせて行うと、技術と業務の両面から整理しやすい。現状を踏まえて移行性の高い設計まで具体化したい場合は、生成AI・AI開発の実装の相談として持ち込むと、出口戦略を含めた設計に落とし込みやすい。

補足：実務上の注意点

ロックイン回避を目的化しすぎると、別の失敗を招く点に注意したい。

第一に、ゼロ依存を目指す必要はない。すべてのレイヤーで完全な移行性を確保しようとすると、抽象化層の作り込みや多重実装でコストが膨らみ、肝心の業務価値が後回しになる。重要なのは、依存を「意識して選んだ依存」に変えることであり、許容できるリスクと、許容できないリスクを切り分けることである。

第二に、移行性とランニングコストは別の論点として両方見る。乗り換えやすい構造であっても、日々の推論コストや従量課金の設計が甘ければ、本番で費用が膨らむ。この点は初期費だけ見て本番で破綻するランニングコストの失敗で扱った観点とあわせて確認したい。

第三に、特定ベンダーの値上げや提供終了を断定的に語るのではなく、AIプラットフォーム全般で起こりうる一般的なリスクとして備える姿勢が現実的である。どの提供者も仕様変更や価格改定の可能性はあり、「特定の1社が危ない」のではなく「依存構造に出口がないこと」がリスクの本質である。

第四に、業務システム全体としての移行性も忘れない。AI部分だけ差し替え可能でも、連携する基幹システムやデータ基盤が硬直していれば、全体としては動かせない。DX・システム開発の文脈で、AIと既存システムの境界をどう設計するかまで含めて見ておくと、部分最適のロックインを避けられる。

関連記事

• 特集トップ：AI開発発注の失敗図鑑
• 開発会社選びで見るべき7項目
• 作って終わり——モデル陳腐化・再学習を計画せず劣化する失敗（技術的負債）
• 初期費だけ見て本番で破綻するランニングコスト（従量課金・推論コスト）
• ベンダー選定の実務チェック（特集）

よくある質問

Q1. 最初からマルチモデルや抽象化層を作るべきか

すべての案件で最初から作り込む必要はない。ただし、モデルやAPIの呼び出し口を1か所に集めておくだけでも、後の差し替えコストは大きく下がる。最初は1モデルで始めても、抽象化層を薄く挟んでおけば、必要になったときに段階的に移行できる。投資対効果を見ながら、どこまで作るかを決めるのがよい。

Q2. 特定のベンダーやモデルが値上げ・提供終了するか心配だ

個別の提供者がどうなるかを断定することはできず、本記事もそれを前提にしていない。重要なのは、どの提供者でも仕様変更や価格改定はありうると考え、出口戦略を持っておくことである。別モデルへ移る手順・コスト・必要データを把握していれば、外部環境が変わっても落ち着いて対応できる。

Q3. すでに特定ベンダーに深く依存してしまっている。どうすればよいか

まずは依存構造を棚卸しし、どのレイヤーで、どの固有機能に密着しているかを可視化することから始める。すべてを一度に移す必要はなく、影響の大きい依存から順に、抽象化層やデータの持ち出しを整えていく。現状の依存度と移行コストを把握するだけでも、次の打ち手と価格交渉の材料になる。

Q4. 出口戦略は契約と設計のどちらで担保するのか

両方で担保する。契約では、データの取り出し可否、仕様変更・提供終了時の通知や移行支援、利用条件の扱いを明記する。設計では、抽象化層・標準形式でのデータ保持・評価データの整備によって、技術的に移行できる状態を作る。片方だけでは、移れる権利はあるが手段がない、あるいは手段はあるが契約上動けない、という事態になりやすい。

発注前チェックリスト（全30項目・無料）：本連載の30類型を1枚で点検できるチェックリストを無料ダウンロードできます。発注前の社内確認・稟議の添付資料にご利用ください。

ベンダー・モデルロックインと出口戦略の不在は、平時には見えにくく、外部環境が変わった瞬間に高いコストとして表面化する失敗である。自社の依存度を棚卸しし、移行性を保つ設計と出口戦略を整理したい場合は、GXOの無料相談で現状の確認から始めてほしい。