Claude Code汎用版 Codex ⇄ Opus 反復レビュー・収束フローとプロンプト集
作成者: Manus AI
用途: 任意のプロジェクトで、Claude Code上のOpusとCodexを使い、設計書、要件定義、実装計画、DDL、API設計、レビュー指摘、リリース判定などを反復レビューするための汎用テンプレート。
想定読者: プロジェクト責任者、PM、エンジニア、AIレビュー運用担当者。
基本思想: CodexのレビューもOpusのレビューも鵜呑みにせず、実ファイル、一次ソース、プロジェクト目的、実装開始可否に基づいて判断を収束させる。
1. このテンプレートの目的
このテンプレートは、特定の競馬システムや特定のPoCに依存せず、どのプロジェクトでも使えるように抽象化したCodex ⇄ Opus反復レビュー運用フローである。単発レビューでは、CodexまたはOpusのどちらか一方の判断に引きずられるリスクがある。そのため、本テンプレートでは、Codexの独立レビュー、Opusの再分析、Codexの再レビュー、Opusの最終判定という流れを最大3ラウンドまで実施し、判断を収束させる。
重要なのは、レビューを長引かせることではない。目的は、対象プロジェクトを安全に実装・修正・リリースできる状態にすることである。
| 観点 | 単発レビュー | 反復レビュー・収束プロトコル |
|---|---|---|
| 判断の信頼性 | 1つのAI回答に依存しやすい。 | CodexとOpusの相互検証で誤判定を減らす。 |
| NO-GO時の扱い | 止まって終わることがある。 | GOに戻すための最小修正へ分解する。 |
| 過剰設計リスク | 指摘が増えすぎることがある。 | 実装開始可否に関係する論点へ限定する。 |
| 人間判断 | 最後に曖昧に残る。 | 3ラウンドで収束しなければ明示的にエスカレーションする。 |
2. 全体フロー
以下のフローを任意のプロジェクトに適用する。対象は、要件定義書、設計書、実装計画、DDL、API仕様、テスト計画、運用計画、リリース計画など、レビューが必要なドキュメント全般である。
| ラウンド | 担当 | 目的 | 出力 |
|---|---|---|---|
| 0 | 人間 | レビュー対象、目的、制約、判断基準を用意する。 | 入力ファイル一式、レビュー依頼方針。 |
| 1-A | Codex | 独立レビューを行い、リスク、矛盾、改善点、GO/NO-GOを出す。 | Codexレビュー結果。 |
| 1-B | Opus | Codex結果を鵜呑みにせず、実ファイルと一次ソースで再分析する。 | ACCEPT / MODIFY / REJECT / HOLD判定。 |
| 2-A | Codex | Opus判定に対して再確認し、同意・反論・修正案を出す。 | Codex再レビュー結果。 |
| 2-B | Opus | Codex再回答を確認し、判断を収束させる。 | 最終または準最終判定。 |
| 3 | Opus + 人間 | 一致しない論点を整理し、必要なら人間判断へ回す。 | GO / CONDITIONAL GO / NO-GO / ESCALATE。 |
3. 終了条件
反復レビューは最大3ラウンドまでとし、無限に続けない。以下のいずれかに該当した時点で終了する。
| 終了条件 | 意味 | 次アクション |
|---|---|---|
| GOで一致 | 重大な阻害要因がない。 | 実装、修正、またはリリースへ進む。 |
| CONDITIONAL GOで一致 | 必須修正はあるが、実装開始を止めるほどではない。 | Must修正をv1.1等へ反映して進む。 |
| NO-GO原因が具体化 | 止める理由が明確で、修正タスクに分解済み。 | Blockerを修正して再レビューする。 |
| Laterのみ残存 | 残課題が実装開始可否に直結しない。 | 後続課題として管理する。 |
| 3ラウンド到達 | AI同士で収束しない。 | 人間判断へエスカレーションする。 |
| 事業判断が必要 | 技術だけで決められない。 | 最終承認者が判断する。 |
4. 判定ラベルの定義
レビュー結果では、必ず以下のラベルを使う。ラベルを統一することで、CodexとOpusの回答を比較しやすくなる。
| ラベル | 意味 | 典型例 |
|---|---|---|
| GO | このまま進んでよい。 | 重大な矛盾や未確認事項がない。 |
| CONDITIONAL GO | 条件付きで進んでよい。 | Must修正はあるが、Blockerではない。 |
| NO-GO | 進んではいけない。 | DDL不整合、重大なセキュリティ欠陥、受入基準欠落など。 |
| ESCALATE | AIでは決めきれない。 | 事業リスク、法務判断、費用対効果、責任者判断。 |
| 指摘区分 | 意味 | 対応 |
|---|---|---|
| Blocker | 直さないと進めない。 | 実装前に必ず修正する。 |
| Must | v1.1等に必ず反映する。 | 直近改訂で対応する。 |
| Should | 反映が望ましい。 | 時間があれば直近、なければ次版。 |
| Later | 後続でよい。 | 課題台帳に移す。 |
| Reject | 採用しない。 | 理由を残して終了。 |
| Escalate | 人間判断が必要。 | 最終承認者に回す。 |
5. ファイル運用ルール
Claude Codeで使う場合、レビュー結果をファイルとして保存しておくと、次ラウンドで比較しやすくなる。どのプロジェクトでも、以下のようなディレクトリを作ることを推奨する。
| ファイル/ディレクトリ | 用途 |
|---|---|
_reviews/ |
レビュー結果の保存先。 |
_reviews/round1_codex.md |
Codex初回レビュー。 |
_reviews/round1_opus.md |
Opus再分析。 |
_reviews/round2_codex.md |
Codex再レビュー。 |
_reviews/round2_opus.md |
Opus再判定。 |
_reviews/final_decision.md |
最終判定。 |
_reviews/review_issues.csv |
指摘台帳。必要に応じて作成する。 |
_reviews/human_decisions.md |
人間判断が必要な論点。 |
6. コピー用プロンプト一覧
ここから下は、Claude Codeでそのままコピーして使えるプロンプトである。各プロンプトには、コピー開始とコピー終了を明示している。
6.1 Round 1-A: Codex独立レビュー用プロンプト
以下は、まずCodexにレビューさせるためのプロンプトである。Opusの意見を先に見せず、Codexに独立レビューをさせる。
コピー開始: Codex独立レビュー用プロンプト
あなたは、プロジェクト横断で設計・要件・実装計画をレビューする上級レビュー担当者です。
以下の入力ファイルを読み、対象プロジェクトが安全に次工程へ進める状態かを独立レビューしてください。既存の結論に引きずられず、実ファイル、仕様、制約、一次ソースを優先して判断してください。
# 入力ファイル
- レビュー対象ファイル: [ここに対象ファイルパスを書く]
- 関連設計書: [必要に応じてファイルパスを書く]
- 関連DDL/schema/API仕様: [必要に応じてファイルパスを書く]
- 既存レビューまたは前提資料: [必要に応じてファイルパスを書く]
- プロジェクト固有ルール: [必要に応じてファイルパスを書く]
# レビュー目的
このレビューの目的は、対象プロジェクトを次工程へ進めてよいかを判断することです。次工程とは、実装開始、計画書改訂、テスト開始、リリース判断など、今回のプロジェクトで定義された次の行動を指します。
# 必ず確認すること
1. レビュー対象に矛盾、抜け漏れ、曖昧な判断基準がないか。
2. 実ファイル、DDL、schema、API仕様、設定値と文書の内容が一致しているか。
3. 外部仕様や一次ソースに依存する場合、根拠が妥当か。
4. 実装開始または次工程移行を止めるべきBlockerがあるか。
5. 追加すべきMust修正、Should修正、Later課題があるか。
6. 指摘が過剰設計になっていないか。
# 判定ラベル
全体判定は以下のいずれかにしてください。
- GO: 重大な阻害要因はなく、次工程へ進んでよい。
- CONDITIONAL GO: 次工程へ進んでよいが、直近で反映すべきMust修正がある。
- NO-GO: 次工程へ進む前に解消すべきBlockerがある。
- ESCALATE: 技術判断だけでは決められず、人間の最終判断が必要。
# 指摘区分
各指摘は以下のいずれかに分類してください。
- Blocker: 直さないと次工程へ進めない。
- Must: 直近改訂で必ず反映する。
- Should: 反映が望ましい。
- Later: 後続でよい。
- Reject: 採用不要。
- Escalate: 人間判断が必要。
# 出力形式
以下の構成で出力してください。
## 1. 全体判定
GO / CONDITIONAL GO / NO-GO / ESCALATE のいずれかで判定してください。
## 2. 判定理由
実ファイル、仕様、一次ソース、プロジェクト目的との関係に基づいて説明してください。
## 3. 指摘一覧
| No | 区分 | 指摘内容 | 根拠 | 影響 | 推奨対応 | 対象ファイル |
|---:|---|---|---|---|---|---|
## 4. Blocker一覧
Blockerがない場合は「なし」と明記してください。
## 5. Must / Should / Later一覧
| 区分 | 論点 | 対応方針 | 対象ファイル |
|---|---|---|---|
## 6. 次工程へ進むための最小修正
NO-GOまたはCONDITIONAL GOの場合、GOに近づけるための最小修正を示してください。
## 7. 人間判断が必要な事項
事業判断、法務判断、費用判断、責任者判断が必要な事項を整理してください。
## 8. 再レビュー時に確認すべき観点
次にOpusまたは人間が確認すべき観点を示してください。
# 制約
- 一般論だけでNO-GOにしないでください。
- NO-GOにする場合は、実ファイル、仕様、一次ソース、または明確なプロジェクト制約に基づくBlockerを示してください。
- 新しい理想論を増やしすぎず、次工程に影響する論点を優先してください。
コピー終了: Codex独立レビュー用プロンプト
6.2 Round 1-B: Opus再分析・accept/reject判定プロンプト
以下は、Codexのレビュー結果をOpusに再分析させるためのプロンプトである。Codexの回答を鵜呑みにせず、各指摘をACCEPT / MODIFY / REJECT / HOLDで判定させる。
コピー開始: Opus再分析プロンプト
あなたは、プロジェクト横断で使える上級要件・設計レビュー担当者です。
前提として、Codexの独立レビューは完了しています。ただし、Codexの回答は鵜呑みにせず、必ずあなた自身が実ファイル、一次ソース、プロジェクト目的、既存ルールを確認したうえで、各指摘に対して ACCEPT / MODIFY / REJECT / HOLD の判定を行ってください。
今回のレビューは1回で終了しません。CodexとOpusの判断が一致しない場合、またはNO-GO / CONDITIONAL GOが出た場合は、最大3ラウンドまで反復レビューを行い、判断を収束させます。
ただし、目的は文書を完璧にすることではありません。目的は、対象プロジェクトを安全に次工程へ進める状態にすることです。したがって、反復レビューは「次工程への移行可否に影響する論点」に限定してください。
# 入力ファイル
- Codexレビュー結果: [例: _reviews/round1_codex.md]
- レビュー対象ファイル: [ここに対象ファイルパスを書く]
- 関連設計書: [必要に応じてファイルパスを書く]
- 関連DDL/schema/API仕様: [必要に応じてファイルパスを書く]
- プロジェクト固有ルール: [必要に応じてファイルパスを書く]
- 一次ソースまたは公式ドキュメント: [必要に応じてURLまたはメモを書く]
# 今回の目的
Codexのレビュー結果について、Opus自身が再分析し、対象プロジェクトを次工程へ進めてよいかを判断してください。また、計画書、要件定義、設計書、DDL、schema、API仕様などを改訂すべき場合は、改訂範囲を最小限に絞って提示してください。
# 判定ルール
各Codex指摘に対して、以下のいずれかで判定してください。
- ACCEPT: 事実確認でき、直近改訂にそのまま反映すべき。
- MODIFY: 指摘の方向性は正しいが、表現、範囲、優先度、実装時期を調整して反映すべき。
- REJECT: 事実誤認、過剰設計、現段階では不要、またはプロジェクト目的に合わない。
- HOLD: 判断に必要な一次情報や実ファイル確認が不足しており、追加確認が必要。
# ラウンド全体の判定区分
- GO: 重要な阻害要因はなく、次工程へ進んでよい。
- CONDITIONAL GO: 次工程へ進んでよいが、直近改訂に反映すべきMust修正がある。
- NO-GO: 次工程へ進む前に解消しなければならないBlockerがある。
- ESCALATE: CodexとOpusで判断が割れており、人間の意思決定が必要。
# 指摘の重要度分類
- Blocker: これを直さないと次工程へ進んではいけない。
- Must: 直近改訂に必ず反映する。
- Should: 直近改訂に入れるのが望ましいが、次工程移行の絶対条件ではない。
- Later: 後続フェーズでよい。
- Reject: 今回は採用しない。
- Escalate: 人間判断が必要。
# 反復レビューの終了条件
以下のいずれかを満たした時点でレビューを終了してください。
1. CodexとOpusの最終判定がGOまたはCONDITIONAL GOで一致した。
2. NO-GOの原因が具体的な修正タスクに分解され、直近改訂で修正可能と判断できた。
3. 残論点が次工程移行に直接影響しないLater項目だけになった。
4. 最大3ラウンドに到達した。
5. 人間、つまり最終承認者の判断が必要な論点に到達した。
# NO-GOが出た場合の処理
NO-GOが出た場合、単に「NO-GO」と結論づけて終わらないでください。必ず以下を出力してください。
1. NO-GOの原因。
2. 実ファイルまたは一次ソースで確認できた根拠。
3. 次工程移行を止めるほど重大な理由。
4. GOまたはCONDITIONAL GOに戻すための最小修正。
5. 修正対象ファイル。
6. 修正後に再レビューすべき観点。
7. Codexに再レビューさせるための追加プロンプト。
# 意見不一致時の処理
CodexとOpusの判断が一致しない場合、以下の表を作成してください。
| 論点 | Codex判定 | Opus判定 | 一致/不一致 | 事実確認結果 | 次工程への影響 | 推奨判断 | 人間判断要否 |
|---|---|---|---|---|---|---|---|
不一致が残る場合でも、以下の条件を満たすならCONDITIONAL GOとしてよいです。
- 不一致論点が次工程直後の破綻につながらない。
- 修正または確認をMust / Should / Laterに分類できる。
- Blockerが残っていない。
- 人間が後から判断できる形で論点が記録されている。
# 出力形式
以下の構成で出力してください。
## 1. ラウンド判定
今回がRound 1 / Round 2 / Round 3のどれに該当するかを明記し、GO / CONDITIONAL GO / NO-GO / ESCALATEのいずれかで判定してください。
## 2. 結論
Codex回答を総合して、次工程へ進んでよいかを説明してください。Blockerが残っているか、Must修正で済むか、人間判断が必要かを明確にしてください。
## 3. Codex指摘ごとのaccept/reject判定表
| No | Codex指摘 | Opus判定 | 重要度 | 根拠 | 反映方針 | 備考 |
|---:|---|---|---|---|---|---|
## 4. 実ファイル・一次ソース確認結果
確認できた事実と、確認できなかった事項を分けて整理してください。
## 5. 重要論点の事実確認
Codexが重要指摘として挙げた論点について、実ファイルまたは一次ソースで確認し、事実 / 不明 / 誤り のいずれかで判定してください。必要な場合は修正文案も提示してください。
## 6. 過剰設計リスクの評価
Codexの提案が安全性向上なのか、紙の議論を増やすだけなのかを評価してください。
| 論点 | 実装安全性への寄与 | プロジェクト目的への直接関係 | 過剰設計リスク | 反映必要性 | 理由 |
|---|---|---|---|---|---|
## 7. Blocker / Must / Should / Later / Reject / Escalate一覧
| 区分 | 論点 | 対応方針 | 対象ファイル | 次アクション |
|---|---|---|---|---|
## 8. CodexとOpusの一致状況
| 論点 | Codex判定 | Opus判定 | 状態 | 備考 |
|---|---|---|---|---|
## 9. 改訂方針
直近改訂に反映する項目を、Must / Should / Laterに分けてください。
| 区分 | 反映項目 | 理由 | 対象ファイル |
|---|---|---|---|
## 10. 最終承認者向けの簡単な説明
専門用語を避け、今回のCodexレビュー結果とOpus再分析の結論を、高校生にも分かる言葉で説明してください。
必ず以下を含めてください。
- Codexの意見をそのまま信じなかった理由。
- 重要論点の確認がなぜ必要だったか。
- 今すぐ直すことと、後でよいこと。
- 最終的に次工程へ進んでよいか。
- もしGOできない場合、何を直せばGOに戻るか。
## 11. 具体的な修正文案
直近改訂に反映すべき文章、表、命名規則、DDL修正案、テスト観点などがあれば、コピペ可能な形で提示してください。
## 12. 残課題
今回の再分析後も残る未決事項、追加確認事項、後続レビュー項目を整理してください。
## 13. 次ラウンドが必要か
次ラウンドが必要 / 不要 / 人間判断へ移行 のいずれかで判定してください。
## 14. 次にCodexに渡すプロンプト
次ラウンドが必要な場合のみ、Codexにそのまま渡せるプロンプトを作成してください。次ラウンドが不要な場合は、以下のように明記してください。
「次ラウンド不要。理由: Blockerが残っておらず、残論点はMust / Should / Laterに分類済みであるため。」
# 最重要指示
Codexの結論に同意する場合でも、必ずOpus自身の根拠を示してください。逆にCodexの指摘を却下する場合も、感覚ではなく、実ファイル、一次ソース、プロジェクト目的との関係から説明してください。
レビューを重ねる場合でも、論点を無限に増やさないでください。レビューの目的は、次工程へ進めるかを判断することです。3ラウンドを超えても一致しない場合は、意見不一致表を作成し、最終承認者へエスカレーションしてください。
コピー終了: Opus再分析プロンプト
6.3 Round 2-A: Codex再レビュー用プロンプト
以下は、Opusの再分析をCodexに戻し、再確認させるためのプロンプトである。新しい論点を増やしすぎないよう、既存論点の同意・反論・修正に限定する。
コピー開始: Codex再レビュー用プロンプト
あなたは、前回レビューを行ったCodexレビュー担当者です。
今回は新規レビューではありません。Opusがあなたのレビュー結果を再分析し、各指摘に対して ACCEPT / MODIFY / REJECT / HOLD の判定を行いました。あなたの役割は、Opus判定を確認し、同意、反論、修正提案、または追加根拠の提示を行うことです。
# 入力ファイル
- Codex初回レビュー: [例: _reviews/round1_codex.md]
- Opus再分析結果: [例: _reviews/round1_opus.md]
- レビュー対象ファイル: [ここに対象ファイルパスを書く]
- 関連ファイル: [必要に応じてファイルパスを書く]
# 今回の目的
Opusの判定に対して、Codexとして同意できるか、反論すべきか、修正案を出すべきかを確認してください。目的は、CodexとOpusの判断を収束させ、対象プロジェクトを次工程へ進めてよいかを判断することです。
# 厳守する制約
- 新しい論点を無制限に増やさないでください。
- 既存論点の事実確認、反論、同意、修正提案に集中してください。
- 次工程移行に直接関係しない改善はLaterに分類してください。
- NO-GOとする場合は、必ず実ファイルまたは一次ソースに基づくBlockerを示してください。
- 一般論だけでNO-GOにしないでください。
- OpusがREJECTした論点を再主張する場合は、新しい根拠を示してください。
- OpusがACCEPT済みの論点は、原則として再議論しないでください。
# 判定ラベル
各論点について、以下のいずれかで判定してください。
- AGREE: Opus判定に同意する。
- DISAGREE: Opus判定に反対する。
- MODIFY: Opus判定の方向性には同意するが、範囲や優先度を調整すべき。
- NEEDS EVIDENCE: 追加の実ファイル確認または一次ソース確認が必要。
- ESCALATE: 人間判断が必要。
# 全体判定
全体として、以下のいずれかを出してください。
- GO: 次工程へ進んでよい。
- CONDITIONAL GO: Must修正を反映すれば進んでよい。
- NO-GO: Blockerが残っており、進んではいけない。
- ESCALATE: AI同士では判断できず、人間判断が必要。
# 出力形式
以下の構成で出力してください。
## 1. Codex再レビュー判定
GO / CONDITIONAL GO / NO-GO / ESCALATE のいずれか。
## 2. Opus判定への回答一覧
| 論点 | Opus判定 | Codex再判定 | 理由 | 追加根拠 | 推奨対応 |
|---|---|---|---|---|---|
## 3. Codexが同意する点
Opus判定のうち同意するものを整理してください。
## 4. Codexが反論する点
反論する場合は、必ず実ファイル、一次ソース、明確なプロジェクト制約のいずれかを根拠にしてください。
## 5. 修正すべき優先度
| 区分 | 論点 | 理由 | 対象ファイル |
|---|---|---|---|
区分は、Blocker / Must / Should / Later / Reject / Escalate のいずれかにしてください。
## 6. 新たなBlockerの有無
新たなBlockerがない場合は「なし」と明記してください。ある場合は、なぜ前回見落とされたのかも説明してください。
## 7. Opus最終判定で確認すべきこと
次にOpusが最終判定する際に確認すべき観点を示してください。
コピー終了: Codex再レビュー用プロンプト
6.4 Round 2-B / Round 3: Opus最終判定プロンプト
以下は、Codex再レビューを受けて、Opusが最終判定または人間判断へのエスカレーションを行うためのプロンプトである。
コピー開始: Opus最終判定プロンプト
あなたは、プロジェクト横断の最終レビュー判定者です。
Codex初回レビュー、Opus再分析、Codex再レビューが完了しています。これ以上レビューを続けるべきか、次工程へ進むべきか、人間判断へ回すべきかを最終判定してください。
# 入力ファイル
- Codex初回レビュー: [例: _reviews/round1_codex.md]
- Opus再分析結果: [例: _reviews/round1_opus.md]
- Codex再レビュー結果: [例: _reviews/round2_codex.md]
- レビュー対象ファイル: [ここに対象ファイルパスを書く]
- 関連ファイル: [必要に応じてファイルパスを書く]
# 今回の目的
CodexとOpusの判断を比較し、対象プロジェクトを次工程へ進めてよいかを最終判定してください。判断が一致しない論点が残る場合は、追加AIレビューを続けるのではなく、人間判断に回すべきかを決めてください。
# 最終判定区分
- GO: 重大な阻害要因はなく、次工程へ進んでよい。
- CONDITIONAL GO: Must修正を反映すれば、次工程へ進んでよい。
- NO-GO: Blockerが残っており、次工程へ進んではいけない。
- ESCALATE: AI同士では判断できず、人間の最終判断が必要。
# 終了条件
以下のいずれかに該当する場合、レビューを終了してください。
1. Blockerがない。
2. 残論点がMust / Should / Laterに分類済みである。
3. NO-GO原因が具体的な修正タスクに分解済みである。
4. CodexとOpusの不一致が人間判断事項として整理できている。
5. 3ラウンドに到達している。
# 出力形式
以下の構成で出力してください。
## 1. 最終判定
GO / CONDITIONAL GO / NO-GO / ESCALATE のいずれか。
## 2. 最終判定理由
実ファイル、一次ソース、プロジェクト目的、CodexとOpusの一致状況を踏まえて説明してください。
## 3. CodexとOpusの一致・不一致表
| 論点 | Codex最終見解 | Opus最終見解 | 一致/不一致 | 最終扱い | 理由 |
|---|---|---|---|---|---|
## 4. 最終Blocker一覧
Blockerがない場合は「なし」と明記してください。
## 5. Must / Should / Later / Reject / Escalate一覧
| 区分 | 論点 | 対応方針 | 対象ファイル | 担当または判断者 |
|---|---|---|---|---|
## 6. 次工程へ進むための最小修正
CONDITIONAL GOまたはNO-GOの場合、必要な最小修正を明記してください。
## 7. 人間判断事項
| 論点 | 判断が必要な理由 | 選択肢 | 推奨案 | 判断者 |
|---|---|---|---|---|
## 8. 最終承認者向けの簡単な説明
専門用語を避け、今回のレビュー結果を高校生にも分かる言葉で説明してください。
## 9. 追加レビューの要否
追加レビューが必要か不要かを明記してください。原則として、3ラウンド到達後は追加AIレビューではなく人間判断へ移行してください。
## 10. 保存すべき最終成果物
レビュー結果、指摘台帳、修正方針、人間判断事項として保存すべきファイル名を提案してください。
コピー終了: Opus最終判定プロンプト
6.5 人間・社長向け説明生成プロンプト
以下は、レビュー結果を最終承認者に説明するためのプロンプトである。専門用語を避け、実務判断に必要な内容だけを簡潔に説明させる。
コピー開始: 人間・社長向け説明生成プロンプト
あなたは、技術レビュー結果を非エンジニアの最終承認者に説明するPMです。
以下のレビュー結果を読み、専門用語をできるだけ使わず、高校生にも分かる言葉で説明してください。
# 入力ファイル
- 最終レビュー結果: [例: _reviews/final_decision.md]
- 指摘台帳: [必要に応じてファイルパスを書く]
- 修正方針: [必要に応じてファイルパスを書く]
# 出力目的
最終承認者が、次工程へ進んでよいか、何を今すぐ直すべきか、何を後回しにしてよいかを判断できるようにすることです。
# 必ず含めること
1. 今回何をレビューしたのか。
2. CodexとOpusの意見が一致したのか。
3. そのまま進んでよいのか、条件付きなのか、止めるべきなのか。
4. 今すぐ直すべきこと。
5. 後でよいこと。
6. 人間が判断すべきこと。
7. 放置した場合のリスク。
8. 推奨する次の行動。
# 出力形式
## 1. 一言でいうと
## 2. 今回確認したこと
## 3. 結論
GO / CONDITIONAL GO / NO-GO / ESCALATE の意味を、分かりやすく説明してください。
## 4. 今すぐ直すこと
## 5. 後でよいこと
## 6. 最終承認者に決めてほしいこと
## 7. 推奨アクション
# 制約
- 専門用語を使う場合は必ず簡単に説明してください。
- 不安を煽らず、判断に必要な事実を整理してください。
- AIの意見を絶対視せず、人間の最終判断を尊重してください。
コピー終了: 人間・社長向け説明生成プロンプト
7. 実務での使い方
実務では、以下の順番で運用する。まず、対象ファイルと目的を明確にする。次に、Codexに独立レビューをさせる。その後、OpusにCodexレビューを再分析させる。Opusが次ラウンド必要と判断した場合のみ、Codex再レビューを実施する。最後にOpusが最終判定を出し、必要なら人間向け説明を作成する。
| 手順 | 操作 | 保存先例 |
|---|---|---|
| 1 | 対象ファイルと目的を決める。 | _reviews/review_scope.md |
| 2 | Codex独立レビュー用プロンプトを実行する。 | _reviews/round1_codex.md |
| 3 | Opus再分析プロンプトを実行する。 | _reviews/round1_opus.md |
| 4 | 必要ならCodex再レビュー用プロンプトを実行する。 | _reviews/round2_codex.md |
| 5 | Opus最終判定プロンプトを実行する。 | _reviews/final_decision.md |
| 6 | 人間・社長向け説明を生成する。 | _reviews/executive_summary.md |
| 7 | Must修正を反映し、必要に応じて再レビューする。 | 修正版ドキュメント |
8. 運用上の注意
CodexとOpusの反復レビューは強力だが、使い方を誤ると、指摘が増え続けてプロジェクトが進まなくなる。そのため、レビュー対象を毎回明確にし、終了条件を必ず設定する必要がある。特に、実装開始可否に関係しない論点はLaterへ送るべきである。
良いレビューとは、指摘を無限に増やすことではなく、今進んでよいか、何を直せば進めるかを明確にすることである。
| 悪い運用 | 良い運用 |
|---|---|
| 新しい論点を毎回増やす。 | 既存論点の事実確認と収束を優先する。 |
| 一般論だけでNO-GOにする。 | 実ファイル、一次ソース、プロジェクト制約に基づいて判断する。 |
| 3回以上AI同士で議論させる。 | 3ラウンドで止め、人間判断に回す。 |
| すべてをMustにする。 | Blocker、Must、Should、Laterを分ける。 |
| 文書を完璧にしようとする。 | 次工程に進むための最小修正を決める。 |
9. 最小運用版
時間がない場合は、以下の最小運用でよい。すべてのプロンプトを使わなくても、Codex独立レビューとOpus再分析だけでかなりの品質向上が見込める。
| 状況 | 使うプロンプト |
|---|---|
| 30分で確認したい | Codex独立レビュー → Opus再分析 |
| NO-GOが出た | Opus再分析 → Codex再レビュー → Opus最終判定 |
| 最終承認者に説明したい | 人間・社長向け説明生成プロンプト |
| 判断が割れた | Opus最終判定プロンプトでESCALATE整理 |
10. 汎用テンプレートとして置換する項目
このテンプレートを各プロジェクトに使う場合、以下のプレースホルダーだけ置き換えればよい。
| プレースホルダー | 置き換える内容 |
|---|---|
[ここに対象ファイルパスを書く] |
要件定義書、設計書、DDL、計画書など。 |
[必要に応じてファイルパスを書く] |
関連する補助資料、ログ、レビュー結果など。 |
[例: _reviews/round1_codex.md] |
実際に保存したレビュー結果ファイル。 |
次工程 |
実装開始、設計確定、テスト開始、リリースなど。 |
最終承認者 |
社長、PM、PO、CTO、法務責任者など。 |
一次ソース |
公式ドキュメント、規約、標準仕様、実ファイルなど。 |
11. 推奨する最終保存物
最終的には、レビュー結果を口頭で終わらせず、以下のファイルを残すことを推奨する。
| ファイル名 | 内容 |
|---|---|
_reviews/final_decision.md |
最終判定、理由、Blocker有無、次アクション。 |
_reviews/review_issue_register.md |
指摘台帳。 |
_reviews/human_decisions.md |
人間判断が必要な論点。 |
_reviews/executive_summary.md |
最終承認者向け説明。 |
_reviews/review_history.md |
Roundごとの判定履歴。 |
12. まとめ
この汎用フローの本質は、AIレビューを一発勝負にしないことである。Codexに独立レビューをさせ、Opusに再分析をさせ、必要に応じてCodexに戻し、最後はOpusまたは人間が判断する。この流れにより、AIの指摘を有効活用しながら、過剰設計や誤判定を抑えられる。
最も大切なのは、GO / CONDITIONAL GO / NO-GO / ESCALATEを明確に分けることである。Blockerがあるなら止める。Must修正で済むなら条件付きで進める。判断が割れるなら人間に回す。この原則を守れば、どのプロジェクトでもClaude Code上で安定したレビュー運用ができる。