株式会社Good Labでエンジニアをしている コータロー です。
日々、Java・SQL・Gitなどの技術情報や、新人エンジニア向けの学習ノウハウ、
AI活用についての情報を発信しています。
Good Labについて気になった方は、コーポレートサイトもぜひご覧ください。
▶コーポレートサイト
はじめに
AIコーディングツールを1つだけ使っていた頃は「どのツールが最強か」しか考えていませんでした。ですが実際に Claude Code をメイン、Codex CLI をサブ として並行運用してみると、問われるのは「どっちが強いか」ではなく 「どの作業をどっちに振るか」 だと分かってきました。
私は受託開発・SES を本業にしつつ、副業で iOS アプリを複数リリースしていて、日常の開発は Claude Code をメインに回しています。そこに Codex CLI を併用する中で、自分の中では次のような一見矛盾したルールに落ち着きました。
- コードレビューには Codex を使わない（自前チェックで十分だった）
- 実装作業の移譲には Codex を使ってよい（トークン節約になる）
「レビューは頼まないのに、実装は頼む」。字面だけ見ると変ですが、この2つは 評価している軸がまったく違う ので矛盾していません。この記事ではその判断基準を言語化し、実務でそのまま真似できる運用ルールと引き継ぎ資料のテンプレートまで落とし込みます。
対象読者：
- Claude Code や Codex CLI など、AIコーディングツールを複数併用している（したい）人
- 「AIにレビューさせる意味あるの？」とモヤモヤしている人
- チーム開発・受託開発でAIツールの役割分担を決めたい人
本記事のツール名・コマンドは執筆時点（2026年7月）のものです。CLI のサブコマンドやフラグは更新が速いため、実際の仕様は各公式ドキュメント（記事末尾の「参考」）で確認してください。
結論：2つの軸で判断している
先に結論です。私は次の2軸でツールを振り分けています。
| 判断軸 | 問い | 私の答え |
|---|---|---|
| レビュー軸 | 「AIに"最終チェック"を任せるか？」 | 任せない。自前（grep + ビルド）で足りる |
| 実装移譲軸 | 「作業そのものをAIに肩代わりさせるか？」 | 場合による。移譲するが最終判断は自分 |
ポイントは、レビューと実装移譲は別のレイヤーの話 だということです。
- レビュー軸で「Codexにレビューさせない」と決めても、
- 実装移譲軸で「Codexに実装させる」ことは何ら矛盾しない。
なぜなら 実装をCodexに移譲した場合でも、"レビューという最終工程" は必ず自分（Claude Code＋人間）に戻す からです。作業は分担しても、品質保証の責任は分担しない。これが軸を分けて考える意味です。
軸1：なぜコードレビューをCodexに任せないのか
最初、私も「セカンドオピニオンとしてAIにレビューさせれば品質が上がるのでは」と期待していました。実際 Codex にレビューをさせる運用を試したのですが、自分のワークフローでは 費用対効果が合いませんでした。
理由は主に3つです。
1. 指摘の多くは自前チェックで先に潰せる
私が日常で潰したい問題は、だいたい機械的なチェックで検出できるものでした。iOSアプリ開発なら例えばこうです。
# force unwrap（!）の混入チェック
grep -rn '!' Sources/ --include='*.swift' | grep -v '!=' | grep -v '//'
# print デバッグの消し忘れチェック
grep -rn 'print(' Sources/ --include='*.swift'
# try! / as! の混入チェック
grep -rn 'try!\|as!' Sources/ --include='*.swift'
そして最後に ビルドを通す。これがいちばん強いレビューです。
xcodebuild -project MyApp.xcodeproj -scheme MyApp \
-destination 'platform=iOS Simulator,name=iPhone 16' build 2>&1 | tail -5
「規約違反 grep」＋「ビルド（＋テスト）が緑」で、レビューで拾いたかった指摘の大半はカバーできてしまいました。ここに追加でAIレビューを重ねても、新規に拾える指摘は多くありませんでした。
2. レビューは時間がかかる割にノイズが多かった
外部ツールにレビューを依頼すると、コンテキストを読み込ませて、指摘が返ってくるまで待ち時間が発生します。返ってくる指摘も「一般論としては正しいが、この文脈では不要」というノイズが混じり、取捨選択のコスト が乗ります。自前 grep が数秒で終わるのに対し、割に合いませんでした。
3. レビューの最終責任は分担できない
受託でもアプリでも、「AIがOKと言ったから」は理由になりません。最終的に人間（＋メインのClaude Code）がdiffを読んで納得する工程は、どのみち省けない。だったら、その工程に外部レビューを足しても二度手間になりやすい というのが実感でした。
補足：これは「AIレビューが無意味」という主張ではありません。CIに組み込んだ自動レビューや、規約が緩い大規模OSSなどでは有効な場面もあります。あくまで 私の（規約が明確で、grep＋ビルドが効く）ワークフローでは費用対効果が合わなかった という話です。
軸2：なぜ実装移譲はCodexに任せてよいのか
一方で、実装作業そのものの移譲 は話が別です。ここでの狙いは品質向上ではなく トークン（コンテキスト）の節約 です。
Claude Code のメインセッションで大きな実装をぶん回すと、コンテキストを消費します。定型的・機械的で、方針が既に固まっている作業なら、それを Codex に肩代わりさせることで、メインセッションのコンテキストを重要な判断のために温存できます。
Codex の非対話実行はこんな形です（stdout に最終メッセージだけを返してくれるのでパイプに乗せやすい）。
# 引き継ぎ資料をそのまま渡して非対話実行
codex exec "$(cat handoff.md)"
ここで重要なのが、冒頭で述べた原則です。
実装は移譲しても、レビュー（最終判断）は移譲しない。
Codex が実装した結果は、必ずメイン側（Claude Code＋人間）が 全コミットを1件ずつ diff レビュー してから本番適用・push の可否を判断します。
# Codexが積んだコミットを1件ずつ精査する
git log --oneline origin/main..HEAD
git show <commit-hash> # diffを1件ずつ確認
特に DBスキーマの制約（NOT NULL、外部キー、UNIQUE、マイグレーションの前方互換） のような「実際に本番で効く制約」との突き合わせは、AIの自己申告を信じず自分で確認します。Codexは会話の文脈も本番環境も知らないので、ここは人間の担当領域です。
つまり分担はこうなります。
| 工程 | 担当 |
|---|---|
| 手を動かす実装 | Codex（移譲可） |
| diffレビュー・制約突き合わせ | Claude Code＋人間（移譲しない） |
| 本番適用・push可否の最終判断 | 人間（移譲しない） |
実践：Codexへの引き継ぎ資料の書き方
ここが本記事のいちばん実用的なところです。
Codex に実装を移譲するときの最大の落とし穴は「会話の文脈を持っていない」こと です。Claude Code のメインセッションでは「さっき話したあの件」で通じますが、Codex にはそれがありません。だから引き継ぎ資料は それ単体で完結 していなければなりません。
私は次の項目を必ず埋めた Markdown を用意し、それを丸ごと Codex に渡します。
引き継ぎ資料テンプレート
# タスク: <一文で目的>
## 背景 / なぜやるか
<この変更が必要な理由を、前提知識ゼロの人に説明するつもりで書く>
## 対象ファイルと箇所
- `Sources/Models/User.swift` の 42〜58行目（`init` 周辺）
- `Sources/Services/UserStore.swift` の `save(_:)` メソッド
## 現状の問題 / 失敗シナリオ
- 空の name で save するとクラッシュする
- 再現手順: 新規ユーザーを name 未入力で保存 → force unwrap で落ちる
## 期待する修正方針
- name は必須。空文字は弾いて `throws` でエラーを返す
- force unwrap は使わず `guard let` で安全にアンラップ
## 受け入れ基準（Doneの定義）
- [ ] 空 name で save したときエラーが返る（クラッシュしない）
- [ ] 既存テストが緑のまま
- [ ] 新規テストを1件追加（空nameケース）
## 制約（厳守）
- スコープ厳守。指定箇所以外は触らない（"ついで修正"禁止）
- 実装 → ビルド → コミット の順を守る
- DBの本番適用（マイグレーション実行）は自動で行わない
- git push はしない（コミットまでで停止）
このテンプレの肝は最後の 「制約（厳守）」 ブロックです。ここに毎回同じ4点を明記しています。
- スコープ厳守（ついで修正禁止） ― AIは親切心で余計な箇所を直しがちで、それがdiffレビューを膨らませ、事故の温床になる
- 実装→ビルド→コミットの順序 ― 動く状態でコミットさせることで、途中で止まっても安全に引き継げる
- DB本番適用は自動実行しない ― 取り返しがつかない操作は人間の承認を通す
- git push しない ― リモートに出す前に必ず自分のdiffレビューを挟む
「途中で止まっても安全」が効いた実例
この運用の価値を実感したエピソードがあります。
あるとき Codex に実装を移譲したところ、作業の途中で トークン切れ／環境制約（その環境では xcodebuild が実行できない） に当たって停止しました。ここで効いたのが、引き継ぎ資料に書いておいた 「実装 → ビルド → コミットの順を守る」 という制約です。
Codex はその順序を守っていたため、中途半端な変更を無理にコミットせず、未コミットのまま停止 していました。結果として作業ツリーは「どこまで進んだか」がそのまま残った状態で、私は以下の流れで安全に続きを引き継げました。
git status # 未コミットの変更を把握
git diff # Codexがどこまで書いたか差分で確認
# → 内容を精査し、メイン側（Claude Code）でビルド・テストを通してからコミット
もし「順序を守らず、ビルドが通らない状態でとりあえずコミットしておく」挙動だったら、壊れたコミットを取り除く後始末が発生していました。「順序」と「push しない」を最初に明文化しておいたおかげで、中断が事故にならなかった わけです。
移譲の設計では「うまくいったとき」より 「途中で止まったときにどう安全に受け取れるか」 を先に決めておくのが、実は一番効きます。
チーム開発・受託への一般化
ここまでは私個人の運用ですが、考え方はそのままチーム開発・受託開発に応用できます。AIツールを複数併用するときの原則はシンプルです。
「作業（手を動かすこと）」は分担してよい。「品質保証（最終判断）」は分担しない。
これは人間同士の分業とまったく同じ構造です。実装を後輩やパートナー会社に任せても、レビューとマージの責任はチームに残る。AIツールが増えても、この責任の所在は動かしません。
そのうえで、AIに渡す指示は「文脈ゼロの相手にタスクを引き継ぐドキュメント」として書く。これは実は 人間向けの良いチケット・良い引き継ぎ資料の書き方そのもの です。ファイルパス・行番号・再現手順・受け入れ基準・スコープの4点が揃った指示は、AI相手でも人間相手でも事故を減らします。AI活用の練習は、良いドキュメントを書く練習でもあるのです。
まとめ
- レビュー軸と実装移譲軸は別レイヤー。「レビューは自前、実装移譲はCodex」は矛盾しない
- レビューを自前にした理由：規約 grep ＋ ビルド／テストで大半を潰せて、AIレビューは費用対効果が合わなかった（※ワークフロー依存）
- 実装移譲の目的はトークン節約。ただし diff レビューと本番適用の判断は必ず自分に戻す
- 引き継ぎ資料は自己完結 させる。パス・行番号・失敗シナリオ・修正方針・受け入れ基準を明記
- 制約に「スコープ厳守／実装→ビルド→コミット順／DB本番適用しない／pushしない」を毎回書く
- 途中で止まっても安全に引き継げる設計が、実運用ではいちばん効く
AIツールが増えるほど「最強の1本」を探したくなりますが、実務で効くのは 役割分担の設計 の方でした。
参考
- Codex CLI（OpenAI 公式ドキュメント）
- Codex CLI Non-interactive mode（codex exec / OpenAI 公式）
- codex/docs/exec.md（openai/codex 公式リポジトリ）
- Claude Code 公式ドキュメント
@kotaro_ai_lab
AI活用や開発効率化について発信しています。フォローお気軽にどうぞ！