AIコーディング
vibe codingで要件をタスクへ変換する方法
ラフなアイデアをタスク分解、受け入れ基準、制約、非目標、実装に使えるAI用プロンプトへ変えるための、実践的なvibe codingの要件整理ワークフローです。
最初のプロンプトをそのままアプリの最初の下書きにしなければ、vibe codingはより効果的になります。最適な出発点は、コードを変更する前にラフなアイデアをタスク、制約、非目標、受け入れ基準へ変える、小さな要件整理のワークフローです。
このガイドでは、アイデアを実装可能なタスク分解へ変換する方法を説明します。AIコーディングエージェントに推測を減らして構築させ、予想外の機能を少なくし、完了の定義を明確にしたいときに活用してください。
このガイドの対象者
- プロダクトのアイデアはあるものの、最初に構築するスコープを明確にする必要がある創業者
- AIコーディングエージェントを使い、機能をレビュー可能なタスクへ分ける開発者
- ディスカバリーのメモを実装用プロンプトへ変えるプロダクトマネージャー
- AIで生成したプロダクトのコンセプトをエンジニアリングへ引き継ぐデザイナー
- 要件を省かず、vibe codingで迅速に進めたいチーム
ステップごとのワークフロー
- 機能名を挙げる前に、ユーザー、成果、実際の課題から始めます。
- アイデアを証明できる最小のワークフローを書きます。
- AIが作り込みすぎないよう、明確にスコープ外とする項目を列挙します。
- フレームワーク、既存コンポーネント、データソース、対応端末、認証、SEO、パフォーマンスへの期待という制約を定義します。
- ワークフローを、1つずつ実装してレビューできるタスクへ変換します。
- エッジケースと失敗状態を含め、各タスクに受け入れ基準を追加します。
- ファイルを編集する前に、曖昧な点を特定するようAIに依頼します。
- データ構造、ルート、UI、操作、検証、確認という依存関係の順にタスクへ優先順位を付けます。
- タスクリストを停止地点を含むプロンプトへ変換します。
- 機能を拡張する前に、元のスコープに照らして最初の差分を確認します。
推奨ツール
要件をタスクへ変換するプロンプトテンプレート
実装を依頼する前に、次のプロンプトを使います。
Convert this rough idea into a vibe coding task breakdown: [idea]. The target user is [user]. The desired outcome is [outcome]. Before writing code, identify scope, non-goals, constraints, data assumptions, user actions, edge cases, and acceptance criteria. Then break the work into small implementation tasks ordered by dependency.
For each task, include what files or modules are likely involved, what must be verified, and what should not be changed. If the request is too broad, reduce it to the smallest useful vertical slice and explain what will wait until later.
タスク分解のチェックリスト
- プロンプトにユーザー、成果、スコープ、非目標、制約、受け入れ基準が定義されていますか？
- 各タスクに実装するべき明確な動作が1つありますか？
- データ構造が明確になる前にAIがUIを構築しないよう、依存関係を順序付けていますか？
- 実装を始める前にエッジケースを含めていますか？
- 重要なタスクごとに検証手順がありますか？
- 無関係な機能を明確に除外していますか？
- レビュアーはタスクが完了したか判断できますか？
よくある間違い
- 曖昧なプロダクトの一文から構築するようAIへ依頼する
- ユーザーワークフローが明確になる前にUIの仕上げから始める
- 非目標を忘れ、追加のルートや機能をAIに作らせる
- レビューするには大きすぎるタスクを書く
- 受け入れ基準を省き、好みで出力を評価する
- 既存のプロジェクトパターンを確認せず、AIにアーキテクチャを選ばせる
- 検証を終えず、最初の画面が動作した時点でスコープを拡大する
実践例
弱いプロンプト：build a client portal with AI.
改善したプロンプト：turn this into implementation tasks for a client portal where a freelancer can share project updates with one client. First version includes a dashboard route, static project cards, a project detail page, and an empty state. Do not add billing, file upload, team accounts, notifications, or real database writes. Define data shape, route structure, UI states, acceptance criteria, and verification before coding.
改善したプロンプトは、ユーザー、成果、スコープ、非目標、制約、受け入れ基準、明確な最初の垂直スライスをAIへ示します。
FAQ
Q: vibe codingを始める前に、要件をどのくらい詳しくするべきですか？ A: ユーザー、成果、スコープ、非目標、制約、受け入れ基準、検証を定義できるだけの詳細を含めます。小さなタスクのたびに完全なプロダクト仕様を書く必要はありません。
Q: AIは最初に確認の質問をするべきですか？ A: スコープ、データ、認証、支払い、プライバシー、ユーザーの役割が不明確な場合は、質問するべきです。短い確認の工程は、生成されたコードを書き直すより低コストです。
Q: 最適なタスクの大きさはどのくらいですか？ A: 優れたタスクは、1つの差分でレビューでき、1つのテストまたは手動の経路で検証できます。無関係なシステムに触れる場合は、タスクを分割してください。
Q: 技術者ではない人もこのワークフローを使えますか？ A: はい。最初のタスクを小さく保ち、慎重な扱いが必要なデータを避け、生成された変更ごとに手動確認を必須にしてください。