ステップ5: データモデルをスケッチする

ほとんどのアプリは、実のところデータに関するものです。何を保存し、各要素がどう関係するか。手早いデータモデルのスケッチは、後で混乱した一貫性のないコードに悩まされるのを防いでくれます。データベースの図は必要ありません。フィールドのリストで十分です。

読書トラッカーなら、主役は一つ — Bookです。

Book
- id: 一意の文字列
- title: 文字列
- author: 文字列
- status: "to_read" | "reading" | "finished"
- rating: 数値 1–5 (読了の場合のみ)
- addedAt: 日付

この小さなスケッチですら、決定を明示してくれます。評価は読了した本にしか存在しない、ステータスは決まった3つの値のいずれか、すべての本にはidがある、というように。これをAIに渡せば、AIはフィールド名を推測するのをやめ、一貫した形で組み立てます。

これを早い段階で固める理由は、フィールド名があちこちに染み出していくからです。いったんAIがbook.ratingを読むコードを書けば、その名前はフォーム、リスト表示、ストレージ層、そして後で追加するどんな機能にも現れます。それがぶれるのを放っておくと — ある場所ではrating、別の場所ではstars、また別の場所ではscore — 追いかけるのが面倒なバグが生まれます。6行のデータモデルは、それに対する最も安価な保険です。

短くてコピー&ペーストできる仕様ブロックは、AIにとって散文よりもうまく機能する傾向があります。同じモデルを、実際に送るプロンプトとして書くとこうなります。

本にはこの正確なデータ形を使って。挙げていないフィールドは追加せず、
これらの名前も変えないで：

Book {
  id        — 一意の文字列、作成時に生成
  title     — 文字列、必須
  author    — 文字列、必須
  status    — 次のいずれか: "to_read" | "reading" | "finished"
  rating    — 整数 1–5、statusが "finished" のときのみ存在
  addedAt   — ISO日付文字列、本の追加時に設定
}

フィールドが足りないと思ったら、追加する前に聞いて。

最後の一行 — ask me before adding it(追加する前に聞いて) — が実際の仕事をしています。これはAIを推測者から協力者へと変え、データモデルをあなたのものに保ちます。