- AIビルダーで新しいアプリ、または新しい主要機能を作り始めようとしている。
- まだ話したことがなくても、その課題を抱える人を1人挙げられる。
- 誰も求めていない機能をビルダーが追加するのを止めたい。
- あちこちクリックして確かめるのではなく、各ビルドを判断するチェックリストがほしい。
ユースケース日本語
アイデアから、すぐにビルドできるブリーフへ
AIビルダーが従え、実際のユーザーが試せる1ページのPRDを書きましょう。
AIビルダーはプロンプトが示唆することを実行し、空白を推測で埋めます。ログイン画面、ダッシュボード、支払いページなどです。短いPRDは、アプリが誰のためのものか、何をしなければならないか、何をしてはならないか、そして各部分が動くことをどう確かめるかを示します。
適用の条件
ビルダーが推測を続けるなら、PRDを使いましょう。
1行のプロンプトはデモには十分です。ほかの誰かにアプリを使ってもらいたくなったら、ビルダーはコードを変更するたびに、同じいくつかの判断を必要とします。
- ステークホルダーの承認を伴う、完全なエンタープライズ向け要件定義書が必要である。
- 自分の判断なしにPRDを書いてくれるジェネレーターがほしい。
- PRDによって人がアプリを求めていることが証明されると期待している。それができるのは人だけである。
- セキュリティレビュー、コンプライアンスの承認、本番運用準備の認証が必要である。
最小限の完結したワークフロー
1ページに6つの判断を書き、1回に1つずつビルドする。
下のテンプレートをプレーンな Markdown ファイルに記入します。各ステップで、ビルダーが本来推測するはずだったことを1つずつ取り除きます。
- 01
最初のユーザーときっかけを決める
具体的な人物1人と、その人がアプリを必要とする瞬間を書きます。例：「冷蔵庫を1つ共有するルームメイト。誰かが買い出しの代金を払った直後」。1人も挙げられない場合は、ビルドする前に人と話しましょう。
- 02
1つのジョブと最大3つの必須項目を書く
ジョブを1文で述べ、そのジョブのためにアプリが必ず備えるべき動作を最大3つ挙げます。それ以外はすべて後回しです。3つは上限であって、目標ではありません。
- 03
非目標を明示的に挙げる
アカウント、支払い、通知、管理画面、ダッシュボードなど、最初のバージョンに含めてはならないものを挙げます。ビルダーはこれらを既定で追加しがちです。非目標を書いておけば、それを却下する根拠になります。
- 04
データと画面を平易な言葉で説明する
アプリが保存するいくつかのものと、ユーザーが移動する画面を挙げます。リスト、アイテム、誰が払ったか、金額といった平易な名詞で十分です。理由がない限り、フレームワークの選択はビルダーに任せます。
- 05
すべての必須項目にチェックを付ける
動いたときに何が見えるかを書きます。例：「1台目のスマートフォンで追加したアイテムが、更新後に2台目のスマートフォンに表示される」。速い、直感的、モダンなど、確認できない言葉は避けましょう。
- 06
ツールが読む場所に置き、1つずつビルドする
Lovable のナレッジファイルに貼り付けるか、PRD.md として保存して CLAUDE.md または AGENTS.md から参照します。ビルドの前に計画を立て、必須項目を1つ実装し、そのチェックを実行し、判断を変えたらPRDを更新するようビルダーに依頼します。
確認できるコントロール
承認カードの例：必須項目1のみをビルドする
これは説明用のタスクカードであり、顧客の実績や完了した実験を示すものではありません。
- 目的
- 架空の Splitlist PRD の必須項目1として、2人のルームメイトが別々のスマートフォンから1つの共有買い物リストにアイテムを追加できるようにする。
- 行動
- 提供されたプロジェクトで必須項目1を実装する。変更内容と各受け入れチェックの結果をレビュー用に返す。
- 対象
- 1つのプロジェクトとそのリポジトリ。ログインプロバイダー、支払い、通知、残り2つの必須項目は対象外。
- 受け入れ基準
- スマートフォンAで追加したアイテムが、更新後にスマートフォンBに表示される。空のアイテムは拒否される。リストが横スクロールなしで390pxの画面に収まる。ほかの画面は変更されない。
- 停止条件
- データモデルにユーザーアカウント（PRDで非目標として挙げている）が必要になる場合、またはチェックをサンドボックス内で実行できない場合は停止する。
修正却下この範囲で承認
コピーして使える1ページのPRD
8つの見出し。1ページ。すべての行が確認可能。
説明用の例：Splitlist は架空の共有買い物リストアプリです。すべての行を自分の判断に置き換えてください。実際の人に確認していないことは、仮定として明記しましょう。
- 最初のユーザーときっかけ
- 冷蔵庫を1つ共有するルームメイト。そのうち1人が買い出しの代金を払った直後。仮定：すでにメッセージで費用を分けている。
- 1つのジョブ
- スプレッドシートを使わずに、買い出しのたびに誰がいくら払うべきかを把握する。
- 必須項目（最大3つ）
- 1. どのスマートフォンからでも1つの共有リストにアイテムを追加する。2. 1回の買い出しを、1人が合計額を払ったものとして記録する。3. 各人の累計残高を表示する。
- バージョン1の非目標
- アカウントやパスワードなし（非公開リンクで共有）、アプリ内の支払いなし、通知なし、レシートのスキャンなし、管理画面なし。
- データ
- リスト、アイテム（名前、追加した人）、買い出し（払った人、合計、日付）、メンバー（表示名）。残高は保存せず計算する。
- 画面
- 共有リスト、支払い済みにするフォーム、残高。幅390pxでモバイルファースト。
- 受け入れチェック
- 一方のスマートフォンで追加したアイテムが、更新後にもう一方に表示される。メンバー2人の間でAが払った$42の買い出しについて、BがAに$21の借りとして表示される。空のアイテムとマイナスの合計は拒否される。
- 最初のユーザーによるテスト
- 実際のルームメイト2人が、1回の買い出しで使う。合格基準：2人ともあなたに聞かずに誰がいくら払うべきかを言える。何に戸惑ったかを記録する。
判断スコアカード
PRDは、何を防ぎ、何を確認可能にするかで判断しましょう。
良いPRDは短く、テスト可能です。以下のシグナルで、PRDが役目を果たしているかどうかがわかります。
1ページ
PRD全体が1画面または1ページに収まり、1人のユーザーと1つのジョブを示している。
仮定の明記
実際の人に確認していないことは、すべて仮定として表示されている。
チェック合格
各必須項目に自分で実行できるチェックがあり、最新のビルドがそれに合格している。
範囲の維持
非目標リストにあるものはビルドに現れなかったか、あなたが取り除いた。
最初のユーザーの完了
実際の人が、あなたの手助けなしにジョブを完了した。自分自身へのデモは数えない。
更新済み
判断を変えたとき、同じセッション内でPRDも変更された。
調査の証拠フォーマット
各ツールがプロジェクトの背景情報を読む場所
ドキュメントは2026年10月21日に確認しました。ツールの背景情報に関する機能は頻繁に変わります。頼る前に、現在の場所を確認してください。
Lovable のナレッジファイルは、Lovable が扱う背景情報に常に含まれる。ドキュメントによると、良いナレッジファイルは wiki ではなく1ページのブリーフのように読めるもので、ちょっとした調整より大きな作業には Plan モードが推奨されている。
1ページのPRDをナレッジファイルに貼り付け、各必須項目の前に計画を立てましょう。
Lovable ベストプラクティスClaude Code は、すべてのセッションの開始時に CLAUDE.md、またはリポジトリの AGENTS.md を背景情報として読み込み、具体的で簡潔な指示ほど一貫して守られると説明している。
PRDを短く保ち、CLAUDE.md または AGENTS.md から参照して、すべてのセッションがPRDから始まるようにしましょう。
Claude Code メモリのドキュメントCursor はプロジェクトのルートとサブディレクトリにある AGENTS.md をサポートしており、ルールのドキュメントでは、ファイルの内容をコピーするのではなく参照するよう勧めている。
PRD.md を1つのファイルとして保ち、AGENTS.md またはプロジェクトルールからそれを参照しましょう。
Cursor ルールのドキュメントSoloop は、アイデアまたは既存のコードからサンドボックス内でビルドし、プロダクト、ターゲットユーザー、課題、優位性、現在の重点を記載した編集可能な Product Doc を保持する。PRDジェネレーターについては記載されていない。
テンプレートを単独で使うか、Build タスクを承認する前に、チャットで下書きを手伝うよう Soloop に依頼しましょう。
Soloop プロダクトマニュアル · 2026年9月24日更新現在のプロダクトの範囲
いま実際に動くものを前提に計画する。
これはテンプレートとワークフローであり、PRDジェネレーターではありません。明確なPRDはビルドを確認しやすくしますが、誰かがアプリを求めていることを証明するものではありません。Splitlist の例は架空のものです。
テンプレート
無料8つの見出しを任意の Markdown ファイルにコピーしてください。登録は不要です。
チャットでの下書き
提供中アイデアを説明し、仮定に疑問を投げかけてレビュー用のPRDを下書きするよう Soloop に依頼できます。
Product Doc
提供中プロダクト、ターゲットユーザー、課題、現在の重点を、Soloop の編集可能な Product Doc に保持できます。
Build
承認後に提供Soloop は、アイデアまたは提供されたコードからサンドボックス内でビルドし、変更内容とチェック結果をレビュー用に返せます。
PRDジェネレーター
機能ではありませんワンクリックのPRDジェネレーターはありません。PRDの中の判断はあなたのものです。
ほかのビルダー
あなたのプロジェクトSoloop は Lovable、Cursor、Claude Code のプロジェクトを編集しません。PRDはご自身で貼り付けてください。
ループを続ける
判断が変わったら、次のリソースを使う。
よくある質問
次の一手の前に確認したいこと。
バイブコーディング用のPRDには何を含めるべきですか？
最初のユーザーときっかけ、1つのジョブ、最大3つの必須の動作、非目標、データ、画面、必須項目ごとの受け入れチェック、最初のユーザーによるテストです。これだけあれば、AIビルダーは推測をやめ、あなたは各ビルドを判断できます。
Lovable、Cursor、Claude Code では、PRDをどこに置けばよいですか？
Lovable では、プロジェクトのナレッジファイルに貼り付けます。Claude Code では、PRD.md を保存して CLAUDE.md または AGENTS.md から参照します。Cursor では、AGENTS.md またはプロジェクトルールから参照します。これらの機能は変わるため、各ツールの最新ドキュメントを確認してください。
バイブコーディングのPRDはどのくらいの長さにすべきですか？
1ページです。Lovable のドキュメントは良いナレッジファイルを1ページのブリーフと説明しており、Claude Code のドキュメントは簡潔な指示ほど一貫して守られるとしています。詳細は背景説明ではなく、受け入れチェックに書きましょう。
Soloop はPRDを書いて、アプリをビルドしてくれますか？
Soloop は、チャットでの下書きを手伝い、要点を Product Doc に保持し、あなたが Build タスクを承認した後に、アイデアからサンドボックス内でビルドできます。ワンクリックのPRDジェネレーターはなく、ほかのビルダー内のプロジェクトは編集しません。
いまあるプロダクトを持ってきてください
アイデアと、1人の人物を持ってきてください。
このブリーフをコピーし、角括弧の部分を置き換えてください。「プロジェクトから始める」を選ぶと Soloop のホームページが開くので、そこにブリーフを貼り付けてください。内容は自動では引き継がれません。完成したPRDは、ほかのどのビルダーにも貼り付けられます。
［きっかけ］の状況にある［具体的な人物］のために、［アプリのアイデア］を作りたいです。次の項目を含む1ページのPRDを書くのを手伝ってください：最初のユーザーときっかけ、1つのジョブ、最大3つの必須の動作、非目標、データ、画面、必須項目ごとの受け入れチェック、最初のユーザーによるテスト。まず確認のための質問をし、私がまだ確認していないことはすべて仮定として明記してください。私がPRDを承認するまで、Build タスクを開始しないでください。プロジェクトから始める