技術選定を任されるのは、クライアントからの信頼が形になった瞬間です。ただし、選んだ構成が数年後に他の製品へ移れないものだったなら、その判断への評価は長くは続きません。ベンダーロックインは契約の途中で起こるのではなく、選定の段階でほぼ決まります。デジタル庁の実践ガイドブックが示す考え方をもとに、あとの自由度を残す選定の視点を整理します。

1. ベンダーロックインは、選定の段階で決まります

1社の提案を鵜呑みにすると競争を阻害します

提案書が1枚しか出てこない場面は、選定というより追認になりがちです。比較する相手がいないまま話を進めると、条件の妥当性を確かめる機会そのものを失います。1社の提案内容を鵜呑みにすると、他の事業者では実現できず、競争を阻害する可能性があると指摘されています³。

見積もりの安さや導入の早さだけで決めた構成が、あとから一番身動きの取れない選択だったと分かる場面は珍しくありません。提案を評価するときの姿勢が、そのまま数年後の自由度に変わります。

1社の提案を検討の出発点にはしても、そこで確定させない姿勢が、選定を任される立場の最初の一歩になります。

1社の話だけを聞いている段階では、条件がほかの選択肢と比べてどの程度の水準にあるかも判断できません。比較の土台を作ってから提案を評価する順番を守ることが、選定を任される立場の基本になります。急ぎの案件ほどこの順番が省略されやすく、あとから振り返って選択肢を狭めてしまったと気づく場面につながります。

選定時の判断があとの自由度を決めます

選定の場では、目の前の課題を早く解決する提案に目が向きがちです。速さよりも、あとで変更できる余地を残す提案のほうが、長期的には評価されます。

この余地は、契約後に交渉で取り戻すのが難しいものです。選定の入り口で確かめておく判断が、その後の交渉力そのものになります。

提案を評価する立場では、機能一覧の充実度に目を奪われがちです。しかし数年後に困るのは機能の過不足ではなく、離れられない構成にしてしまったことのほうです。選定の場では、いま欲しい機能と、あとで失いたくない自由度の両方を並べて見る視点が求められます。

出典：デジタル庁『デジタル・ガバメント推進標準ガイドライン実践ガイドブック』（2025年6月19日）をもとに作成

表1：ロックインが起きやすい場面

提案の出方や構成の作り方によって、ロックインが起きやすい場面には共通した特徴があります。比較対象がない、独自の設定に寄せている、乗り換えの手順が示されていない、契約更新のタイミングだけで判断してしまう——といった場面は、あとになって選択肢が狭まっていたと気づく典型例です。選定に関わる立場では、こうした場面をあらかじめ把握しておくことが、判断を誤らないための備えになります。案件によって現れ方は異なりますが、どの場面も選定の初期段階でしか手を打てない点は共通しています。

場面	起きやすい理由	選定時の見分け方
提案が1社のみで出てくる場面	比較対象がなく条件を検証できない	他の選択肢も並行して確認します
独自の設定・独自形式に寄せた構成	標準的な仕様から離れるほど乗り換えの難度が上がる	標準的な仕様に沿っているかを確かめます
移行手順が案内されていない提案	乗り換えの想定がない構成は固定化しやすい	乗り換え手順の有無を質問します
契約更新のタイミングだけで判断する場面	総額でなく目先の条件だけで決めてしまう	更新時期以外にも評価する機会を設けます

この表を選定の場で使うときは、1項目ずつ提案書と照らし合わせる進め方が有効です。すべてを一度に確認しようとすると見落としが増えるため、場面ごとに区切って確かめる方が実務では扱いやすくなります。

では、あとで縛られない選定をするには、まず技術仕様の選び方を確かめておく必要があります。

2. オープンな技術仕様を選ぶ

特定ベンダーの技術・製品に依存させない

どれだけ機能が充実していても、その基盤が1社の技術だけで組まれていれば、離れたいと思ったときの選択肢は限られます。情報システムを構成する要素を特定のベンダーの技術や製品に依存させず、オープンな技術仕様に基づくものとすることが選定の判断軸として挙げられています¹。

個々の機能の良し悪しよりも、仕様が公開され広く使われているかどうかのほうが、あとの自由度を左右します。機能の充実さよりも、標準に沿っているかどうかのほうが、選定の判断としては重みがあります。

確かめる方法は難しいものではありません。仕様書が公開されているか、複数の事業者が同じ仕様に対応しているか、乗り換えた事例が外部に共有されているか——この3点を提案の場で質問すれば、依存の度合いはおおよそ見えてきます。

質問しても明確な答えが返ってこない場合は、それ自体が1つの兆候です。仕様の位置づけを説明できない提案は、あとで乗り換えようとしたときに同じ説明のつかなさが障害になります。

標準に沿うと選択肢が残ります

標準的な仕様に沿った構成であれば、対応できる事業者やエンジニアの層が広がり、次の提案を受けやすくなります。特定の製品でしか扱えない設定に寄せるほど、対応できる相手は絞られていきます。

対応できる相手が広いということは、次の提案を受けるときの交渉力にも直結します。1社にしか頼れない構成では、その1社の都合に合わせるほかなくなり、条件面での交渉の余地はほとんど残りません。

