ベンダーロックインとは？開発会社を変えにくい原因と、移管・再構築の判断基準

2026-10-20

ベンダーロックインとは、特定の製品やサービス、技術に依存した結果、他への切り替えが難しくなる状態です。クラウドや業務パッケージでも使われる言葉ですが、この記事では、システムやアプリの開発・保守を委託している会社を変えられるかどうかに絞って扱います。

開発会社との連絡が途絶えた場合だけでなく、対応や費用に不満があっても、他社への変更を進められないことがあります。何が切り替えの妨げになっているかを確かめ、保守の移管、部分的な置き換え、再構築を比較することが出発点です。

Enlyt（エンライト）では、業務システムやアプリの開発と、公開したあとの運用改善までを手がけています。

ベンダーロックインとは

公正取引委員会は、ベンダーロックインという言葉を「ソフトウェアの機能改修やバージョンアップ、ハードウェアのメンテナンス等、情報システムを使い続けるために必要な作業を、それを導入した事業者以外が実施することができないために、特定のベンダーを利用し続けなくてはならない状態」と定義しています。できるかできないか、という作業の可否が基準に置かれています。ベンダーとは、システムやソフトウェアを提供する事業者のことです。

依存そのものは悪いことではありません。長く付き合った会社なら業務の事情も分かっていて、話が早く進みます。問題になるのは、その会社と付き合い続けるかどうかを、自社で選べない状態が発覚したときです。

この違いは、ふだんは見えないもので、何か変えようとした時に初めて分かることが多いのです。

依存にも利点はある

1社に任せ続けることには、やりやすい面もあります。業務の前提を説明しなくても通じる、過去の経緯を踏まえた判断をしてもらえる、窓口が1つで済む。複数社に分けると、説明が増えたり、伝えなくても考慮してくれていた仕様が抜けてしまうなど、スムーズにいかないところが出てきます。

問題は依存の度合いではなく、依存を自分で選べているかどうかです。他にも選べる状況で同じ会社に任せているなら、それは判断の結果です。他を選べないから続いているなら、同じ関係でも意味が違ってきます。デメリットとして挙げられるのは、費用を比べられないこと、対応の速さを交渉しにくいこと、相手の経営状況がそのまま自社のリスクになることです。

開発会社を変えにくくなる原因

切り替えの妨げになるものは、大きく5つに分けて考えられます。どれが効いているかで、確認すべきところが変わります。

1. 仕組みを知っている人が1社にしかいない

設計の意図、どこを直すと何に影響するか、過去にどういう理由でその作りにしたのか。こうした情報が文書ではなく人の頭の中にあると、他社は手を出しにくくなります。引き受けるには、まずコードを読んで仕様を復元する作業が必要になり、その分の時間と費用が見積もりに乗ります。

2. 権利の扱いがはっきりしない

契約で著作権の帰属や、他社への開示と改修の可否を決めていないと、他社に頼めるかどうかを判断できません。ここは契約の書き方で結果が変わるため、あとで確認する項目として扱います。

3. その会社だけの作り方になっている

独自のフレームワークや社内製のライブラリ、公開されていない仕様で組まれていると、他社の技術者が読めるようになるまでに時間がかかります。広く使われている技術で作られているほうが、引き受けられる会社を見つけやすくなります。

4. データが独自の形式で入っている

データの持ち方が独自で、取り出す方法が用意されていないと、別のシステムへ移せません。形式を教えてもらえないまま移行しようとすると、そこで止まります。

5. 運用が属人化している

障害が起きたときの手順、月次のバッチの流し方、サーバへのログインの仕方。こうした運用の知識が引き継がれていないと、システムが動いていても誰も触れない状態になることがあります。

切り替えを考える場面

この問題は、次のような場面で表に出ることがあります。

保守費用の値上げを提示されたとき。相見積もりを取ろうとして、他社に声をかけたところで止まります。資料が無いので見積もれない、と言われる形です。

機能を追加したいと伝えたとき。見積もりは出てくるものの、想定よりも高い。高いと感じても、他社の金額と比べられないため、妥当なのか判断できません。

