統合マスタードキュメント構成案：非エンジニア向けClaude Code要件定義自動化体系
作成者: Manus AI
1. 文書の目的
本マスタードキュメントは、非エンジニアやAI初心者がClaude Codeに「やりたいこと」を伝えるだけで、要件定義書、仕様書、技術要件、ハーネス設計、テスト計画、SDDを作成し、レビュー・テスト・再リサーチループで合意可能な状態まで進める工程を整理するための中核文書とする。
2. 統合すべき主題
| 主題 |
内容 |
統合先 |
| 対象ユーザー |
システム開発知識ゼロの非エンジニア、AI初心者 |
前提・設計思想 |
| 対象ユースケース |
Substack、note、Kindle、メルマガ、文章作成、AI秘書 |
ユースケース分類 |
| 必要成果物 |
要件定義書、仕様書、技術要件、テスト計画、ハーネス設計、SDD |
成果物体系 |
| 逆順アプローチ |
型を先に用意し、型を埋めるためにリサーチV2を行う |
標準工程 |
| Anthropicハーネス思想 |
evaluation harness、agent harness、evaluator-optimizer、initializer/coding agent |
ハーネス設計原則 |
| Codex/Opus役割分離 |
Codexは実装・CI・テスト、Opusは要件・運用・リスク |
レビュー体制 |
| RYGゲート |
Green/Yellow/Redで素人が判断可能にする |
合意工程 |
| 再リサーチ |
不明点、破壊リスク、規約、実現性を再調査する |
品質保証ループ |
3. 標準工程の設計
| Phase |
名称 |
入力 |
AIが行うこと |
人間が判断すること |
出力 |
| 0 |
やりたいこと入力 |
自然文の要望 |
意図、対象者、成果、制約を整理する |
目的が合っているか |
Intent Sheet |
| 1 |
初期リサーチ |
要望と対象領域 |
実現可能性、公式API、規約、競合、構成案を調査する |
進めたい方向性 |
Research Brief / Evidence Matrix |
| 2 |
型の選択 |
対象システム分類 |
必要テンプレートを選ぶ |
不要な範囲の除外 |
Template Pack Selection |
| 3 |
リサーチV2 |
未記入テンプレート |
各テンプレート項目を埋めるために再調査する |
目的とのズレ |
Requirements / Spec / Tech / Harness / Test / SDD |
| 4 |
ハーネス先行設計 |
技術要件・リスク |
sandbox、dry-run、rollback、ログ、権限、承認を設計する |
危険操作の許容可否 |
Harness Design |
| 5 |
テスト計画 |
要件ID・受入基準 |
単体、統合、E2E、回帰、受入、運用テストを設計する |
受入条件の妥当性 |
Test Plan Matrix |
| 6 |
Codexレビュー |
仕様・コード・テスト |
CI、実装破綻、テスト不足、破壊的変更を検出する |
なし、結果確認のみ |
Codex Review Report |
| 7 |
Opusレビュー |
要件・リスク・レビュー結果 |
要件採否、事業・運用リスク、再提案を行う |
採用・保留・却下 |
Opus Review Report |
| 8 |
RYGゲート |
全成果物 |
Green/Yellow/Redを判定し解除条件を整理する |
Green承認または差し戻し |
Gate Decision Log |
| 9 |
再リサーチ/再提案 |
Red/Yellow/Finding |
根拠を再調査し、代替案を作る |
方向性の合意 |
Re-Research / Re-Proposal |
| 10 |
合意 |
Green連続達成 |
最終整合性を確認する |
実装開始またはリリース合意 |
Completion Checklist |
4. マスタードキュメントの章立て
| 章 |
章タイトル |
主な内容 |
| 1 |
結論 |
まず何を作るべきか、なぜ逆順アプローチか |
| 2 |
前提 |
非エンジニア・AI初心者、Claude Code前提、判断範囲 |
| 3 |
対象ユースケース分類 |
Substack、note、複合自動化、AI秘書 |
| 4 |
必要成果物体系 |
要件定義書、仕様書、技術要件、ハーネス、テスト、SDD |
| 5 |
通常手順の問題 |
リサーチ後に手書きで要件化する限界 |
| 6 |
逆順アプローチ |
世界最高基準テンプレートを先に置き、リサーチV2で埋める |
| 7 |
リサーチV1/V2の違い |
実現可能性調査とフォーマット充填調査を分ける |
| 8 |
Anthropicハーネス設計からの原則 |
evaluation harness、agent harness、grader、outcome、trace |
| 9 |
Claude Code実行工程 |
initializer、feature list、progress log、git、1機能ずつ実装 |
| 10 |
Codex/Opusレビュー体制 |
役割分離、レビュー観点、再提案 |
| 11 |
RYGゲートと合意条件 |
100%完璧を「Green条件を満たした状態」として定義 |
| 12 |
Substack自動化への適用例 |
具体的なドキュメント充填順と調査観点 |
| 13 |
最小導入セット |
初回に必要な5台帳と初週工程 |
| 14 |
次に作るべきテンプレート |
ユースケース別パック、Claude Codeプロンプトシーケンス |
| 15 |
参考資料 |
Anthropic、NIST、OWASP、GitHub Actions、SRE等 |
5. 重要な設計判断
「100%完璧」は、バグが永久にゼロという意味ではなく、現時点で確認可能な要件、根拠、テスト、ハーネス、リスク、レビュー、ゲート条件がすべて接続され、未解決のRedがなく、Yellowには解除条件・担当・期限がある状態として定義する。この定義により、非エンジニアでも専門的な正誤判断を背負わず、合意可能な品質状態を確認できる。
6. 作成する最終ファイル
| ファイル |
目的 |
/home/ubuntu/non_engineer_claude_code_requirements_master_summary.md |
今回のユーザー要望を統合したマスター整理ドキュメント |
/home/ubuntu/anthropic_harness_recheck_notes.md |
公式資料再確認の根拠メモ |