非エンジニア向け Claude Code 要件定義・仕様化・ハーネス設計・レビュー再リサーチ自動化体系：統合マスター整理
作成者: Manus AI
作成日: 2026-05-23
1. 結論
本件で構築すべきものは、単なる「要件定義書テンプレート」ではない。構築すべきものは、システム開発知識がまったくない非エンジニアやAI初心者が、Claude Codeに“やりたいこと”を自然文で伝えるだけで、リサーチ、要件定義、仕様書、技術要件、ハーネス設計、テスト計画、SDD、レビュー、再リサーチ、再提案、合意判定までを一貫して進められる開発前工程の自動化OSである。
この体系の核心は、通常の「リサーチしてから手作業で要件定義書を書く」という順番を逆転させる点にある。非エンジニアは、要件定義書、仕様書、技術要件、ハーネス設計、テスト計画、SDDの正しい書き方を知らないため、リサーチ結果を自力で適切な文書へ変換できない。したがって、先に世界最高基準の型を用意し、その型を埋めるためにリサーチV2を行う。この逆順アプローチにより、素人の曖昧な要望を、実装可能で、検証可能で、リスク管理可能な開発仕様へ変換する。
本体系の最重要原則は、素人に専門判断を要求しないことである。人間は目的、方向性、許容可否、赤黄緑の最終判断を担い、技術的妥当性、API制約、規約、テスト、ハーネス、セキュリティ、運用リスク、CI破綻、再提案はAIとテンプレート体系が担う。
Anthropicの公式資料では、エージェント評価において、実行過程を記録し、最終発話ではなく環境上の結果を確認し、評価ハーネスによってタスク実行、採点、集計を行う重要性が説明されている。1 また、長時間の開発タスクでは、初期化エージェント、機能リスト、進捗ファイル、Git履歴、1機能ずつの段階実装、E2Eテストが有効であることが示されている。2 さらに、生成者と評価者を分ける evaluator-optimizer 型の反復改善は、明確な評価基準が存在する場合に有効である。3
本体系は、これらの考え方を、Claude Codeを使う非エンジニア向けの要件定義・仕様化・安全実装準備プロセスへ落とし込むものである。
2. 前提条件
この体系が想定する利用者は、システム開発の知識を持たない非エンジニア、AI初心者、個人事業主、編集者、マーケター、経営者、または企業内で業務自動化を進めたい担当者である。利用者は「API」「DB」「CI」「E2Eテスト」「ハーネス」「SDD」「受入基準」といった用語を正確に理解していない可能性が高い。そのため、この体系では、専門用語を利用者に理解させることではなく、専門用語を知らなくても安全に意思決定できる構造を作ることを目的とする。
| 前提 | 内容 | 設計上の意味 |
|---|---|---|
| 利用者は非エンジニアである | 技術仕様を自力で書けない | テンプレートとAIが仕様化を補助する |
| 利用者は自然文で要望を出す | 「Substackを自動化したい」のような曖昧な入力から始まる | Intent Sheetで目的、対象者、成功条件、不明点へ分解する |
| 初期要望は不完全である | API制約、規約、課金、認証、投稿制限、運用リスクは含まれていない | 初期リサーチとEvidence Matrixで補う |
| AIは誤る可能性がある | AIの自己申告や一発回答を信用しない | テスト、レビュー、ハーネス、ゲートで検証する |
| 自動化には破壊的リスクがある | 投稿、削除、課金、メール送信、個人情報処理などが危険領域になる | sandbox、dry-run、rollback、手動承認を必須化する |
| 合意には客観条件が必要である | 「なんとなく良い」では開発破綻を防げない | Green/Yellow/Redと完了条件を定義する |
この前提に立つと、Claude Codeは単なるコード生成ツールではなく、要件を実装可能なタスクへ分解し、進捗ログを残し、テストを実行し、破綻を検出しながら進むエージェントハーネスとして扱うべきである。Anthropicは、agent harnessをモデルがツールを使い、状態を更新し、結果を返すための基盤として説明しており、Claude Codeも柔軟なagent harnessとして位置づけられている。1
3. 対象ユースケースの分類
ユーザーが提示した要望は、単一サービスの自動化から、複数プラットフォームをまたぐ企業レベルのAI秘書まで幅が広い。したがって、最初から一つの巨大なテンプレートで処理するのではなく、ユースケースを複雑度とリスクで分類し、必要な成果物の厚みを変える必要がある。
| 分類 | 例 | 主なリスク | 必要な文書レベル |
|---|---|---|---|
| Level 1: 単一サービスの半自動化 | Substack下書き生成、note記事案生成 | 品質不足、手動転記ミス、著作権、表現リスク | 軽量要件定義、仕様書、テスト計画 |
| Level 2: 単一サービスの投稿自動化 | Substack自動投稿、note予約投稿支援 | 投稿ミス、規約違反、API/非公式操作、認証情報漏洩 | 標準要件定義、技術要件、ハーネス、E2Eテスト |
| Level 3: 複数サービス連携 | Kindle、note、Substackの連携 | データ不整合、重複投稿、権利管理、フォーマット崩れ | 詳細仕様、連携仕様、リスク台帳、回帰テスト |
| Level 4: 配信・販売・文章作成の複合自動化 | メルマガ、販売導線、文章生成、SNS告知 | 誤配信、課金、個人情報、ブランド毀損、スパム判定 | SDD、監視設計、承認フロー、運用手順 |
| Level 5: 企業レベルAI秘書 | 社内情報検索、メール作成、予定調整、文書作成 | 情報漏洩、権限逸脱、監査不備、意思決定代行 | セキュリティ要件、監査ログ、権限設計、運用規程 |
この分類で重要なのは、「シンプルに見える要望でも、実際には危険操作を含む場合がある」という点である。たとえば「Substackを自動化したい」という要望は、記事案の生成だけなら比較的低リスクだが、実アカウントへの自動投稿、読者へのメール配信、課金購読者向けコンテンツの扱いまで含めると、権限、規約、誤配信、個人情報、ブランド毀損のリスクが急激に高まる。
4. 最初に揃えるべき成果物
本体系では、実装に入る前に、最低限以下の成果物を揃える。これらが揃っていない状態でClaude Codeに実装を依頼すると、AIが勝手に前提を補完し、後から修正不能な構造になる可能性がある。
| 成果物 | 役割 | 非エンジニア向けの意味 |
|---|---|---|
| Intent Sheet | やりたいこと、目的、対象者、成功条件、不明点を整理する | 最初の自然文を開発可能な入口へ変える |
| Research Brief | 何を調べるか、どの情報源を優先するかを定義する | 闇雲な調査を防ぐ |
| Evidence Matrix | 公式資料、規約、API、事例、制約をID付きで管理する | 思い込み要件を防ぐ |
| 要件定義書 | 機能要件、非機能要件、制約、対象外を整理する | 何を作るかを合意する |
| 仕様書 | 画面、操作、データ、連携、例外処理を定義する | どう動くべきかを具体化する |
| 技術要件 | API、認証、DB、ホスティング、外部連携、セキュリティを定義する | 技術選択の前提を明確化する |
| ハーネス設計 | sandbox、dry-run、rollback、ログ、承認、権限を設計する | 壊さずに試せる仕組みを作る |
| テスト計画 | 単体、統合、E2E、受入、回帰、運用テストを定義する | 「できました」を検証可能にする |
| SDD | 詳細設計、モジュール、データ構造、エラー処理、実装手順を定義する | Claude Codeが迷わず実装できる状態にする |
| Risk Register | 技術、運用、規約、セキュリティ、事業リスクを管理する | 素人が見抜けない危険を見える化する |
| Gate Decision Log | Green/Yellow/Redで進行可否を記録する | 専門判断を赤黄緑に変換する |
この中でも、特に重要なのはEvidence Matrix、Harness Design、Test Plan、Gate Decision Logである。要件定義書だけを整えても、根拠、検証、リスク、進行可否が接続されていなければ、AI開発では容易に破綻する。
5. 通常手順の問題と逆順アプローチ
通常の開発では、まずリサーチし、その結果をもとに人間が要件定義書や仕様書を書き、技術要件やテスト計画へ落とし込む。しかし、この手順は専門家を前提にしている。非エンジニアやAI初心者にとっては、リサーチ結果を読んでも、どれを要件にすべきか、どれを制約にすべきか、どれをリスクとして扱うべきか、どのテストが必要かを判断できない。
したがって、本体系では、次のように手順を逆転させる。
| 通常手順 | 本体系の逆順アプローチ |
|---|---|
| 先にリサーチする | 先に必要ドキュメントの型を準備する |
| 人間が要件定義書を書く | AIがテンプレート項目を埋めるためにリサーチV2を行う |
| 書ける人の能力に依存する | 型とレビュー基準に依存させる |
| 実装後にテストを考える | ハーネスとテストを実装前に設計する |
| 問題が出たら修正する | 問題をRed/Yellowとして再リサーチへ戻す |
| 完了は主観判断になりやすい | Green条件と完了チェックリストで合意する |
この逆順アプローチでは、リサーチV1とリサーチV2を明確に分ける。リサーチV1は「そもそも実現できるか」「どのような選択肢があるか」を調べる段階である。一方、リサーチV2は「要件定義書、仕様書、技術要件、ハーネス設計、テスト計画、SDDの各項目をどう埋めるべきか」を調べる段階である。
6. リサーチV1とリサーチV2の違い
リサーチV1は、アイデアの実現可能性と方向性を確認するための調査である。たとえばSubstack自動化であれば、Substackに公式APIがあるのか、メール配信や投稿操作はどの範囲まで自動化できるのか、規約上問題がないのか、手動承認を挟むべきかを確認する。
一方、リサーチV2は、事前に用意されたテンプレートの空欄を埋めるための調査である。たとえば「認証方式」「投稿前プレビュー」「失敗時のrollback」「重複投稿防止」「誤配信防止」「ログ保持期間」「E2Eテスト手順」「人間の承認点」など、要件定義書やハーネス設計に必要な項目ごとに調べる。
| 観点 | リサーチV1 | リサーチV2 |
|---|---|---|
| 主目的 | 実現可能性と選択肢を把握する | テンプレートを正確に埋める |
| 問い | 作れるのか、どう作れそうか | この項目には何を書くべきか |
| 出力 | 実現案、制約、候補技術、懸念点 | 要件、仕様、技術要件、テスト、ハーネス、SDDの記入内容 |
| 失敗例 | 便利そうな方法だけを集める | 根拠なしに空欄を埋める |
| 成功条件 | 作る方向性が選べる | 実装前合意に必要な文書が揃う |
この分離により、非エンジニアは「何を調べればよいか」を考える必要がなくなる。AIがテンプレートを読み、未記入項目、根拠不足項目、テスト不能項目、リスク未評価項目を検出し、それをリサーチV2の問いへ変換する。
7. Anthropicハーネス設計から得られる原則
Anthropicのエージェント評価資料では、評価は単なる出力チェックではなく、タスク、試行、grader、transcript、outcome、evaluation harness、agent harness、evaluation suiteといった構成要素で整理されている。1 この考え方は、Claude Codeを使った開発前工程にもそのまま適用できる。
| Anthropicの概念 | 本体系での対応 | 実務上の意味 |
|---|---|---|
| Task | 要件ID、テストID、実装タスク | 何を達成すべきかをIDで管理する |
| Trial | Claude Codeの実行単位、レビュー単位 | 1回の実行結果を記録し、再現可能にする |
| Grader | Codex、Opus、テスト、CI、人間承認 | AIの自己申告ではなく外部評価を入れる |
| Transcript / Trace | 実行ログ、ツールログ、レビュー記録 | なぜその判断になったかを後から追える |
| Outcome | 実際の投稿、DB状態、テスト結果、画面状態 | 「できました」ではなく実環境の結果を見る |
| Evaluation Harness | テスト計画、CI、E2E、採点、集計 | 検証の仕組みそのものを設計する |
| Agent Harness | Claude Code実行環境、ツール、プロンプト、進捗ログ | AIが安全に作業する枠組みを作る |
Anthropicの長時間エージェントに関する資料では、長い開発タスクを一発で完了させようとすると、コンテキスト枯渇、未完了作業、進捗不明、早すぎる完了宣言が発生しやすいことが説明されている。2 その対策として、初期化エージェントが環境、機能リスト、進捗ファイル、Git履歴を準備し、後続のコーディングエージェントが1機能ずつ進め、作業後にクリーンな状態を残す構成が示されている。2
この原則を本体系に置き換えると、Claude Codeへ最初に渡すべきものは「作ってください」という一文ではなく、feature_list、requirements、test_plan、harness_plan、progress_log、gate_log、risk_register、SDDである。
8. Claude Codeに渡す標準工程
非エンジニアがClaude Codeを使う場合、Claude Codeには最初から実装を開始させない。まず、以下の工程を順番に実行させる。
| Phase | Claude Codeにさせること | 生成される成果物 | Gate |
|---|---|---|---|
| 0 | ユーザーの自然文要望をIntentへ変換する | Intent Sheet | 目的が合っているか |
| 1 | 初期リサーチV1を行い、実現可能性を確認する | Research Brief、Evidence Matrix | 作る方向性を選べるか |
| 2 | 対象ユースケースのレベルを判定する | Complexity & Risk Classification | 必要文書が不足していないか |
| 3 | 必要テンプレートを選択する | Template Selection Log | 過不足がないか |
| 4 | リサーチV2でテンプレートを埋める | 要件定義書、仕様書、技術要件、SDD | 根拠IDが接続されているか |
| 5 | ハーネス設計を行う | Harness Design Sheet | 危険操作がdry-run化されているか |
| 6 | テスト計画を作る | Test Plan Matrix | Must要件にTest IDがあるか |
| 7 | 実装前レビューを行う | Codex/Opus Review Request | Redがないか |
| 8 | Red/Yellowを再リサーチへ戻す | Re-Research Brief | 未解決論点が消えたか |
| 9 | 再提案を作る | Re-Proposal Sheet | 採用・保留・却下が決まったか |
| 10 | Green条件を確認する | Loop Completion Checklist | 合意可能か |
この工程で重要なのは、Claude Codeが「作業者」であると同時に「進捗を残す実行環境」でもある点である。ただし、自己評価は信用しない。Anthropicの資料でも、生成者が自分の成果物を評価すると過度に肯定的になりやすく、生成者と評価者を分離することが有効であると説明されている。4 そのため、本体系ではCodexとOpusを分け、さらに人間の赤黄緑判断を最後に置く。
9. Codex / Opus / 人間の役割分担
本体系では、AIを一つの万能人格として扱わない。役割を分けることで、AIの過信、自己評価の甘さ、修正不能な設計、事業上のズレを防ぐ。
| 役割 | 担当 | 見るもの | 判断内容 | 判断しないこと |
|---|---|---|---|---|
| 実装・CI・破綻検出 | Codex | コード、テスト、CI、差分、依存関係 | バグ、破壊的変更、テスト不足、復旧不能リスク | 事業上の採否、ユーザー価値 |
| 要件・運用・事業リスク | Opus | 要件、仕様、レビュー結果、リスク台帳 | 要件採否、代替案、運用負荷、事業リスク | 細かなコード差分の正否 |
| 目的・許容可否 | 人間 | 要約、赤黄緑、再提案、デモ | 方向性、許容範囲、最終合意 | API設計やセキュリティ制御の専門判断 |
| 実行・生成 | Claude Code | テンプレート、タスク、SDD、テスト | 実装準備、タスク分解、実装、ログ作成 | 自己完了宣言だけでの合格判定 |
この分担により、非エンジニアは技術詳細の採点をする必要がなくなる。人間が判断するのは、「この目的でよいか」「このリスクを受け入れるか」「このYellow条件で進めるか」「この提案を採用するか」である。
10. RYGゲートと“100%完璧”の定義
本体系における「100%完璧」とは、将来永遠にバグが発生しないという意味ではない。それは現実的でも検証可能でもない。本体系での「100%完璧」とは、現時点で合意可能な品質状態が、要件、根拠、仕様、技術要件、ハーネス、テスト、リスク、レビュー、再リサーチ、再提案、ゲートに接続され、未解決のRedがない状態を指す。
| 判定 | 意味 | 次アクション |
|---|---|---|
| Green | 根拠、要件、テスト、ハーネス、リスク、レビューが接続され、進行可能である | 次フェーズへ進む、または合意する |
| Yellow | 進行可能だが、期限、担当、解除条件付きである | 条件付きで進め、期限内に再判定する |
| Red | 重大な未解決リスク、規約違反、破壊的操作、テスト不能、根拠不足がある | 停止し、再リサーチまたは再提案へ戻す |
完了条件は以下のように定義する。
| 完了条件 | 必須基準 |
|---|---|
| 要件接続 | すべてのMust要件にRequirement ID、Evidence ID、Acceptance Criteria、Test IDがある |
| ハーネス接続 | 投稿、削除、課金、メール送信、個人情報処理にdry-run、rollback、ログ、承認がある |
| テスト接続 | 単体、統合、E2E、受入、回帰、運用テストの対象が明確である |
| レビュー接続 | CodexレビューとOpusレビューの結果が記録されている |
| リスク接続 | Risk Registerに重大リスクと対策が記録されている |
| 再リサーチ接続 | Red/Yellow/FindingがRe-Research Briefへ接続されている |
| 合意接続 | Gate Decision LogでGreenまたは条件付きGreenが承認されている |
このように定義すれば、非エンジニアでも「専門的に完璧か」を判断する必要はない。判断すべきなのは、完璧判定の条件を満たしているかである。
11. Substack自動化システムへの適用例
Substack自動化を例にすると、最初のユーザー入力は「Substackの自動システムを作りたい」で十分である。ただし、そのまま実装してはいけない。Claude Codeはまず、この要望を次のように分解する。
| 項目 | 例 |
|---|---|
| 目的 | Substack記事の企画、下書き作成、投稿準備、配信確認を効率化したい |
| 対象者 | 個人発信者、編集者、メルマガ運営者 |
| 自動化範囲 | 企画生成、本文生成、校正、タイトル案、投稿前チェック、手動承認後の投稿 |
| 自動化しない範囲 | 無承認の本番投稿、課金設定変更、読者情報の無制限取得 |
| 主なリスク | 誤投稿、誤配信、規約違反、認証情報漏洩、著作権、内容品質 |
| 必要なハーネス | dry-run投稿、プレビュー、承認ボタン、ログ、rollback手順、重複投稿防止 |
| 必要なテスト | 下書き生成、フォーマット確認、投稿前チェック、配信対象確認、失敗時復旧 |
次に、リサーチV1でSubstackの公式仕様、利用可能なAPIまたは代替手段、規約、認証方式、投稿方法、手動運用との組み合わせを調査する。この段階では、「完全自動投稿が可能か」だけではなく、「どこまで自動化すべきか」「どこに人間承認を置くべきか」を調べる。
その後、リサーチV2では、以下のようにテンプレートを埋めるための問いへ変換する。
| テンプレート | リサーチV2で調べる問い |
|---|---|
| 要件定義書 | Substack自動化におけるMust要件、Should要件、対象外は何か |
| 仕様書 | 下書き生成、プレビュー、承認、投稿、失敗通知はどの画面・操作で行うか |
| 技術要件 | 認証、データ保存、外部連携、秘密情報管理、ホスティングはどうするか |
| ハーネス設計 | 本番投稿前にdry-run、preview、manual approval、rollbackをどう置くか |
| テスト計画 | 誤投稿、重複投稿、配信対象間違い、フォーマット崩れをどう検出するか |
| SDD | モジュール構成、データモデル、ジョブ実行、エラー処理、ログ設計をどう書くか |
| Risk Register | 規約、権限、個人情報、ブランド毀損、運用停止時の代替策は何か |
このように、リサーチV2は一般的な調査ではなく、型の空欄を埋めるための調査である。
12. 複合自動化への拡張
Kindle、note、Substack、メルマガ、文章作成を組み合わせる場合、単純なSubstack自動化よりも設計は大きく複雑になる。理由は、各プラットフォームの規約、フォーマット、配信タイミング、読者属性、課金、著作権、コンテンツ再利用ポリシーが異なるためである。
| 領域 | 追加で必要になる設計 |
|---|---|
| コンテンツ生成 | 文章の再利用ルール、引用、出典、著作権、トーン管理 |
| Kindle | 原稿構成、EPUB/PDF変換、販売前チェック、権利確認 |
| note | 記事フォーマット、有料記事、画像、タグ、公開範囲 |
| Substack | newsletter配信、購読者向け投稿、メール件名、配信タイミング |
| メルマガ | 配信対象、解除リンク、誤配信防止、スパム判定、個人情報管理 |
| 共通DB | コンテンツID、投稿先、公開状態、版管理、重複防止 |
| 承認フロー | 下書き承認、配信承認、有料公開承認、緊急停止 |
| 監視 | 配信失敗、投稿失敗、重複、リンク切れ、エラー通知 |
このレベルでは、ハーネス設計が中心になる。なぜなら、最も危険なのは「文章を作れないこと」ではなく、間違った文章を、間違った読者へ、間違ったタイミングで、自動配信してしまうことだからである。
13. AI秘書・企業レベル自動化への拡張
「AIの秘書を作ってほしい」という要望は、最も曖昧でありながら最もリスクが高い。AI秘書は、メール、カレンダー、社内文書、顧客情報、議事録、意思決定支援、タスク管理などに関わる可能性があるため、単なる自動化ではなく、権限設計、監査ログ、情報分類、承認フロー、データ保持、セキュリティ要件を含む必要がある。
| 項目 | 企業AI秘書で必須になる設計 |
|---|---|
| 権限 | 読み取り専用、下書き作成、送信承認、管理者権限を分ける |
| 情報分類 | 公開、社内、機密、個人情報、顧客情報を区別する |
| 操作制限 | メール送信、予定変更、外部共有、削除を承認制にする |
| 監査 | 誰が、いつ、何を、どの根拠で実行したかを記録する |
| 失敗時対応 | 誤送信、誤共有、誤削除、機密漏洩時の手順を定義する |
| テスト | 権限逸脱、プロンプト注入、誤操作、機密情報露出を検証する |
| ガバナンス | 利用範囲、禁止行為、責任分界、ログ保持を文書化する |
このようなケースでは、いきなりClaude Codeに実装させるのではなく、まずLevel 5のテンプレートパックを選択し、セキュリティ要件、運用要件、監査要件、リスク台帳、承認フローを先に作る必要がある。
14. 最小導入セット
すべての文書を最初から完全に作ると、運用が重くなりすぎる。したがって、初回導入では以下の5台帳を最小セットとする。
| 優先 | 台帳 | 最低限の項目 |
|---|---|---|
| 1 | Intent台帳 | やりたいこと、目的、対象者、成功条件、不明点 |
| 2 | Requirement台帳 | Requirement ID、要件文、優先度、根拠ID、受入基準 |
| 3 | Test台帳 | Test ID、Requirement ID、手順、期待結果、結果 |
| 4 | Risk台帳 | Risk ID、内容、重大度、対策、RYG |
| 5 | Gate台帳 | Gate ID、判定、理由、解除条件、承認者 |
初週は、1機能または1ユースケースに絞るべきである。たとえば「Substack記事の下書き生成と投稿前チェック」だけを対象にする。最初から「Kindle、note、Substack、メルマガ、SNS、AI秘書」を一括で扱うと、リスクと要件が膨張し、非エンジニアが合意不能になる。
15. 最終的に作るべきテンプレートパック
今後、この体系を完成形にするには、ユースケース別にテンプレートパックを分けるのが望ましい。
| パック | 対象 | 含めるべき文書 |
|---|---|---|
| Substack Automation Pack | Substack下書き、投稿支援、配信確認 | 要件定義、仕様、技術要件、ハーネス、テスト、SDD、投稿前チェックリスト |
| note Automation Pack | note記事生成、投稿準備、有料記事管理 | 要件定義、記事品質基準、公開範囲、課金リスク、テスト計画 |
| Publishing Multi-Platform Pack | Kindle、note、Substack、メルマガ連携 | コンテンツID、版管理、配信順序、重複防止、権利確認 |
| Writing Automation Pack | 文章生成、校正、構成、トーン管理 | 品質評価、出典、著作権、スタイルガイド、レビュー基準 |
| AI Secretary Pack | 企業AI秘書、メール、カレンダー、文書 | 権限、監査、セキュリティ、承認、ログ、情報分類 |
| Enterprise Governance Pack | 企業導入、監査、管理者向け | セキュリティ要件、運用規程、監査ログ、責任分界 |
これらのパックは、共通の18テンプレートを土台にしつつ、ユースケースごとの追加項目を持たせる形がよい。
16. 全体工程の最終整理
最終的な工程は、次の一連のループとして定義できる。
| 順番 | 工程 | 目的 | 完了条件 |
|---|---|---|---|
| 1 | 自然文入力 | やりたいことを受け取る | Intent Sheetが作成される |
| 2 | 初期整理 | 目的、対象者、成功条件、不明点を整理する | ユーザーが方向性を確認する |
| 3 | リサーチV1 | 実現可能性、材料、制約を調べる | 実現案と懸念点が出る |
| 4 | テンプレート選択 | 必要文書と型を選ぶ | 文書不足がない |
| 5 | リサーチV2 | 型を埋めるために再調査する | 各項目に根拠IDが付く |
| 6 | 要件・仕様化 | 要件定義、仕様、技術要件、SDDを作る | Must要件が検証可能になる |
| 7 | ハーネス設計 | 壊さず試す仕組みを設計する | dry-run、rollback、ログ、承認がある |
| 8 | テスト計画 | 要件とテストを接続する | Test IDが接続される |
| 9 | Codexレビュー | 実装、CI、テスト、破壊的変更を検出する | Blockerが記録される |
| 10 | Opusレビュー | 要件、運用、事業リスクを再評価する | 再提案が出る |
| 11 | RYGゲート | 進行可否を判定する | Green/Yellow/Redが決まる |
| 12 | 再リサーチ | Red/Yellowを根拠調査へ戻す | 未解決論点が減る |
| 13 | 再提案 | 要件、仕様、実装方針を修正する | 採用・保留・却下が決まる |
| 14 | 合意 | 実装開始またはリリース判断を行う | Completion Checklistが満たされる |
この工程は一度で終わるものではない。RedまたはYellowが残る限り、再リサーチと再提案へ戻る。Greenが連続して達成され、未解決Redがなくなり、Yellowに解除条件、担当、期限がある状態で、初めて合意可能になる。
17. 現時点のまとめ
これまで作成してきた成果物群は、今回のユーザー要望と整合している。既存のテンプレート集、詳細記入例、導入ガイド、管理ツール設定例、進捗管理テンプレート、レビュー・テスト・再リサーチプロトコルは、すでに土台として利用できる。
ただし、今回の要望を受けて明確になった追加の重点は、要件定義書そのものを単体で作るのではなく、要件定義書、仕様書、技術要件、ハーネス設計、テスト計画、SDDを最初からセットで揃えることである。さらに、通常のリサーチではなく、事前に用意されたフォーマットを埋めるためのリサーチV2を標準工程として明文化する必要がある。
最終的には、非エンジニアがClaude Codeに以下のように依頼するだけで、工程が開始される状態を目指す。
「私はSubstackの自動化システムを作りたいです。システム開発の知識はありません。要件定義書、仕様書、技術要件、ハーネス設計、テスト計画、SDDを作るために、まず必要なテンプレートを選び、それを埋めるためのリサーチV1/V2を行い、Codex/Opusレビュー、赤黄緑ゲート、再リサーチ、再提案まで進めてください。危険な本番操作は必ずdry-runと手動承認を挟んでください。」
この一文を起点に、AIが必要な問いを立て、テンプレートを埋め、レビューとテストを行い、Red/Yellowを再リサーチへ戻し、最終的に合意可能なGreen状態まで進める。これが、本件で目指す非エンジニア向け・世界最高基準の要件定義自動化体系である。
18. 次に作るべき具体成果物
次の段階では、このマスター整理をもとに、実際にClaude Codeへ渡せる形式へ落とし込む必要がある。具体的には、以下を作るのが自然である。
| 優先 | 次成果物 | 内容 |
|---|---|---|
| 1 | 要件定義書マスターテンプレート | 非エンジニア入力から自動充填できる要件定義書の完全版 |
| 2 | Substack自動化サンプル | 要件定義、仕様、技術要件、ハーネス、テスト、SDDの記入済み例 |
| 3 | Claude Codeマスタープロンプト | 「やりたいこと」入力から全工程を起動するプロンプト |
| 4 | リサーチV2プロンプト集 | テンプレート項目を埋めるための調査命令集 |
| 5 | Codex/Opusレビュー連携プロンプト | 実装・CI・要件・リスクを分担レビューする依頼文 |
| 6 | RYG合意チェックリスト | 非エンジニアが最後に見る赤黄緑判定表 |