Claude Code と Codex CLI の両方を契約していると、「どう連携させるか」と「どこで Codex を使うか」の 2 点で迷います。

実装を分担させるのか、それともレビューだけ頼むのか、どちらが良いのでしょうか？

このブログでは 2026 年 9 月に、Codex を記事作成の途中工程に組み込み、翌日に外した経緯があります。

途中工程に Codex を組み込む体制が本当に適していなかったのかを検証するため、同じ仕様のコードを 2 つの体制で作り比べ、Claude Code から Codex を呼ぶ 3 つの経路も同じ差分で比較しました。

Claude Code から Codex を呼ぶ方法

Claude Code から Codex を呼び出す方法として、ネット上では MCP、公式プラグイン、Codex CLI の直接呼び出しの 3 つがよく紹介されています。

今回、手元の Codex CLI 0.154.0（2026 年 9 月 10 日リリース）で検証した結果、利用できた方法は以下のとおりです。

MCP が利用可能かどうかについては、執筆時点で最新の 0.159.3 でも確認しています。

※ effort は、AI が回答を出力する前に思考する度合いを設定する項目です。

採用したのは codex exec を読み取り専用で呼ぶ方法

この記事のレビューは、以下の形式で Codex に依頼しました。

codex exec -m gpt-6-astra -c model_reasoning_effort=medium -s read-only "<レビューの依頼文>"

採用した理由は以下の 3 点です。

• モデルと reasoning effort をコマンドで固定できる
• 依頼文で「SPEC.md に照らして確認して」と指示できる
• -s read-only を指定することで、Codex にファイル変更をさせずに済む

公式プラグインは /codex:review の effort を指定できない

公式プラグインは、マーケットプレイスを追加してからインストールしました。

$ claude plugin marketplace add openai/codex-plugin-cc
✔ Successfully added marketplace: openai-codex (declared in user settings)
$ claude plugin install codex@openai-codex --scope project
✔ Successfully installed plugin: codex@openai-codex (scope: project)

マーケットプレイスはユーザー単位の設定に反映されるため、プラグイン本体は --scope project で検証用ディレクトリに限定して設置しました。

使用可能なコマンドは以下の 8 つです。

課題となったのは、/codex:review に effort を指定するオプションが存在しない点です。

--model gpt-6-astra は認識されましたが、effort には Codex のグローバル設定（当方の環境では high）がそのまま適用されました。

