OpenAIが公式でClaude Codeプラグインを公開 ― codex-plugin-ccが意味すること¶

対象 / ポイント

対象: Claude CodeまたはOpenAI Codexを業務で使用しているエンジニア。両ツールの併用を検討中の開発者。

ポイント:

OpenAI公式プラグイン codex-plugin-cc により、Claude Code内からCodexのコードレビュー・タスク委譲が可能になった
競合ツールへの公式プラグイン提供はAIコーディングツール市場で前例がなく、エコシステム戦略の転換点となる
実用上はCodexの使用量制限・バックグラウンド実行の待ち時間・認証の二重管理に注意が必要

何が起きたのか¶

2026年3月30日、OpenAIがGitHub上にリポジトリ openai/codex-plugin-cc を公開した¹。Claude Codeのプラグインシステムを通じてインストールすると、Claude Codeのセッション内から直接OpenAI Codexを呼び出せるようになる。

これはOpenAIが3月下旬に発表したCodexプラグインシステム²の一環だ。注目すべきは提供先がAnthropicのClaude Codeであるという点にある。自社のAIコーディングエージェントを、競合製品のエコシステムに乗せてきた形だ。

では、具体的に何ができるのか。

codex-plugin-ccでできること¶

プラグインは大きく2種類の機能を提供する。レビュー系と委譲系だ。

レビュー系コマンド¶

/codex:review は未コミットの変更やブランチ差分に対してCodexによるコードレビューを実行する。--base main でブランチ比較、--background でバックグラウンド実行が可能だ。読み取り専用で、コードの変更は行わない。

/codex:adversarial-review はより攻撃的なレビューを行う。設計判断のトレードオフ、隠れた前提条件、障害モードを問い直す「デビルズアドボケート型」のレビューだ。認証・データ損失・レースコンディションなど、特定のリスク領域にフォーカスを当てることもできる。

委譲系コマンド¶

/codex:rescue はCodexにタスクそのものを渡す。バグ調査、修正の試行、前回のCodexタスクの継続が可能だ。--model gpt-5.4-mini や --model spark でモデルを切り替えられるため、タスクの重さに応じたコスト制御ができる。

タスク管理は /codex:status（進捗確認）、/codex:result（結果取得）、/codex:cancel（キャンセル）で行う。

動作イメージ¶

Claude Codeでコードを書き、区切りのタイミングで以下を実行する流れになる。

# Claude Codeで実装後、Codexにレビューを委譲
/codex:review --base main --background

# 他の作業を継続しつつ進捗確認
/codex:status

# レビュー結果を取得してClaude Codeで修正
/codex:result

Claude Codeが「手を動かす役」、Codexが「レビュアー役」として分業する構図だ。逆に /codex:rescue を使えば、Codexに実装を渡してClaude Code側で監督するパターンもとれる。

導入手順¶

前提条件として、Node.js 18.18以降と、ChatGPTサブスクリプション（Free含む）またはOpenAI APIキーが必要になる¹。

# マーケットプレイスの追加
/plugin marketplace add openai/codex-plugin-cc

# プラグインのインストール
/plugin install codex@openai-codex

# セットアップ確認（Codex CLIの自動インストールも可能）
/codex:setup

Codex CLIが未インストールの場合、/codex:setup が検出してインストールを提案する。認証は !codex login でChatGPTアカウントまたはAPIキーを使う。

Review Gateという実験的機能¶

基本的な導入はここまでで完了する。ただしcodex-plugin-ccにはもう一つ、使い方を誤るとコストが跳ねる実験的機能がある。

/codex:setup --enable-review-gate を実行すると、Claude Codeの出力に対してCodexが自動レビューをかける「ストップフック」が有効になる。Codexがレビューで問題を検出した場合、Claude Codeの出力がブロックされ、先に修正が求められる。

ただしREADMEには明確な警告がある。Claude CodeとCodexの間でループが発生し、使用量制限を急速に消費する可能性がある¹。有人監視下でのみ有効化すべき機能だ。

既存のDIYアプローチとの違い¶

Claude CodeからCodexを呼び出すアプローチ自体は新しくない。codex exec を直接叩くSKILL.md方式や、Stop Hookで自動発火させるclaude-review-loopプラグインなど、サードパーティの実装が2026年2月時点で複数存在する³。

両者のアーキテクチャ上の違いを整理する。

項目	codex-plugin-cc（公式）	DIY方式（codex exec直接）
実行経路	Codex App Server経由	bash環境から `codex exec` 直接
セッション管理	プラグインが抽象化	自前実装
ループ制御	カスタマイズ不可	停止条件・回数を自由に設定
導入コスト	スラッシュコマンド1つ	SKILL.md / Hook設定が必要

