AIビルダーは本当に実用的なデータベースを扱えるのか？FAQ

この質問は、私がこれまで行ったほぼすべての懐疑的なデモで出てくる。誰かがAIビルダーが数分で動くアプリを立ち上げるのを見て、最初の「へえ、速いな」という驚きが薄れると、次に出てくる本当の質問は決まってこうだ——分かった、でもこれ実際にデータベースは入っているのか、それともデモ用にでっち上げているだけなのか?もっともな疑問だ。人が触り始めてから懐疑心が進化していく順序でおおよそ出てくる質問を並べてみよう。

本物のデータベースはあるのか、それともデモはサンプルデータで誤魔化しているだけなのか?

本物のデータベースはある。変わるのはどれを使うかであり、その違いこそ、何かを維持するつもりで作る前に理解しておく価値がある部分だ。「90秒でこれが動くのを見てほしい」を最適化するプロトタイプ向けAIビルダーは、多くの場合SQLiteを選ぶ——ディスク上の1つのファイルで、セットアップ不要、単一ユーザー向けの本物のアプリを動かすには十分な性能を持つ。「実際のトラフィックと複数テナントに耐える必要がある」を最適化するビルダーはPostgresを選ぶ。SQLiteのファイルロックモデルは、複数のプロセスが同時に書き込む必要が出た瞬間に痛み始めるからだ。どちらを使っているか聞いてみるべきだ。セールスページやサポートチャットに聞くのに全く問題ない質問であり、誰も明確に答えられないなら、それ自体が何かを物語っている。

実際にはどのデータベースエンジンを使っているのか?

おもちゃ以上の何かを目指すプラットフォームでは、Postgresだ。地味だが正しい答えであり、ここでは地味さこそ求めるべきものだ。Postgresは行レベルセキュリティを提供するので、アプリケーションコードにバグがあってもテナントAの行がテナントBのクエリから見えないようになる。本物の外部キー、本物のトランザクション、そして「誰かが既にこのエッジケースに当たって直してくれた」という20年分の蓄積がある。興味深い失敗パターンは「どのSQL方言か」ではなく、速度のためにSQLiteで始めて、利用が拡大しても決して移行しないビルダーだ。稼働中のユーザーがいるデータベースの移行は地味な作業で、後回しにされ続けやすいからだ。何年も動かすつもりのものにビルダーを評価しているなら、アプリがユーザー1人分の規模を超えたときにデータベースがどうなるか聞くべきだ。誠実な答えには移行パスの話が出てくる。はぐらかす答えには具体性のない「スケーラブル」という言葉が繰り返されるだけだ。

自分のデータを見ることはできるのか、それともブラックボックスの中に閉じ込められているのか?

見られるべきだ、それだけだ。テーブルブラウザ、クエリコンソール、エクスポートボタン——アプリ自体のUIを経由せずに行を確認する何らかの手段が必要だ。これは技術的な質問というより信頼の質問だ。検査できないスキーマを生成するAIビルダーは、あなたが書いていない、監査もできないコードを信頼してくれと言っているようなもので、「大丈夫、UIのボタンはちゃんと動くから」よりもはるかに大きな要求だ。これをきちんとやっているツールは、根底にあるデータをあなたから守るべき実装の詳細ではなく、デフォルトであなたのものとして扱う。

新しい機能を頼んだとき、スキーマの変更にも対応してくれるのか?

ここが本当に難しく、多くのAIビルダーが密かに力不足を露呈する場所だ。カラムを追加するのは簡単だ。カラムを追加し、既存の行に妥当なデフォルト値をバックフィルし、そのテーブルに触れるすべてのクエリを更新し、しかもすでに存在するデータを失わずにやる——それがマイグレーションであり、マイグレーションは「AIがコンパイルの通るコードを書いた」ことと「AIが本番データに対して実行しても安全なコードを書いた」ことが同じではない数少ない領域の一つだ。使う価値のあるビルダーは、スキーマ変更を大きな機能要望に黙って組み込むのではなく、それ自体をレビュー可能なステップとして扱う。「タスクに期限日を追加して」と頼んで、フロントエンドしか触れていない差分が返ってきたら、疑うべきだ——データベースにはその話が伝わっていない。

