ベンダーロックインとは｜回避策と6構成の比較
こんにちは、合同会社SAi代表の佐藤です。受託開発を月額制で請けています。
先日、ある会社から開発のご相談をいただき、その中に「ベンダーロックインとなる要素の有無」という質問がありました。正面から答えるために、クラウド各社の制限と料金を一つずつ調べ直しました。この記事は、そのとき分かったことをまとめたものです。
「うちは大丈夫です」と言われて安心してはいけません。確認すべきことは決まっていて、しかも技術より契約のほうが効きます。
結論：ロックインは「契約」と「独自ランタイム」で起きる
ベンダーロックインとは、特定の開発会社やサービスから他へ移れなくなる状態のことです。値上げを飲むしかない、担当者が辞めても文句を言えない、機能追加を断られても諦めるしかない。そういう状態を指します。
多くの人が「どのクラウドを選ぶか」の問題だと思っています。違います。発生源は3つあり、そのうち2つは契約の話です。
- 権利：ソースコードの著作権が開発会社に残っている
- 技術：他社が触ったことのない仕組みで作られている
- データ：解約しても、データを使える形で取り出せない
このうち①と③は契約書に書けば解決します。②だけが設計の話です。順に見ていきます。
ロックインが生まれる3つの場所と、発注前に聞く質問
① 権利：ソースコードは誰のものか
日本の著作権法では、何も取り決めをしなければ、ソースコードの著作権は作った側（開発会社）に残ります。発注してお金を払っても、自動的に発注者のものにはなりません。ここを知らずに進める会社が本当に多いです。
聞くべき質問はこれです。
「ソースコードの著作権は、どちらに帰属しますか。契約書のどの条項に書かれていますか」
「納品します」という答えだけでは足りません。納品と権利の移転は別だからです。コピーを渡されても、権利が相手にあれば、他社に見せて改修してもらうことができません。
なお当社は、社内で使う業務システムの場合は譲渡せず、プロダクト開発（お客様が自社の商品として外部に販売するもの）の場合は譲渡する、と分けています。どちらが良い悪いではなく、どちらなのかを先に決めておくことが大事です。
② 技術：他社が引き継げる形か
ここが唯一、設計の話です。判断の軸は一つだけで、その技術を使える会社が世の中に何社あるかです。
聞くべき質問はこれです。
「このシステムは、他のクラウドや自社サーバーでも動きますか。移すとしたら何が必要ですか」
答えが「動きます」で終わるなら、もう一段掘ってください。アプリをコンテナ形式（Docker）で納品してもらえるなら、実質どこでも動きます。逆に、特定のクラウドにしか無い仕組みを土台に使っていると、移すときに作り直しになります。
③ データ：解約後に持ち出せるか
システムを止めても、顧客データは残ります。これを標準的な形式で取り出せるかどうかです。
「解約後、データはどの形式で受け取れますか。保持期間はどれくらいですか」
データベースが標準的なPostgreSQLやMySQLなら、まるごとエクスポートして他社に渡せます。独自形式で保存されていると、ここで詰みます。
クラウド6構成を比較した
1,000店舗規模のマルチテナント型サービスを想定して、実際に検討した構成です。当社が店舗向けのLINE配信サービスを約100店舗に提供している経験をもとにしています。運用の手間と引き継ぎやすさは、だいたい反比例します。
| 構成 | 東京リージョン | 引き継ぎやすさ | 運用の手間 |
|---|---|---|---|
| Cloudflare Workers + Neon | ✗（アジアはシンガポール・シドニー） | △ 独自ランタイム | ◎ ほぼゼロ |
| Cloudflare Workers + Supabase | ○ | △ 同上 | ◎ |
| Cloud Run + マネージドPostgreSQL | ○ | ◎ コンテナで渡せる | ○ |
| AWS ECS + Aurora Serverless v2 | ○ | ○ | △ 設定項目が多い |
| Fly.io + Postgres | ○ | ○ | △ データベースを自分で見る |
| VPS 1台 + Docker + PostgreSQL | ○ | ◎ | ✗ 冗長性がない |
引き継ぎやすさで言えばコンテナ形式で動かす構成が最も強いです。コンテナはどのクラウドでも、自社サーバーでも同じように動きます。逆に、サーバーレスの独自ランタイムは運用が楽な代わりに、その会社のサービスに紐づきます。
一番下のVPS1台は移植性が最高ですが、機械が1台止まったら全部止まります。小規模なら現実的な選択肢です。
カタログに書いていない3つの制約
調べて初めて分かったことを3つ書きます。料金表の一番上には書いていない部分です。
東京リージョンが無いサービスがある
サーバーレス系のデータベースには、東京リージョンを持っていないものがあります。アジア太平洋ではシンガポールとシドニーだけ、という状態です。しかもプロジェクトを作った後にリージョンは変更できません。移すには新規に作り直してデータを移行することになります。
日本から使うと、データベースへの往復が毎回70〜80ミリ秒増えます。1画面で5回問い合わせれば0.35秒。バッチ処理なら問題ありませんが、店舗が毎日触る管理画面では体感できる差になります。
もう一つ、法律の話があります。個人情報保護法では、外部に委託してデータを保管する場合「外的環境の把握」として、保管されている国を把握し、その国の制度を踏まえた安全管理措置を講じることが求められます。プライバシーポリシーにも保管国を書くことになります。国内に揃えておけば、この説明が要りません。
独自ランタイムは「Node.jsがそのまま動く」わけではない
エッジ実行環境の一部は、Node.jsではなく独自のランタイムで動いています。見た目はJavaScriptですが、Node.js向けに書いたコードがそのまま動くとは限りません。
アプリ本体は、複数の環境で動くフレームワークを使えば移植できます。問題は周辺で、定期実行・キュー・簡易データストア・オブジェクトストレージといった「その会社にしか無い部品」は持っていけません。ここを土台にして作ると、移すときに作り直しになります。
引き継ぐ側の立場でも考えてみてください。別の開発会社が保守を引き受けるとき、「触ったことがない」と言われる可能性があるかどうか。ここは技術の優劣ではなく、使っている会社の数の問題です。
バックアップは「日次」と「時点復旧」で料金が違う
マネージド型のデータベースには、たいてい日次バックアップが標準で付いています。ただし「任意の時点に戻す」機能（ポイントインタイムリカバリ）は別料金で、月100ドル前後かかるのが相場です。
これを知らずに「バックアップは込みです」と説明すると、後で揉めます。誤って大量のデータを消したとき、日次バックアップだけだと最大24時間ぶんが戻りません。見積もりを見るときは、どちらが入っているか確認してください。
1,000店舗規模で実際に積算してみた
上の制約を踏まえて、東京リージョンに揃えた構成（コンテナ実行基盤＋マネージドPostgreSQL）で積算した例です。1店舗あたり月8回・友だち500人へ配信、履歴は13か月保持という前提です。
| 項目 | 10店 | 100店 | 1,000店 |
|---|---|---|---|
| 実行基盤 | 無料枠 | 1,100円 | 33,700円 |
| データベース | 3,880円 | 6,200円 | 39,760円 |
| 画像の保管と配信 | 込み | 込み | 16,950円 |
| バックアップ・ログ・検証環境 | — | — | 30,000円 |
| メール送信 | 無料枠 | 3,100円 | 5,430円 |
| 生成AI | 560円 | 5,600円 | 56,000円 |
| 監視・エラー収集 | 無料枠 | 4,810円 | 4,810円 |
| 合計 | 約4,400円 | 約20,800円 | 約186,600円 |
| 1店舗あたり | 444円 | 208円 | 187円 |
各社の公表価格に使用量を当てはめた見込み額です（1ドル155円換算・税込）。迷った項目は高い側に寄せています。
見ていただきたいのは金額そのものより、1店舗あたりが444円から187円へ下がることです。インフラ費用は店舗数に比例しません。そして1,000店舗でも月19万円程度です。ここが想像より高く見積もられていると、事業計画そのものが狂います。
契約で押さえる4項目
技術より、こちらのほうが効きます。以下を契約書に明記できれば、ロックインはほぼ防げます。
- ソースコードの著作権の帰属。譲渡するのか、使用許諾なのか。譲渡なら、いつの時点で移るのか
- 納品の形態。コンテナ形式で、そのまま動く状態で渡されるか。手順書は付くか
- 保守の移管。他社へ引き継ぐとき、引き継ぎ資料の作成と説明に応じてもらえるか
- データの書き出し。解約後、どの形式で、いつまでに受け取れるか
4番目を忘れがちですが、解約を申し出た後に揉めるのはたいていデータです。「解約から30日以内に、標準的な形式で書き出したものを提供する」と書いておけば済みます。
契約前に確認すべきことは、月額制の受託開発について書いた記事でも5項目にまとめています。あわせてご覧ください。
当社の場合
特定のクラウドを標準と決めてはいません。案件ごとに、規模と引き継ぎやすさを見て選びます。ただし守っていることが3つあります。
- 当社だけの特殊な仕組みは使わない。広く使われている標準的な技術だけで組む
- クラウドの契約をお客様名義で取得していただくこともできる。請求も管理画面もお客様の手元に置けます
- プロダクト開発はソースコードを譲渡する。他社への移管も可能です
一人で開発から運用まで見ている会社なので、「担当者が辞めたら分からなくなる」という心配をされることがあります。だからこそ、引き継げる形で作っておくことを自分の側の責任だと思っています。料金と取引条件はすべて公開していますし、開発の実績も個別のページで、対応できない条件まで書いています。
よくある質問
Q. 自治体のシステムでロックインが問題になるのはなぜですか
長く使われている大規模システムで、仕様書もソースコードも当初のベンダーしか持っていない状態が続いたためです。入札しても他社が見積もりを出せず、結果的に随意契約が続きます。権利とドキュメントを発注側が持っていなかったことが根本の原因です。
Q. AWSやGoogle Cloudに寄せるのはロックインですか
程度問題です。仮想サーバーやコンテナ、標準的なデータベースだけを使っているなら、移すのは難しくありません。一方、そのクラウドにしか無いサービスを土台に据えると、移植は作り直しに近くなります。「どこまで固有機能に寄りかかっているか」で判断してください。
Q. 一括請負ならロックインしませんか
支払い方法とロックインは関係ありません。一括で数百万円払っても、契約書にソースコードの譲渡が書かれていなければ権利は移りません。確認すべきは金額ではなく条項です。
Q. 小規模なシステムでも気にするべきですか
規模が小さいほど、作り直しの費用も小さくなります。数十万円で作れるものなら、ロックインされても作り直せば済みます。気にするべきなのは、止まると業務が止まるシステムと、事業の中核になるシステムです。
開発の外注を検討されていて、契約条件や構成でご不明な点があれば、お問い合わせからお気軽にご相談ください。ご相談だけでも構いません。当社がどういうものを作っているかは、サービス一覧とホームページ制作のページにまとめています。
