ベンダーロックインとは？原因と回避策・契約で押さえる条項とリプレイスの判断基準

ベンダーロックインとは、システムの改修や保守を導入したベンダー以外が担えず、特定の事業者を使い続けるしかなくなった状態を指します。公正取引委員会が官公庁1,835機関を対象にした調査では、既存ベンダーと再び契約した経験がある機関が98.9%に達しました。この記事では、ロックインが起きる原因を契約・納品物・技術・体制に分けて説明し、発注前に契約で押さえる条項、クラウドの退出費用をめぐる最新の制度、ロックインされた後にリプレイスへ進むかどうかの判断基準までを、発注者の立場で整理します。

まとめ｜ベンダーロックインは引き継げない状態で、契約と納品物で大半を防げる

ベンダーロックインの本質は「他社が引き継げない」ことです。原因の多くは技術の難しさより、著作権の扱い、設計書の納品範囲、データの返し方、契約終了時の協力義務を決めないまま発注したことにあります。発注前の契約でこの4点を書面に残せば、技術的な依存が残っても乗り換えの道は閉ざされません。

クラウドでは、AWSとGoogle Cloudが退出時のデータ転送料を無料にする手続きを用意し、EUデータ法は2027年1月12日から乗り換え料金を禁止します。退出費用は以前より下がりましたが、独自サービスへの作り込みは費用では解けません。

すでにロックインされている場合は、現行ベンダーに頼らず現行システムを可視化できるかが分かれ目です。可視化できて保守費が上がり続けているならリプレイスを検討し、業務が安定していて改修予定が少ないなら継続を選んでかまいません。

ベンダーロックインとは何か｜公取委の定義と2種類のロックインの違い

公正取引委員会の定義と官公庁1,835機関の調査で見えた実態

公正取引委員会は2022年2月8日公表の官公庁における情報システム調達に関する実態調査で、ベンダーロックインを「機能改修やバージョンアップ、ハードウェアのメンテナンスなど、情報システムを使い続けるために必要な作業を、導入した事業者以外が実施できないために、特定のシステムベンダーを利用し続けなくてはならない状態」と定義しました。

調査は国の機関と地方公共団体の計1,835機関へのアンケートで、回答機関の98.9%が既存ベンダーと再度契約した経験があると答えています。ベンダーから自社や特定企業しか対応できない機能を仕様書に盛り込むよう求められた、または提示されたと答えた機関も39ありました。報告書は対策として、システムの疎結合化、オープンな仕様での設計、発注者側の組織・人員体制の整備を挙げ、ベンダーの行為によっては独占禁止法上の問題になりうるとの考え方も示しています。

民間企業の調査ではありませんが、発注側に仕様を判断できる人が少ない構造は中堅・中小企業にもそのまま当てはまります。

コーポレートロックインとテクノロジーロックインの依存先による見分け方

ロックインは、何に縛られているかで2種類に分けて考えると対策が選びやすくなります。

実務で先に手を打つべきはコーポレートロックインです。独自製品を使っていても、設計書とソースコードとデータが手元にあれば別の会社が保守を引き継げます。逆に標準的な技術で作られていても、権利と資料が手元に無ければ乗り換えられません。

ベンダーロックインが起きる原因｜契約・納品物・技術・体制の4つの要因

著作権と納品物の範囲を決めずに契約する問題と著作権法61条2項

受託開発で作られたプログラムの著作権は、契約で定めなければ作った側、つまりベンダーに残ります。著作権を譲り受ける契約にした場合でも、著作権法第61条2項により、翻案権などを定める第27条・第28条の権利は「譲渡の目的として特掲されていないとき」譲渡した側に留保されたものと推定されます。改修の権利が明記されていない契約では、他社に改修を頼むこと自体が争いの種になりうるのです。

