Claude CodeとCodexで止まらない開発フローを作った話
ここ数か月、Claude CodeとCodex CLIを併用するようになって、開発のスピードがはっきり変わった。1日の作業量が体感で1.5〜2倍になっている。
ポイントは「両方に同じことをさせない」こと。役割をきっぱり分けて使うと、トークンも節約できるし、ミスも減る。
今日はこの分業フローを、実例つきで解説する。
Claude Code＝設計とレビュー、Codex＝実装と修正
役割は次のように切り分けている。
Claude Code：考える / 設計する / レビューする
要件整理、アーキテクチャ判断、Codex成果物のレビュー
Codex CLI：作る / 直す / つなげる
実装、バグ修正、コード統合、テスト追加
「実装が必要だな」と思った瞬間、Claudeから手を離してCodexに渡す。Codexが書き終わったらClaudeで確認する。これだけ。
理由は3つある。
なぜ役割を分けるのか
1. コンテキスト長の壁を回避できる
Claude Codeは1Mトークンの長尺コンテキストが強み。だから設計フェーズでは多くのファイルを読み込んで、全体像を把握しながら判断するのに向く。
一方で、実装フェーズに入ると差分の多いファイル編集を繰り返す。これをすべてClaudeでやると、コンテキストがすぐパンクする。
そこで実装はCodexに切り出す。Codexは1タスク完結型で動かせるので、メインのClaudeセッションのコンテキストを汚染しない。
2. レビューが効きやすい
実装したエージェント自身がレビューしても「自分の書いたコードを自分で評価する」状態になりがち。
Claudeで設計→Codexで実装→Claudeでレビュー、と分けると、レビュー時に第三者視点が入る。Codex成果物の妥当性チェックがClaudeでできる。
3. 得意分野を活かせる
Codex CLIはコード生成タスクに特化している。長文の意思決定や設計判断はClaude Codeのほうが上手い。
両方を「ジェネラリスト」として使うより、専門家ペアとして役割分担したほうが、結果として品質が上がる。
実際のフロー：4ステップで回す
実装が必要なタスクが出てきたら、こんな流れで動かす。
STEP 1 Claude Codeで要件を整理する
ユーザーの要望を読み解いて、何を作るか・どこを直すか言語化する
STEP 2 Claude Codeで設計判断をする
影響範囲、依存関係、アーキテクチャ上の選択肢を確認する
STEP 3 Codex CLIに実装を委譲する
明確な指示をプロンプトに落とし、codex exec --full-autoで動かす
STEP 4 Claude Codeで成果物をレビューする
変更ファイルを読み、テスト追加、デプロイ判断をする
ここで雑な指示を出すと、Codexは雑な実装で返してくる。設計フェーズでしっかり言語化しておくのが、結果的に手戻りを減らす。
実例：LINE Harnessのチャット機能を強化したとき
実際に最近この分業で進めた案件を一例として紹介する。
LINE運用ツール「LINE Harness」のオペレーターチャットに、タグ表示・複数タグ絞り込み・顧客情報ページを追加するタスク。これはコード変更が10ファイル以上にまたがる中規模の改修だった。
進め方はこんな感じ。
Claude Codeでやったこと
・既存のテーブルとAPIエンドポイントの調査
・タグ編集ロジックの分離方針を決定
・マルチアカウント境界の権限チェック設計
・実装後の動作確認と修正パッチの設計
Codex CLIに任せたこと
・tag-editor.tsxの新規実装
・/friends/[id]ページの追加
・APIにassertFriendBelongsToAccountヘルパー追加
・migration SQLとフロントエンドの統合
このとき、Codexが置いた__dynamic__プレースホルダがフロントエンドのバグになった。これをClaude Codeで実機確認したときに発見し、usePathname()を使う形に修正した。
実装はCodexに任せても、最後の動作確認とレビューはClaudeで自分が見る。そうしないと、コードは動くけれど挙動がおかしい状態を見逃す。
Codexの起動方法とレビューゲート
/codexスラッシュコマンドから呼び出すのが楽。 Codex CLIは公式サイトからインストールでき、Claude Codeから呼ぶときは/codexスラッシュコマンドを使うパターンが多い。
設定で--enable-review-gateをオンにしておくと、Codexの作業終了時にレビューゲートが立ち上がる。Claudeに戻る前のチェックポイントになるので、品質保証で有効。
ただしレビューゲートは、毎回必須にすると逆にテンポが落ちる。複雑な案件だけONにするのが現実的。
軽い修正はClaude単体でOK
すべての作業をCodexに渡すと、逆にオーバーヘッドが大きくなる。判断基準はざっくりこうしている。
Claude単体でOK：1〜2ファイルの修正、文言変更、調査タスク、ドキュメント生成
Codex委譲推奨：3ファイル以上にまたがる実装、新機能追加、リファクタリング、テスト追加
非自明な実装が発生した時点でCodexに渡す。それまでは無理に分業する必要はない。
まとめ
Claude CodeとCodex CLIの分業は、トークン節約と品質向上を同時に実現できる運用パターン。
ポイントは「実装はCodex、設計とレビューはClaude」という線引きを徹底すること。両方を兼業させると、長所が削られる。
このフローに切り替えてから、毎日2〜3個の中規模タスクが安定して回るようになった。1人開発でも、ここまでスピードが出せるとは思っていなかった。
最近Codex CLIを触り始めた人は、まずは1案件だけこのフローで回してみてほしい。半日もすれば違いがわかるはず。
