AI開発契約の出口条項レビューでロックインを防ぐ
AI開発・保守契約の終了時に発注側が困らないための出口条項(引き継ぎ義務・データ返却・移行支援・料金)のレビュー観点を、契約締結前の確認手順として解説します。

結論
ベンダーロックインの本体は技術ではなく契約です。ソースコードが手元にあっても、契約に「終了時の引き継ぎ支援義務」「データとモデルの返却形式」「移行期間中の並行支援料金」が書かれていなければ、乗り換えの実務は成立しません。出口条項のレビューは契約締結前にしかできない作業であり、関係が良好なうちに終了時のルールを固定することが目的です。レビューは、引き継ぎ義務、返却物の範囲と形式、移行支援の期間と料金、終了トリガー別の扱いの4象限で行います。
出口条項とは何か
出口条項とは、契約の終了(期間満了、中途解約、解除)に際して、ベンダーが負う義務と発注側の権利を定めた条項群のことです。多くの契約書ひな形では「契約終了時は貸与物を返還する」程度の一般条項しかなく、AI開発で実際に必要な「動くシステムを別の運用者へ渡す」ための実務は何もカバーされていません。
出口条項がない契約で保守ベンダーを変えようとすると、現行ベンダーには引き継ぎに協力する義務がなく、協力するとしても言い値の「引き継ぎ支援費」を提示されます。この時点で発注側に交渉力はありません。締結時に決めておくべき理由はここにあります。
レビューの4象限
| 象限 | 確認する内容 | 合格の目安 |
|---|---|---|
| 引き継ぎ義務 | 終了通知後の技術説明会、質問対応、ドキュメント更新の義務 | 期間(60-90日)と工数上限が明記 |
| 返却物 | コード、モデル重み、学習データ、プロンプト、設定、運用手順、アカウント | 形式(リポジトリ、エクスポート形式)まで明記 |
| 移行支援 | 後継ベンダーへの説明、並行運用、切替立ち会い | 料金レート(人日単価)が事前固定 |
| 終了トリガー別 | 満了・発注側都合・ベンダー都合・債務不履行での義務の差 | ベンダー都合終了時は支援無償 |
このうち交渉で最も重要なのは、移行支援の料金レートの事前固定です。「別途協議」と書かれた移行支援費は、終了局面では競争が働かないため高止まりします。通常の開発単価と同水準のレートを契約時に書かせてください。
返却物リストの具体化
「一切の資料を返還する」では実務は動きません。返却物は成果物明細(IP帰属の別紙)と対応づけて、次の粒度でリスト化します。ソースコード一式(ビルド手順と依存関係定義を含む)、学習済みモデルの重みファイルと学習再現に必要なコード・ハイパーパラメータ、プロンプトテンプレートと設定値、学習・評価データセット(発注側データ由来のもの)、インフラ構成のコード化定義(IaC)またはパラメータシート、運用手順書と障害対応履歴、SaaS・クラウドの管理者権限とAPIキーの移管手順です。
クラウド環境がベンダー名義で契約されている場合は、名義変更またはアカウント移管の手続きも出口条項の対象です。ベンダー名義のまま運用を始めると、終了時に環境ごと人質になるため、可能なら最初から発注側名義+ベンダーへの権限付与の構成にしてください。
終了トリガー別の設計
出口の義務は、終了の理由によって濃淡をつけます。期間満了・発注側都合の解約では、引き継ぎ支援は有償(事前固定レート)で構いません。一方、ベンダー都合の撤退(事業終了、サービス打ち切り)では、十分な予告期間(6ヶ月以上)と無償または割引の移行支援を義務づけます。ベンダーの債務不履行による解除では、引き継ぎ協力を損害軽減義務の一部として明記し、協力拒否が損害賠償の対象になることを書きます。
外部の基盤モデルAPIに依存する構成では、ベンダー自身が制御できない「依存サービスの終了」も想定し、代替構成の検討をベンダーの協力義務に含めておくと、モデル切替時の初動が変わります。
出口条項とデータ・ログの残し方
出口を実際に使う日のために、平時から残すものがあります。第一に、リリースごとの構成情報と依存台帳の最新化(第三者コンポーネント開示台帳と共通)。第二に、運用ナレッジの社内蓄積(障害対応の判断理由をベンダーのチケットシステムだけに残さない)。第三に、契約・覚書・単価改定の履歴一元管理です。出口条項が完備でも、これらが散逸していると移行先ベンダーの立ち上がりに数ヶ月かかります。移行コストの実態は、条項の有無と情報の残り方の掛け算で決まります。
実務チェックリスト
- 引き継ぎ支援の期間・工数上限・料金レートが契約に明記されているか
- 返却物リストがモデル重み・プロンプト・IaC・権限まで具体化されているか
- 移行支援費が「別途協議」になっていないか
- ベンダー都合撤退時の予告期間(6ヶ月以上)と支援条件を定めたか
- 債務不履行解除時の引き継ぎ協力義務を書いたか
- クラウド・SaaSの契約名義と権限構成を確認したか
- 依存する外部モデル終了時の協力義務を含めたか
- 構成情報・運用ナレッジ・契約履歴の社内保管を運用化したか
図解で確認するポイント
この記事の画像は、契約関係の終了地点から複数の移行経路が延び、必要な資産が経路に沿って引き渡される構造を文字なしで図解しています。出口が設計されていれば終了は行き止まりではなく分岐点になることを示しています。
AllAI内での次の行動
出口条項を含む離脱計画の全体はベンダーロックイン出口計画ガイド、実際の乗り換え手順はベンダー切替ガイド、終了時の体制解消はベンダーオフボーディングチェックリストへ進んでください。契約前の比較段階ならAI発注診断で要件を整理し、AI開発パートナーで出口条件の交渉に応じる会社を見極められます。
FAQ
Q. 出口条項を求めるとベンダーとの関係が悪くなりませんか? A. 出口条項は「辞める前提」ではなく「続ける理由を品質に置く」ための条項です。優良ベンダーは、ロックインではなく成果で選ばれ続けることに自信があるため、合理的な出口条項を拒みません。強く抵抗するベンダーほど、出口を塞ぐことを事業戦略にしている可能性があります。
Q. 既存契約に出口条項がない場合、後から足せますか? A. 更新のタイミングが交渉機会です。更新合意と引き換えに出口条項の覚書を結ぶのが現実的で、更新直後より更新の2-3ヶ月前に切り出すと交渉時間を確保できます。
Q. 引き継ぎ支援の工数はどのくらい見込むべきですか? A. 中規模システムで20-40人日が目安です。技術説明会、後継ベンダーからの質問対応、ドキュメント補完、切替立ち会いを含みます。契約には上限工数と超過時のレートを書き、実際の消化は移行計画で管理します。
Q. モデルの重みを返してもらえば同じシステムを再現できますか? A. 重みだけでは不十分です。前処理コード、プロンプト、推論時の設定、依存ライブラリのバージョンが揃って初めて挙動が再現します。返却物リストを「再現に必要な一式」という機能要件で定義するのが安全です。
出典と確認日
- 経済産業省「AI・データの利用に関する契約ガイドライン」: https://www.meti.go.jp/press/2018/06/20180615001/20180615001.html (確認日: 2026-07-10)
- IPA「情報システム・モデル取引・契約書」: https://www.ipa.go.jp/digital/model/index.html (確認日: 2026-07-10)
- 公正取引委員会「下請法・中小受託取引適正化法」: https://www.jftc.go.jp/shitauke/index.html (確認日: 2026-07-10)
- 経済産業省「DXレポート」: https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html (確認日: 2026-07-10)
関連する記事・ガイド
- AI開発会社ガイドBest-of-N: OpusAI開発 本番KPI未達時の契約見直し会議
AIシステムの本番KPIが未達のとき、事業責任者・PM・調達が開く契約見直し会議の論点、証跡、判断、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 検収後クレームの紛争証跡ワークフロー
AI受託開発の検収後にクレームや紛争が起きたとき、法務・PM・経理が証跡を整理するワークフロー、紛争段階、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 障害時ベンダー連絡のエスカレーション表
AIシステムの障害時に、運用・情シス・ベンダーが使うエスカレーション表の作り方、連絡基準、証跡、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 運用マニュアル検収の版管理
AI受託開発で納品される運用マニュアルを、運用・品質保証・情シスが検収し版管理する手順、確認項目、証跡、費用の見方を整理します。