ベンダーロックインとは？中小企業が陥る典型パターン

「この改修は、うちでないとできません」。長年付き合いのある開発会社の担当者から、そう言われたことはないでしょうか。あるいは、他社に相見積もりを取ろうとしたら「御社のシステムは特殊な作りなので、弊社では対応が難しいです」と何社にも断られた経験。保守費の値上げを打診されても、断れば誰もこのシステムを触れなくなる恐怖から、言い値で契約を更新してしまった経験。

これらはすべて、ベンダーロックインと呼ばれる状態に陥っているサインです。特定の開発会社やツールに依存しすぎて、他社への乗り換えが技術的にも契約的にも困難になっている状態のことを指します。多くの場合、ロックインは一夜にして起きるわけではありません。発注時の小さな判断の積み重ねが、数年かけてじわじわと「他に頼める先がない」という状況を作り上げていきます。

この記事では、中小企業がベンダーロックインに陥る典型的なパターンを6つに整理し、それぞれがなぜ起きるのか、自社がどの段階にいるのかをどう見極めるか、そして今日から始められる第一歩を解説します。

• なぜロックインが起きるのか: 発注側・開発会社側それぞれの構造的な原因
• 6つの典型パターン: ソースコード、データ、属人知識、契約、技術選定、心理的依存
• 自社の危険度をどう見極めるか: パターンごとのチェック観点
• 今日からできる第一歩: 契約を切らずにできる対抗策

先に断っておきたいのは、この記事は「今すぐ開発会社を変えろ」と煽る内容ではないということです。長年付き合ってきた開発会社との関係を否定するものでもありません。ロックインの怖さは、契約を切りたくなったときに切れないことにあります。だからこそ、今すぐ関係を変える必要がなくても、「いざというときに選択肢を持てる状態」を今のうちに作っておくことが重要です。この記事はその準備のための地図です。

なお、この記事の運営元である株式会社ゼットリンカーはシステムの受託開発を事業としており、開発会社を乗り換える際の受け皿になり得る立場でもあります。ただし、ここで書く内容は特定のベンダーや契約形態を推奨するものではなく、公正取引委員会の実態調査など公的な一次情報に基づいた、中立的な整理であることを断っておきます。自社に不利な情報であっても、事実として重要であれば書きます。

この記事で分かること

この記事では、中小企業のシステム担当者が「うちでしか直せません」と言われる、あるいは開発会社を変えたくても変えられないという状況に陥る典型的な6つのパターンを、公正取引委員会の実態調査や著作権法の条文などの一次情報を基に解説します。それぞれのパターンについて、自社がどの程度当てはまるかを確認するための具体的な観点と、契約を今すぐ切らなくても始められる対抗策を示します。

すでに「うちでしか直せません」と言われている、あるいは開発会社を変えたいのに変えられないと感じている方はもちろん、まだそこまで深刻な状況ではないが将来が不安だという方にも、早い段階で読んでおいていただきたい内容です。ロックインは、深刻化してからの対処より、予兆の段階での対処のほうがはるかにコストが低いためです。

ベンダーロックインとは何か。定義を一次情報で確認する

まず、ベンダーロックインという言葉の定義を確認しておきます。公正取引委員会が2022年に公表した「官公庁における情報システム調達に関する実態調査報告書」では、ベンダーロックインを次のように説明しています。

ソフトウェアの機能改修やバージョンアップ、ハードウェアのメンテナンス等、情報システムを使い続けるために必要な作業を、それを導入した事業者以外が実施することができないために、特定のベンダーを利用し続けなくてはならない状態

この調査はもともと官公庁のシステム調達を対象にしたものですが、指摘されている構造そのものは民間の中小企業にもそのまま当てはまります。報告書では、ロックインが起きる要因の一つとして、既存システムの機能(技術)やデータに関する権利を既存のベンダーが握っており、それが調達仕様や契約の設計段階で特定のベンダーに有利な形になっていたことが挙げられています。

