ベンダーロックインとは｜原因6つ・問題点と脱却の手順

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

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

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

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

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

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

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

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

ベンダーロックインの基本をすでにご存じの方は、② 見積もりを取ったら、桁が違って返ってきたから読み進められます。

ベンダーロックインとは

ベンダーロックインとは、特定の会社の製品・技術・体制に依存してしまい、他社へ乗り換えられなくなった状態のことです。囲い込まれた側は、価格も納期も相手の条件を受け入れるしかなくなります。

ロックインは、契約の話だけではありません。契約上は自由に切り替えられるのに、実際には切り替えられない状態が起こります。どこで縛られているのかを、種類で分けて見るのが最初の一歩です。

ベンダーロックインの2つの種類

種類	何に依存しているか	典型的な症状
コーポレートロックイン	特定の会社・特定の人	担当者しか中身が分からない。相見積もりを取っても比べられない
テクノロジーロックイン	特定の製品・独自技術	他の製品に載せ替えると、作り直しになる

対策の打ち方が違います。テクノロジー側は標準技術やオープンソースを選ぶことで下げられますが、コーポレート側は、資料と体制の側でしか下げられません。

クラウドで起きるロックイン

クラウドを使う場合は、そのクラウド固有の機能を使うほど移せなくなります。データの取り出し（エクスポート）にかかる費用や時間も、実際に移すときに効いてきます。

使わないことが正解とは限りません。固有の機能を使えば開発は速くなります。「どこまで固有機能に寄せるか」を意識して決めているかどうかが、偶然ロックインされている状態との違いです。

原因1｜設計書などのドキュメントが整備されていない

仕様書、設計書、運用手順書が無い、あるいは更新されていない状態です。中身が分かるのが、作った会社だけになります。

「納品されているか」と「読んで分かるか」は別です。納品物の一覧に設計書が並んでいても、最新の状態に更新されていなければ、他社は見積もれません。

原因2｜ベンダー独自の技術・仕様に依存している

その会社しか扱えないフレームワーク、独自の言語、公開されていない社内ライブラリ。技術者を採用しても引き継げなくなります。

発注時には見えにくい項目です。提案書に「自社独自の基盤」と書かれているとき、それが強みなのか、後の縛りなのかを聞いてください。

原因3｜システムの著作権がベンダー側にある

ソースコードの権利が受注側に残っていると、他社に渡して改修してもらうことができません。

権利の帰属は、後から変えられません。契約書の「著作権は乙に帰属する」という一文を、締結前に必ず確認してください。買い取る条件を先に決めておくという書き方もあります。

原因4｜契約期間や保守契約に縛りがある

長期契約、自動更新、途中解約の違約金、保守を切ると使えなくなるライセンス。切りたいときに切れない構造が、契約の側に埋まっていることがあります。

見るのは解約の条項です。解約時にデータをどの形式で受け取れるか、移行に協力する義務があるか、その作業は有償か。ここが空欄のまま締結されている契約は珍しくありません。

原因5｜社内にIT判断ができる人がいない

提案の妥当性、見積もりの妥当性、技術の選択。これらを判断できる人が社内にいないと、相手の提案をそのまま受け入れるしかなくなります。

これは技術力の話ではありません。「その見積もりの根拠は何か」と聞ける人がいるかどうかです。1人でも社内にいると、条件が変わります。

原因6｜業務プロセスが複雑で、個別に作り込まれている

自社の業務に合わせて細かく作り込むほど、同じものを他社が作り直す費用が上がります。

作り込み自体が悪いわけではありません。作り込んだ理由が記録として残っているかが分かれ目です。理由が残っていないと、他社は全部を必要な仕様として見積もります。

問題点1｜費用が高止まりする

他社と比べられないため、提示された金額が妥当かどうかを判定できません。相見積もりを取っても、条件を揃えられないため比較になりません。

高くなるのは改修費だけではありません。保守費、ライセンス費、そして「調査費」として計上される作業が積み上がります。

問題点2｜開発の主導権を握られる

やりたいことを伝えても、「その作りでは難しい」と言われれば確かめる手段がありません。優先順位も納期も、相手の都合で決まります。

判断の材料が相手からしか来ない状態が、ロックインの実態です。別の見方を持ち込める相手を、どこかに確保しておいてください。

問題点3｜他社への移行や内製化が難しくなる

資料が無い、権利が無い、独自技術が使われている。この3つが揃うと、移行の見積もりが「作り直し」の金額になります。

移行できないと分かった時点で、交渉の材料が無くなります。乗り換える気が無くても、乗り換えられる状態を保つこと自体に価値があります。

問題点4｜古いまま使い続けることになる

