Claude Code × Codex の二刀流 AI コードレビュー実践 – Opus 4.7 の 1M context で実現する長期タスク

2026 年 4 月、Anthropic が Claude Opus 4.7 をリリースし、1M context window が一般提供されました。

これまで「context が足りずに途中でスコープを分割する」という制約があったタスクが、そのまま通しで扱えるようになります。

一方で「書いたコードのレビュー」には別の課題があります。自分で書いたコードを自分でレビューすると、どうしても書いた時点の思考のフレームに縛られてしまう。

特に「そもそもこの前提が間違っている」系の指摘は、セルフレビューでは出てきにくい種類の指摘です。

本記事では、Opus 4.7 の 1M context で複数リポジトリに跨る長期タスクを進めつつ、節目ごとに OpenAI の Codex CLI に第三者レビューを依頼する「二刀流」のワークフローを、実例を交えて紹介します。

題材：GitHub Actions の大規模マイグレーション

今回の題材は、以下のような「広く・深い」作業です。

• 広さ: 20+ リポジトリを横断して GitHub Actions を SHA ピン止め + Node.js 24 対応版に更新
• 深さ: gr2m/create-or-update-pull-request-action から gh pr create/edit への移行（単純な置換ではなく、積み上げロジック・並行実行制御・エラー処理まで設計し直し）

従来の 200K context だと、「今どのリポジトリの話か」「前に何をどう直したか」がセッション中盤で流れ落ち、人間が都度サマリを作り直す必要がありました。

1M context ではこの苦労がほぼ消えます。

1M context が効いた具体シーン

1. 20 リポジトリ同時並列の状態保持

各リポジトリで feature ブランチを切って、一括 sed で actions のバージョンを SHA ピン止めに置き換えて、コミット・プッシュ・PR 作成まで 1 セッションで完遂できました。

途中で actions/cache の SHA 誤りの指摘が入った時も、「どのリポジトリに何を入れたか」の記憶を失わずに追加コミットで修正を当てられました。

2. 複数回の設計変更を一貫させる

gh CLI 移行では、Codex レビューを受けて数回の大きな設計変更を挟みました。

1. 最初は git fetch origin $BRANCH || git checkout -b の素朴な実装
2. セルフホストランナーの stale state 対策で -B に変更
3. 削除済みリモートブランチ対策で git fetch --prune の書き方を見直し
4. リトライ冪等性のために has-changes ゲートを撤廃
5. 判定ロジックを HEAD 基準に統一
6. 並行実行制御のための concurrency 追加

これらの変更は互いに影響し合います。

例えば 5 の判定ロジック変更は 4 のリトライ冪等性の前提になっていて、前の設計を忘れると後の変更で矛盾が生まれやすい。

1M context では「なぜこの形になっているか」の経緯が全て保持されているので、矛盾なく積み上げられます。

3. 関連リポジトリの横展開

「あるワークフローで設計した積み上げロジックを別のワークフローにも適用したい」「同じ構成の複数リポジトリに同じ修正を横展開したい」のように、過去に作った設計・コード片を別の場所に応用する作業が、コピペや再説明なしで進みます。

なぜ別モデルのレビューが刺さるのか

1M context で長期タスクを通せるようになったことで、逆に 「書き手の視野が固まる」リスクが増えます。同じフレームの中でずっと考えていると、そのフレーム自体に疑問を持てなくなるからです。

ここに別モデルのレビューを挟むと、「その前提が実は正しくない」系の指摘が出てきます。具体的には以下のような指摘が Codex から飛んできました。

これらは 書いている最中には疑問の対象にならない種類の知識です。

別モデルに「何も前提を共有せず」レビューさせると、こういう前提層の誤りが炙り出されます。

実践ワークフロー

実際に採用しているワークフローは以下の通りです。