ここで重要なのは、ロックインは「悪意のある開発会社に閉じ込められる」という単純な話ではないという点です。多くの場合、発注側が契約や仕様の設計時に権利関係やデータの扱いを十分に詰めなかった結果として、構造的に「他社が入り込めない」状態ができあがります。開発会社側に他社を排除する意図がなくても、結果としてロックインは成立してしまうのです。

• 発注側がシステムの権利関係を意識せず契約を結んでしまう
• データの形式が独自仕様のまま何年も運用され続ける
• 担当者が特定の1社の窓口としか付き合わない体制が定着する
• 「動いているから」という理由で見直しの機会を先送りし続ける

これらが積み重なった結果として、ある日突然「もう他社には頼めない」という現実に直面することになります。次の章から、具体的にどのようなパターンでロックインが進行するのかを見ていきます。

なぜ多くの企業がロックインに気づかないまま放置するのか

ロックインの厄介さは、渦中にいる間は「特に困っていない」と感じられてしまう点にあります。経済産業省が公表した「DXレポート2.1」でも、ユーザー企業がITをコストとして捉え、開発会社に任せきりにすることでIT対応能力が育たず、結果としてシステムがブラックボックス化し、ベンダーロックインによって経営の機動性が損なわれるという構造が指摘されています。同レポートでは、開発会社側についても、要件定義があいまいなまま丸投げされる案件を抱え込み、責任の所在が開発会社側に偏った結果、契約上のトラブルにつながりやすいという課題が挙げられています。

つまりロックインは、発注側の「任せきり」と、開発会社側の「丸ごと引き受ける」という、双方にとって一見合理的に見える選択が積み重なった末に生まれる構造的な結果だということです。発注側からすれば、いちいち技術的な中身に口を出さず、信頼できる担当者に任せておくほうが日々の業務は楽です。開発会社からすれば、深く入り込んでもらったほうが継続的な保守収益が見込めます。この両者の利害が一致してしまうため、ロックインは表面化するまで問題として認識されにくいのです。

問題が表面化するのは、たいてい次のようなタイミングです。

• 開発会社の担当者が退職・異動し、急に対応が悪くなった
• 開発会社自体が廃業した、あるいは連絡が取れなくなった
• 保守費用の大幅な値上げを一方的に打診された
• 新しい業務要件に対応してもらえず、他社に相談したら断られた

これらはいずれも、「今まで気づかなかった依存」が可視化される瞬間です。裏を返せば、こうした事態が起きる前の平時にこそ、自社の依存度を点検しておく価値があります。

パターン1: ソースコードの権利が自社にない

最も根深く、しかし発注側が気づきにくいのがこのパターンです。長年システムを発注し、費用も全額支払ってきたはずなのに、実はソースコードの著作権が開発会社側に残っている、というケースが少なくありません。

著作権法第61条2項は、著作権を譲渡する契約において、翻案権(第27条)や二次的著作物の利用権(第28条)が「譲渡の目的として特掲されていない」場合、これらの権利は譲渡した側、つまり開発会社側に留保されると定めています。翻案権とは、既存の著作物を改変・発展させて新しいものを作る権利のことです。プログラムに置き換えれば、既存のソースコードに手を加えて機能を追加したり改修したりする権利にほぼ相当します。

つまり、契約書に「著作権を譲渡する」とだけ書かれていて、翻案権・二次的著作物の利用権について個別に明記されていない場合、法律上はこれらの権利が開発会社側に残ったままになっている可能性が高いということです。この場合、たとえソースコード一式のファイルを受け取っていたとしても、それを改変する権利がない状態になっているおそれがあります。

契約書の著作権譲渡条項に、著作権法第27条・第28条の権利を「含む」という一文があるかどうかを確認してください。この一文がない契約書は、想像以上に多く存在します。

