ベンダーロックインとは？原因・リスクと抜け出し方をわかりやすく解説

ベンダーロックインとは、システムを作った会社（ベンダー）しか中身がわからず、改修も保守もその会社に頼むしかなくなる状態のことです。

原因は契約の縛りだと思われがちですが、公正取引委員会の調査では「既存ベンダーしか機能の詳細を把握できない」という理由が最も多く挙がっています。この記事では、ロックインが起きる原因とリスク、自社の依存度の確かめ方、すでに陥っている場合の抜け出し方と、これから発注するときの予防策を解説します。

⇒　900件以上の構築実績から生まれた『型』でリスクを抑える。AI駆動セルフ開発ツール『S-MASE』の詳細を見る

ベンダーロックインとは？

ベンダーロックインとは、特定のITベンダーやその製品に頼りきりになり、他社へ乗り換えたくても乗り換えられない状態を指します。問題は「同じ会社と付き合い続けること」ではなく、「付き合い続けるしか選択肢がないこと」です。

家にたとえると、合鍵と間取り図を工務店だけが持っている状態に近いといえます。水回りを直したいときも、リフォームしたいときも、その工務店に頼むしかありません。ほかの業者に見積もりを取ろうにも、家の構造を説明できないからです。

公正取引委員会による定義

公正取引委員会は2022年2月に公表した調査報告書で、ベンダーロックインを次のように定義しています。

情報システムを使い続けるために必要な作業を，それを導入した事業者以外が実施することができないために，特定のベンダーを利用し続けなくてはならない状態のことをいう。

出典：公正取引委員会「官公庁における情報システム調達に関する実態調査報告書」（2022年2月）

ポイントは「導入した事業者以外が実施できない」という部分です。ソフトウェアの改修や保守を他社に頼めない状態が、ロックインの中身だといえます。

「会社への依存」と「技術への依存」の2種類がある

ベンダーロックインは、大きく2つに分けて説明されることが多くあります。1つは、特定の開発会社やその担当者に頼りきりになる「会社への依存」です。もう1つは、特定の製品や独自の技術、データ形式から離れられなくなる「技術への依存」です。

実際には、2つが重なっていることもあります。独自技術で作られたシステムを、その技術に詳しい1社だけが保守しているような場合です。

「ベンダー依存」「囲い込み」とも呼ばれる

ベンダーロックインは、「ベンダー依存」や「囲い込み」と言い換えられることがあります。ロックイン（lock-in）は英語で「閉じ込める」という意味で、顧客が他社に移れないように囲い込まれている状態を表します。

同じ会社に任せ続けること自体は悪くない

同じベンダーに長く任せることには、利点もあります。経緯を知っている担当者に頼めるので話が早く、窓口も1つで済みます。

避けたいのは、「替えようと思えば替えられる」状態を失うことです。いつでも乗り換えられる状態であれば、ベンダーとの付き合いが長くても、競争や交渉の余地は残ります。

ベンダーロックインが起きる原因

48.3%の機関ベンダーロックインの原因は、契約よりも「情報の偏り」にあることが多いと考えられます。中身を知っているのがベンダーだけになると、他社に頼むという選択肢が実質的に消えるからです。

公正取引委員会は2021年6月から、国の機関・都道府県・市区町村の計1,835機関にアンケートを行い、1,021機関から回答を得ました。既存ベンダーと再び契約した経験がある機関は98.9%（1,011機関中1,000機関）です。その理由（複数回答）は次のとおりでした。

調査対象は官公庁ですが、同じ構図は民間企業にも当てはまります。ここからは、原因を4つに分けて見ていきます。

システムの中身を知っているのがベンダーだけ

最も多い原因は、システムの機能の詳細をベンダーしか把握していないことです。再契約の理由として48.3%の機関がこれを挙げています。

仕様書や設計書が作られていない、作られていても改修のたびに更新されていない、という状態が続くと、システムの全体像は担当者の頭の中にしか残りません。こうなると、ほかの会社は見積もりすら出しにくくなります。

