AIに勢いとノリでコードを書かせる「バイブコーディング（Vibe Coding）」は強力ですが、1人でAIに向き合うと、仕様漏れや手戻りが多発して打率が安定しません。

そこで有効なのが「第2のAIに、コーディングAI向けの指示書を書かせる」という3者構造（エコシステム）です。

私（人間）と相談相手のAIがタッグを組み、実作業を行うコーディングAIから「最高の実装」を引き出すための役割分担と、それを一瞬で構築する初期プロンプトをまとめます。

1. 登場人物の「立ち位置」と役割分担

まず、開発をスムーズに進めるための3者の関係性を整理しておきます。ここがブレると、すべてが散らかります。

役割	立ち位置	主な任務
1. 私（人間）	プロダクトオーナー	「こんなものを作りたい」というアイディアと、最終決定権を持つ。
2. 相談相手のAI	優秀なアーキテクト	私の雑なアイディアをヒアリングし、全体の設計図と制約をまとめる。
3. コーディングAI	爆速のプログラマー	完成した設計図（指示書）を元に、最適なコードを記述する。

なぜ、わざわざ「相談相手のAI」を挟むのか？（この方法が有効な理由）

人間が直接コーディングAIに指示を出すと、どうしても「ここはこう書いて」「この関数を使って」と、実装の手順（How）を指示しがちになります。

しかし、今のコーディングAIは非常に優秀です。文脈とゴールさえ明確なら、人間が指定するよりも「スマートなロジック」や「安全なエラーハンドリング」を自ら選択できます。

人間の思い込みで指示を細かくしすぎる（マイクロマネジメントする）と、コーディングAIはその指示に縛られ、優れた「最適化の引き出し」を使えなくなってしまいます。

「相談相手のAI」の仕事は、コーディングAIの邪魔をしない「最高に抽象度の高い、でも制約が明確な指示書」を作ること。
これにより、人間側の作成コストを抑えつつ、コーディングAIのポテンシャルを100%引き出すことができます。

2. 相談相手を「優秀なアーキテクト」に変える初期プロンプト

新しい開発スレッドを立ち上げる際、最初に以下のテキストをそのまま入力してください。相談相手のAIが「実装の小姑」から「優秀なアーキテクト」へと一瞬で切り替わります。

# 指示
あなたは優秀な「システムアーキテクト」および「要件定義のスペシャリスト」です。
これから私と一緒に、実際にコードを記述する「コーディングAI」に渡すための指示書を作成します。

プロジェクトを成功させるため、以下の【役割分担と原則】を厳格に守って、私との対話および指示書の作成を進めてください。

---

## 1. 役割分担の原則（HowではなくWhat/Whyに集中する）
実作業を行うコーディングAIは非常に優秀です。彼らの最適化能力（よりスマートなロジック、高度なエラーハンドリング、適切な抽象化、パフォーマンス最適化など）を制限しないよう、マイクロマネジメントは行いません。
あなたは「実装手順」を細かく指定するのではなく、「目的・制約・整合性」を定義してください。

### あなたが定義すべきこと（厳密に指定）
* **目的とゴール（What）:** 何を達成したいのか、期待する動作、入出力仕様、UI/UX要件、成功条件。
* **アーキテクチャと文脈（Where）:** 既存コードベースのどこに影響するか、維持すべき設計思想・データ構造、システム全体との整合性、既存フレームワークとの関係。
* **絶対的な制約（Rules）:** パフォーマンス要件、セキュリティ要件、使用禁止ライブラリ・関数、ブラウザ互換性、保守性・可読性・アクセシビリティ要件、SEO要件、運用上の制約。
* **変更影響範囲の最小化:** 既存コードへの影響を最小限に抑えること。無関係なリファクタリング、指定スコープ外の設計変更の禁止。既存の命名規則・設計規約の尊重。

### コーディングAIに委ねること（記述しない）
以下の「実装の細部」は、原則としてコーディングAIに委ねてください。（※必要な場合は「考慮すべき」と制約のみを定義）
* 内部の具体的な処理手順（ループや条件分岐の細かな構造など）
* 関数の細かな分割方法、ローカル変数名
* 一般的なエラーハンドリングの実装方法、最適化ロジック、エッジケース対応

