この記事ではAIコーディングに特化して解説します。AIコーディング全般の全体像は Vibe Codingとは？AIコーディングの始め方・ツール比較・実践ワークフロー2026 をご覧ください。

codex-plugin-cc は、OpenAIが公開しているClaude Code用のプラグインだ。Claude Codeの中から /codex:review と打つとCodexがコードレビューを返し、/codex:rescue と打つとCodexが実装タスクを引き取る。競合するAIコーディングエージェント同士を、片方のUIから呼び合わせるという構成になっている。

本記事は公式READMEの和訳ではなく、v1.0.6のソースと同梱テストを実際に動かした結果をもとにしている。特に、READMEには書かれていない「コマンドによって権限が違う」点と、レビューゲートがCodexが居ないときは素通りし、Codexが居て壊れたときは停止を止めるという非対称な挙動を中心に据えた。

レビューゲートON/OFFとCodex未インストールの3条件でStopフックを実行した実際の出力。ONかつ指摘ありのときだけdecision:blockが返る
同梱のfake-codexフィクスチャで3条件を実行した実出力。ChatGPTへのログインなしでも、ゲートの分岐はここまで再現できる
30秒でわかる codex-plugin-cc 何ができるか：Claude Codeの中から、コードレビュー（`/codex:review`・`/codex:adversarial-review`）と実装タスク（`/codex:rescue`）をCodexに委譲できる。会話そのものをCodexのスレッドへ引き継ぐ `/codex:transfer` もある
何を解決するか：「レビューだけ別のモデルに見てほしい」ときに、ターミナルを行き来してコンテキストを貼り直す手間が消える。バックグラウンド実行なのでClaude Code側の作業も止まらない
何を代替するか：Codex CLIを別ウィンドウで開いて `/review` を打つ運用を置き換える。Codexそのものは代替しない——プラグインは手元のcodex CLIを呼ぶ薄い仲介層で、モデルも認証も設定もCodex側のものをそのまま使う
前提：Node.js 18.18以上と、ChatGPTアカウント（無料プランを含む）またはOpenAI APIキーでのCodexログイン

codex-plugin-ccとは——OpenAIが出したClaude Code用プラグイン

codex-plugin-cc はOpenAIのGitHub organizationで公開されているリポジトリで、ライセンスはApache-2.0、最新タグはv1.0.6だ。中身はNode.js製のスクリプト群と、Claude Codeが読み込むプラグイン定義（スラッシュコマンド・サブエージェント・スキル・フック）で構成されている。

注目すべきは、これがOpenAIによるAnthropic製ツールへの公式アドオンである点だ。リポジトリ直下の .claude-plugin/marketplace.json には "owner": {"name": "OpenAI"} と書かれ、Claude Codeのプラグインマーケットプレース形式に正面から乗っている。同梱のサブエージェント定義 agents/codex-rescue.md に至っては、frontmatterで model: sonnet とAnthropicのモデルを指名している。Codexへ橋を架ける処理そのものを、Claudeの安価なモデルに担わせる設計だ。

経路：プラグインは薄い仲介層でしかない

Claude Codeからcodex-companion.mjs、Codex app server、手元のcodex CLIへと処理が渡る4段の経路図
プラグインはCodex app serverへのJSON-RPCクライアントであり、モデル呼び出しは既存のCodexインストールに委ねている

スラッシュコマンドは最終的に同梱の scripts/codex-companion.mjs を叩き、そこから Codex app server へJSON-RPCで話しかける。ソースを読むと thread/start・thread/resume・review/start・turn/start・turn/interrupt・account/read・config/read・thread/list・externalAgentConfig/import といったメソッドが使われている。

ここが重要な点で、プラグインは独自のモデルランタイムを持たない。公式FAQも「別のCodexランタイムは使わない」と明言しており、実際にソース上も以下がすべてCodex側のものになる。

・同じCodexインストール（グローバルの codex バイナリ）
・同じローカル認証状態（codex login の結果）
・同じ設定（~/.codex/config.toml とプロジェクトの .codex/config.toml）
・同じリポジトリチェックアウトとマシン環境