プログラムの権利がベンダー側にある

2番目に多いのは、機能（技術）の権利が既存ベンダーにあるという理由で、24.3%でした。開発を依頼した側は「お金を払ったのだから自社のもの」と考えがちです。しかし、ソースコードの著作権などの権利は、契約で取り決めておかなければ開発した会社側に残る場合があります。

権利がベンダーにあると、ほかの会社がそのプログラムを改修したり、別のシステムに流用したりすることが難しくなります。

データの形式や中身をベンダーしか把握していない

既存ベンダーしかデータの内容を把握できなかった、という理由は21.1%でした。データの権利がベンダーにあるという回答も7.1%あります。

システムを乗り換えるときは、蓄積したデータを新しいシステムに移す必要があります。データの形式が独自で、項目の意味も記録されていなければ、移行の作業そのものが既存ベンダーにしかできなくなります。

発注側に判断できる人がいない

発注する側の体制も原因の1つです。同じ調査では、情報システムの専門部署があっても、深い知見を持つ人員が含まれないという回答が52.5%ありました。ベンダーロックインを防ぐための研修を実施している機関は9.0%にとどまります。

ベンダーの提案が妥当か判断できる人が社内にいなければ、仕様も見積もりもベンダーの言うとおりに決まります。その積み重ねが、結果としてロックインにつながります。

ベンダーロックインで起きる問題

ロックインされると、費用・スピード・将来の選択肢の3つの面で、発注側が不利になります。いずれも、ほかの会社と比べられないことから生じる問題です。

改修や保守の費用が下がらない

ほかの会社に見積もりを頼めないため、価格の競争が起きません。改修費用や保守費用が高いと感じても、比べる相手がいないので、妥当かどうかを判断しにくくなります。

改修に時間がかかり、事業の動きに追いつかない

改修を頼める会社が1社しかないと、そのベンダーの人員や優先順位に左右されます。市場の変化に合わせて機能を変えたいときに、対応を待つしかない場面が増えます。

システムの乗り換えや刷新が難しくなる

老朽化したシステムを新しくしたいときも、中身とデータを把握しているのが既存ベンダーだけでは、別の会社に頼む計画を立てにくくなります。結局、同じベンダーに刷新を任せることになり、ロックインが次のシステムに引き継がれることもあります。

DXやレガシーシステムの刷新が進まない

経済産業省は2025年5月の報告書で、「多くのユーザー企業はベンダー企業へ依存し、IT人材が過度にベンダー企業に偏っている」と指摘しています。そのうえで、問題の1つとして「ベンダーロックインにより経営のアジリティが低下」と挙げています。アジリティとは、状況の変化に素早く対応する力のことです。

同じ報告書では、ユーザー企業の61%がレガシーシステム（古い技術や仕組みのまま使い続けているシステム）を保有していると示されています。

自治体・官公庁でベンダーロックインが問題になっている理由

ベンダーロックインは、自治体や官公庁で特に問題として取り上げられてきました。先に紹介した公正取引委員会の調査が官公庁を対象にしていたのも、そのためです。

官公庁では、システムの調達を入札で行います。しかし、既存システムの中身を把握しているのが既存ベンダーだけだと、入札をしても実質的に1社しか応じられません。調査では、担当者が既存システムの仕様やソースコードの変更履歴を把握できず、既存ベンダー以外に発注できない状況が報告されています。担当者が少ない小規模な自治体では、人員や予算の不足も課題として挙げられています。

公正取引委員会は、仕様書の作り方やデータの標準化、オープンな技術の活用などについて考え方を示し、デジタル庁と連携して周知を進めるとしています。担当者の異動で知識が引き継がれない、仕様をベンダーに頼ってしまう、という構図は民間企業でも起こりうるものです。

自社のベンダーロックインの度合いを確認する

ここまでの原因を、自社に当てはめて確かめてみましょう。当てはまるものが多いほど、ロックインの度合いは高いと考えられます。

