Codex 反復レビュー・ループ

codex:rescue(read-only)にレビューさせ、Claude が各指摘を実コードで検証して 修正/反証/受容/保留に仕分け、再レビューさせる反復ループ。日本語で報告する。

• 前段(レビュー): codex:codex-rescue サブエージェント(read-only)が指摘を出す
• 後段(判断): Claude が各指摘を実コード・仕様書と照合し、修正/反証/受容/保留に仕分ける (判断ロジックの正本は review-loop-judgement スキル)
• Codex は編集しない(修正は Claude が行う)。Codex 出力はそのまま信じず裏取りする

レビュアーの正体に依らない判断ロジックは review-loop-judgement スキルを見よ。 codex を起動してから結果を受け取るまでのハング防止契約は codex-watchdog スキルを見よ。 このスキルはその上に、レビューループ固有の合否解釈・再試行上限・終了判定を定める。

ユーザー待ちを出さない(無プロンプト運用)

このループは許可プロンプト等のユーザー待ちを出さずに自走できることを設計目標にする。codex の 起動・監視まわりの無プロンプト運用(companion 起動 glob・watchdog 起動 glob)は codex-watchdog の無プロンプト運用 に従う。このスキルが追加で使う Bash コマンドは以下に限る:

• 照合: 読み取り専用コマンド(cat/sed -n/grep/rg/git 系)。検証ツール (docs/conventions/verification.md の各検査)はレビュー中に 実行しない(手順2: 照合・仕分けはコードの読解と読み取り専用コマンドで行う。検証はレビューループの外 (レビューループの呼び出し元)で別途担保する)
• 結果取得・修正・停止: Read / Edit / TaskStop ツール(プロンプト無し)

複合コマンド(A && B、until …; do …; done)やインラインのループは許可パターンに一致せず毎回 プロンプトを出す。新しいコマンドが要るときは狭いパターンで allow に追加してから使う (書き込み系・sed -i は登録しない)。

手順

手順0: 起動可否ゲート・対象確認・可用性確認

review-loop-judgement スキルの手順0のとおり 起動可否ゲートと対象を確認する。あわせて codex-watchdog スキルの使用不可の検知と再試行の とおり、前ラウンドで記憶した「使用不可」の状態が無いか確認してから手順1へ進む(自動復帰・ スキップの判定基準は同スキルが定める)。

手順1: レビュー実行(1ラウンド)

codex:codex-rescue エージェント(Agent ツール、 subagent_type: "codex:codex-rescue")を、codex-watchdog スキルの契約のとおりに 実行する(同スキルが定める契約全体に従う。一部だけを選んで適用しない)。node を Bash で直接叩かない(層違い。 companion の起動許可 glob はエージェント内部の node 実行を通すためのもので、呼び出し側の直打ち用 ではない)。

レビュー指示文には review-loop-judgement スキルのレビュー依頼に含めるべき内容をすべて 満たし、レビュー依頼に含めてはならない内容(検査をレビュアーに割り当てない・読む量や読み方を指定しない)に 反する記述を含めない上で、以下のレビュー固有の起動契約を追加する:

• 「codex を read-only で実行し --write を付けるな」を明示する(レビューでリポジトリを 編集させないため。実行時契約上 codex:rescue は既定で --write、read-only 明示時のみ 読み取り専用)。ただし注意: read-only にしても companion の task モードはジョブ状態ログを codex 起動前に無条件で書くため、--write の有無と無関係に EPERM になりうる(codex-watchdog のサンドボックス規約参照)。EPERM が出た場合はサンドボックスを切らず失敗として扱う。
• 「テスト・静的検査・リンク検査などの検証ツールは実行するな。指摘の検証はコードの読解と 読み取り専用コマンドの確認だけで行え」を明示する(read-only 指定はファイル編集を防ぐだけで、 テスト・検証コマンドの起動までは防がない。明示しなければレビュアーが自発的に実行しうるため、 この禁止は read-only 指定と別に明示が必須)。
• 出力契約(codex-watchdog のエージェント内部の実行契約に追加する形で明記): 「レビュー 結果を応答に必ず含めて返す。指摘があれば file:line＋内容＋根拠で列挙する。指摘が一つも無い 場合は、各観点について何を検査しどの実装/仕様と照合して問題なしと判断したかを観点ごとに具体的に 述べ、その確認結果を伴わせた上で指摘が無い旨を結論する」(観点ごとの確認結果の実体を必ず伴わせる ——確認内容の無い『問題なし』『指摘なし』の一言だけの応答は不可。実体があればゲートで検証でき 監査証跡になる)。

