Claude Code vs Codex: どちらかを選ばず、開発者が 2 つに仕事を振り分ける 7 つの方法

2026 年 3 月 30 日、OpenAI は codex-plugin-cc を公開しました。Claude Code の中から Codex を動かすプラグインです。README には対象が書かれています。Codex を "from the workflow they already have" (すでに使っているワークフローから) 使い始めたい Claude Code ユーザーです。OpenAI はそのユーザーに乗り換えを求めていません。すでに選ばれたツールの隣に席をひとつ求めています。「Claude Code vs Codex」で上位に出る比較ページは、最後の行に勝者が書かれた機能比較表で、どちらか一方を選ぶことを前提にしています。

そこでこの記事は、順位付けではなく、仕事がどう分けられているかの一覧にします。以下ではラベルを 2 つ使います。文書化済みは、ベンダー自身のドキュメントかリポジトリがその仕組みを説明しているという意味です。報告は、名前のわかる人が自分の構成を公開しているもので、この記事ではそれを自分で再現せずに紹介しているという意味です。バージョンに関する記述はすべて 2026 年 10 月時点のものです。

5 月に、ほとんどの仕事には Claude を使い、明らかに優れているいくつかの仕事には Codex を使っていると書きました。以下のパターンは、同じ考えをもとに他の人たちが組み立てたものです。ただし違いがひとつあります。大半は、どちらのモデルがその作業に強いかではなく、役割で分けています。

Claude Code が書いたばかりのコードを Codex にレビューさせられるか

できます。7 つのうち、いちばん裏付けが多い分担です。文書化済みです。プラグインは Claude Code に /codex:review を追加します。未コミットの変更、またはベースに対するブランチをレビューするコマンドで、README には "is read-only and will not perform any changes." (読み取り専用で、変更は一切行わない) とあります。README は、Codex の中で /review を実行した場合と同じ品質のレビューを約束しています。その /review は、OpenAI のコードレビューのドキュメントによると、作業ツリーを変更せずに、優先度を付けた指摘を報告します。

どちらのツールにも、すでに自前のレビュアーがあります。Claude Code にはローカルの /code-review と、Team および Enterprise プラン向けのマネージド型 GitHub Code Review があり、Anthropic は後者の費用をレビュー 1 回あたり平均 15 〜 25 ドルとしています。レビュアーが足りないからベンダーをまたぐ人はいません。別のモデルファミリーに、その diff を生んだ会話なしで読ませるためです。

会話がないことは、ファミリーが違うことと同じくらい効いています。書き手のセッションを丸ごと渡されたレビュアーは、事実と一緒に、書き手が捨てた推測まで引き継ぎます。あなたがフォークしたサブエージェントは、すでに知りすぎていますで書いたのと同じ汚染です。/codex:review は Codex を Claude Code のセッションではなく diff の上で起動します。この新鮮さはコマンドがもたらすもので、別のコマンドでは保たれません。同じプラグインには後述の転送コマンドがあり、そちらはセッションを向こうへ運ぶこと自体が目的です。

8 月には、レビュアーの席は気質で決めるべきだと論じました。歩き回り、疑い、確認しすぎるモデルがそこに向いています。その記事には、モデルファミリーをまたぐレビューについて自分の経験として言える唯一のことも書いてあります。異なるファミリーの 2 つのレビュアーがその議論の最初の版を読み、それぞれが別の誤りを見つけました。記事ではファミリーの名前を挙げていませんし、1 件の事例は割合ではありません。

コードを書く前に、Claude Code の計画を Codex に批判させられるか

これは、diff ではなく計画という、より手前を狙う最初のパターンです。プラグインにはそのための 2 つ目のレビューコマンドがあり、計画に向けて使っているという報告があります。まず文書化済みの部分です。/codex:adversarial-review はフラグの後ろに自由記述のフォーカスを受け取ります。README によると用途は "pressure-testing around specific risk areas like auth, data loss, rollback, race conditions, or reliability." (認証、データ損失、ロールバック、競合状態、信頼性といった特定のリスク領域に負荷をかけて試すこと) です。こちらも読み取り専用です。対象の選び方は /codex:review と同じで、リポジトリ内の変更から選びます。そのため、計画をレビューさせるには、計画が作業ツリー内のファイルとして存在している必要があります。

