Vibe Coding 工作流は何をしますか？

プログラミング初心者が小さなWebプロジェクトをアイデアから確認可能な成果物へと進めるのを支援します。ユーザーが理解できる言語で製品決定を議論し、タスクの規模に応じてプロセスを調整します。このスキルは作業方法であり、フレームワーク、データベース、デプロイプラットフォームを前提としません。

初版はシンプルな公開ページに焦点を当てます。ログイン、管理画面、ファイルアップロード、決済、機密データ処理はこの簡略化された範囲外です。これらの要件が発生した場合は、まず新たに必要な製品、データ、権限、デプロイの決定を指摘し、ユーザー確認後の拡張範囲に基づいて計画し、元のロードマップに静かに混入させないようにします。

入口：まず振り分け、終点と現状を確定する

ユーザーの発言から目標、制約、権限を抽出し、明確な小さな変更、新規プロジェクト、または既存プロジェクトへの多段階機能追加かを判断します。小さな変更はクイックパスを、新規プロジェクトと多段階機能はフルパスを進みます。
フルパスでデリバリ終点がまだ説明されていない場合、ユーザーに次のどれを望むか尋ねます：計画のみ、ローカル実行可能状態、デプロイ準備、または正式リリース。小さな変更の場合は、デリバリ方法がタスクに影響する場合にのみ尋ねます。以降の作業は、ユーザーが選択または明示的に許可した範囲にのみ進めます。
既存プロジェクトの場合は、まずリポジトリのREADME、AGENTS.md（存在する場合）、関連コード、実行方法と確認方法、既存の計画ドキュメント、およびGitの状態を読みます。ユーザーがコミットしていない変更を識別し、それらを上書きしたり、自分のコミットに混入したりしません。空のディレクトリの場合は、まず作成する製品と既存リソースを確認します。
簡潔なサマリーで、既知の事実、未確定の製品決定、現在の提案を示します。優先度として、次に最も影響の大きい質問を1ラウンドに1つだけ行います。複数の決定が密接に関連し、ユーザーがまとめて回答したい場合にのみ質問を統合します。影響の小さい詳細は、明確に注釈された仮定として扱います。

フルパス：まず製品を確定し、次に実装方法を選択する

1. 初版製品を確定する

ターゲットユーザー、解決すべき問題、初版の成功基準と制約を明確にします。ロール別に主要なユーザーストーリーを整理し、P0（最重要）のコアパスを選択し、P1/P2と今回行わないことを記録します。AIが提案するすべての機能を初版に含めないようにします。
ストーリーから、ページ、ナビゲーション、主要な操作、および必要な空、ローディング、成功、失敗の状態を導き出します。ユーザーが実際のシナリオに沿って、サイトへの入り口から目標達成までのステップを説明できるようにします。
「使いやすい」「完全」などの曖昧な目標を、観察可能な行動に変更します。ストーリーや優先順位が競合する場合は、まず競合を指摘します。
簡潔な対応関係を保持します：各P0ストーリーに対応するページまたは動作、開発スライス、検証方法。計画終了前に、すべてのP0ストーリーがスライスに割り当てられているか確認し、ドキュメントを作成しただけでコア機能を実装し忘れることを防ぎます。

2. 技術、データ、デプロイに関するアドバイスを提供する

既存プロジェクトでは、合理的な既存技術と規約を優先的に採用します。新規プロジェクトでは、ユーザーが何に詳しいかをまず聞きます。特に好みがない場合は、初版の要件を満たし、開発、デプロイ、保守が容易な組み合わせを推奨します。推奨理由と主なトレードオフを説明し、ユーザーが比較を求めた場合にのみ代替案を示します。
まず何を保存、更新、共有、またはデバイス間で読み取る必要があるかを尋ね、その後でデータベースの必要性を判断します。固定コンテンツで初版が十分な場合、データベースが不要な理由を明確に記述します。永続化が必要な場合、データエンティティ、関係、読み書きパス、データ喪失の影響、移行方法を説明します。バックエンドやアカウントシステムを勝手に追加しないようにします。
デリバリ終点に基づき、実行環境、データの場所、環境変数、コスト、ドメイン、ビルド方法、ロールバックを事前に考慮します。現在のバージョン、互換性、プラットフォーム機能、価格に関わる場合は公式資料を確認し、根拠と不確実性を明記します。
コスト、データ、アーキテクチャ、または将来のメンテナンスに影響する決定は、ユーザーに確認させます。初心者にフレームワーク名やデータベース製品、テーブルフィールドを先に推測させないようにします。

3. ルート確認後に着手する

