結論、Claude CodeとCodex CLIを同じプロジェクトで気分次第で切り替えながら使うのは、最初の3日はわりとカオスでした。同じファイルに2回違うコミットが乗ったり、片方で書いたメモがもう片方から見えなかったり。それでも7日続けたら作業時間が4時間から1.5時間まで縮みました。何が地雷で何が効いたのか、実際にやってみた手順と失敗を残します。
なぜ2つのCLIを併用しようと思ったか
普段はClaude Code1本でした。気になっていたのはコストです。1日4〜5時間使うと月の請求がじわじわ膨らみます。私の環境では自動化スクリプトの量産フェーズで、1日のセッションコストが想定の2.5倍に膨れた月があって、さすがにこのまま増やすのは怖いなと思ったのが始まりでした。
仮説はシンプルで、判断系と対話系はClaude Code、同型ファイル量産はCodex、CLAUDE.md/AGENTS.md/メモリ/MCPは両者で共有。言葉にすると綺麗ですが、「共有」の3文字に1.5日溶かしました。
環境
- OS: Windows 11 Pro 24H2
- シェル: PowerShell 5.1とGit Bash併用
- Node.js: 22.11.0
- Claude Code: 2.0系 / Codex CLI: 0.36系(npm経由)
- プロジェクトサイズ: Pythonファイル約480本、CLAUDE.md 312行
両方ともnpm経由で1分で入りました。設定が地雷でした。
Day 1: いきなり二重コミットが発生する
初日、軽い気持ちでCodex側を起動して、Claude Codeで作りかけだったツールの仕上げを頼みました。1時間後、git logを見たらこうなっていました。
1a2b3c4 feat: add csv exporter (Claude Code session)
2b3c4d5 feat: add csv exporter (Codex session)
3c4d5e6 fix: merge conflict between csv exporter implementations同じ機能が別ファイル名で2回実装されていました。これ、完全に自分が悪いんですけど、両CLIに「未コミットの作業状況」を渡せていなかったからです。この時点でいったんコーヒーを置きました。怒る相手が自分しかいないタイプの事故です。最初はエラーが出たわけではなく、両方とも「成功した」風に見えたのが厄介でした。テストも通る。けど内部にゴーストが生まれている。
対策は地味で、切替時に必ず以下を踏むルールにしました。
- 切替前のCLIで
git add . && git commit -m "wip: handoff"まで進める - 未コミットでも進捗を後述のメモリに書く
- 新CLI起動直後に
git log -5 --onelineとgit statusを読ませる
3日目以降、これだけで二重コミットがゼロになりました。
Day 2-3: 片方だけ古いルールで動く事故
Claude Codeは CLAUDE.md を、Codex CLIは AGENTS.md を読みます。中身を同じに保ちたい。最初は両方を手動で直していて、3回くらい片方の更新を忘れて、Codex側だけ古いルールでコミット文面が崩れる事故を起こしました。「同じファイル2本置き運用」を舐めていたのが原因です。
pre-commit hookでCLAUDE.mdからAGENTS.mdを自動再生成する短いスクリプトに切替えました。生成直後のAGENTS.mdをCodexに食わせたら、ルール表のあと半分が「無かったこと」になっていて、見出し直後を行頭から詰めすぎていたのが原因でした。## 見出しのあとに必ず1行空行を入れる整形を足したら、ちゃんと全部読んでくれます。同期の仕組みそのものは別の記事で書いたので、ここでは併用したからこそ刺さる地雷だけ。要は両CLIで指示の解釈ぶれを起こす最大原因は、人間の二重メンテでした。これ完全に自分が悪いんですけど、いったんラクするためのhook化に1日かかったのも含めて、もう少し早くやればよかったです。
Day 4: メモリの場所問題で迷子になる
Claude Codeにはセッションを跨いだメモリ機能があり、私は188件ほど溜めています。Codex側からこれを参照できないと、片側でしか前提が効きません。最初に試したのはディレクトリをCodexのワークスペースにコピーする方法。即破綻でした。両側で更新するたびに差分が増えて、どっちが正解か分からなくなります。
採用したのは小さなMCPサーバーを1本書いて、両CLIから同じファイルを読み書きさせる方式です。MCPの作り方そのものは別の記事に書いたので、ここでは併用ならではの痛い話だけにします。.mcp.json と ~/.codex/config.toml の両方に同じMCPサーバーを登録します。
# ~/.codex/config.toml の該当部分
[mcp_servers."project-memory"]
command = "python"
args = ["C:/project/tools/project_memory_mcp.py"]ハイフン入りのサーバー名はクォートで囲わないとTOMLが怒ります。私はここで30分溶かしました。あと、書き込み側は tmpファイル経由でリネームしてアトミックに差し替えないと、両CLIがほぼ同時にwriteしたときに片方の内容が消えます。これは実害が出るまで気づかず、3日目の夜に貴重なfeedbackメモを1件失いました。
Day 5: 体感差が見えてくる
両者の得意分野
5日目には両者の得意分野がハッキリしてきました。Claude Codeは仕様の曖昧な依頼を整理しながら実装するのと、長いデバッグで粘り強く掘る用途に強い。Codex CLIは同型ファイルを20本作る量産系と、機械的な一斉修正に強い。
同じタスク(180行の自動化スクリプトをゼロから生成)を両者に投げて記録したところ、こうなりました。
Claude Code: 実時間 14分 / 出力品質 9/10 / コスト指数 1.0
Codex CLI: 実時間 8分 / 出力品質 7/10 / コスト指数 0.25コスト指数は私の環境での感覚値で厳密じゃないんですが、肌感としてCodexは4倍効率に見えるけど品質では2点落ちる。最初は「全部Codexでよくないか」とニヤッとしましたが、Codex単独で詰めた設計をClaude Codeに見せたら静かに直されまくったので、設計はClaude Codeで詰めてから量産だけCodexに渡す運用に落ち着きました。
Day 6: 並列起動で1度だけ事故った
6日目、5日目までうまく回り過ぎたせいで、調子に乗ってCodexを5本並列で起動しました。1本目は本文執筆系の長文タスク、残り4本は軽量チェック。1時間後、見たことのないログが出ました。
ERROR: You've hit your usage limit.
try again at YYYY-MM-DD HH:MM.Codex CLIには日次の使用量制限があります。プロセス自体はexit 0で終わるので、ログを見ないと失敗に気づけないのが地味に怖い挙動です。気づいたのは2時間後で、その間に「終わったつもりの4本」が全部空打ちでした。並列するなら軽量タスクのみ最大3本、本文執筆系は1本ずつ、というルールを後付けで足しました。
Day 7: 1日4時間が1.5時間になった
7日目、定型業務(自動化ツール3本のメンテとブログ下書き1本)を計測しました。これまで4時間かかっていた一式が1時間半に。内訳は仕様整理にClaude Codeで30分、同型ツール3本の修正にCodexで25分、下書き起草にCodexで15分、仕上げと公開判断にClaude Codeで20分。1ヶ月換算で50時間以上の節約です。最初の3日で溶かした分が、4日目以降に何倍にもなって返ってくる感じで、これは正直やってよかった。
2つのCLIを併用するときの落とし穴チェックリスト
- 切替前に必ずgit commit、または進捗をメモリに書く
- CLAUDE.mdとAGENTS.mdの同期はpre-commit hookで自動化する
- メモリは両CLIから同じMCPサーバー経由で読み書きする
- MCP設定でハイフン入りサーバー名はクォート必須
- OAuthトークンは両CLIで使い回さない(リフレッシュ衝突する)
- Codex並列起動は3本まで、本文執筆系は1本ずつ
- シンボリックリンクはWindowsだと管理者権限が必要、コピー方式が無難
- 新CLIを起動したら最初の指示で
git log -5とgit statusを読ませる
最後の確認
これから併用を試す人へ。Codex CLIをnpmで入れ、プロジェクト直下にAGENTS.mdを作り、両方の設定ファイルに必要なMCPサーバーを登録し、軽量タスクを1本だけCodexに投げて挙動を見ます。切替時の git status 確認をルールにすれば、最初の3日のカオスはだいぶ短くなるはずです。
道具を1つ増やすと最初は手間が2倍に見えますが、3日我慢すると1.5倍速くなる。AI開発まわりはまだそのパターンが多いです。
コメント