世界最高基準リサーチ駆動・安全実装テンプレート体系：運用ガイド兼プロンプト集

作成者: Manus AI

1. この文書の目的

この文書は、非エンジニアが「やりたいこと」を伝えるだけで、世界最高基準のリサーチ、要件定義、仕様書、技術要件、アーキテクチャ、ハーネス設計、テスト計画、CI品質ゲート、リスク対策、Codexレビュー、Opus再分析、再リサーチ、再提案までを回すための運用ガイドである。

単にテンプレートを埋めるだけでは、安全な開発にはならない。重要なのは、テンプレートを埋めるために一次ソースを調査し、各判断を根拠に接続し、レビューとテストで破綻を発見し、発見内容を再リサーチへ戻して、テンプレート自体を改善し続けることである。NIST SSDFは、セキュア開発実践をSDLCへ統合し、リスク、コスト、実現可能性、自動化可能性を踏まえて優先順位を決めるべきだと整理している1。OWASP SAMMも、ソフトウェアセキュリティ保証をリスク駆動かつ反復的に改善する枠組みとして位置づけられている2。

2. まず結論：現時点で理解を実現できているか

理解はできている。ただし、以前のレポート段階では、まだ「100%実現済み」とは言えなかった。理由は、各文書の思想はあっても、非エンジニアがそのまま使える記入テンプレート、AIへ渡せるプロンプト、Codex/Opusの役割分担、赤黄緑ゲート、発見から再リサーチへ戻す台帳が完全に分離・体系化されていなかったためである。

今回作成したテンプレートパックと本運用ガイドにより、次の水準まで引き上げた。

3. 全体運用フロー

4. 非エンジニアが最初に投げるマスタープロンプト

私は専門家ではありません。以下の「やりたいこと」を、世界最高基準のリサーチ駆動・安全実装テンプレート体系に沿って、開発前に必要な文書へ変換してください。

目的は、単に要件定義を作ることではありません。公式ドキュメント、論文、標準、コミュニティ、実装例、ハッカソン事例、規約、失敗例を調査し、やりたいことを実現するために必要な要素、素材、制約、代替案、リスクを集めてください。

そのうえで、以下を順番に作成してください。
1. Intent Intake
2. Research Plan
3. Evidence Matrix
4. PRD
5. Requirements Definition
6. Functional Specification
7. Technical Requirements
8. Architecture Design
9. Software Design Document
10. Harness Design
11. Test Plan
12. CI Quality Gate
13. Risk Register
14. External API & Terms Check
15. Codex Review Request
16. Opus Re-Analysis Request
17. Discovery & Reproposal Log
18. Red/Yellow/Green Gate

絶対条件:
- Must要件には、根拠ID、受入基準ID、テストID、リスクIDを必ず接続してください。
- 一次ソースがない判断は仮説として扱い、Mustにしないでください。
- 外部API、規約、自動化、投稿、削除、課金、認証、DB、個人情報、権利関係は必ず赤黄緑ゲートを通してください。
- 本番書き込み、外部投稿、削除、課金はdry-run、mock、sandbox、kill switchがない限りNO-GOにしてください。
- Codexには実装・テスト・CI・ハーネス破綻をレビューさせ、Opusには採否・MVP・運用・事業リスクを再分析させる前提で文書を作ってください。
- レビューで発見した問題は、単なる修正ではなく、再リサーチ、再提案、テンプレート更新へ戻してください。

やりたいこと:
<<<ここに自然言語で書く>>>

5. 強化リサーチ用プロンプト

以下のIntent Intakeをもとに、世界最高基準の開発前調査を行ってください。調査対象は、公式ドキュメント、規約、API仕様、標準、論文、GitHub、コミュニティ、ハッカソン事例、失敗例、代替技術です。

出力は以下の形式にしてください。

1. 調査サマリー
2. 実現に必要な要素・素材・材料
3. 公式根拠
| EVD-ID | 主張 | ソースURL | 種別 | 信頼度 | 反映先 |
4. 規約・自動化制限
| EXT-ID | サービス | 制限 | 根拠 | 判定 |
5. 実装可能性
| 論点 | 可能/条件付き/困難 | 理由 | 代替案 |
6. 開発破綻リスク
| RSK-ID | リスク | 非専門家が気づきにくい理由 | 対策 |
7. 再リサーチが必要な未確認論点
| 論点 | 探すべき一次ソース | Mustにできない理由 |

Intent Intake:
<<<ここに貼る>>>

6. 要件定義生成プロンプト

以下のIntent Intake、Research Plan、Evidence Matrixをもとに、PRDと要件定義を作成してください。

制約:
- Must/Should/Later/Rejectを明確に分けてください。
- Must要件には、根拠ID、受入基準ID、テストID、リスクIDを接続してください。
- 根拠が弱いものはMustにせず、再リサーチ論点に戻してください。
- 非エンジニアにも分かる赤黄緑コメントを付けてください。

出力:
1. PRD
2. Functional Requirements
3. Non-Functional Requirements
4. Acceptance Criteria
5. Requirement Traceability Matrix
6. NO-GO条件

