はじめに：AIフルスタック開発のボトルネックはDBだった
AIエージェントにWebアプリを作らせる体験は、かなり進化しました。
Claude Code、Codex、Gemini、Cursor、Windsurfに要件を渡せば、UI、API、認証、DBアクセスまで含むフルスタックアプリのたたき台が短時間で出てきます。
しかし、実務で使うとすぐに壁に当たります。
DBです。
フロントエンドはDeploy Previewで簡単に確認できます。
でも、DBを含むアプリになると急に面倒になります。
- PRごとにDBをどう分けるのか
- 本番DBのデータを壊さずに検証できるのか
- AIエージェントが作ったマイグレーションをどこで実行するのか
- 複数のAIエージェントが別々のスキーマ変更をしたらどうなるのか
- 本番反映時にコードとDBスキーマのバージョンがズレないか
AIが画面を作る速度は上がりました。
でも、DBが単一の本番環境に近いままだと、実験の速度は上がりません。
むしろ、AIが速く壊すだけです。
そこで出てきたのが、Netlify Databaseです。
これは単なる「NetlifyにPostgresが付きました」という話ではありません。
私の見方では、Netlify Databaseの本質は、データ層にもDeploy Previewの思想を持ち込んだことです。
Netlify Databaseとは
Netlify Databaseは、Netlifyプラットフォームに統合されたフルマネージドPostgresです。
公式ドキュメントでは、以下をNetlify側が扱うと説明されています。
- プロビジョニング
- マイグレーション
- データベースブランチング
つまり、アプリケーション開発者は「Postgresをどこに作るか」「プレビュー用DBをどう分けるか」「本番マイグレーションをいつ実行するか」を、従来よりかなり意識しなくてよくなります。
特に重要なのは、Netlify Databaseが以下のNetlify実行環境から使える点です。
- Netlify Functions
- Edge Functions
- Builds
- Agent Runners
AIエージェントがコードを書く時代に、DBがAgent Runnersの文脈に入っていることは大きいです。
何が革命的なのか：DBもブランチする
Netlify Databaseの最大の特徴は、Database branchingです。
従来の開発では、よくこういう構成になります。
Production DB
Staging DB
Local DB
一見きれいですが、実務では問題があります。
問題1：Staging DBはすぐ本番とズレる
本番DBのデータは日々変わります。
でも、Staging DBはコピーした瞬間から古くなります。
その結果、Stagingでは動くのに本番では壊れる、ということが起きます。
問題2：Staging DBが並行開発のボトルネックになる
複数人、または複数AIエージェントが同時に作業すると、Staging DBはすぐ汚れます。
Agent A: usersテーブルにroleを追加
Agent B: usersテーブルのnameをdisplay_nameへ変更
人間C: subscriptionsテーブルを追加
これを同じStaging DBでやると、誰の変更で壊れたのか分からなくなります。
AIエージェントを並列に走らせたいなら、単一Staging DBは限界です。
Netlify Databaseの考え方
Netlify Databaseでは、Production deployだけがメインDBへアクセスできます。
一方で、Deploy Previewには専用のDBブランチが割り当てられます。
Deploy Preview用のDBブランチは、作成時点の本番データをコピーして持ちます。
その後、プレビュー環境でデータを追加しても、削除しても、スキーマを変えても、本番DBには影響しません。
これは、AIエージェントにとって非常に大きいです。
AIエージェントは、時々かなり大胆な実装をします。
- カラム名を変える
- テーブルを作り直す
- seedデータを大量に入れる
- 誤ったDELETEクエリを書く
- マイグレーションの順序を間違える
これを本番DBや共有Staging DBに対してやられると危険です。
でも、エージェントごとにDBブランチが分かれていれば、壊しても影響範囲はそのブランチだけです。
AIエージェント並列開発の実務インパクト
Netlify Databaseが面白いのは、単に安全な検証環境ができることではありません。
AIエージェントを並列に走らせる前提に合っていることです。
たとえば、顧客向けの管理画面を作っているとします。
顧客からこう言われました。
在庫管理画面に、以下の3パターンを試したいです。
A: ステータス管理を追加
B: 承認ワークフローを追加
C: コメント履歴を追加
従来なら、DBスキーマが絡むので慎重に順番を決めます。
しかし、Netlify Database + Agent Runnersの前提なら、こうできます。
Agent A: statusカラムとステータスUIを実装
Agent B: approvalsテーブルと承認UIを実装
Agent C: commentsテーブルと履歴UIを実装
それぞれが別ブランチ、別Deploy Preview、別DBブランチを持ちます。
顧客には3つのPreview URLを渡せます。
- A案のURL
- B案のURL
- C案のURL
顧客は実際に触って選べます。
この時、本番DBは一切壊れません。
これが「DBもブランチする」ことの実務的な意味です。
自動マイグレーションの価値
もう一つ重要なのが、Automatic migrationsです。
Netlify Databaseでは、リポジトリ内のマイグレーションファイルを追跡し、Deploy PreviewやProduction Deployのライフサイクルに合わせて適用します。
これにより、以下のズレを防ぎやすくなります。
コードは新しいschemaを前提にしている
↓
しかしDBは古いschemaのまま
↓
本番で落ちる
AIエージェント開発では、このズレが起きやすいです。
AIはUIとAPIを書き換えるついでに、DBスキーマも変えます。
しかし、人間がマイグレーション実行を忘れると壊れます。
Netlify Databaseの自動マイグレーションは、ここをプラットフォーム側で吸収しようとしています。
Drizzle ORMとの相性
公式ブログでは、Drizzle ORMとdrizzle-kitによるマイグレーションにも触れられています。
AIエージェントにフルスタックアプリを作らせる場合、DrizzleのようなTypeScriptファーストなORMは相性がいいです。
理由はシンプルです。
- スキーマがコードとして読める
- TypeScript型とDB構造を近づけやすい
- AIがスキーマ変更を把握しやすい
- マイグレーションファイルをGitでレビューできる
たとえば、AIに以下のような指示を出せます。
Netlify DatabaseとDrizzle ORMを使って、顧客管理アプリを作ってください。
要件:
- customersテーブル
- notesテーブル
- customersとnotesは1対多
- 削除は物理削除ではなくdeleted_atによる論理削除
- マイグレーションファイルを生成
- Netlify FunctionsからDBへアクセス
- Deploy Previewで動作確認できるようにする
AIは、DB設計、API、UI、マイグレーションをまとめて作れます。
ただし、ここで人間が見るべきものは残ります。
特に以下です。
- 外部キー制約
- unique制約
- index設計
- 論理削除の扱い
- 個人情報の保存範囲
- 本番移行時の破壊的変更
AIに作らせてよい。
でも、DB設計の責任までAIに渡してはいけません。
Netlify BlobsやIdentityと組み合わせる
動画のチュートリアルでは、Netlify Databaseだけでなく、画像保存にNetlify Blobs、ログインにNetlify Identityを組み合わせる流れも紹介されていました。
この組み合わせは、AIエージェントによる管理画面PoCと相性がいいです。
Netlify Database: 構造化データ
Netlify Blobs: 画像・添付ファイル
Netlify Identity: ログイン・ユーザー認証
Netlify Functions: サーバーサイド処理
Deploy Preview: 顧客レビュー
たとえば、以下のようなPoCはかなり早く作れます。
- 商品マスタ管理
- 社内FAQ管理
- 採用候補者管理
- イベント会場管理
- 写真付きコレクション管理
- 顧客ポータル
従来なら、DB、画像保存、認証、デプロイでそれぞれ設定が必要でした。
Netlify上でまとまると、AIエージェントが扱いやすい構成になります。
ただし、注意点もある
Netlify Databaseは強力ですが、何も考えずに使ってよいわけではありません。
1. Credit-based planが必要
公式ドキュメントでは、Netlify DatabaseはCredit-based planで利用可能とされています。
また、DBがアクティブな間はcomputeとbandwidthのクレジットを消費します。
ストレージ容量については、2026年7月1日まで無料と案内されていますが、料金条件は変わりうるため、本番導入前に必ず最新のPricingとUsage docsを確認した方がよいです。
2. ブランチ数やバックアップ条件はプラン依存
公式ブログでは、プランによってデータベース数、許可されるブランチ数、バックアップ期限などが変わると説明されています。
AIエージェントを大量に並列実行する場合、ブランチ数の上限やコストは設計に入れるべきです。
3. 自動マイグレーションは「レビュー不要」ではない
自動で適用されるからといって、破壊的変更をレビューしなくてよいわけではありません。
特に以下は危険です。
- カラム削除
- テーブル削除
- 型変更
- NOT NULL制約追加
- 大量データに対するindex追加
- 本番データ前提のデータ移行
AIが作ったマイグレーションは、必ず人間が読みます。
ここを飛ばすと、便利な自動化がそのまま事故になります。
4. Production DBへの責任境界を明確にする
Deploy PreviewのDBブランチは安全な実験場です。
しかし、本番反映は別です。
PRをマージすれば本番DBへのマイグレーションが走る可能性があります。
だからこそ、以下のような運用ルールが必要です。
- DB変更を含むPRにはラベルを付ける
- マイグレーションファイルを必ずレビュー対象にする
- 破壊的変更は別PRに分ける
- 本番データ移行はロールバック方針を明記する
- AIエージェントが作った変更をそのままマージしない
AI開発では、ここが人間の仕事です。
私ならこう運用する
Netlify Databaseを実務で使うなら、私は以下のルールにします。
ポイントは、AIに自由に試させる場所と、人間が止める場所を分けることです。
AIに任せる範囲:
- 初期スキーマ案
- CRUD画面
- APIハンドラ
- seedデータ
- マイグレーションファイルの生成
- Deploy Previewでの動作確認
人間が握る範囲:
- 本番DBの設計責任
- 制約・index・権限
- 個人情報の扱い
- 破壊的マイグレーションの判断
- コストとブランチ数の管理
- 本番マージ判断
この分担なら、AIの速度を活かしつつ事故を抑えられます。
Netlify Databaseは「AX」のためのDB
最近、Agent Experience、つまりAXという言葉が出てきています。
DXが人間開発者の体験だとすれば、AXはAIエージェントが正しく開発できるための体験です。
Netlify Databaseは、このAXをかなり意識した機能です。
理由は以下です。
- エージェントごとにDBブランチを持てる
- CLIが非対話・JSON出力を意識している
- SkillsによりAIがDBの扱いを理解しやすい
- マイグレーションがコードと一緒に追跡される
- Deploy PreviewとDBの状態が対応する
AIにとって一番つらいのは、暗黙の手作業です。
「このSQLは本番前に人間が手で実行してね」
「この環境変数は管理画面から入れてね」
「このDBはStagingだけど、たまに本番データをコピーしてね」
こういう曖昧な運用は、AIエージェントと相性が悪いです。
Netlify Databaseは、DB運用をGit、Deploy Preview、Agent Runの流れに寄せることで、AIが扱いやすい形にしています。
まとめ：DBにも安全な実験場が必要になった
AIエージェントにフルスタック開発を任せるなら、コードだけでなくDBにも安全な実験場が必要です。
Netlify Databaseの本質は、Postgresが使えることだけではありません。
本質は、以下です。
- Deploy PreviewごとにDBブランチを持てる
- Agent Runごとに隔離されたDB環境を持てる
- 本番DBを壊さずスキーマ変更を試せる
- マイグレーションをデプロイライフサイクルに組み込める
- AIエージェントの並列開発を現実的にできる
フロントエンドは、すでにブランチごとのPreviewが当たり前になりました。
次は、DBもブランチする時代です。
AIがフルスタックアプリを作る時代に、データ層だけが単一の危険な共有環境のままでは耐えられません。
Netlify Databaseは、その最後のボトルネックをかなり本気で潰しにきた機能だと思います。
参考リンク
この記事を書いた人✏️@YushiYamamoto
株式会社プロドウガ CEO / AIアーキテクト
Next.js / TypeScript / n8n / Netlifyを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。