• 契約書に「著作権は甲(発注者)に帰属する」とだけ書かれている
• 「著作権法第27条及び第28条に規定する権利を含む」という文言がない
• そもそも著作権の帰属について契約書に記載がない、または口頭でのやり取りしかない
• ソースコード自体を受け取っていない(納品物がバイナリや実行ファイルのみ)

このパターンに当てはまる場合、他社の開発会社にソースコードを渡して改修や引き継ぎを依頼しようとしても、著作権法上のリスクを理由に断られることがあります。多くの開発会社は、権利関係が不明確なソースコードへの手出しを避けます。トラブルに巻き込まれるリスクを取りたくないためです。結果として、権利上の理由から「元の開発会社にしか頼めない」状態が固定化されてしまいます。

なお、まったく身動きが取れなくなるわけではありません。著作権法第20条2項3号は、特定のコンピューターで動かなくなったプログラムを実行できるようにするための改変や、より効果的に実行できるようにするための改変については、著作者人格権のうち同一性保持権の適用を除外すると定めています。つまり、動かすために最低限必要な改変までもが一律に禁止されているわけではありません。ただし、これはあくまで限定的な例外規定であり、機能追加や大幅な改修まで自由に行えることを保証するものではない点には注意が必要です。権利関係が不明確なまま大きな改修に踏み込む前に、弁護士など専門家に相談することをおすすめします。

パターン2: データが独自仕様で閉じ込められている

ソースコードの権利とは別に、データそのものが特定のシステムやベンダーに閉じ込められているパターンもあります。これはデータポータビリティの問題です。自社が長年蓄積してきた顧客データや取引データが、そのシステム固有の形式でしか保存されておらず、他のシステムへ持ち出そうとしても標準的な形式でのエクスポート機能がない、という状態です。

• 標準的なCSVやExcel形式でのエクスポート機能がそもそも存在しない
• エクスポートはできるが、独自の暗号化やコード体系が使われていて他システムで読み込めない
• データベースへの直接アクセス権限が発注者側に与えられていない
• APIなどの外部連携手段が用意されておらず、データの取り出し自体に開発会社の作業が必要

このパターンが厄介なのは、システムそのものを入れ替える決断をしたとしても、過去のデータを新システムに引き継げなければ、実質的に「業務の歴史がゼロから始まる」ことになってしまう点です。何年分もの顧客対応履歴や取引実績が失われる、あるいは移行のためだけに高額な費用を元の開発会社に支払わざるを得ない、という状況に陥ります。

データのロックインが特に深刻なのは、乗り換えの意思決定そのものを萎縮させる点です。「システムを変えたいが、過去データが失われるなら現状維持のほうがまし」という判断に、多くの担当者が至ります。これは技術的な制約というより、心理的なブレーキとして機能してしまいます。

見落とされやすいのが、エクスポート機能自体は存在していても、実際に使ってみないとその品質が分からないという点です。「一応CSV出力ボタンはある」というシステムでも、実際に出力してみると文字コードが特殊で開けない、必要な項目の一部が含まれていない、関連するテーブル間のつながりが失われてバラバラのデータになる、といった不具合に直面することがあります。年に一度でよいので、実際にエクスポート機能を使ってみて、出てきたデータが本当に業務で使える状態かを確認しておくことをおすすめします。使えるかどうかを試すこと自体に、開発会社の作業や追加費用は通常発生しません。

パターン3: 仕様書がなく、開発会社の頭の中にしか知識がない

3つ目のパターンは、ソースコードやデータの権利関係とは別次元の問題です。仕様書や設計書がまったく整備されておらず、システムの仕組みが開発会社の担当者の頭の中にしか存在しない、という状態です。

このパターンでは、たとえソースコードの権利を自社が持っていて、データも標準形式でエクスポートできたとしても、実質的なロックインが発生します。他社の開発会社がソースコードを読み解こうとしても、なぜその実装になっているのか、どの部分が業務上重要な処理なのかという「理由」が記録に残っていなければ、解読には膨大な時間がかかります。結果として、多くの開発会社は「一から作り直したほうが早い」と判断し、既存システムの改修という選択肢自体が事実上失われます。

