← AI開発 資料アーカイブ
テンプレート体系(設計思想)

世界最高基準リサーチ駆動・安全実装テンプレート体系の全体設計(思想・8層・18種)

元ファイル: システム要件定義の分析と汎用化方法/世界最高基準テンプレート体系:全体設計.md

要約

非エンジニアの自然言語の希望から要件・仕様・設計・テスト・運用ゲートまでをAIが構造化し、レビューと検証で破綻を発見して再リサーチへ戻す『開発前ガバナンスの型』の全体設計書。Intent IntakeからRe-Research Loopまでの8層アーキテクチャと、生成すべき18種類のテンプレート(INT/RES/EVD/PRD/REQ/SPEC等)を定義。生成文書はレビュー前は『仮説』とみなし、一次ソース・テスト・Codex/Opusレビュー・赤黄緑ゲートで検査する循環を中核に置く。

要点

テンプレート体系リサーチ駆動ガバナンス非エンジニアCodexOpus赤黄緑ゲート

世界最高基準テンプレート体系:全体設計

作成者: 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フォーマットとして作成し、それを束ねるマスター運用ガイドとプロンプト集を作成する。

↑ トップへ戻る