ベンダーロックイン対策｜技術責任者がいない会社が開発会社・クラウド・SaaSに縛られない方法と脱却の順番

ベンダーロックインの対策は、発注前・契約時・運用中の3つの場面で打てます。社内に技術責任者がいない経営者に向けて、開発会社・クラウド・SaaSに縛られないための確認項目と、すでに抜け出せない場合に何から確かめるかという脱却の順番を、CTO代行の経験をもとに解説します。

2026年10月5日

執筆者

運営者・AIエンジニア／ IT歴36年以上

ベンダーロックイン対策｜技術責任者がいない会社が開発会社・クラウド・SaaSに縛られない方法と脱却の順番

要約

ベンダーロックインは、「データ」「ソースコード」「管理者の権限」の3つを自社で持っているかで、防げるかどうかがほぼ決まります。
防ぐ機会は、発注前・契約時・運用中の3回あります。いちばん効果的なのは発注前で、乗り換えるときの費用を見積もりの段階で出してもらうことです。
すでに離れられない場合は、いきなり乗り換え先を探さず、「自社が持っているもの」の棚卸し→データの持ち出し→コードと権限の移管→乗り換えの順で進めます。

ベンダーロックインとは「ほかの会社に頼めなくなる状態」のこと

ベンダーロックインとは、特定の開発会社やサービスに頼りきりになり、他社に乗り換えられなくなる状態のことです。ここでいうベンダーとは、システムを作ったり、サービスを提供したりする会社を指します。

公正取引委員会は、2022年2月に公表した官公庁のシステム調達の調査で、ベンダーロックインを「システムを使い続けるのに必要な改修や保守を、導入した事業者以外ができないため、その事業者を使い続けなければならない状態」と定義しています。保守とは、作ったシステムを動かし続けるための修理や更新の作業のことです。

この定義でいちばん重要なのは、「ほかの会社では作業ができない」ことが問題の正体だという点です。値段が高いこと自体は、ロックインの結果にすぎません。ほかに頼める会社があれば、値段の交渉ができます。頼める会社がないから、言い値を受け入れるしかなくなるのです。

縛られる相手は開発会社だけではない

社内に技術責任者がいない会社では、次の3種類の相手に縛られることがよくあります。

相手	縛られる例
開発会社	作ってもらったシステムの中身を、その会社しか分からない
クラウド	特定の会社の独自の機能に合わせて作ってしまい、ほかへ移せない
SaaS	顧客情報などのデータが、そのサービスの中からうまく取り出せない

クラウドとは、インターネット越しに借りて使うサーバー（データを保存したりプログラムを動かしたりするコンピューター）やデータの置き場所のことで、AWSやGoogle Cloudが代表例です。SaaSとは、インターネット越しに使うソフトのことで、自社で持たずに月額などで借りて使います。

技術責任者がいない会社で起きやすい理由

私はCTO代行として、技術責任者のいない会社の問題を何度も間近で見てきました。典型的なのは、経営者が技術的に正しいかどうかを判断できず、外注先の言い値や説明をそのまま受け入れ、何年もたってから「保守費用が高すぎる」「システムを直したくても身動きが取れない」と気づくケースです。

システムを分かっている社員が1人だけで、その人の退職と同時に手を付けられなくなった会社も、複数見てきました。これは外部の会社ではなく社内の個人に縛られている状態ですが、仕組みとしてはベンダーロックインと同じです。

経営者が押さえるべきは「3つの所有物」

ロックインを防ぐ話は、技術の話に見えて、実は所有物の話です。経営者が確かめるべき所有物は、次の3つです。

データ：顧客情報、注文、会員などの記録。会社の財産そのものです。
ソースコード：プログラムの設計図にあたる文字の集まり。これがないと、ほかの会社は直せません。
管理者の権限：サービスの設定を変えたり、ほかへ移したりできる、いちばん強い権限です。クラウド、ソースコードの保管場所、ドメインなどにあります。

ドメインとは、ホームページやメールの住所にあたる名前（example.com など）のことです。

この3つを自社で持っていれば、たとえ今の開発会社との関係が悪くなっても、別の会社に引き継げます。逆に、どれか1つでも開発会社が所有していれば、そこが抜け出せない原因になります。ロックイン対策とは、この3つを自社の手元に置き続けることだと覚えておいてください。

発注前にやること：乗り換えの費用を先に見積もる

いちばん安く、いちばん確実に防げるのが発注前です。作り始めてからでは、直す費用がどんどん大きくなります。

失敗談：安さで選んだ設計が、あとで作り直しになった

