2026年1月06日·1 分
AIで構築するアプリの一貫性を保つワンページ仕様テンプレート
ワンページのアプリ仕様テンプレートを使って、あいまいなアイデアをPlanning Modeで使う明確なプロンプトに変えます。ユーザー、Jobs-to-be-done、エンティティ、エッジケースを網羅します。
ワンページのアプリ仕様テンプレートを使って、あいまいなアイデアをPlanning Modeで使う明確なプロンプトに変えます。ユーザー、Jobs-to-be-done、エンティティ、エッジケースを網羅します。
あいまいなアイデアは妄想には向いていますが、作るには粗いままです。
「習慣を追跡するアプリを作って」とだけAIビルダーに頼むと、AIはあなたの意図を推測するしかありません。その推測はプロンプトごとに変わり、結果としてアプリも変わります。画面が噛み合わなかったり、データ名が途中で変わったり、機能が出現・消失・別の形で再登場したりします。
この不整合はだいたい次のような箇所に現れます：
「Planning Mode」は、ビルドの前に一旦立ち止まるシンプルな手法です。AIが勝手に決める代わりに、あなたが決定を書き出します。目的は一貫性：UI、バックエンド、データベースが従う共通の選択を作ることです。
目標は完璧ではなく、反復しやすいビルドを作ることです。後で方針を変えるなら、小さな仕様を更新して同じ論理で再構築すればいい。だからワンページの仕様テンプレートが役に立ちます。長いPRDでも図の山でもなく、誰が使い、何を達成し、どんなデータがあって、どのエッジケースや非ゴールがv1を爆発させないかを答える1ページです。
例：「予約アプリ」が単一のサロンオーナー向けかマーケットプレイスか、顧客が再調整・キャンセル・ノーショーできるかを決めればぐっと明確になります。
ワンページ仕様テンプレートは、あいまいなアイデアを明確な指示に変える短いメモです。製品全体を設計するのではなく、AIビルダーが毎回同じ選択をするのに十分な構造を与えます。
ページは4つのブロックです。1ページに収まらないなら、最初のビルドに機能が多すぎます。
ワンページにすることで有益な制約が生まれます。主要ユーザーを一つに絞り、最小の成功フローを定義し、「全部対応する」といった曖昧な約束を避けるよう促します。これらの制約がAIビルドの画面ずれを防ぎます。
「十分に良い」詳細は単純でテスト可能な記述です。誰かが読んで「これが動いているとどう分かる？」と問えるなら、適切なレベルです。
目安：
言葉は平易に。プロンプトへそのまま貼れる行を書きます：例「マネージャーはリクエストを承認または却下でき、リクエスターはステータス更新を受け取る」。
タイマーを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は何を優先するか推測する必要があります。ワンページ仕様では、意図（何をしに来たか）でユーザーを定義してください。意図は画面やデータ、権限に関する明確な選択につながります。
2–4のユーザータイプを挙げ、各々に単一の主要ゴールを与えます。良い例：「注文する顧客」「注文を処理するチームメンバー」「パフォーマンスを確認するマネージャー」。曖昧な例：「18–35歳」「忙しいプロ」や「管理者」（何を管理するかを書いていない場合）です。
毎回同じ文型を使いましょう：「When..., I want to..., so I can...」。これがアプリを成果に集中させ、AIビルダーに安定した、テスト可能な要件を与えます。
現実的なJTBD例（完了条件付き）：
成功基準があると「見た目で良ければOK」という曖昧さが消えます。UIに何を許容するか、バックエンドに何を保存するかが明確になります。
完全なセキュリティ計画は不要です。誰が何をできるかを平易に書くだけで十分です。
例：「メンバーは自分のアイテムを作成・編集できる。マネージャーは任意のアイテムを編集・ステータス変更できる。オーナーはユーザーと課金を管理できる。」
Planning Modeのようなツールを使う場合、これらのユーザータイプ、JTBD、権限が信頼できる入力になり、AIが余計な役割を発明したり責任を混同したりするのを防ぎます。
エンティティはアプリが追跡する「もの」です。明確に名付ければ、AIビルダーは画面、フォーム、データベースを一致させて生成できます。これがフィールドの食い違いや余計な機能を防ぐ鍵です。
まず主要な名詞をリストアップします。プロジェクト管理ならProject、Task、Comment。ヘアカットの予約ならBooking、Service、Customer、Staffなど。
各エンティティについて、日常語でフィールドを書きます。人がフォームに入力するイメージで。
一文で説明できないフィールドはv1には不要な場合が多いです。
エンティティのつながりは短い文で記述します：
「1人のユーザーは多くのプロジェクトを持てる」「各タスクは1つのプロジェクトに属する」「コメントはタスクに属し、1人の作成者がいる」など。
これがあれば一貫した一覧、詳細ページ、フィルタが生成できます。
いくつかデータルールも加えておくと混乱を避けられます：
最後に、まだ保存しないものを明確にします。「v1ではファイル添付なし」「スタッフのスケジュールは追跡せず、予約のみ扱う」など。これらの除外がアプリの無駄な膨張を止めます。
最初のバージョンは画面数を小さく安定させると最もうまくいきます。将来必要かもしれないすべての画面を設計すると、AIビルダーは推測を続け、UIが世代ごとにずれていきます。
主要なジョブを完了させるために最低限必要な画面を名前で挙げます。多くのMVPは3–6画面で足ります：
次にハッピーパスを開始から終了まで短い物語で書きます。
例：「ユーザーがサインインし、一覧に着き、検索し、項目を開き、1つのフィールドを編集して保存し、一覧に戻る」
各画面で重要な操作を平易にメモします。すべてを詰め込むのは避け、作成・編集・検索・エクスポート・アーカイブなど、最も重要な2–4アクションを選びます。
また、どこを速くするべきか、どこを「十分良い」で済ますかを決めます。通常「速い」は一覧の表示、検索の応答、保存の即時感。「十分良い」はエクスポートに数秒かかることや基本的な分析、設定の簡素さなどです。
最後に役割とアクセスを一行ずつ書きます：
これで画面と権限が予測可能になり、後の書き直しを減らせます。
ほとんどの書き直しは、ハッピーパスでは問題ないが実際の利用で壊れるケースが原因です。
良いワンページ仕様はエッジケースと非ゴールの余白を用意し、その小さな記述が何時間もの手戻りを防ぎます。
各JTBDについて「何が壊れるか？」を考え、平易に書きます。技術的にではなく曖昧さを排するためです。これでビルダーは毎回同じ判断を下します。
よく書くべきエッジケース：
そして反応を決めます。具体的に：「操作をブロックして明確なメッセージを表示」「下書きとして保存を許可」「1回再試行して、それでもダメなら再試行ボタンを表示」など。これらのルールはそのまま一貫したプロンプトになります。
プライバシーと安全性の期待も1–2行で書きます。例：「必要最小限のデータを収集する」「ユーザーはアカウントと個人データを削除できる」「プライベート項目はデフォルトで非表示」。UGCがあるなら、v1でも通報やスパム対処を簡潔に定めておきます。
最後に非ゴールを書き、スコープの膨張を止めます。よくある例：
例：「イベント作成」のジョブなら、過去日付、タイトル空欄、同じイベント重複の際にどうするかを定義しておくと、次の再構築を防げます。
最も早く一貫した結果を得る方法は、ワンページの各ブロックを小さく直接的な指示にすることです。ブロックごとにカードのように渡すと、ビルダーは順番に実行できます。
各ブロック（Users, Jobs, Entities, Screens, Edge cases, Non-goals）を名詞と動詞が明確な一つの命令に変えます。「きれいにしろ」などの意見は、「きれい」の定義も付けない限り避けてください。
二段階のサイクルを使います：まず作らせ、次に仕様に照らして検証します。
完了定義を短く入れて、ビルダーがいつ止めるか分かるようにします。測定可能に：
本当に必要な制約（モバイル優先、管理者のみ、特定のスタックなど）だけを追加してください。プラットフォームが期待する場合はたとえばReactフロントエンド、Goバックエンド、PostgreSQLなどを指定してもよいです。
編集したいときはコードではなく仕様ブロックを参照してください。
例：「Entitiesブロックを更新：'Subscription'をフィールドXとYで追加。影響するAPIと画面だけ再生成して検証を走らせて。」
この方法なら計画を安定させつつ安全に反復できます。
簡易な美容院向けアポイントリマインダートラッカーを作るとします。目的はフルの予約システムではなく、軽量に予定を保存してリマインダーを送ることです。
以下はワンページ仕様が埋められた例です。
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ビルダーは指示どおりに作りますが、心の中までは読めません。小さな欠落が画面やフローの大きな違いに発展します。
不整合を最も引き起こす罠と、ワンページ仕様がそれをどう直すか：
もしPlanning ModeをKoder.aiで使っているなら、このような基本がさらに重要です。計画が繰り返し使われるプロンプトの源になるため、ジョブの明確化、小さなデータモデル、明示的な権限、テスト可能な成功ルールが各画面の整合性を保ちます。
ビルド前にワンページ仕様を素早く点検して、AIに推測させる穴を埋めましょう。推測は書き直しにつながります。
高速な完成度チェック：
各領域を0–2で評価する簡単なスコアリングも有効：
最初の生成前に合計で少なくとも7/10を目指してください。EntitiesやEdge casesが2未満ならそこを先に直します。v1後は各JTBDに対してアプリをチェックし、不一致をマークしてください。変更前にスナップショットを取り、反復で悪化したらロールバックして小さな修正から試します。
Koder.ai (koder.ai) を使っている場合、Planning Modeはこのワンページ仕様を「真実の源」として保ち、変えた部分だけ再生成するのに実用的な場所です。受け入れた変更は同じ日に仕様に反映し、拒否した変更はなぜかを書き残して次のプロンプトの一貫性を保ってください。
Planning Modeは、画面やコードを生成する前に重要な決定を書き出す短い「立ち止まり」です。目的は一貫性です：UI、バックエンド、データベースで同じユーザー、フロー、データ名を使い、毎回の推測で再構築しなくて済むようにします。
一文で表すゴールを書き、次に4つのブロックを埋めます：
これがワンページに収まらないなら、v1の機能を絞ってください。
実用的で意図に基づいた定義にします。いくつかのユーザータイプを挙げ、それぞれが何を達成したいかを書きます。
例：「Owner/Staff が予約を作る」は「Admin」より明確です。一行で役割を説明できない場合、その役割は曖昧すぎます。
厳密なパターンを使って各ジョブをテスト可能にします：
さらに、どのデータが保存されるか／表示されるかの完了定義を短く付けます。これでビルダーが余計なステップやランダムな画面を作るのを防げます。
MVPでは「アプリが覚えておくもの」を平易な言葉で列挙し、各項目に実際に画面で使う3～7個のフィールドを書きます。
例：Appointment: start time, duration, status, service, client。ジョブや画面で使わないフィールドはv1では除外します。
関係はシンプルな文で書きます：
必要最低限のルールも加えます（必須、ユニーク、デフォルトなど）。これでリストやフォーム、フィルタが一貫します。
最初のバージョンで必要なのは小さく安定した画面セットです。将来のすべての画面を設計しようとすると、AIビルダーは推測を続けてUIがずれてしまいます。
多くのMVPは3～6画面で完結します：
各画面について主要な操作2～4つを決め、ハッピーパスを短いストーリーで書いてください。
現実の利用でハッピーパスが壊れる場面を想定して上位5～10件を書きます。一般的な例：
それぞれに対して「ブロックしてメッセージを表示」「下書きとして保存」「1回再試行して失敗したらボタン表示」など具体的な対応を書きます。
各ブロックをビルダーが実行できる短い指示に変換します。ブロックごとにカードのように順に渡すと、曖昧な大きなプロンプトより一貫した結果が得られます。
簡単なシーケンス例：
完了条件を測定可能にしておくと、いつ止めるかが明確になります。
仕様を先に更新し、影響のある部分だけを再生成してください。
例：「EntitiesブロックにSubscriptionを追加してフィールドX/Yを追加。影響するAPIと画面だけを再生成して検証する。」仕様を唯一の真実として保つことで、散在する不整合を避けられます。