AI開発の失敗事例:ベンダーロックイン
AI開発でベンダーロックインを避けるため、RFP、契約、データ、評価、運用、引き継ぎ条件の実務ポイントを整理します。

結論
AI開発のベンダーロックインは、特定の会社に依存すること自体ではなく、データ、プロンプト、評価セット、運用手順、ログ、権限、設計資料を発注者側が引き継げない状態になることです。AI開発では、モデルや外部APIだけでなく、評価方法や運用ノウハウも資産になります。これらを契約前に整理しないと、改善や乗り換えのたびに大きな追加費用が発生します。
RFPでは、納品物、知的財産、データ返却、ログ、評価データ、プロンプト、運用手順、権限移管、契約終了時の支援を明記します。最初からすべてを内製化する必要はありませんが、将来の変更余地を残すことが重要です。
失敗が起きる流れ
ベンダーロックインは、PoCの成功後に起きやすい失敗です。短期間で成果を出すためにベンダー固有の環境へ作り込み、評価データやプロンプトがベンダー側だけに残り、発注者は画面だけを使う状態になります。最初は問題なく見えても、価格改定、担当変更、品質低下、追加要望、契約終了のタイミングで困ります。
特にAI開発では、何を正解としたのか、どのデータを使ったのか、どの禁止回答を設定したのか、どのログを見て改善したのかが重要です。これが残っていないと、別ベンダーへ相談しても再構築に近い作業になります。
RFPに入れる項目
| 項目 | 確認する内容 |
|---|---|
| 納品物 | 設計資料、プロンプト、評価セット、運用手順 |
| データ | 入力データ、加工済みデータ、ログ、返却形式 |
| 権限 | 管理者権限、APIキー、環境、監査ログ |
| 変更管理 | モデル変更、プロンプト変更、評価更新の手順 |
| 終了時支援 | 引き継ぎ期間、移行支援、削除証跡 |
この表をRFPに入れることで、提案比較がしやすくなります。安い見積でも、引き継ぎやログ提供が含まれていなければ、長期では高くなることがあります。逆に、すべての成果物を発注者が所有する条件にすると初期費用が上がる場合もあるため、必要な範囲を選びます。
契約前に確認すること
契約前には、使用するモデル、外部SaaS、クラウド、データ保存場所、サブプロセッサ、利用規約、解約時のデータ扱いを確認します。ベンダーが独自の基盤を使う場合でも、ログ、評価データ、プロンプト、設定値、設計思想をどこまで開示できるかを確認します。
また、評価データの所有権を曖昧にしないことが重要です。評価データは、AI開発の品質を確認するための資産です。これを引き継げないと、改善や再発注のたびに同じテストを作り直すことになります。
運用で失敗しないための設計
運用では、月次や四半期で、プロンプト変更、モデル変更、データ更新、誤出力、改善履歴を記録します。担当者が変わっても理由が追えるように、変更ログを残します。ベンダーに依存する部分と社内で理解しておく部分を分け、少なくとも管理画面、ログ、評価結果は発注者側が読める状態にします。
本番化後も、年に1回は乗り換え可能性を確認します。これはすぐ乗り換えるためではなく、データ返却、手順書、権限、問い合わせ先が現実に使えるかを点検するためです。点検しておくと、価格改定や品質問題が起きても交渉しやすくなります。
検収条件の作り方
検収では、画面やAPIの動作だけでなく、引き継ぎ資料があるかを確認します。テストケース、評価結果、ログ形式、管理者権限、プロンプト、設定値、更新手順、障害時の連絡先、契約終了時の削除手順を納品物として確認します。
また、第三者が読んで再現できる粒度かも見ます。担当者の口頭説明だけでは不十分です。運用資料に、変更方法、禁止事項、確認観点、問い合わせ先が書かれているかを確認します。
図解で確認するポイント
この記事の画像は、AI開発の資産を「データ、評価、プロンプト、ログ、運用手順、引き継ぎ」へ分け、ベンダー依存を下げる流れを示す図解です。画像内にタイトルや売り文句を入れず、発注前に確認すべき資産の位置づけを視覚的に把握できるようにしています。
AllAI内での次の行動
発注前に比較軸を作る場合はAI開発会社一覧で候補を見ながら、引き継ぎ条件をRFPへ入れます。標準SaaSで足りる可能性がある場合はAI/SaaS比較で確認し、社内担当者の理解を高める場合はAI講座で基礎を学びます。
FAQ
Q. ベンダーロックインを完全になくすべきですか? A. 完全になくすより、重要な資産を引き継げる状態にすることが現実的です。すべてを内製化すると費用と負荷が上がります。
Q. 最低限引き継ぐべきものは何ですか? A. 設計資料、プロンプト、評価データ、ログ、運用手順、管理者権限、データ返却手順です。
Q. 契約終了時の条件はいつ決めるべきですか? A. 契約前に決めます。終了時に交渉すると、データや運用資料の扱いで不利になりやすいです。
出典:
- 経済産業省 AI事業者ガイドライン 第1.2版: https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html (確認日: 2026-07-08)
- NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework (確認日: 2026-07-08)
- OWASP Top 10 for LLM Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/ (確認日: 2026-07-08)
次に見る
関連する記事・ガイド
- AI開発会社ガイドAI開発RFPでAIエージェント権限境界を指定する方法
AI開発RFPでAIエージェント権限境界を指定する方法では、AI開発を外注する前にAIが実行できる操作、承認が必要な操作、ログ取得をRFPで分けるためのRFP・契約・見積比較の観点を整理します。
- AI開発会社ガイドAI開発RFPでAIエージェントのツール利用リスクを指定する方法
AI開発RFPでAIエージェントのツール利用リスクを指定する方法では、AI開発を外注する前に外部API、メール送信、DB更新などの実行権限を段階制御するためのRFP・契約・見積比較の観点を整理します。
- AI開発会社ガイドAI開発契約でデータエクスポート形式を決める方法
AI開発契約でデータエクスポート形式を決める方法では、AI開発を外注する前に解約時のデータ形式、メタデータ、ログ、再利用権を契約で押さえるためのRFP・契約・見積比較の観点を整理します。
- AI開発会社ガイドAI開発のデータ移行リスクで起きる失敗事例
AI開発のデータ移行リスクで起きる失敗事例では、AI開発を外注する前に移行対象、欠損、名寄せ、検収条件を曖昧にした失敗を避けるためのRFP・契約・見積比較の観点を整理します。