「数年前に業務システムを作ってもらった開発会社の担当者が辞め、会社自体も連絡が取りにくくなりました。ちょっとした修正を頼んでも返事が遅く、他社に相談しようにもソースコードも仕様書も手元にない。結局、言われるままに高い保守費を払い続けています」——卸売業を営む会社の方から、こんな相談を受けました。一度システムを作ってしまうと、その会社以外は中身に手を出せず、値上げにも交渉できない。この「特定のベンダーに縛られて身動きが取れない状態」を、ベンダーロックインと呼びます。
厄介なのは、ロックインの大半が「作り終わった後」ではなく「発注のときの詰め方」で決まっている点です。契約書と納品物のどこを握っておくかで、あとから他社に引き継げるかどうかが分かれます。本記事では、なぜ縛られてしまうのか、発注の段階で何を押さえれば防げるのか、そして近年とくに縛られやすくなっている理由を、発注する側の視点で整理します。
なぜ「その会社しか触れない」状態になるのか
ロックインは、悪意ある囲い込みだけで起きるわけではありません。多くは、発注時に取り決めをしなかった結果として自然に生まれます。経路は主に三つです。
一つ目は、ソースコードと著作権の問題です。契約で何も定めていないと、作られたプログラムの著作権は制作した側に残るのが原則です。すると、発注側はコードを他社に渡して改修してもらう権利を持てず、元の会社に頼み続けるしかなくなります。二つ目は、ドキュメントの不在です。設計書や運用手順が残っていないと、他社が引き継ごうにも中身の解読から始めることになり、見積もりが跳ね上がるか、そもそも断られます。三つ目は、その会社にしか扱えない独自の作りです。広く使われている技術ではなく、開発会社が独自に組んだ仕組みで作られていると、扱える技術者が限られ、実質的にその会社の専属になります。この三つが重なると、他社への乗り換え費用が高くなりすぎて、事実上抜け出せなくなります。
発注「前」に契約と仕様で押さえておくこと
ロックインを防ぐ最大の機会は、契約を交わす前です。作り終わってから「コードをください」と言っても、契約に書いていなければ交渉は難航します。発注段階で次の点を取り決めておくだけで、将来の選択肢が大きく変わります。
| 押さえる点 | 発注時に確認・明記すること |
|---|---|
| 著作権・利用権 | 成果物の著作権を自社に譲渡、または自由に改修・移転できる利用権を明記 |
| ソースコードの納品 | 完成品だけでなくソースコード一式を納品物に含める |
| ドキュメント | 設計書・運用手順・環境構成を納品物として指定 |
| 使用技術 | 特定ベンダー独自の仕組みではなく、広く使われる技術での構築を求める |
| データの持ち出し | 蓄積したデータを標準的な形式で取り出せることを条件にする |
とくに効くのが、著作権の扱いとソースコードの納品の二つです。ここを契約に入れておけば、たとえ開発会社と関係が切れても、コードと権利を持って他社に引き継げます。発注前の要件のまとめ方や見積もりの取り方はシステム開発のRFPと費用の記事にまとめているので、あわせて確認してください。逆に、契約書にこれらの条項がなく、口頭で「大丈夫です」と言われるだけなら、その一点で発注を見送る理由になります。
弊社が発注のお手伝いをしたある小規模な製造業の会社では、当初の見積書に成果物の著作権や納品物の記載がまったくありませんでした。そのままなら数年後に前述のロックインへ一直線だったところを、契約前に「ソースコード一式と設計書を納品物に含める」「成果物を自由に改修・移転できる利用権を得る」の二点を条項として加えてもらいました。開発費は数万円ほど上がりましたが、その後に別の会社へ保守を切り替えたいとなったとき、コードと設計書を渡すだけで見積もりが取れ、乗り換えがすんなり進みました。発注前のわずかな一手間が、数年後の交渉力を丸ごと左右した例です。
AIで作ったシステムほど、実は縛られやすい
近年、この問題に新しい火種が加わりました。生成AIを使った開発の広がりです。AIにコードの大半を書かせて短期間で作る手法は費用と納期の面で魅力的ですが、発注側から見ると ロックインのリスクをむしろ高める側面があります。
理由は二つあります。まず、AIが大量に生成したコードは、作った本人ですら細部を説明できないことがあり、ドキュメントが残らないまま納品されがちです。数か月後に不具合が出たとき、誰も全体像を把握していない、という事態が起こります。次に、AI生成コードは動いてはいるものの内部が整理されていない「見えない負債」を抱えやすく、時間が経つほど手を入れにくくなります。この「AIに書かせたコードが半年後に劣化する」現象はAI生成コードが腐る記事で詳しく扱っています。安く速く作れるという触れ込みの裏で、引き継ぎ用のドキュメントや設計の整理が省かれていないか——発注側は、成果物にコードだけでなく「他社が読んで引き継げる状態」が含まれるかを、これまで以上に確認すべき局面です。
すでに縛られている場合の抜け出し方
「もう作ってしまった。契約にも何も書いていない」という場合でも、打つ手はあります。ポイントは、一気に全部を乗り換えようとしないことです。
まず着手すべきは、蓄積されたデータの確保です。日々の業務データが標準的な形式で取り出せるなら、たとえシステム本体を作り替えても、業務の記録は守れます。データを安全に移す進め方は業務システムのデータ移行の記事で整理しています。次に、現在のシステムを丸ごと置き換えるのではなく、機能ごとに段階的に別の仕組みへ移していく。使い続けながら少しずつ移すことで、業務を止めずにロックインから抜けられます。焦って全面刷新を急ぐと、かえって新しいベンダーに同じ形で縛られる危険があるため、次の発注では本記事の契約条項を必ず入れることが肝心です。
「安く早く」の裏で、引き継げる状態になっているか
システム開発の発注で本当に見るべきは、目先の費用や納期だけではありません。その開発会社がいなくなっても、コードとデータとドキュメントを持って他社に引き継げるか——この一点を発注前に握っておくかどうかで、数年後の自由度がまるで変わります。とくに生成AIで速く作る提案が増えたいまは、「速さ」と引き換えに引き継ぎ性が失われていないかを確かめる価値があります。
「発注しようとしている契約書に、ソースコードや著作権の条項が入っているか見てほしい」「今のシステムが特定の会社に縛られていて、抜け出す道筋を相談したい」「AIで安く作るという提案が、後々のリスクにならないか判断したい」——そうしたお悩みがあれば、グリームハブの開発・AI・自動化のご相談からお気軽にお問い合わせください。発注者が縛られない形での進め方を、契約と設計の両面でご一緒に組み立てます。
