ベンダーロックインとは？対策を全部やったのに、乗り換えられなかった話

題材は、受発注の基幹システムです。取引先からの注文を受けて、在庫を引き当て、出荷指示を出し、請求まで回す。10年前に1社へ発注して、以来その1社が改修と運用を続けています。

なぜ乗り換えの話が出てきたのかというと、保守費が毎年上がっているからです。 上がる理由の説明はあります。人件費、対象範囲の増加、24時間の監視体制。どれも理屈は通っている。ただ、比べる相手がいないので、妥当かどうかを誰も判断できません。

要望を出してから着手までの日数も伸びています。急ぎの改修を頼んで、3週間。 断られてはいません。ただ、他に頼める先がない状態で待っている、という事実だけが残ります。

ベンダーロックインとは、特定の提供者の製品・技術・体制に依存してしまい、他へ乗り換えようとすると費用や期間が現実的でなくなって、事実上動けなくなる状態のことです。値上げを受け入れるしかない、品質が落ちても言いにくい、という形で表面化します。

そして、対策の型もほぼ確立しています。調達の基本動作なので、チェックリストも解説もいくらでも出てきます。

前置きはさておき、本題に入ります。

今日は、その対策を教科書どおりに全部やったうえで、10年目に乗り換えを見積もって、そこで何に詰まったかという話をしていこうと思います。

① 教科書どおりに、ロックイン対策を入れる

契約時に、対策は一通り入れてありました。当時の担当者は、かなり慎重な人だったようです。

→ ソースコードの著作権を、発注側に帰属させる
→ 設計書・運用手順書の納品を、契約上の義務にする
→ 特定の商用製品に依存せず、標準技術とオープンソースで作る
→ 保守と監視は別会社に分ける（1社に全部を握らせない）
→ 契約終了時の移行協力義務を、条文に入れる

5つとも、守られていました。

ソースコードも、設計書一式も、全部、社内のサーバーに入っています。 ライセンスの制約もない。移行協力義務の条文も、10年前のまま生きている。

ここまでは、教科書どおりの状態です。 だから、乗り換えられるはずでした。

② 見積もりを取ったら、桁が違って返ってきた

3社に声をかけて、現行システムの引き継ぎと刷新の見積もりを依頼しました。コードも設計書も全部開示しています。

返ってきた金額は、いまの年間保守費を大きく超えていました。 期間も、いちばん短いところで年単位です。

高いこと自体より、各社の金額がだいたい揃ったことのほうが気になります。理由を聞くと、答えはだいたい同じところに落ち着きました。コードは読める。ただ、なぜそうなっているかが分からない。

具体例を出してもらいました。締め日の判定に、例外の分岐が数百件規模で入っています。 取引先ごとに締め日が違うのは珍しくないので、そこは想定内です。問題は、その分岐のうち、理由が文書に残っているものがごく一部しかないことでした。

残りは、コードとしては読めます。条件も結果も明快です。分からないのは、なぜその取引先だけ例外なのかという一点です。

そして、この一点が分からないと、刷新のときに消せません。

→ 消して業務が止まったら、止めた側の責任になる
→ だから全部そのまま移すという判断になる
→ 移すには、1件ずつ挙動を確認する必要がある

見積もりの大部分は、書き直しではなく、この確認作業でした。

念のため書いておくと、前のベンダーが隠していたわけではありません。設計書のどこにも、「なぜ」を書く欄が無かっただけです。書式に無いものは、書かれません。

③ AIの部分でも、同じことが起きた

このシステムには、2年前にAIを入れた部分があります。取引先から届く注文メールの一次仕分けです。定型の発注書か、問い合わせか、クレームか。これを自動で分類して、担当へ振り分けます。

ここは、ロックインを強く意識して設計してありました。

→ モデルの呼び出しは1箇所にまとめてある
→ 特定の提供者に固有の機能は使っていない
→ プロンプトはテキストなので、納品物に含まれている

設計としては、正しい。 実際、別のモデルへの差し替えは、すぐに終わりました。

そして、差し替えた結果がこうです。正しく振り分けられた割合が、目に見えて落ちました。

落ちたこと自体は、想定内です。問題はその次で、何が原因で落ちたのかが分かりませんでした。 理由は単純です。何を正解とするかの集合を、こちらが持っていなかった。

2年間の運用で、振り分けの誤りは何度も報告されています。そのたびに前のベンダーが調整して、精度を上げてきました。その履歴と失敗の事例集が、向こう側にあります。

→ プロンプトに書いてあるのは、現在の答えだけ
→ なぜその書き方に落ち着いたかは、失敗の履歴の側にある
→ 履歴が無いと、同じ失敗をもう一度踏むまで気づけない

差し替えられるように作ってあったのに、差し替えた結果の良し悪しを、自分で判定できませんでした。

