ベンダーロックインとは｜基幹システムで起きる原因と、契約・設計・体制での防ぎ方

ベンダーロックインとは、システムの改修や保守を導入した会社以外に頼めず、高くても不満があっても同じベンダーを使い続けるしかない状態です。原因の多くは技術ではなく、「仕様とデータを相手しか知らない」「権利が相手にある」ことにあります。この記事では、公正取引委員会の調査からわかる原因、自社のロックイン度を測る診断表、契約・設計・体制の3つの面での防ぎ方を、大手コンサルティングファーム出身の専門家の知見をもとに解説します。

ベンダーロックインとは：乗り換えの選択肢がない状態

公正取引委員会は2022年2月に公表した官公庁の情報システム調達の実態調査で、ベンダーロックインを次のように説明しています。ソフトウェアの機能改修やバージョンアップ、ハードウェアの保守などを、システムを導入した事業者以外が行えないため、特定のベンダーを使い続けざるを得ない状態です。

この調査の対象は官公庁ですが、起きている構造は民間の中小企業でも同じです。むしろ中小企業のほうが起きやすい面があります。情シスが1〜2名、あるいは総務や経理の担当者が兼任している会社では、システムの中身を説明できる人が社内にいないことが多いからです。

注意したいのは、同じベンダーと長く付き合うこと自体は悪くない点です。業務をよく知るベンダーに任せ続けるのは合理的な判断になりえます。問題は、「乗り換えようと思えば乗り換えられる」状態を失っていることです。この状態では、保守料の値上げや対応の遅さに不満があっても、交渉の材料がありません。

見分け方は簡単です。「今のベンダーが明日撤退したら、半年以内に別の会社へ引き継げるか」を考えてみてください。答えに詰まるなら、ロックインが進んでいます。

ロックインが進むと、現場で何が起きるか

ロックインは、ある日突然困るものではありません。次のような小さな不満が、数年かけて積み重なります。

• 保守料の値上げを提示されても、比べる相手がいないため受け入れるしかない
• 帳票の項目を1つ足すだけの改修に、想定より大きな見積もりが出る。妥当かどうか判断できない
• ベンダーの担当者が替わったとたん、問い合わせへの回答が遅くなる
• OSやデータベースを更新したいのに、「そのシステムは新しい環境で動くか確認できない」と言われる
• 新しい会計ソフトやECサイトとつなぎたいのに、連携の改修が今のベンダーにしか頼めない

どれも1つずつは小さな問題です。ただ、こうした状況が続くと、システムの都合で業務や経営の判断が止まるようになります。

なぜ起きるのか：公的調査からわかる4つの原因

公正取引委員会の同じ調査では、既存システムの更新や改修で、既存のベンダーと再び契約することになった理由を尋ねています（複数回答）。上位の回答と、中小企業の基幹システムに置き換えたときの典型的な状況を並べました。

※割合は公正取引委員会「官公庁における情報システム調達に関する実態調査報告書」（2022年）の回答結果。右列は説明用の例です。

この結果から読み取れるのは、最大の原因が「権利」より「情報」だという点です。半数近くは、仕様がベンダーの頭の中や手元の資料にしかないことが理由でした。権利の問題は契約書を直せば防げますが、情報の偏りは日々の運用で少しずつ進みます。

IPAの「システム再構築を成功に導くユーザガイド 第2版」にも、この情報の偏りが招くトラブルが載っています。現行どおりに作り直す方針で開発を始めたところ、5割以上の設計書が実際のシステムと乖離しており、内容を知る人もいなかったという事例です。設計書の更新が止まると、ロックインと再構築の失敗は同時に起きます。

地方の中小企業では、地元の開発会社1社とだけ長く付き合っている例も少なくありません。その会社の経営者や担当者が高齢になり、事業の継続そのものが不安になって初めて、ロックインに気づくこともあります。この場合、急いで他社を探しても、仕様の資料がなければ引き継ぎの見積もりは出ません。相手の会社が元気なうちに資料の整備を進めておくことが、双方にとって負担の少ない進め方です。

自社のロックイン度を測る12の質問

次の12の質問に「はい＝0点」「一部＝1点」「いいえ＝2点」で答えてください。合計点で、どこから手を打つべきかがわかります。

• 0〜6点：乗り換えの選択肢は残っています。次の契約更新で条項を見直し、今の状態を保ちましょう。
• 7〜14点：部分的にロックインが進んでいます。点数の高い区分から手を打ちます。情報の区分なら設計書と項目定義の整備、権利の区分なら契約の見直しが先です。
• 15〜24点：乗り換えは難しい状態です。次のリプレイスの前に、現行システムの資産を棚卸しする期間を計画に組み込む必要があります。