改修の費用が高いため、必要最小限の変更しかしなくなります。結果として、技術も業務も古いまま固定されます。

新しい仕組みを足そうとしたときに、この固定が最初の障害になります。既存システムと繋げられないという理由で、検討そのものが止まります。

問題点5｜相手の事業が止まったときに、行き場が無くなる

倒産、事業撤退、担当者の退職。依存先が1社だと、その1社の事情がそのまま自社の事業リスクになります。

特に人に依存している場合が危険です。会社が続いていても、その人が辞めた時点で中身が分からなくなります。

問題点6｜データが取り出せず、活用できない

データが特定の製品の形式でしか存在しないと、他の仕組みと組み合わせられません。分析や新しい活用の話が、そこで止まります。

データの持ち出しやすさ（可搬性）を、契約の条件に入れてください。どの形式で、どの範囲を、どのくらいの期間で受け取れるのか。「取り出せます」だけでは足りません。

ベンダーロックインにも、良い面はある

業務を分かっている相手なので、説明の手間が少ない
過去の経緯を知っているため、判断が速い
関係が長いぶん、無理を聞いてもらえることがある

この良さは実在します。問題は依存そのものではなく、依存していることに気づかないまま条件を比べられなくなることです。長く付き合う判断を、自分で選んでいるかどうかが分かれ目になります。

公的機関での実態と、公正取引委員会の指摘

自治体や官公庁のシステム調達では、同じ事業者と契約が続く割合が高いことが調査で示されています。仕様書を職員だけで作れていない、オープンソースの採用が進んでいない、といった状況も報告されています。

公正取引委員会も、調達の実態としてロックインが競争を妨げている点を指摘しています。民間でも構造は同じです。仕様を自分で書けないところから、依存が始まります。

発注前にできる予防策

対策	具体的に何を決めるか
権利の帰属を決める	ソースコードと成果物の著作権をどちらが持つか。買い取り条件
納品物を契約に書く	設計書・運用手順書と、その更新の義務
標準技術・オープンソースを優先する	独自基盤への依存度を下げる
データの可搬性を確保する	出力形式、範囲、期間、費用
解約と移行の条件を書く	移行協力の義務と、その作業の扱い
複数社の体制を視野に入れる	開発と保守を分ける、など

6つとも、契約の前にしか決められません。着手後に持ち出すと、追加の条件として費用が付きます。

すでに陥っている場合の脱却手順

	やること	終わったと言える状態
1. 依存を棚卸しする	何に、どの程度依存しているかを一覧にする	種類（会社／技術／契約／人）で分けられている
2. 資料を最新化する	現状の設計と運用を書き起こす	他社が読んで見積もれる
3. 社内の規定を見直す	調達のルール、相見積もりの条件	同じ状態を繰り返さない仕組みがある
4. 契約を見直す	権利、解約、保守の範囲	解約時の手順が書かれている
5. 優先順位を付けて移す	全部を一度に移さない	止まっても業務が回る単位で分かれている
6. 移行先を選ぶ	複数社で比較する	条件を揃えた比較ができている
7. 社内に担当を置く	判断できる人を決める	窓口が1人以上いる

2を飛ばして6に行くと、比較になりません。資料が無い状態で相見積もりを取ると、各社が別々の前提で見積もることになります。

脱却を進めるときの注意

全部を一度に移そうとしない — 止まっても業務が回る単位に割る
現行のベンダーを敵に回さない — 移行には相手の協力が要る
業務そのものを見直す — 作り込みの理由が消えている箇所を探す
期間を長めに見る — 調査と資料づくりに時間がかかる
移行後の体制まで決める — 移した先で同じことが起きないように

2つ目は実務上とても重要です。移行の作業には、現行の担当者しか知らない情報が必ず要ります。取引を続ける前提で協力を仰ぐほうが、結果的に速く終わります。

ベンダーロックインについてよくある質問

Q. ベンダーロックインとは何ですか。
特定の会社の製品・技術・体制に依存し、他社へ乗り換えられなくなった状態です。コーポレートロックイン（会社や人への依存）とテクノロジーロックイン（製品や独自技術への依存）に分かれます。

Q. ベンダーロックインは、なぜ起きるのですか。
設計書などの資料が整備されていない、独自技術に依存している、著作権がベンダー側にある、契約や保守に縛りがある、社内に判断できる人がいない、業務が個別に作り込まれている。この6つが主な原因です。

Q. ベンダーロックインを防ぐには、何を契約に書けばよいですか。
成果物の権利の帰属、設計書と運用手順書の納品と更新、データの出力形式と範囲、解約時の手順と移行協力の扱いです。これらは着手後に持ち出すと、追加の条件として費用が付きます。

