誰がロックインと言ったのか！ - バイブコーディング時代のインフラ依存を考える

「誰がロックインと言ったのか！」

2026年になってもオンプレミスを好む人は大勢います。機械を自分で扱い、すべての層を管理することに魅力を感じるのは分かります。遅延、既存設備との接続、規制上の要件から自社環境が必要な場合もあります。ただ、「クラウドはロックインされるから使えない」という言葉には納得できません。クラウド間、あるいはオンプレミスへの移行費用は、バイブコーディングの登場によって大きく下がりました。一方、施設、機器、専門の運用担当者に縛られる費用は残っています。 本当の依存はどちらでしょうか。

TL;DR

• バイブコーディングによってクラウド移行の労務費はすでに大きく下がりました。モデルとエージェントの進化によって、今後さらに下がると考えています。
• オンプレミスには、データセンター用の不動産、施設、機器、運用担当者への、さらに重い依存があります。
• クラウド上のKubernetesなら自社データセンターは不要ですが、専門の運用担当者は必要です。その人材の雇用も依存になります。
• GPUを使う高性能計算とLLMサービスが急速に変わる中、クラウドなら機器を購入せずに新しい技術を試せるため、先端技術への参入障壁が下がります。
• 筆者は、バイブコーディングが開発のニューノーマルになると、実装とテストの難しさから避けられてきたサーバーレスなどのクラウドネイティブな構成が、より多く選ばれると考えています。
• ROBOCOは文書とテストを整え、小さなサービスから移行し、そのテストと文書に照らして成功を確認した後、実証した手順をエージェントのルールやスキルにする方法を提案します。

1. ロックインを定義し直す

ベンダーロックインとは通常、あるクラウド事業者のマネージドサービスやAPIに深く依存し、別の事業者へ移るにはアプリケーションやデータの変更が必要な状態を指します。NISTも、移植性をアプリケーションとデータを別の環境へ受け入れ可能な費用で移せる能力として説明しています。¹

鍵になるのは「費用」です。特定のサービスを使っているかどうかだけでは、依存を判断できません。選択を変えるときに何を、どれだけやり直す必要があるかが重要です。クラウドAPIの変更だけでなく、サーバーの減価償却、機器の交換、ネットワーク契約、運用手順、人員も同じ帳簿に載せるべきです。

2. 移行費用はすでに下がり、さらに下がる

以前は、クラウドを使い始めるだけでも高くつきました。新しいサービスを学び、インフラ設定を書き直し、SDKの呼び出しを変え、テストとデプロイの手順を組み直す必要がありました。一つのクラウドに最適化するほど、後で離れる費用が増えるという懸念には理由がありました。

今はAIエージェントがサービスとの接続箇所を見つけ、インフラコードを別の環境に合わせ、アプリケーションの呼び出しとテストを一緒に修正できます。AWSも、エージェントを使ってインフラ、アプリケーション、コードの変換を支援するツールを文書化しています。² 以前は人が何日もかけてファイルを探し直していた作業を、エージェントとともにはるかに速く終えられます。移行の労務費はすでに大きく下がりました。

変化はここで終わりません。モデルが長いコードベースやサービス間の関係をよりよく理解し、エージェントが変更からテスト、復旧まで安定して進められるようになれば、移行に必要な人の時間は今後も減るでしょう。筆者は、バイブコーディングが定着した組織では移行作業の費用が従来とは比べにくいほど小さくなると考えています。削減幅はシステムごとに異なりますが、方向は明らかです。今の製品をより簡単に、速く作れるクラウドネイティブな機能があるなら、将来の移行を漠然と恐れて利用を避ける理由は弱くなっています。

3. それでも残る移行費用

エージェントがコードを変えても、データは実際に移さなければなりません。データベースのスキーマや機能が別のエンジンでそのまま動くとは限りません。AWSのスキーマ変換ツールも、自動変換できない項目を明示します。³ 停止時間を決め、並行運用とロールバックを準備し、セキュリティ、権限、規制上の要件を再確認する必要があります。Google Cloudの移行指針でも、検証と費用の見積もりは別の作業です。⁴

ここにもバイブコーディングが役立ちます。スキーマ変換案、データ比較スクリプト、検証シナリオ、切り替えと復旧の手順をエージェントとともに作れます。データ移動、検証、切り替えに投入する人の作業も、以前とは比べにくいほど少なくなり、今後さらに減るでしょう。 それでも実際の転送時間と料金、停止のリスク、最終結果を確認する責任は残ります。小さなサービスと、大規模な取引データベースの無停止移行は別の問題なので、総費用を一律には語れません。しかし、残る作業があるからといって、すでに起きた費用削減を無視すべきではありません。

4. サーバーを所有すれば依存はなくなるか

オンプレミスを選べば、クラウド事業者との契約への依存は減るかもしれません。その代わり、建物、電力と冷却設備、サーバーとネットワーク機器、交換周期、保守契約に縛られます。本番環境のKubernetesクラスタを自社で運用するなら、高可用性、証明書、ノード、セキュリティ、障害対応、アップグレードを継続して担う専門の運用担当者を必ず確保しなければなりません。 Kubernetesの公式ドキュメントも、こうした運用責任を項目ごとに説明しています。⁵