• システムの仕様書・設計書・データベース定義書が存在しない、または古いバージョンのまま更新されていない
• コード内にコメントがほとんど残っていない
• 開発会社の担当者が変わると、引き継ぎに毎回時間がかかっている
• 「なぜこの仕様になっているか」を説明できるのが、特定の1人の担当者だけである

このパターンは、開発会社側の属人化が発注側企業のロックインに直結するという点で特徴的です。開発会社の中の1人の技術者が異動・退職しただけで、発注側企業が事実上その開発会社全体から見放されたのと同じ状態になることもあります。

パターン4: 契約形態と保守費用が乗り換えを阻んでいる

技術的な問題がなくても、契約の構造そのものがロックインとして機能しているケースがあります。代表的なのが、保守契約の内容が曖昧なまま長期間にわたって自動更新され続け、契約書を見返しても何にいくら払っているのか誰も説明できない、という状態です。

• 保守契約の内容(対応範囲・対応時間・費用の内訳)が契約書に具体的に書かれていない
• 毎年ほぼ同額で自動更新され、その妥当性を誰も検証していない
• 保守費用を止めた場合に何が起きるか(サポートが完全になくなるのか、有償対応に切り替わるだけなのか)が不明
• 契約解除の条件や、解除時のデータ・ソースコードの引き渡し条件が契約書に定められていない

このパターンで特に見落とされがちなのが、解除条件の欠如です。「今の開発会社との契約をやめたい」と思ったとき、契約書に円滑な引き継ぎのための取り決め(ソースコードやドキュメントの引き渡し義務など)がなければ、開発会社側に協力する法的な義務はありません。多くの開発会社は円満な形で協力してくれますが、関係がこじれた場合や、開発会社自体の経営状況が悪化している場合には、この取り決めの有無が決定的な差になります。

保守費用が年々上がっているのに内容の説明がない、という状態も一種のロックインのサインです。SLA（サービス品質保証）が明文化されていない保守契約では、値上げの妥当性を検証する材料自体が手元にありません。

こうした保守契約は、多くの場合準委任契約という形態で結ばれます。成果物の完成を約束する請負契約とは異なり、準委任契約は業務の遂行そのものを目的とするため、契約書に「何をどこまでやるか」が具体的に書き込まれていないと、双方の期待値がずれたまま何年も更新され続けることになりがちです。値上げの打診があった際は、金額の是非だけでなく、そもそも対応範囲が契約書のどこに書かれているかを確認する機会と捉えるとよいでしょう。

パターン5: 発注先を1社に固定する社内の慣習

技術や契約の話とは別に、発注側の社内慣習そのものがロックインを助長しているケースもあります。長年同じ開発会社に発注し続けてきた結果、相見積もりを取るという発想自体が社内から失われている、という状態です。

• 新しい改修案件が出るたびに、検討なく同じ開発会社に発注している
• 過去数年間、他社から見積もりを取ったことが一度もない
• 「今の担当者との関係が良いから」という理由が、発注継続の主な根拠になっている
• 経営層が、システムの中身よりも担当者個人との人間関係で発注判断をしている

これはマルチベンダー体制とは対照的な状態です。複数の会社に分散して発注するマルチベンダー体制には調整コストがかかる一方、1社への依存を避ける効果があります。すべてを1社に集約すること自体が悪いわけではありませんが、その1社との関係が発注側にとって「唯一の選択肢」になってしまっている場合、価格交渉力も、品質を評価する基準も、発注側から失われていきます。

パターン6: 技術選定そのものが特殊で代替が効かない

