バイブコーディング時代、マルチクラウドDRの損益分岐点は下がった

マルチクラウドは複雑すぎるという通念は、アクティブ・アクティブ運用には今も当てはまります。しかし、別のクラウドにバックアップと復旧手段だけを保持するDR層では、コスト構造が変わりました。バイブコーディングはDRを最初に構築するコストを減らし、ソフトウェアファクトリーは構築したDRが機能し続けるよう維持・検証するコストを減らします。この二つのコストが、DRコストの大半を占めてきました。

---

TL;DR

• マルチクラウドは難しいという通念は、二つのクラウドでサービスを同時に運用するアクティブ・アクティブ構成には今も当てはまります。データ転送料金、常時の運用人員、利用量の分散による割引の希薄化は、AIでは減らないからです。
• 一方、別のクラウドにバックアップと復旧手段だけを置くDR層は、コストの大半が構築と検証の作業であるため、損益分岐点が下がりました。平常時の利用量はプライマリクラウドに集まっているので、割引も維持されます。
• バイブコーディングはDRを構築するコスト（セカンダリクラウド用のIaC、リストアスクリプト、ランブック）を減らし、ソフトウェアファクトリーは構築したDRをインフラの変更に合わせて更新し、定期的な復元訓練で検証する繰り返しのコストを減らします。
• サービスごとのRTO/RPO目標は人が決める成功基準であり、フェイルオーバーの決定権も人に残ります。
• 出発点は、サービスごとのRTO/RPO目標を決め、最も重要なサービス一つのバックアップを別のクラウドに置き、そのバックアップから実際に復元してみることです。

---

ゲームはすでに複数プラットフォームへ向かっている

ここ1〜2年、ゲーム業界では独占タイトルが他のプラットフォームで発売されることが珍しくなくなりました。MicrosoftはXbox独占だったForza Horizon 5を2025年4月にPS5で発売し、同作はその月の米国販売ランキングで2位に入りました。¹ 同じ年にはGears of War: Reloadedがシリーズで初めてPS5に登場し、Indiana Jones and the Great Circleは2026年5月にSwitch 2で発売されました。² 逆方向の動きもあります。SonyのHelldivers 2は2025年8月にXboxで発売され、分析会社Alineaの推計によれば、Xbox版の発売後6日間の販売本数（約92.6万本）は、2024年のPS5版の同期間の販売本数（約63.3万本）を上回りました。³

この流れの主な動機は収益の多角化です。開発費が上がり続ける中で、一つのプラットフォームのユーザーだけでは投資を回収しにくいためです。UnrealやUnityのような汎用エンジンが成熟し、プラットフォームごとの違いをかなりの部分吸収してくれることも、以前からある背景です。

私は、ここにバイブコーディング、つまりAIコーディングエージェントに実装を任せる開発手法が移植コストを下げているという要因が加わりつつあると考えています。ただし、これは解釈であって、確認された事実ではありません。2026年10月時点で、AIによってゲームの移植コストがどれだけ下がったかを示す定量的な資料は見つかりませんでした。GDC 2026の調査では回答者の36%が業務で生成AIを使っていると答え、その用途のうちコード補助が47%でしたが、同じ調査で生成AIが業界に有害だという回答も52%に増えています。⁴

定量的な根拠は、ゲームではなく一般的なソフトウェアのコードマイグレーション分野にあります。Amazonは約3万のアプリケーションをJava 17へアップグレードする際、AIツールによって4,500開発者年を削減したと発表しました。この数値はAmazon自身の推計です。⁵ GoogleはAdsシステムの32ビットIDを64ビットに変更するマイグレーションで、反映されたコード変更の80%をAIが作成し、エンジニアは全体の所要時間が約50%短縮されたと見積もりました。ただし、ほとんどのケースで人がモデルの変更の一部を差し戻す必要があったことも、著者らは併せて述べています。⁶ プラットフォーム移植は本質的に「同じ動作を、別の環境のAPIと制約に合わせて再実装する作業」なので、これらの研究はゲーム移植にも同じ方向の変化が起こりうるというシグナルとして読むことができます。レガシーコードをバイブコーディングで移行する具体的な方法は、レガシーモダナイゼーションのシリーズで取り上げました。⁷