権利の帰属と利用許諾の考え方は、ソースコードの著作権は誰のものかを判例やAI生成コードまで含めて解説した記事で詳しく扱っています。ここで押さえるべきは、権利の条文より先に「何を納品物とするか」を決めることです。ソースコード、設計書、テスト仕様書、運用手順書、構成情報が納品物に入っていなければ、権利を持っていても引き継ぐ材料がありません。

設計書と運用手順が保守ベンダーの担当者の頭の中にしか無い状態

初回の開発時には設計書が揃っていても、保守契約の中で小さな改修を何年も重ねるうちに、資料が更新されなくなるのが典型的な経緯です。改修のたびに見積もりと作業だけが行われ、設計書の更新が作業範囲に入っていないためです。

この状態が5年、10年と続くと、仕様を知っているのは保守ベンダーの特定の担当者だけになります。担当者が異動や退職をすると、現行ベンダー自身も改修見積もりの精度を落とすことになるのです。保守契約に「改修時の設計書更新」を作業として含め、年に1回は最新版を受け取る運用にしておくと、この経路はほぼ塞げます。

独自製品・独自APIへの依存とクラウドの退出費用が生む乗り換えの縛り

パッケージ製品の独自のデータ形式、クラウド事業者固有のマネージドサービス、特定SaaSのAPIに深く作り込んだ処理は、テクノロジーロックインの代表例です。移行先に同じ機能が無ければ、作り直しになります。

クラウドでは、データを外へ出すときの転送料（エグレス料金）も乗り換えの障壁でした。大量のデータを持つほど、出すだけで費用がかかるためです。この費用は2024年以降に制度面で大きく変わったので、後半の章で具体的に扱います。

発注側に仕様を判断できる担当者がいない体制とベンダー任せの見積もり

公取委の報告書も、発注側の人員体制が十分でないことをロックインの要因の一つに挙げています。仕様書をベンダーに書いてもらい、その仕様で入札や相見積もりをすれば、書いたベンダーに有利な条件になりやすいのは当然です。

社内にエンジニアを抱える必要はありません。要件を自社の言葉で書き、見積もりの妥当性を第三者に確かめられる担当者を1人置くだけで、比較できない状態はかなり解消します。

ベンダーロックインのデメリットと発注側が受け入れてよい場面の線引き

保守費の上昇と現行システムの改修見積もりを他社と比較できなくなる仕組み

ロックインの実害は、価格の比較ができなくなることです。他社に相見積もりを頼んでも、現行システムの資料が無ければ他社は正確に見積もれず、結果として現行ベンダーの見積もりを受け入れるしかありません。

もう一つの実害は、技術の更新が遅れることです。OSやミドルウェアのサポート終了が近づいても、改修を担える会社が1社しかなければ、その会社の繁閑で更新の時期が決まります。こうして古い構成のまま使い続けた結果がレガシーシステムで、刷新の進め方はレガシーシステム脱却の判断基準と進め方で整理しています。

ロックインをあえて受け入れてよい2つの条件と独自業務で避けるべき場面

すべての依存を避ける必要はありません。次の2つを両方満たすなら、特定ベンダーへの依存は合理的な選択です。

• 業務の差別化に関わらず、要件が数年単位で変わらない領域である（会計、勤怠など）
• 製品の提供元が事業として継続し、データを標準的な形式で出力できる

反対に、売上に直結する独自業務を、資料もデータ出力手段も無い個別開発で特定の1社に任せるのは避けるべき場面です。依存の深さそのものより、依存を解く手段が残っているかで判断します。

契約で押さえる条項｜発注前に確認する権利・納品物・データ・退出支援の項目

権利帰属・納品物・データ返還・引継ぎ協力を確認する5項目の一覧

契約書の雛形には、IPAが公開している情報システム・モデル取引・契約書（第二版）が参考になります。ユーザー企業とITベンダーのどちらにも偏らない契約を目指して作られたもので、著作権の帰属は複数の選択肢から選ぶ形式になっています。ロックイン対策として確認する項目は次のとおりです。

