ベンダーロックインを防ぐには｜発注時にできる対策
ベンダーロックインを防ぐために発注時にできる対策を解説。ロックインの種類と原因、ドキュメントとソースコードの納品を契約に入れる方法、乗り換えコストの考え方を紹介します。
「保守費が毎年上がるのに、ほかの会社に頼めない」「改修の見積が高いと思っても比べようがない」。こうした状態をベンダーロックインと呼びます。ベンダーロックインの回避は、システムができあがってからでは難しく、発注の時点での対策が効きます。この記事では、ロックインの種類と原因、ドキュメントとソースコードの納品を契約に入れる方法、特定の技術への依存を減らす設計、乗り換えコストを事前に見積もる考え方を説明します。
ベンダーロックインとは：回避の前に知っておきたい2つの種類
公正取引委員会は、ベンダーロックインを、システムの機能改修や保守など使い続けるために必要な作業を導入した事業者以外が行えず、特定のベンダーを使い続けなければならない状態と説明しています（公正取引委員会「官公庁における情報システム調達に関する実態調査報告書」2022年2月公表）。官公庁を対象にした調査ですが、民間企業の発注でも同じことが起きます。
ロックインには、大きく分けて2つの種類があります。
コーポレートロックインは、技術的には乗り換えられるのに、手間や社内事情で動けない状態です。テクノロジーロックインは、乗り換えようとしても技術的に引き継げない状態です。実際には、この2つが重なっていることがほとんどです。
ロックインが起きる主な原因
ロックインは、発注者が意図しないうちに少しずつ進みます。よくある原因は次のとおりです。
- 設計書が残っていない: 開発会社の担当者の頭の中にしか仕様がなく、ほかの会社が全体を把握できない。
- ソースコードを受け取っていない: 契約で納品物に含めていなかった、または著作権が開発会社に残っていて改変できない。
- 独自の仕組みに依存している: 開発会社独自のフレームワーク（開発の土台となる部品群）や、中身が見えない外部サービスの上に作られている。
- アカウントが開発会社の名義になっている: サーバー、ドメイン、アプリストアのアカウントを開発会社が持っている。
- 社内に分かる人がいない: 発注者側でシステムの全体像を説明できる人がいない。
ドキュメントとソースコードの納品を契約に入れる
最も効果の大きい対策は、納品物の範囲を契約で決めておくことです。契約書や発注書に、次の項目を明記しましょう。
著作権は、契約で何も決めていなければ、原則として実際にプログラムを作った開発会社に残ります。発注者が改修や再利用を自由に行えるようにするには、契約で譲渡や利用許諾を決めておく必要があります。詳しくは著作権とソースコードの扱いで説明しています。
また、設計書は「あとでまとめて作る」とすると、納期の圧力で省略されがちです。工程の区切りごとに受け取り、検収の対象に含めると確実です。
契約で決めるだけでなく、発注者の社内にもシステムの全体像を説明できる人を置いておくことが、コーポレートロックインを防ぎます。設計書を受け取ったら、社内の担当者が一度目を通し、分からない点を開発会社に質問しておきましょう。担当者が異動するときは、資料の置き場所とアカウントの管理者を引き継ぎ項目に入れておきます。
ベンダー固有の技術への依存を減らす設計
契約だけでなく、システムの作り方でもロックインは減らせます。発注時に、次のような方針を要望として伝えてください。
- 広く使われている技術で作る: 主要なプログラミング言語やデータベースで作れば、引き継げる会社が多くなります。
- 外部サービスを部品として分ける: SNS連携やAIなどの外部サービスは、システム本体と分けた「接続部品」にしておくと、仕様変更や値上げ、提供終了のときに部品だけを差し替えられます。
- AIのモデルを差し替えられるようにする: 生成AIを使う場合、特定のモデルに合わせて作り込まず、用途ごとにモデルを切り替えられる設計にします。
- 環境の構成を記録として残す: サーバーの設定をコードとして残す方法（IaC：インフラの構成をコードで管理する方法）や、動く環境を丸ごと固定するコンテナという仕組みを使うと、特定の人しか環境を再現できない状態を防げます。
ノーコードツール（プログラムを書かずに作れるツール）や、月額制のクラウドサービスを使うこと自体は悪くありません。早く安く作れる利点があります。ただし、そのサービスの上でしか動かないため、乗り換えの難しさとセットで判断する必要があります。
乗り換え時のコストを事前に見積もる考え方
ロックインを完全になくすことはできません。大切なのは、「もし乗り換えるなら、どのくらいかかるか」を事前に把握しておくことです。
発注時や方式を選ぶときに、次の観点を比較表に入れてみてください。
開発会社に「もし他社に引き継ぐとしたら、何が必要で、どのくらいの作業になるか」と率直に聞くのも有効です。きちんと答えられる会社は、引き継ぎを前提にした作り方をしていると考えられます。
受託開発の現場から
ある受託開発会社の提案や社内の議論から、ロックインを防ぐ考え方を紹介します。
- 外部設計がそろえば、どこに頼んでも進められる: 画面の一覧と遷移、APIの設計、データの構造、インフラの設計といった外部設計までそろえば、どの開発会社に依頼しても比較的安全に開発を進められる水準になる、という見方があります。設計書をそろえることが、そのままロックインを防ぐ手段になります。
- オープンな技術構成を要求水準に入れる: 提案書では、主要な言語とデータベースで実装し、ベンダーにロックインされない技術構成にすることを要求水準として明記しています。方式を比べるときにも「依存・移行のしやすさ」を観点に入れ、発注者がコードを保有できるかを評価しています。
- 個人情報は発注者が管理できる場所に置く: 個人情報を含むデータは発注者側で管理できる環境に置き、外部のSNSやAIは接続部品として分けて、差し替えられるようにしています。
- ノーコード基盤への依存は見直しの対象になる: 社内でも、ノーコード基盤や中身を確認できない外部APIに依存した構成が足かせになっていると議論し、標準的な構成に書き換える方針を検討しています。発注者から「途中でAIを切り替えられるか」と聞かれた案件では、切り替えを想定した仕組みづくりを段階的な投資の後半に位置づけました。
まとめ
- ロックインには、取引や社内事情によるものと、技術的な理由によるものがあります。
- ソースコード・設計書の納品、権利の扱い、アカウントの名義を契約で決めます。
- 広く使われている技術で作り、外部サービスやAIは差し替えられる部品にします。
- 乗り換えのコストを、方式を選ぶ段階で比較の観点に入れておきます。
本記事は一般的な情報提供を目的としたもので、個別の契約や法的判断については弁護士などの専門家にご相談ください。
発注時にどこまで決めておけばよいか迷ったら、まず案件の中身を整理するところから始めましょう。FastProposal の無料AI相談では、案件を整理し、開発の範囲と費用の目安を数分で確認できます。