継続レビュー(2ラウンド目以降)

レビュアーの文脈を持つのは codex のスレッドなので、2ラウンド目以降はそのスレッドを継がせ、前ラウンドの 指摘・読んだファイル・受け取った観点を保ったままレビューさせる。エージェント自体は毎ラウンド新規に 起動する(codex:codex-rescue は task を1回転送するだけのラッパーで、レビューの記憶を持たない。転送する タスク指示文は要約・言い換えを禁じているので継続しても本文は短くならず、ラッパーを継続すると蓄積した トランスクリプトを毎ラウンド読み直す分だけトークンが増える)。

• スレッド継続で起動させる: タスク指示文に、前回の codex スレッドを継続する形で起動せよと明記する (codex 起動の作法のスレッド継続)。あわせて companion の出力を JSON 形式で受け取り、 応答に codex のレビュー本文とスレッドIDの両方を含めて返せと指示する(JSON 指定で止まるのは進捗の 標準エラー出力だけで、watchdog が見るジョブログは従来どおり書かれる)。
• 継いだスレッドを起動後に照合する(取り違え検出): 継ぐ相手は呼び出し側が選べないので、 ラウンドの間に別用途の codex 起動が挟まったり直前のラウンドが失敗していたりすると無関係なスレッドを 継ぎうる。 継ぐ回は、返ったスレッドIDが直近に採用したラウンドのスレッドIDと一致しなければ結果を採用せず、 失敗ラウンドとして取り直す。照合の基準にするため、ラウンド1から JSON 形式で起動させ、各ラウンドで 返ったスレッドIDを採否を問わず控えておく。
• スレッドを継がせない回は、継がないことを明示する: ループ最初のラウンド・失敗ラウンドの 取り直し・照合不一致の取り直しは新しいスレッドで実行させたいので、タスク指示文に新規スレッドで 起動せよと明記する(明示しないと自分の判断で継続される)。これらの回は照合も逆向きになる: 返ったスレッドIDがこのループでこれまでに返ったスレッドIDのいずれかと一致したら、継がせない指示に 反して継がれた回なので採用せず取り直す(照合の基準を採用ラウンドだけに絞ると、継がれる相手が直前の 失敗ラウンドのスレッドだった場合に素通りする)。ループ最初のラウンドは照合の基準がまだ無く、指示の 明示だけが防御になる(ここで得たスレッドIDが以後の照合の基準になるため、汚染されると照合機構全体が 働かなくなる)。
• スレッドIDが応答に無く照合できない回は、継ぐ回も継がない回も採用しない(照合が唯一の検出手段なので、 照合を飛ばした回を通すと検出機構が黙って無効になる)。
• スレッドを解決できずに起動が失敗した回は、失敗ラウンドに算入せず、新規スレッドで起動し直して続行する (スレッド継続のとおり、このエラーは継げないことだけを意味する)。このエラーを一度観測したら、 そのセッションの残りは継がない回として進める(実行中のまま残ったジョブ記録は回収されないので同じ エラーが繰り返される)。継げないことを理由にレビューを止めない——文脈を指示文へ要約して渡す従来の形に 落ちるだけである。
• スレッドを継がない回は、レビュー指示文一式(目的・品質基準・常設観点・出力契約)と前ラウンドまでの 文脈を改めて渡す(新しいスレッドは何も覚えていない)。
• 継いだ回は指摘そのものの再掲が要らない。前ラウンドの文脈として渡すのは各指摘への対応結果 (修正した内容・反証の理由・受容の認否要求・スコープ外却下の理由)と今回問うことで足りる。 常設観点は毎ラウンドすべて適用させるので、前ラウンドで渡した観点をすべて適用して再レビューせよと 明記する(観点を減らさない)。
• RUNID の発行と watchdog の起動は従来どおり。スレッド継続で起動しても、ジョブの summary は タスク指示文の冒頭から作られるので RUNID による相関はそのまま成立する。

完了の判定(codex-watchdog の機械的な判定に、レビュー固有の合否解釈を重ねる)

