2026 年 5 月、Zenn Trending で AIエージェント時代のDB設計をTursoが書き換えに来ている話 が話題になり、AI エージェントを組み込むアプリの DB 設計が「中央集権 PostgreSQL 一択」から「Turso / libSQL ベースの Local-First」に揺らぎ始めていることが議論されています。
Turso は libSQL（SQLite のフォーク）+ エッジレプリケーションを提供するクラウド DB で、「AI エージェントが手元で読み書きする」ユースケースに最適化されています。本記事では受託案件で Turso を採用するときの判断基準を整理します。
なぜ「PostgreSQL 一択」が揺らいだのか
AI エージェントを内蔵するアプリの典型的な要件は、従来の Web アプリと根本的に違います。
| 要件 | 従来の Web アプリ | AI エージェント内蔵アプリ |
|---|---|---|
| 書き込み頻度 | 顧客操作トリガー（疎） | エージェントの判断（頻繁） |
| 読み取り対象 | ユーザー自身のデータ | エージェントの記憶・履歴・状態 |
| レイテンシ | 100 〜 300ms 許容 | 10 〜 50ms 必要（思考連鎖中） |
| トランザクション | ACID 重視 | 局所一貫性で十分 |
| マルチテナント | スキーマ分離 | テナントごと DB 分離が現実的 |
特に 「エージェントの思考連鎖中の読み取り」が 10 〜 50ms を要求する点で、ネットワーク往復前提の PostgreSQL は構造的に厳しいケースが増えています。これは ローカルファースト Web アーキテクチャ受託 で扱った “オフライン業務 SaaS” の議論を、AI エージェント向けに展開したものです。
Turso の 4 つの構造的優位
優位 1: 「テナント = DB」が安く実現できる
Turso では DB 作成が無償・無制限で、「顧客 1 社 = DB 1 個」を現実的にできます。これは Cloudflare Dynamic Workflows マルチテナント受託 で扱った “テナント分離” を DB 層で実装するパターンです。
優位 2: エッジレプリカで読み取りが速い
Read Replica が エッジで自動配置され、エージェントの読み取りが 10 〜 30ms で返ります。中央 DB を叩く構成より 1 桁速いことが、エージェントの応答性に直接効きます。
優位 3: 埋め込み SQLite で開発体験が良い
ローカル開発で 本番と同じ SQLite を使えるため、「開発で動くが本番で動かない」 トラブルが激減します。これは Astro クラウドビルドエラー対応 と同種の “環境差異” の話で、開発体験が改善するのが現実的なメリットです。
優位 4: Vector データ型をネイティブサポート
Turso は ベクトル検索を SQLite ネイティブ拡張で持つため、「ベクトル DB を別建てしない」 設計が可能です。これは 既存 SaaS API を MCP サーバー化する設計パターン で議論した “AI 連携用 DB” を 1 本にまとめる選択肢です。
受託案件での適用シナリオ 3 パターン
パターン 1: AI エージェント内蔵 SaaS の MVP
新規 SaaS で AI エージェントを核に据える場合、Turso は 「テナント = DB」+ Vector 内蔵で 初期構築が劇的に速い選択肢です。
- 想定リードタイム: MVP 構築 8 〜 12 週間
- 典型予算レンジ: 400 万 〜 1,200 万円
- 判断基準: 1 テナント当たりデータ量が 数 GB 未満、書き込みが 1k QPS 未満
パターン 2: 既存 PostgreSQL の AI エージェント部分だけ Turso 化
既存システムは PostgreSQL のままで、AI エージェントの状態・記憶・履歴だけ Turso にオフロードするパターンです。「コア業務 DB を触らない」 ことで、リスクを最小化します。
- 想定リードタイム: 設計 + 実装 6 〜 10 週間
- 典型予算レンジ: 300 万 〜 800 万円
- 判断基準: 既存 DB が触れない・触りたくない案件で AI 機能を追加する場合
パターン 3: オフライン業務 SaaS の DB 層
訪問・現場で使う業務 SaaS では、Turso の埋め込み SQLite + 同期が 「オフラインで動く」 要件を最も簡潔に満たします。
- 想定リードタイム: 12 〜 24 週間
- 典型予算レンジ: 1,000 万 〜 3,000 万円
- 判断基準: オフライン要件 + AI 機能の同居
移行設計のロードマップ
[Phase 0: スパイク] 2 週間
├ Turso 上で代表データのプロトタイプ
├ レイテンシ・コスト・運用感の確認
└ Go / No-Go 判断
[Phase 1: スキーマ設計] 4 週間
├ テナント分離方式の決定
├ Vector 用テーブル設計
└ バックアップ・レプリカ戦略
[Phase 2: 実装] 6 〜 10 週間
├ Repository 層の libSQL 対応
├ AI エージェント側の読み書き層
└ 監視・アラート整備
[Phase 3: 並行運用] 4 週間
├ 既存 DB との突合検証
├ 性能ベンチ
└ ロールバック手順整備
[Phase 4: 本番切替]
├ 段階移行（テナント単位）
└ 並行運用解除Phase 0 のスパイクを独立した契約にすることで、「Turso が合うかどうか」の判断自体を案件化できます。
受託契約に書く Turso 導入条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 可用性 SLA | Turso の SLA を契約に転記 + アプリ側 SLA を分離 | 二重 SLA の責任分解 |
| データ所在地 | エッジレプリカの所在地と法的規制 | 越境データの制約 |
| バックアップ | バックアップ頻度・保管期間・復元手順 | RTO / RPO |
| ベンダーロックイン | libSQL の OSS 性を理由にロックインリスクを評価 | 撤退コスト |
| コスト上限 | 月額コストの想定と超過時のアラート | 予算統制 |
特に **「ベンダーロックイン」は、Turso が libSQL（OSS）ベースである点を顧客に説明することで、「PostgreSQL より閉じている」**懸念を解消できます。
価格モデル — Turso 導入受託パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| Spike | 100 万円〜 | 2 週間 | スパイク + 判断レポート |
| Lite | 500 万円〜 | MVP / 小規模 SaaS | 単一テナント MVP |
| Standard | 1,200 万円〜 | マルチテナント SaaS | テナント = DB の実装 |
| Enterprise | 3,000 万円〜 | 既存 + AI 拡張 | 既存 DB との並列運用 |
ハマりやすい 4 つの落とし穴
落とし穴 1: 「テナント = DB」の管理コスト
DB が数百個に増えると、「マイグレーションをどう全 DB に適用するか」が運用の主課題になります。マイグレーション基盤を最初から組むことが必須です。
落とし穴 2: トランザクション境界の誤解
libSQL は SQLite ベースなので DB 間トランザクションを張れません。「テナント間集計」が要件にあると詰むため、事前にユースケースを洗います。
落とし穴 3: バックアップ戦略
DB が大量にあるため、手動バックアップは不可能です。Turso 純正バックアップ + 自社側スナップショットの二重化を設計します。
落とし穴 4: 監視の盲点
DB が大量にあると 「どの DB が遅いか」が分かりにくくなります。テナント横断の P99 レイテンシダッシュボードを最初から組みます。
まとめ — AI エージェント時代の「DB 1 階層下げる」設計
Turso が示すのは、AI エージェント内蔵アプリでは「DB を中央集権で持つこと」自体が制約になるということです。受託の現場で AI エージェントを核にした SaaS を組むとき、「PostgreSQL を分散するのではなく、SQLite をエッジに撒く」選択肢を持つことが、性能・コスト・運用の 3 軸で効きます。
弊社では Spike / Lite / Standard / Enterprise の 4 段階で Turso 導入受託パッケージを提供しています。「AI エージェントを内蔵した SaaS を作りたい」「既存 PostgreSQL に AI 機能を追加したい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
