
この記事の要点
- ベンダーロックインは、独自の仕様、資料や知識の偏り、契約上の権利の3つが重なって起きることが多いです
- 契約では成果物の権利と終わるときの協力を、設計では標準的な技術とデータの持ち出しの手段を、運用では資料の更新と名義の管理を手当てします
- 同じ会社と長く付き合うこと自体は悪いことではなく、替えようと思えば替えられる状態を保っておくことが大切です
ベンダーロックインとは、システムの改修や保守を、導入した会社以外が行えないために、同じ会社を使い続けざるを得ない状態です。原因は、独自の仕様、資料や知識の偏り、契約上の権利の3つが重なることが多く、手当ては契約・設計・運用の3つの面で行います。
同じ会社と長く付き合うこと自体は、業務への理解が深まるなど良い面もあります。大切なのは、替えようと思えば替えられる状態を保っておくことです。原因と手当てを順に整理します。
ベンダーロックインとは
ベンダーロックインは、公正取引委員会の官公庁の情報システムの調達に関する実態調査(2022年2月8日公表)でも取り上げられています。そこでは、情報システムの改修や保守などを、導入した事業者以外が行えないために、特定のベンダーを使い続けざるを得ない状態と説明され、今後の調達ではベンダーロックインを避けることが重要だとしています。
出典:官公庁における情報システム調達に関する実態調査について(公正取引委員会、2022年2月8日)
民間の会社でも、同じことが起こります。ロックインの状態になると、次のような困りごとが生まれやすくなります。
- 改修や保守の費用を、ほかの会社と比べられない
- 対応の速さや品質に不満があっても、替えられない
- 開発会社の事情(担当者の退職、事業の縮小)に、自社のシステムが左右される
- 新しい技術やサービスに移りたくても、移れない
ロックインが起きる3つの原因
ロックインは、独自の仕様、資料や知識の偏り、契約上の権利のうち、1つの原因だけでなく、いくつかの原因が重なって起きることが多いです。
1. 独自の仕様
開発会社が独自に作った部品や枠組み(フレームワーク)、独自の形式のデータ、特定の製品だけの機能を多く使っていると、ほかの会社が中身を理解して手を入れるのが難しくなります。クラウドでも、特定の事業者だけの機能を多く使うと、ほかの事業者に移りにくくなります。
2. 資料や知識の偏り
設計書が作られていない、古いまま、という状態では、システムの中身を知っているのは開発会社の担当者だけになります。運用の手順や過去の障害の記録が残っていない場合も同じです。
3. 契約上の権利
契約で、ソースコードの著作権が開発会社に残る、改修をほかの会社にさせてはいけない、といった定めがあると、資料がそろっていても替えにくくなります。サーバーやドメインの契約が開発会社の名義になっていることも、移りにくさの原因になります。
契約での手当て
契約では、成果物の権利と、終わるときの扱いを決めておきます。
- 成果物の権利:ソースコードの著作権を発注する側に移すか、移さない場合でも、改修・再利用・ほかの会社への委託ができる許諾の範囲を決めます。考え方はシステム開発の成果物の著作権は誰のものかで説明しています
- 納品物の範囲:ソースコード、組み立てと公開の手順、設計書、運用の手順書を、納品物として書きます
- 終わるときの協力:契約が終わるときに、データや資料を渡し、次の会社に説明する協力を、範囲と費用を含めて決めておきます
- 名義:サーバー・クラウド・ドメインの契約は、発注する側の名義にすることを決めます
設計での手当て
設計では、ほかの会社でも理解しやすい形と、データを持ち出せる手段を用意しておきます。
- 広く使われている技術を選ぶ:使う人の多い言語や枠組みを選ぶと、引き継ぐ会社を探しやすくなります。採用した技術スタックの一覧を残しておきます
- データを持ち出せるようにする:データを一般的な形式(CSV など)で書き出せる機能や、API を用意しておくと、別のシステムへのデータ移行がしやすくなります
- 独自の部品は境目を分ける:特定の製品や事業者の機能を使う部分を、ほかの部分と分けて作っておくと、入れ替えるときの影響を小さくできます
特定の製品の機能を使うことには、早く安く作れるという利点もあります。使う場合は、移るときにどこを作り直すことになるかを、あらかじめ書き留めておきます。
運用での手当て
運用では、資料を新しく保ち、アカウントと名義を発注する側が管理します。
- 改修のたびに、設計書と運用の手順書を直してもらう
- ソースコードを、発注する側が管理する場所に置く
- 管理のアカウントの一覧を発注する側で持ち、担当者が替わったら権限を見直す
- 年に1回など、ほかの会社に引き継げる状態かを点検する
点検では、「いまの会社がいなくなったら、どこで困るか」を考えると、足りないものが見えやすくなります。
すでにロックインの状態になっている場合
すでに替えにくい状態になっている場合は、いきなり替えるのではなく、資料と権限を取り戻すところから始めます。
- ソースコード・環境・アカウント・資料・契約の5つについて、いま持てているものと足りないものを一覧にする
- 足りないものを、いまの会社に依頼して受け取る(作業の範囲と費用は話し合って決める)
- 契約の見直しの時期に、権利と終わるときの協力の定めを加える
- そのうえで、替えるか、いまの会社と続けるかを判断する
替えることを決めた場合の進め方は開発会社を替えるときの引き継ぎと、そろえておく資料で説明しています。古い仕組みの作り直しを考えている場合は、古くなったシステムを刷新する(モダナイゼーション)の進め方もご覧ください。
契約の権利の解釈や見直しは、個別の事情によって変わります。弁護士などの専門家にご相談ください。
当社のご支援
いまのシステムがどのくらい特定の会社に頼っているかの確認と、契約・資料・権限の整え方を、AI・DXコンサルティングでご相談いただけます。当社が開発や運用を受け持つ場合も、Webシステム開発では設計書や運用の手順書をお渡しし、区切りごとにお客様と一緒に確かめながら進めます。M&Aを控えて第三者の目でシステムを確かめたい場合は、システム監査をご覧ください。
- ベンダーロックイン
- 契約
- データ移行
- クラウド
この記事に出てくる用語
関連する法令・指針(参考情報)
- 法令
著作権法 第61条(著作権の譲渡)
著作権は、その全部または一部を譲渡できます。譲渡の契約で、第27条・第28条の権利を譲渡の目的として明記していないときは、これらの権利は譲渡した側に残ると推定されます(第2項)。
法令は2026年10月21日時点の内容です。要旨は当社がまとめたもので、条文・判決・指針の全文ではありません。個別の事案への当てはめは、弁護士・社会保険労務士などの専門家にご確認ください。表記の決まりは法令・指針の参考情報と凡例をご覧ください。
このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。