※点数の区切りは説明用の目安です。区分ごとの点数の偏りを見ることにも意味があります。

契約で防ぐ：著作権・ソースコード・データの条項

権利の問題は、契約書で防げます。まず押さえたいのが著作権法のルールです。プログラムの著作権は、原則として作った側（ベンダー）に発生します。発注者がお金を払ったからといって、自動的に発注者のものにはなりません。

さらに著作権法第61条第2項は、著作権を譲渡する契約で、翻案権など（第27条・第28条の権利）が譲渡の対象として明記されていない場合、それらの権利は譲渡した側に残ると推定すると定めています。「著作権を発注者に譲渡する」とだけ書いた契約では、改修や作り替えに関わる権利がベンダーに残っていると読まれるおそれがあります。

一方で、すべての著作権を発注者が持つ必要はありません。IPAと経済産業省が公表している「情報システム・モデル取引・契約書」のパッケージ・SaaS/ASP活用向けの版（第二版追補版）では、中小企業がパッケージを使う取引を前提に、アドオンなどの著作権をベンダーに帰属させる案を採用しています。そのうえで、発注者が自社で使うための複製や翻案（改変）をできることを定めています。譲渡を受けると別に対価が必要になり、費用が増えるという理由です。

大事なのは、権利の持ち主よりも「自社が困らない使い方ができるか」です。契約で確認したい条項を整理しました。

※書き方の例は説明用です。実際の契約では、法務担当者や弁護士に確認してください。

こうした条項は、契約の段階で持ち出すより、RFP（提案依頼書）の段階で前提条件として示すほうが通りやすくなります。各社が同じ条件で見積もるため、後から「その条件なら追加費用です」と言われにくいからです。書き方はRFPの書き方で、提案の比べ方はベンダー選定の進め方で解説しています。

設計で防ぐ：データと連携を「外せる形」にする

契約が整っていても、システムの作りが特殊すぎれば、引き継げる会社は見つかりません。設計の段階で意識したいのは、次の4点です。

• データを自社で取り出せるようにする：全マスタと取引データを、決まった形式（CSVなど）で出力できる機能を最初から要件に入れます。項目の意味を書いたデータ定義書もセットで納品してもらいます。
• 連携はファイルや公開された仕組みで行う：会計や倉庫システムとの連携を、相手のデータベースに直接書き込む方式で作ると、どちらかを替えるときに両方の改修が必要になります。連携の項目・形式・頻度を一覧にしておくと、相手を替えても影響範囲がすぐにわかります。
• 独自開発を減らす：パッケージやクラウドサービスを使う場合、アドオンが増えるほど、そのアドオンを作った会社しか触れない部分が増えます。標準機能に業務を合わせる判断はERPのアドオンとはで詳しく解説しています。
• コードと区分値を自社で決める：取引先コードや品目コードの付け方をベンダー任せにすると、その会社の流儀が残ります。採番ルールは自社の業務の言葉で決め、文書に残します。

この4点は、どれもシステムを作った後では直しにくいものです。要件定義の段階で「対象外にしない」ことが、いちばん安上がりな対策になります。要件定義書への書き方は要件定義書の書き方を参考にしてください。

もう1つ、設計の段階で決めておきたいのが「出口」の想定です。システムを何年使うつもりか、その後はどう入れ替えるつもりかを、最初の要件定義で一言でも書いておきます。たとえば「7年後のリプレイス時に、全データを新システムへ移せること」と書いてあれば、データ出力の機能や定義書の整備が要件から漏れにくくなります。入れ替えの時期が見えていれば、保守契約の更新時期にあわせて他社の見積もりを取る計画も立てやすくなります。

体制で防ぐ：社内に残すべき3つの知識

公正取引委員会の調査で最も多かった原因は、仕様を既存ベンダーしか把握できないことでした。これは契約や設計だけでは防げません。社内に、最低限次の3つの知識を残す仕組みが必要です。

1. 業務の知識：どの業務で、システムの何を使っているか。例外処理（特定の取引先だけの締め方、月末だけの手順など）を含めて、業務フローとして残します。
2. データの知識：主要なマスタと区分値の意味。たとえば「受注区分の3は直送、5はサンプル出荷」といった対応表です。
3. お金の知識：保守料に何が含まれ、改修はいくらで頼んでいるか。年1回、保守の作業内容と金額を一覧にして見直します。