対応の速さや進め方に不満が出てきたとき。別の会社に変えたいと思っても、変えた先で何が起きるのかが読めないため、動けないままになります。

担当者が代わったとき。前任者が口頭で把握していた前提が引き継がれず、残っている資料だけでは説明がつかない部分が出てきます。異動が定期的にある組織では、ここが先に表に出ます。

そして、連絡が取れなくなったとき。担当者が辞めて連絡先が分からない、会社の電話がつながらない、事業をやめている。この場合は交渉の余地がないぶん、動きにくくなります。ただし連絡が取れないことと、権利が無くなることは別です。権利が開発会社やその承継人に残っている可能性は残ります。契約先や連絡先の状況を確認しながら、自社に残っている資料・データ・権限の棚卸しを進めます。

いま自社で確認すること

次の5つを確かめます。何が欠けているかによって、調べる範囲が決まります。

本番環境へのアクセス権

サーバやクラウドの管理画面に入れるか。ドメインの管理権限とDNSの設定を変えられるか。SSL証明書の更新ができるか。アプリならApp StoreとGoogle Playの開発者アカウントに入れるか。外部サービスのAPIキーや管理画面の情報があるか。

ここが押さえられていないと、本番環境の直接の調査や変更を進められません。業務の聞き取りや、契約書と資料の確認は並行して進められます。証明書やアカウントの更新が切れた時点でサービスが止まることもあるため、期限の確認も含めて見ておきます。

データ

データベースの中身を取り出せるか。管理画面からCSVなどで出せるか、サーバに入って直接取得できるか。顧客の情報や取引の記録が入っている場合、ここが確保できているかどうかで、最悪の場合に失うものが変わります。

取り出せるなら、先にコピーを取っておきます。どの進め方を選んでも、データは引き継ぐことになります。独自の形式で保存されていて取り出し方が分からない場合は、構造を読み解く作業が別に必要になります。

ソースコード

納品されたコードが手元にあるか。それが本番で動いているものと同じ版か。この2つは別に確かめます。納品後に修正が入っていると、手元のコードが古いことがあります。

コードが無い場合でも、サーバに入れるなら、動いているものを取得できる場合があります。ただしコンパイルされた形で配置されている部分は、元のソースコードがそのまま戻るわけではありません。読める形に変換できる場合もありますが、変数名やコメントは失われます。変換してよいかは権利の扱いにも関わるため、別に確認が必要です。

契約書

契約書で見るところは3つに整理できます。

1つめは、権利の帰属です。プログラムの著作権が自社に譲渡されているのか、開発会社に残っているのか、記載そのものが無いのか。

2つめは、他社への開示と、保守の委託や改修が認められる範囲です。譲渡と書かれていても、改変に関わる権利が開発会社に残っている場合があります。著作権法には、著作権を譲渡する契約で第27条または第28条に規定する権利が譲渡の目的として特掲されていないときは、これらの権利は譲渡した者に留保されたものと推定する、という定めがあります（第61条第2項）。第27条は翻案権などで、プログラムを改変する場面に関わります。譲渡と書いてあるかどうかだけでなく、条項の文言まで見る必要があるのはこのためです。

3つめは、契約が終わるときに何をどの形式で引き渡すかです。この条項が無い契約では、終了時に受け取れるものが決まっていません。

ここに挙げたのは一般的な見方で、個別の契約がどう扱われるかは文言と経緯によって変わります。他社に改修を頼めるかどうかの判断が必要な段階では、弁護士に相談してください。契約の書き方については、IPA（情報処理推進機構）が公開している情報システム・モデル取引・契約書も参考になります。

設計書と仕様書

画面の仕様、データベースの構造、外部連携の仕様、環境構築の手順、運用の手順。これらが残っているか、残っているものが現在の動きと合っているかを見ます。

資料が無くても進められないわけではありません。コードを読んで仕様を書き起こす作業になります。ただし、その作業の分だけ費用と期間が増えます。

移管、部分的な置き換え、再構築のどれを検討するか

確認した結果は、進め方を自動的に決めるものではありません。どこまで調べる必要があるかを示す材料です。