次に報告の部分です。Engr Mejba Ahmed は、Claude Code にマイグレーション計画を書かせ、実装の前に Codex にそれを攻撃させる流れを説明しています。本人の説明では、レビューは外部キーの欠落と、同時書き込みでデッドロックしうるインデックスを見つけました。計画レビューは 2 ラウンドまでと決めているそうです。3 ラウンド目が必要なら、計画に要るのは追加の批評ではなく別のアプローチだ、という理由です。持ち帰れるのはこの上限です。2 つのモデルは、料金を払い続けるかぎり、いつまでも礼儀正しく意見を違え続けられます。

Claude Code が計画とレビューを担い、Codex がコードを書くべきか

逆向きに回している人もいます。分担は役割に従うもので、それぞれの役割にどのブランドを置くかは入れ替えがききます。こちらは報告のみです。longranger2 の plan-execute スキルは、完成した計画ファイルを受け取り、Claude Code がそれを Codex に送って実装させます。続いて Claude Code が各結果をレビューして reviews/ ディレクトリに書き出し、見つかった問題を直すよう Codex に差し戻します。スキルが明記しているルールは、このループの中で Claude Code はコードを一切書かず、編集もしないことです。レビューと指揮だけを行います。

最初のパターンと並べると、矛盾して見えます。一方では Codex がレビュアーで、もう一方では実装者です。けれども肝心な点は一致しています。書き手とレビュアーは別のシステムであり、その間を行き来するのはファイルです。書き手の椅子に Claude Code と Codex のどちらが座るかは、自分のコードベースでスコープを守ると信頼できるのはどちらのモデルか、という好みの問題です。その好みが別のコードベースにも通用する見込みは薄いです。持ち越せると言う表は疑ってかかるべきです。

行き詰まった問題を Claude Code から Codex に渡すのはいつか

別のモデルによる 2 回目の試みが、同じモデルによる 5 回目の試みより安くつくときです。仕組みは文書化済みです。/codex:rescue は、プラグインがインストールするサブエージェント codex:codex-rescue を通じてタスクを Codex に渡します。README は想定される用途を挙げています。バグを調べる、修正を試す、以前の Codex タスクを続ける、あるいは "take a faster or cheaper pass with a smaller model." (小さなモデルで、より速いか安い一巡を回す) です。バックグラウンドでも実行でき、/codex:status と /codex:result で状況と結果を確認できます。普通の言葉で頼んでもかまいません。README 自身の例は、データベース接続の設計を Codex にやり直させるよう Claude に頼むものです。

2 つのレビューコマンドと違って、こちらはファイルを変更できます。プラグインの rescue エージェント定義は、読み取り専用の動作を求められた場合や診断だけが必要な場合を除き、書き込み可能な実行を既定にするよう指示しています。

委任について Mejba が報告しているルールは、自分で良し悪しを判断できる仕事だけを渡す、というものです。見抜けない誤答は、答えがないより悪いからです。どんな委任にも通じるもっともなルールですが、ベンダーをまたぐといっそう効いてきます。見分けるべき癖が 1 組ではなく 2 組になるからです。

Codex で Claude Code の毎ターンに自動でゲートをかけられるか

できます。そして、プラグインの README 自身がそれについて警告しています。スイッチは文書化済みです。/codex:setup --enable-review-gate は Stop フックをインストールします。このフックは Claude の応答に対して的を絞った Codex レビューを実行し、問題が見つかれば停止をブロックします。Claude は先にそれに対処しなければなりません。警告はこの機能のすぐ下にあります。

