AI受託開発の『ベンダーロックイン』｜乗り換え・引き継ぎできない事態の防ぎ方

「動くものはあるのに、誰も触れない」——発注後になって気づく問題

AI受託開発を発注し、いったんは動くものが納品された。ところが半年、一年と経つうちに「担当エンジニアの対応が遅い」「追加要望のたびに高額な見積もりが来る」「そもそも中身がブラックボックスで何が起きているか分からない」といった不満が積み重なり、他社への乗り換えを検討し始める——これは決して珍しいケースではありません。

問題は、いざ乗り換えようとした段階で初めて壁にぶつかることです。「引き継ぎ資料を出してほしい」と依頼しても「そのような資料は作成していない」と言われる。あるいは他社のエンジニアに現行システムを見てもらっても「独自の構成すぎて解読に時間がかかる（＝追加の調査費用が発生する）」と言われてしまう。発注した時点では見えなかったリスクが、乗り換えようとした瞬間に一気に表面化する——これがAI受託開発における「ベンダーロックイン（特定の委託先に縛られ、他社に切り替えられなくなる状態）」の典型的な現れ方です。

この記事では、なぜ「引き継ぎできない」が起きるのかを3つのパターンに分解し、すでに困っている場合の現実的な対処と、次に発注する際にロックインを避けるための確認ポイントを整理します。

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

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

受託開発の現場では、動くコードだけが納品され、「何のためにこの処理があるのか」「どういう設計判断でこの構成にしたのか」を記した設計仕様書やドキュメントが作成されていないケースが少なくありません。この場合、元の開発者以外の誰かが引き継ごうとしても、コードを一行ずつ読み解くところから始めることになり、事実上「元の委託先にしか触れない」状態が固定化されます。

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

依頼した業務に合わせて完全にゼロから作り込む「フルスクラッチ」の開発は、その会社・その担当者だけが理解できる独自の構成になりやすい構造的な傾向があります。標準的な技術・共通化された部品を使わず、その場しのぎの実装が積み重なっていくと、他社のエンジニアが見ても「まず全体構造の把握から」というコストが発生し、乗り換えのハードルが上がります。

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

見落とされがちですが、契約書に成果物の著作権や利用範囲、データの持ち出し可否が明記されていないと、「そもそも納品物を他社に見せてよいのか」「ソースコードの著作権は発注者側にあるのか」という段階で足止めされることがあります。契約時点で意識していないと、乗り換えを検討する段になって初めて「実は契約上グレーだった」と気づくことになります。

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

すでに上記のような状況で困っている場合、次の3ステップで現実的に状況を整理できます。

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

いずれの場合も、焦って一方的に契約を打ち切るのではなく、まず現状を可視化してから動くのが、追加のトラブルを避ける進め方です。

発注前に確認しておくべき3つの条件——ロックインしない発注の受け方

これから発注する、あるいは次回の発注先を選ぶ段階であれば、次の3条件を確認しておくことで、将来の乗り換えのハードルを大きく下げられます。

• ① 納品物が「貴社の資産」として残る形か — コードを丸ごと預けっぱなしにする納品ではなく、業務の設定内容を設定ファイル（構成情報をテキストの形でまとめたもの）として受け取れる設計であれば、中身を貴社側で把握・保管でき、乗り換え判断をしても資産が手元に残ります
• ② フルスクラッチではなく、共通する業務を部品（モジュール）化した設計になっているか — 業種を超えて構造が似ている業務（受注取込・見積作成・請求突合など）を汎用の部品として組み合わせる設計であれば、他社エンジニアが見ても構造の把握がしやすく、乗り換えの調査コストが下がります
• ③ 契約条件に「試してから決められる」余地があるか — 初期投資を大きく約束させる契約ではなく、小さく試してから継続を判断できる条件（トライアル期間・最低契約期間の有無）が明記されているかを確認してください

awaiの設計思想——乗り換えられる前提で作る

awai Core（受注取込・見積作成・請求突合といった定型業務をAIで自動化するサービス）は、この3条件を製品設計そのものに組み込んでいます。納品はコードを丸ごと預かる形ではなく、業務ごとの設定を設定ファイル（config）として渡し、どの機能をどう有効化しているかが貴社側で把握できる形にしています。受注取込・見積・請求突合などの定型業務は業種を超えて共通する部品（モジュール）として設計しており、個社ごとの違いは部品の組み合わせと設定値で吸収する考え方です。契約面では、初期費用0円・最低契約期間なしを基本方針とし、小さく試してから継続を判断できる進め方を大切にしています（具体的な提供条件は貴社の状況に合わせて個別にご案内します）。

これは「乗り換えさせたくない」ではなく、「乗り換えられる状態を保つこと自体が、委託先として選ばれ続ける条件だ」という考え方に基づいています。内製か外注かで迷う段階の判断軸はAI受託開発は「内製か外注か」で選ぶと失敗するで詳しく整理していますので、発注前の比較検討にはあわせてご覧ください。

まとめ

AI受託開発の「乗り換えたいのに引き継げない」問題は、多くの場合、発注時点でのドキュメント不足・フルスクラッチ依存・契約条項の曖昧さという3つの原因に行き着きます。すでに困っている場合は契約書確認→資産の棚卸し→セカンドオピニオンの順で現状を可視化すること、これから発注する場合は「資産として残るか」「部品化されているか」「試してから決められるか」の3条件を確認することが、それぞれの対処法になります。awaiでは、現在の委託先の状態やこれから発注する業務の切り分けについて、無料相談（30分・オンライン）でお話を伺うところから対応しています。

※本記事の内容は一般的な傾向・設計原則の解説であり、特定企業の契約内容や個別事案への法的助言ではありません。契約書の解釈が必要な場合は弁護士等の専門家にご相談ください。提供条件・費用は貴社の状況により個別にご案内します。