クラウドでも同じことが起きるのか

ゲームで複数プラットフォーム対応を阻んでいたのが移植コストだったとすれば、クラウドで同じ役割を果たしてきたのはマルチクラウドの複雑さです。そして、単一のクラウドに依存するリスクは理論上の話ではありません。

ちょうど1年前、2025年10月19日夜から20日午後にかけて（米国太平洋時間）、AWSのus-east-1リージョンで大規模な障害が発生しました。AWSの事後レポートによれば、DynamoDBのDNS管理自動化に潜んでいた競合状態（race condition）によって、リージョンエンドポイントのDNSレコードが空になりました。この障害はEC2インスタンスの起動、Network Load Balancer、Lambda、STS、IAMコンソールへのサインインへと連鎖的に広がりました。⁸ 2025年6月12日には、Google CloudのService Controlにエラー処理と機能フラグなしでデプロイされたコードが、世界中に複製されたポリシーデータに遭遇してクラッシュループに陥り、障害は約7時間続きました。⁹

二つの事故には共通点があります。障害が一つのサービスや一つのアベイラビリティゾーンにとどまらず、認証、エンドポイント、ポリシーといったプロバイダー内部の共通の依存関係をたどって広がったという点です。同じクラウドの中でリージョンを分けても、こうした共通の依存関係までは分離されません。

一方、Flexeraの2026年の調査では、企業の88%がマルチクラウドを使っていると回答しました。¹⁰ しかし、この数値の大半は「業務ごとに異なるクラウドを使っている状態」を意味します。一つのクラウドが止まったときに別のクラウドでサービスを復旧できるよう設計された状態とは異なります。

マルチクラウドが難しかった理由をコスト項目ごとに分けてみる

「マルチクラウドは開発と運用の複雑さが大きく増す」という通念は、一つのコストではなく複数のコストをまとめた言葉です。AIの効果を正確に見極めるには、これらのコストを項目ごとに分ける必要があり、AIの効果も二つに分ける必要があります。

一つ目はバイブコーディングの効果です。バイブコーディングは、人がAIコーディングエージェントと対話しながら一つの作業を仕上げる手法です。この手法が減らすのは 一度だけかかる構築コスト です。二つ目はソフトウェアファクトリーの効果です。以前の記事で説明したように、ソフトウェアファクトリーとは、人が目標と制約、委任の範囲を決めると、複数の自動化された開発の流れが要件の整理から実装、検証、報告までを継続して実行する運用体制です。¹¹ この体制が減らすのは 繰り返しかかる維持・検証コスト です。二つの効果は時期も異なります。バイブコーディングは現場ですぐに使える手法であり、ソフトウェアファクトリーは組織がこれから構築を始められる方向性です。

下の表は、各コストを二つの効果に分けて判定したものです。この判定は私のコンサルティング経験に基づく解釈であり、測定した結果ではありません。

コスト項目	内容	バイブコーディング（構築）	ソフトウェアファクトリー（維持・検証）
インフラコードの二重作成	クラウドごとに異なるリソースモデルに合わせてIaCを別々に作成・維持する	最初に作成するコストが大きく減る	プライマリクラウドの変更に追従する更新コストが大きく減る
設計とレビュー	サービス対応表の作成、データ複製方式の設計、フェイルオーバー手順の設計	大きく減る	変更時に再レビューするコストが一部減る
ランブックとテストコード	復旧手順書、リストアスクリプト、検証テスト	初稿の作成コストが大きく減る	インフラ変更に合わせた更新コストが大きく減る
復元訓練	定期的にバックアップから復元し、実際のRTO/RPOを測定・報告する	訓練パイプラインを作るコストが減る	繰り返しの実行と結果報告のコストが大きく減る
抽象化レイヤーの維持	二つのクラウドの違いを隠す共通インターフェースの維持	一部減る	一部減る
データ転送コスト	クラウド間の複製で発生するegress料金	減らない	減らない
セキュリティ・IAMモデルの違い	権限モデル、鍵管理、監査ログの仕組みをクラウドごとに運用する	設定作成のコストが一部減る	設定の差異を検知するコストが一部減る。運用責任は残る
運用人員とオンコール	両方のクラウドを理解する人材の確保、障害対応体制	減らない	障害の検知と一次報告は一部減る。フェイルオーバーの決定権は人に残る
利用量割引の希薄化	利用量を二つのクラウドに分けると、コミットメント割引やボリューム割引の条件を満たしにくくなる	減らない	減らない

