ベンダーロックインはいつ始まるのか
「保守を別の会社に頼みたいが、現在のベンダーがソースコードを渡してくれない」「乗り換えようとしたら移行費用として数百万円を請求された」——こうした相談が増えています。
ベンダーロックインは、新しいシステムを発注した瞬間、あるいは保守契約を締結した瞬間から始まります。契約書に何が書かれているかが、5年後・10年後に選択肢があるかどうかを決めます。
本記事では、発注者がベンダーロックインを防ぐために契約前・更新時に確認すべき6つのポイントと、具体的な交渉の進め方を解説します。
ベンダーロックインが発生する主な原因
ベンダーロックインには4つの主要な原因があります。
1. ソースコードの権利がベンダーに帰属している
契約書に「著作権はベンダーに帰属する」と書かれている場合、発注者はソースコードを受け取ることができません。別のベンダーに保守を依頼しても、コードを読めないため対応できないか、膨大な解析コストがかかります。
2. データのエクスポートができない
SaaS型の業務管理ツールで「データをCSVやAPIでエクスポートできない」仕様になっている場合、サービス終了時にデータが取り出せなくなるリスクがあります。
3. 独自技術・独自フォーマットへの依存
特定のベンダーしか対応できない独自のフレームワークや、汎用性のないファイル形式でシステムが構築されている場合、他社への移行コストが極めて高くなります。
4. ドキュメントが整備されていない
システム設計書・仕様書・運用マニュアルがなければ、他のベンダーは保守に着手できません。「ドキュメントを納品物として契約書に明記していなかった」ケースが最も多い落とし穴です。
発注者が確認すべき6つのポイント
ポイント1：ソースコードと著作権の帰属
契約書で確認すべき記載は「著作権はユーザー（発注者）に帰属する」または「発注者は制限なく使用できるライセンスを受ける」という条文です。
IPAの「情報システム・モデル取引・契約書（第二版）」（2020年12月公開）では、汎用的な利用が可能なプログラムの著作権はベンダーに帰属させつつ、発注者が制限なく使用できる形を一つの選択肢として提示しています。自社専用の業務ロジック部分の著作権を発注者に帰属させることも可能な構成になっており、契約交渉時の参考として活用できます。
ポイントは「ソースコードの納品」を成果物として明記することです。「システムの動作保証」だけでは、コードを受け取る権利がないまま保守が続くことになります。
ポイント2：ドキュメントの納品義務
契約書に納品物として明記すべきドキュメントは以下の4種類です。
- システム設計書（基本設計・詳細設計）
- データベース設計書（テーブル定義・ER図）
- インフラ構成図（サーバー・ネットワーク設定）
- 運用・保守マニュアル（障害対応手順・バックアップ手順）
これらが揃っていれば、別のベンダーへの引き継ぎが現実的に可能になります。ドキュメントは「初版納品時」だけでなく、「保守フェーズでの更新義務」も契約に含めることが重要です。
ポイント3：データポータビリティ（持ち出し可能性）
システムが保持するデータを発注者がいつでも取り出せる仕組みが保証されているかを確認します。具体的には以下を契約または仕様に明記します。
- データのエクスポート形式（CSV・JSON・標準的なDBダンプ等）
- エクスポートの頻度・手順
- 契約終了時のデータ返却・削除手順とタイムライン
SaaS型サービスを利用する場合は、サービス利用規約のデータポータビリティ条項を必ず確認してください。
ポイント4：独占保守条項と競合禁止条項
「本システムの保守は甲のみが行うことができる」「第三者に保守を依頼することを禁止する」という条文が含まれていないか確認します。このような独占条項があると、問題があっても乗り換えることができません。
代わりに推奨する契約表現は「甲は乙の事前承諾なく第三者に本システムの保守を委託できる」または「保守契約の終了後、乙は新たな保守ベンダーへの引き継ぎに協力する義務を負う」という条文です。
ポイント5：引き継ぎ・移行支援の義務化
契約終了時のベンダー側の義務として、「移行支援期間」と「サポート内容」を明記します。一般的な内容は以下の通りです。
- 引き継ぎ期間：契約終了日から3〜6ヶ月間
- 新ベンダーへの技術説明・質疑応答への対応
- ドキュメントの最新版納品
- 環境構築手順書の提供
引き継ぎサポートに追加料金が発生する場合は、その上限額を契約書に明記しておくと交渉が有利になります。
ポイント6：エスクロウ制度の活用
ベンダーが倒産した場合に備える仕組みとして「ソフトウェアエスクロウ」があります。ソースコードを中立的な第三者機関に預け、ベンダーが倒産・廃業した場合に発注者がコードを受け取れるようにする制度です。
大規模なシステムでは有効な手段ですが、専門機関への費用が発生するため、中小企業の場合は「ソースコードの納品義務」と「定期的なコード共有（四半期ごとのリポジトリ共有等）」で代替するアプローチも選択肢の一つです。エスクロウの詳細は提供機関（ソフトウェア情報センター等）にご確認ください。
既存契約の見直しと更新時の交渉術
現状の確認から始める
まず現在の契約書を確認し、上記6ポイントのうちどれが不足しているかをチェックします。不足している項目を「追加条項」として次回更新時に盛り込む準備をします。
更新時の交渉の進め方
契約更新の3〜6ヶ月前から交渉を始めることが重要です。以下の順序で進めると効果的です。
- 現状のドキュメント整備を依頼する：「次回更新の条件としてドキュメント納品を求める」と事前通知する
- 複数社への相見積もりを取る：「他社への切り替えを検討している」という事実が交渉力になる
- 段階的な改善を提案する：一度に全条項の変更を求めると合意しにくい。今期はドキュメント整備、次期は引き継ぎ条項追加という段階的アプローチが現実的
マルチベンダー体制の構築
現実的なアプローチは「メインベンダー1社＋セカンドソース1社」の確保から始めることです。全システムを複数社に分散させる必要はなく、「緊急時に相談できる別のベンダーとの関係」を持つだけでも、メインベンダーへの依存度を心理的に下げることができます。
この記事のまとめ
- ベンダーロックインは契約締結時に始まる。ソースコード権利・ドキュメント・データポータビリティ・独占条項・引き継ぎ義務・エスクロウの6点を契約前に確認する
- IPA「情報システム・モデル取引・契約書（第二版）」が契約交渉の参考になる
- 既存契約は更新3〜6ヶ月前から交渉を開始。段階的な改善アプローチが現実的
- 中小企業の第一歩は「セカンドソース確保」と「ドキュメント整備の依頼」から
まとめ：発注者が主導権を持つための行動ステップ
ベンダーロックインを防ぐための行動を整理します。
- 新規発注時：ソースコード納品・ドキュメント整備・引き継ぎ支援義務を契約書に明記する
- 既存契約の更新時：不足条項を追加交渉する（3〜6ヶ月前から準備）
- 日常の保守運用：ドキュメントの最新性を四半期ごとに確認する
- リスク管理：定期的にセカンドソースのベンダーとコンタクトを持つ
特に中小企業では「全部ベンダーに任せる」方が楽に感じますが、主体的な関与が長期的なコスト削減と事業継続性の確保につながります。FUNBREWでは保守契約の見直し相談や、セカンドオピニオン的な技術評価も承っています。まずはお気軽にご相談ください。
この記事をシェア
保守契約の見直し・ベンダー評価をご検討中ですか？
「今のベンダーへの依存度が気になる」「契約書の内容を第三者に確認してほしい」といったご相談をお受けしています。まずはお気軽にお問い合わせください。