世界最高基準テンプレート体系:全体設計
作成者: Manus AI
1. 理解の確認
今回の構想は、非エンジニアが専門文書を自力で作ることを前提にしない。出発点は「こういうことをやりたい」という自然言語の希望だけであり、そこからAIが調査し、材料を集め、仮説として要件・仕様・技術要件・ハーネス・テスト・運用を構造化する。そのうえで、レビューとテストで不足や破綻を発見し、見つかった問題を再リサーチ、再提案、再設計に戻す。
したがって、目指すものは単なるテンプレート集ではない。テンプレートを埋めるための調査プロセス、テンプレートの品質を検査するレビュー基準、破壊的な実装を防ぐゲート、発見事項を再リサーチへ戻すループを一体化した、開発前ガバナンスの型である。
2. 完成形の名称
本体系を、以下では World-Class Research-to-Delivery Harness Template System と呼ぶ。日本語では、世界最高基準リサーチ駆動・安全実装テンプレート体系 とする。
非エンジニアの希望を、一次ソースに基づく要件、仕様、設計、テスト、レビュー、運用ゲートへ変換し、発見事項を再リサーチへ戻し続けるためのテンプレート体系である。
3. 全体アーキテクチャ
| 層 | 目的 | 主な成果物 | 非エンジニアの判断方法 |
|---|---|---|---|
| 0. Intent Intake | やりたいことを安全に聞き取る | 希望入力シート、制約質問票 | 何をしたいかだけ答える |
| 1. Research | 材料・根拠・制約を集める | Research Brief、Evidence Matrix | 一次ソース有無を見る |
| 2. Product Definition | 何を作るかを明確化する | PRD、要件定義、MVP範囲 | Must/Should/Later/Rejectを見る |
| 3. Specification | どう振る舞うかを定義する | 機能仕様、データ仕様、API仕様 | 受入基準の有無を見る |
| 4. Technical Design | どう作るかを定義する | 技術要件、C4、ADR、SDD | 代替案と採否理由を見る |
| 5. Harness & Test | 壊さず検証する | ハーネス設計、テスト計画、CIゲート | 赤黄緑判定を見る |
| 6. Risk & Compliance | 事故を防ぐ | リスク台帳、外部API/規約チェック | NO-GO条件を見る |
| 7. Dual Review | 破綻を発見する | Codexレビュー、Opus再分析 | Blocker数と解消状況を見る |
| 8. Re-Research Loop | 改善を循環させる | 発見台帳、再提案ログ、変更履歴 | 次アクションだけ確認する |
4. ループの中核
この体系では、生成した文書を完成品として扱わない。すべての文書は、レビューと検証を受ける前は 仮説 である。仮説は、一次ソース、テスト、CI、Codexレビュー、Opus再分析、非エンジニア向け赤黄緑ゲートによって検査される。
| ループ段階 | 入力 | 処理 | 出力 | 失敗時の戻り先 |
|---|---|---|---|---|
| 1. 発見 | レビュー結果、テスト失敗、規約疑義 | 問題を分類する | 発見台帳 | Research |
| 2. 再リサーチ | 問題分類、未確認論点 | 公式・論文・コミュニティ・実装例を確認する | 追加Evidence | Definition / Design |
| 3. 再提案 | 追加Evidence | 採用・修正・保留・棄却を判断する | 改善案 | Specification |
| 4. 再レビュー | 改善案、更新文書 | Codex/Opusで別観点レビュー | Blocker/Warning | Harness & Test |
| 5. 再検証 | テスト計画、PoC、CI | 安全に検証する | GO判定 | Risk Gate |
5. 生成すべきテンプレート群
| No | テンプレート | 役割 | 必須ID |
|---|---|---|---|
| 1 | Intent Intake Template | 素人の希望を構造化する | INT |
| 2 | Research Plan Template | 何を調査するかを定義する | RES |
| 3 | Evidence Matrix Template | 根拠と要件を接続する | EVD |
| 4 | Product Requirements Template | 価値、対象者、MVPを定義する | PRD |
| 5 | Requirements Definition Template | 機能・非機能要件を定義する | REQ |
| 6 | Functional Specification Template | 振る舞い、画面、状態遷移を定義する | SPEC |
| 7 | Technical Requirements Template | 技術制約、外部依存、SLOを定義する | TECH |
| 8 | Architecture Design Template | 構成、責務、データ流を定義する | ARC |
| 9 | SDD Template | 実装可能な詳細設計に落とす | SDD |
| 10 | Harness Design Template | 安全な検証環境と自動化境界を定義する | HRN |
| 11 | Test Plan Template | 単体、統合、E2E、回帰、受入を定義する | TST |
| 12 | CI Quality Gate Template | 素人でも赤緑を判断できるCI基準を定義する | CI |
| 13 | Risk Register Template | 開発破綻・運用事故を管理する | RSK |
| 14 | External API & Terms Template | API、規約、自動化制限を管理する | EXT |
| 15 | Codex Review Template | 実装・テスト・CI破綻を検出する | CDR |
| 16 | Opus Re-Analysis Template | 要件採否・運用・事業リスクを再判断する | OAR |
| 17 | Discovery & Reproposal Log | 発見から再提案まで追跡する | DRL |
| 18 | Red/Yellow/Green Gate Template | 非エンジニアの意思決定を支援する | GATE |
6. 品質原則
各テンプレートは、次の原則を満たす必要がある。第一に、各要件は一次ソースまたは明示された仮説に接続される。第二に、各Must要件は受入基準とテストIDを持つ。第三に、外部API、規約、自動投稿、課金、認証、DB、セキュリティ、個人情報、権利関係に関わる項目は、必ず赤黄緑ゲートを通す。第四に、発見された問題は、実装修正だけで終わらせず、テンプレートそのものと判断基準に戻す。
7. 100%完璧かどうかの判断
現時点の既存成果物は、方向性としては正しい。しかし、ユーザーの求める「すべて作成」という水準から見ると、まだ100%ではない。理由は、各テンプレートが独立したコピー可能なフォーマットとして整備されておらず、非エンジニアが入力するだけでAIに渡せる完全プロンプト体系、レビュー結果を再リサーチへ戻す運用台帳、NO-GO時の再生成手順が一体化されていないためである。
そのため、次工程では、上記18テンプレートを実際に記入できるMarkdownフォーマットとして作成し、それを束ねるマスター運用ガイドとプロンプト集を作成する。