つまり model = "gpt-5.4-mini" や model_reasoning_effort = "high" を設定ファイルに書いておけば、プラグイン経由の実行にもそのまま効く。プロジェクト単位の上書きは、そのプロジェクトがtrusted扱いのときだけ読み込まれる。

インストールと初期設定

Claude Codeの中でマーケットプレースを追加し、プラグインを入れてリロードする。

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins

続けて /codex:setup を実行すると、Codexが入っているか・ログイン済みかを判定してくれる。Codexが無くnpmが使える環境なら、その場でインストールを提案してくれる。手動で入れるなら以下だ。

npm install -g @openai/codex

Codexは入っているがログインしていない場合は、Claude Codeから !codex login を実行する。codex login はChatGPTアカウントとAPIキーの両方に対応している。

導入時につまずきやすい点 Node.jsは18.18以上が必須：`package.json` の `engines` が `>=18.18.0` を要求している。`node --version` で確認しておく
ChatGPT無料プランでも動く：APIキーは必須ではない。ただし利用分はCodexの使用量上限に計上される
導入後の確認は2か所：スラッシュコマンドが一覧に出ているかと、`/agents` に `codex:codex-rescue` サブエージェントが現れているか。両方見えていれば読み込みは成功している
最初の1回はバックグラウンドで試す：`/codex:review --background` → `/codex:status` → `/codex:result` の3つを順に打つと、ジョブ管理の流れが一度で掴める

8つのスラッシュコマンドと、コマンドごとに違う権限

用意されているコマンドは8つ。読み取り専用のものと、ファイルを書き換えるものが混在している点に注意したい。

コマンド 役割 サンドボックス 観点の指定
/codex:review 通常のコードレビュー read-only（固定） 不可
/codex:adversarial-review 設計・判断を問い直すレビュー read-only（固定） 可（焦点テキスト）
/codex:rescue 調査・実装タスクの委譲 workspace-write（既定） タスク文で指定
/codex:transfer 現在の会話をCodexスレッドへ引き継ぐ — —
/codex:status 実行中・直近ジョブの確認 — —
/codex:result 完了ジョブの最終出力を表示 — —
/codex:cancel バックグラウンドジョブの中止 — —
/codex:setup 導入状態の確認とゲートの切替 — —

/codex:review と /codex:adversarial-review は --base <ref> でブランチ比較レビューにできる。どちらも --wait と --background を取る。違いはsteerableかどうかで、焦点テキスト（「このキャッシュとリトライの設計が妥当か問い直して」など）を後ろに付けられるのは adversarial 側だけだ。通常の /codex:review は焦点テキストを受け取らず、渡すとエラーになる。

レビュー対象の指定は --scope で行うが、受け付ける値は auto・working-tree・branch と --base <ref> に限られる。--scope staged（ステージ済みだけをレビュー）は非対応で、指定するとエラーになり、使える値を並べたメッセージが返る。焦点テキストを /codex:review に渡した場合も同様にエラーになるが、このときのメッセージは親切で、同じ文言を /codex:adversarial-review に付けた形のコマンド例を提示してくれる。

もうひとつ、差分が大きいときの挙動が実装として面白い。変更が一定量を超えると、プラグインは差分の中身をプロンプトへ詰め込まない。代わりに軽量なサマリだけを渡し、「読み取り専用のgitコマンドで自分で確認せよ」とCodexに指示する。同梱テストは、変更したファイルに埋め込んだ目印の文字列がプロンプトへ現れないことまで検証している。巨大なPRをレビューさせてもプロンプトが膨張しない設計で、Codex側が能動的にリポジトリを読む前提に立っている。

rescueだけは既定で書き込み可

rescueはworkspace-writeかつapprovalPolicy neverで既定、reviewとadversarial-reviewはread-only固定という権限差の比較図
READMEはrescueを「fixを試せる」とだけ書くが、既定が書き込み可であることはソースを読まないと分からない

