世界最高基準の要件定義を作成する汎用プロンプトと実務フロー
作成者: Manus AI
対象: 新規事業、業務システム、AI/MLシステム、SaaS、Webアプリ、モバイルアプリ、データ基盤、業務改善、研究開発、PoC、MVP、本番開発のすべて
目的: どのプロジェクトでも、実装できる・検証できる・運用できる・改善できる要件定義書を作るための再利用可能なプロンプトと運用フローを提供する。
1. 結論
世界最高基準の要件定義を作るためのプロンプトは、単に「要件定義書を書いてください」と依頼するものではありません。最も重要なのは、AIに対して、背景理解、利害関係者整理、業務フロー、機能要件、データ要件、非機能要件、受入基準、要件ID、フェーズ別Exit Criteria、運用・監査・変更管理までを一貫して生成・検証させることです。
世界最高基準の要件定義とは、綺麗な文章ではなく、関係者が同じ理解で実装・検証・運用判断を行える状態を作る文書である。
特に重要なのは、要件を本文だけで終わらせないことです。本文に加えて、要件ID台帳、受入基準、テスト観点、フェーズ別Exit Criteria、リスク・未決事項、変更管理ルールを必ず作ります。これにより、要件定義は「説明資料」ではなく「開発と運用の制御システム」になります。
| 必須成果物 | 目的 | なぜ必要か |
|---|---|---|
| 要件定義書本体 | プロジェクトの目的、範囲、業務、機能、非機能を定義する。 | 関係者の共通理解を作るため。 |
| 要件ID台帳 | すべての要件をIDで管理する。 | 実装、テスト、変更管理、レビューを追跡可能にするため。 |
| 受入基準表 | 各要件の完了条件を定義する。 | 「できた」の判断を曖昧にしないため。 |
| フェーズ別Exit Criteria表 | PoC、MVP、本番などの移行条件を定義する。 | 感覚的なフェーズ移行を防ぐため。 |
| ロジック採用・停止基準表 | AI、予測、推奨、判定ロジックの採用・停止条件を定義する。 | 品質劣化や誤作動を運用で制御するため。 |
| リスク・未決事項管理表 | 未確定事項、前提条件、リスクを管理する。 | 後工程での手戻りを減らすため。 |
2. このプロンプトを使う前に準備する情報
プロンプトを使う前に、以下の情報を可能な範囲で準備します。すべて埋まっていなくても実行できますが、空欄が多いほどAIに追加質問をさせる設計にします。
| 項目 | 入力内容 | 例 |
|---|---|---|
| プロジェクト名 | 作りたいシステム、サービス、業務改善の名称 | 予約管理システム、競馬分析システム、営業支援SaaS |
| 背景 | なぜこのプロジェクトが必要か | 手作業が多い、判断が属人化している、データ活用ができていない |
| 目的 | 何を達成したいか | 業務時間削減、売上向上、予測精度向上、顧客体験改善 |
| 利用者 | 誰が使うか | 一般ユーザー、管理者、営業担当、分析担当、承認者 |
| 現状業務 | 現在どのように業務が行われているか | Excel管理、手入力、メール承認、外部データ参照 |
| 作りたい機能 | 思いついている機能 | 一覧表示、検索、登録、分析、通知、レポート、AI推奨 |
| データ | 入力・外部・保存データ | 顧客データ、売上データ、API、CSV、画像、ログ |
| 制約 | 技術、法務、予算、納期、運用上の制約 | 3か月以内、既存DB利用、個人情報あり、外部API制限あり |
| 成功指標 | 成功をどう測るか | 処理時間50%削減、CVR改善、手戻り削減、精度向上 |
3. 世界最高基準の要件定義作成マスタープロンプト
以下のプロンプトをそのままコピーして使ってください。角括弧 【 】 の部分だけ、対象プロジェクトに合わせて置き換えます。
あなたは、世界最高水準の要件定義、業務設計、システム設計、プロダクトマネジメント、品質保証、セキュリティ、データ設計、AI/ML運用、プロジェクト管理に精通したシニア要件定義コンサルタントです。
これから、以下のプロジェクトについて、実装・検証・運用・改善まで可能な「世界最高基準の要件定義書」を作成してください。
# プロジェクト情報
- プロジェクト名: 【プロジェクト名】
- 背景: 【なぜこのプロジェクトが必要なのか】
- 目的: 【達成したい成果】
- 対象ユーザー: 【利用者・管理者・関係者】
- 現状業務: 【現在の業務や課題】
- 作りたい機能: 【思いついている機能】
- 使用するデータ: 【入力データ、外部データ、保存データ、ログなど】
- 制約条件: 【予算、納期、法務、技術、運用、外部APIなど】
- 成功指標: 【KPI、品質目標、業務改善目標】
- 想定フェーズ: 【PoC、MVP、β版、本番、運用改善など】
# 作成方針
以下の方針を必ず守ってください。
1. 要件を単なる文章ではなく、実装・テスト・運用で使える管理単位に分解してください。
2. すべての主要要件に要件IDを付与してください。
3. 各要件に、優先度、受入基準、検証方法、依存関係、リスクを付けてください。
4. 曖昧な表現は避け、「誰が、何を、どの条件で、どの結果として」行うのかを明確にしてください。
5. 機能要件だけでなく、データ要件、画面要件、業務フロー、非機能要件、セキュリティ、権限、監査、運用、保守、障害対応、変更管理まで含めてください。
6. AI、予測、推奨、判定ロジックが含まれる場合は、採用基準、停止基準、再評価基準、説明可能性、ログ、例外承認ルールを定義してください。
7. PoC、MVP、本番などのフェーズがある場合は、各フェーズの目的、成果物、Exit Criteria、承認者、未達時対応を定義してください。
8. 不明点がある場合は、勝手に断定せず、「仮定」と「確認事項」に分けて明示してください。
9. 最後に、要件定義の品質チェックリストと、次に実施すべきタスクを提示してください。
# 出力してほしい成果物
以下の構成で出力してください。
1. エグゼクティブサマリー
2. プロジェクト背景と目的
3. スコープ定義
- 対象範囲
- 対象外範囲
- 前提条件
- 制約条件
4. ステークホルダー一覧
5. 現状業務と課題
6. To-Be業務フロー
7. ユースケース一覧
8. 機能要件一覧
9. 画面要件一覧
10. データ要件一覧
11. 外部連携要件
12. AI/ロジック要件
13. 非機能要件
14. セキュリティ・権限・監査要件
15. 運用・保守要件
16. 障害対応・バックアップ・復旧要件
17. 要件ID台帳
18. 受入基準表
19. テスト観点表
20. フェーズ別Exit Criteria表
21. リスク・未決事項・確認事項一覧
22. 変更管理ルール
23. リリース判定基準
24. 要件定義品質チェックリスト
25. 次アクション
# 出力形式
- Markdown形式で出力してください。
- 表を多用し、実務でそのまま使える形にしてください。
- 要件IDは、FUNC、SCREEN、DATA、API、AI、NFR、SEC、OPS、TEST、RISK のような分類コードを使ってください。
- 各表には、判断可能な基準を入れてください。
- 曖昧な箇所は「確認事項」として一覧化してください。
4. 詳細化用の追加プロンプト
マスタープロンプトを一度実行しただけでは、すべての粒度が十分にならない場合があります。そのため、要件定義は1回で完成させるのではなく、段階的に深掘りするのが正しい使い方です。
| 利用タイミング | 使うプロンプト | 得られる成果 |
|---|---|---|
| 初回 | マスタープロンプト | 要件定義書の初版 |
| 2回目 | 要件ID台帳プロンプト | 実装・テスト可能な要件一覧 |
| 3回目 | Exit Criteriaプロンプト | フェーズ移行条件 |
| 4回目 | ロジック採用・停止基準プロンプト | AI/判断ロジックの運用基準 |
| 5回目 | レビュープロンプト | 抜け漏れ、矛盾、曖昧さの検出 |
4.1 要件ID台帳を作るプロンプト
先ほど作成した要件定義書をもとに、すべての主要要件を要件ID台帳に変換してください。
以下の列を必ず含めてください。
- 要件ID
- 分類
- 要件名
- 要件内容
- 背景・理由
- 優先度
- 受入基準
- 検証方法
- 依存関係
- リスク
- 未決事項
要件IDは、FUNC、SCREEN、DATA、API、AI、NFR、SEC、OPS、TEST、RISK の分類コードを使って採番してください。1つの要件に複数の意味が入っている場合は、必ず分割してください。受入基準は「確認できる・測定できる・判定できる」表現にしてください。
4.2 フェーズ別Exit Criteriaを作るプロンプト
このプロジェクトを、PoC、MVP、β版、本番、運用改善のフェーズに分け、それぞれのExit Criteriaを作成してください。
以下の列を含む表で出力してください。
- フェーズ
- フェーズの目的
- 対象範囲
- 必須成果物
- 完了条件
- Exit Criteria
- 承認者
- 未達時の対応
- 次フェーズへ進めない条件
- 判断に必要な証跡
Exit Criteriaは曖昧な表現ではなく、実際に会議やレビューで合否判定できる表現にしてください。
4.3 AI・ロジック採用停止基準を作るプロンプト
このプロジェクトに含まれるAI、予測、推奨、スコアリング、ランキング、判定ロジックについて、採用基準、警告基準、一時停止基準、強制停止基準、再評価基準、例外承認ルールを作成してください。
以下の列を含む表で出力してください。
- ロジックID
- ロジック名
- 目的
- 入力データ
- 出力結果
- 採用基準
- 警告基準
- 一時停止基準
- 強制停止基準
- 再評価タイミング
- 例外承認条件
- 必要なログ・証跡
- 責任者
特に、データ欠損、異常値、未来データ混入、精度劣化、説明不能な出力、重大バグが起きた場合の停止条件を明確にしてください。
4.4 非機能要件を深掘りするプロンプト
この要件定義書に対して、非機能要件を世界最高基準の実務レベルまで詳細化してください。
以下の観点を必ず含めてください。
- 性能
- 可用性
- 拡張性
- 保守性
- セキュリティ
- 権限管理
- 監査ログ
- バックアップ
- 障害復旧
- データ品質
- 運用監視
- コスト管理
- 法務・コンプライアンス
各項目について、要件ID、要件内容、基準値または判定条件、検証方法、運用時の確認方法を表で出力してください。基準値が不明な場合は、仮置き値ではなく「確認事項」として整理してください。
4.5 要件レビュー用プロンプト
以下の要件定義書を、シニアPM、業務設計者、システムアーキテクト、QA責任者、セキュリティ責任者、運用責任者の観点でレビューしてください。
レビューでは、以下を抽出してください。
- 曖昧な要件
- 実装できない要件
- 検証できない要件
- 受入基準が不足している要件
- 非機能要件の不足
- データ要件の不足
- 権限・監査・セキュリティの不足
- 運用・保守の不足
- フェーズ移行条件の不足
- リスクと未決事項
出力は、指摘ID、該当箇所、問題内容、影響、修正案、優先度、担当候補、期限目安の表にしてください。
5. プロンプトを使うべき実務フロー
プロンプトは、次の順序で使います。最も重要なのは、生成、構造化、基準化、レビュー、確定の5段階に分けることです。1回のプロンプトで完璧な要件定義を作ろうとすると、曖昧な箇所が本文に埋もれます。
| フェーズ | 目的 | 使用プロンプト | 完了条件 |
|---|---|---|---|
| 1. 入力整理 | AIに渡す材料を整える。 | 入力テンプレート | 背景、目的、利用者、制約、成功指標が整理されている。 |
| 2. 初版生成 | 要件定義書の全体像を作る。 | マスタープロンプト | 主要章がすべて出力されている。 |
| 3. 要件ID化 | 実装・テスト可能な単位にする。 | 要件ID台帳プロンプト | 主要要件にID、受入基準、検証方法が付いている。 |
| 4. フェーズ基準化 | PoC、MVP、本番の移行条件を作る。 | Exit Criteriaプロンプト | 各フェーズの合否判定が可能である。 |
| 5. 運用基準化 | AI/ロジック、非機能、運用を制御可能にする。 | ロジック基準・非機能プロンプト | 採用、停止、障害、監査、復旧が定義されている。 |
| 6. 第三者レビュー | 抜け漏れと矛盾を発見する。 | レビュープロンプト | 指摘表と修正方針が出ている。 |
| 7. 確定・テンプレート化 | 再利用可能な資産にする。 | 汎用化プロンプト | 固有名詞が抽象化され、次案件に使える。 |
6. 実務での推奨フロー図
以下の流れで進めると、最も品質が安定します。
[プロジェクト情報の入力]
↓
[マスタープロンプトで要件定義初版を生成]
↓
[不足情報・確認事項を人間が補足]
↓
[要件ID台帳に変換]
↓
[受入基準・検証方法を詳細化]
↓
[フェーズ別Exit Criteriaを作成]
↓
[AI/ロジック・非機能・運用要件を補強]
↓
[第三者レビュー用プロンプトで監査]
↓
[修正・再レビュー]
↓
[最終要件定義書として確定]
↓
[固有要素を抽象化してテンプレート化]
7. どのような流れでAIと対話すべきか
AIとの対話では、最初から細かい仕様を完成させようとせず、次のように段階的に進めます。人間が判断すべきことと、AIに整理させることを分けるのが重要です。
| ステップ | 人間が行うこと | AIに依頼すること |
|---|---|---|
| Step 1 | 背景、目的、課題、制約を入力する。 | 要件定義の初版を作成させる。 |
| Step 2 | AIが出した仮定と確認事項を確認する。 | 不明点を質問リスト化させる。 |
| Step 3 | 重要な判断を人間が補足する。 | 補足情報を反映して再構成させる。 |
| Step 4 | 開発対象範囲を決める。 | 要件ID台帳に変換させる。 |
| Step 5 | 優先度とフェーズ方針を決める。 | Exit Criteriaを作成させる。 |
| Step 6 | 運用・停止・例外判断の方針を決める。 | ロジック基準、非機能、運用要件を作成させる。 |
| Step 7 | 最終承認者が確認する。 | レビュー指摘表と修正案を作成させる。 |
8. 最終品質チェックプロンプト
要件定義書を完成させる前に、以下のプロンプトで必ず品質チェックを行います。
この要件定義書が、実装・検証・運用・改善に耐えられる世界最高基準の要件定義になっているかを厳しく評価してください。
以下の観点で、100点満点で採点し、不足点と修正案を提示してください。
1. 背景・目的の明確性
2. スコープの明確性
3. 利害関係者の網羅性
4. 業務フローの具体性
5. 機能要件の実装可能性
6. 画面要件の具体性
7. データ要件の網羅性
8. 外部連携要件の明確性
9. AI/ロジック要件の運用可能性
10. 非機能要件の十分性
11. セキュリティ・権限・監査の十分性
12. 運用・保守要件の具体性
13. 要件IDによる追跡可能性
14. 受入基準の検証可能性
15. フェーズ別Exit Criteriaの妥当性
16. リスク・未決事項の管理可能性
17. 変更管理の明確性
18. リリース判定基準の明確性
出力は、評価項目、点数、問題点、修正案、優先度の表にしてください。最後に、最優先で修正すべき上位10項目を提示してください。
9. 汎用テンプレート化プロンプト
一度作った要件定義を、他のプロジェクトでも使えるテンプレートに変換するためのプロンプトです。
この要件定義書を、他のどのプロジェクトでも再利用できる汎用テンプレートに変換してください。
以下を実施してください。
1. 固有名詞、業界固有語、特定データ名、特定システム名を抽象変数に置き換えてください。
2. 例示は残しつつ、どの業界でも使える説明にしてください。
3. 入力欄、記入例、判断基準、チェック項目を分けてください。
4. 要件ID台帳、受入基準表、Exit Criteria表、ロジック採用・停止基準表、非機能要件表、リスク管理表をテンプレート化してください。
5. プロジェクト開始時、PoC前、MVP前、本番前、運用開始後のどのタイミングで使うかも説明してください。
出力は、Markdown形式の汎用テンプレートとして、実務でコピーして使える形にしてください。
10. 最短で使う場合の簡易版プロンプト
時間がない場合は、以下の簡易版を使います。ただし、最終的にはマスタープロンプトと追加プロンプトで補強することを推奨します。
以下のプロジェクトについて、実装・検証・運用できる要件定義書を作成してください。
プロジェクト名: 【名称】
背景: 【背景】
目的: 【目的】
利用者: 【利用者】
課題: 【課題】
作りたい機能: 【機能】
データ: 【データ】
制約: 【制約】
成功指標: 【KPI】
出力には、背景、目的、スコープ、業務フロー、機能要件、画面要件、データ要件、外部連携、非機能要件、セキュリティ、運用要件、要件ID台帳、受入基準、テスト観点、フェーズ別Exit Criteria、リスク、未決事項、次アクションを含めてください。
要件はすべて、実装可能・検証可能・運用可能な粒度に分解してください。不明点は仮定と確認事項に分けてください。
11. 使い方の実例
たとえば、新しい予約管理システムを作る場合は、次のように入力します。
| 入力項目 | 入力例 |
|---|---|
| プロジェクト名 | 店舗向け予約管理システム |
| 背景 | 電話と紙で予約管理しており、二重予約と確認漏れが発生している。 |
| 目的 | 予約登録、変更、キャンセル、通知を一元化し、スタッフの確認作業を削減する。 |
| 利用者 | 店舗スタッフ、店長、顧客、管理者 |
| 作りたい機能 | 予約登録、空き枠表示、キャンセル、リマインド通知、管理画面、レポート |
| データ | 顧客情報、予約情報、店舗情報、スタッフ情報、通知ログ |
| 制約 | 個人情報を扱う。スマホ対応が必要。3か月以内にMVPを出したい。 |
| 成功指標 | 電話対応時間30%削減、二重予約ゼロ、予約確認漏れ削減 |
この情報をマスタープロンプトに入れると、AIは初版の要件定義を作成できます。その後、要件ID台帳プロンプト、Exit Criteriaプロンプト、非機能要件プロンプト、レビュープロンプトの順に使います。
12. 最終的に完成すべき状態
最終的な要件定義は、以下の状態になっていれば合格です。
| 判定項目 | 合格状態 |
|---|---|
| 目的 | なぜ作るのかが明確である。 |
| スコープ | 対象範囲と対象外範囲が明確である。 |
| 業務 | As-IsとTo-Beが説明できる。 |
| 機能 | 実装単位に分解されている。 |
| データ | 入力、出力、保存、連携、品質が定義されている。 |
| 非機能 | 性能、可用性、セキュリティ、運用、保守が定義されている。 |
| 要件ID | すべての主要要件が追跡可能である。 |
| 受入基準 | 完了判断ができる。 |
| Exit Criteria | フェーズ移行の合否判定ができる。 |
| リスク | 未決事項とリスクが管理されている。 |
| 運用 | 障害、変更、監査、保守が定義されている。 |
13. 運用上の注意
このプロンプトは、AIに要件定義を丸投げするためのものではありません。AIは構造化、抜け漏れ検出、表形式化、レビュー観点の提示に強みがありますが、事業判断、法的判断、予算判断、最終的な優先順位決定は人間が行うべきです。
特に、外部データ、個人情報、金融、医療、法務、AI判断、課金、決済、監査が関係するプロジェクトでは、専門家レビューを必ず入れてください。要件定義の品質基準としては、検証可能性、一貫性、完全性、追跡可能性を重視する考え方が要求工学の標準的な観点として扱われています。1