Vibe Codingとは、生成AI (LLM) を単なるコードジェネレーターとしてではなく、アイデアの壁打ち相手、知識の整理係、そして実装パートナーとして活用し、人間とAIが協調しながら開発を進める手法です。
この標準は、プロンプトを体系的にファイル化し管理することで、AIが持つコンテキストの限界を超え、開発のどの段階においても一貫性、品質、効率を最大化することを目的とします。
| 役割 | 人間（開発者）の責任 | AI（LLM）の責任 |
|---|---|---|
| 戦略と判断 | プロジェクトのビジョン、技術選定、アーキテクチャの最終判断、法的・倫理的チェック。 | 計画と設計の提案、技術的選択肢の提示。 |
| コンテキスト管理 | ルール、アイデア、計画をファイルとして作成・更新・参照する（プロンプトマネジメント）。 | 参照されたファイルに基づき、常に最新かつ一貫したコンテキストを維持し、タスクを実行する。 |
| 品質保証 | AIが生成したコードの最終レビュー、重要なセキュリティ/性能検証。 | 要求に基づくコード生成、対応する単体テストコードの作成、ルールの遵守。 |
プロンプトは、フェーズに依存しない共通知識と、フェーズごとの変動履歴の2つに大別し、以下の階層構造で管理します。
├── prompts/
│ ├── specifications/ # [フェーズ非依存] プロジェクト全体の最新仕様書
│ ├── rules/ # [フェーズ非依存] プロジェクト全体で共通する開発ルール
│ │ ├── Vibe-Coding-Standard.md # (このドキュメント自体 - メタ・ルール)
│ │ └── project-coding-rules.md # (プロジェクト固有のコーディング規約など - 実務ルール)
│ ├── refs/ # [フェーズ非依存] プロジェクト全体で共通の参考資料
│ │ └── global-apis.md # 例: API定義
│ └── phases/ # [フェーズ依存] 開発フェーズごとの履歴とプロンプト
│ └── {nnn}-{phase_name}/ # 例: 001-prototype (アクティブな開発フェーズ)
│ ├── ideas/ # アイデア、要件定義 (What)
│ │ └── {branch_id}/ # 例: main
│ │ └── 000-FirstIdea.md # 例
│ ├── plans/ # 開発計画、タスク定義 (How - Plan)
│ │ └── {branch_id}/ # 例: main
│ │ └── 000-FirstPlan.md # 例
│ ├── designs/ # 設計ドキュメント、構造定義 (Structure) 【任意】
│ └── refs/ # フェーズ固有の参考資料 【任意】
これらのフォルダは、特定の開発フェーズに紐づかず、プロジェクト全体を通じて役割とパスが固定されます。内容（ファイルの中身）は必要に応じて随時アップデートされます。
目的: Vibe Codingのプロセス自体を規定するメタ・ルールと、コード生成の品質を規定する実務ルールの両方を管理し、AIの出力の一貫性、品質、セキュリティを保証します。ルールを **「共通ルール」**と **「シーン別ルール」**に分割し、管理します。
| ルールの種類 | ファイル名例 | 記述すべき項目 |
|---|---|---|
| メタ・ルール | Vibe-Coding-Standard.md |
このドキュメント自体。開発プロセス、ファイル命名規則、役割分担など。 |
| 共通ルール (Always) | project-coding-rules.md |
ビルドとテスト方針（TDDの強制、カバレッジ目標）、コーディング規約（命名規則、ファイル構成）、エラーハンドリングなど。常にAIに適用させるべき最低限の実務ルール。 |
| シーン別ルール (Scenario) | api-design-rules.md / db-schema-rules.md |
特定のタスク（例: API設計、データベーススキーマ設計、フロントエンドコンポーネント実装）にのみ適用する詳細な実務規約。 |
運用:
- 共通ルールの設定:
project-coding-rules.mdなど、常に適用したい実務ルールファイルは、利用環境の設定（例:.cursorrulesや.agent、システムプロンプト）で、常に最優先で参照されるように設定します。 - シーン別ルールの適用:
api-design-rules.mdなどのシーン別ルールは、タスク実行時のチャットメッセージ内で、明示的に参照させることで適用します。 - 注意: AIの出力がルールを無視した場合、該当するルールファイルを改めて参照させ、再検討を依頼します。
目的: 複数のフェーズをまたいで参照される、プロジェクト固有の共通知識を保存します。
| 内容例 | 記述すべき項目 |
| global-apis.md | プロジェクトが利用する外部APIの仕様概要、認証フローなど。 |
| common-utilities.ts | 全体で共通して利用されるヘルパー関数やカスタムユーティリティコード。 |
運用:
- AIへの依頼時、このフォルダ内のファイルを明示的に参照させることで、AIはプロジェクト全体にわたる知識に基づいてタスクを実行できます。
命名規則: {nnn}-{phase_name} (例: 001-prototype)
- 切り替え: 現行フェーズの開発が完了したら、
phases/直下に連番を上げた新しいフェーズフォルダを作成します。 - 履歴の保持: 古いフェーズフォルダは移動させず、そのまま残します。これにより、以前の議論や決定事項が履歴として完全に保持され、パスも不変となります。
| フォルダ | 役割 | サマリー（目的と主なアクション） |
|---|---|---|
| ideas/ | 要件定義 (What) | AIとの壁打ち結果をMarkdown化し、要件、ビジョン、機能を定義する最上位のコンテキスト。 |
| plans/ | 開発計画 (How) | ideas/を参照させ、具体的なタスク、工程を生成。TDDを推奨し、計画変更時は必ずideas/から修正する。 |
| designs/ | 構造定義 (Structure) | 【任意】 AIにMermaidなどで構造図を作成させ、複雑な仕様における人間とAIの相互理解を深める。 |
| refs/ | 固有の参考資料 | 【任意】 そのフェーズでのみ必要な一時的なコード片やテストデータなどを格納し、タスク実行時に参照する。 |
目的: 開発したいものの要件、ビジョン、機能を定義します。AIとの壁打ちの「種」となる最上位のコンテキストです。
手順:
- 壁打ち: ChatGPTやGeminiなどのAIと対話し、アイデアの具体化、実現可能性の検討、機能の洗い出しを行います。
- ファイル化: 十分に議論した後、その結果をMarkdown形式で整理し、要件定義とします。
- 命名:
{branch_id}/{mmm}-{title}.mdの規則に従ってideas/内に保存します。
目的: アイデアを実現するための具体的なタスク、工程、マイルストーンを定義し、実行の指針とします。
手順:
- 計画の生成:
ideas/内のファイルを参照させ、「このアイデアを実現するための計画を作成してください」とAIに依頼します。空の計画ファイルを作成し、その中に記述させるのが効率的です。 - 実行前のコミット: コード生成を含む計画を実行する直前に、現在のプロジェクトの状態をGitにコミットします。これにより、AIによる大規模な改変や意図しない変更が発生した場合でも、即座に安全な状態へロールバックできます。
- 実現可能性の検討: 生成された計画を人間が確認し、技術的、時間的に実現可能か評価します。
- 計画の実行: 承認された計画ファイルを参照させ、「この計画の最初のステップを実行してください」と依頼します。
計画のアップデート:
- 計画から漏れや変更が見つかった場合、まず
ideas/の要件を修正してから、そのファイルを指定して計画の更新を依頼します。 - チャットメッセージでの軽微な修正依頼は、コンテキストとして残りづらいため極力避けます。
目的: 【任意】 コードの複雑化や規模拡大に伴い、AIと人間の相互理解を深めるため、システム構造や処理フローを図やドキュメントとして記録します。
活用方法:
- AIへの依頼: 開発中のコードベースや計画を参照させ、「現在のシステムの設計概要（処理フロー図、クラス図など）をMarkdownまたはMermaid形式で作成してください」と依頼し、
designs/に保存します。 - コンテキストの参照: 新しい計画を作成する際や、既存コードを修正する際に、AIにこの設計ファイルを参照させ、現状の構造を正しく把握させます。
目的: 【任意】 そのフェーズのタスクにのみ必要な一時的・固有の知識（例: 特定のコードスニペット、一時的なテストデータ、外部仕様の一部）を保存します。
活用方法:
- プロジェクト全体で共有すべきでない、または一時的な参照にのみ使用するファイルを格納し、必要なタスク実行時にAIに参照させます。
すべてのプロンプトファイルは、以下の規則に従い、ブランチごとに時系列を識別できるようにします。
{branch_id}/{mmm}-{title}.md
{branch_id}(ブランチ識別子): 現在作業中のGitブランチ名の簡略形（例:feat-login,bug-001）。衝突回避を目的とします。{mmm}(ファイル連番): 3桁の連番（例:001）。各ブランチ内での作成順を示します。{title}: 内容を簡潔に表すタイトル（例:initial-api-reqs）。
パスの永続性はVibe Coding標準の核心です。
- AIへの指示: AIへの依頼時には、以下の手法に基づき、参照パスを指定すること。
- IDE及びGUIベースの環境 (VSCode, Cursor等): ファイルをメッセージフォームへドラッグ＆ドロップするか、
@による逐次的検索を通じて、相対パスを生成すること。 - CLIベースの環境 (Claude Code等): 現在アクティブなフェーズフォルダ内を起点とする相対パスを、手動でメッセージ内に直接記述すること。
- 例:
./ideas/feat-login/001-initial-api-reqs.md
- 文脈の保持: この方法により、チャット履歴が流れても、AIは参照されたファイルから常に正確なコンテキストを読み込み、一貫した出力を維持できます。
- ファイルのコミット:
ideas/,plans/,designs/内のプロンプトファイルは、コードファイルと同様にGitでバージョン管理し、コミットメッセージで変更内容を明確に記録します。 - ブランチID: ファイル名にブランチIDを含めることで、どのブランチで議論・計画されたプロンプトであるかを一目で識別できます。