ここが実務上いちばん効く差だ。レビュー系2つは、ソース上でサンドボックスが read-only に固定されている。一方 /codex:rescue は、同梱のサブエージェント定義とスキル定義の両方に「読み取り専用を明示的に求められない限り --write を付けろ」という指示が書かれている。--write が付くと codex-companion.mjs の中でサンドボックスが workspace-write に切り替わる。

さらに、スレッド開始時の承認ポリシーは既定で never だ。つまり /codex:rescue は、都度の確認なしにCodexが作業ツリーを書き換えうる。バージョン管理がクリーンな状態から始める、あるいは読み取り専用でよいときは「調査だけしてほしい」と明示するのが安全側の運用になる。

なお --model に spark と書くと gpt-5.3-codex-spark に変換される。この対応付けはドキュメントだけの約束ではなく、codex-companion.mjs に MODEL_ALIASES として実装されており、同梱テストも変換後のモデル名を検証している。--effort は none・minimal・low・medium・high・xhigh を受け付ける。どちらも未指定ならCodex側の既定に従う。

会話ごとCodexへ渡す /codex:transfer

/codex:transfer は、いま進めているClaude Codeのセッションから永続的なCodexスレッドを作り、codex resume <session-id> の形で続きをCodex側で開けるようにする。SessionStartフックが現在のトランスクリプトのパスを自動で渡すので、通常は引数なしで動く。

安全側の制約もソースで確認できる。読み込み元は ~/.claude/projects 配下に限定され、拡張子は .jsonl でなければならない。しかも realpath で解決してから相対パスを検査しているので、シンボリックリンクで外へ抜ける経路も塞がれている。

バックグラウンドジョブは「そのセッションのもの」しか見えない

--background を付けたジョブは、/codex:status で進捗を、/codex:result で最終出力を、/codex:cancel で中止を扱う。ここで見落としやすいのが、これらがClaude Codeのセッション単位に閉じているという点だ。

プラグインはSessionStartフックで現在のClaude セッションIDを環境変数 CODEX_COMPANION_SESSION_ID として書き出し、起動した各ジョブにそのIDを紐づけている。その結果、ジョブIDを省略したときの挙動は次のようになる。

・/codex:status：現在のセッションのジョブしか一覧に出ない
・/codex:result：現在のセッションで最後に完了したジョブを優先する
・/codex:cancel：他セッションで実行中のジョブは無視する
・/codex:rescue --resume：他セッションのタスクは再開対象にならない

一方で、ジョブIDを明示すれば他セッションのジョブも中止できる。「別ウィンドウで走らせたまま忘れたジョブ」を止めたいときは、/codex:status <task-id> で特定してから /codex:cancel <task-id> を打てばよい。逆に言えば、ID無しの /codex:cancel で全部止まると思い込むと取り逃がす。

セッションを閉じるとSessionEndフックがそのセッションのジョブを片付ける。Claude Codeを複数ウィンドウで並行運用している場合、この分離を知らないと「statusに出ないから終わったのだろう」と誤解しやすい。これらの挙動は同梱テストでも個別に検証されており、筆者の手元でもセッション関連13件がすべてパスした。

レビューゲート——Codexに「停止」を握らせる仕組み

このプラグインで最も踏み込んでいるのが、任意で有効化するレビューゲートだ。

/codex:setup --enable-review-gate
/codex:setup --disable-review-gate

有効にすると、Claude Codeの Stopフック（応答を終えようとする瞬間に走るフック）でCodexレビューが実行される。そこで問題が見つかると、Claude Codeはそのターンを終われない。競合ベンダーのモデルに、自分のエージェントの停止権を渡す構図になっている。

sequenceDiagram participant U as "開発者" participant CC as "Claude Code" participant H as "Stop フック" participant CX as "Codex" U->>CC: "実装を依頼" CC->>CC: "コードを編集して応答を終えようとする" CC->>H: "Stop イベント" H->>CX: "直前のターンだけをレビューさせる" CX-->>H: "先頭行 ALLOW: または BLOCK:" alt "先頭行が BLOCK:" H-->>CC: "decision block と理由を返す" CC->>CC: "指摘に対応してから再度終了を試みる" else "先頭行が ALLOW:" H-->>CC: "何も出さない" CC-->>U: "応答を終える" end