資料やコードが無いから再構築、という単純な話にはなりません。再構築する場合も、現行の業務、例外処理、外部連携、移行するデータの確認は必要になります。逆に資料がそろっていても、使っている技術のサポートが終わっている場合や、運用の負担が大きくなっている場合は、再構築のほうが合うことがあります。

見積もりが想定より高いと感じたときは、調査にどれだけの工数が置かれているかを聞いてみると、理由が見えることがあります。1つの画面を直すと別の処理に影響が出る作りになっている場合は、影響の調査に時間がかかります。

改修で延ばせる限界と、リプレースに踏み切る基準については、レガシーシステムは作り直すべきかで扱っています。費用の見方はシステム保守費用の相場と算出方法にまとめています。

会社を変えるだけでは、同じ依存を作り直すことがある

切り替えが難しくなったのは、相手の会社が悪かったからとは限りません。契約と資料の決め方がそのままなら、新しい会社に移ったあとで、同じ状態がもう一度できあがります。

自社で管理できる状態とは、すべての開発や保守を社員だけで行うことではありません。契約、アカウント、コード、データ、運用資料の所在を把握し、必要に応じて依頼先を選び直せる状態を指します。作り替える場合も、この状態を納品と運用の条件に含めておく必要があります。

具体的には、次のことを確認できる状態を目指します。

• サーバ、ドメイン、ストアなどの契約と管理権限を自社で把握できる
• 現在のソースコード、構築手順、設計資料を確認できる
• バックアップを取得し、復元の方法も把握できる
• 別の会社への保守委託や改修に必要な契約条件を確認できる
• 特定の担当者しか知らない作業を減らす

契約の段階で決めておくのは3つです。納品の対象に、ソースコードだけでなく設計書やデータベースの構造図、API仕様、環境構築の手順、運用の手順を含めるか。著作権の帰属と、他社への開示や改修が認められる範囲をどう書くか。契約が終わるときに何をどの形式で引き渡すか。

アカウントの名義も見ておきます。サーバやドメイン、ストアのアカウントが開発会社の名義になっていると、契約終了後の管理権限の確保や、別の会社への移管が難しくなることがあります。コードの保管場所も自社のアカウントに置きます。

揉めていないから大丈夫、という前提ではなく、切り替える可能性がある前提で書けているかが判断の基準になります。発注する側がベンダーとの関係をどう設計するかは、システム開発のベンダーコントロールとはで扱っています。

Enlytでは、いま動いているシステムをこれからどうするか、というご相談もお受けしています。手元に何が残っているかを一緒に確認したうえで、どの進め方が現実的かを整理するところから始められます。これまでの開発についてはEnlytの開発事例をご覧ください。

公的な調査で示されていること

切り替えの難しさは、個々の会社の事情というより、構造として起きるものとして扱われています。公正取引委員会は2022年2月、官公庁における情報システム調達に関する実態調査の結果を公表しています。アンケートは全ての国の機関と都道府県、市区町村の計1,835機関を対象に2021年6月から実施され、1,021機関から回答がありました。回答率は約55.6%です。設問ごとの有効回答数は異なります。

保守や改修、更改の際に既存のベンダーと再度契約することとなった事例があるかを尋ねた設問では、「ある」が1,000機関で98.9%でした（有効回答数1,011）。「ある」と答えた1,000機関に理由を尋ねた結果が次のとおりです。複数回答のため、合計は100%を超えます。

再契約がすべて切り替えられなかった結果というわけではありません。2位の「入札の結果、既存ベンダーが落札したため」は競争が行われた結果ですし、4位にも「技術的には他社にも委託できる」と書かれています。

競争の結果にあたる項目を除いて見ると、多いのは「既存ベンダーしか機能の詳細を把握することができなかった」の48.3%です。次に「機能（技術）に係る権利が既存ベンダーに帰属していた」の24.3%が来ます。ただしこの項目には、報告書の注記によると、市販のパッケージソフトを導入している機関が含まれます。パッケージソフトの権利が提供元にあるのは当然のことなので、受託開発の著作権をどう決めたかという話だけを示す数字ではありません。

