コピペリレーを消す — Claude Code × Codex レビューループの自動化

実装ガイド · Multi-Agent Review Loop · 2026-08-06

この記事が想定する状況：Claude Code に計画や実装を書かせ、その出力を手でコピーして Codex（あるいは別のCLIエージェント）に貼り、返ってきたレビューをまた手でコピーして Claude に戻す——という往復を人間がやっている。生産性の律速がモデルではなく自分の手のコピペになっている状態。

結論：この往復は 2026年に入って複数の開発者が独立に自動化に取り組んだテーマで、すでに実用段階のパターンが揃っている。最短ルートは公式プラグインで5分。本格運用は SKILL.md 1ファイルで済む。

1. なぜ Git の push / pull ではないのか

最初に潰しておくべき誤解がこれ。「2つのエージェントを繋ぐなら Git で同期すればいいのでは」と考えがちだが、粒度が合わない。

Git の同期粒度はコミット。一方、レビューループの同期粒度はターン（1回のレビュー往復）。ここで必要なのはバージョン管理ではなく、エージェント間のメッセージパッシングと停止条件の定義である。

そもそも両者が同じ作業フォルダを見ているなら、成果物（コード・設計ドキュメント）はすでに共有されている。自動化すべきなのは成果物の輸送ではなく、「レビュー依頼 → レビュー結果 → 修正 → 再レビュー」という制御フローだけ。ここが本質。

Claude: 計画を書く→ 一時ファイルに書き出し→ Codex: read-only レビュー→ VERDICT 判定→ Claude: 自分で書き直す↻

2. 技術的な鍵：`codex exec`（非対話モード）

すべての自動化パターンの土台がここにある。Claude Code の bash 環境は非対話型なので、Codex CLI を呼ぶときは codex exec サブコマンド（非対話モード）を使うのが定石。つまり Claude Code が Codex を「ツールとして」bash 経由で呼ぶ構図にすれば、コピペは消える。

流用できるフラグ群

# レビュー用（read-only サンドボックス：レビュアーがコードを触れないことを技術的に担保）
codex exec -m gpt-5.3-codex -s read-only \
  "Review the plan in /tmp/plan.md. End with VERDICT: APPROVED or VERDICT: REVISE"

# 前回の指摘を覚えたまま再レビュー
codex exec resume <session-id> "Re-review the updated plan"

-s read-only — 権限分離。レビュアーがコードを書き換えられないことを、お願いではなく技術で担保する。
codex exec resume — 前回のセッションを再開できる。Codex は前回の指摘を覚えたまま再レビューし、修正が実際に反映されたかを検証できる。
--output-schema — 最終出力の JSON 構造をスキーマで制約できる。「判定＋指摘リスト＋重大度」のような構造化出力が可能。レビュアー出力を後段のツールで機械処理したいなら、最初からここに寄せておくとよい。

3. 実装パターン4段階

下のタブで4つのパターンを切り替えて比較できる。上から順に導入コストが低い。

OpenAI 公式プラグイン `codex-plugin-cc`所要5分

2026年3月30日に OpenAI が公式プラグイン codex-plugin-cc をリリースし、スラッシュコマンド1つで Codex レビューを実行できるようになった。導入は3行。

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/codex:setup

/codex:review — 通常レビュー
/codex:adversarial-review — 設計判断やリスクを強めに疑うレビュー
/codex:rescue — タスクそのものを Codex に委任

まずこれで疎通確認するのが最短。ここでコピペが消える体験をしてから、次のパターンに進むかを決めればいい。

SKILL.md 1ファイルで VERDICT ループ推奨

.claude/skills/codex-review/SKILL.md を置くだけで、以下が自動実行される。

Claude が計画を一時ファイルに書き出す
codex exec で read-only レビュー
VERDICT: REVISE なら修正して resume で再提出
VERDICT: APPROVED か最大5ラウンドで収束

SKILL.md は Gist で公開されている（Aseem Shrey 氏）。

設計上いちばん重要な一文：「Claude should make real improvements」——Codex のフィードバックを単にパススルーするのではなく、Claude 自身が計画を書き換えてから再提出する。これが「単なるメッセージリレー」と「レビューループ」の本質的な違い。

手作業のコピペ律速を置き換える対象は、正確にここ。人間がやっていたのは輸送業務に見えて、実は「指摘を読んで書き直す」という判断作業が混ざっている。そこを Claude 側に寄せないと、自動化しても品質が落ちる。

Stop Hook で自動発火（claude-review-loop）要注意設定あり

パターン1の弱点は起動を忘れるとスキップされること。Hamel Husain 氏の claude-review-loop プラグインは、Claude Code がタスクを完了して終了しようとするタイミングに割り込む Stop Hook を使い、これを構造的に潰す。

タスク完了→ Stop Hook が横取り→ Codex 自動起動（最大4並列）→ reviews/review-<id>.md→ Claude に戻して修正

重大な注意点①：サンドボックスフラグ
デフォルト設定では Codex の実行フラグに --dangerously-bypass-approvals-and-sandbox が使われている。環境変数 REVIEW_LOOP_CODEX_FLAGS を --sandbox read-only 等に上書きすることが推奨されている。ローカルサービスを 127.0.0.1 バインドに限定するような環境ポリシーを持っているなら、ここは必ず上書きすべき箇所。

重大な注意点②：再帰ガード
Stop hook の入力には stop_hook_active フラグが含まれる。hook スクリプト内でこれを確認して再帰をブロックするガードを入れないと、レビュー → ブロック → レビューの無限ループに陥る可能性がある。

パイプライン化・マルチCLIオーケストレーション大掛かり