選定を任されたときは、機能の比較と同じ重さで、その仕様がどれだけ公開され標準化されているかを確かめる姿勢が問われます。

出典：デジタル庁『デジタル・ガバメント推進標準ガイドライン実践ガイドブック』（2025年6月19日）をもとに作成

図に示したとおり、依存した構成では層ごとの色がひとつのベンダーで揃い、オープンな構成では層ごとに異なる仕様を選べます。この違いは提案書の見た目では分かりにくく、仕様書まで確認して初めて分かるものです。

仕様の選び方が定まったら、次に確かめておきたいのが、実際に乗り換えられる構成になっているかという点です。

3. 乗り換えできる構成にしておく

将来的に他の製品やサービスへ乗り換え可能な構成にします

仕様がオープンであっても、構成そのものが1つの製品に密着して組まれていれば、乗り換えは容易ではありません。将来的に他の製品やサービスへの乗り換えが可能な構成とすることが、選定時の観点として挙げられています²。

重要なのは、乗り換えを前提に置くかどうかを選定の入り口で決めておくことです。稼働が始まってから設計をやり直すのは、費用も時間もかかります。

乗り換えを前提にした構成は、最初の設計に少しだけ手間を足すことになります。それでも、その手間を惜しんだ結果として選択肢を失う場面と比べれば、割に合う投資です。選定の場でこの手間を提案できるかどうかも、任される判断の一つになります。

変更可能な部分を最初に特定しておきます

すべての部分を一律に乗り換え可能にする必要はありません。基盤やデータ連携など、影響範囲が広い部分だけでも、あらかじめ入れ替えの余地を残しておけば、あとの交渉力は変わります。

全体を作り直す前提よりも、一部分だけを入れ替えられる前提のほうが、現実的な備えになります。

変更可能な部分を特定するには、データの受け渡し方と設定の持ち方を見るのが近道です。データ形式が公開された標準に沿っていれば移し替えやすく、独自形式でしか出力できない場合は乗り換えの難度が上がります。設定情報が特定の管理画面に閉じていないかも、あわせて確認しておきたい点です。

出典：デジタル庁『デジタル・ガバメント推進標準ガイドライン実践ガイドブック』（2025年6月19日）をもとに作成

表2：選定で確かめる観点

技術選定の場では、依存・乗り換え・コストという3つの観点を、順番に確かめておくと判断がぶれにくくなります。依存は特定の技術に縛られていないか、乗り換えは将来ほかの製品へ移れる構成かどうか、コストは初期費用だけでなく総額で比較できているかを指します。提案を受け取った段階で、この3つを1つずつ照らし合わせる姿勢が、選定を任される立場には欠かせません。

観点	確認すること
依存	特定の技術・製品がなくても代替できる仕様かどうか
乗り換え	将来的に他の製品やサービスへ乗り換えられる構成かどうか
コスト	初期費用だけでなくライフサイクルコスト全体で比較しているか

図の標準インターフェースのように、入れ替えたい部分の前後を仕様で区切っておくと、後工程への影響を抑えたまま乗り換えを進められます。この区切り方を選定の段階で決めておくかどうかが、数年後の負担の大きさを分けます。

構成の乗り換えやすさが確認できたら、次はコストの見方です。初期費用の安さだけで選んでいないか、総額で確かめていきます。

4. コストは総額で見る：ライフサイクルと為替

初期コストが高くてもライフサイクルコストで低く抑えられる場合があります

導入時の見積もりが安い提案は魅力的に映ります。ただし、移行や乗り換えを適切に行えば、初期コストは高くてもライフサイクルコスト全体で見ると低く抑えられる場合があります⁴。

目先の安さよりも、運用や乗り換えまで含めた総額のほうが、数年単位で見たときの実際の負担に近づきます。

提案を比較するときは、導入費だけでなく、運用・保守にかかる費用と、将来乗り換えるときにかかる費用を、それぞれ別の行として並べて確かめる進め方が有効です。1つの合計額にまとめられてしまうと、どこにコストがかかっているのかが見えづらくなります。

クラウドはドルベース料金で為替リスクがあります

クラウドサービスの中にはドルベースで料金を設定するものがあり、円安に振れると利用料が想定以上に高額になるリスクがあります⁵。為替という、技術とは別の変数が費用に影響することを、選定の段階で織り込んでおく必要があります。特定の通貨に依存しない構成にしておくか、変動を見込んだ予算の幅を確保しておくかは、案件ごとに検討する余地があります。

総額での比較に、為替のような外部要因まで含めておくと、あとになって費用が想定を超える事態を避けやすくなります。

出典：デジタル庁『デジタル・ガバメント推進標準ガイドライン実践ガイドブック』（2025年6月19日）をもとに作成

表3：参画時の技術選定チェック