The review gate can create a long-running Claude/Codex loop and may
drain usage limits quickly. Only enable it when you plan to actively
monitor the session.

Zachary Proser は、codex exec の上に自分のバージョンを作ったと報告しています。彼の Stop フックは作業ツリーとブランチのベースの差分を取り、高リスクのパス (認証、課金、マイグレーション、インフラを挙げています) に触れていない小さな diff ではレビューを省きます。それ以外では、diff と変更されたファイルを、敵対的な指示とタイムアウトを付けて codex exec に送り、判定を含む構造化 JSON が返ることを期待します。判定が block ならフックは失敗します。タイムアウトや壊れた出力でも同じです。彼のフックはフェイルクローズです。2 つのモデルの意見が割れたときは、多数決としてではなく、自分で読むべき行を指し示すものとして扱っています。

真似する前に注意がひとつあります。公開されているスクリプトは最終メッセージを message 型のイベントから読んでいますが、OpenAI の現在の非対話モードのドキュメントでは、最終メッセージは agent_message を載せた item.completed イベントとして届きます。自分では彼のフックを実行していませんが、フェイルクローズのフックでセレクターが何にも一致しなければ、すべてのターンがブロックされます。少なくとも、派手に気づける壊れ方ではあります。判定オブジェクトを得るには、ドキュメントにある --output-schema フラグのほうが堅実です。

いずれにせよ、真似する価値があるのはしきい値とフェイルクローズのルールです。しきい値がなければ、些細な編集のたびにレビューを 1 回買うことになります。フェイルクローズでなければ、タイムアウトが承認として数えられます。

Claude Code と Codex で指示を 1 セットにまとめて共有するには

AGENTS.md を使い、Claude 側に 1 行の糊を足します。どちらの半分も文書化済みです。Codex は ~/.codex から、続いてプロジェクトのルートから現在のディレクトリまで下りながら指示を組み立てます。ディレクトリごとに最大 1 ファイルで、ルート側から順に連結し、合計が既定の 32 KiB に達するとそれ以上ファイルを追加しません。Codex で /init を実行するとこのファイルが作られます。

v2.1.277 以降、Claude Code が既定で AGENTS.md を読むのは、作業ディレクトリとその上位に CLAUDE.md も CLAUDE.local.md もない場合だけです。両方のファイルがあるリポジトリでは、プロジェクト指示の設定を変えないかぎり CLAUDE.md だけが読み込まれます。その帰結は Claude Code が AGENTS.md を読むようになった。ただしデフォルトはフォールバックで詳しく見ました。その記事の助言は、両方のツールを使う人すべてに当てはまります。1 行目で共有ファイルをインポートする CLAUDE.md を置き、Claude だけに向けたルールはその下に書いてください。

同じ記事から、制約をひとつ。インポートが取り込むのは名指ししたファイルだけで、CLAUDE.md が存在すると、既定ではサブディレクトリの AGENTS.md を探さなくなります。Codex が下りていく途中で拾うネストされた AGENTS.md には、それ専用のインポートか、両方のファイルを読む設定が必要です。あの記事を書いた時点で、自分のリポジトリのひとつは逆の形でした。見出しが「Codex Instructions」の AGENTS.md があり、CLAUDE.md はまったくありませんでした。

@AGENTS.md
 
## Claude Code
 
Use plan mode for changes under `src/billing/`.

2 つのツールは共有ファイルを同じようには扱いません。Codex にはチェーン全体で 32 KiB の上限があり、ディレクトリごとに 1 ファイルを取ります。Claude Code は 4 MiB までの指示ファイルを丸ごと読み込み、200 行未満に収めることを推奨し、サブディレクトリのファイルは必要になったときに読み込みます。長い AGENTS.md 群は、一方の読み手では途中で切られ、もう一方では全部読み込まれることがあります。2 つのエージェントが違うルールに従っているように見えたら、モデルを疑う前に長さを確認してください。

