LASSIC Media らしくメディア

2026.09.09 採用支援コラム

ベンダーロックインの対策|作った会社しか改修できない状態の抜け方

監修・編集責任者:牛尾 昭昌(株式会社LASSIC 執行役員)

錆びた赤い金属板に鍵穴が1つ開いている様子を近くから写したもの

この記事の結論

  • IPAの調査データを集計すると、ベンダーロックインの対策を1つ以上挙げた企業は51.1%でした。
  • 多く挙がったのは、オープン標準の採用の31.5%と、仕様や設計情報の可視化の27.6%です。
  • どのシステムの情報を手元に置くかは社内で決め、仕様書などを書き出す作業だけを委託すると始めやすくなります。

※ 本記事は2026年9月時点の公式情報(省庁・公的機関、および製品やサービスを提供する事業者が公開している資料)に基づきます。

そのシステムを改修できるのが、作った会社1社だけ。見積を取れる相手が1社しかなく、期間も相手の都合で決まってしまう——。長く使っている業務システムでは、こうした状態が起こりがちです。ベンダーロックインとは、特定の開発会社や製品に頼りきりになり、ほかの会社に切り替えたり、自社で改修したりするのが難しくなった状態を指します。

対策には、広く使われている技術を選ぶ、仕様や設計の情報を書き出して手元に残す、といった自社で始められるものがあります。ただし万能ではなく、どの対策もそれだけで解決するわけではありません。何をどこまで実施すればよいかは、システムごとに違います。本記事では、エンジニアの体制を考える実務担当者に向けて、企業が実際にとっている対策、企業規模による違い、社内で決めることと委託する作業の分け方、そして外部に委託するときに確認したい点を整理します。

ベンダーロックインとは

ベンダーロックインは、何に頼りきりになっているかで、主に4つに分けられます。1つ目は技術や製品です。その会社にしか扱えない仕組みで作られていると、ほかの会社では改修しにくくなります。2つ目は情報です。仕様書や設計書が作った会社の中にしかなければ、社内でもほかの会社でも、どこを直せばよいかを判断できません。

3つ目はシステムの作りです。ある機能を直すと別の機能も直す必要があるような作りだと、一部だけをほかの会社に任せられず、全体を作った会社に頼むしかなくなります。4つ目は契約です。ソースコード(プログラムの本文)が誰のものかを契約で決めていないと、手元にあっても、あとで扱いに迷うことがあります。

長く動いているシステムほど、改修できる会社は限られていきます。作った会社に情報が集まるからです。問題なく動いているうちは困りませんが、困るのはシステムが止まったときや、改修の期間や費用を自社で決めたいときです。システムの仕組みを説明できる人が作った会社にしかいないと、社内で判断ができません。

企業がとっている4つの対策

企業が実際にどんな対策をとっているかは、IPA(情報処理推進機構)の「2025年度ソフトウェア動向調査」から分かります。国内企業を対象にした調査で、2026年2月9日時点で362件の回答があり、回答は匿名化してオープンデータとして公開されています。*1 その中のQ6-3が、ベンダーロックインを回避・軽減するために実施している取り組みを、当てはまるものすべて選んでもらう設問です。*3

IPA「2025年度ソフトウェア動向調査」Q6-3の公開CSVから集計した図。ベンダーロックインを回避・軽減するために実施している取り組み(全体362件、複数回答)は、オープン標準やデファクトスタンダードな技術・製品の採用31.5%、仕様や設計情報の可視化27.6%、疎結合化やモジュール化18.5%、知的財産権やソースコードの帰属の契約書への明記6.6%、わからない18.0%、その他4.4%、特になし/ベンダーロックインはない28.2%。4つの防止策のいずれかを挙げた企業は185件51.1%、わからないか特になしを選んだ企業は167件46.1%。従業員数別では300人以下と301人以上で、オープン標準22.4%と45.5%、可視化19.2%と40.6%、疎結合化11.0%と30.1%、契約書への明記3.2%と11.9%。差の順と倍率の順は入れ替わる。社内で決めることと委託する作業を分ける4つの手順も示す。

