AIでアプリ要件を整理する方法｜Vibe Coding前に画面と機能を決める

Vibe Codingの前に、利用者・解決する仕事・最初の版で完了できることを決め、画面、操作、必要なデータ、権限、失敗時の挙動までつないで書きます。要件整理は機能をたくさん並べる作業ではありません。利用者が入口から目的を終えるまでを描き、実装する範囲と後回しの範囲を分けます。AIに要件案や実装計画を作らせても、抜けがない保証にはなりません。計画を人が読み、曖昧な条件を解消してからコード生成へ進みます。

最初にJobを一文で定義する

「誰が、どんな状況で、何を終えられるアプリか」を一文にします。例えば「営業担当が訪問後に顧客メモを登録し、次回対応日をチームで確認できる」です。「AIで営業を効率化する」では対象者も完了状態も広すぎます。一文にできないときは、機能を増やす前に利用者と場面を絞ります。

次に、利用者が完了したと判定できる状態を決めます。メモを入力できるだけでなく、保存後に再表示される、誰が閲覧できるかが明確、次回対応日を一覧で見つけられる、など観察できる条件にします。「使いやすい」「便利」は受け入れ条件として曖昧です。

要件メモを埋める順番

1. 利用者とJob：誰が、どの頻度で、何を完了するか。

2. 完了条件：画面上の成功状態。保存や通知など画面外の結果も含める。

3. MVP：最初の版に必須の行動を一つから三つに絞る。

4. 画面と操作：各画面で見る情報、入力、押した後の変化。

5. データ：保存する項目、必須・任意、作成者、更新時点、関連データ。

6. 権限：未ログイン、一般利用者、管理者など、役割別に許される操作。

7. 例外：空データ、入力不備、通信失敗、権限不足、重複登録、上限到達。

8. 非機能条件：個人情報、応答時間、バックアップ、運用担当。

9. 対象外：初回に入れない機能と再検討条件。

画面一覧だけでは処理の抜けが残ります。画面を列挙したら入口から完了までを矢印でつなぎます。営業メモなら「ログイン→顧客一覧→顧客選択→メモ入力→保存→保存結果を確認→次回対応日を一覧で確認」です。戻る、保存に失敗する、権限のない人がURLを直接開く、といった分岐も必要なものだけ加えます。

操作をInput・処理・Outputへ分ける

メモ保存なら、入力は顧客ID・本文・次回日付、処理は必須項目と権限の確認、出力は保存済みメモと成功表示です。失敗時は入力を消すのか保持するのか、再送で二重登録にならないかを決めます。ここを曖昧にすると、見た目は完成してもデータが保存されない、別の利用者から見える、失敗後に入力が消える問題が残ります。

利用者の流れを例に確認します。顧客を選び、メモを入力し、「保存」を押した後、成功表示だけでなく一覧に同じ内容が出ることを受け入れ条件にします。通信失敗なら、入力内容を保持し、再試行で二重登録しないこと。権限外なら、画面を隠すだけでなくAPIも拒否すること。画面上の導線とデータ側の条件を両方定義します。

MVPと後回し機能を切り分ける

機能候補は「Job完了に必須」「運用上必要」「あると便利」に分けます。最初の版に入れるのは、前二つのうちリリースを成立させるものです。営業メモなら登録・閲覧・権限確認はMVP候補です。自動要約、通知、分析dashboardは、なくてもメモを共有できるなら後回し候補です。

後回しにした機能には理由と再検討条件を残します。「通知は使わない」ではなく「初回は通知なし。週次確認が定着せず、確認漏れが起きたら通知を検討」とします。納期だけを理由にsecurityやデータ保持を対象外にしてはいけません。対象外と未決を混同せず、誰が決めるかも記録します。

再利用できる要件シート

・利用者：

・利用場面：

・完了するJob：

・完了を確認できる状態：

・MVPで実装する操作：

・対象外にする機能と再検討条件：

・画面名／見る情報／利用者の操作：

・画面遷移と分岐：

・保存データ／必須項目／任意項目：

・閲覧・編集できる役割：

・空データ時：

・入力不備時：

・通信失敗時：

・再送時の重複防止：

・個人情報・機密情報の扱い：

・リリース後の運用担当：

・受け入れテスト：

・未決事項／決める人／期限：

埋められない欄は推測で埋めず「未決」とします。これだけでも、利用者が誰か、最初の版で何を終えられるか、何が決まっていないかを共有できます。

受け入れ条件をテストへ変える

「次回日付を設定できる」を、確認できる動作にします。

・日付を入力して保存すると、詳細と一覧の両方に同じ日付が表示される。

・未入力を許す仕様なら、保存でき、一覧で未設定と分かる。

・日付形式が不正なら保存せず、入力値を保持して修正方法を示す。

・権限のない利用者は、画面とAPIの両方で拒否される。

