AI受託開発のベンダーロックイン対策｜引き継げない原因と契約条項

AI受託開発を発注し、動くものは納品されました。ところが半年、一年と経つうちに「担当エンジニアの対応が遅い」「追加要望のたびに高額な見積もりが来る」「中身が分からず、何が起きているか説明できない」といった不満が積み重なり、他社への乗り換えを考え始めます。しかし引き継ぎ資料がなく、他社のエンジニアも手を出せません。このように特定の委託先に縛られ、他社に切り替えられなくなる状態を「ベンダーロックイン」と呼びます。

ロックインの原因は主に3つで、納品物がコードのみで設計書や運用手順書がない、会社ごとに一から作り込んだ独自の構成になっている、契約書に成果物の権利やデータの持ち出しの定めがない、のいずれかに当たります。すでに困っている場合は、契約書の確認、納品物の棚卸し、他社によるセカンドオピニオンの順に進めます。これから発注する場合は、成果物の範囲（プロンプトやテストデータを含む）・権利の帰属・環境の名義・終了時の引き渡しを契約書に書き込みます。

「引き継ぎできない」が起きる3つの典型パターン

パターン1：納品物がコードのみで、設計仕様書・運用ドキュメントがない

受託開発では、動くコードが納品されても、「何のためにこの処理があるのか」「どういう設計判断でこの構成にしたのか」を記した設計書や運用手順書が作られていないことがあります。この場合、元の開発者以外が引き継ごうとすると、コードを一行ずつ読み解くところから始めることになり、元の委託先しか触れない状態が固定されます。

パターン2：業務ごとに一から作り込む「フルスクラッチ」で、汎用性のない独自構成になっている

依頼した業務に合わせてゼロから作り込む「フルスクラッチ」の開発は、その会社・その担当者にしか分からない構成になりやすい傾向があります。標準的な技術や共通化された部品を使わず、その場しのぎの実装が積み重なると、他社のエンジニアが見ても全体構造の把握から始める必要があり、乗り換えの費用が上がります。

パターン3：契約書に著作権・成果物の帰属・データの持ち出しに関する定めがない、または不利になっている

契約書に成果物の著作権や利用範囲、データの持ち出し可否が書かれていないと、「納品物を他社に見せてよいのか」「ソースコードの著作権は発注者にあるのか」という段階で止まることがあります。契約時に意識していないと、乗り換えを検討する段になって、権利関係が曖昧だったと気づきます。

今すでに「乗り換えたいのに動けない」場合の対処

すでに上記のような状況で困っている場合は、次の3ステップで対処します。

• ① 契約書を確認する：著作権・成果物の帰属、データの持ち出し可否がどう定められているかを読みます。定めが曖昧な場合は法的な解釈が必要になるため、弁護士など専門家への相談も検討してください
• ② 現状の資産を棚卸しする：何が納品されているか（コード一式・設定ファイル・利用しているデータ）、どの環境で動いているか（サーバー・利用しているツール・AIサービスの契約名義）を、分かる範囲で書き出します。ドキュメントがなくても、動いている実物から棚卸しを始められます
• ③ セカンドオピニオンとして他社に見てもらう：乗り換えを決める前に、他社に現状を確認してもらい、「引き継ぎにどの程度の調査費用・期間がかかりそうか」の見立てをもらうと、乗り換えるか、今の委託先と条件を見直すかを判断できます

どの場合も、一方的に契約を打ち切る前に現状を把握します。引き継ぎに必要な情報が手元にない状態で契約を終えると、追加のトラブルを招きます。

これから発注する段階、あるいは次の発注先を選ぶ段階なら、次の3条件を確かめると、将来の乗り換えの負担を減らせます。

• ① 納品物が自社の資産として残る形か：ソースコードに加えて、単価表や判定ルールのような業務ごとの設定内容を設定ファイル（構成情報をテキストの形でまとめたもの）として受け取れれば、中身を自社で把握・保管でき、乗り換えても資産が手元に残ります
• ② 共通する業務を部品（モジュール）化した設計か：業種を超えて構造が似ている業務（受注取込・見積作成・請求突合など）を汎用の部品として組み合わせる設計なら、他社のエンジニアも構造を把握でき、乗り換えの調査費用が下がります
• ③ 段階的に契約し、途中で止められる条件か：初期投資を一度に約束する契約より、小さく試してから継続を判断できる条件（試験導入の期間、最低契約期間の有無、解約の通知期限）が明記されているかを確認します

「乗り換えられる状態」を契約書でどう担保するか

3条件を口約束で終わらせないために、契約書と発注書に書く項目を挙げます。どれも特別な条件ではなく、応じない相手のほうが例外です。

• 成果物の範囲：ソースコード、設定ファイル、設計書、運用手順書のうち何が納品されるかを列挙する。「一式」という記載で済ませない
• 知的財産権の帰属：開発したプログラムと設定の権利がどちらに帰属するか。受託者に帰属する場合、少なくとも自社が継続利用・改変できる許諾を明記する
• アカウントと環境の保有：クラウド環境、管理者アカウント、ドメインは自社名義で契約する。委託先名義だと、解約時に環境ごと失う
• AI固有の成果物：AIへの指示文（プロンプト）、精度の確認に使ったテストデータ、モデルの設定値も成果物に含める。生成AIのAPIも自社名義で契約し、利用料を自社で把握する
• 契約終了時の引き渡し：終了の◯日前までに、データと設定一式を指定の形式で引き渡す、という条項を入れる。この1行の有無で、契約の終わり方が変わる

この5点を最初の打ち合わせで伝えると、相手の姿勢が早い段階で分かります。乗り換えを妨げる設計は、受託側から見て短期的には有利でも、選ばれ続ける条件にはなりません。内製するか外注するかから迷っている場合は、AI受託開発は内製か外注か｜判断基準と委託先を見極める3条件の判断基準で方向を決めてから委託先を選びます。

まとめ

AI受託開発の「乗り換えたいのに引き継げない」問題は、多くの場合、発注時点のドキュメント不足・フルスクラッチ依存・契約条項の曖昧さという3つの原因に行き着きます。すでに困っている場合は、契約書の確認、資産の棚卸し、セカンドオピニオンの順で現状を把握します。これから発注する場合は、資産として残るか・部品化されているか・段階的に契約できるかの3条件を確かめ、契約書の文言に落とします。

※本記事の内容は一般的な傾向と設計原則の説明で、特定企業の契約内容や個別事案への法的助言ではありません。契約書の解釈が必要な場合は、弁護士等の専門家に相談してください。

乗り換えるか、今の委託先と条件を見直すかで迷っている段階なら、現行システムの納品物と契約書で確認する項目の洗い出しをawaiが手伝えます。