公開されている調査結果のCSVから集計すると、いちばん多いのは「オープン標準やデファクトスタンダードな技術・製品を採用している」で、114件、31.5%でした。*2 オープン標準は仕様が公開されている技術の決まり、デファクトスタンダードは広く使われて事実上の標準になった技術のことです。次いで「仕様や設計情報の可視化を行い、ブラックボックス化を防いでいる」が100件、27.6%でした。作った会社の外からは中身が分からない状態を、情報を書き出して防ぐ取り組みです。

3番目は「システムの疎結合化やモジュール化を意識して設計・構築している」で、67件、18.5%です。疎結合化やモジュール化は、機能を部品ごとに切り離し、一部だけを入れ替えられるようにする作り方を指します。いちばん少ないのは「知的財産権やソースコードの帰属を契約書に明記している」で、24件、6.6%にとどまりました。*2

上の3つは、どれも自社で始められる作業です。使う技術を選ぶ、情報を書き出す、機能を切り離して入れ替えやすく作る——いずれも契約を結び直さなくても着手できます。一方で、この設問は当てはまるかどうかを聞いたもので、各社がどこまで実施しているか、実施して実際にほかの会社へ切り替えられたかは公表されていません。

対策を挙げた企業と挙げていない企業

回答した企業1社ずつについて、対策を1つでも選んだかを数えると、4つの対策のいずれかを挙げた企業は185件で、51.1%でした。*2 反対に、「わからない」または「特になし/ベンダーロックインはない」を選んだ企業が167件で46.1%、「その他」だけを選んだ企業が10件で2.8%です。この3つのグループを足すと362件になります。何らかの対策を挙げた企業は、半分をわずかに超える程度ということです。

挙げていない側には、そもそも頼りきりになる心配がない企業と、対策をまだ決めていない企業の両方が含まれます。「特になし」と「ベンダーロックインはない」が1つの選択肢にまとめられているため、両者の内訳は分かりません。

1社がいくつの選択肢を選んだかにも偏りがあります。選択肢は「わからない」などを含めて7つあり、選ばれた選択肢の総数は488でした。362件で割ると1社あたり平均1.35個で、1つだけ選んだ企業が276件、76.2%を占めます。*2 複数回答なので、7つの比率を足すと134.8%になります。

企業規模による違い

従業員数で300人以下(219件)と301人以上(143件)に分けると、4つの対策はいずれも301人以上のほうが多く挙げていました。*2 オープン標準の採用は22.4%に対して45.5%、可視化は19.2%に対して40.6%、疎結合化は11.0%に対して30.1%、契約書への明記は3.2%に対して11.9%です。

ベンダーロックインを回避・軽減するために実施している取り組み(IPA「2025年度ソフトウェア動向調査」Q6-3の公開CSVから集計。複数回答。差は集計値から計算)
選択肢 全体(362件) 300人以下(219件) 301人以上(143件) 差
オープン標準やデファクトスタンダードな技術・製品を採用している 31.5% 22.4% 45.5% 23.1ポイント
仕様や設計情報の可視化を行い、ブラックボックス化を防いでいる 27.6% 19.2% 40.6% 21.4ポイント
システムの疎結合化やモジュール化を意識して設計・構築している 18.5% 11.0% 30.1% 19.1ポイント
知的財産権やソースコードの帰属を契約書に明記している 6.6% 3.2% 11.9% 8.7ポイント
わからない 18.0% 22.8% 10.5% 12.3ポイント低い
その他 4.4% 3.7% 5.6% 1.9ポイント
特になし/ベンダーロックインはない 28.2% 32.9% 21.0% 11.9ポイント低い

