AI プロンプトのベストプラクティスは「プロの手順」の踏襲 — 要件定義から実装まで 5 段階に分ける

gohan 氏（@grandchildrice）が、Cursor アンバサダーの Kinopee 氏のツイートを引用して次のように投稿しています。

AIプロンプトのベストプラクティスは「プロの人間はどういう手順を取る？」を徹底して踏襲すること

システム開発するとなったらざっくり

  1. ゴールと要件定義
  2. 要件定義の検証
  3. テスト工程設計
  4. 開発
  5. テスト

バイブコーディングするときも、1〜5でそれぞれプロンプトを分けるとクオリティは格段に上がる — gohan

引用元の Kinopee 氏（@kinopee_ai）は 2,048 いいね・35 万回表示を記録したツイートで、こう述べています。

壁打ちして、いきなり「それで実装して」ではなく、このひと手間をかけるだけで、結果が全然違いますよ — Kinopee

「ひと手間」とは何か。要件定義と実装の間に「検証」と「テスト設計」を挟むことです。この記事では、プロの開発プロセスを AI プロンプトに適用する具体的な方法を解説します。

なぜ「一発プロンプト」は失敗するのか

多くの人がバイブコーディングでつまずく原因は、1 つのプロンプトですべてを済ませようとすることにあります。

❌ 「経費精算アプリを作って」

この指示は、人間の開発チームに例えれば「要件定義も設計もテストも全部同時にやって」と言っているのと同じです。プロの開発者はそんなことはしません。

LLM は 1 つのプロンプトに複数の目的を詰め込むと、各目的の達成度が下がります。要件定義の精緻さ、テスト設計の網羅性、実装の品質が、すべて中途半端になります。

5 段階プロンプト設計

gohan 氏が提唱する 5 段階は、ソフトウェア開発の V 字モデルを簡略化したものです。各段階で別々のプロンプトを使うことで、AI の出力品質が格段に向上します。

第 1 段階：ゴールと要件定義

目的: 「何を作るか」を言語化する

このアプリのゴールは「月次経費精算の手作業を 30 分から 5 分に短縮する」ことです。

以下の要件定義書を作成してください：
- ユーザーストーリー
- 機能要件（入力・処理・出力）
- 非機能要件（性能・セキュリティ）
- 制約条件（使用する外部サービス、予算）

ポイントはゴールを定量的に書くことです。「便利なアプリ」ではなく「30 分を 5 分に短縮」と書けば、AI が判断基準を持てます。

第 2 段階：要件定義の検証

目的: 要件の抜け漏れや矛盾を発見する

添付した要件定義書をレビューしてください。以下の観点で問題点を指摘してください：
- 曖昧な表現はないか
- 矛盾する要件はないか
- セキュリティ・コンプライアンス上の懸念はないか
- 想定されるエッジケースは網羅されているか

gohan 氏は「2 のあとに人間フィードバックがあるとなおいい」と指摘しています。AI のレビュー結果を人間が確認し、足りない部分や曖昧な部分を指摘して修正させる。この人間のチェックポイントが品質の分水嶺です。

あなたが要件定義を理解してないのに開発を進めてはならない — gohan

第 3 段階：テスト工程設計

目的: 実装する前に「何をもって完成とするか」を定義する

添付した要件定義書に基づき、テスト計画を作成してください：
- 単体テストケース一覧
- 結合テストシナリオ
- 受け入れテストの合格基準
- エッジケースのテストケース

テストを先に設計する理由は、AI に「ゴールライン」を示すためです。テストケースが明確であれば、実装段階で AI が自律的にテストを通過するコードを生成できます。これはテスト駆動開発（TDD）の原則と同じです。

第 4 段階：開発

目的: 要件定義とテスト計画に基づいてコードを生成する

添付した要件定義書とテスト計画に基づき、実装してください。
- 要件定義書: [添付]
- テスト計画: [添付]
- 技術スタック: Python + FastAPI
- コーディング規約: [添付]

この段階では、前の 3 段階で作成したドキュメントがすべてコンテキストとして機能します。AI は「何を作るか」「どう検証するか」を理解した状態でコードを書くため、手戻りが大幅に減ります。

第 5 段階：テスト

目的: 実装がテスト計画を満たしているか検証する

添付したテスト計画に基づき、実装コードに対してテストを実行してください。
- 不合格のテストがあれば、原因を特定し修正してください
- テストカバレッジを報告してください

「壁打ち」から「実装」への橋渡し

Kinopee 氏が言う「ひと手間」は、上記の第 2 段階と第 3 段階に相当します。多くの人は第 1 段階（壁打ち）からいきなり第 4 段階（実装）に飛びます。