・通信が切れたときは内容を保持し、再送で同じメモを重複登録しない。

画面の完成条件も見た目だけで決めません。読み込み中、空、成功、失敗の状態が必要な画面にあるか確認します。データが存在する状態しか作らないと、初回利用者や失敗時に操作が止まります。各条件に、誰がどう確認するかを紐づけます。

AIへ渡す実装前の依頼

要件メモを作ったら、AIにはすぐコードを書かせず、抜けと矛盾を探させます。

「下記要件を読み、まだコードは変更しないでください。利用者のJob、完了条件、画面遷移、データ、権限、失敗状態、対象外機能の矛盾と不足を列挙してください。各指摘に、影響する操作と、決めない場合の失敗を付けてください。推測は事実と分け、要件を満たす最小の画面・API・data変更案を示してください。未決事項は質問にしてください。」

Cursor Plan Modeは、複数fileに触れる複雑な作業などでcodebaseを調べ、質問し、確認・編集できる計画を作る機能です。計画の完全性を保証するものではないため、画面、data、例外、scopeを人が確認します。小さな変更なら既存の開発手順に沿って直接依頼できます。いずれの場合も、実装後はdiffと該当testを確認します。

計画レビューで見る点

・要件にない機能を追加していないか。

・画面からAPI、保存先まで流れがつながっているか。

・認証だけでなく、各dataへの閲覧・編集権限を確認しているか。

・空・失敗・再送の状態が必要な場所にあるか。

・削除、復元、移行、logの扱いが決まっているか。

・testが完了条件を確かめているか。

・未決事項を仮定で埋めていないか。

AIの提案が要件からずれていたら、コード生成の前に要件を直します。実装後に権限や保存方式を初めて決めると、画面とdata modelを作り直す場合があります。

SecurityとPrivacyの確認

名前、メール、顧客記録、決済、健康情報を扱うなら、必要最小限の保存、閲覧範囲、保持期間、削除方法を具体化します。秘密情報をコード、画面、AIへのpromptに貼り付けないようにします。認証済みであることと、対象データを見てよいことは別です。開発用sampleへ実在顧客の情報をコピーしないことも要件に含めます。

AIの判断だけで法令適合や安全性を確定できません。法務・security判断が必要なら担当者を決め、未確認のまま公開しない条件を記録します。リスクが高いdataを扱う場合、要件レビューに責任者を含めます。

要件が曖昧なときの判断

実装へ進むかは三点で判断できます。

・利用者は誰か、一文で説明できる。

・最初の版で完了できる操作が決まっている。

・成功・失敗・権限の確認方法をtestとして書ける。

欠けた項目があれば、その箇所だけ質問に戻します。目的と受け入れ条件が明確なら、将来機能が未決でもMVPの範囲を区切って進められます。要件表を完成させることが目的になり、実装に不要な説明を増やさないようにします。

AIものさしの判断

要件メモの完成は長い仕様書を書くことではなく、主要な利用者操作を実装前に検証できる状態にすることです。画面、data、権限、失敗の関係が一貫し、受け入れ条件を人が確認できるなら、MVP計画を依頼します。計画はそのまま採用せず、利用者のJobとtest条件へ照らしてから実装へ進んでください。

優先順位を決める簡易表

要件が多い場合は、各候補を「Jobを止めるか」「発生頻度」「失敗時の影響」「代替手段」の四点で見ます。ログイン後に主要操作へ進めない、保存内容が消える、誤った利用者へ情報が見える、といった項目は優先度を上げます。一方、色やanimationの好みは、主要操作が完了した後に評価できます。点数で機械的に決めるより、優先理由を一行残すほうが、後から範囲を見直しやすくなります。

例えば、保存失敗時に入力が消える問題は、頻度が低くても利用者が同じ作業をやり直すため、MVPの受け入れ条件に入れる価値があります。プロフィール画像の切り抜きは、Job完了を妨げず代替表示があるなら後回しにできます。どちらを後回しにする場合も、リリース後に確認する指標や問い合わせの種類を決めておくと、延期が放置になりません。

要件レビューを終える前に、利用者の流れを初めから一度たどり、画面名ではなく行動と結果を読み上げます。各操作に入力、成功後の状態、失敗時の回復方法があるか、利用者に必要な案内があるかを確認してください。最後に、MVPの対象外一覧と未決事項を分け、未決が主要Jobを止めるなら実装開始条件として残します。

レビュー記録の残し方

要件変更の理由、決めた人、影響する画面、確認するtestを短く記録します。変更を重ねても、AIが作った案と人が確定した条件を区別できます。 未確定案を実装済み仕様のように扱わないためです。 担当と期限も添えます。 読み返せる形で残します。 実装中に条件が変われば更新します。 変更を追跡します。 仕様を追加したら、関連する受け入れ条件も同じ変更記録で更新し、古い要件を参照して実装しないようにします。