Codex のログ（~/.codex/logs_2.sqlite）にも、model=gpt-6-astra codex.turn.reasoning_effort=high と記録されていました(^^;

MCP は 0.153.4 を指定すれば接続できる

最も広く紹介されている MCP の登録について、0.154.0 では接続できませんでした(´・ω・`)

$ claude mcp add codex -- codex mcp-server
Added stdio MCP server codex with command: codex mcp-server to local config
$ claude mcp list
codex: codex mcp-server - ✘ Failed to connect — CONNECTION_CLOSED: Connection closed

codex --help のサブコマンド一覧に mcp-server が含まれておらず、0.159.3 でも同様でした。

ひとつ前のバージョンである 0.153.4 では、非推奨の警告が出力されるものの動作しました！

$ claude mcp add codex -- npx -y @openai/[email protected] mcp-server
$ claude mcp list
codex: npx -y @openai/[email protected] mcp-server - ✔ Connected

warning: `codex mcp-server` is deprecated and will be removed in a future release.

提供されるツールは codex と codex-reply の 2 つで、codex ツールの config 引数に {"model_reasoning_effort": "medium"} を渡すことで effort を固定できました。

-s workspace-write で一度動かすと、そのディレクトリが信頼済みになる

作業完了後に ~/.codex/config.toml を作業前のバックアップと照合したところ、未登録の設定が追加されていました。

> [projects."/Volumes/SSD-Kioxia-2TB/Projects/laratech/claude-code-codex-demo"]
> trust_level = "trusted"

更新時刻は、codex exec -s workspace-write を実行した時刻と一致していました。

この記述を削除してから -s workspace-write で再度実行すると、同様の設定が再追記されました。

信頼済み状態になると、-s を付与しない codex exec のサンドボックスの動作が変化します。

レビューのみを目的とする場合は、毎回 -s read-only を明示的に付与して実行するのが安全です。

なお、プロジェクト内に配置した .codex/config.toml も、信頼済みディレクトリでのみ読み込まれる仕様となっていました。

このブログで Codex を途中工程に入れ、翌日に外した経緯

2026 年 9 月 10 日に、Claude Code をディレクター、Codex CLI 経由の GPT-6 Astra を作業者とする連携体制を構築しました。

Codex にはファイル編集を担当させ、コミットおよびプッシュは必ず Claude 側で行うという役割分担です。

当初は記事の一次執筆を Astra に任せ、Claude が文体ルールチェックと差し戻しを行う運用でした。

しかし、確認と差し戻しのやり取りによるオーバーヘッドが増大しました。

そこで一次執筆を Claude に戻し、Astra の担当領域を構成案作成と推敲に絞り込みましたが、最終的に同日夜に Astra を記事作成パイプラインから除外しました。

コミットメッセージに残されている理由は「GPT-6 の不調」となっています。

当時 GPT 側の接続障害だったのか、あるいは高負荷なプロンプトの処理に起因するものかは不明ですが、生成される文章品質に大きな差異が見られなかったため、この時点で連携運用を中断しました。

同じ仕様のモジュールを 2 つの体制で開発し、検証してみた

言語は TypeScript（Node.js）を採用し、テストフレームワークには Vitest を使用しました。

開発対象は、ブログ記事を指定日時に自動公開する「予約公開」の判定処理です。

UI やデータベースは構築せず、以下の 4 つの関数のみを仕様として設定しました。

開発および検証環境は以下のとおりです。

このモジュールを、以下の 2 つの開発体制で作成しました。

• 体制 A: Codex を途中工程に組み込む（Claude Code が設計を行い、Codex が実装を担当）
• 体制 B: Codex は最終レビューのみ担当（Claude Code が実装完了までを担当）

検証は以下の手順で実施しました。

1. 仕様書（SPEC.md）を作成する
2. 受入テストを 22 件作成し、両エージェントから参照できない場所に配置する
3. 体制 A で開発を行う（Claude Code が設計書作成 → Codex が実装 → Claude Code がレビューおよび差し戻し → Codex が修正 → Claude Code が承認）
4. 体制 B で開発を行う（Claude Code が実装とテストコードを作成 → Codex が読み取り専用でレビュー → Claude Code が指摘事項を適用）
5. 両体制の成果物に対して受入テストを実行し、処理時間および合格数を比較する
6. 体制 B の差分を、他の経路（MCP、プラグイン、codex review）および Claude Code のレビュー用サブエージェントにも適用し、指摘内容を比較する

体制 A・B における「Claude Code」は、検証用ディレクトリで個別に起動した claude -p のセッションです。

補足として、CLAUDE.md が複数存在する環境では、--settings オプションで claudeMdExcludes を渡すことで読み込みを除外できます。

claude -p "<指示文>" --model claude-opus-5-5 --effort medium \
  --settings '{"claudeMdExcludes":["/path/to/laratech/CLAUDE.md"]}'

Codex に送った最終レビューの依頼文

体制 B において Codex へ送付したレビュー依頼文の全文です。

このリポジトリの main ブランチと現在のブランチの差分(`git diff main...HEAD`)をコードレビューしてください。
SPEC.md を仕様として、バグ・仕様違反・テストの不足を探してください。
各指摘に重要度(P0〜P3)、ファイルと行、理由を付けてください。指摘がなければ「指摘なし」と書いてください。
ファイルは変更しないでください。

MCP 経由の実行でも同一の依頼文を渡しています。

codex review およびプラグイン経由では、依頼文を指定せず標準組み込みのレビュー機能を使用しました。

体制 B は体制 A の約 3 分の 1 の時間で、受入テストの結果は同一だった

体制 A における 5 つの工程実績です。

差し戻し理由は「年 0000 の日時が 0001 と表示される」点でした。

処理が途中で停止することはなく、手動でのコード修正や追加の指示出しは発生しませんでした。

体制 B における 3 つの工程実績です。

Codex からの指摘事項は、体制 A の差し戻し内容と同様の年 0000 に関するものでした。

[P3] 年 `0000` の公開日時が `0001` と表示される — src/schedule.ts:116
`formatPublishedAt` に `publishedAt: '0000-01-01T00:00:00Z'`、`tz: 'UTC'` を渡すと、
期待する `0000-01-01 00:00` ではなく `0001-01-01 00:00` を返します。
`Intl.DateTimeFormat` が返す紀元前年を、紀元情報なしで使用しているためです。

外部に配置していた受入テストを実行した結果と、全体の所要時間一覧です。

2 月 30 日や 25 時指定、タイムゾーン指定なしなどのエッジケースを含めて検証を行いましたが、両体制とも初回のテスト実行から全件成功しました！

実行環境のタイムゾーンを America/Los_Angeles に変更した場合も結果は同様でした。

出力成果物の品質が同等であれば、Codex を途中に挟まない体制 B のほうが約 3 分の 1 の所要時間で完了する結果となりました。

重大な不具合は Codex のいずれの経路でも検出されなかった

体制 B の同一差分に対し、Claude Code のレビュー用サブエージェント（--agents で定義した reviewer）に同内容の依頼文を入力して検証しました。

サブエージェントは 52 秒で 4 件の指摘を出力しました。

最も重要度の高い P2 の指摘は、Codex のいずれの呼び出し経路においても検出されませんでした。

一方で、年 0000 の指摘については Codex 側のみが検出し、Claude のサブエージェントでは検出されませんでした。

また、テスト実行の可否に関しても差が生じました。

読み取り専用サンドボックス内では Vitest の一時ファイル作成が制限されるため、codex exec、codex review、MCP の 3 経路では EPERM エラーが発生しテストを実行できませんでした。

プラグイン経由の Codex のみが npm test -- --configLoader runner --no-cache --pool threads という回避コマンドを自動生成して実行し、62 件のテストを通過させていました。

同一の Codex であっても、接続経路によってリカバリ動作に違いが見られました！

プラグイン経由のみ effort 設定が high となっていたため、より高度な推論が行われた結果として回避策に到達した可能性があります。

なお、プラグインと codex review は、双方とも Codex 組み込みのレビュー機能に対して「main との差分」を渡す仕組みであり、指示プロンプトは同等です。

ただしプラグイン経由の検証は 1 回のみの実施であるため、effort 設定の差が直接影響したかについての確証はありません。

入力値チェックの厳格さにおける差異は Claude の設計書に起因

P2 指摘に該当する値を、両体制の最終成果物に適用して挙動を確認しました。

体制 A で厳格な判定が行われたのは、Claude Code が設計書段階で「Date.parse に依存しない」旨を定義していたためであり、Codex を開発プロセスに組み込んだことによる直接の効果ではないと考えられます。

日本語文章の推敲における役割分担

参考検証として、本ブログ記事の推敲処理を Codex へ依頼しました。

本記事の下書き（本節を除く）に対し、ブログの文体ルールを添付して codex exec -s read-only によるレビューを実行しました。

検出された 13 件の指摘はすべて妥当であり、手元のローカルチェック用スクリプトでは検出できない内容が含まれていました。

ただし、本レビューの処理には 2263 秒（約 38 分）を要しており、コードレビューの処理時間（53 秒）と比較して極めて長くなった要因については未特定です。

実際の指摘事項は以下のとおりです。

日本語表現の不自然さ・難解さ（6 件）

文体ルールへの不適合（4 件）

数値・記述内容の不整合（3 件）

サムネイル画像を条件変更により 3 回作成・比較する

ニュース番組のスタジオにおいて、架空の日本人解説員がモニターを指し示しながら記事内容を解説している実写風サムネイルの生成を依頼しました。

生成条件を変更し、計 3 回の比較検証を行いました。

なお、生成された画像内の人物はすべて AI によって生成または描画された架空の人物であり、実在の人物とは関係ありません。

ケース 1: ツールごとに作成方法を指定した場合

1 回目の検証では、Codex には画像生成機能を、Claude Code には HTML/CSS を用いた描画手順をそれぞれ個別の指示で依頼しました。

Codex ケース 1

Codex は組み込みツールの image_gen を使用して 1 枚の画像を生成しました。

モニター内の「最終レビュー」表記や見出しの「連携」といった文字列も、崩れることなく描写されていました！

Claude Code ケース 1

Claude Code による出力は、人物を SVG 描画したイラスト形式となりました。

ケース 1 の比較結果

ただし、Claude Code に対してのみ「イラストによる代替表現」を容認する条件を提示していたため、厳密な同一条件下の比較ではありません。

ケース 2: 同一指示文を用い、作成手法を任せた場合

2 回目の検証では、作成手法を指定せず、両者に共通のプロンプトを投入しました。

技術ブログ記事のサムネイル画像を1枚作ってください。

記事の内容: 「Claude Code と Codex CLI を連携させるなら、作業の途中工程ではなく最終レビューを Codex に任せるのがアリ」という検証記事。

画像の要件:
- 1280x720 の PNG。
- 実写の写真のような見た目。ニュース番組のスタジオで、日本人の解説員(架空の人物。実在の人物に似せない)が、横の大きなモニターを手で示しながらこの記事を解説している場面。
- モニターには、左に「Claude Code」、右に「Codex」と書いた2つの箱と、その間に矢印、矢印の下に「最終レビュー」という文字がある簡単な図。
- 画面上部か下部に、大きな日本語の見出し「Claude Code×Codex 連携」。
- Anthropic・OpenAI のロゴ、その他の製品ロゴやブランドマークは入れない。

完成した画像を ./thumbnail/thumbnail.png として保存してください。
git commit / git push はしないでください。
最後に、どの方法で画像を作ったかと、作ったファイルを報告してください。

Codex ケース 2

Codex はケース 1 と同様に画像生成を実施し、sips コマンドを用いて 1280x720 サイズへ補正しました（処理時間: 92 秒）。

Claude Code ケース 2

Claude Code 側の処理では、環境内に Codex CLI が存在することを検知すると、自発的に codex exec を呼び出し、写真部分の生成を Codex の画像生成機能に委ねる動作を見せました。

その上で、見出しテキスト処理のみ Python の Pillow ライブラリを用いてヒラギノ角ゴシックで重畳描画を行いました（処理時間: 136 秒）。

Claude Code の処理レポートには、テキスト描画を個別処理した理由として「画像生成ツールへ直接文字出力を任せるとフォント崩れが発生しやすいため」と記載されていました。

明示的な指示がない状態で、Claude Code 側から Codex との連携処理が構築される結果となりました。

なお、Claude Code から実行された codex exec にはモデルや effort のパラメータ指定が含まれておらず、Codex 側のグローバル設定（effort: high）で動作していました。

ケース 3: 同一指示文で、HTML/CSS のみによる実写描画を指定した場合

3 回目の検証では、ケース 2 の指示プロンプトを以下のように修正し、両者に同一内容で投入しました。

• HTML/CSS で構築し、指定コマンドにより PNG 出力を行うこと
• 実写写真相当の質感描画を目指す指定とし、代替表現の例外規定を排除
• 外部画像ファイル、Web フォント、画像生成 AI（Codex 等を含む）の使用を禁止
• 変換後の PNG を出力確認し、崩れが存在する場合は自己修正を行うこと

Claude Code ケース 3

Claude Code は 2 回の画像変換処理を実行し、初回出力で発生していた「Claude Code」文字列の折り返し不備および肩幅の描写不良を自発的に検知して修正を加えました（処理時間: 173 秒）。

Codex ケース 3

Codex は HTML コードの生成までは完了したものの、PNG への変換処理で 2 回連続でエラーとなりました（処理時間: 254 秒）。

Codex のサンドボックス環境内からレンダリング用ブラウザ（Chrome）を起動できなかったことが原因です。

Codex が生成した HTML ファイルを変更せず、同一の変換コマンドをサンドボックス外部で手動実行することにより PNG ファイルを出力しました。

ケース 3 の比較結果

双方とも実写写真相当の品質には達しておらず、実行レポートにおいても「実写レベルには達しなかった」「髪・肌・手のリアルな質感描画は断念した」との自己評価が記載されていました。

Codex 側はレンダリング結果の画像確認を行えなかったため、出力結果を確認して修正を行うプロセスを経た Claude Code とは前提条件が異なります。

また、両ツールともに指示に含まれていない「検証」ラベルや「TECH REPORT」といった追加テキストを描画に含めていました。

3 回の検証結果まとめ

実写風の画像出力を行うには、専用の画像生成機能の利用が不可欠です。

HTML/CSS 描画のみの制約下では、いずれのツールにおいても実写レベルの描写には到達しませんでした。

一方で、テキストの視認性や正確性を担保したい場合は、ケース 2 で Claude Code が採った「画像生成による背景写真と、コード描画によるテキスト重ね合わせ」の組み合わせが極めて有効です。

なお、本記事のサムネイル画像には、ケース 1 で Codex が生成した画像を採用しています。

Claude Code と Codex の共存の方針（結論）

環境はどんどん変わっていくと思いますが、現時点だと作業の途中の処理を Codex などに任せるのは微妙だと感じます。

理由としては、Claude Code がエージェントとして仕事を振っていくのですが、

人間と同じで伝言ゲームになって、あまり正確ではないと感じるからです。

（これはサブエージェントに送るパターンでも言える）

自分で正確にその引き継ぎの文言などを書くのであれば、より精度が高まる可能性もあると思うので、そこは自分の検証不足ということで、すでに完璧に運用している人がいたとしたら申し訳ないです。

「Codex を最終レビュー役」に配置する

今回の検証結果を総括すると、以下のようになります。

• 受入テストの合格率は同等であり、Codex を途中工程に組み込んだ体制 A は体制 B と比較して約 3.1 倍の作業時間を要した
• 最終レビュー役としての Codex 実行は 1 回あたり 34〜63 秒で完了し、ファイル書き換えを伴わずに Claude とは異なる視点の指摘を 1 件検出した
• 最も重大な不具合指摘については、Claude のサブエージェント側のみが検出した

結論として、「Codex を最終レビュー役に配置する運用は有効であるが、Claude 自身のレビュー工程を代替させるものではない」という整理になります。

とはいえ、レビューを複数人が行い、リストで提示してくれるのはありがたいですし、

デメリットがあまり感じられないので、Codex にレビューを依頼するのはアリだと思います。

ただし、effort の設定は high 以上に設定した方が良いと思います。

middium は検証速度が流石に早すぎるんじゃないかと思います。

早すぎて見落としがあるみたいなパターンで、なんとなくやったみたいな印象を受けています。

HTML 画像は Claude Code、実写画像は Codex

これは当たり前の結果なのですが、実写画像を使いたい場合は Codex 一択になります。

しかし、実写画像を必要とするパターンは文章を書いたりするタスクとなっていて、エンジニアのコーディングにはあまり必要のないスキルだと思いますし、ドキュメントとしてアーキテクチャを描くパターンだとしたら Claude Code で十分なものを作ってくれます。

僕みたいにブログで研究結果を発信したい人とかは Codex に画像を作らせても面白いんじゃないかなとは思いますが、自分はあんまり驚かない系のライティング（利用方法について真剣に考察したい系）だと思っているので、画像も Claude Code のスライド形式で十分だなぁという感じ。

Claude Code のトークンでは足りず、Codex を併用したいパターン

基本的に Claude Code だけでやる方が簡単だし、サブエージェントでモデル変えて強弱つける運用が一番だと思いますが、トークンが若干足りなかったりして Codex に切り分けたい人もいると思います。

その場合は、タスクを完全に切り離せるところや、作業が完了した後の品質向上（今回のレビューのみのような）のための担当にする方が良いと思いました。

まぁそんな運用をしている人はもうすでに無限にいると思いますが。

AI 同士で 24 時間働かせる系の話について

現時点、それは有用ではないと思います。

議論と整理までやって、人間に提示するまでであれば良いと思います。

AI 同士の議論で実装までされるのは現実的な運用としてマイナスな面が多いように感じます。

そこまで勝手にされると、人間によるレビューが大変すぎる。

おそらく SNS で、AI コンサルタントと名乗る謎のみなさんが 24 時間働かせているのは、薄いポエムを垂れ流して note で小銭稼ぎしてるだけなんだろうなぁと思ってしまいます。

人が実装に追われることは少なくなったけど、まだまだ介入する必要性を感じる今日この頃でした。

最後まで読んでいただきありがとうございました。