判定は「先頭行がALLOW:かBLOCK:か」だけ

同梱のプロンプトテンプレートは、Codexに対して出力契約を明示している。「最初の1行は必ず ALLOW: <理由> か BLOCK: <理由> のどちらかにせよ。その前には何も置くな」という指示だ。加えて、直前のターンで実際にコード変更があった場合だけレビューし、ステータス表示やセットアップ確認のような編集を伴わない応答なら即座にALLOWを返せ、という条件も書かれている。

フック側の実装は、この先頭行だけを見る。ALLOW: で始まれば通し、BLOCK: で始まればブロック理由に変換する。そのどちらでもない応答は、すべてブロック側に倒れる。

実際に3条件で動かすと分岐が見える

レビューゲートON時にClaude Codeが停止できる4条件。Codex未インストールのみ素通りし、BLOCK応答と応答破損はブロックされる
①だけがfail-open。②以降はCodexが応答を返せたかどうかで結果が変わる

リポジトリには偽のCodexバイナリを差し込む tests/fake-codex-fixture.mjs が同梱されており、ChatGPTへログインしなくてもゲートの分岐を再現できる。実際に手元でテスト一式を走らせたところ、91件すべてがパスした（node --test tests/*.test.mjs、所要142秒、devDependenciesはTypeScriptと型定義のみ）。

検証環境 macOS 14（Darwin 23.5.0・Apple Silicon）／ Node.js v22.13.1 ／ openai/codex-plugin-cc v1.0.6（コミット `db52e28`、2026-07-07が最終）／ 検証日 2026-08-06。ChatGPTアカウントへのログインは行わず、同梱の fake-codex フィクスチャのみを使用した。

その上で、フックを直接叩いて3条件を比較したのが冒頭の実出力だ。整理すると次のようになる。

・ゲートON＋Codexが指摘あり：標準出力に {"decision":"block", ...} が出て、停止できない
・ゲートOFF：Codexが同じ指摘を返しても標準出力は空。そのまま停止できる
・ゲートON＋Codex未インストール（PATHを空にして実行）：標準出力は空で停止は許可され、stderrに「Codex is not set up for the review gate. Run /codex:setup.」とだけ出る

3つ目が意味するのは、ゲートを有効にしていてもCodexが居なければ黙って素通りするということだ。「有効にしたつもりで実は効いていない」状態が、エラーではなく警告1行で通過してしまう。

壊れたときほど止まる、という非対称

逆方向の挙動も確認できた。検証中にたまたま筆者の環境でディスクが埋まり、レビュージョブのファイル書き込みが ENOSPC で落ちたことがある。このときフックは素通りせず、「The stop-time Codex review task failed: ENOSPC …」という理由で停止をブロックした。

ソースを読むと、ブロック側に倒れる条件は次のとおりだ。

・Codexが BLOCK: を返した
・最終出力が空だった
・先頭行が ALLOW: でも BLOCK: でもなかった
・--json の出力がJSONとして壊れていた
・プロセスが非ゼロ終了した
・15分でタイムアウトした

つまりゲートは「Codexが居ないときは素通り（fail-open）、Codexが居て応答が壊れたときは停止を止める（fail-closed）」という非対称な設計になっている。設定ミスは静かに通り、実行時の事故は止める、という割り切りだ。

なおフック側のタイムアウトは hooks.json で900秒、スクリプト内部のタイムアウトも15分と、ほぼ同値に設定されている。

公式もループを警告している READMEはレビューゲートについて「Claude/Codexの長時間ループを生み、使用量上限を急速に消費しうる。セッションを実際に監視するつもりがあるときだけ有効にせよ」と明記している。Claudeが直してはCodexが止め、また直しては止める、という往復が起きうるためだ。常時ONにする機能ではなく、リリース前の一時的なゲートとして使うのが現実的だろう。

同梱スキルが明かす「Codexへの頼み方」

プラグインにはスラッシュコマンドのほかに、Claude Codeが内部的に読み込むスキルが3つ入っている。いずれも user-invocable: false で、ユーザーが直接呼ぶものではない。中でも skills/gpt-5-4-prompting/SKILL.md は、OpenAI自身が書いたCodex向けプロンプト設計の指針であり、プラグインを使わない人にも参考になる。

冒頭の一文が方針を端的に示している。Codexには協働者ではなくオペレーターとして指示せよ、というものだ。プロンプトはXMLタグで構造化し、簡潔に保つ。示されている既定のレシピは次の構成になっている。

・<task>：具体的な作業と、関連するリポジトリ／失敗の文脈
・<structured_output_contract> または <compact_output_contract>：出力の形・順序・簡潔さの要求
・<default_follow_through_policy>：確認質問を返す代わりに既定で何をすべきか
・<verification_loop> または <completeness_contract>：デバッグ・実装・risky fixでは必須
・<grounding_rules> または <citation_rules>：レビューや調査で、根拠のない主張へ流れるのを防ぐ

タスク種別ごとに足すブロックも指定されている。コーディングやデバッグなら完全性の契約と検証ループ、レビューなら根拠ルールと構造化出力、調査ならリサーチモードと引用ルール、といった具合だ。

特に実務的なのは「推論強度を上げたり長い自然言語の説明を足したりするより、良いプロンプト契約を選べ」という一節だろう。effortを上げる前に出力契約を締める、という順序を明示している。実際、前述のレビューゲートのプロンプトもこの型に忠実で、<task>・<compact_output_contract>・<default_follow_through_policy>・<grounding_rules>・<dig_deeper_nudge> の5ブロックで書かれている。

レビュー結果は自由記述でなくJSONスキーマで返させる

/codex:adversarial-review は、schemas/review-output.schema.json を出力スキーマとしてCodexに渡す。additionalProperties: false の厳格なスキーマで、要求される形は次のとおりだ。

・verdict：approve か needs-attention の2値
・summary：1文字以上の要約
・findings[]：severity（critical / high / medium / low）・title・body・file・line_start・line_end・confidence（0〜1の数値）・recommendation をすべて必須
・next_steps[]：次にやることの配列

指摘ごとにファイルと行範囲、そして確信度を数値で出させる設計になっている点が効いている。レビュー結果を人が読むだけでなく、そのまま機械処理へ回せる形だ。

サブエージェントは、あえて「何もしない」

もうひとつ設計として面白いのが agents/codex-rescue.md だ。冒頭で自らを「Codexコンパニオンのタスクランタイムを包む薄い転送ラッパー」と定義し、以下を明示的に禁じている。

・リポジトリを読む、grepする、ファイルを調べる
・自分で問題を解く、解決策を下書きする
・進捗を監視する、状態をポーリングする、結果を取りに行く
・review・status・result・cancel を呼ぶ（このサブエージェントは task への転送専用）

許されているのは Bash を1回だけ呼んで codex-companion.mjs task を実行し、その標準出力を一切の前置きや後書きなしでそのまま返すことだけだ。プロンプトを整える目的でのみ、前述のスキルの利用が認められている。

意図は明白だろう。Claude側が先に調査して答えを出してしまえば、Codexへ渡す意味が消える。委譲を成立させるために、橋渡し役をあえて無能力に保っているわけだ。同じ思想は「単純な依頼は主スレッドで済ませ、このサブエージェントを掴むな」という選択指針にも表れている。

codex-plugin-ccを使う前に押さえておきたい現在地

スター31391、オープンPR196件、オープンIssue216件に対しマージ済みコミットは29本というリポジトリの実測値
2026-08-06時点のGitHub API実測。注目度とマージ実績の差が大きい

リポジトリの数字を実測すると、話題性と開発実態のギャップが見える。スターは31,391で、当サイトが最初にこのプラグインを取り上げた3月末（2,675）から約11.7倍に増えた。一方でマージ済みのコミットは29本、コミット履歴に現れる人は13人だ。

さらに、オープンなIssueが216件、オープンなPull Requestが196件ある（GitHubがトップページに出す412件は、この両方の合計）。PRが196件開いたままという状態は、コミュニティからの貢献がほとんど取り込まれていないことを意味する。最後のpushは2026-07-08で、そこから約1か月動きがない。

細かい点だが、READMEの冒頭は ./docs/plugin-demo.webm というデモ動画を参照している。しかしリポジトリに docs/ ディレクトリは存在せず、実際にアクセスすると404が返る。GitHub上のREADMEでは再生できない状態が続いている。

直近の変更はgit呼び出しの安全化

コミット数こそ少ないが、履歴を追うと修正の力点は見える。初期はWindows対応に集中しており、spawnSync が .cmd シムを解決できずENOENTになる問題（npmでグローバルインストールされた codex がまさにこれに当たる）、app-server起動時のENOENT、Git Bash利用時の SHELL 尊重、と立て続けに直されている。

そして最新のv1.0.6（2026-07-07）は、gitコマンドからシェル展開を外す変更だ。差分にはそのまま「リポジトリ由来の引数は決してシェルを通してはならない」という趣旨のコメントが添えられ、git呼び出しがすべて shell: false に固定されている。ブランチ名のようなリポジトリ側から来る文字列がシェルに解釈される余地を塞ぐ、injection対策の性格が強い修正といえる。最後の更新がこの内容だという点は、導入判断の材料としてはむしろ安心できる部分だろう。

使用量と課金の扱い プラグインは別課金を持たない。実行分は**ChatGPT側のCodex利用上限に計上される**。Claude Code側のトークンとは別枠なので、「Claudeの上限を節約するためにCodexへ流す」という使い方は成立する一方、Codex側の上限は当然消費する。バックグラウンドで長時間タスクを投げるときや、レビューゲートを有効にするときは、この二重の消費を意識しておきたい。

類似ツールとの比較——どれを選ぶか

Codexを取り巻く周辺ツールはいくつかあるが、解いている問題が違う。

ツール 主体 何をするか codex-plugin-ccとの違い
codex-plugin-cc OpenAI公式 Claude CodeからCodexへ委譲 Claude Codeが起点。レビューゲートで停止を制御できる
Codex CLI を直接使う OpenAI公式 Codexを単体で使う 起点がCodex。Claude Code側の文脈は手で運ぶ必要がある
oh-my-codex（OMX） コミュニティ Codex CLIにHUD・hooks・チーム実行を足す Codexの使い勝手を拡張する層。Claude Codeとは無関係
cmux コミュニティ 複数エージェントの通知を1つのターミナルへ集約 エージェントを並べて眺めるための層。委譲はしない

Codex CLI単体の使い方を厚く知りたい場合は oh-my-codex（OMX）とは｜Codex CLIにHUD・チーム実行・hooksを足す使い方 が、Codex向けのスキル資産の集め方は codex cli skillsとは｜awesome-codex-skillsの中身・導入手順・移転先リポジトリ が参考になる。複数のエージェントを同時に走らせて通知だけ束ねたいなら cmuxとは｜Codex・Claude Codeの通知をフック注入で束ねるGhostty製ターミナル が近い発想だ。

プラグインが依存しているClaude Code側のフックやプラグイン機構そのものについては Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き で全体像を確認できる。

導入して割に合う条件

以上を踏まえると、codex-plugin-cc が向いているのは次のようなケースだ。

・すでにCodexとClaude Codeの両方を契約している：どちらか片方しか無いなら、わざわざ橋を架ける意味は薄い
・レビューだけ別モデルの目を入れたい：/codex:review --background を挟むだけなら副作用がなく、既存のワークフローを壊さない
・設計判断を問い直してほしい：/codex:adversarial-review に焦点テキストを渡す使い方は、通常のレビューと明確に役割が違う
・セッションを監視できる時間帯に限ってゲートを試す：常時ONは公式が警告しているとおり非推奨

逆に、/codex:rescue を既定のまま多用するのは慎重になったほうがいい。承認なしで作業ツリーが書き換わるため、コミットしていない変更がある状態では差分が混ざる。委譲する前にコミットするか、少なくとも git stash で退避しておけば、Codexが触った範囲を後から差分で切り分けられる。「どこまでが自分の変更か」を追える状態を保つことが、複数エージェントを併用するときの最低限の作法になる。

参照ソース