技術的には、乗り換えは可能です。ただ、乗り換えた結果を評価できない乗り換えは、意思決定としては不可能です。

④ 2つの詰まりは、同じ前提から来ている

締め日の例外分岐と、AIの評価セット。領域は全然違いますが、原因は1つでした。

ロックイン対策の全部が、「渡せるもの」に向いていたからです。

著作権も、設計書も、ライセンスも、物として存在します。だから条文に書けるし、納品物として数えられる。そして、数えられるものは対策した気になれます。

ところが移行のコストは3層に分かれていて、渡せるものが効くのは1層目だけでした。

層	内容	渡せるか	今回の見積もりでの比重
書き直し	コードを新しい基盤で作り直す	渡せる（コードがある）	小さい
再発見	なぜその分岐があるかを突き止める	渡せない	いちばん大きい
検証	移した後、同じ挙動だと確かめる	渡せない	大きい

書き直しそのものは、いまならずっと短い期間で終わります。 AIが入ってから、この層ははっきり下がりました。

下がらなかったのは、下の2層です。 理由の再発見も挙動の検証も、業務を知っている人の時間を使うしかなく、その人は相手の会社にいます。

つまり、ロックインの正体は「所有していないこと」ではなく、「再現できないこと」でした。 所有権を移しても、再現能力は移りません。そして契約書は、所有権しか移せません。

⑤ 直してみる — 渡すものではなく、再現できることを契約に書く

条項を足す話ではありません。発動する時点を変えます。

いまの移行協力義務は、離れると決めた日にしか発動しません。 その日まで、出口が開くかどうかを誰も確かめない。だから10年後に開けようとして、動かなかった。平時に発動するものへ、書き換えます。

1. 判断の記録を、納品物にする

設計書とは別に、決めごとを1件1ページで残すことを義務にします。書く欄は4つです。

→ 何を決めたか
→ なぜそう決めたか（採らなかった案と、その理由も）
→ 前提にしている事実
→ その前提が崩れる条件

締め日の例外分岐は、この形式なら1件につき1ページです。設計書一式の分量に対して、ごくわずかな上乗せにしかなりません。

4つ目の欄が本体です。「先方の経理の締めが月末+3営業日だから」と書いてあれば、その運用が変わった日に消せます。 理由の無い分岐は、永久に消せません。

2. 評価データを、自社の所有にする

AIが入る部分では、ここが本体です。

→ 正解付きの判定用データ（どの入力に、どの答えが正しいか）
→ 失敗事例の一覧（いつ、どう外して、どう直したか）
→ 判定の実行手順（誰でも走らせて、数字が出る状態にする）

プロンプトの著作権より、この3つのほうが強い資産です。 これがあれば、モデルも提供者も、比べたうえで替えられます。

3. 年1回、乗り換えの演習をする

いちばん効いたのが、これでした。

年1回、自社の担当者だけで、開発環境をゼロから立ち上げる。 前のベンダーは質問に答える役として同席し、代わりに操作はしない。測る数字は1つ、業務が動く状態になるまでの日数です。

この演習に協力する義務を、契約に書きます。 移行協力義務が「離れる日の義務」なら、こちらは「毎年の義務」です。

⑥ あとで知った — 全部、名前がついていた

素朴な整理のつもりでしたが、調べると3つとも確立した考え方でした。

1つ目。出口戦略（exit strategy）。 欧州の銀行監督当局が出している外部委託のガイドラインでは、重要な業務を外部に委託する場合、委託を始める時点で出口計画を持っていることが求められています。離れるときに作るものではなく、入るときに作るものとして扱われている。

さらに2025年9月から適用が始まったEUのデータ法（Data Act）では、クラウドサービスの乗り換えそのものが利用者の権利として整理されました。提供者には移行への協力義務があり、乗り換えの手数料は2027年1月以降、原則として請求できなくなります。

「出口は権利であって、交渉事項ではない」という方向へ、制度の側が先に動いていたわけです。

2つ目。判断の記録には、そのままの名前がありました。ADR（Architecture Decision Record） です。2011年に提唱された形式で、書く項目は「文脈・決定・状態・結果」。推奨されている運用が、1決定につき1ファイル、1〜2ページ。分量の見立てまで、ほぼ同じでした。

3つ目。演習も、隣の分野では常識でした。 災害復旧の訓練です。取ってあるのに戻せなかった、という事故が繰り返された結果、「試していないバックアップは、無いのと同じ」という言い方が定着しています。

乗り換え条項も、同じでした。試していない出口は、無いのと同じです。

人への依存を測る指標もありました。バス係数（bus factor） — 何人が抜けたら立ち行かなくなるかを表す数です。理由が文書に残っていない分岐は、答えを知っている人が1人しかいない状態、つまりバス係数1のまま置かれています。

新しい理屈は、ひとつも要りませんでした。

⑦ 何が変わったか