最後に、技術的な選定そのものがロックインの原因になっているパターンです。汎用的なプログラミング言語やクラウドサービスではなく、特定のベンダーしか対応できない独自のツールや、既に開発が終了した古い技術で構築されているケースがこれにあたります。

フルスクラッチ開発で開発されたシステムであっても、広く使われている言語やフレームワークで作られていれば、対応できる開発会社の選択肢は多く残ります。一方で、特定の1社が独自に開発した非公開のプラットフォームや、既にサポートが終了している開発環境の上に構築されたシステムは、そもそも技術的に対応できる会社が市場にほとんど存在しない、という状況になり得ます。

• 使われている言語・フレームワークが一般的に広く使われているものか、特定企業の独自技術か
• 動作環境(サーバーOS・データベース等)が既にEOL（サポート終了）を迎えていないか
• そのツール・プラットフォームを扱える技術者が、開発会社1社の外にどれだけ存在するか
• クラウドサービスを使っている場合、他のクラウドへ移行する際のデータ移行手段が用意されているか

このパターンはレガシーシステムの問題とも重なりますが、ロックインの観点で見ると「古いこと」自体が問題なのではなく、「その古い技術を扱える会社が、事実上1社しか残っていないこと」が問題の本質です。

開発会社の立場から見たロックインの構造

ここまで発注側の視点でパターンを整理してきましたが、開発会社側の事情にも触れておきます。冒頭で述べた通り、この記事の運営元であるゼットリンカー自身も受託開発を営む立場であるため、この視点はあえて中立に書きます。

開発会社の多くは、意図的に発注者を囲い込もうとしているわけではありません。むしろ、次のような合理的な経営判断の積み重ねが、結果としてロックインを生んでいます。

• 保守契約は収益が安定しやすいため、深く入り込んだ関係を維持したいという経営上の動機がある
• 独自のフレームワークや社内標準を使うほうが、自社内の開発効率は上がる
• ドキュメント整備には工数がかかるため、優先順位が後回しになりやすい
• 契約書のひな形が自社に有利な内容のまま、長年見直されていない

これらは開発会社にとって不自然な行動ではなく、多くの受託開発会社が抱える構造的な事情です。だからこそ、発注側が「相手が悪意を持っている」と決めつけて対立的に動くよりも、契約や仕様の透明性を上げてほしいと、対等な取引条件として求めていくほうが現実的です。良心的な開発会社であれば、ソースコードの権利関係やドキュメント整備について具体的な相談をすれば、応じてくれることも少なくありません。まずは疑うより先に、確認と対話から始めることをおすすめします。

自社がどの段階にいるかをチェックする

ここまで6つのパターンを見てきましたが、多くの企業は一つのパターンだけでなく、複数のパターンが重なった状態にあります。次の表で、自社がどのパターンに、どの程度当てはまるかを確認してみてください。

すべてに該当しなくても心配は不要です。むしろ、これらのうちどれか一つでも「該当しない(=ロックインされていない)」と自信を持って答えられる項目があれば、それは今後の交渉や乗り換えの際の足がかりになります。逆に、すべてに「分からない」と答えるしかない場合は、まず現状を把握するところから始める必要があります。

今日からできる、契約を切らずに済む第一歩

繰り返しになりますが、この記事は今すぐ開発会社との契約を切ることを勧めるものではありません。むしろ、関係を維持したまま、いざというときの選択肢を確保しておくための準備を推奨します。

まず取り組みやすいのは、契約書の再確認です。今すぐ何かを変更する必要はなく、現状把握のためだけに、手元にある契約書・発注書を引っ張り出して、著作権の譲渡範囲・保守契約の内容・解除条件がどう書かれているかを確認してください。これだけで、自社がどのパターンに該当するかがかなり明確になります。

次に、システム管理台帳の整備です。稼働しているシステム・使用している技術・契約している会社・保守費用の内訳を一覧化しておくことで、いざ乗り換えや相見積もりを検討する際に、他社への説明がスムーズになります。この台帳自体は、今の開発会社との関係を損なうものではなく、自社の防衛のための資料です。