報告書に載っている具体的な場面

報告書には、官公庁へのヒアリングで出た意見が載っています。いずれも機関名は示されていません。

ある情報システムの改修にあたって運用主体を他のベンダーに変更することを検討したものの、プログラムの著作権が既存ベンダーに帰属していたため変更できず、再度契約することとなった（国の機関）。何度も改修されてきたシステムで、改修ごとのソースコードの変更履歴を既存ベンダーしか把握できない状態になっており、担当者が変更履歴を理解できていないため他に発注できない（都道府県）。新システムへの移行に際し、既存ベンダーから企業秘密であるとの理由でデータフォーマットの開示がなされず、移行が速やかにできなかったため、つなぎとして既存システムを再度契約することとなった（人口5万人未満の地方公共団体）。

3つとも、権利、知識、データ形式という別の原因が表に出た形です。この調査は官公庁を対象にしたものですが、同じ原因は民間でも起きます。

なお地方公共団体では、基幹業務システムの標準化とガバメントクラウドへの移行が進められています。デジタル庁の資料によると、令和7年度末の時点で対象34,366システムのうち24,353システム（70.9%）が移行を完了し、残る10,013システム（29.1%）は2026年度以降の移行となる見込みです。該当する団体は1,015団体で、全1,788団体の56.8%にあたります。ただしこの遅れには事業者側の人員の不足なども含まれるため、件数をそのまま切り替えの難しさの件数として読むことはできません。

よくある質問

開発会社が廃業していた場合、ソースコードはどうなりますか

開発会社の廃業だけでは、ソースコードの著作権が誰にあるかは判断できません。まず契約上の帰属を確認し、必要に応じて権利の承継先も調べます。コードとアクセス権があっても、第三者による調査や改修が認められるかを確認してから進めます。判断が必要な段階では弁護士に相談してください。

他社に相談するとき、何を用意すればよいですか

確認した5つのうち、何があって何が無いかをまとめたものがあると話が早くなります。無いものを隠さずに伝えたほうが、調べる範囲の見立てが正確になります。

一部だけ切り出して他社に任せることはできますか

できる場合があります。外部連携の部分や新しく作る機能だけを別に開発し、既存部分とはAPIでつなぐ形です。ただし既存システムの仕様が分からないと、つなぐ側の設計ができません。この場合も、先に現状を調べる工程が入ります。

まとめ

ベンダーロックインは、特定の製品やサービス、技術への依存によって、他への切り替えが難しくなる状態です。開発会社を変えられるかどうかを左右するのは、仕組みを知っている人がどこにいるか、権利の扱いがどうなっているか、技術とデータの形式、そして運用の属人化です。

まず確かめるのは、本番環境へのアクセス権、データ、ソースコード、契約書、設計書の5つです。何が欠けているかは、調べる範囲を決める材料であって、進め方を単独で決める基準ではありません。保守の移管、部分的な置き換え、再構築のどれを選ぶかは、それぞれに必要な条件を並べてから判断できます。

そして、会社を変えるだけでは同じ状態をもう一度作ることがあります。契約、アカウント、コード、データ、運用資料の所在を把握し、必要に応じて依頼先を選び直せる状態を、納品と運用の条件に含めておくところまでが見直しの範囲です。

参考にした資料

• 公正取引委員会「官公庁における情報システム調達に関する実態調査について」（2022年2月8日公表）
• デジタル庁「地方公共団体情報システムの標準化・共通化」関連資料（令和7年度末時点の移行状況）
• IPA（情報処理推進機構）「情報システム・モデル取引・契約書（第二版）」
• 著作権法（昭和45年法律第48号）　e-Gov法令検索

金子 遼平

フィリピンの語学学校スタッフとして5年間勤務後、Enlytに参画。 現在はフィリピン在住で完全リモートにて、開発ディレクター・PM・デザイナーとして複数プロジェクトを担当。 UI/UX設計とプロジェクトマネジメントを横断できる点を強みとし、リモート環境下でも安定した品質とスピードを実現している。

View More