直接雇用すれば、採用、オンコール対応、教育、引き継ぎ、退職による空白まで引き受けます。重要な運用知識が少数の人に集中するほど、その人たちへの依存も強まります。外部委託やマネージドKubernetesは責任の範囲を変えられますが、運用の専門知識そのものが不要になるわけではありません。移植可能なコンテナが組織を自動的に自由にするわけではありません。専門人材を確保し続けるという雇用への依存も計算に入れるべきです。

機器を所有することの機会費用も大きくなっています。GPUを使う高性能計算とLLM提供サービスは急速に変化しています。サーバーを購入すると、その世代と交換周期に縛られます。一方、クラウドではさまざまなGPUインスタンスや新しく提供されるモデルをサービスカタログから選び、試すことができます。⁶⁷⁸ 小さなチームでも、多額の先行設備投資なしに先端技術を利用する機会を得られます。利用可能な地域、クォータ、利用料金は確認が必要ですが、新しい技術への参入障壁を下げることもクラウドの利点です。

5. カーシェアリングと自動車の所有

カーシェアリングのサービスを乗り換えるのにも不便はあります。料金や利用できる地域を確認し直さなければなりません。それでも、すでに車を購入した場合とは選択の重さが違います。購入した瞬間から減価償却が始まります。もっと良い車が登場したり、今の車が目的に合わなくなったりしても、すぐに替えるのは難しいものです。利用規模によっては駐車場、整備、運転手も必要になります。

クラウドと自社データセンターにも似た面があります。「借りるか、所有するか」という掛け声より、進路を変える総費用が重要です。ソフトウェアを作り直す費用は、モデルとエージェントの進化でさらに下がる可能性があります。一方、すでに所有する機器と築いた運用チームを一度に変えるのは容易ではありません。

6. 推測せず、脱出費用を測る

クラウドのロックインが心配なら、すべてのクラウドネイティブ機能を避ける代わりに、小さな移行実験をしてみましょう。重要なサービスを一つ選び、エージェントとともに別のクラウドや自社環境で動かしてみます。コードとインフラ設定の変更、データ移動と検証にかかった時間、追加費用、残った手作業を分けて記録します。元の環境へ戻す手順も試します。

そうすれば「ロックインされそうだ」という感覚が、作業一覧と実際の費用に変わります。規制や契約によってクラウド利用が難しい組織は、その条件を先に守るべきです。しかしバイブコーディングを導入したチームなら、将来離れられないかもしれないという未検証の不安だけで、今役立つクラウド機能を諦める必要はありません。

7. ROBOCOが提案するバイブコーディングを使った移行プロセス

移行全体を一度にエージェントへ任せる前に、現状を共有し、結果を検証する基準を整える必要があります。ROBOCOは次の順序を提案します。

1. 現行システムを分析し、文書を更新します。 ソースコードと既存の文書を合わせて読み、サービス間の依存関係、データの流れ、デプロイ方法、運用手順を確認します。コードと食い違う説明を直し、人とエージェントが同じ現状を見られるようにします。
2. テストを整備または追加します。 UIテスト、結合テスト（IT）、エンドツーエンドテスト（E2E）で現在の動作を記録します。不足するテストを補い、移行後も利用者の操作とサービス間連携が動くかを確認する基準を作ります。
3. エージェントと計画を立て、小さなサービスから移します。 各サービスの重要度、規模、依存関係、ロールバック方法を計画に含めます。複数のサービスがあるなら、比較的小さく重要度の低いものから始め、より大きく重要なサービスへ広げる順序を決めます。
4. テストと文書に基づいて成功を確認します。 移行前に整備したUI・結合・E2Eテストを新しい環境で実行します。最新の文書に記録したデータの流れ、サービス間連携、デプロイと運用方法を実際の動作と照らし合わせ、差があれば直します。テストの通過と文書に示した期待動作との一致を、次のサービスに進む基準とします。
5. 成功した手順をルールとスキルにします。 最初のサービスがこの基準を満たし、移行後も安定して動き始めたら、計画、コード変更、テスト、デプロイ、検証のうち繰り返せる手順を記録します。エージェントのルールやスキルとして次のサービスに機械的に適用し、例外と最終承認は担当者が確認します。

最初の成功を一度きりの経験で終わらせず、再利用できる手順にすることが重要です。同じ移行作業を毎回学び直す必要がなくなれば、後続のサービスはより速く移せます。

結論

バイブコーディングが下げる費用は、最初の実装だけではありません。文書とテストを更新し、小さなサービスを実際に移して検証した後、成功した手順をルールやスキルとして繰り返せば、移行できる力を経験として確かめられます。データの移動と規制上の確認は残りますが、モデルとエージェントが進化するほど、移行の実装と検証にかかる時間はさらに減るでしょう。

これからはクラウドのAPIだけでなく、機器への投資とKubernetesの運用担当者も含めて依存を計算する必要があります。急速に変わるGPUやLLMサービスを機器の購入なしに試せる利点も、同じ計算に入れるべきです。現在の製品に最も適したアーキテクチャを選び、必要なときに移せるかを継続して確かめるのが合理的です。筆者は、バイブコーディングが開発のニューノーマルになるにつれ、実装とテストの難しさから採用をためらっていたサーバーレスなどのクラウドネイティブなアーキテクチャが、より多く選ばれると考えています。