優先順位をつけるなら、納品物の範囲とデータ返還が先です。著作権の譲渡はベンダーが汎用部品の権利を手放せないことも多く、利用許諾と改変の許諾で足りる場面がほとんどだからです。

退出支援条項の協力期間・単価と発注先選定の段階で確かめておく姿勢

契約終了時の協力義務は、関係が良好なうちにしか合意できません。終了の何か月前に通知すれば、何か月間、どの単価で引継ぎに協力するかを数字で書いておきます。

条項の文言だけでなく、提案段階でベンダーがこれらの条件にどう答えるかも判断材料になります。設計書の更新や引継ぎ協力を嫌がるベンダーは、選定の評価を下げてかまいません。評価項目の作り方はベンダー選定の流れと評価表の配点設計で解説しています。

クラウドとSaaSのロックイン対策｜退出費用の無料化とEUデータ法の期限

AWSとGoogle Cloudが用意した退出時のデータ転送料無料化の条件

AWSは2024年3月5日、AWSから他の環境へ移る際のインターネット向けデータ転送料を無料にする手続きを公式ブログで公表しました。AWSサポートに申請し、承認されると移行するデータ分のクレジットが付与されます。EU以外の顧客は180日以内に移行を終える必要があり、2026年10月8日の追記では、適格なアカウントのすべてのデータ、または特定サービスのデータ全量を移す場合が対象と明記されました。もともと月100GBまではリージョンからの転送が無料で、この制度はそれを超える分が対象です。

Google Cloudも退出時の無料データ転送の申請窓口を設けています。どちらも「一部だけ外へ出す」用途には使えず、移行として申請する必要がある点は共通です。

EUデータ法が2027年1月12日に禁止するクラウド乗り換え料金の範囲

EUのデータ法（Data Act）は2025年9月12日に適用が始まり、クラウド事業者を乗り換える顧客の権利を定めました。フランスの電気通信規制機関ARCEPが2026年7月2日に出したプレスリリースは、データ法第29条に基づき、乗り換え料金が2027年1月12日から禁止されると説明しています。

国内企業の国内契約に直接及ぶ規制ではありません。それでも大手事業者は退出手続きを整備しており、AWSもEU顧客向けにデータ法の付属合意を設けています。退出費用は個別交渉で下げるものから、制度として下がるものへ変わりつつあります。

マルチクラウドやIaCで抽象化する前に移行費用と比べる二重運用の費用

ロックイン対策としてマルチクラウドや抽象化レイヤーの構築がよく挙げられますが、中堅企業の業務システムでは多くの場合過剰です。2つのクラウドを同時に運用すると、監視・権限管理・障害対応の手順がすべて二重になり、その費用は将来の移行費用を上回りがちです。

実務での優先順位は、データを標準形式で出せること、インフラ構成をTerraformなどのコードで記録しておくこと、クラウド固有サービスを使う箇所を設計書に一覧化しておくこと、の順です。監視基盤を特定製品に縛られない形で組むなら、OpenTelemetryの仕組みとCollectorの導入手順が参考になります。

ロックインされた後の脱却とリプレイス判断｜現行調査から切替までの進め方

現行ベンダーに頼らず契約・資料・費用から現行システムを可視化する4つの手順

脱却の第一歩は、現行ベンダーの協力が得られなくても進められる調査です。

1. 契約書と過去の納品物を集め、手元にある資料と権利の範囲を確定する
2. 画面・帳票・外部連携・バッチの一覧を、利用部門への聞き取りで作る
3. データベースのテーブル一覧と件数を、出力できる範囲で取得する
4. 過去3年の保守費と改修費を集計し、毎年の増え方を把握する

この調査結果が、他社に見積もりを依頼するときの現行情報になります。どこまで開示すれば提案の精度が上がるかは、システム刷新のRFPで開示する現行情報の範囲を参照してください。

保守費と改修予定から判断するリプレイスへ進む条件と現行ベンダーとの継続条件