• codex-watchdog の完了の判定のとおりエージェント応答/watchdog 通知の先着で分岐した上で、 レビュー固有の合否解釈を適用する:
  • エージェントの応答に、codex/companion/app-server が起動失敗・完走不能だったことを示す記述 (EPERM・初期化失敗・アクセス拒否等)と、タスク内容への回答(指摘列挙・確認結果・分析等)が 同時に含まれる場合(自己代行) → 契約違反として無条件で失敗ラウンド扱いにする。応答内の タスク内容は指摘列挙としても無指摘の結論としても一切採用せず(参考にもしない)、新規 RUNID で 取り直す。「念のため自分で確認した」等の注記が付いていても、codex 自身が完走していない以上 採用しない(Codex 未完走時の自己代行禁止参照)。この判定は、失敗の症状が EPERM かつ呼び出し側 原因の既知パターンに一致する場合であっても変わらない(自己代行は codex 未完走時にエージェント 自身がタスク回答を代行した独立の契約違反であり、EPERM の原因分類とは別軸のため)。
  • エージェントが指摘列挙を返す(上記の自己代行に該当しない) → 採用(手順2: 照合・仕分けへ)。
  • エージェントが観点ごとの確認結果を伴った無指摘の結論を返す → 無指摘ラウンドとして採用し、 手順3へ回す。確認結果の実体を伴わない無指摘の結論(観点ごとに何をどの実装/仕様と 照合したかが無い、または結論の一言だけ)は契約違反として失敗ラウンド扱いにし、新規起動でやり直す (実体の有無で採否を決め、特定語の有無では決めない)。
  • watchdog 正常終了なのにエージェント応答が来ない場合(ログ走査で 代替する経路) → 【安全規則】このフォールバックでは無指摘(収束)を確定しない: 抽出が 指摘列挙なら参考にしつつ対処してよいが、無指摘に見えても採用せず失敗ラウンド扱いで新規 エージェントで取り直す。無指摘の確定はエージェントの直接応答(観点ごとの確認結果を伴った 無指摘の結論)でのみ行う(ログ走査由来の無指摘で誤コミットに至らせない)。
  • エージェントが companion を起動せず差し戻す応答を返す(codex-watchdog・ review-loop-judgement など起動契約が定める差し戻し全般。禁止記号違反・目的記載不備等、 理由は問わない)→ 失敗ラウンドとしてカウントしない(下記再試行と継続参照)。呼び出し側 (このループを実行している Claude 自身)がレビュー指示文の組み立てを誤ったことが原因で、 companion・codex 側の障害ではないため。差し戻し応答が明示する不備を修正した上で、新しい RUNID で同じラウンドを即座に取り直す。
  • codex-watchdog が stall・no-start・wall-cap・失敗・エージェントの失敗報告・早期復帰等を 検出した場合 → codex-watchdog の失敗は症状のラベルでなく原因で仕分けるのとおり、 症状のラベル(stall/no-start/wall-cap 等)だけで機構障害と決めつけず原因を確認する:
    • 原因が呼び出し側の起動コマンド組み立てミス(相対パス・誤ったパス推測・-- 省略・RUNID 不一致等)だと判明した場合 → 失敗ラウンドとしてカウントせず、原因を取り除いた上で上限を 設けずに新規エージェントで再試行する(下記再試行と継続参照)。
    • Codex/companion 側が実際に応答不能・処理停止していると判断できる場合、または原因が 判明しない場合 → 失敗ラウンド扱いで新規エージェントによる取り直しへ。
    • stall・wall-cap での取り直しでは、review-loop-judgement の1ラウンドが時間内に終わらないときに 従う。
• 補足: 「短時間で完了した無指摘」や、確認結果の実体を伴わない無指摘の結論(結論の一言だけ)は、 契約違反(失敗を無指摘と詐称)の疑い。失敗ラウンドとして新規起動でやり直す。再試行で正規結果と 認めるのは、各観点の確認結果を伴った上で指摘が無い旨を結論してきた場合に限る(再び実体の無い 結論だけならまた失敗ラウンド)。

再試行と継続(このループの再試行上限)