作業をユーザーが結果を見られるエンドツーエンドのスライスに分割します。各スライスには、目標、範囲、依存関係、検証動作、確認方法を明確に記述します。最初のスライスでは、最も重要なパスを優先的に動かします。
新規プロジェクトでファイルの変更を開始する前に、製品範囲、主要な技術決定、最初のスライスを提示します。ユーザーがこれらの決定をまだ確認していない場合は確認を取得します。ユーザーが明示的に確認し、作業開始を許可している場合は、繰り返し尋ねずに直接続行します。通常の実装詳細はCodexが処理しますが、範囲、アーキテクチャ、または影響の大きい決定が変更された場合にのみ再調整します。
ユーザーが計画のみを希望する場合、計画またはユーザーが要求した計画ドキュメントで停止します。計画リクエストを自動的にコーディングやリリースにエスカレーションしないようにします。

クイックパス：明確な小さな変更

関連コードとワークスペースの状態を確認し、期待される動作と検証方法を一文で説明し、限定された範囲の変更を完了して検証します。ユーザーが手順や計画のみを要求した場合も、実際の変更を加えた場合の検証方法を説明し、計画中の確認とすでに実行した確認を区別します。要件が実際に複数モジュール、データ構造、アーキテクチャ、またはリリース方法に関わる場合にのみ、フルパスに移行します。小さな変更のために新しい製品ドキュメントやテストフレームワークを作成する必要はありません。

各開発スライスのサイクル

開始前に、現在のスライス、関連ソースコード、プロジェクトの規約を再読し、上書きされるユーザーの変更がないことを確認します。ローカルGitはロールバック可能なチェックポイントとして使用します。まだリポジトリがない場合は、実装開始前にローカルリポジトリを作成します。ユーザーに関係のない変更をコミットせず、リモートリポジトリは必要に応じてセットアップします。
新機能を開発する場合、メインブランチまたはプロジェクトの既存の統合ブランチから機能ブランチを作成し、そのブランチで実装とコミットを行います。まず、ワークスペースにあるユーザーの未コミット変更を処理し、それらを機能ブランチやマージ結果に持ち込まないようにします。明確な小さな修正は、プロジェクトの習慣に応じてブランチを作成するかどうかを決定します。
現在のスライスを実装し、範囲を拡大しません。未決定の製品動作、データに影響する変更、または元の計画から明らかに逸脱する依存関係に遭遇した場合、まず影響を説明し、計画を更新します。
リスクに応じて、既存のテスト、ビルド、起動チェック、またはページ操作による検証を実行します。クリティカルパスには価値のある自動テストを追加できます。簡単な変更には明確な手動手順を使用します。検証に失敗した場合は診断、修正、再チェックを行い、実行していないチェックを合格として報告してはいけません。
実際の結果を現在のスライスと関連するP0ストーリーの検証条件に照らして項目ごとにチェックします。満たされていない条件は未完了としてマークします。変更範囲を確認し、必要なプロジェクトドキュメントとローカルGitチェックポイントを更新します。
機能ブランチの関連する検証とチェックが通過したら、ターゲットのメインブランチの状態を確認してからマージします。競合がある場合や、開発中にメインブランチが変更された場合は、解決後にマージ結果に対して関連チェックを再実行します。失敗した場合はマージ保留状態を維持し、理由を報告し、未検証の結果を完了としてマークしません。このスライスが完了したら、次のスライスに進みます。

プロジェクト記録と復元

確認された重要な決定はプロジェクト docs/ に残します。新規プロジェクトでは通常、docs/PROJECT.md に製品事実、初版範囲、重要な選択を記録し、docs/ROADMAP.md にスライスと進捗を記録します。技術とデータの計画が複雑な場合にのみ、アーキテクチャドキュメントを個別に維持します。個別の機能に独立した検証仕様が必要な場合にのみ、仕様ファイルを追加します。
各事実の主要な記録場所は1つだけに保ちます。既存プロジェクトでは、その既存のドキュメント構造を優先的に更新し、コンテンツが重複する新しいファイルを作成しないようにします。後で作業を再開する場合、まずプロジェクト記録を読み、次に現在のコードと照合します。ドキュメントとコードに矛盾がある場合は差異を指摘します。
ユーザーが要件を変更した場合、影響を受けるストーリー、ページ、データ、技術、またはマイルストーンを説明します。対応する記録と未完了のスライスを更新し、古い決定を静かに上書きしないようにします。

リリースと完了

ユーザーが最初に選択したデリバリ終点に従って完了します。デプロイが必要な場合、まずビルド、環境変数サンプル、データマイグレーション、本番環境チェック、ロールバック手順を準備します。実際のリソースを作成したり、費用が発生したり、正式にリリースする前に、具体的な操作を説明し、対応する確認を取得します。実際のシークレットキーをコード、ドキュメント、またはコミット履歴に書き込まないでください。

デリバリ時には簡潔なチェックリストで、何を完了したか、実行方法、実際に行った検証とその結果、まだある制限と次のステップを説明します。実行または検証できない部分は明確に注釈する必要があります。

Vibe Coding 工作流