AIで構築するアプリの一貫性を保つワンページ仕様テンプレート

アイデアがまだあいまいなときにPlanning Modeが重要な理由

あいまいなアイデアは妄想には向いていますが、作るには粗いままです。

「習慣を追跡するアプリを作って」とだけAIビルダーに頼むと、AIはあなたの意図を推測するしかありません。その推測はプロンプトごとに変わり、結果としてアプリも変わります。画面が噛み合わなかったり、データ名が途中で変わったり、機能が出現・消失・別の形で再登場したりします。

この不整合はだいたい次のような箇所に現れます：

• ユーザー像の違い（個人利用者 vs チーム）
• ワークフローの矛盾（まずログをつけるのか、まず作るのか）
• データ名の揺れ（habit vs routine vs goal）
• エッジケースの抜け（削除されたらどうなるか）

「Planning Mode」は、ビルドの前に一旦立ち止まるシンプルな手法です。AIが勝手に決める代わりに、あなたが決定を書き出します。目的は一貫性：UI、バックエンド、データベースが従う共通の選択を作ることです。

目標は完璧ではなく、反復しやすいビルドを作ることです。後で方針を変えるなら、小さな仕様を更新して同じ論理で再構築すればいい。だからワンページの仕様テンプレートが役に立ちます。長いPRDでも図の山でもなく、誰が使い、何を達成し、どんなデータがあって、どのエッジケースや非ゴールがv1を爆発させないかを答える1ページです。

例：「予約アプリ」が単一のサロンオーナー向けかマーケットプレイスか、顧客が再調整・キャンセル・ノーショーできるかを決めればぐっと明確になります。

1分でわかるワンページ仕様テンプレートの説明

ワンページ仕様テンプレートは、あいまいなアイデアを明確な指示に変える短いメモです。製品全体を設計するのではなく、AIビルダーが毎回同じ選択をするのに十分な構造を与えます。

ページは4つのブロックです。1ページに収まらないなら、最初のビルドに機能が多すぎます。

• Users：誰が使うか（2–3タイプ）、何が違うか。\n- Jobs-to-be-done：各ユーザーが達成したいことを成果として記述。\n- Entities：保存・追跡する主要なもの（データの名詞）。\n- Edge cases + non-goals：何が壊れうるか、v1で作らないもの。

ワンページにすることで有益な制約が生まれます。主要ユーザーを一つに絞り、最小の成功フローを定義し、「全部対応する」といった曖昧な約束を避けるよう促します。これらの制約がAIビルドの画面ずれを防ぎます。

「十分に良い」詳細は単純でテスト可能な記述です。誰かが読んで「これが動いているとどう分かる？」と問えるなら、適切なレベルです。

目安：

• 新規ユーザーが主要ジョブを2分以内に完了できる。\n- 各ジョブに明確な開始と終了がある（「管理する」みたいな終わりのない表現は避ける）。\n- 各エンティティに実際に必要なフィールドが3–7個ある。\n- 上位5件のエッジケースは名前が付いている（重複、権限、空の状態、失敗、不正な入力）。

言葉は平易に。プロンプトへそのまま貼れる行を書きます：例「マネージャーはリクエストを承認または却下でき、リクエスターはステータス更新を受け取る」。

ステップごとに：20分でテンプレートを埋める

タイマーを20分にセットして、「作れるレベルに十分明確」になることを目指します。目的はAIビルダーの推測を排して、毎回同じ選択をさせることです。

まず一文で「誰のためで、どんな成果か？」を答えます。

例：「犬の飼い主向けのモバイルアプリで、散歩と獣医の受診を一箇所で記録する。」

一文で言えないなら、そのアイデアはおそらく2つのアプリに分かれます。

次に「オーナー」「獣医」「家族」など実在の人を意識した1–3のユーザータイプを名前で挙げ、それぞれが最も重視することを一行で書きます。

続いて、以下の形式で3–7個のJTBDを書きます：「When [状況], I want to [行動], so I can [結果].」テスト可能に保ちます。例：「散歩が終わったら距離とメモを記録して傾向を把握できる」等。

次にエンティティと主要フィールドをデータベース用語を避けて定義します。アプリが覚えている「もの」を考えてください。犬アプリなら：Dog（name, age）、Walk（date, duration, notes）、Visit（date, clinic, cost）。画面やジョブで使わないフィールドは除外します。

最後にエッジケースと非ゴールを短く書きます。エッジケースは厄介ですが一般的なもの（「ネットワークなし」「同名の犬が2匹いる」など）。非ゴールはv1で作らないもの（「支払いなし」「ソーシャルフィードなし」）。

各ブロックをビルダーが従えるプロンプトに変換します。構造（目的、ユーザー、ジョブ、エンティティ、エッジケース）を保つと、システムは画面、データ、フローを一致させて生成できます。