反対に、301人以上のほうが少ないのが「わからない」と「特になし」です。「わからない」は300人以下が22.8%、301人以上が10.5%で、「特になし」は32.9%と21.0%でした。対策を1つも挙げていない企業は、300人以下で122件、55.7%、301人以上で45件、31.5%です。*2 両者の差は24.2ポイントあり、300人以下では半分を超える企業が対策を挙げていないことになります。

差と倍率で変わる見え方

規模による違いを比べるときは、差で見るか倍率で見るかで順番が変わります。301人以上と300人以下の差を計算すると、オープン標準が23.1ポイント、可視化が21.4ポイント、疎結合化が19.1ポイント、契約書への明記が8.7ポイントです。倍率で見ると、契約書への明記が3.72倍、疎結合化が2.74倍、可視化が2.11倍、オープン標準が2.03倍になり、順番がちょうど逆になります。

倍率で契約書への明記がいちばん大きくなるのは、300人以下の割合が3.2%と低いためです。件数にすると、300人以下が7件、301人以上が17件にすぎません。倍率だけを見ると「規模でいちばん差がつくのは契約」と受け取りがちですが、規模による違いがよく表れているのは、実施している企業の割合の差のほうです。差と倍率を並べて見ておけば、倍率だけで判断せずにすみます。

社内で決めることと委託する作業

ここまでの結果をふまえ、自社で始める手順を4つに分けると、次のようになります。

  • 作った会社しか手を入れられないシステムを1つ選ぶ
  • そのシステムの仕様書や設計書のうち、手元に無いものを書き出す
  • 情報を書き出す作業と、どの情報を社内で持つかを決める作業を分ける
  • 書き出す作業を、期限を決めて外部に委託する

1つ目は、すべてのシステムを洗い出そうとせず、止まると業務が困るものから1つに絞ることです。最初から対象を広げるより、1つのシステムで手順を一通り終えるほうが、社内の担当者の負担が読みやすく、続けやすくなります。

2つ目は、足りない情報の書き出しです。仕様書や設計書がそろえば、社内で判断できることが増えます。画面や帳票の一覧、ほかのシステムとのデータのやり取り、設計書の有無など、何が手元に無いかが分かれば、誰にどの作業を頼むかも決めやすくなります。

3つ目は、作業と判断を分けることです。情報を書き出す作業は手間がかかりますが、何を書き出すかが決まっていれば社外の人にも任せられます。一方で、どのシステムを社内で持ち続けるか、どの情報を手元に置いておくかの判断は、社内の担当者が持っておきます。

4つ目は、書き出す作業の委託です。社内の担当者だけで着手するのが難しい場合は、作業量の見当がつく部分から、「現行システムの画面と帳票の一覧を作る」のように作業名と期限を決めて頼むと、終わったあとの引き継ぎもしやすくなります。

つまずきやすい点

一つ目は、判断まで委託してしまうことです。どのシステムから始めるか、何が足りないかを決めるところまで委託先に任せると、何を社内に持つかを決めるのも社外の人になります。頼りきりになる相手が、別の会社に移るだけになりかねません。

二つ目は、契約を後回しにすることです。ソースコードの帰属を契約書に明記している企業は6.6%と、4つの対策の中でいちばん少なくなっています。書き出した仕様書や設計書、作ったプログラムを誰がどう使えるのかは、委託を始める前の契約で決めておくと、あとで扱いに迷わずにすみます。

三つ目は、ほかの企業の数字だけを見て、優先する対策を決めてしまうことです。調査の結果は、どの対策が挙がりやすいかの参考にはなりますが、自社のシステムで何が足りないかは示していません。同じ調査の、長年使っている古いシステムの刷新が進まない理由は「レガシー刷新を止めるのは理解不足ではなく要員の不足」で、工程ごとに社内と外部をどう分けているかは「工程別の内製化|設計開発テストだけ委託が34.4%」で扱っています。

まとめ:ロックイン対策で確かめておきたい3つの点