観点	確認すること
権利	ソースコードや成果物の権利が、どちらにあるか契約書で確かめられるか
データ	自社のデータを、一般的な形式（CSVなど）で書き出せるか
ドキュメント	仕様書・設計書が、直近の改修内容まで反映されているか
人	システムの全体像を説明できる人が社内にいるか
契約	保守契約の期間・解約条件・引き継ぎへの協力が書かれているか

すべてを満たす必要はありません。ただし、「わからない」と答えた項目があれば、そこが最初に手を付けるべき場所です。

ベンダーロックインから抜け出す方法

すでにロックインされている場合は、いきなり乗り換えるのではなく、手元に情報を取り戻すことから始めます。順番を誤ると、乗り換えの途中でデータや仕様が引き継げずに止まってしまうからです。

依存している範囲を棚卸しする

最初に、どのシステムが、どのベンダーに、どの程度依存しているかを一覧にします。システムごとに、担当ベンダー、契約内容、保守費用、ドキュメントの有無を書き出すだけでも、手を付ける順番が見えてきます。経済産業省の報告書でも、自社のシステムの状況を棚卸しし、IT資産を可視化することが対策として挙げられています。

仕様書と設計書を今の状態に合わせる

次に、仕様書や設計書を、現在のシステムの状態に合わせて整えます。ほかの会社が中身を理解できる資料があれば、それだけで「既存ベンダーしか把握できない」状態から一歩抜け出せます。資料の作成を既存ベンダーに依頼する場合は、作業範囲と費用を事前に確かめておきます。

権利とデータの持ち出し条件を確かめる

契約書を見直し、ソースコードや成果物の権利がどちらにあるか、データをどの形式で受け取れるかを確かめます。契約に書かれていない場合は、既存ベンダーと話し合って取り決めます。

なお、公正取引委員会の調査では、既存ベンダーから仕様の開示やデータの引き継ぎを合理的な理由なく拒否されたという回答が2.1%ありました。公正取引委員会はこのような行為について、独占禁止法上問題となるおそれがあるという考え方を示しています。

小さな範囲から切り出して移す

システム全体を一度に乗り換えるのは、費用もリスクも大きくなります。外部とつなぎやすい機能や、更新頻度の高い機能など、切り出しやすい部分から別の会社や別の技術に移していく方法があります。公正取引委員会も、システムを小さな単位に分けて調達することは新規参入を促し、競争の面で望ましいとしています。

社内に判断できる人を置く

最後に、ベンダーの提案や見積もりを判断できる人を社内に置きます。すべてを自社で開発する必要はありません。仕様を決め、提案を比べ、ベンダーに説明を求められる人がいれば、主導権を取り戻せます。

SIer・保守契約を見直すときの観点

大手のSIer（システムの開発と運用をまとめて請け負う会社）に長く任せている場合は、保守契約の見直しから始めるのが現実的です。保守の範囲、費用の内訳、契約期間と解約の条件、契約終了時に受け取れる資料とデータを確かめます。費用の内訳が「保守一式」のようにまとめられているなら、作業ごとに分けて説明してもらうと、他社と比べやすくなります。

開発会社を乗り換えるときは引き継ぎ範囲を先に決める

開発会社そのものを替えると決めた場合は、新しい会社を探す前に、何を引き継ぐかを決めておきます。ソースコード、データ、仕様書、サーバーの設定、アカウントの権限などです。引き継ぎの期間中は、既存ベンダーの協力が欠かせないため、契約終了の時期にも余裕を持たせます。

これから発注するときにベンダーロックインを防ぐ方法

新しくシステムを発注するときは、契約前の決め方でロックインの起きやすさが大きく変わります。後から取り戻すより、最初に決めておくほうが費用も手間もかかりません。

要件と仕様は自社が主導して決める

何を作るかを決める要件定義や仕様の作成を、ベンダーに任せきりにしないことが基本です。提案依頼書（RFP）を自社で作り、複数の会社から提案を受ければ、特定の会社に有利な仕様になるのを防げます。書き方は「０から分かる！RFP（提案依頼書）の書き方解説」をご覧ください。