AIが実際に従えるユーザーとJTBD

「誰でも使える」と書くと、AIは何を優先するか推測する必要があります。ワンページ仕様では、意図（何をしに来たか）でユーザーを定義してください。意図は画面やデータ、権限に関する明確な選択につながります。

2–4のユーザータイプを挙げ、各々に単一の主要ゴールを与えます。良い例：「注文する顧客」「注文を処理するチームメンバー」「パフォーマンスを確認するマネージャー」。曖昧な例：「18–35歳」「忙しいプロ」や「管理者」（何を管理するかを書いていない場合）です。

JTBDは統一フォーマットで書く

毎回同じ文型を使いましょう：「When..., I want to..., so I can...」。これがアプリを成果に集中させ、AIビルダーに安定した、テスト可能な要件を与えます。

現実的なJTBD例（完了条件付き）：

• クライアント通話を終えたら、次のアクションを一箇所に記録したい。Done: メモ保存、期日設定、リマインダー登録。\n- 新しいリクエストが来たら、迅速に承認または却下して作業を進めたい。Done: 決定記録、依頼者へ通知、ステータス更新。\n- モバイルでは今日のタスクだけを見たい。Done: 今日でフィルタ、ワンタップで完了。\n- ミスをしたら最後の変更を取り消したい。Done: 前の状態に復元、監査ノート作成。

成功基準があると「見た目で良ければOK」という曖昧さが消えます。UIに何を許容するか、バックエンドに何を保存するかが明確になります。

権限については大まかに書く

完全なセキュリティ計画は不要です。誰が何をできるかを平易に書くだけで十分です。

例：「メンバーは自分のアイテムを作成・編集できる。マネージャーは任意のアイテムを編集・ステータス変更できる。オーナーはユーザーと課金を管理できる。」

Planning Modeのようなツールを使う場合、これらのユーザータイプ、JTBD、権限が信頼できる入力になり、AIが余計な役割を発明したり責任を混同したりするのを防ぎます。

エンティティ：専門用語を使わずデータを定義する

エンティティはアプリが追跡する「もの」です。明確に名付ければ、AIビルダーは画面、フォーム、データベースを一致させて生成できます。これがフィールドの食い違いや余計な機能を防ぐ鍵です。

まず主要な名詞をリストアップします。プロジェクト管理ならProject、Task、Comment。ヘアカットの予約ならBooking、Service、Customer、Staffなど。

実際に使う5–10個のフィールドを選ぶ

各エンティティについて、日常語でフィールドを書きます。人がフォームに入力するイメージで。

• Task: title, description, status, due date, priority, assigned to, created by\n- Project: name, goal, start date, end date, owner, archived（yes/no）\n- Invoice: invoice number, client name, amount, currency, due date, paid（yes/no）

一文で説明できないフィールドはv1には不要な場合が多いです。

関係とルールは平易に

エンティティのつながりは短い文で記述します：

「1人のユーザーは多くのプロジェクトを持てる」「各タスクは1つのプロジェクトに属する」「コメントはタスクに属し、1人の作成者がいる」など。

これがあれば一貫した一覧、詳細ページ、フィルタが生成できます。

いくつかデータルールも加えておくと混乱を避けられます：

• 必須：「Taskのtitleは必須」\n- 一意：「Invoice番号はユニーク」\n- 上限：「Descriptionは最大500文字」\n- デフォルト：「新規タスクは status = Open で始まる」

最後に、まだ保存しないものを明確にします。「v1ではファイル添付なし」「スタッフのスケジュールは追跡せず、予約のみ扱う」など。これらの除外がアプリの無駄な膨張を止めます。

画面とフロー：シンプルで予測可能に保つ

最初のバージョンは画面数を小さく安定させると最もうまくいきます。将来必要かもしれないすべての画面を設計すると、AIビルダーは推測を続け、UIが世代ごとにずれていきます。

主要なジョブを完了させるために最低限必要な画面を名前で挙げます。多くのMVPは3–6画面で足ります：

• Sign in\n- List（主要項目）\n- Detail（1件表示）\n- Create/Edit（フォーム）\n- Settings（オプション）

次にハッピーパスを開始から終了まで短い物語で書きます。

例：「ユーザーがサインインし、一覧に着き、検索し、項目を開き、1つのフィールドを編集して保存し、一覧に戻る」

各画面で重要な操作を平易にメモします。すべてを詰め込むのは避け、作成・編集・検索・エクスポート・アーカイブなど、最も重要な2–4アクションを選びます。

また、どこを速くするべきか、どこを「十分良い」で済ますかを決めます。通常「速い」は一覧の表示、検索の応答、保存の即時感。「十分良い」はエクスポートに数秒かかることや基本的な分析、設定の簡素さなどです。