セッションや構成全体を Claude Code と Codex の間で移すには

いまでは両ベンダーが相手側の設定を取り込むインポーターを提供しており、OpenAI は進行中のセッション向けのものも提供しています。すべて文書化済みです。6 月に追加されたプラグインの /codex:transfer は、次のことを行います。

Creates a persistent Codex thread from the current Claude Code session
and prints a `codex resume <session-id>` command.

構成全体については、Codex CLI に 2026 年 8 月 11 日から /import があります。OpenAI のインポートのドキュメントは、インポートで持ち込めるものを挙げています。指示ファイル、設定、スキル、プラグイン、MCP サーバーの設定、フック、スラッシュコマンド、サブエージェントです。CLI は過去 30 日間のチャットも最大 50 件インポートします。同じページは、ツールの制限、MCP の認証、フックは挙動が異なる場合があるので、インポート後に確認し直すよう勧めています。

Claude Code にはその鏡像があります。コマンドリファレンスには v2.1.213 から使える /import codex が載っています。指示ファイル、MCP サーバー、コマンド、サブエージェント、スキルを取り込み、--dry-run で事前に確認できます。/init は、Codex の設定を見つけるとこれを実行するか尋ねます。

どちらのインポーターも作るのはコピーです。2 つの構成をつなぐものではありません。例外がひとつあります。ChatGPT デスクトップアプリは、インポートした内容を自動更新で同期させておけます。CLI のドキュメントにそうしたオプションの記載はありません。コピーした構成は、どちらか一方を編集したその日から元とずれ始めます。実際の設定を入れた状態でもう一方のツールを試すために使ってください。2 つの設定を同じに保つ用途には向きませんし、指示については先ほどの共有 AGENTS.md のほうがその役目をうまく果たします。

組み合わせたとき、Claude Code と Codex は同じサンドボックスで動くのか

いいえ。プラグインが両者を統一することもありません。

Codex のセキュリティのドキュメントは、エージェントが既定でネットワークアクセスをオフにして動くと述べています。非対話モードのドキュメントは、--sandbox workspace-write を渡すまで codex exec は読み取り専用サンドボックスで始まると述べています。Claude Code のサンドボックスのページによると、Bash サンドボックスは既定でオフで、対象はシェルコマンドだけです。ファイルツール、MCP サーバー、フックはその外で動きます。どちらのサンドボックスもツール全体を覆ってはいません。Codex のネットワークフィルターが適用されるのはサンドボックス内のコマンドで、同じドキュメントによれば、ウェブ検索、MCP サーバーへの接続、コネクター呼び出しには適用されません。初期状態では、Claude Code は各ツール呼び出しの手前にあるパーミッションルールとモードに頼り、Codex は実行するコマンドを囲む OS レベルの境界に頼っています。同じタスクでも、どちらのツールが実行するかで、さらされる範囲が変わります。

分担した構成では、ここから具体的な帰結がひとつ出てきます。README を読んでも見つかりません。README は、プラグインが Codex を直接実行した場合と "the same local authentication state" (同じローカル認証状態) と "the same repository checkout and machine-local environment" (同じリポジトリのチェックアウトとマシンローカルの環境) を使い、Codex の設定を適用すると述べています。プラグインのソースはもっと具体的です。7 月 8 日のコミット時点で、プラグインは承認ポリシーを never、サンドボックスを read-only にして Codex のスレッドを開始します。そしてタスクが --write 付きで開始されると、タスクランナーがサンドボックスを workspace-write に切り替えます。rescue エージェントが既定で行うのがまさにこれです。つまり、委任された修正は、Codex のワークスペースサンドボックスの中で承認プロンプトなしに走ります。Claude Code で委任を承認することが、存在する唯一の承認です。バックグラウンドジョブの設計としては妥当ですが、守りを担っているのはサンドボックスだけだということでもあります。書き込みを委任する前に、どのディレクトリがワークスペースなのかを確認してください。