3つとも、ベンダーに作ってもらうことはできます。ただし社内の誰かが読んで説明できる状態にしておかないと、文書があっても役に立ちません。担当者が1人しかいない会社では、その人が異動や退職をした時点で、知識はベンダーの側にしか残らなくなります。

知識を残す仕組みとしては、年に1回、ベンダーと「保守の振り返り」の場を設ける方法があります。議題は3つで足ります。1年間の改修の一覧と、それぞれの金額。設計書とデータ定義書がどこまで更新されたか。翌年に予定している改修と、OSやデータベースなど基盤の保守期限です。この場に社内の担当者を2人以上参加させると、知識が1人に偏るのを防げます。

パッケージ・クラウドでもロックインは起きる

「スクラッチ開発をやめてパッケージやクラウドにすればロックインはなくなる」と考える方もいますが、形が変わるだけです。提供形態ごとに、ロックインの起き方と確認する点を整理しました。

パッケージの場合は、製品を作るメーカーと、導入や保守を担うパートナーが別の会社であることが多い点に注意してください。製品そのものは多くの会社が扱っていても、自社向けに作ったアドオンの資料が今のパートナーにしかなければ、パートナーを替えることは難しくなります。製品を選ぶときに「この製品を扱うパートナーは他に何社あるか」「パートナーを変更した事例はあるか」を聞いておくと、将来の選択肢の広さがわかります。

クラウドサービスで特に確認したいのは、解約するときの手順です。契約の前に「解約したら、データはいつまでに、どの形式で受け取れますか」と聞いてみてください。明確に答えられるサービスほど、乗り換えの選択肢が残ります。クラウド化の判断の考え方は基幹システムのクラウド化で解説しています。

すでにロックインされている場合の抜け方

診断表で15点を超えた会社でも、手順を踏めば別のベンダーに移ることはできます。ただし、いきなり他社に見積もりを頼んでも、仕様がわからない以上、正確な金額は出ません。順番が大切です。

1. 契約書を読み直す
   著作権、ソースコード、ドキュメント、データ、契約終了時の条項を抜き出します。書いていない項目も「書いていない」と一覧にします。
2. 手元にある資産を棚卸しする
   設計書、テーブル定義書、ソースコード、連携の仕様、操作マニュアルのうち、何が社内にあり、いつ更新されたかを確認します。
3. 現行ベンダーに資料の提供を依頼する
   契約上の根拠がある項目から依頼します。根拠がない項目は、有償での作成も含めて相談します。
4. 業務とデータの知識を社内で書き起こす
   主要業務のフローと、マスタ・区分値の対応表を、業務部門の担当者と一緒に作ります。これが新しいベンダーへのRFPの土台になります。
5. 移行の方式を決める
   保守だけを別の会社に移すのか、システムごと作り替えるのかを決めます。作り替える場合は、次の契約で同じことが起きないよう、本記事の条項をRFPに入れます。

次のリプレイスで同じことを繰り返さないために、契約前に次の10項目を確認してください。

• 独自開発部分の著作権の帰属と、自社利用のための複製・改変の条件が書かれている
• 保守や改修を第三者に委託できることが書かれている
• ソースコードの写しを受け取る時期と範囲が決まっている
• 改修のたびに設計書とデータ定義書を更新する義務がある
• データが自社に帰属し、決まった形式で全件を取り出せる
• 契約終了時の引継ぎへの協力が書かれている
• 他システムとの連携の項目・形式・頻度が一覧になっている
• 取引先・品目などのコード体系を自社で決めている
• 保守料の内訳（作業内容と金額）が毎年報告される
• システムの中身を説明できる社内の担当者が2人以上いる

よくある質問

まとめ

ベンダーロックインは、改修や保守を導入したベンダー以外に頼めない状態です。公正取引委員会の調査では、既存ベンダーと再契約した理由の最多は「機能の詳細を既存ベンダーしか把握できなかった」（48.3%）でした。原因の中心は権利より情報の偏りにあります。

防ぐには、契約で著作権の利用条件・ソースコード・データ・引継ぎを決め、設計でデータと連携を外せる形にし、体制で業務・データ・お金の知識を社内に残すことです。ベンダーロックインへの対策は、特定のベンダーを避けることではなく、乗り換えの選択肢を持ち続けることです。自社の状態がどの程度か整理したい方は、無料診断で現状の課題と打ち手の順番を確認できます。