技術選定を任されて案件に参画するときは、提案の数・仕様の位置づけ・乗り換えの想定・コストの見方という項目を、契約前に確かめておくと安心です。いずれも、あとから交渉で取り戻すのが難しい項目です。クライアントとの協議の場で、これらを1つずつ言葉にして共有しておくと、選定の判断そのものが実績として積み上がっていきます。チェックの結果を議事録に残しておけば、あとで振り返るときの根拠にもなります。参画のたびに同じ項目を確かめる習慣をつけておくと、案件ごとの違いにも気づきやすくなります。

チェック項目	確認内容
提案の数	1社の提案だけで進んでいないか
仕様の位置づけ	オープンな技術仕様に基づいているか
乗り換えの想定	将来の乗り換え手順が示されているか
コストの見方	ライフサイクルコストと為替まで含めて比較しているか

依存を避け、総額で選べる判断は、選定の場に立ち会うたびに積み上がっていく実績です。この判断ができることは、次にどんな案件で任されるかにもつながります。

5. 縛られない選定ができる人が、案件で任されます

依存を避け総額で選べる人は任されやすくなります

1社の提案を鵜呑みにせず、標準的な仕様と乗り換えの余地、総額でのコストまで確かめる判断は、資料や議事録に残る実績になります。この判断を示せるかどうかで、次に任される選定の範囲は変わっていきます。

選定の判断は、コードの実装力とは別の評価軸です。設計や実装の力を積み上げてきたエンジニアであっても、依存を避け総額で選ぶ視点はあらためて意識しないと身につきません。実装力に加えてこの視点を持つことが、任される案件の幅を広げます。

1つの案件で示した選定の判断は、次の案件の初回の打ち合わせでもそのまま生きてきます。クライアントが変わっても、確かめる観点そのものは共通しているためです。

リモート中心でも選定の判断は示せます

技術選定に関わる判断は、対面の場に限らず、資料と議事録、オンラインでの協議でも十分に示せます。Remogu（株式会社LASSIC運営）が扱う案件の90%以上がフルリモート可能です⁶。場所に縛られず、選定という上流の判断そのものに関わり続けられる環境です。

まずは、自分がこれまで下してきた選定の判断が、どんな案件で評価されるのかを確かめてみることから始められます。登録すれば、経験に合う条件を具体的に見比べられます。

6. まとめ

ベンダーロックインは、契約の途中で急に起きるものではなく、選定の段階に判断の種があります。ここまでの内容を整理します。

• ベンダーロックインは契約後でなく、選定の段階でほぼ決まります
• 特定ベンダーに依存させないオープンな技術仕様を選ぶことが、判断の軸になります
• 将来的に乗り換え可能な構成にしておくと、あとの交渉力が残ります
• コストは初期費用でなく、ライフサイクルコストと為替まで含めた総額で見ます
• こうした判断を示せる人は、案件で任される範囲が広がります

1社の提案を鵜呑みにせず、仕様と乗り換えの余地、総額まで確かめる——この一連の判断は、案件を重ねるほど積み上がる実績です。どれも一度に完璧を目指す必要はなく、次の提案から1つずつ確かめていくだけで十分な変化になります。まずは、自分の経験に合う条件を確かめるところから始めてみましょう。

7. よくある質問

ベンダーロックインを完全に避けることはできますか

完全に避けられるとは言い切れません。ただし、1社の提案を鵜呑みにせず、オープンな技術仕様と乗り換え可能な構成、総額でのコストという3つの観点を選定の段階で確かめておけば、あとで身動きが取れなくなるリスクは抑えられます。トレードオフがあることを踏まえたうえで選ぶ姿勢が欠かせません。標準に沿うことで多少の機能面での妥協が生じる場合もあり、そこは案件ごとの優先順位に応じて判断する部分になります。

技術選定では最初に何を確認すればよいですか

まず、提案が1社だけで進んでいないかを確かめます。次に、その仕様が特定の製品に閉じていないか、将来的に乗り換えられる構成になっているかを見ます。この2点は契約前にしか確認できないため、選定の初期段階で押さえておく項目です。稼働が始まってからでは、条件を変える交渉の余地はほとんど残っていません。

クラウドはどのように選べばよいですか

特定のクラウドを比較・推奨する形ではなく、一般的な考え方として、料金体系がドルベースかどうか、円安が進んだ場合に費用がどう変わるかを確かめておくことが挙げられます⁵。初期費用だけでなく、運用まで含めた総額で比較する視点が欠かせません。個々のサービスの優劣を比べるより、この視点を持って提案を読み解くほうが、選定を任される立場としては実践的です。

リモート中心でも技術選定に関わる案件はありますか

選定や設計に関わる判断は、資料や議事録をもとにした協議で十分に進められるため、リモート中心の案件でも任される場面があります。場所を理由に上流の判断から遠ざかる必要はなく、経験を積み上げてきた領域で評価される道が開けています。対面での立ち会いが前提だった時期と比べても、判断を共有する手段そのものが広がってきています。気になる場合は、自分の経験に近い案件の傾向を実際に確かめながら判断できます。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」（2025年6月19日）
＊2 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」（2025年6月19日）
＊3 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」（2025年6月19日）
＊4 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」（2025年6月19日）
＊5 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」（2025年6月19日）
＊6 Remogu（株式会社LASSIC運営）公開情報：扱う案件の90%以上がフルリモート可能