判断は次のように言い切れます。保守費が3年続けて上がり、改修の見積もりを他社と比べられず、OSやミドルウェアのサポート終了が2年以内に迫っているなら、リプレイスを前提に動くべきです。逆に、業務が安定していて改修予定が少なく、現行ベンダーが設計書の更新と引継ぎ協力に応じるなら、継続して契約条件だけを直すほうが費用もリスクも小さく済みます。

失敗しやすいのは、資料が無いまま「同じものを別の会社で作り直す」発注です。現行の仕様を誰も説明できないため、移行後に機能の抜けが見つかります。可視化の調査を先に済ませ、移行方式の選定と切替計画まで一続きで進めることが要点です。現行ベンダーからの乗り換えを含む刷新は、一創のシステムマイグレーション・リプレイスで現行調査の段階から相談できます。

よくある質問

ベンダーロックインについて、発注側の担当者から寄せられることの多い質問をまとめました。

ベンダーロックインは違法なのですか？

ロックインの状態そのものは違法ではありません。製品の選択や契約の結果として特定のベンダーを使い続けることは、通常の取引の範囲です。ただし公正取引委員会は2022年の報告書で、競合他社を排除する目的で仕様書に特定企業しか対応できない機能を入れさせるなど、ベンダーの行為によっては独占禁止法上の問題になりうるとの考え方を示しています。違法かどうかは状態ではなく、ベンダーの具体的な行為で判断されます。

ベンダーロックインを完全に防ぐことはできますか？

完全に防ぐことはできませんし、目指す必要もありません。どの製品やクラウドを選んでも、ある程度の依存は生まれます。目指すべきは、依存を解く手段を残しておくことです。具体的には、ソースコードと設計書を納品物に含め、データを標準形式で出力でき、契約終了時の引継ぎ協力が書面で約束されている状態です。この3つがあれば、乗り換えの費用は発生しても、乗り換えられない状態にはなりません。

現行ベンダーがソースコードを渡してくれないときはどうすればよいですか？

まず契約書で、ソースコードが納品物に含まれているか、著作権がどちらに帰属するかを確認します。納品物に含まれているなら、契約に基づいて引き渡しを求めることが可能です。含まれていない場合は、買い取りや利用許諾の追加契約を交渉します。交渉がまとまらないときは、画面や帳票、データ構造から現行仕様を復元し、作り直す選択肢を取ります。費用は増えますが、データさえ出力できれば移行は可能です。

オープンソースを使えばロックインは起きませんか？

製品のテクノロジーロックインは起きにくくなりますが、コーポレートロックインは防げません。オープンソースで作ったシステムでも、独自の改造や設定の記録が保守ベンダーの手元にしか無ければ、他社は引き継げないためです。公取委の報告書もオープンな仕様での設計を提言していますが、それと並べて発注側の体制整備を挙げています。技術の選択と、資料と権利の管理は別の対策として考えます。

内製化すればベンダーロックインは解消しますか？

外部ベンダーへの依存は減りますが、依存先が社内の特定の担当者に移るだけで終わる例も少なくありません。担当者が退職すれば、外部ベンダーにロックインされていたときと同じ状態になります。内製化する場合も、設計書の更新やコードレビューの仕組みを作り、複数人が保守できる体制が必要です。外注との比較は内製化のメリット・デメリットと外注との判断基準で詳しく整理しています。

関連記事

• マイグレーションとは？リプレイス・モダナイゼーションとの違いと発注判断を解説：ロックインからの脱却で選ぶ移行の方式の違いを整理しています。
• システム移行とは？移行方式の種類と進め方・失敗を防ぐ判断基準を解説：切替の進め方と失敗を防ぐ確認点をまとめています。
• レガシーシステム脱却の判断基準と進め方｜経産省調査が示す停滞要因と費用の見積り方：長年のロックインで古くなったシステムを刷新する判断を扱っています。
• ソースコードの著作権は誰のもの？どこまで守られるかと譲渡契約・判例・AI生成コードの扱い：契約で権利をどう定めるかの詳細です。