私自身にも苦い経験があります。日本で動画配信の仕組みを作った際、安さだけで判断して、特定のデータベースに頼りきった設計にしてしまいました。データベースとは、顧客情報や注文などのデータを整理してためておく仕組みのことです。

あとで別のサービスへ移ろうとしたところ、大がかりな作り直しが必要になりました。最初に浮いた費用より、移るときの費用のほうがはるかに大きかったのです。この出来事は、実務ケース「コストだけで選んだデータベースが、あとで足かせになった話」で詳しく紹介しています。

それ以来、私は見積もりの段階で、1つの業者に縛られた場合にかかる費用を、毎回計算しています。経営者の方にも、同じことを発注先に確認することをおすすめします。

発注先に聞くべき質問

発注前の打ち合わせでは、次のように質問してください。技術が分からなくても、答え方で相手の姿勢が分かります。

「このシステムを、将来ほかの会社に引き継ぐことになったら、何が必要で、いくらくらいかかりますか」
「データは、どんな形式で取り出せますか」
「特定の会社のサービスにしかない機能を使う部分はどこですか。使う理由は何ですか」
「ソースコードはどこに保管し、誰が管理者になりますか」

「引き継ぎのことは考えなくて大丈夫です」と答える会社には注意が必要です。まともな会社なら、引き継ぎに必要なものを具体的に答えられます。

「誰でも触れる技術か」を基準にする

もう1つ、私が判断の基準にしているのは「新しい技術かどうか」ではなく、「ほかの技術者でも扱える技術かどうか」です。

日本でASP事業（インターネット越しにソフトを貸し出す事業）を立ち上げたとき、当時流行していた独自のやり方ではなく、あえて使い古された技術の組み合わせを選びました。扱える人を採用しやすく、資料も多いため、管理しやすいからです。担当が何度か替わっても仕組みは動き続け、その後、事業を売却したときもスムーズでした。

珍しい技術を使ったシステムは、その技術を扱える会社が少ない分だけ、管理や乗り換えも難しくなります。流行より、引き継ぎやすさを選ぶのが、経営者として正しい判断です。

何でも自社で作る必要はない

ロックインを恐れて、何でも自社で作ろうとするのも間違いです。私は、経理や勤怠管理のように自社の強みと関係のない業務には、迷わずSaaSを使います。一方、顧客に届ける価値そのものに関わる部分は、自社で開発しました。

自社で作るか、SaaSを借りるかは、「その部分で、お客様が他社ではなく自社を選んでくれるかどうか」で決めます。経理や勤怠管理のように、どの会社でもやり方がほぼ同じ業務は、SaaSを借りて済ませます。自社の強みになる部分は、自社のものとして作ります。こうして分けておけば、ロックインの問題を小さくできます。

契約時にやること：所有物を自社に残す条項を入れる

契約書は、発注前に決めたことを守らせるためのものです。口約束で済ませず、書面に残しましょう。

契約書に入れるべき項目

最低限、次の点を契約書や付属の文書で取り決めておきます。

データ：自社のデータは自社のものであること。いつでも、ほかのソフトで取り出せること。
ソースコード：納品物にソースコードを含めること。保管場所の管理者は自社にすること。
仕様書と設計の資料：納品物に含めること。仕様書とは、システムに何をさせるかを書いた文書のことです。
引き継ぎへの協力：契約が終わるとき、次の会社への引き継ぎに協力すること。

契約書のひな形に迷ったら、IPA（情報処理推進機構）が2020年12月に公開した「情報システム・モデル取引・契約書」第二版が参考になります。受託開発、保守運用、パッケージやSaaSの活用に対応していて、発注側と開発会社のどちらかに有利に偏らない契約書をめざしたものです。自社で一から条文を考えるより、こうしたひな形をもとに相手と話すほうが、抜け漏れが少なくなります。

性能や障害対応の条件は数字で書く

これは、私の失敗から学んだことです。初期の案件で、想定するアクセス数や、障害のときにどこまで対応するかを曖昧にしたまま契約し、動き始めてから「話が違う」ともめることになりました。

曖昧な契約は、あとで開発会社の解釈に従うしかなくなります。これもロックインの一種です。条件は必ず数字で文書にしましょう。言った言わないの争いは、ほぼなくなります。

事業を売るときに必ず見られる点でもある

私は日本で、自分の事業を他社に譲渡した経験があります。そのとき技術面で重点的に確認されたのは、システムの権利関係（自社で開発したものか、他社から使用の許可を受けているものか）、1人の担当者にしか扱えない部分はないか、そして将来の拡張性でした。