• 失敗ラウンドの取り直しでは codex のスレッドも継がせず、新規スレッドで取り直す(新しい RUNID を 発行し、継続レビューのとおり新規スレッドで起動せよと明記した上で、前ラウンドまでの文脈——修正済みの 要約・却下理由・受容理由・今回問うこと——とレビュー指示文一式を渡す)。契約違反・起動失敗を起こした 文脈を引き継がせないため。取り直したラウンドを採用できたら、そのラウンドのスレッドIDが以後の照合の 基準になる。
• 2回連続で失敗ラウンド扱いになったら「問題発生」として停止し、状況をユーザーに報告する (自律進行を止める)。ここでの「失敗ラウンド扱い」は、新規起動でやり直しに回る全ての失敗を指す (codex-watchdog が判定する失敗に加え、自己代行の検出・確認結果を伴わない無指摘の結論・ フォールバックでログ走査が無指摘に見えた場合の不採用 など)。呼び出し側のレビュー指示文の組み立てミスによる 差し戻し(上記完了の判定参照)は、この失敗ラウンド扱いに含めない(機構(codex・watchdog)の 障害ではなく呼び出し側の指示文生成ミスに由来するため)。不備を修正した指示文で新しい RUNID を 発行し即座に取り直す。これが実行失敗の有限停止を担う(ラウンド数に上限は 設けず、暴走は「数ラウンド連続で新規解消なし」の千日手と、この連続失敗停止の二つで止める)。 差し戻しには別立ての連続回数上限を設けない(差し戻しは呼び出し側が指示文を直せば解消するもので、 そのたびに自走を止めてユーザーへ諮る理由がない)。スレッドを解決できずに起動が失敗した回も この失敗ラウンド扱いに含めない。
• 原因が呼び出し側の起動コマンド組み立てミスだと判明した失敗(stall/no-start/wall-cap 等の症状 ラベルであっても)も、この失敗ラウンド扱い・2回連続停止のカウントに含めない。EPERM は 起動コマンドの既知の不備パターンに起動コマンドが一致すれば同様に除外 するが、この一致は不備の存在を確定するのみで、それがEPERMの直接原因であることまでは要求 しない(下記参照)。この種の失敗にも連続回数上限を設けない(companion/node プロセスが コマンド組み立てミスで一過性に失敗しているだけで、呼び出し側が原因を取り除けば解消するため)。EPERM もこれと同じく回数上限を設けない(codex-watchdog 参照。対策を講じたうえでの再試行を、再発を理由に通常の失敗 ラウンド扱いへ倒すことは、この規律の目的に反する)。呼び出し側は直前の失敗原因(相対パス・ 誤ったパス推測・-- 省略・RUNID 不一致・ --cwd 省略やスペース区切り2トークン形・中間変数経由での起動コマンド組み立て等)を取り除いた 上で、上限なく新規エージェントで再試行する。再試行時のタスク指示文には、今回特定した具体的な 不備そのものを名指しした禁止文を必ず追加する。一般論の「標準形で起動せよ」のみを付けて無対策の まま再試行することを禁止する。この判定(呼び出し側原因か機構障害か)を裏付けなく毎回 「呼び出し側原因」に倒さない: エージェントの報告・ジョブログから原因を確認できない場合は 通常の失敗ラウンドとして扱う(原因不明を無条件リトライの免罪符にしない)。ただし EPERM に ついては、codex-watchdog のEPERM は呼び出し側の失敗と推定するの手順(ジョブログ本文 ——ジョブ状態ログの書き込み自体がサンドボックス制限で拒否され参照できない場合はエージェント 報告の起動コマンドと生のエラー出力——と起動コマンドを起動コマンドの既知の不備パターンと照合する)を実際に 実施してから結論する。この照合を省略して いきなり「原因不明」に倒すことを禁止する(照合の結果起動コマンドの既知の不備パターンのいずれにも一致しない 場合に限り、通常の失敗ラウンドとして扱ってよい)。

手順2: 照合・仕分け

review-loop-judgement スキルの手順2のとおり判定する。

手順3: 終了判定

review-loop-judgement スキルの手順3のとおり。

手順4: 報告(日本語)

review-loop-judgement スキルの手順4のとおり。コミットはしない (コミットは別途ユーザーの指示で commit スキルに委譲)

注意

• 設計・方針への異議出しが主目的なら、前段プロンプトを挑戦的(アプローチ・設計を問う) に寄せてよい(/codex:adversarial-review 相当の枠組み)