Q. すでに陥っている場合、どこから手を付ければよいですか。
依存の棚卸しと、資料の最新化からです。資料が無い状態で相見積もりを取っても、各社が別々の前提で見積もるため比較になりません。

Q. ベンダーロックインに良い面はありますか。
あります。業務を分かっている相手なので説明の手間が少なく、判断も速くなります。問題は依存そのものではなく、依存に気づかないまま条件を比べられなくなることです。

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

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

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

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

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

ここまでが、ベンダーロックインの教科書どおりの整理です。原因を種類で分け、契約で権利と資料と解約条件を押さえ、標準技術を選び、複数社の体制を用意する。

この記事の後半で扱うのは、この対策が全部入っていた案件で、乗り換えようとしたときに何が起きたかです。契約も納品物も、不備はありませんでした。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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年前の形のまま残っています。契約書の条項が守っているのは、いちばん安くなった層です。

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

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

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

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

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

以上です。

ベンダーロックインよくある質問

ベンダーロックインとは何ですか？

特定の会社の製品・技術・体制に依存してしまい、他社へ乗り換えられなくなった状態です。特定の会社や人に依存するコーポレートロックインと、特定の製品や独自技術に依存するテクノロジーロックインの2種類に分かれます。契約上は自由に切り替えられるのに、実際には切り替えられないという形で現れるのが特徴です。

ベンダーロックインは、なぜ起きるのですか？

主な原因は6つです。設計書や運用手順書が整備・最新化されていない、ベンダー独自の技術や仕様に依存している、システムの著作権がベンダー側にある、契約期間や保守契約に縛りがある、社内にIT判断ができる人がいない、業務プロセスが複雑で個別に作り込まれている。納品されていても更新されていない資料は、他社が見積もれないため同じ結果になります。

ベンダーロックインを防ぐには、何を契約に書けばよいですか？

成果物とソースコードの著作権の帰属（または買い取り条件）、設計書・運用手順書の納品と更新の義務、データの出力形式・範囲・期間、解約時の手順と移行協力義務の扱いです。あわせて標準技術やオープンソースを優先し、開発と保守を分けるなど複数社の体制も視野に入れます。これらは着手後に持ち出すと追加の条件として費用が付きます。

すでにベンダーロックインに陥っている場合、どこから手を付ければよいですか？

依存の棚卸しと、資料の最新化からです。何に、どの程度（会社／技術／契約／人）依存しているかを一覧にし、他社が読んで見積もれる状態まで資料を書き起こします。資料が無い状態で相見積もりを取っても、各社が別々の前提で見積もるため比較になりません。移行は、止まっても業務が回る単位に割って進めます。

ベンダーロックインに良い面はありますか？

あります。業務を分かっている相手なので説明の手間が少なく、過去の経緯を知っているぶん判断も速くなります。問題は依存そのものではなく、依存していることに気づかないまま条件を比べられなくなることです。長く付き合う判断を、自分で選んでいるかどうかが分かれ目になります。

ベンダーロックインとは何ですか？

特定の提供者の製品・技術・体制に依存してしまい、他へ乗り換えようとすると費用や期間が現実的でなくなり、事実上動けなくなる状態のことです。値上げや品質低下を受け入れざるを得なくなる、要望への回答が遅くなっても他に選択肢がない、といった形で表面化します。技術的な依存だけでなく、その仕組みを理解している人が相手側にしかいないという人の依存も含みます。

ソースコードの著作権を自社に帰属させれば、ロックインは防げますか？

防げません。所有権が移っても、そのコードがなぜそう書かれているかは移らないからです。実務で移行を止めるのは書き直しの作業量ではなく、既存の分岐や例外処理の理由を再発見する時間です。著作権の帰属は必要な条件ですが、それだけでは足りない条件だと理解しておくと、契約書に何を足すべきかが決まります。

マルチベンダーにすればロックインは解消しますか？

依存先が移動するだけのことがあります。複数社に分割すると、今度は全体をつなぐ役割を担う会社が生まれ、そこが新しい単一障害点になります。分割そのものより、どの会社が抜けても業務を立ち上げ直せるかを、実際に試して確かめられるかどうかが効きます。

AIを使ったシステムでは、ロックインの何が変わりますか？

依存の場所が、コードから評価データへ移ります。モデルの呼び出しは差し替えやすく設計できますが、差し替えた結果が良くなったのか悪くなったのかを判定するには、何を正解とするかの集合が要ります。この評価セットと失敗事例の履歴を提供側だけが持っていると、乗り換えは技術的に可能でも意思決定として不可能になります。