とくに「担当者が抜けても事業を続けられるか」という点は厳しく見られました。ロックインの対策は、守りのためだけではありません。将来、事業を売ったり、出資を受けたりするときの、会社の価値にも直結するのです。

運用中にやること：3つの所有物を定期的に確かめる

契約で取り決めても、運用しているうちに少しずつ崩れていきます。年に1回は、次の点を確かめてください。

データを実際に取り出してみる

「取り出せるはず」ではなく、実際に取り出してみることが重要です。

データを持ち出せる状態にする方法は、次のとおりです。

特定の会社に縛られないデータ形式を使う（CSV、JSON、XML、Parquet など）
利用者がデータを持ち、管理する権利を確保する
標準化された仕組みでデータをやり取りする

CSVとは、表のデータをカンマで区切った文字で保存する形式で、Excelなど多くのソフトで開けます。JSON・XML・Parquetも、特定の会社に縛られないデータの保存形式です。

経営者がやることは単純です。担当者に「顧客データをCSVで出してください」と頼み、実際にExcelで開けるかを確認してください。開けない、または出力に何週間もかかると言われたら、すでにロックインされている状態です。

バックアップは「戻せるか」まで試す

バックアップも試してください。私がこれまでに経験した中でいちばん大きな障害は、ディスクの故障でした。バックアップがきちんと使えるか検証していなかったため、復旧に丸一日以上かかりました。

それ以来、私は「バックアップがあるか」ではなく「そこから本当に元に戻せるか」を定期的に試しています。持ち出せるはずのデータが、いざというときに使えなければ、持っていないのと同じです。

管理者が誰になっているかを一覧にする

次の項目について、管理者が誰になっているかを一覧にしましょう。

項目	確かめること
ドメイン	登録者が自社になっているか。管理する会社（レジストラ）のログイン情報を自社が持っているか
クラウド	契約の名義と、いちばん強い権限のアカウントが自社か
ソースコードの保管場所	GitHub などで、自社のアカウントが管理者になっているか
SaaS	管理者のアカウントが、社員個人ではなく会社のものか

レジストラとは、ドメインの登録手続きを受け付ける会社のことです。GitHubは、ソースコードを保管・共有する代表的なサービスです。

開発会社の担当者や、辞めた社員の個人アカウントが管理者になっていたら、すぐに会社のアカウントへ移してください。それだけで、ロックインの危険は大きく下がります。

社内の「便利な自作ツール」にも気をつける

最近増えているのが、社員が自分のパソコンの中だけで動くAIツールを作り、それを業務に使うケースです。作った本人は助かっても、だれかに引き継ぐことは考えられていません。誰がどんな手順で何をさせているのかが周囲に分からず、作り手が休むとその業務が止まります。

これは、Excelが職場に入り始めた頃、詳しい社員が関数やマクロを駆使して自分だけの見積書を作り込み、本人が異動すると誰も直せなくなったのと同じ構図です。社内の個人に縛られる、ロックインの一種です。便利な工夫は、社内のみんなが使える仕組みにしてはじめて、会社の財産になります。

すでに抜け出せないときの脱却の順番

ここからは、すでに今の開発会社やサービスから離れられなくなっている場合です。脱却とは、頼りきりの状態から抜け出すことです。

いちばんやってはいけないのは、いきなり乗り換え先を探して、新しい会社に作り直しを頼むことです。今のシステムが何をしているか分からないまま作り直すと、同じ失敗を繰り返したり、必要な機能がなくなったりします。次の順番で進めてください。

手順1：今の状態を「見えるようにする」

まず、自社が何を持っていて、何を持っていないかを確認しましょう。前の章の「3つの所有物」と「管理者の一覧」を、そのまま使ってください。

私は以前、資料が一切なく、ソースコードの中にも説明書きがほとんどないシステムを引き継いだことがあります。コードを1行ずつ読み解くところから始めるしかありませんでした。この経験から、引き継ぎを受けるときは、まず「今どうなっているかを確認する」ための調査期間を必ず設けています。ここを省くと、あとの見積もりがすべて当てずっぽうになります。資料がない状態からの引き継ぎの進め方は、他社システムの引継ぎで失敗しない進め方｜資料がない状態からの手順で説明しています。

手順2：データを手元に確保する

次に、データを自社の手元に確保します。乗り換えるかどうかを決める前でも、これは先にやっておくべきです。データさえあれば、最悪の場合でも、新しいシステムを一から作って移せます。

クラウドを解約するときの費用を心配する方もいますが、大手のクラウドは解約するときの負担を軽くしています。