最後に役割とアクセスを一行ずつ書きます：

• Viewer: 閲覧と検索のみ\n- Editor: 作成と編集が可能\n- Admin（必要なら）: ユーザー管理と削除が可能

これで画面と権限が予測可能になり、後の書き直しを減らせます。

書き直しを防ぐエッジケースと非ゴール

ほとんどの書き直しは、ハッピーパスでは問題ないが実際の利用で壊れるケースが原因です。

良いワンページ仕様はエッジケースと非ゴールの余白を用意し、その小さな記述が何時間もの手戻りを防ぎます。

各JTBDについて「何が壊れるか？」を考え、平易に書きます。技術的にではなく曖昧さを排するためです。これでビルダーは毎回同じ判断を下します。

よく書くべきエッジケース：

• 情報の欠落（空のフィールド、住所不明、プロフィール写真なし）\n- 重複（同じユーザーが2回登録、同じアイテムが2回追加）\n- 競合（同じレコードを二人が同時編集、表示中にステータス変更）\n- 制限とタイムアウト（接続遅延、アップロード失敗、リクエストが長時間かかる）\n- 権限問題（閲覧・編集権限のない操作）

そして反応を決めます。具体的に：「操作をブロックして明確なメッセージを表示」「下書きとして保存を許可」「1回再試行して、それでもダメなら再試行ボタンを表示」など。これらのルールはそのまま一貫したプロンプトになります。

プライバシーと安全性の期待も1–2行で書きます。例：「必要最小限のデータを収集する」「ユーザーはアカウントと個人データを削除できる」「プライベート項目はデフォルトで非表示」。UGCがあるなら、v1でも通報やスパム対処を簡潔に定めておきます。

最後に非ゴールを書き、スコープの膨張を止めます。よくある例：

• v1で支払いはなし\n- ソーシャルログインなし（当面はメールのみ）\n- 管理ダッシュボードは基本の一覧と削除だけ\n- オフラインモードなし

例：「イベント作成」のジョブなら、過去日付、タイトル空欄、同じイベント重複の際にどうするかを定義しておくと、次の再構築を防げます。

ワンページ仕様をAIビルダーが実行するプロンプトに変える

最も早く一貫した結果を得る方法は、ワンページの各ブロックを小さく直接的な指示にすることです。ブロックごとにカードのように渡すと、ビルダーは順番に実行できます。

各ブロック（Users, Jobs, Entities, Screens, Edge cases, Non-goals）を名詞と動詞が明確な一つの命令に変えます。「きれいにしろ」などの意見は、「きれい」の定義も付けない限り避けてください。

有効な簡単なプロンプトパターン

二段階のサイクルを使います：まず作らせ、次に仕様に照らして検証します。

1. Build: “Create the data model and API for these Entities: [paste Entities]. Support these roles: [paste Users].”
2. Build: “Create screens and flows exactly for: [paste Screens/Flows].”
3. Validate: “Now check your work against this spec. List any mismatches and fix them: [paste full one-page spec].”

完了定義を短く入れて、ビルダーがいつ止めるか分かるようにします。測定可能に：

• 記載した全ロールが各JTBDをエンドツーエンドで完了できる\n- 各エンティティに対して作成・表示・編集・アーカイブ（仕様にある場合）がある\n- 画面は指定したフローと一致し、フィールド名が一貫している\n- エッジケースは明確なメッセージで扱われる（サイレントフェイルなし）

本当に必要な制約（モバイル優先、管理者のみ、特定のスタックなど）だけを追加してください。プラットフォームが期待する場合はたとえばReactフロントエンド、Goバックエンド、PostgreSQLなどを指定してもよいです。

変更要求は計画を壊さないように

編集したいときはコードではなく仕様ブロックを参照してください。

例：「Entitiesブロックを更新：'Subscription'をフィールドXとYで追加。影響するAPIと画面だけ再生成して検証を走らせて。」

この方法なら計画を安定させつつ安全に反復できます。

現実的な例：アイデアからPlanning Modeプロンプトへ

簡易な美容院向けアポイントリマインダートラッカーを作るとします。目的はフルの予約システムではなく、軽量に予定を保存してリマインダーを送ることです。

以下はワンページ仕様が埋められた例です。

APP: Appointment Reminder Tracker
GOAL: Track appointments and send reminders. No payments, no online booking.

USERS
1) Owner/Staff: creates and manages appointments, wants fewer no-shows.
2) Client: receives reminders, wants an easy way to confirm.

JOBS TO BE DONE (JTBD)
1) As staff, I add an appointment in under 30 seconds.
2) As staff, I see today's schedule in time order.
3) As staff, I mark a client as confirmed or no-show.
4) As staff, I resend a reminder when asked.
5) As a client, I confirm from a message without creating an account.