claude-codex（Z-M-Huang 氏）— requirements-gatherer → planner → plan-reviewer → implementer → code-reviewer という工程をスクリプトで管理し、全レビュアーが承認するまでループする。
Claude-Code-Workflow（catlog22 氏）— JSON 駆動のマルチエージェントフレームワーク。Codex・Gemini・Qwen など複数CLIを統合オーケストレーションできる。
Agent HQ（GitHub）— リポジトリ内で Copilot・Claude・Codex の3エージェントを直接起動。同一 issue に複数エージェントを割り当てて結果比較し、PR コメントで @Claude や @Codex をメンションしてフォローアップ指示を出せる。

個人の作業ループを消すのが目的なら、ここまでは要らない。チーム/CIに組み込む段になってから検討すればよい層。

4. 「全体が分からなくなったら構造化解説」の自動化 — 2流派のハイブリッド

手動でやっている「いったん全体を俯瞰させて、気になる点を挙げさせる」というステップ。これは設計論としてすでに名前がついている。

resume 流派

◯ セッション継続で修正の追跡性を確保
◯ 「前回の指摘が直ったか」を検証できる
△ 一度「些細」と判断した問題を再度取り上げにくいバイアスが生じる

fresh session 流派

◯ 毎回新規セッションで独立性を担保
◯ 前回の判断に引きずられない
△ 修正追跡は人間側の責任になる

推奨はハイブリッド——修正ループ中は resume で追跡性を確保し、ループ収束後に fresh session で最終監査を1回だけ走らせる。

このとき最終監査の Codex は「計画全体の一貫性を確認する監査役」としてプロンプトの役割を変え、判定も意図的に分ける：

フェーズ	判定トークン	役割	回数
修正ループ	`VERDICT: APPROVED / REVISE`	個別指摘のレビュアー	最大N回（例：5）
最終監査	`AUDIT: PASS / CONCERNS`	全体一貫性の監査役	1回限り

exit condition を曖昧にするとループが終わらない。最終監査は1回限りとし、CONCERNS が出たら人間に判断を委ねる設計が安定する。つまり自分の役割を「リレー係」から「CONCERNS 発生時の裁定者」に昇格させるのが、正しい自動化のかたち。

5. 流用できるパーツまとめ

特定のプラグインを採るかどうかとは別に、設計要素として抜き出せるのは次の6つ。自作する場合もこの対応表がそのまま設計図になる。

役割	実装	補足
メッセージバス	共有作業フォルダ＋一時ファイル `/tmp/claude-plan-<uuid>.md`	Git ではなくファイル1枚で足りる
プロトコル	`VERDICT:` 文字列（将来的には `--output-schema` の JSON）	まず文字列で始めて、機械処理が要るならスキーマへ
権限分離	`-s read-only`	レビュアーがコードを触れないことの技術的担保
セッション継続	`codex exec resume`	指摘の反映を検証させるために必要
トリガー	Stop Hook	起動忘れを構造的に潰す。再帰ガード必須
停止条件	最大ラウンド数＋ fresh session 監査	これが無いと止まらない

セッションIDは UUID で明示管理する。--last フラグは複数インスタンスを並行させたときに誤ったセッションを掴む。複数マシンや複数ターミナルで並行セッションを回す構成なら、ここは早めに潰しておくべき地雷。

6. 推奨導入順

公式プラグインで /codex:review を試す（5分、コピペ即消滅）。まず「往復が消える」感覚を掴む。
SKILL.md 方式に移行し、VERDICT ループの停止条件とプロンプトを自分のドメインにカスタマイズする。知財なら FTO 検討や特許ドラフトのレビュー観点を /codex:adversarial-review 相当のプロンプトに移植できる。
Stop Hook でレビュー漏れを排除。ただしサンドボックスフラグの上書きは必須。またレビューゲートは長いループになり利用上限を消費しやすいので、監視できるセッションでだけ使う。
fresh session 監査を「構造化解説」ステップの代替として組み込む。ここが最後のピース。

実運用者の共通見解：Codex の指摘で自動的に停止や merge をブロックする仕組みは便利だが、ループや誤検知も起こる。実装 → 独立レビュー → 確認済み修正 → 再チェック → 人間の最終判断という流れにすると、制御を失わずにレビュー品質を上げられる。「自動でマージまで」を狙わないのがコツ。

7. 応用：攻め／守りの対戦型エージェントへの転用

ここで定めた判定規約——read-only な独立レビュアー、VERDICT: というプロトコル、最大ラウンド数と最終監査による停止条件——は、レビューループに限らず攻撃役／防御役の2体を対戦させる構成とそのまま同型になる。請求項ドラフトを「広げる側」と「無効化を試みる側」で回すような構成を作っているなら、SKILL.md の判定規約はそちら側へ逆輸入できる。

逆に言えば、この記事で扱っているのは Codex 固有の話ではなく、「2体の非対称なエージェントを、人間の手を介さずに収束させるプロトコル設計」の一般解である。相手が Codex でも Gemini でもローカルLLMでも、必要な部品は同じ6つ。

出典・一次情報

SmartScope 実装ガイド — claude-code-codex-review-loop-automation-2026（各パターンの具体的な設定手順）
Aseem Shrey 氏の SKILL.md — GitHub Gist
OpenAI 公式プラグイン codex-plugin-cc（2026年3月30日リリース）

※ 本稿の各プラグイン・フラグの仕様は上記出典時点のもの。CLI のフラグ名やプラグイン構成は更新が早いので、導入時に codex exec --help と各リポジトリの README で現行仕様を確認すること。

← 参照コンテンツ一覧に戻る