最後に、次に何か改修が発生するタイミングで、一度だけでも他社に相見積もりを依頼してみることです。実際に発注するかどうかは別として、「他社ならどう見るか」という視点が入るだけで、自社の状況を客観視するきっかけになります。相見積もりを取ったからといって、必ずしも今の開発会社との関係を解消する必要はありません。

• 契約書・発注書を引っ張り出し、著作権譲渡と解除条件の記載を確認する
• システム管理台帳を作り、技術・契約・費用を一覧化する
• 次の改修時に一度だけ他社に相見積もりを依頼してみる
• 保守費用の内訳について、開発会社に説明を求めてみる

これらはいずれも、今の開発会社との関係を壊さずに始められることです。ロックインからの脱出は、契約解除という一つの大きな決断ではなく、こうした小さな確認の積み重ねから始まります。

すでに深刻な状態にある場合

ここまでは、まだ致命的な状態には至っていない前提で、予防的な確認作業を中心に書いてきました。しかし、この記事を読んでいる方の中には、すでに「うちでしか直せません」と明確に告げられている、開発会社と連絡が取れなくなっている、あるいは保守契約が実質的に破綻しているという、より切迫した状況にいる方もいるはずです。

そうした状況は、この記事で扱う「予兆段階での対処」の範囲を超えています。当メディアの他カテゴリでは、開発会社と連絡が取れなくなった場合の具体的な確認手順や、老朽化したシステムを延命させるか作り直すかの判断基準、保守契約が切れたまま動いているシステムのリスクの整理方法など、より個別具体的な状況への対処法を扱っています。自社の状況がどの記事に近いかを見比べながら、次に読む記事を選んでみてください。

この記事のまとめ

ベンダーロックインは、悪意ある1社に閉じ込められるという単純な話ではなく、発注側の契約・データ管理・社内慣習と、開発会社側の権利関係・属人化が絡み合って生じる構造的な問題です。ソースコードの権利、データの独自仕様、仕様知識の属人化、契約内容の曖昧さ、発注先の固定化、技術選定の特殊性という6つのパターンのうち、自社がどこに当てはまるかをまず把握することが、脱出への最初の一歩になります。

大事なのは、これらのパターンに一つでも当てはまったからといって、今すぐ開発会社との関係を断つ必要はないということです。ロックインへの対処は、関係を壊す決断ではなく、いざというときに自社の手元に選択肢を残しておくための準備です。契約書を読み直す、データを一度エクスポートしてみる、システム管理台帳を作る。どれも今日から一人で始められることばかりです。

このカテゴリでは、今後それぞれのパターンについて、より具体的な対処法を掘り下げた記事を公開していく予定です。まずは自社の現状把握から始めてみてください。

個別のテーマも順次記事にしています。クラウド移行の始め方はクラウド移行でロックインされないための設計視点、老朽化したパッケージシステムの乗り換え判断は古いパッケージシステムからの乗り換え判断、値上がりしたSaaSへの対処は高くなったSaaSの乗り換え・縮小の選択肢、内製とアウトソースの見極めは内製化とアウトソースの分岐点、実際の移行フェーズでの注意点はリプレイス時のデータ移行で失敗しないために、最初の一歩としては脱ロックインの第一歩: 自社で管理すべきアカウント一覧で扱っています。

開発会社を変えられない構造そのものを分解したい方は開発会社を変えたいのに変えられない理由。ロックインの構造を分解する、複数の開発会社に分散して発注するマルチベンダー体制を検討している方はマルチベンダー体制のメリット・デメリット、実際に開発会社を乗り換える際の必要書類は開発会社の乗り換え手順: 引き継ぎに必要な資料一覧、基幹システムのリプレイス費用の内訳は基幹システムのリプレイス費用はなぜ高い？内訳の読み方もあわせてご覧ください。