壁打ち → 実装     ❌  結果が不安定
壁打ち → 検証 → テスト設計 → 実装 → テスト  ✅  結果が安定

Kinopee 氏は Cursor アンバサダーとして、この中間ステップの重要性を繰り返し発信しています。GitHub で公開している cursorrules リポジトリには、コーディング支援ルール、コミットメッセージ規約、テスト戦略ルールなどが含まれており、段階的な開発プロセスを Cursor のルールとして体系化しています。

仕様駆動開発（SDD）との関係

gohan 氏の 5 段階プロセスは、2025 年後半から注目を集めている**仕様駆動開発（Spec-Driven Development, SDD）**と本質的に同じ考え方です。

SDD は「仕様を最初に明確化し、そこからすべてを逆算する」開発手法です。従来のテスト駆動開発（TDD）や振る舞い駆動開発（BDD）と異なり、AI との協業を前提に設計されています。

アプローチ起点AI の役割
バイブコーディング（一発）曖昧なプロンプトコード生成のみ
TDDテストコードテストを満たすコード生成
SDD仕様書仕様理解 → 設計 → 実装 → テスト
5 段階プロンプトゴール定義各段階で専門的な出力

2026 年には SDD を支援するツールも急速に増えています。GitHub の Spec Kit、AWS の Kiro、cc-sdd などが、仕様書の作成からコード生成までのワークフローを自動化しています。

実践：モデルの使い分け

Kinopee 氏の実践では、段階ごとにモデルを使い分ける戦略も紹介されています。

段階推奨モデル理由
要件定義・検証推論モデル（o3 等）論理的整合性の検証に強い
テスト設計推論モデル網羅性・エッジケース発見
実装コーディングモデル（Claude 等）コード生成の品質が高い
テスト実行コーディングモデルテストコード生成・実行

壁打ちの段階では推論に強いモデルで設計を詰め、実装段階ではコード生成に強いモデルに切り替える。この「モデルのリレー」が、単一モデルでの一貫した開発よりも高い品質を生み出します。

人間フィードバックの挿入ポイント

gohan 氏が強調する「人間フィードバック」は、第 2 段階の後に挿入するのが最も効果的です。

[AI] 要件定義 → [AI] 要件検証 → [人間] レビュー・修正指示
                                    ↓
[AI] テスト設計 → [AI] 実装 → [AI] テスト → [人間] 最終確認

要件定義の品質が後工程すべてに影響するため、ここで人間が介入する投資対効果が最も高いのです。富士通が 2026 年 2 月に発表した AI ドリブン開発基盤でも、要件定義から結合テストまで全工程を AI が実行しますが、人間のレビューポイントは要件定義の直後に設定されています。

「プロの手順」がなぜ効くのか

gohan 氏の洞察の核心は、「プロの人間はどういう手順を取る？」という問いにあります。

プロの開発者が数十年かけて磨いてきた開発プロセスには、失敗から学んだ知恵が凝縮されています。V 字モデル、アジャイル、TDD、いずれも「手戻りを最小化する」ための仕組みです。AI コーディングでも同じ原則が適用されます。

LLM は本質的に「コンテキストに依存した出力生成器」です。良質なコンテキスト（要件定義書、テスト計画）を段階的に積み上げることで、各段階の出力品質が向上します。これは 2026 年に「コンテキストエンジニアリング」として体系化されつつある考え方と一致します。

プロンプトエンジニアリングの進化形は、個々のプロンプトの最適化ではなく、プロンプト群の設計にあります。どの順序で、何を、どのモデルに問うか。この全体設計が、AI コーディングの品質を決定します。

まとめ

  • プロの開発手順を踏襲する: 要件定義 → 検証 → テスト設計 → 開発 → テストの 5 段階でプロンプトを分ける
  • 一発プロンプトを避ける: 複数の目的を 1 つのプロンプトに詰め込むと、各目的の達成度が下がる
  • 人間フィードバックは要件定義の直後: 投資対効果が最も高いレビューポイントは第 2 段階の後
  • テストを先に設計する: AI に「ゴールライン」を示すことで、実装の品質が安定する
  • モデルを段階ごとに使い分ける: 推論モデルで設計を詰め、コーディングモデルで実装する「リレー」戦略
  • 仕様駆動開発（SDD）と同根: 2025 年後半から体系化が進む SDD は、同じ原則をツールで支援する
  • コンテキストの段階的積み上げ: 各段階の成果物が次段階のコンテキストとなり、出力品質を向上させる

参考