リレーションを適切にモデル化しているのか、それともすべてが一つの巨大なJSONの塊に平坦化されているのか?

両方のパターンが存在し、どちらを得るかは多くの人が最初に思うより重要だ。リレーショナルスキーマ——ユーザー、注文、注文明細に分かれ、外部キーで結ばれたテーブル——なら、アプリの元のUIが想定していなかった質問にも答えられる。「XとYを両方買った顧客は誰か」「商品カテゴリ別の返金率はどうか」といった具合だ。レコードごとに単一の非正規化されたJSONの塊は生成が速く、本当にシンプルなアプリなら問題ないが、後から「レポートを追加してほしい」という要望が来るたびに再アーキテクチャになってしまう。動いているアプリだけでなくスキーマも見せてもらおう。すべてのテーブルが`{ id, data jsonb }`のように見えるなら、画面に何かを素早く表示することを最適化し、本当のデータモデリングを先送りしたビルダーを見ていることになる。

設計時に想定されていたデータ量を超えたらどうなるのか?

根底のエンジンがそもそも並行処理を想定して作られているかどうかに完全に依存する。これは形を変えた、あのSQLite対Postgresの話だ。1人のユーザーで数百行を扱うSQLite上のアプリは、同じ負荷を扱うPostgres上のアプリと見た目は変わらない——違いが表れるのは、同時書き込みが発生したり、行数が増えたり、インデックスとクエリプランニングの恩恵を受けるような分析クエリを追加してからだ。アプリが本当に単一ユーザーで永久に低ボリュームなら、これが問題になることはないかもしれない。顧客を持つことを望むものを作っているなら、問題が起きる前にスケーリングについて聞いておこう。サポートチケットが答えを教えてくれる後ではなく。

共有プラットフォーム上の他のユーザーから、自分のデータは実際に分離されているのか?

これは最も強く押しておきたい点だ。失敗するまで見えないからだ。全員のデータを同じデータベースに保存するマルチテナントプラットフォームには、本物の分離境界が必要だ——すべてのクエリに`WHERE user_id = ?`句を付け忘れずに追加するアプリケーションコードではなく、データベース自体が強制する行レベルセキュリティポリシーだ。この違いが重要なのは、アプリケーションコードによる分離は静かに失敗するからだ。あるエンドポイントでフィルターを一つ見落とすだけで、テナントAが突然テナントBの行を見られるようになる。データベースが強制する分離は派手に失敗する。アプリケーションコードがフィルターを忘れていても、クエリは何も返さないからだ。テナント分離がデータベース層で強制されているのか、それともアプリケーションコードに委ねられているのか、具体的に聞いてみよう。「本物のデータベースを扱えるか」と聞いている人の多くは、実はまだ語彙を知らないままこの質問をしているのだ。

望めばすべてをエクスポートして離脱できるのか?

実際のデータの完全なエクスポートを取得できるべきだ——アプリのスクリーンショットでも、レポートのPDFでもなく、他の場所に読み込める形式での元データだ。これを難しくしているビルダーは、その関係性をどう考えているかについて何かを物語っている。「AIビルダー」の誠実な意味は、プラットフォームがあなたに代わってコードとスキーマを生成したということであって、自分で用意していないテーブルにデータが着地した瞬間にそのデータがあなたのものでなくなる、という意味であってはならない。

データベースは誰もデモしない部分だ。だからこそ、何かに登録する前に聞いておく価値がある部分なのだ。

これはどれも突飛なエンジニアリングではない。どんなバックエンド・アズ・ア・サービスやホスティングの決定にも適用する、それと同じデューデリジェンスだ。AIという要素は、それを尋ねるのを忘れやすくしているだけだ。デモがあまりに配管を隠すのが上手いからだ。どのエンジンか聞き、スキーマを見せてもらい、マイグレーションについて聞き、分離について聞こう。答えが具体的なら、おそらく大丈夫だ。