この演習を1回でも通すと、まず立ち上がりません。 そして止まる場所は、たいていコードの外に出ます。

→ 証明書の発行手順が、手順書に無い（前任者の記憶にある）
→ 外部システムとの接続に使う設定値が、本番環境にしか存在しない
→ 初期データの投入順序が、間違うと途中で失敗する（順序はどこにも書かれていない）

どれも、コードの問題ではありません。 そして、契約書の納品物の一覧には載っていない種類のものです。演習が測っているのは技術力ではなく、手順書の欠けです。止まった場所をその場で書き足していくと、次の回は短くなります。日数が縮んだ分が、そのまま埋めた欠けの量です。

そのうえで、この方法には代償があります。

1つ目。演習そのものが工数を食います。 業務が止まらない時期に、担当者を数日空ける必要がある。年1回でも、予定を押さえる調整は毎回発生します。

2つ目。手順書の更新が、恒常的な仕事として増えます。 演習で見つかった欠けは、書き足さなければ翌年また同じ場所で止まります。見つける仕組みを持つと、直す仕事が増えるという当たり前の交換です。

3つ目。離れる前提の作業を、相手に頼むことになります。 言い方を間違えると、単純に角が立つ。ここは条項の問題ではなく、関係の作り方の問題として残り続けます。

そして、出口を作ったからといって、出口を使うとは限りません。演習に付き合う相手は、抱え込む意図が無いということでもあるので、替える理由のほうが先に無くなることがあります。比較できる状態と、比較すること自体は、別です。

逆に、演習への協力を「工数が読めない」という理由で断られたなら、断られた時点で判断がつきます。演習ができない相手は、自分たちでも再現できていない可能性が高い。

出口を作ると、出口を使わなくなる。 そして、出口を作れない相手のほうが先に分かります。

⑧ 現場で使うなら、この3枚

表1：ロックイン度を測る5問

すべて、自社側だけで答えられるかを問うています。

問い	答えられない場合
1. 開発環境をゼロから立ち上げるのに何日かかるか	演習をしていない。実測から始める
2. 主要な分岐の理由は文書に残っているか	再発見のコストが移行費の大半になる
3. AIの出力の良し悪しを判定する数字を自社で出せるか	差し替えの意思決定ができない
4. 本番でしか動かない設定値はいくつあるか	数を把握していない時点で危ない
5. その仕組みを説明できる人は、自社に何人いるか	1人以下なら、バス係数1

3問目と5問目が、いまいちばん抜けやすいところです。

表2：契約に入れる4条項

条項	発動する時点	無いと
著作権・ライセンスの帰属	契約時	そもそも移せない
判断の記録の納品	毎月・毎リリース	理由が消える
評価データの自社保有	毎月	AIを替えた結果を判定できない
年1回の移行演習への協力	毎年	出口が開くか、離れる日まで分からない

下の3つが、平時に発動する条項です。 上の1つだけで安心していたのが、10年前の失敗でした。

表3：移行費を見積もるときの内訳

層	見積もりの根拠にするもの	AI導入後の変化
書き直し	行数・画面数	大きく下がった
再発見	理由が不明な分岐の件数	変わらない
検証	判定用データの有無	変わらない

総額を1本で比べても意味がありません。 3層に割って、2層目と3層目が何で決まっているかを聞いてください。そこを説明できる相手は、移行をやったことがあります。

⑨ この見方が効き続ける理由

ロックイン対策が所有権の話に寄っていたのは、書き直しが高かったからです。既存のコードを丸ごと作り直すのが最大の費用なら、そのコードを持っていることが最大の対策になる。理屈は通っています。

その前提が、崩れました。

→ 書き直しの費用は、この2年で目に見えて下がった
→ 再発見と検証の費用は、1日も下がっていない
→ 結果として、移行費に占める比重が入れ替わった

比重が入れ替わったのに、対策の側は10年前の形のまま残っています。契約書の条項が守っているのは、いちばん安くなった層です。

だから、対策の主戦場は法務から運用へ移ります。条文に書いて安心する対象が、「渡してもらうもの」から「毎年やること」へ変わるということです。そして「渡されたものだけで、もう一度立ち上げられるか」という問いの形は、次に何が来ても変わりません。

囲い込まれているかどうかは、相手の姿勢では決まりません。 こちらが再現できるかどうかだけで決まります。相手が善良でも、再現できなければロックインです。 そして相手が強気でも、再現できるならロックインではありません。

---

ちなみに、この演習をお願いする場面は、言い方がなかなか難しいところです。

「万一お別れするときのために、練習させてください」と正面から言うと、さすがに角が立ちます。

通りが良いのは、「消防訓練だと思ってください」という言い方だそうです。 火事が起きると思って訓練する人はいない、という理屈です。苦笑しながら付き合ってもらえる程度には、角が取れます。

以上です。