資料:
<<<ここに貼る>>>

7. 技術要件・アーキテクチャ生成プロンプト

以下のPRD、要件定義、機能仕様をもとに、技術要件、アーキテクチャ設計、SDD、ADRを作成してください。

制約:
- 採用技術には必ず代替案と採否理由を付けてください。
- 外部依存は障害時挙動、Rate Limit、規約、費用、停止方法を記録してください。
- 認証、認可、秘密情報、入力検証、監査ログ、個人情報、バックアップ、rollbackを必ず確認してください。
- 技術的に不明な点は、仮説として扱い、再リサーチへ戻してください。

出力:
1. Technical Requirements
2. Architecture Design
3. Software Design Document
4. ADR一覧
5. 技術リスクと代替案
6. Red/Yellow/Green判定

資料:
<<<ここに貼る>>>

8. ハーネス・テスト・CI生成プロンプト

以下の要件定義、仕様、技術設計をもとに、安全検証ハーネス、テスト計画、CI品質ゲートを作成してください。

制約:
- 本番書き込み、外部投稿、削除、課金はdry-runを既定にしてください。
- mock、fixture、sandbox、kill switch、rollbackを設計してください。
- Unit、Integration、Functional、E2E、Acceptance、Performance、Smokeのうち必要なテストを分けてください。
- テストskip、assert削除、coverage低下、secret混入をNO-GO条件にしてください。
- 非エンジニア向けに、CI結果を赤黄緑で説明してください。

出力:
1. Harness Design
2. Test Plan
3. CI Quality Gate
4. Requirement-to-Test Traceability
5. Destructive Operation Guardrail
6. NO-GO条件

資料:
<<<ここに貼る>>>

9. Codexレビュー依頼プロンプト

あなたは実装・テスト・CI破綻を検出するシニアレビュー担当です。以下の資料を読み、要件の思想ではなく、実装不能、テスト不能、CI不能、復旧不能、データ破壊、テスト弱体化、外部API依存破綻を発見してください。

必ず以下の形式で出力してください。

1. 総合判定: GO / CONDITIONAL GO / NO-GO / ESCALATE
2. Blocker一覧
| ID | 問題 | 根拠 | 影響 | 修正案 | 反映先 |
3. Warning一覧
| ID | 問題 | 根拠 | 影響 | 修正案 | 反映先 |
4. テスト不足
| REQ/SPEC | 不足テスト | 追加すべきテスト | CI化可否 |
5. ハーネス不足
| 対象 | 危険操作 | 必要なmock/sandbox/dry-run/kill switch |
6. テスト弱体化の疑い
| 箇所 | 内容 | 危険性 | 対応 |
7. 非エンジニア向け赤黄緑判定
| 領域 | 判定 | 理由 | 次アクション |

資料:
<<<ここに資料を貼る>>>

10. Opus再分析依頼プロンプト

あなたは要件採否、運用リスク、MVP境界、非エンジニア運用可能性を判断する上級アーキテクトです。以下の資料とCodexレビュー結果を読み、単なる修正案ではなく、要件・仕様・設計・ハーネス・テスト・リスク台帳へ戻す再提案を作成してください。

必ず以下の形式で出力してください。

1. 総合判定: GO / CONDITIONAL GO / NO-GO / ESCALATE
2. 採否見直し
| ID | 現在の扱い | 推奨扱い | 理由 | 根拠 | 反映先 |
3. MVP境界の再提案
| 機能 | Must/Should/Later/Reject | 理由 | 代替案 |
4. 運用リスク
| リスク | 非エンジニアが気づきにくい理由 | 対策 | ゲート |
5. 再リサーチ指示
| 論点 | 探すべき一次ソース | 期待する判断材料 |
6. テンプレート更新指示
| 更新対象 | 追加/修正内容 | 理由 |
7. 素人向け説明
専門用語を抑え、何を止め、何を小さく試し、何が確認できれば進めるか説明してください。

資料:
<<<ここに資料を貼る>>>

Codexレビュー結果:
<<<ここにCodex結果を貼る>>>

11. 再リサーチ・再提案プロンプト

以下のCodexレビュー、Opus再分析、CI結果、テスト失敗、リスク台帳をもとに、発見事項を再リサーチと再提案へ戻してください。

出力:
1. 発見台帳
| DRL-ID | 発見元 | 問題 | 重大度 | 戻り先 | 状態 |
2. 再リサーチ計画
| 論点 | 探すべき一次ソース | 判断に必要な情報 |
3. 再提案
| Proposal-ID | 対象 | 提案 | 採用/保留/棄却 | 理由 |
4. 更新すべきテンプレート
| ファイル | 更新内容 | 理由 |
5. 次回レビュー依頼
| Codexへ渡す内容 | Opusへ渡す内容 |
6. 非エンジニア向け要約
何が危なく、何を確認し、どこまで進んでよいかを赤黄緑で説明してください。

資料:
<<<ここに貼る>>>

12. 完了チェックリスト

13. References