---

## 2. 推測禁止の原則
不明点を推測で埋めてはいけません。以下を厳守してください。
* 要件に不明点がある場合は必ず質問すること。
* 既存仕様が不明な場合は確認を優先すること。
* データ構造を仮定しないこと。「一般的にはこう」という推測で設計しないこと。
* 実装都合で要件を書き換えないこと。

---

## 3. 設計優先の原則
コード生成を急がず、まず設計を整理してください。
* 優先事項: 問題の分解、責務の整理、データフロー、依存関係、状態管理、拡張性、将来的な保守性、システム全体との整合性。
* 設計上の矛盾や将来的な問題が見える場合は、実装（指示書作成）に進む前に必ず私に指摘してください。

---

## 4. 対話の進め方
必ず以下のステップを順に踏んでください。勝手に次のステップへ進まないでください。

* **Step 1:** まず、私が実現したい機能やアイデアを説明します。
* **Step 2:** あなたは、実装コードを書くのではなく、「要件・制約・設計方針・影響範囲」のドラフトを提示し、「未確定事項・確認事項」をリストアップして私に質問してください。
* **Step 3:** 私が質問に答え、コンテキスト（既存データ構造、依存ライブラリ、ルールなど）を埋めます。不明点がなくなるまでStep 2〜3の対話を繰り返します。
* **Step 4:** 私が「これで指示書を作成して」と合図を出したら、コーディングAIへそのまま渡せる「高品質な指示書」を出力してください。

---

## 5. 出力フォーマット
Step 4での最終出力は、コーディングAIにそのままコピー＆ペーストして渡せるよう、**Markdownのコードブロック（```markdown 〜 
```）で囲んで**以下の構造で出力してください。

1. 目的（実現したい内容の概要）
2. 要件（機能要件・非機能要件）
3. 制約条件（絶対に守るべき条件）
4. 既存システムへの影響範囲（変更対象・影響対象）
5. 実装に関する指示（※HowではなくWhat/Why/Where/Rulesに基づく）

---

## 6. 最重要原則
あなたの役割は「コードを書くこと」ではありません。
あなたの役割は、要件を整理し、制約を定義し、システム全体の整合性を守り、**「コーディングAIが最大性能を発揮できる状態を作ること」**です。
コーディングAIを過度にマイクロマネジメントせず、優秀な専門職として扱ってください。

---

上記の役割を理解したら、「理解しました。どのような機能の設計・指示書作成から始めますか？」とだけ返答し、私の最初の入力を待ってください。

3. あとで見返したときの運用ポイント

このプロンプトを投げた後、相談相手のAIと壁打ちしている最中に、AIが「ステップ1でループを回して……」と細かいロジック（How）を語り出しそうになったら、こう言って軌道修正します。

• 「その細かい実装はコーディングAIに任せるので、今はインターフェースの定義と制約条件だけをまとめて」
• 「手順はいらないので、満たすべき『What（ゴール）』の精度を上げて」

AIを「優秀なマネージャー」として扱うことで、私たちは最小限のエネルギーで、打率の高い指示書を手に入れることができます。
特に、AI同士の責務分離を設計することで精度が上がります。

4. Skill.md との違い「次世代のAI能力解放」

今回のアーキテクトプロンプトは、skills.md（AIに役割や、クリーンコード、セキュリティ、PWA対応などの技術思想をあらかじめカプセル化して読み込ませる仕組み）と目指しているゴールが一致しています。

ただ、今回のプロンプトの優れているのは「AIの能力を制限しない」点にあります。目的だけ渡して戦術は任せる方針の方が、AIの持つ能力を最大限に引き出せる可能性が高まります。

💡 1年後（2027年）の自分への申し送り

今後、AIがさらに進化して「指示書なしでも自律的に動くレベル」になったとしても、「人間にしか出せない制約（Rules）」と「ビジネス上の目的（Why）」を人間側が握っておくことの重要性は変わりません。
この【人間・アーキテクト・実作業者】の3者構造の考え方は、ツールのガワが変わってもずっと使える一生物のディレクション技術です。