選択の指針はシンプルだ。「まず試す」ならcodex-plugin-cc、「レビューループの挙動を細かく制御する」ならDIY方式。両者は排他的ではなく、日常のレビューに公式プラグイン、重要なリリース前にDIY方式の最終監査という併用も成立する。

DIYアプローチの詳細

codex exec を直接叩く3段階の実装ガイドは「Codex Reviewを自動化する：Claude Code × Codex レビューループ実装ガイド」を参照。

なぜOpenAIは競合に「乗り入れ」たのか¶

機能面は把握できた。次の疑問は、なぜOpenAIがわざわざ競合製品のエコシステムにプラグインを出したのか、という点だ。

まず市場シェアの現実だ。Claude Codeは2026年初頭時点で年間売上ベース推計約25億ドルの規模に達しており、GitHubの全パブリックコミットの約4%（日次約13.5万件）を占める⁴。開発者のワークフローにおけるデファクトの地位を築きつつある。

一方、Codexは週間アクティブユーザー200万人を抱えるが、その強みはクラウドサンドボックスでの自律実行やエンタープライズ向けガバナンスにある⁴。ローカル実行を前提としたClaude Codeとは特性が異なる。

このプラグインは「Claude Codeのユーザーが離脱するのを待つ」のではなく、「Claude Codeの中にCodexの接点を作る」という戦略だ。開発者がClaude Codeを主力ツールとして使い続けたとしても、レビューやタスク委譲の場面でCodexの使用量が発生する。

収益構造がこの戦略を後押ししている。Codexの課金は使用量ベースだ⁵。ユーザーを丸ごと奪わなくても、プラグイン経由のレビュー1回ごとにOpenAIの売上が立つ。ユーザー獲得コストゼロで課金ポイントだけが増える構造であり、プラグインの「乗り入れ」はOpenAIにとってリスクが極めて低い。

運用上の注意点¶

実際に導入する場合、以下の4点に留意する必要がある。

認証の二重管理 — Claude CodeにはAnthropicアカウント、CodexにはChatGPTアカウントまたはOpenAI APIキーが必要。チームで導入する場合、アカウント管理の負荷が増える
使用量制限の分散 — Codexの使用はChatGPTサブスクリプションの使用量制限にカウントされる⁵。Claude Code側とは別管理のため、両方のリミットを意識する運用が求められる
バックグラウンド実行の遅延 — READMEが繰り返し --background を推奨している通り、特にマルチファイルのレビューは時間がかかる。同期的に待つとClaude Codeのセッションがブロックされる
モデル選択のコスト影響 — /codex:rescue ではデフォルトでCodexがモデルを自動選択する。意図せずgpt-5.4（ $2.50/$ 15 per MTok）が使われる可能性がある⁸。--model gpt-5.4-mini や --model spark の明示を推奨

市場の文脈 ― プラグインの相互乗り入れ時代¶

前節ではOpenAI単体の動機を見た。ここでは市場全体の流れの中にcodex-plugin-ccを位置づける。

サードパーティ開発者はすでにClaude Code向けのCodexプラグインやGeminiプラグインを公開しており、「どのエージェントCLIからでも別のエージェントを呼び出す」パターンが一般化しつつある⁶。

OpenAIとAnthropicの二社がプラグインシステムを整備し、Googleもエージェント拡張の仕組みを構築しつつある⁷。いずれもMCPサーバー・スキル・サブエージェントをバンドルする方向に進んでいる。インターフェースの互換性はまだないが、プラグインという抽象レイヤーがエージェント間の相互運用を事実上可能にしている。

開発者の視点では「メインのエージェントCLIを1つ選び、足りない能力はプラグインで補う」というマルチエージェント運用が現実的な選択肢になった。

まとめ¶

codex-plugin-ccは、技術的にはCodex CLIのラッパーに過ぎない。しかし「OpenAIが競合製品のエコシステムに公式プラグインを出した」という事実は、AIコーディングツール市場がプラットフォームロックインではなくエコシステムの浸透率で争うフェーズに入ったことを示している。

実務的には、Claude Codeをメインとしつつ「セカンドオピニオンとしてのコードレビュー」をCodexに委譲するワークフローが最も自然な使い方になる。導入にあたっては認証の二重管理と使用量制限のモニタリングを整備した上で、まず /codex:review --background から試すのが堅実だ。

次に注視すべきは、AnthropicやGoogle側が同様の「逆方向プラグイン」を出すかどうかだ。相互乗り入れが双方向になったとき、AIコーディングツールの競争軸は「モデル性能」から「エコシステムの統合体験」へ本格的にシフトする。エージェントCLIの選定基準に「プラグインエコシステムの充実度」を加えるべきタイミングが来ている。