Codex ⇄ Opus 反復レビュー・収束プロトコル適用版 Opus再分析プロンプト

以下をそのまま Opus に渡してください。

あなたは、グロクロ準拠の上級要件レビュー担当者です。

前提として、Codex の独立レビューは完了しています。ただし、Codex の回答は鵜呑みにせず、必ずあなた自身が一次ソース、実物ファイル、既存ルールを確認したうえで、各指摘に対して ACCEPT / REJECT / MODIFY / HOLD の判定を行ってください。

今回のレビューは1回で終了しません。Codex と Opus の判断が一致しない場合、または NO-GO / CONDITIONAL GO が出た場合は、最大3ラウンドまで反復レビューを行い、判断を収束させます。

ただし、目的は紙の議論を完璧にすることではありません。目的は、micro-PoC-A を安全に実装開始できる状態にすることです。したがって、反復レビューは「実装開始可否に影響する論点」に限定してください。

# 1. 入力ファイル

以下のファイルを確認してください。

- Codex レビュー結果:
  _codex_reviews/2026-05-22_micro-PoC-A_stage_review_codex_response.md
- 現行計画書 v1.0:
  該当する micro-PoC-A / Stage 計画書
- DDL / schema 定義ファイル:
  stage_id enum または stage 管理に関係する実ファイル
- codex-review.md:
  Codex レビュー結果の扱い方、accept/reject 判定ルール、グロクロ準拠ルール
- 関連する一次ソース:
  SQLite 公式ドキュメント
  Anthropic 公式ドキュメント
  その他、Codex が根拠として挙げた公式情報

# 2. 今回の目的

Codex の暫定回答について、Opus 自身が再分析し、計画書 v1.0 を v1.1 に改訂すべきかどうか、また改訂するならどの範囲まで反映すべきかを判断してください。

さらに、Codex と Opus の判断が一致しない場合、または NO-GO / CONDITIONAL GO が出た場合は、次ラウンドで Codex に再確認させるためのプロンプトを必ず作成してください。

# 3. Codex の暫定回答要約

- 判定: GO。ただし v1.1 改訂が必要。
- Opus 推奨 C 案、すなわち Stage 4 + 5b + 6 + 13 は ACCEPT。
- 重要指摘: Codex DDL の stage_id enum に stage_05b が存在しない可能性がある。命名規則の明文化が必要。
- Must 8 項目を Must 12 項目へ統合する提案がある。

# 4. 必ず確認すること

1. Codex の根拠が一次ソースに裏付けられているか確認してください。特に SQLite 公式、Anthropic 公式、プロジェクト内の実ファイルを優先してください。
2. 「stage_05b enum 未許容」という指摘が事実か、DDL または schema の実物を確認してください。推測で判断しないでください。
3. Stage 4 + 5b + 6 + 13 の C 案が、現行計画の目的、制約、依存関係、実装順序に照らして妥当か確認してください。
4. Must 8 項目から Must 12 項目への統合提案が、本当に実装前に必要な安全策なのか、それとも紙の議論を増やす過剰設計なのかを判定してください。
5. v1.1 改訂が必要な場合でも、改訂範囲は最小限にしてください。目的は文書を完璧にすることではなく、実装の失敗リスクを下げることです。

# 5. 判定ルール

各 Codex 指摘に対して、以下のいずれかで判定してください。

- ACCEPT: 事実確認でき、v1.1 にそのまま反映すべき。
- MODIFY: 指摘の方向性は正しいが、表現、範囲、優先度を調整して反映すべき。
- REJECT: 事実誤認、過剰設計、現段階では不要、または目的に合わない。
- HOLD: 判断に必要な一次情報が不足しており、追加確認が必要。

# 6. ラウンド全体の最終判定区分

各ラウンドの最終判定は、以下のいずれかにしてください。

- GO: 重要な阻害要因はなく、実装開始してよい。
- CONDITIONAL GO: 実装開始してよいが、v1.1 に反映すべき必須修正がある。
- NO-GO: 実装開始前に解消しなければならない重大な欠陥がある。
- ESCALATE: Codex と Opus で判断が割れており、人間の意思決定が必要。

# 7. 指摘の重要度分類

Codex または Opus の指摘は、以下の区分で整理してください。

- Blocker: これを直さないと実装開始してはいけない。
- Must: v1.1 に必ず反映する。
- Should: v1.1 に入れるのが望ましいが、実装開始の絶対条件ではない。
- Later: 後続フェーズでよい。
- Reject: 今回は採用しない。
- Escalate: 人間判断が必要。

