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

> AI（バイブコーディング）で『作る』コストは消えました、大量のサービスを運営していく際のDBのコストを考えます

Date: 2026-05-13

Tags: Cloudflare, D1, SaaS, アーキテクチャ, AI, 中小企業

---

![Cloudflare D1 によるシングルテナント SaaS のアーキテクチャ](https://img.wiredxeco.com/wiredxeco/cloudflare-d1-single-tenant/hero.webp)

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 への移行設計、量産期のマイグレーション運用設計など、お気軽にお問い合わせください。