権利・データ・ドキュメントの扱いを契約で決める

契約の段階で、ソースコードや成果物の権利の帰属、データの受け取り方、納品してもらうドキュメントの範囲を決めておきます。IPA（情報処理推進機構）は、システム開発の契約書のひな形として「情報システム・モデル取引・契約書」を公開しています。自社の契約書と見比べる際の参考になります。

標準的な技術とつなぎやすい設計を選ぶ

広く使われている技術や、外部のシステムとつなぐための仕組み（API）を持つ設計を選ぶと、別の会社でも扱いやすくなります。公正取引委員会も、オープンソースや汎用的な技術を使った仕様は新規参入を促し、ロックインを防ぐ観点から望ましいとしています。

AI開発ツールやプラットフォームを選ぶときに確認したいこと

最近は、AIを使った開発ツールや、ひな形をもとにシステムを作るプラットフォームを使う選択肢も増えています。開発の手間は減りますが、ツールやサービスそのものに依存する「技術へのロックイン」には注意が必要です。

契約前に聞いておきたい4つの質問

どの会社のツールやサービスを使う場合でも、契約前に次の点を確かめておくと安心です。

質問	確かめたい理由
作ったシステムのソースコードや設定は、自社で受け取れるか	他社やほかの技術に移す必要が出たときの選択肢を残すため
データは一般的な形式で書き出せるか	乗り換えの際に、データ移行が既存の会社にしかできない状態を避けるため
解約したとき、システムとデータはどうなるか	解約の時点で使えなくなるのか、引き継げるのかを把握するため
自社で直せる範囲と、依頼が必要な範囲はどこか	小さな修正まで依頼が必要だと、費用とスピードの面で不利になるため

AI駆動開発の会社を選ぶ際の確認項目は、「AI駆動開発会社の選び方｜3つのタイプと依頼前に確認したい7つのこと」でも詳しく解説しています。

自社で開発を進められる体制をつくるという選択肢

ロックインの主な原因は、中身を知っているのがベンダーだけになることでした。そのため、発注する側が自分で作り、自分で直せる体制を持つことは、有効な対策の1つです。ただし、社内にエンジニアを抱えるのは、多くの会社にとって簡単ではありません。

弊社の「カスタメディアプラットフォーム」では、お客様ご自身がAI駆動セルフ開発ツール「S-MASE」を使って開発を進め、カスタメディアが伴走します。900件以上の構築実績から生まれた「型」をもとに、マッチング、EC、クラウドファンディング、コミュニティなどのプラットフォームを作れます。検討する場合は、上の4つの質問もあわせてご確認ください。

よくある質問

まとめ｜ベンダーロックインは「中身を自社が把握する」ことから防げる

ベンダーロックインとは、システムを作った会社しか中身がわからず、他社に乗り換えられなくなる状態です。公正取引委員会の調査では、既存ベンダーと再契約した理由として「既存ベンダーしか機能の詳細を把握できなかった」が48.3%で最も多く、権利の問題を上回っていました。

すでにロックインされている場合は、依存している範囲の棚卸し、ドキュメントの整備、権利とデータの確認から始め、小さな範囲から切り出していきます。これから発注する場合は、要件と仕様を自社で決め、権利・データ・ドキュメントの扱いを契約で取り決めておくことが予防になります。AI開発ツールやプラットフォームを使うときも、何を自社に残せるかを契約前に確かめておきましょう。

ベンダーに頼りきらないシステムづくりを相談したい方へ

カスタメディアでは、新規事業のプラットフォームを、お客様ご自身が主導して開発する進め方をご提案しています。「今のシステムを自社で直せるようにしたい」「次のシステムはベンダー任せにせず作りたい」といった段階からご相談いただけます。課題の整理から開発の進め方まで、まずはお気軽にお問い合わせください。

⇒　900件以上の構築実績から生まれた『型』でリスクを抑える。AI駆動セルフ開発ツール『S-MASE』の詳細を見る