世界最高基準レビュー・テスト・再リサーチループ運用プロトコル
作成者: Manus AI
1. 結論
このプロトコルは、非エンジニアが希望を伝えるだけで開発前文書を作れるようにするだけでなく、作られた文書が危険なまま実装へ進むことを防ぐための運用設計である。NIST SSDFが示すように、セキュア開発は脆弱性を減らし、未対応脆弱性の影響を下げ、根本原因の再発を防ぐ活動として扱うべきである1。また、OWASP SAMMはソフトウェアセキュリティ保証をリスク駆動かつ反復的に改善する枠組みを提供している2。したがって、このテンプレート体系では、一回作った文書を完成品とはみなさず、レビュー、テスト、再リサーチ、再提案を通じて継続的に改善する。
2. なぜこのループが必要か
非エンジニアが最も危険なのは、間違った要件や曖昧な仕様を「それっぽく整った文書」として受け入れてしまうことである。AIが整形した文書は見た目が整うため、外部APIの規約違反、認証権限の過大化、テスト不能、CI未整備、rollback不能、課金事故、誤投稿、DB破壊などが隠れやすい。そこで、テンプレートは文書作成だけでなく、根拠接続、受入基準接続、テスト接続、リスク接続、レビュー接続を必須化する。
| 危険 | 非エンジニアが気づきにくい理由 | 必須対策 |
|---|---|---|
| 要件の曖昧さ | 文書が丁寧だと正しく見える | Must要件に受入基準とテストIDを必須化する |
| 外部API破綻 | 利用上限や規約は実装前に見えにくい | 公式Docs、規約、Rate Limit、SandboxをEvidence化する |
| テスト不能 | 動作確認とテスト設計の違いが分かりにくい | Unit、Integration、E2E、Acceptanceを分離する |
| 本番破壊 | dry-runやmockの必要性が分かりにくい | ハーネス設計で本番接続を禁止または制限する |
| CI不在 | 手元で動くと安全に見える | GitHub Actions等で自動ゲートを設計する |
| セキュリティ欠落 | 脅威が目に見えない | ASVS型の検証要件をセキュリティ要件に接続する |
| 運用不能 | 作った後の監視・復旧が軽視される | SLO、監視、アラート、rollbackを設計する |
3. 標準ループ
| Step | 名称 | 入力 | 処理 | 出力 | 次の判断 |
|---|---|---|---|---|---|
| 1 | Intent | ユーザーの自然言語 | 目的、対象者、制約、避けたい失敗を構造化 | Intent Intake | 調査へ進む |
| 2 | Research | Intent | 公式、論文、規約、コミュニティ、実装例を調査 | Research Brief / Evidence Matrix | 根拠不足なら再調査 |
| 3 | Definition | Evidence | PRD、要件、受入基準を作成 | PRD / REQ | Must要件にACとTestがなければ戻る |
| 4 | Specification | REQ | 機能、画面、状態、例外を定義 | SPEC | 例外・権限不足なら戻る |
| 5 | Technical Design | SPEC | 技術要件、ADR、アーキテクチャを作成 | TECH / ARC / SDD | 代替案なしなら戻る |
| 6 | Harness | TECH | mock、fixture、dry-run、sandbox、kill switchを設計 | HRN | 本番破壊リスクならNO-GO |
| 7 | Test & CI | REQ/SPEC/HRN | テスト計画とCI品質ゲートを作成 | TST / CI | 自動化不能ならYellow以上 |
| 8 | Risk Gate | 全資料 | リスク台帳と赤黄緑判定を作成 | RSK / GATE | Redなら再リサーチ |
| 9 | Codex Review | 全資料またはPR | 実装・テスト・CI破綻を検出 | CDR | Blockerは再提案へ |
| 10 | Opus Re-Analysis | CDRと全資料 | 採否、MVP、運用、事業リスクを再判断 | OAR | 必要なら要件へ戻る |
| 11 | Reproposal | CDR/OAR/テスト結果 | 発見を再リサーチと再提案へ変換 | DRL / PROP | Blocker 0まで循環 |
4. CodexとOpusの役割分担
CodexとOpusは、単なる二重レビューではない。二重レビューだけでは同じ観点の見落としが残るため、役割を非対称に分ける。Codexは実装、テスト、CI、差分、ハーネス、破壊防止のレビューに集中する。一方、OpusはCodexの発見を受けて、そもそもその要件を採用すべきか、MVPに入れるべきか、運用できるか、非エンジニアが誤判断しないかを再分析する。
| 役割 | Codex | Opus |
|---|---|---|
| 主目的 | 実装・テスト・CI破綻の検出 | 採否・運用・事業・安全性の再判断 |
| 見るもの | 差分、テスト、CI、ハーネス、依存関係 | PRD、要件、リスク、ユーザー目的、運用制約 |
| 典型出力 | Blocker、Warning、追加テスト、ハーネス不足 | MVP再提案、要件削除、運用対策、再リサーチ指示 |
| 判断軸 | 動くか、壊さないか、検証できるか | 作るべきか、素人が運用できるか、目的に合うか |
| 戻り先 | SPEC、TECH、HRN、TST、CI | Research、PRD、REQ、RSK、GATE |
5. ループ停止条件
ループは永遠に回すものではない。以下の条件を満たした時点で、次段階へ進める。
| 条件 | 必須水準 |
|---|---|
| Blocker | 0件 |
| Must要件 | 根拠ID、受入基準ID、テストID、リスクIDが接続済み |
| 外部API | 公式Docs、規約、Rate Limit、Sandbox、停止方法が確認済み |
| ハーネス | 本番書き込みが制御され、dry-runまたはsandboxが存在する |
| CI | lint、test、build、secret scanの最低ゲートがある |
| セキュリティ | 認証、認可、秘密情報、入力検証、監査ログが確認済み |
| 運用 | 監視、アラート、rollback、復旧手順が定義済み |
| 素人向け説明 | 次に何をしてよいかが赤黄緑で説明されている |
6. Red時の標準対応
Red判定は失敗ではない。Redは、壊れる前に危険を検出できたという意味である。Redが出た場合は、実装を進めず、発見台帳に登録し、再リサーチへ戻す。
| Red原因 | 戻り先 | 実施する再リサーチ | 更新するテンプレート |
|---|---|---|---|
| 規約不明 | Research | 公式規約、自動化制限、コミュニティ事例 | EXT, EVD, RSK |
| 実装不能 | Research/Technical | SDK、API制限、類似実装、代替技術 | TECH, ARC, SDD |
| テスト不能 | Harness/Test | mock、fixture、sandbox、CI事例 | HRN, TST, CI |
| 要件過大 | Product/Requirements | MVP事例、競合範囲、ユーザー価値 | PRD, REQ |
| セキュリティ不明 | Security/Research | OWASP ASVS、SSDF、脅威モデル | TECH, TST, RSK |
| 運用不能 | Operations | SRE、監視、復旧、費用制限 | TECH, CI, GATE |
7. 根拠との接続
NIST SSDFは、セキュア開発実践を各SDLCへ追加・統合し、リスク、コスト、実現可能性、適用可能性、自動化可能性を考慮して優先順位を決めることを示している1。OWASP SAMMは、組織のセキュリティ実践を評価し、反復的に改善し、測定可能な保証プログラムを作るためのモデルである2。OWASP ASVSは、セキュリティ制御のテスト基準と開発要件の基礎を提供している3。ADRは、機能要件または非機能要件に影響する設計判断と理由、トレードオフ、結果を記録するため、技術選定と代替案管理に適している4。GitHub Actionsは、イベントで起動する自動ワークフローによりbuild、test、deployなどを実行できるため、CI品質ゲートの実装モデルとして使える5。Google SREは、監視において症状と原因を分け、低ノイズで明確なアラートを重視するため、非エンジニア向け赤黄緑ゲートの運用思想に合う6。Anthropicのエージェント設計論は、単純で構成可能なワークフローを優先し、明確な評価基準がある場合にEvaluator-Optimizerループが有効であることを示している7。Atlassianのテスト分類は、Unit、Integration、Functional、E2E、Acceptance、Performance、Smokeを分け、テスト計画を階層化する実務的根拠になる8。