ベンダーロックインの対策を進めるうえで、確かめておきたい点は3つに整理できます。第一に、作った会社しか手を入れられないシステムを1つ選び、仕様書や設計書のうち手元に無いものを書き出すこと。第二に、情報を書き出す作業と、どの情報を社内で持つかを決める作業を分け、判断は社内の担当者が持つこと。第三に、書き出す作業を委託するときは作業名と期限を決め、できあがった資料やプログラムを誰が使えるかを契約で決めておくことです。この3点を踏まえておけば、「委託先を替えたのに、また1社にしか頼めなくなった」という事態を避けやすくなります。社内の担当者だけで進められるかに迷いがあれば、外部の手を借りるのも一つの選択肢です。

LASSICに相談するメリット

手元に無い情報を書き出したあとも、その作業を誰が担当するかが残ります。300人以下では、対策を挙げていない企業が半分を超えています。社内の担当者の手が空くのを待つより、作業と期限を決めて外部の専門人材に加わってもらうほうが進めやすくなります。

Remoguは、株式会社LASSICが運営するフリーランス・業務委託のITプロ人材サービスです。リモート前提で全国から登録が集まっており、登録は約20,000名規模、その約8割が開発系です。人材が必要になった時点から4時間以内に候補者を提案し、最短1週間で実際の業務開始まで進みます(条件によっては実現できない場合があります)。

よくある質問

ベンダーロックインは、すべて解消しなければいけませんか

すべてを急いで解消する必要はありません。問題なく動いていて改修の予定も無いシステムより、止まると業務が困るシステムや、これから大きく手を入れるシステムから優先するのが現実的です。

委託の契約書には、何を書いておけばよいですか

調査の選択肢に挙がっているのは、知的財産権とソースコードの帰属を契約書に明記することです。*3 あわせて、委託先が作った仕様書や設計書などの資料を、社内やほかの会社が使えるかどうかも決めておくと、委託先を替えるときに迷わずにすみます。

この記事の数値は、どこで確かめられますか

IPAの「2025年度ソフトウェア動向調査」のページで、調査結果のCSVと設問一覧が公開されています。*1 本記事の比率は、そのCSVのQ6-3と従業員数の回答から集計した値です(確認日2026年9月9日)。

ベンダーロックインの対策を相談したいとき

手元に無い情報の洗い出しと、どの作業を委託するかの整理からご相談いただけます。

Remoguとリラシクなら、リモートワークで働く社員の候補者も、業務委託で開発に加わる専門人材も探せます。

Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。

無料相談はこちら

出典

  1. *1 参考:IPA「2025年度ソフトウェア動向調査」(https://www.ipa.go.jp/digital/software-survey/software-engineering/software2025.html)。出典:IPA「2025年度ソフトウェア動向調査」。公開日2025年11月25日・最終更新日2026年5月13日、回答対象が国内企業、2026年2月9日時点で362件の回答、匿名化してオープンデータとして公開していることを参照(2026年9月確認)
  2. *2 参考:IPA「2025年度ソフトウェア動向調査 調査結果(選択肢項目文字列)」(https://www.ipa.go.jp/digital/software-survey/software-engineering/j5u9nn000000hkhs-att/software2025-result-data-str.csv)。出典:同調査の調査結果CSV。Q6-3とQ1-7(従業員数)の回答を集計した元データ。本記事の比率・件数・ポイント差・倍率はこのCSVから集計・計算した値。単純集計グラフのPDFは図が画像で比率を文字として取り出せないため、CSVから集計した(2026年9月確認)
  3. *3 参考:IPA「2025年度ソフトウェア動向調査 設問一覧」(https://www.ipa.go.jp/digital/software-survey/software-engineering/j5u9nn000000hkhs-att/software2025-c-questions.xlsx)。出典:同調査の設問一覧。Q6-3の設問文・7つの選択肢・回答種別(複数選択)と、Q1-7の従業員数の区分を参照(2026年9月確認)




View