バイブコーディング時代に中小企業がSaaSを作る際のDBの最適解 — Cloudflare D1×シングルテナントがDBのコスト壁を破壊する

AIによって「機能を作る」コストはほぼゼロに近づきました。少人数チームでも大手と同じ機能を、同じスピードで出せるようになっています。それでも、サービスを公開した瞬間に立ちはだかるのが「インフラの固定費」 — 特にAWS RDSに代表される占有型データベースの維持コストです。

この壁を、Cloudflare D1 と「1顧客1DB」のシングルテナント戦略で正面から壊す。それが今、中小企業が大規模SaaSを運営するための最短ルートだと考えています。

「1DBに全員入れる」時代は終わった

これまで大規模SaaSがマルチテナント（1つの巨大RDBに全顧客を相乗り）を選んできた理由は、ほぼ一つだけです。RDS や Aurora の固定費が高すぎて、相乗りでしか採算が合わなかった。

ただし相乗りには代償が常につきまといます。

• セキュリティ事故の温床: WHERE tenant_id = ? の書き忘れ一発で、他社のデータが混ざる。レビューでどれだけ気を張っても、ゼロにはできない
• うるさい隣人問題: 特定の巨大顧客のクエリが詰まると、関係ない他社まで一緒に遅くなる
• AI活用の難しさ: RAGで「この顧客のデータだけ」を渡したいとき、全顧客が混ざったDBから安全に抜き出すロジックは想像以上に重い。プロンプトインジェクションで他社データに到達される事故も現実に起きている

この構造は、AIで何でも作れる時代にそのまま持ち越して良いものではないと思います。

Cloudflare D1 がインフラの前提を変える

D1 は SQLite をベースに、Cloudflare のエッジに分散配置されたサーバーレスのリレーショナルDBです。SaaSを量産する側にとって何が違うか。

• 固定費がほぼゼロ: アイドル中のDBにお金を払わなくていい。100個のDBを「念のため」立てっぱなしにしても、空のままなら課金されない
• 動的にDBを生成できる: 新規契約のたびに API 一本で「その顧客専用の D1 を1つ作る」が成立する。RDSで同じことをやろうとしたら、まず経理に怒られます
• Workers と地続き: Worker からのアクセスはネットワーク的にほぼゼロホップ。マルチリージョン読み取りも標準でついてくる

これまで「贅沢すぎてやれなかった」シングルテナント構成が、D1 だとデフォルト選択肢に変わります。

シングルテナント（1顧客1DB）の圧倒的優位性

中小企業が大手と戦うとき、この構成はそのまま営業トークになります。

「物理的に隔離されています」と言える

B2B SaaS の商談で、情シスや法務に最初に聞かれるのが「他社とデータが分かれているか」です。マルチテナントだと「論理的に分離されています」としか言えないが、シングルテナントなら**「DBファイル自体が別物です」と即答できる**。これは契約締結スピードに直結します。

AI / RAG が圧倒的にシンプルになる

DBが顧客ごとに分かれていれば、AIに参照させる範囲は最初から物理的に確定しています。

• 「この顧客のDBだけ読め」と言えば終わり
• 他社データへの越境クエリは構造的に不可能
• 検索精度も、ノイズが減るぶん上がる

マルチテナントで RAG の権限分離を頑張るより、先にDBを分けてしまうほうが結果として早い。

データのポータビリティ

「解約するからデータを返してくれ」と言われたとき、SQLiteファイル一本を渡せば終わります。エクスポートバッチを毎回組まなくていい。解約時の体験が良いSaaSは、再契約率も高いというのが個人的な観察です。

デメリットと、それを越える「覚悟」

もちろん銀の弾丸ではありません。シングルテナント量産には固有の難しさがあります。

マイグレーションの自動化が必須

1,000 個のDBに一斉にカラムを追加する、というオペレーションが日常になります。手作業は最初から不可能 — マイグレーションランナーを自前で持ち、失敗時のロールバックと再試行までセットで組む必要があります。ここは AI に書かせるにしても、人間が最終レビューする領域です。

横断分析には別パイプラインが要る

「全顧客の月間アクティブを出して」と言われたとき、1,000 個の D1 に個別に SQL を投げて回るのは現実的ではない。

• 各 D1 → 分析用 DB（DuckDB、BigQuery、ClickHouse など）へ ETL を回す
• 集計はそちらで行う

要は OLTP と OLAP を最初から分ける設計です。マルチテナントだと「同じDBで両方やる」誘惑に負けがちですが、シングルテナントは強制的に正しい構造に追い込まれます。

巨大化した顧客の「卒業プラン」

シングルテナント時代でも、1つのDBが容量・QPS の上限に当たることはあります。その顧客だけを別のインフラ（専用 D1、あるいは別構成の RDS など）に切り出せる設計を最初から仕込んでおく。テナントID から接続先 DB を解決する層を必ず一枚挟む、というのが具体的な対応です。

インフラを制する者が、AI時代のSaaSを制する

AIで「作る」コストが消える世界では、勝敗を分けるのは**「いかに低コストで、安全に、スケーラブルに運営し続けるか」**です。

重厚長大な RDS の固定費に縛られたまま AI 機能を盛っても、収益構造は健全になりません。Cloudflare D1 でDBを量産し、顧客ごとに最適化された価値を、シングルテナントの安心感ごと届ける。この組み合わせは、中小企業が大規模SaaSを名乗るための最も現実的な装備だと思っています。

株式会社ワイアード&エコでは、この構成を前提とした SaaS 開発・移行の相談を承っています。既存マルチテナント SaaS のシングルテナント化検討、D1 への移行設計、量産期のマイグレーション運用設計など、お気軽にお問い合わせください。