AIアプリビルダーが、まず偽のデータを見せる理由（そして、それが正しい一手である理由）

あなたはAIアプリビルダーにアプリを説明します。1分後、動くインターフェースを目にします — ページ、ボタン、「Alex Rivera」や「Priya Shah」といった名前のユーザーが並ぶ表、意味のなさない価格、頼んでもいない「Proプラン」。何も保存されていません。リロードしてもデータはまだそこにあります。新しいユーザーを追加すると、消えてしまいます。

崩れる寸前の手品のように見えます。違います。それはビルドの良い部分です。画面に映るモックデータは、意図された最初の一歩であり、次に作られるデータベースが、あなたがほしかったアプリに実際に一致する理由なのです。

「まず偽のデータ」とは、本当はどういうことか

AIアプリビルダーは、あなたの依頼を受け取ると、まっすぐデータベースへは向かいません。良いビルダーは、まず画面を書き、もっともらしい仮のデータでそれを満たし、そして — そのあとで初めて — それに合うようにデータベースを設計します。

仮のデータは飾りではありません。契約です。アプリが「すべての注文には顧客名、3つの明細、合計、ステータスがある」と言った時点で、次に作られるデータベースは、まさにそれらを、まさにその形で持たなければなりません。データの見た目を決めるのは画面であって、その逆ではないのです。

これは、人間の開発者が普通に始めるやり方とは逆です。従来の開発者は、まずデータベースを設計し、それに対して画面を作ります。AIビルダーはそれをひっくり返しました。そして、ほとんどの人はそれに気づきません — ただ偽のユーザーを見て、ビルダーがごまかしていると思い込むのです。

なぜこの順序がAIではうまくいくのか

私たちはデータベースと画面を同時に作ろうとしてみました。うまくいきませんでした。なぜかを手短に。

2つのAIエージェントが、互いの出力を見ないままアプリの別々の部分を作業すると、互いに食い違う推測をします。インターフェース担当のエージェントは、ユーザーには「name」フィールドがあると決める。データベース担当のエージェントは、ユーザーには「fullName」フィールドがあると決める。どちらも正しそうに見えます。合わさると、何も動きません。食い違いをつぎはぎするために3番目のエージェントが呼ばれます。それも推測します。今や3つの推測が野放しになり、あなたがプレビューするアプリは、そのすべてが混ざったフランケンシュタインです。

直し方はほとんど気恥ずかしいほどです。まず一方をやり、それから他方をやる。インターフェースが作られます。それが、必要なデータを、偽のユーザー、偽の注文、あなたのアプリのテーマが何であれその偽物の、ひとつのファイルとして書き出します。データベース担当のエージェントがそのファイルを読み、フィールドごとに一致させます。推測なし。交渉なし。食い違いなし。

だからAIアプリビルダーは、1分で完成したように見えるアプリをあなたに見せられるのです。ビルドをごまかしたのではありません。ビルドの4分の1 — ほかすべてを決める部分 — を終えたのであり、データベースは、次の10時間の仕事ではなく、次の10秒の仕事なのです。

偽のデータが画面にあるとき、何に注目すべきか

ここが、ほとんどの人が素通りする瞬間です。彼らは仮のデータを見て、色の変更を頼み始めます。でも、仮のデータはあなたに投げかけられている問いです。それを読みましょう。

注目すべきものの例をいくつか。

言葉づかいが違う。 あなたがほしかったアプリは「出荷」を扱う。仮のデータはそれを「注文」と呼んでいる。ビルダーに伝えましょう。今これを見逃すと、すべての画面、すべてのデータベースのフィールド、すべてのレポートが間違った言葉を使います — そしてあとからの改名は、マーケティングが何と言おうと、どんなツールでもワンクリックの操作ではありません。
フィールドが足りない。 偽の請求書には合計と日付がある。あなたには発注番号も必要だ。データベースが作られて本物の顧客データが入ったあとよりも、画面にモックの請求書が5つある今、足したほうがいい。
形が違う。 モックデータは「1顧客、1住所」を示している。あなたの実際の顧客は複数の住所を持つ。ビルダーは、あなたの依頼からそれを推測できません。形を変えるのにコストがかからない今、伝えましょう。
意外なエンティティ。 ビルダーが、頼んでもいない「チーム」という概念を発明した。マルチユーザーのアプリだと想定したからです。ほしかったのかもしれない。ほしくなかったのかもしれない。いずれにせよ、データベースがそれを軸に作られる前に決めましょう。

役立つ法則：あなたのアプリに、画面の仮のデータに表れていない名詞があるなら、ビルダーはまだそれを知りません。最初のプレビューで「保存」をクリックする前に、それを口にしましょう。

なぜこの順序が、次に来るものにとって重要なのか

仮のデータが正しくなれば、データベースの構築は機械的です。ビルダーは偽のデータを読み、それに合うスキーマを生成し、画面がすでに呼ぼうとしているクエリを書き、最後に仮のインポートを本物のものに差し替えます。偽のユーザーを表示していた同じ画面が、今度はあなたが実際に入れたものを表示します。

たいてい、その差し替えがリアルタイムで起きるのが見えます。ローカルファイルを読んでいたから即座に表示されていたページが、今や半秒のローディング状態を持つ — それが、画面が初めて本物のデータベースと話している瞬間です。ほとんどの人はこれを見逃し、アプリがたった今「デモ」から「本物のデータを保存できるもの」へと一線を越えたことに気づきません。

これがそもそも機能する理由は、その下流のすべて — データベースの設計、クエリ、ローディング状態、空の状態 — が、仮のデータの段階であなたが画面で見たものによって決められたからです。3列を承認したなら、3列が手に入ります。値が「draft」と「sent」の「status」フィールドを承認したなら、まさにそれがデータベースの受け入れるものです。デザイナーから開発者への引き継ぎで物事がぐちゃぐちゃになる、2度目の翻訳ステップはありません。

試せる小さなテスト

次に何かを作るとき、これを試してください。仮のデータが現れたら、ほかの何かを頼む前に、それについて 1つだけ変えてみましょう。フィールドの名前を変える。列を足す。「users」を「members」に置き換える。そして、データベースが作られるときに何が起きるか見てください。

その変更が、あらゆるところに現れるのが見えるはずです — データベースの設計に、クエリに、アプリが完成したときにビルダーが入れるシードデータに。仮の段階での1つの言葉が、アプリ全体に波及したのです。それが、この段階であなたが持つレバレッジであり、「まず偽のデータ」が手抜きの技ではない理由です。それは、アプリが実際に決まる場所なのです。

もっと深掘りしたいなら、AIで作ったアプリの中身には実際に何があるのかという前回の記事が、一見では見えないほかの可動部を案内します。パターンは同じです。レバレッジのほとんどは、重要でなさそうに見える部分にあるのです。