# 8. Codex ⇄ Opus 反復レビュー・収束プロトコル

今回のレビューは、最大3ラウンドまで反復可能とします。

## 8.1 ラウンド定義

- Round 1: Codex 初回レビューに対する Opus 再分析。
- Round 2: Opus の ACCEPT / MODIFY / REJECT / HOLD 判定を Codex に再確認させる。
- Round 3: Codex 再回答に対する Opus 最終判定。

Round 3 でも判断が一致しない場合は、追加レビューを続けず、意見不一致表を作成して人間判断に回してください。

## 8.2 反復レビューの終了条件

以下のいずれかを満たした時点でレビューを終了してください。

1. Codex と Opus の最終判定が GO または CONDITIONAL GO で一致した。
2. NO-GO の原因が具体的な修正タスクに分解され、v1.1 で修正可能と判断できた。
3. 残論点が micro-PoC-A の実装開始可否に直接影響しない Later 項目だけになった。
4. 最大3ラウンドに到達した。
5. 人間、つまり社長または最終承認者の判断が必要な論点に到達した。

## 8.3 NO-GO が出た場合の処理

NO-GO が出た場合、単に「NO-GO」と結論づけて終わらないでください。必ず以下を出力してください。

1. NO-GO の原因。
2. 実ファイルまたは一次ソースで確認できた根拠。
3. 実装開始を止めるほど重大な理由。
4. GO または CONDITIONAL GO に戻すための最小修正。
5. 修正対象ファイル。
6. 修正後に再レビューすべき観点。
7. Codex に再レビューさせるための追加プロンプト。

## 8.4 意見不一致時の処理

Codex と Opus の判断が一致しない場合、以下の表を作成してください。

| 論点 | Codex 判定 | Opus 判定 | 一致/不一致 | 事実確認結果 | 実装開始への影響 | 推奨判断 | 人間判断要否 |
|---|---|---|---|---|---|---|---|

不一致が残る場合でも、以下の条件を満たすなら CONDITIONAL GO としてよいです。

- 不一致論点が実装開始直後の破綻につながらない。
- 修正または確認を v1.1 の Must / Should / Later に分類できる。
- Blocker が残っていない。
- 人間が後から判断できる形で論点が記録されている。

# 9. Codex 再レビュー用プロンプトの生成ルール

Opus の再分析結果の最後に、次に Codex に渡す再レビュープロンプトを必ず出力してください。ただし、次ラウンドが不要な場合は「次ラウンド不要」と明記してください。

Codex 再レビュープロンプトには、必ず以下を含めてください。

- Opus が ACCEPT した指摘。
- Opus が MODIFY した指摘。
- Opus が REJECT した指摘。
- Opus が HOLD または ESCALATE にした指摘。
- Codex に再確認してほしい論点。
- Codex に新規論点を増やしすぎないようにする制約。
- Codex が GO / CONDITIONAL GO / NO-GO のいずれで判断すべきか。

# 10. Codex 再レビュー時の制約

Codex に再レビューさせる場合は、以下の制約を必ず課してください。

- 新しい論点を無制限に増やさない。
- 既存論点の事実確認、反論、同意、修正提案に集中する。
- micro-PoC-A の実装開始可否に直接関係しない改善は Later に分類する。
- NO-GO とする場合は、必ず実ファイルまたは一次ソースに基づく Blocker を示す。
- 一般論だけで NO-GO にしない。
- すでに Opus が REJECT した論点を再主張する場合は、新しい根拠を示す。
- すでに ACCEPT 済みの論点は、原則として再議論しない。

# 11. 特に重視する判断基準

- 実ファイルで確認できる事実を最優先する。
- 一次ソースで確認できない一般論は、根拠として弱く扱う。
- micro-PoC-A の目的に直接関係しない改善は、原則として後続課題へ回す。
- 「実装を安全に始めるために必要な最低限」と「文書を完璧にするための追加論点」を分ける。
- 社長に説明する前提で、高校生にも分かる言葉に翻訳できる判断にする。
- 3ラウンドを超えても判断が一致しない場合は、AI同士の議論を続けず、人間判断へエスカレーションする。

# 12. 出力形式

以下の構成で出力してください。

## 1. ラウンド判定

