生成AIを組み込んだWebサービスを、自社サーバーからクラウドへ移行する計画があるなら、データベース選定で立ち止まることになります。特に「外部から取得したデータを正規化して保存し、ユーザーの好みに応じて動的にフィルタする」ような仕組みを持つサービスでは、DB選びが運用コストと障害耐性を大きく左右します。
東南アジア向けの住宅検索エージェント「Roamstead」の開発事例では、実在する不動産情報240件（ホーチミン市200件、バンコク20件、クアラルンプール20件）を取り込み、通貨と言語を正規化してデータベースに保存する構成が採用されています。生成AIの応答のたびにモデルを呼び出すのではなく、保存済みのカタログを検索する設計です。これはコスト面でも障害対応面でも理にかなった判断で、同様の構成を検討する際の判断材料になります。
なぜ「モデル呼び出し都度実行」を避けたのか
この事例で注目したいのは、ページ表示のたびにAIモデル（Gemini）を再実行せず、事前に正規化して保存したデータを検索する方式を選んでいる点です。
AIモデルのAPI呼び出しは、レイテンシ（応答までの遅延時間）とコストの両方が読み込みDBのクエリより桁違いに大きくなります。仮に検索リクエストのたびにモデルを呼び出す設計にすると、アクセス数の増加がそのままAPI課金額に直結し、モデル側の障害やレート制限（呼び出し回数の上限）がサービス全体の可用性を左右してしまいます。
これはクラウド移行を検討するエンジニアにとって重要な教訓です。「AIが動的に応答を作る部分」と「データを保存・検索する部分」を分離しておけば、後者は従来のクラウドDB運用のノウハウがそのまま活きます。障害の切り分けもしやすくなります。
判断軸1：データ更新頻度とリアルタイム性
不動産情報のように、更新頻度が「1日数回〜数週間に1回」程度のデータであれば、バッチ処理でデータを取り込み、正規化してからDBに書き込む「ETL的な取り込みパイプライン」との相性が良くなります。
一方、在庫状況や価格が秒単位で変わるようなデータを扱う場合は、書き込みの整合性やレイテンシ要件がまったく変わってきます。自分のサービスがどちらに近いかを最初に整理してください。
判断軸2：スキーマの柔軟性が必要か
Roamstead の事例では、価格表記の通貨、物件種別の分類、写真の種類（実際の部屋の写真か、書類や地図の誤登録か）といった「データの型が揃っていない」状態からスタートしています。
こうした半構造化データを扱う場合、スキーマ（データの構造定義）を厳密に固定するRDBMS（リレーショナルデータベース）よりも、ドキュメント指向のNoSQL（柔軟なスキーマを持つデータベース）の方が初期の取り込みは楽になります。ただし後々の集計・分析クエリが複雑になりやすい点はトレードオフです。
判断軸3：運用チームの規模とマネージドサービス依存度
SRE（サイト信頼性エンジニアリング）担当者が専任でいないチームであれば、インフラの面倒を見る範囲を減らすことが障害対応の負荷軽減に直結します。
Google Cloud には Firestore（サーバーレスのドキュメントDB）のようなフルマネージドサービスがあり、レプリケーションやバックアップ、スケーリングをクラウド側に任せられます。自前でPostgreSQLやMongoDBをVM上に構築・運用する場合と比べ、深夜のディスク容量アラートや複製遅延といった障害対応の頻度は明確に下がります。
判断軸4：データの信頼性検証をどこで行うか
見落とされがちですが、外部ソースから取り込んだデータを「検証してから書き込む」工程をどこに置くかも設計上の判断ポイントです。
Roamstead の取り込みワークフローでは、ソースページと画像を検証したうえで、承認されたレコードだけをデータベースに書き込む設計になっています。これは単なるデータ品質の話ではなく、「不正確なデータによる障害」を未然に防ぐ運用設計でもあります。書き込み前のバリデーション層を薄くしすぎると、後工程のAIエージェントが誤った前提で応答を返し、ユーザー体験の障害につながります。
選択肢の比較
| 選択肢 | 運用負荷 | スキーマ柔軟性 | 向いているケース |
|---|---|---|---|
| フルマネージドNoSQL（Firestore等） | 低い | 高い | 半構造化データ・少人数運用 |
| 自前運用のRDBMS（PostgreSQL等） | 高い | 低い（要マイグレーション） | 集計分析が多い・既存資産がある |
| マネージドRDBMS（Cloud SQL等） | 中程度 | 低い | トランザクション整合性重視 |
ケース別の推奨
外部APIやスクレイピングで取得した非定型データを扱い、運用担当者が少ないなら、フルマネージドNoSQLを選ぶのが妥当です。バックアップやスケーリングの設計コストを削減できます。
既存の基幹システムと連携し、在庫や決済のようなトランザクション整合性が必須な要件があるなら、マネージドRDBMSを選ぶべきです。Cloud SQLやAmazon RDSのような選択肢が該当します。
分析基盤としてBIツールから直接クエリを投げる用途が多いなら、自前運用のRDBMSかBigQueryのような分析特化型サービスとの併用を検討してください。
あえて移行を見送るべき条件
すでにオンプレミスのDBが安定稼働しており、障害発生率が低く運用コストも許容範囲であれば、無理にクラウド移行する必要はありません。
移行によって得られるメリット（スケーラビリティ、マネージド運用）よりも、移行作業自体のリスク（データ移行時の不整合、ダウンタイム）の方が大きいと判断できる場合は、移行時期を再検討してください。
また、AIエージェントの機能追加が本体DBの移行よりも優先度が高い場合、DB移行を先に進めると開発リソースが分散します。まずは小規模なPoC（概念実証）環境で新しいDB構成を試し、既存システムと並行稼働させる段階を踏むことをおすすめします。
まとめ
クラウド移行時のDB選定は、データの更新頻度・スキーマの柔軟性・運用チームの規模・検証工程の設計という4つの軸で整理すると判断しやすくなります。
まず自社のデータ特性を棚卸しし、Google CloudのFirestoreやCloud SQLのドキュメントで料金体系とマネージド範囲を確認してみてください。
小規模なPoCでレイテンシとコストを実測し、既存システムとの並行稼働期間を設けることが、障害を出さない移行の近道です。