表のとおり、二つの効果は異なるコストを対象にしています。バイブコーディングはコードと文書を最初に作るコストを減らし、ソフトウェアファクトリーはそのコードと文書を正しい状態に保ち、実際に機能するかを確認するコストを減らします。どちらもデータ転送料金と割引の条件は減らせません。

最後の項目は特に取り上げておく必要があります。クラウドプロバイダーの割引は、利用量を一か所に集めるほど有利になるよう設計されています。AWSのSavings Plansやリザーブドインスタンス、Google Cloudの確約利用割引（Committed Use Discounts）のように、一定の利用量を確約して割引を受ける商品があり、大規模な顧客は年間の支出確約を条件にプロバイダーと個別の割引契約を結ぶこともあります。平常時に運用しているワークロードを二つのクラウドに分けると、それぞれのクラウドの利用量が減るため、こうした確約を結びにくくなったり、より低い割引段階にとどまったりします。このコストは、どれほど優れたコードを書いても減りません。

この区分から結論が導かれます。二つのクラウドでサービスを同時に運用するアクティブ・アクティブ構成は、残るコスト、つまりデータ転送、常時運用、割引の希薄化がコストの大半を占めるため、依然として難しいままです。一方、別のクラウドにバックアップと復旧手段だけを置くDR構成では、コストの大半が設計・実装の作業と繰り返しの検証作業でした。まさにバイブコーディングとソフトウェアファクトリーがそれぞれ減らすコストです。さらにDR構成では、平常時のコンピューティング利用量がプライマリクラウドに集まったままなので、プライマリクラウドの割引も維持されます。セカンダリクラウドで常時発生するコストは、主にバックアップのストレージと転送料金です。だからこそ、マルチクラウド全般ではなく、DR層で損益分岐点が先に下がったと考えるのです。

マルチクラウドDR戦略マトリクス

AWSはDR戦略をバックアップと復元、パイロットライト、ウォームスタンバイ、マルチサイト・アクティブ・アクティブの4段階に分け、RTO（サービス中断から復旧までに許容される最大の遅延）とRPO（最後の復旧時点から許容される最大のデータ損失時間）を下げるほど、リソースコストと運用の複雑さが増すと説明しています。¹² 原文はAWS内のマルチリージョン構成を扱っていますが、同じ枠組みを「プライマリクラウドとセカンダリクラウド」に当てはめることができます。下の表はそのように置き換えたものです。AWSの原文は段階ごとのRTO/RPOの数値を示していないため、表でも相対的な水準のみを記しました。

戦略	セカンダリクラウドに保持するもの	RTO / RPO	常時コスト	バイブコーディングが減らす構築作業
バックアップと復元	データのバックアップ（オブジェクトストレージの複製、DBのスナップショット・ダンプ）とセカンダリクラウド用のIaCコード	最も長い / バックアップ間隔分	最も低い（ストレージと転送料金）	セカンダリクラウド用IaCの作成、リストアスクリプト、復元検証テスト
パイロットライト	常時複製されるデータベースと最小限のネットワーク・中核インフラ。コンピューティングは停止しておく	長い / 短い	低い	クラウド間のDB複製の構成、コンピューティング起動の自動化
ウォームスタンバイ	縮小した容量で常時稼働するサービス全体	短い / 短い	高い	両クラウドのデプロイパイプラインの同期、容量拡張の自動化
マルチサイト・アクティブ・アクティブ	プライマリクラウドと同規模の運用環境	最も短い / ほぼゼロ	最も高い	一部しか減らない。データ整合性と常時運用のコストが残る