AWSは2024年3月、ほかのクラウドや自社サーバーへ移るときの、インターネットへのデータ転送料金を免除すると発表しました。
Google Cloudは2024年1月、Google Cloudの利用をやめて、ほかのクラウドや自社サーバー（オンプレミス）へデータを移すときの、ネットワークのデータ転送料金をなくすと発表しました。対象は世界中のすべての利用者です。

データ転送料金とは、クラウドからデータを他へ移すときにかかる料金のことです。自社サーバー（オンプレミス）とは、クラウドを借りずに自社で持つサーバーのことです。

ただし、Google Cloudは同じ発表の中で、データを運び出す料金がなくなっても、それだけでは自由に乗り換えられないとも述べています。ソフトを使うための契約（ライセンス）の条件が厳しく不公平なせいで、利用者がほかの会社に移れなくなる状況は残る、という指摘です。データを外部に移動することと、システムごと乗り換えられることは別の話です。料金がかからないからといって、それだけで抜け出せるわけではありません。

手順3：ソースコードと管理者の権限を移す

データを確保したら、ソースコードと管理者の権限を自社に移しましょう。

ソースコードがGitHubにある場合は、リポジトリ（ソースコードと変更の記録をまとめて保管する場所）を自社のアカウントへ移譲できます。移譲すると、課題の記録や変更の提案などのやり取り、これまでの変更の履歴もそのまま移ります。以前の場所へのリンクは、新しい場所へ自動で転送されます。

注意点は、移譲にはそのリポジトリの管理者の権限が必要なことです。開発会社のアカウントにしか権限がなければ、開発会社に作業してもらうしかありません。だからこそ、関係が悪くなる前に、契約で決めた内容に沿って依頼するのが得策です。

ドメインも同じです。ドメインが開発会社の名義やアカウントで登録されているなら、自社の名義とアカウントに移しましょう。

手順4：引き継ぎ先を選び、少しずつ移す

ここまで完了して、ようやく乗り換え先を探す段階になります。手順1でまとめた資料があれば、新しい会社に正確な見積もりを出してもらえます。見積もりが妥当かどうかの確かめ方は、システム開発の見積もりは妥当か、工数の内訳から確かめる方法で説明しています。

移すときは、一度にすべてを切り替えず、影響の小さい部分から順に移すのが安全です。また、新しい会社を選ぶときにも、発注前の章の質問をそのまま使ってください。新しい会社に乗り換えた結果、また別の会社にロックインされるのでは意味がありません。

経営判断は「コスト・リスク・時間」で比べる

今の開発会社やサービスから離れて別の会社に乗り換えるかどうかは、技術ではなく経営の判断です。コスト、リスク、時間の3つで比べてみましょう。

コスト：今の会社に払い続ける保守費用と、乗り換えにかかる費用の比較
リスク：今の会社が値上げしたり、担当者が辞めたりしたときに、事業が止まる危険
時間：乗り換えにかかる期間と、その間に止まる業務

この3つで比べると、「今すぐ乗り換える」「データと権限だけ先に確保して様子を見る」「今の会社と条件を交渉し直す」のどれが正しいかが見えてきます。手順2と手順3までは、乗り換えるかどうかに関係なく、今すぐやるべきことです。所有物が手元にあれば、今の会社との交渉でも強い立場に立てます。

よくある質問

Q: 今の開発会社に「ソースコードを渡してほしい」と言うと、関係が悪くなりませんか。

伝え方しだいです。「乗り換えるため」ではなく、「会社の資産として管理するため」「万が一に備えるため」と伝えれば、まともな会社は応じます。契約書にソースコードの納品が書かれているなら、そもそも受け取る権利があります。渡すことを嫌がる会社からは、早めにソースコードを受け取っておきましょう。

Q: SaaSを使うと、必ずロックインになりますか。

なりません。自社の強みと関係のない業務には、むしろSaaSを使うべきです。大事なのは、データをCSVなど、ほかのソフトでも開ける形式で取り出せるかを、SaaSを使い始める前と運用中に確かめることです。取り出せるデータがあれば、SaaSは乗り換えられます。

Q: クラウドから移るとき、データ転送料金がかからないなら、すぐに乗り換えられますか。

料金の面では負担が軽くなりましたが、それだけでは乗り換えられません。特定のクラウドの独自の機能に合わせて作ったシステムは、移す先で作り直しが必要になることがあります。Google Cloudも、ライセンスの条件による囲い込みは残ると指摘しています。まず今の状態を確認してから、作り直しの範囲を見積もるのが先です。