ENTITIES (DATA)
- Client: id, name, phone, email (optional), notes
- Appointment: id, client_id, service, start_time, duration_min, status (scheduled/confirmed/canceled/no_show)
- Reminder: id, appointment_id, channel (sms/email), send_at, sent_at, result (ok/failed)
- StaffUser: id, name, role (owner/staff)
Relationships: Client 1-to-many Appointment. Appointment 1-to-many Reminder.

EDGE CASES (WHAT BREAKS NAIVE BUILDS)
1) Duplicate client (same phone, different name)
2) Overlapping appointments for the same staff
3) Time zone changes (travel, daylight saving)
4) Client has no email, SMS only
5) Reminder send fails, needs retry and visible status
6) Appointment edited after reminder scheduled
7) Client cancels after confirmation
8) Same-day appointment created 10 minutes before start
9) Phone number format varies (+1, spaces, dashes)
10) Deleting a client with future appointments

これをPlanning Modeに貼れるプロンプト群に変換します。厳格にして、ビルダーが毎回同じ選択をするようにします。

PLANNING MODE PROMPT BUNDLE
1) Build an MVP web app with these entities and relationships exactly as written.
2) Required screens: Login (StaffUser), Today Schedule, Client List, Client Detail, Appointment Create/Edit.
3) Required flows: create client, create appointment for a client, confirm/cancel/no-show, schedule reminders, resend reminder.
4) Constraints: no payments, no public booking page, no client accounts.
5) Edge-case handling: implement validation and UI feedback for all 10 edge cases listed.
6) Output: database schema, API endpoints, and UI behavior notes per screen.

AIで作られたアプリが不整合になるよくある落とし穴

雑な仕様や欲張った機能リストから始まると出力が散らかります。AIビルダーは指示どおりに作りますが、心の中までは読めません。小さな欠落が画面やフローの大きな違いに発展します。

不整合を最も引き起こす罠と、ワンページ仕様がそれをどう直すか：

• 機能だけを書く：「お気に入りを追加」は機能。ジョブは「後で見直すためにアイテムを保存する」。ジョブには意図と成功が含まれるため、ボタンの場所や空状態の文言などをAIが合理的に判断できます。\n- 早すぎる段階で多すぎるエンティティ：最初から12テーブル定義するとロジックが散らかる。出荷できる最小モデルから始める。\n- 権限が抜けている：誰が編集・削除できるかを書かないとビルダーが推測する。単純なルールを書けばデータ漏洩のミスも減ります。\n- 完了基準がない：いつ終わりか分からないと終わらない。例えば「ユーザーが30秒以内でタスクを作れる」などの受け入れチェックを入れます。\n- エッジケースに期待動作がない：ただ「オフライン」や「重複」だけ書いても足りません。期待する振る舞いを明記しましょう（「既に存在するメールならフレンドリーなエラーを出し、サインインを提案する」など）。

もしPlanning ModeをKoder.aiで使っているなら、このような基本がさらに重要です。計画が繰り返し使われるプロンプトの源になるため、ジョブの明確化、小さなデータモデル、明示的な権限、テスト可能な成功ルールが各画面の整合性を保ちます。

簡単なチェックリストと次のステップ

ビルド前にワンページ仕様を素早く点検して、AIに推測させる穴を埋めましょう。推測は書き直しにつながります。

高速な完成度チェック：

• Users：各ユーザータイプに明確なゴールと「誰が何をできるか」（作成、閲覧、編集、削除）がある。\n- Jobs-to-be-done：各ジョブはトリガーから始まり、検証できる明確な成功結果で終わる。\n- Entities：ジョブに出てくる名詞はデータ項目として裏付けられている（名前、ステータス、タイムスタンプなど）。\n- Screens and flows：各ジョブが単純な経路にマップされている（開始画面、主要アクション、確認）。\n- Edge cases：少なくとも5件は書かれている（空状態、無効入力、重複、権限、オフラインや遅延）。

各領域を0–2で評価する簡単なスコアリングも有効：

• 0: 欠落または曖昧\n- 1: 存在するが不明瞭\n- 2: ビルド可能な明確さ

最初の生成前に合計で少なくとも7/10を目指してください。EntitiesやEdge casesが2未満ならそこを先に直します。v1後は各JTBDに対してアプリをチェックし、不一致をマークしてください。変更前にスナップショットを取り、反復で悪化したらロールバックして小さな修正から試します。

Koder.ai (koder.ai) を使っている場合、Planning Modeはこのワンページ仕様を「真実の源」として保ち、変えた部分だけ再生成するのに実用的な場所です。受け入れた変更は同じ日に仕様に反映し、拒否した変更はなぜかを書き残して次のプロンプトの一貫性を保ってください。