今回が Round 1 / Round 2 / Round 3 のどれに該当するかを明記し、GO / CONDITIONAL GO / NO-GO / ESCALATE のいずれかで判定してください。

あわせて、計画書 v1.1 改訂が必要か、必要ならどの範囲かを明記してください。

## 2. 結論

Codex 回答を総合して、実装開始してよいかを説明してください。単なる賛否ではなく、Blocker が残っているか、Must 修正で済むか、人間判断が必要かを明確にしてください。

## 3. Codex 指摘ごとの accept/reject 判定表

次の表形式で整理してください。

| No | Codex 指摘 | Opus 判定 | 重要度 | 根拠 | v1.1 反映方針 | 備考 |
|---:|---|---|---|---|---|---|

## 4. 一次ソース・実ファイル確認結果

SQLite 公式、Anthropic 公式、DDL / schema 実ファイル、codex-review.md などを確認した結果を整理してください。確認できた事実と、確認できなかった事項を分けてください。

## 5. stage_05b enum 指摘の事実確認

DDL または schema の実物を確認し、stage_05b が許容されているかどうかを明確に判定してください。

判定は以下のいずれかにしてください。

- 事実: stage_05b が未許容であり、修正が必要。
- 事実: stage_05b は許容済みであり、Codex 指摘は不要。
- 不明: 対象ファイルを特定できず、追加確認が必要。

必要な場合は、修正文案も提示してください。

## 6. Must 8 → Must 12 統合提案の評価

Must 12 項目への拡張について、以下の観点で評価してください。

| 観点 | 評価 | 理由 |
|---|---|---|
| 実装安全性への寄与 | 高/中/低 |  |
| micro-PoC-A への直接関係 | 高/中/低 |  |
| 過剰設計リスク | 高/中/低 |  |
| v1.1 反映必要性 | 必須/一部/不要/保留 |  |

結論として、Must 8 のまま維持するのか、Must 12 にするのか、一部だけ取り込むのかを明記してください。

## 7. Blocker / Must / Should / Later / Reject / Escalate 一覧

| 区分 | 論点 | 対応方針 | 対象ファイル | 次アクション |
|---|---|---|---|---|

## 8. Codex と Opus の一致状況

| 論点 | Codex 判定 | Opus 判定 | 状態 | 備考 |
|---|---|---|---|---|

状態は、一致 / 不一致 / 要追加確認 / 人間判断 のいずれかにしてください。

## 9. v1.1 改訂方針

v1.1 に反映する項目を、Must / Should / Later に分けてください。

| 区分 | 反映項目 | 理由 | 対象ファイル |
|---|---|---|---|

## 10. 社長向けの高校生説明

専門用語を避け、今回の Codex レビュー結果と Opus 再分析の結論を高校生にも分かる言葉で説明してください。

必ず以下を含めてください。

- Codex の意見をそのまま信じなかった理由。
- stage_05b の確認がなぜ重要か。
- Must 8 を Must 12 に増やすべきかどうか。
- 今すぐ直すことと、後でよいこと。
- 最終的に GO してよいか。
- もし GO できない場合、何を直せば GO に戻るか。

## 11. 計画書 v1.1 への具体的な修正文案

v1.1 に反映すべき文章、表、命名規則、DDL 修正案があれば、コピペ可能な形で提示してください。

## 12. 残課題

今回の再分析後も残る未決事項、追加確認事項、後続レビュー項目を整理してください。

## 13. 次ラウンドが必要か

次ラウンドが必要 / 不要 / 人間判断へ移行 のいずれかで判定してください。

必要な場合は、なぜ必要か、何を Codex に再確認させるかを明記してください。

## 14. 次に Codex に渡すプロンプト

次ラウンドが必要な場合のみ、Codex にそのまま渡せるプロンプトを作成してください。

次ラウンドが不要な場合は、以下のように明記してください。

「次ラウンド不要。理由: Blocker が残っておらず、残論点は v1.1 Must / Should / Later に分類済みであるため。」

# 13. 最重要指示

Codex の結論に同意する場合でも、必ず Opus 自身の根拠を示してください。逆に Codex の指摘を却下する場合も、感覚ではなく、一次ソース、実ファイル、micro-PoC-A の目的との関係から説明してください。

レビューを重ねる場合でも、論点を無限に増やさないでください。レビューの目的は、実装開始可否を判断することです。3ラウンドを超えても一致しない場合は、意見不一致表を作成し、社長または最終承認者へエスカレーションしてください。