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

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

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

Book
- id: unique string
- title: string
- author: string
- status: "to_read" | "reading" | "finished"
- rating: number 1–5 (only if finished)
- addedAt: date

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

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

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

Use this exact data shape for a book. Don't add fields I didn't list,
and don't rename these:

Book {
  id        — unique string, generated on creation
  title     — string, required
  author    — string, required
  status    — one of: "to_read" | "reading" | "finished"
  rating    — integer 1–5, present ONLY when status is "finished"
  addedAt   — ISO date string, set when the book is added
}

If you think a field is missing, ask me before adding it.

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