このマトリクスで私が最も注目しているのは1行目です。バックアップだけを別のクラウドに置く構成は、常時コストが低い一方で、同じクラウド内のマルチリージョン構成では防げないリスクを防ぎます。先に見たような、プロバイダー内部の共通の依存関係をたどって広がる障害がその一つです。アカウントが停止されたり乗っ取られたりして、同じアカウント内のバックアップまで削除される事故も同様です。こうした事故は、同じクラウドにどれだけバックアップを複製しても防げません。

かつてこの構成がためらわれた理由は、バックアップそのものではなく、その次の段階にありました。バックアップデータが別のクラウドにあっても、実際に復旧するにはセカンダリクラウドにネットワーク、コンピューティング、データベース、権限設定を新たに構築する必要があり、その手順をあらかじめコードとして用意しておかなければなりません。この準備作業こそ、バイブコーディングで大きく減る部分です。プライマリクラウドのIaCを基にセカンダリクラウド用のIaCを書くこと、サービスの対応関係を整理すること、リストアスクリプトを書くことは、いずれもコードマイグレーションと同じ性質の作業だからです。

戦略を選ぶ基準は、サービスごとのRTO/RPO目標です。すべてのサービスを同じレベルにする必要はありません。ほとんどのサービスはバックアップと復元から始め、売上や規制に直結する一部のサービスだけをパイロットライトやウォームスタンバイに引き上げるのが現実的です。バイブコーディングは、このレベルをサービスごとに変えて実装するコストも下げます。

本当のコストは構築の後にある：ソフトウェアファクトリーで常時検証する

DR計画で最もよくある失敗は、構築しなかったことではなく、実際に機能するかを確認しなかったことです。バックアップはあるのに一度も復元したことがない、あるいはランブックはあるもののその間にインフラが変わって手順が合わなくなっている、というケースを現場でよく目にします。マルチクラウドDRではこの問題がさらに大きくなります。プライマリクラウドの変更が、セカンダリクラウドの復旧コードに自動的に反映されないためです。

カオスエンジニアリングはこの問題への答えです。AWSはカオスエンジニアリングの原則として、実際の状況に基づく仮説の設定、影響範囲の限定、ロールバック手段の準備、CI/CDの中での継続的な障害注入を挙げ、想定外の挙動が見つかった場合には原因分析を行うよう勧めています。AWS Fault Injection Service（FIS）は、EC2、ECS、EKS、RDSなどのリソースに、インスタンスの終了、強制フェイルオーバー、遅延、パケットロスといった障害を注入するマネージドサービスです。¹³ その記事の言葉どおり、カオスエンジニアリングの目的は本番システムを壊すことではありません。

マルチクラウドDRに適用すると、検証の仕組みは二つに分かれます。第一に、プライマリクラウド側では、FISのようなツールで「プライマリ環境が使えない」という状況を作り、検知とフェイルオーバーの判断が期待どおりに行われるかを確認します。第二に、セカンダリクラウド側では、定期的にバックアップからサービスを実際に復元し、復元にかかった時間と、最後に復旧されたデータの時点を測定します。この測定値が実際のRTOとRPOです。FISはAWSのリソースを対象とするため、二つ目の部分は復元訓練のパイプラインとして別途構築する必要があります。

この仕組みを最初に作ることは、バイブコーディングで十分に可能です。実験シナリオ、復元パイプライン、結果を目標値と比較するチェックは、いずれも一度書けば済むコードです。しかし、この仕組みを有効な状態に保ち続けることは性質が異なります。プライマリクラウドのインフラは毎週のように変わり、そのたびにセカンダリクラウドの復旧コード、ランブック、訓練シナリオを合わせる必要があります。人がその都度エージェントに作業を指示するやり方では、忙しい時期に更新が後回しになり、DRは再び文書の中だけの計画に戻ってしまいます。