1. Claude Code（Opus 4.7）で実装 – 要件と設計意図を共有して、実装・テスト・コミットまで任せる
2. PR 作成 – この時点で 1 次レビューは終わっている
3. Codex CLI でレビュー – 「前提を疑う」系の指摘を期待して別モデルに見せる
4. Claude Code に指摘を転送 – Codex の指摘が妥当か検証コードで確認させ、必要な修正だけを反映
5. 修正後、再度 Codex レビュー – 前回指摘への対応と、新しい観点での追加指摘を期待

ステップ 4 の 「指摘の妥当性を検証させる」が重要です。

Codex の指摘がすべて正しいわけではなく、実装の文脈を完全には理解していないので、時には的外れな指摘も混じります。

そこで Claude Code には「指摘を盲目的に受け入れず、小さな再現実験で検証してから判断する」ことを明示的に指示します。

例えば「gh pr list --head は前方一致」という指摘を受けた時、Claude Code は実際に既存の PR に対してコマンドを叩いて、指摘通りの挙動を確認した上で修正に入りました。

Codex を呼び出す具体的な方法

Claude Code から Codex を呼ぶには、codex スキルを定義しておくと便利です。

codex exec --full-auto --sandbox read-only --cd <project_directory> "<request>"

重要な指定は以下の 2 点です。

• --sandbox read-only – レビュー用途なのでファイル変更は禁止
• プロンプト末尾に「確認や質問は不要、具体的な修正案まで出力」 – これを入れないと、Codex は曖昧さを感じた時に質問で返してしまう

レビュー依頼のプロンプトには、実装の文脈と特に気になる観点を具体的に列挙するのがコツです。

汎用的な「レビューしてください」だと指摘が浅くなります。例えば：

• どのファイルが対象か
• セルフホストランナーなど環境固有の前提
• 特に確認したい観点（race condition、heredoc の安全性、など具体的に）
• 既知のトレードオフ（あえて見送った選択と理由）

このプロンプト設計を怠ると、Codex は「typo 直した方がいい」のような浅い指摘を出してきます。

効果の実感

今回の gr2m → gh CLI 移行 PR では、Codex から合計 10 件以上の指摘を受けました。そのうち：

• 採用: 7 件 – High/Medium レベルの設計上の問題
• 見送り: 3 件 – 複雑化のコストに見合わない or 影響範囲が限定的と判断

採用した 7 件のうち、人間レビューでは気付いていなかった類の指摘が 5 件以上ありました。

特に「git push と remote-tracking ref の関係」「ls-remote の exit code 区別」のような、git の深い挙動に関する指摘は、Codex を使わなければそのまま本番にマージされていた可能性が高いです。

いま試すならどこから始めるか

いきなり全部のワークフローに Codex レビューを組み込もうとすると、プロンプト設計の手間で挫折します。

まずは以下のような 「失敗したら影響が大きい PR」から始めるのがおすすめです。

• CI/CD パイプラインの変更
• デプロイスクリプトの変更
• 認証・権限周りの変更
• DB マイグレーションや破壊的変更を含む PR

これらは本番で失敗するとリカバリが難しい類の変更なので、別モデルからの視点で前提が正しいか確認する価値が特に大きいです。

まとめ

• Opus 4.7 の 1M context で、複数リポジトリに跨る長期タスクが途切れず通せる
• 長期タスクほど「書き手の視野が固まる」リスクが増える
• 別モデル（Codex）レビューを節目で挟むと、前提層の誤りが炙り出される
• Codex の指摘を Claude Code に検証させてから反映する二段構えが効果的
• まずは「失敗したら影響が大きい PR」から導入するのがおすすめ

「1 つの AI にすべて任せる」ではなく、「AI 同士を協調させて人間が意思決定する」という役割分担が、これからの実装作業のスタンダードになっていくと感じています。

saratoga

フリーランスエンジニア

XYouTube

仕事にも趣味にも IT を駆使するフリーランスエンジニア。技術的な TIPS や日々の生活の中で深堀りしてみたくなったことを備忘録として残していきます。