2026 年に使えなくなった Claude Code と Codex の連携はどれか

いくつかあり、古いチュートリアルにはまだ載っています。いちばん大きいのは MCP ブリッジです。しばらくの間、別のエージェントから Codex に届く一般的な方法は、Codex を MCP サーバーとして起動することでした。2026 年 9 月 5 日の Codex の変更履歴がそれを終わらせています。

The codex mcp-server command and standalone codex-mcp-server binary
have been removed after their deprecation on August 24, 2026. Update
integrations that launch either command before upgrading Codex. Use
the Codex app server for integrations.

Claude Code の MCP 設定に codex mcp-server を追加するコミュニティの構成は、アップグレードすると動かなくなります。公式プラグインは影響を受けません。README によると、Codex app server をラップしているからです。同じ変更履歴の項目は、app server コマンドを実験的なもので、本番ワークロードではサポートされないと説明しています。無人のゲートをそこに掛ける前に知っておくべきことです。

古いスクリプトやチュートリアルに影響する小さな変更が 3 つあります。

• codex exec --full-auto は非推奨の互換フラグで、警告を表示します。ドキュメントは --sandbox workspace-write を明示的に渡すよう案内しています。
• approval_policy = "untrusted" は Codex で廃止されました。ドキュメントによると、設定に残っているとクライアントが起動しなくなることがあります。
• Claude Code では、v2.1.223 から /review は /code-review のエイリアスです。それ以前は GitHub のプルリクエストをレビューする別のコマンドでした。「/review を実行する」と書いたチュートリアルは、別のコマンドの話をしているかもしれません。

逆向きのブリッジは書類の上にしかありません。Claude Code は今も claude mcp serve を文書化していますが、MCP クライアントに公開されるのは Claude Code のツールであって、エージェントではありません。ここで引用した記事のどれも、それを Codex につないではいません。

Claude Code と Codex の分担は、どれから始めるべきか

必要なときに呼ぶレビュー、つまり完成した diff に対する /codex:review から始め、指摘を数十件読むまではそこにとどまってください。これは出典を読んだうえでの見立てで、計測結果ではありません。

7 つのうち、やめるときの負担がいちばん小さい分担です。コマンドは読み取り専用で、頼んだときだけ動き、ワークフローの何もこれに依存しません。プラグインの README によると、ChatGPT のサブスクリプションがあれば足り、Free プランも含まれます。利用分は Codex の上限に計上されます。つまり、最初の試用のために 2 つ目の有料プランを契約する必要はありません。そして、指摘を読むことで、2 つ目のモデルが自分のコードについて 1 つ目のモデルの見落としを見つけるかどうかがわかります。2 つのツールを使うことを正当化する問いはそれだけです。指摘の大半が /code-review にすでに言われたことの繰り返しなら、それが答えで、かかったのは午後ひとつ分です。

ゲートを有効にするのは最後にしてください。そもそも有効にするなら、サイズのしきい値と、タイムアウト時にどうするかの決定を必ず添えてください。書き込みを委任するのは、Codex がどのディレクトリをワークスペースとして扱うかを確認してからです。

2 つ目のツールを見送るべき人もいます。変更が小さく、すでに全行を読んでいる人。そして、良い指摘と、自信満々の誤った指摘をまだ見分けられない人です。2 つ目のモデルは、判断しなければならない山を増やします。代わりに判断してはくれません。

7 つのパターンすべてで、ツールの間を行き来するのは成果物です。diff、計画ファイル、指摘ファイル、AGENTS.md、エクスポートされたセッション。どのパターンも進行中の会話を共有しませんし、ベンダーが作ったブリッジはどれもファイルとスレッドで止まります。成果物が良ければ、どちらのツールがどちら側に座ってもかまいません。承認は成果物と一緒には渡りません。ペンを握っているツールは、自分のサンドボックスの下で書きます。だから席を入れ替えることは、ファイルの側では設定の変更で、もう一方の側では権限の確認になります。