この繰り返しの作業こそ、ソフトウェアファクトリーが担う領域です。たとえば、次のような流れを常時運用できます。プライマリクラウドのIaC変更がマージされると、自動化された開発の流れがセカンダリクラウドの復旧コードに必要な変更を見つけて修正案を作ります。修正案は、定められた検証を通過して初めて反映されます。決められた周期ごとに復元訓練を実行し、測定したRTO/RPOを目標値と比較します。目標を外れたり想定外の挙動が見つかったりした場合は、原因と影響、残るリスクをまとめて人に報告します。

このとき、人が固定しておくべきものがあります。サービスごとのRTO/RPO目標は人が決める成功基準であり、ファクトリーがこの基準を自ら変えられるようにしてはいけません。成功基準まで変えられるなら、訓練に合格したという判断そのものが信頼できなくなるからです。以前の記事で、ソフトウェアファクトリーには優れた報告体制が必要だと書いたのも同じ理由です。

だから私は、マルチクラウドDRにおけるより大きな変化は、構築コストの削減よりも常時検証のコストの削減にあると考えています。構築コストはバイブコーディングですでに下がりました。検証コストまでソフトウェアファクトリーで下がれば、訓練の周期を四半期ごとから週ごとに縮めることができ、計画と実際の差を早く見つけられます。

限界：バイブコーディングとソフトウェアファクトリーが解決しないこと

この主張には明確な限界があります。

第一に、データ転送コストはそのまま残ります。2024年にGoogle、AWS、Azureが相次いでegress料金の免除を発表しましたが、この免除はそのクラウドから完全に離れる場合にのみ適用されます。たとえばAWSでは60日以内にすべてのデータを移す必要があり、Azureではサブスクリプションを解約する必要があります。¹⁴ したがって、常時運用するDR複製には転送料金が発生し続けます。バックアップの対象と頻度を決める際には、まずこのコストを計算する必要があります。

第二に、規制がマルチクラウドを求めているわけではありません。2025年1月から適用されているEUのDORAは、金融機関に重要なICTサービスの出口戦略と集中リスクの管理を求めていますが、マルチクラウドを義務付けてはいません。¹⁵ 規制は見直しのきっかけにはなりますが、構成の根拠は各組織のRTO/RPO目標であるべきです。

第三に、人の判断は減りません。サービスごとのRTO/RPO目標を決めること、障害時にセカンダリクラウドへ切り替えるかどうかを判断する権限と基準、訓練で見つかった差をどう扱うかは、依然として組織が決めなければなりません。バイブコーディングで作った復旧コードであれ、ソフトウェアファクトリーが更新した復旧コードであれ、人がレビューの基準を決め、訓練で検証しなければならない点は他のコードと同じです。

結論：DR層から損益を計算し直そう

この記事の結論は「マルチクラウドに移行しよう」ではありません。マルチクラウドは難しいという通念をひとかたまりのまま受け入れるのではなく、コスト項目ごとに分けて計算し直そうということです。そのように分けてみると、AIが減らすコストが最も大きな割合を占めるのがDR層です。バイブコーディングはDRを構築するコストを下げ、ソフトウェアファクトリーは構築したDRを機能させ続けるコストを下げます。特にバックアップだけを別のクラウドに置く構成は、平常時の利用量をプライマリクラウドに集めて割引を維持しながら、単一のプロバイダーに縛られるリスクを防ぎます。

ゲーム業界が移植コストの低下に合わせてより多くのプラットフォームへ進んでいるように、クラウドアーキテクチャも検証コストの低下に合わせて、より広い範囲の障害に備えられるようになりました。出発点はシンプルです。サービスごとのRTO/RPO目標を決め、最も重要なサービス一つのバックアップを別のクラウドに置き、そのバックアップから実際に復元してみることです。最初の復元訓練で測った時間が計画とどれだけ違うかが、次の投資を決める根拠になります。

---