Codexでプラグインが使えるようになったというニュースを聞いたが、今まで使えなかったのか、いまごろ、何を発表したのかと疑問に思ったので調べ始めたところ、YouTube動画で、Claude CodeからCodexを呼び出してプラグインを使う事例が紹介されていた。本記事では、わざわざ、Claude Codeから使うのはなぜか、どのような場合にどのような使い方をするのかを調べた。
(注)本記事の内容は正確性を保証するものではない。
(2026年4月3日 追記)YouTube動画を追加しました。 https://youtu.be/SDYUMRnb9fk

Claude CodeからCodexを呼び出してプラグインを使う事例
Codexに新しいプラグインが導入されたというニュースを最近聞きましたが、それを紹介するYoutube動画や記事では、Claude CodeからCodexを呼び出して、それらのプラグインを使うというような事例が紹介されていました。Codexでそれらのプラグインを使い場合と、Claude CodeからCodex経由でプラグインを使う場合を比較して、Claude Codeから使う利点としてはどのようなものがあるのか、発生する費用も含めて調べてください
ChatGPT 5.4 Thinkingの回答
結論だけ先に言うと、ClaudeからMCP経由でCodexを使う利点は、主に「安さ」ではなく「ワークフローの一体化」と「別モデルによる二重チェック」です。
費用面はむしろ、Codex単体より増えやすいです。なぜなら、公式のClaude Code向けCodexプラグインは、Claude Codeの中からローカルのCodex CLI / Codex app serverを呼び出す仕組みで、Codex側の利用枠も使う一方、Claude Code側の利用枠やAPI課金も別に存在するからです。 (OpenAI Developer Community)
まず、最近の「Codexの新しいプラグイン」は、Codex内にプラグインディレクトリが追加され、プラグインを発見・インストール・利用できるようになったという話です。OpenAI公式ドキュメントでは、プラグインはskills、app integrations、MCP serversを束ねた再利用可能ワークフローで、例として Gmail、Google Drive、Slack が挙がっています。ChatGPTのリリースノートでも、2026年3月下旬にCodexへ curated plugins directory が追加されたと案内されています。 (OpenAI 開発者)
一方、あなたが見た「ClaudeからCodexをMCPでつなぐ」事例について、私が確認できたOpenAI公式の実装は Claude Code 向けです。OpenAI Developer Community の告知では “Introducing Codex Plugin for Claude Code” として公開されており、用途は 通常レビュー、より懐疑的な adversarial review、Codexへの作業委譲 の3つが中心です。つまり、CodexのプラグインをClaudeの中に丸ごと移植するというより、Claude Codeを主画面にしたまま、Codexをサブエージェントとして呼ぶ発想に近いです。 (OpenAI Developer Community)
Codex単体で使う場合は、当然ながら最短経路です。Codexのプラグインディレクトリをそのまま使えますし、OpenAI側の認証・設定・管理だけで済みます。Business/Enterpriseでは、プラグインの有効化やアクション許可もワークスペース側で管理できます。さらに、Codexの公式価格ページでは、API key運用だとクラウド機能(GitHub code review、Slackなど)は使えないと明記されているので、Gmail/Drive/Slack系の“Codexプラグインらしい使い方”をしたいなら、Codexを直接使うほうが自然です。 (OpenAI Help Center)
Claudeから使う利点は、公式情報ベースだと次の5点にまとまります。
1つ目は、Claude Codeの作業フローを崩さずにCodexを呼べることです。OpenAI公式プラグインは、同じローカルのCodex CLI / app server を使い、同じ認証・設定・環境・MCP設定をそのまま再利用します。つまり、環境を二重に組み直さなくてよい、という利点があります。 (OpenAI Developer Community)
2つ目は、別エージェントによるセカンドオピニオンです。公式の説明でも、通常レビューに加えて adversarial review や second pass が強調されています。Claudeで実装や設計を進め、Codexに“本当にその設計でよかったか”を疑ってもらう運用は、Claude側から使うほうがやりやすいです。これは「Codexの機能が増える」というより、Claudeを司令塔にしてCodexを検証役に回せるのが利点です。 (OpenAI Developer Community)
3つ目は、長時間処理の委譲です。公式READMEでは /codex:rescue、/codex:status、/codex:result、/codex:cancel が用意され、バックグラウンド処理や結果確認ができます。Claudeで会話しながら、重い調査や別視点レビューだけをCodexへ投げる、という分業がしやすいです。 (GitHub)
4つ目は、レビューゲートです。/codex:setup --enable-review-gate を有効にすると、Claudeの応答後にCodexレビューを走らせ、問題が見つかればClaude側の停止をブロックできます。これは「Claudeの出力を、その場でCodexに監査させる」運用で、Claudeを主役にしたい人にはかなり分かりやすい利点です。もっとも、READMEでも長いClaude/Codexループになり、使用量を早く消耗しうると警告されています。 (GitHub)
5つ目は、途中からCodex本体へ引き継げることです。プラグイン経由で投げた作業は、後で codex resume でCodex側に持ち替えられます。つまり、最初はClaude中心、途中からCodex中心、という切り替えがしやすいです。 (GitHub)
費用の話に移ると、Codex単体のほうが基本的にはシンプルで安くなりやすいです。CodexはChatGPT Plus、Pro、Business、Enterprise/Edu に含まれ、期間限定でFree/Goにも含まれると案内されています。Plusは 月20ドル、Proは 月200ドルです。上限に達した後は追加クレジットで継続でき、Codexの平均消費量はたとえば GPT-5.4のローカルタスク約7 credits、GPT-5.3-Codexのローカルタスク約5 credits、クラウドタスクやコードレビューは約25〜34 credits とされています。 (OpenAI Help Center)
また、Codex公式ページでは、MCPを増やすほどコンテキストが増え、使用枠を消費しやすくなると案内されています。これはCodex単体でもClaude経由でも同じで、たくさんのMCPや重い指示を抱えさせるほどCodex側のコストは上がりやすいです。 (OpenAI 開発者)
Claude経由の費用は、少なくとも“請求面が二重化しやすい”と考えるのが安全です。Claude Proは 月20ドルで、Claude Codeを含みます。Claude Codeの利用はClaude本体と使用枠を共有し、さらにAPI creditsを使う設定にすると標準API料金で別課金されます。AnthropicのAPI料金は、たとえば Claude Sonnet 4.6 が入力 $3/MTok・出力 $15/MTok、Claude Opus 4.6 が入力 $5/MTok・出力 $25/MTok です。さらにAnthropicのツール利用では、client-side tools は通常のClaude APIリクエストと同じ課金で、server-side tools には追加課金がありえます。 (Anthropic)
そのうえで、Claude Code向けCodexプラグインは、ChatGPT subscription(Free含む)または OpenAI API key が必要で、Codex usage limits に加算されるとREADMEに明記されています。したがって、Claudeで指示 → Codexへ委譲という1回の流れでも、実務上は Claude側の使用量 と Codex側の使用量 の両方を気にする必要があります。これは、Codexだけを直接使う場合には発生しにくい負担です。 (GitHub)
なので、整理するとこうです。
Codexを直接使うほうが向く人は、CodexのGmail/Drive/Slackなどのプラグインを主役に使いたい人、構成を単純にしたい人、費用をなるべく増やしたくない人です。 (OpenAI 開発者)
Claudeから使うほうが向く人は、Claude Codeを主戦場にしていて、実装・設計はClaudeで進めつつ、Codexを批判的レビュー役、バックグラウンド調査役、別モデルの検証役として差し込みたい人です。この場合の利点は明確ですが、費用面の得はほぼなく、むしろ運用価値で選ぶ構成です。 (OpenAI Developer Community)
実務向けに一言でまとめるなら、「Codexのプラグインを安く使いたいならCodex直、Claude中心の開発にCodexの査読・委譲を足したいならClaude→Codex」です。公式情報を見る限り、Claudeから使う最大の利点はクロスレビューと作業導線の一体化であって、コスト削減ではありません。 (OpenAI 開発者)
必要なら次に、「Gmail連携」に絞って、Codex直利用と Claude→Codex の差を表で整理します。
(補足)公式README:OpenAI 公式の codex-plugin-cc README (GitHub)
プラグインディレクトリ追加前は、第三者またはユーザー自身がスキルを作成し、それをSKILL.mdに反映させる作業から行う必要があったが、既成のスキルなどを、選択するだけで導入できるようになったということですか
ChatGPT 5.4 Thinkingの回答
はい、大筋ではその理解で合っています。
ただし、正確には 「以前は自作しかできなかった」ではなく、以前は“手動で入れる必要があった”、今は “公式の curated plugins directory から選んで入れやすくなった” です。Codex のリリースノートでは、2026年3月26日に curated plugins directory が追加され、そこで packaged workflows を発見・インストール・利用できるようになったと説明されています。 (OpenAI Help Center)
補足すると、従来から 既成のもの はありました。
たとえば skills は、SKILL.md を必須マニフェストに持つ再利用可能な束で、OpenAI 公式ドキュメントでも OpenAI skills repository から入れる ことが案内されています。つまり、プラグインディレクトリ前でも、第三者やOpenAIが用意した skill を手動導入することは可能でしたし、もちろん 自分で skill を作ることもできました。 (OpenAI Developers)
その当時の導入は、たとえば次のような形でした。
- skill を
SKILL.md付きフォルダとして.agents/skillsなどに置く。 - あるいは plugin を自分で作り、
marketplace.jsonにパスを書いて Codex に読ませる。
OpenAI の docs では、Codex は repo / personal の marketplace JSON を読めるとされ、plugin は.codex-plugin/plugin.jsonとskills/<skill-name>/SKILL.mdなどで手動作成・手動登録する流れになっています。 (OpenAI Developers)
なので、整理するとこうです。
- 以前
自作の skill / plugin を作って入れることもできたし、既成の skill を手動で配置・登録して使うこともできた。 (OpenAI Developers) - 今
それに加えて、公式ディレクトリから選んでインストールする導線ができた。plugin は skill だけでなく、必要に応じて app integrations や MCP 設定もまとめて配布できる。 (OpenAI Help Center)
つまり、あなたの文を少しだけ直すなら、こうなります。
「プラグインディレクトリ追加前は、ユーザー自身や第三者が作成した skill / plugin を手動で配置・登録して導入する必要があった。今は、既成の packaged workflow をディレクトリから選んで導入しやすくなった。」 (OpenAI Developers)
ひと言でいうと、
“作れなかったものが作れるようになった” ではなく、“手動中心だった導入が、選択式でかなり楽になった” という理解がいちばん近いです。 (OpenAI Help Center)
必要でしたら次に、skills・plugins・MCP の違いを、導入方法と役割の観点で1枚の表にまとめます。
curated plugins directoryに納められたプラグインは、OpenAIが、その性能や安全性などを確認したものですか、それとも、保証対象外ですか
ChatGPT 5.4 Thinkingの回答
結論から言うと、「一定の審査はあるが、性能や安全性をOpenAIが保証しているわけではない」が最も正確です。
つまり、完全な無審査ではありませんが、“OpenAIのお墨付き保証品” とまでは言えません。 (OpenAI Developers)
まず、公式の Codex Plugin Directory に公開されるプラグインは、単に誰でも勝手に並ぶ仕組みではありません。OpenAI の Apps SDK ドキュメントでは、公開配布したい app は dashboard-based review flow に提出され、承認された app を公開すると OpenAI が Codex 配布用の plugin を作成すると書かれています。さらに OpenAI は、自動スキャンや手動レビューを行って、app の動作やポリシーとの衝突がないか確認すると明記しています。 (OpenAI Developers)
しかも、そのレビューではかなり具体的な確認項目があります。
たとえば OpenAI は、テストケースが正しい結果を返すか、プライバシーポリシーに未開示のユーザーデータを返していないか、tool hint が実際の挙動と合っているかなどを確認し、問題があれば却下または再提出になります。なので、最低限の品質・安全・ポリシー整合性チェックはあると見てよいです。 (OpenAI Developers)
ただし、ここが大事ですが、それでも保証まではしていません。
OpenAI の Services Agreement では、サービスは “as is” で提供され、顧客の要求や期待を満たす保証はしない、不具合修正の保証もしない、さらに Third-Party Services についても保証しない と明記されています。加えて、第三者サービスの利用は、そのサービスの利用規約にも従う形です。つまり、Directory に載っていること = OpenAI が性能・安全性を法的に保証している、とは読めません。 (OpenAI)
さらに、「curated」という言葉自体も、審査済み認証を意味する専門用語ではありません。
Codex の build docs では、ユーザー自身が作る marketplace.json についても、“curated list” という言葉が使われています。つまり、この言葉は「選んで並べた一覧」くらいの意味で使われており、それ自体が安全認証ラベルではないことが分かります。 (OpenAI Developers)
なので、整理するとこうなります。
- 公式の public Codex Plugin Directory 掲載物
→ OpenAI のレビュー工程を通っているので、無審査ではない。 (OpenAI Developers) - ただし
→ OpenAI が性能・安全性・継続動作を保証しているわけではない。第三者サービス部分も含めて、法的には 保証対象外寄り です。 (OpenAI) - “curated” の語感だけで安心しすぎるのは危険
→ これは「選定済みディレクトリ」を示す言葉であって、完全審査済み認証バッジではありません。 (OpenAI Developers)
実務的には、「公式ディレクトリ掲載 = ある程度の審査は通った」とは見てよいですが、
「だから安全・高性能が保証される」ではない、と考えるのが安全です。
特に Gmail や Drive のような外部サービスに触るプラグインは、権限範囲、実際の read/write 動作、返すデータの種類を自分でも確認して使うべきです。 (OpenAI Developers)
Claudeから使う利点についてだが、思った以上に利点があることが分かった。もともと、プラグインがこのニュースの主役で、より導入しやすくなったという話だったわけだが、調べていくと、Claude CodeからCodexを使う意味・メリットに興味が移ったので、以降、そちらの調査を行った。
GmailをCodexで直に利用する場合と、 Claude→Codexで利用する場合の比較
「Gmail連携」に絞って、Codex直利用と Claude→Codex の差を表で整理してください
ChatGPT 5.4 Thinkingの回答
はい。Gmail連携だけに絞ると、差はかなりはっきりしています。
要点は、メールを直接扱う能力そのものは Codex 側にある一方で、Claude→Codex の利点は「Claude を司令塔にしたまま Codex の Gmail 連携を呼べること」です。つまり、Gmail操作の機能差というより、作業導線の差です。
Codex の Gmail プラグインは、Codex に Gmail の読み書きや管理をさせるためのものとして案内されています。
Claude Code 用の Codex プラグインは、別実装ではなく、ローカルの Codex CLI / app server をそのまま呼び出す方式です。 (OpenAI 開発者)
| 比較項目 | Codex直利用 | Claude→Codex | 実務上の見え方 |
|---|---|---|---|
| Gmailで何ができるか | Codex の Gmail プラグインを直接使って、Gmail を読んだり管理したりできます。Codex のプラグイン一覧から扱う形です。 (OpenAI 開発者) | 実際の Gmail 操作は Claude のネイティブ Gmail 機能ではなく、背後で動く Codex が担当します。 Claude Code の Codex プラグインは別ランタイムではなく、ローカルの Codex を呼びます。 (OpenAI Developer Community) | Gmail連携そのものはほぼ Codex 側の能力です。 |
| 操作の入り口 | Codex app / CLI からそのまま Gmail プラグインを使う形です。 Codex app には Plugins 画面、CLI には /plugins があります。 (OpenAI 開発者) | Claude Code から Codex を呼び出して使います。 OpenAI はこれを「同じワークフローに Codex を持ち込む」用途として案内しています。 (OpenAI Developer Community) | Claude中心で普段作業している人には Claude→Codex が自然です。 |
| 設定の単純さ | OpenAI 側だけを見ればよく、構成が最も単純です。Codex は ChatGPT プランまたは API キーで使えます。 (OpenAI Help Center) | Claude Code 側のセットアップに加えて、Codex 側にもログインが必要です。 もっとも、いったん整えば同じ Codex install / auth / config / MCP setup を再利用します。 (GitHub) | 初期設定はCodex直利用のほうが簡単です。 |
| 権限・認証の見え方 | Gmail 権限は Codex 側で扱うので、責任の所在が分かりやすいです。 Codex は ChatGPT アカウント接続または API キーで使えます。 (OpenAI Help Center) | Claude→Codex でも、実際には Codex のローカル認証状態 を使います。 つまり Gmail アクセス権は Claude ではなく、Codex 側の設定に依存します。 (GitHub) | 権限管理の分かりやすさはCodex直利用が上です。 |
| Claudeから使う利点 | なし。Codexを直接触る前提です。 | OpenAI は、Claude Code から Codex を使う利点として、標準レビュー、より懐疑的な adversarial review、別エージェントへの作業委譲を挙げています。 Gmail連携で言えば、たとえば「メール内容を踏まえてコード修正や調査を続ける」ような流れを、Claude中心の画面でつなぎやすいです。 (OpenAI Developer Community) | メール操作自体の利点ではなく、作業フロー統合の利点です。 |
| Gmail用途との相性 | 「受信メールを読む」「草案を作る」「受信内容に基づいて手早く処理する」には最短です。 これは Codex の Gmail プラグインの想定に合います。 (OpenAI 開発者) | 「まず Claude で考え、必要なところだけ Codex に渡して Gmail も触らせる」には向きます。 | 単純なメール処理はCodex直利用、複合ワークフローはClaude→Codexが向きます。 |
| 固定費 | Codex は ChatGPT Plus / Pro / Business / Enterprise/Edu に含まれ、期間限定で Free / Go にも含まれます。 (OpenAI Help Center) | Claude Code を使うには、少なくとも Claude Pro / Max か API 利用が必要です。 Claude Pro は月額20ドル、Claude Code は Pro に含まれます。 さらに Codex 側も ChatGPT サブスクまたは OpenAI API キーが必要です。 (Claudeヘルプセンター) | 両方使うと固定費が二重化しやすいです。 |
| 従量課金の増え方 | Codex 単独なら、Codex の使用量だけを見ればよいです。Codex の平均コスト例は、ローカルタスク約7 credits、クラウドタスク約34 credits(GPT-5.4)です。 (OpenAI Help Center) | Claude Code は Pro / Max の利用枠共有ですが、API credits を使う設定にすると Claude 側も標準 API 料金 で課金されます。 そのうえ Codex 側の使用量も別に発生しえます。 Claude API価格の例は Sonnet 4.6 が入力 $3/MTok・出力 $15/MTok、Opus 4.6 が入力 $5/MTok・出力 $25/MTok です。 (Claudeヘルプセンター) | 費用面はCodex直利用のほうが有利です。 |
ひとことで整理
Gmail連携だけを見るなら、Codex直利用のほうが分かりやすく、安く済みやすいです。 (OpenAI 開発者)
一方で、Claude→Codex の利点は Gmail 機能の強化ではなく、Claude を中心に据えたまま Codex の Gmail 連携・レビュー・委譲を差し込めることです。OpenAI自身も、Claude Code 向け Codex プラグインの主用途を「レビュー」「より懐疑的なレビュー」「別エージェントへの委譲」と説明しています。 (OpenAI Developer Community)
なので、実務上はこう考えると分かりやすいです。
メールを直接処理したいなら Codex直利用。
メールを材料にして、Claude中心で設計・実装・レビューまで流したいなら Claude→Codex。
ただし後者は、便利さの代わりに費用と構成が増えやすいです。 (Claudeヘルプセンター)
下記のように回答されましたが、どういうことなのか、その違いを分かりやすく教えてください。
Gmail連携を使う際、Claude Code の Codex プラグインは別ランタイムではなく、ローカルの Codex を呼びます。
ChatGPT 5.4 Thinkingの回答
分かりやすく言うと、
Claude Code の中に「Codexの別コピー」が入って動いているわけではない、という意味です。
Claude Code のプラグインは、Claude 側にレビュー用や委譲用のコマンドを追加する“窓口”で、実際のレビューや rescue の処理は 手元に入っている Codex 本体に渡されます。README でも、このプラグインは「Claude Code の中から Codex を使う」もので、セットアップ時にローカルの Codex が入っているか確認し、なければインストールを促し、未ログインなら codex login を求める流れになっています。 (GitHub)
たとえば、これを家電でたとえると、
Claude Code = リモコン
Codex = 実際に動く本体
です。
リモコンに「レビュー開始」ボタンが増えても、実際に動作するのは本体です。Claude Code 側の /codex:review や /codex:rescue は、その本体に仕事を依頼するための入口です。README でも、/codex:review は「Codex で直接 /review を実行したのと同じ品質」とされ、/codex:rescue は Codex の subagent 経由でタスクを渡すと説明されています。 (GitHub)
なので、違いを整理するとこうなります。
| 観点 | そうではない意味 | 実際の意味 |
|---|---|---|
| 「別ランタイムではない」 | Claude Code の中に、Codex専用の別エンジンが新しく内蔵されているわけではない | Claude Code のプラグインが、ローカルの Codex を呼び出して使う |
| インストール | Claude プラグインだけ入れれば完結、ではない | Codex 本体も必要で、README でも npm install -g @openai/codex が案内されている |
| ログイン | Claude 側だけログインすればよい、ではない | Codex 側のログイン状態も必要で、README に !codex login がある |
| 実際に処理するのは誰か | Claude プラグイン自身がレビュー処理を持っている、ではない | 実際のレビュー・委譲は Codex が行う |
この一文が特に重要なのは、権限・設定・費用の見方が変わるからです。
ローカルの Codex を使うということは、レビューや委譲は Codex の利用枠に加算されますし、Codex 側の設定やログイン状態にも依存します。README でも、必要条件として ChatGPT subscription または OpenAI API key が挙げられ、利用は Codex usage limits に加算されると書かれています。 (GitHub)
かなり短く言うと、
Claude Code プラグインは「Codexそのもの」ではなく、「Codexを呼び出すための操作パネル」です。
だから、見た目は Claude Code のコマンドでも、裏で本当に働いているのはローカルの Codex です。 (GitHub)
必要なら次に、これを 「Claudeチャット」「Claude Code」「Codex本体」 の3者比較で図っぽく整理できます。
「Claudeチャット」「Claude Code」「Codex本体」 の3者比較で図っぽく整理してください
ChatGPT 5.4 Thinkingの回答
はい。
混ざりやすいので、「何者か」「どこで動くか」「何が得意か」で図っぽく分けると、こう理解すると分かりやすいです。Claude の通常チャットは会話中心のUIで、カスタムコネクタや remote MCP をつないで外部サービスに触れます。
Claude Code はターミナル中心のコーディング支援で、ファイル・シェル・Web などを使う開発向けの体験です。
Codex 本体は OpenAI のコーディングエージェントで、CLI・IDE拡張・Codex app・app server を持ち、プラグインで Gmail や Drive なども拡張できます。 (Claudeヘルプセンター)
[Claudeチャット]
会話が主役
├─ 外部接続: Connectors / custom connectors / remote MCP
├─ 得意: 要約・相談・文書化・資料横断
└─ 必要に応じて外部ツールを呼ぶ
[Claude Code]
開発作業が主役
├─ 場所: ターミナル
├─ 得意: コード読解・編集・コマンド実行
├─ 拡張: skills / 設定 / 連携
└─ 必要ならCodexを“外部の作業者”として呼ぶ
[Codex本体]
OpenAIのコーディングエージェント本体
├─ 場所: Codex CLI / Codex app / IDE拡張 / app-server
├─ 得意: コード編集・実行・レビュー・並列作業
├─ 拡張: plugins(Gmail, Drive, Slack など)
└─ 他の製品からも呼ばれうる
1枚で見る役割の違い
| 項目 | Claudeチャット | Claude Code | Codex本体 |
|---|---|---|---|
| 主役 | 会話 | 開発作業 | コーディングエージェント |
| 主な場所 | Claude の Web / Desktop | ターミナル | CLI / app / IDE / app server |
| 得意分野 | 要約、相談、資料整理、成果物化 | コード修正、シェル実行、開発フロー | 実装、レビュー、実行、並列タスク |
| 外部接続 | Connectors / custom connectors / remote MCP | skills・設定・各種連携 | plugins・MCP・app server |
| Gmailとの距離感 | 会話の中で参照・活用しやすい | 開発フローの補助として扱う | プラグインで直接 read/manage できる |
| Codexとの関係 | 必要なら remote MCP などで外部接続 | 公式プラグイン経由で Codex を呼べる | それ自体が本体 |
この整理の根拠として、Claude の通常チャット側は custom connectors / remote MCP を通じて外部サービスにつなぐ仕組みがあり、未検証サーバーは信頼できるものだけ使うよう注意書きがあります。
Claude Code は Anthropic の公式 docs で、数分で使い始められる開発用ツールとして案内されています。
Codex は OpenAI の docs で、ソフトウェア開発向けの coding agent として説明され、CLI・app・IDE 拡張・app server を持ちます。 (Claudeヘルプセンター)
3者の関係を、もう少し直感的に言うと
Claudeチャットは「相談役兼まとめ役」です。メールやDriveの情報、外部コネクタの内容を会話の中で扱い、要約や文章化に強いです。Artifacts は MCP 経由で外部サービスともつながれます。 (Claudeヘルプセンター)
Claude Codeは「開発現場の操縦席」です。ターミナルでコードを見て、編集して、必要ならコマンドを実行するための場です。skills を SKILL.md で拡張できるのも Claude Code 側の特徴です。 (Claude API Docs)
Codex本体は「実際に働く作業者」です。ローカルの CLI でも、Codex app でも、IDE 拡張でも使え、コードの読解・編集・実行やレビューを行います。さらに plugins で Gmail、Google Drive、Slack などを扱えるように拡張できます。 (OpenAI Developers)
以前の質問とつなげると
「Claude Code の Codex プラグインは別ランタイムではなく、ローカルの Codex を呼ぶ」というのは、
Claude Code = 操作パネル
Codex本体 = 実際に働くエンジン
という意味です。OpenAI は Codex app server を、他製品に深く組み込むためのインターフェースとして公開していますし、Codex CLI 自体もコーディングエージェント本体です。 (OpenAI Developers)
使い分けの感覚
- Claudeチャットを使う場面
メールや資料を読みながら、相談・整理・文章化したいとき。 (Claudeヘルプセンター) - Claude Codeを使う場面
端末でコードを直しながら、開発フローの中でAIを使いたいとき。 (Claude API Docs) - Codex本体を使う場面
実装・レビュー・プラグイン活用まで含めて、OpenAI の coding agent を主役にしたいとき。 (OpenAI Developers)
かなり短くまとめると、
Claudeチャットは“相談する場所”、
Claude Codeは“開発を進める場所”、
Codex本体は“実際に手を動かすエンジン”
です。 (Claude API Docs)
「レビュー」と「より懐疑的なレビュー」を比べた場合、Codexへの指示はどのように違うのですか
ChatGPT 5.4 Thinkingの回答
はい。違いは「レビュー対象」よりも、Codexに求める姿勢と自由度」です。
公式READMEの説明に沿って言うと、/codex:review は通常の読み取り専用レビューで、/codex:adversarial-review は実装方針そのものを疑ってかかる、誘導可能なレビューです。 (GitHub)
表にするとこうです。
| 項目 | /codex:review | /codex:adversarial-review |
|---|---|---|
| 基本姿勢 | 通常のコードレビュー | 実装方針・設計判断を疑って検証 |
| 指示の自由度 | 固定的。追加の焦点テキストを渡せない | 可変。flags の後ろに追加の焦点テキストを渡せる |
| 主な見る点 | 変更内容の一般的な問題点 | 前提、トレードオフ、失敗モード、代替案、隠れたリスク |
| 向く場面 | 変更の全体チェック | 出荷前の詰め、認証・データ損失・ロールバック・競合など高リスク領域の圧力試験 |
| 例 | /codex:review --base main | /codex:adversarial-review --base main challenge whether this was the right caching and retry design |
これを自然な日本語に直すと、通常レビューの指示は
「今の差分を普通のレビューとして見て、問題があれば指摘して」
に近いです。READMEでも、これは Codex本体の /review をそのまま使うのと同等品質 と説明されています。しかも steerable ではなく、独自の注目点を追加できません。 (GitHub)
一方、より懐疑的なレビューの指示は
「この実装方針自体が本当に正しいか疑って、前提の甘さや別案のほうが安全・単純ではないかまで見て」
に近いです。READMEでは、/codex:adversarial-review は chosen implementation and design を question する、つまり「選ばれた実装や設計を疑う」レビューだと明記されています。さらに focus text を追加できるので、たとえば「race condition を探して」「この retry/caching 設計が妥当か疑って」のように、疑う観点を明示できます。 (GitHub)
実務では、次のように使い分けると分かりやすいです。
/codex:review のイメージ
- 変更差分の一般的な欠陥を探す
- バグ、漏れ、危ない実装、見落としを広く確認する
- 方向性はひとまず受け入れたうえでチェックする (GitHub)
/codex:adversarial-review のイメージ
- そもそもその方向で良かったのかを疑う
- 「その設計、もっと単純な代替案はないか」
- 「ロールバック不能、データ損失、認証抜け、競合、信頼性低下の穴はないか」
- 実装の正しさだけでなく、判断そのものを pressure-test する (GitHub)
補足すると、レビュー対象の選び方自体はほぼ同じです。どちらも現在の未コミット変更や --base main のようなブランチ差分を対象にでき、--wait と --background も使えます。違うのは、review は「何を見るか」をこちらが細かく操れず、adversarial-review は「何を疑うか」をこちらが指定できる点です。 (GitHub)
かなり短くまとめると、
review= 「普通に査読して」adversarial-review= 「その設計判断を疑って、危ない前提や代替案まで突っ込んで」
です。 (GitHub)
「別エージェントへの委譲」としてCodexに依頼するメリットは何ですか
ChatGPT 5.4 Thinkingの回答
「別エージェントへの委譲」として Codex に依頼するメリットは、“もう一人のレビューアー” 以上に、“別の作業者として切り出せる”ことです。通常レビューは読み取り専用ですが、委譲は 調査・修正・継続実行 まで任せられます。
Claude Code 向けの公式 Codex プラグインでも、/codex:rescue は バグ調査、修正の試行、前回タスクの続行、より速い/安いモデルでの再実行 に使うものとして説明されています。 (GitHub)
いちばん大きい利点は、Claudeで考える作業と、Codexにやらせる作業を分離できることです。OpenAI は Codex を、コードを読み・編集し・コマンドを実行できるクラウド型のコーディングエージェントとして案内しており、タスクは独立した環境で動きます。つまり、Claude側で要件整理や会話を続けつつ、Codex側には「CIが落ちた理由を調べる」「最小パッチを試す」といった実務タスクを別枠で持たせやすい、ということです。 (OpenAI)
次の利点は、長い仕事をバックグラウンドに逃がせることです。/codex:rescue は --background、/codex:status、/codex:result、/codex:cancel を備えていて、時間のかかる調査や修正を裏で走らせ、あとで進捗確認や結果回収ができます。Codex 本体も、クラウドでバックグラウンド実行や並列実行ができると案内されています。これは、会話が止まりにくいという意味で、単なるレビュー依頼より実用的です。 (GitHub)
3つ目は、“考える人”と“手を動かす人”を分けられることです。レビュー系コマンドの /codex:review と /codex:adversarial-review はどちらも読み取り専用で、コードを直しません。一方 /codex:rescue は、README 上でも「問題を Codex に hand off する」用途として示され、fix the failing test with the smallest safe patch のように、修正の試行まで任せられます。つまり、「Claudeに設計相談し、Codexに実装や切り分けを任せる」という分業ができます。 (GitHub)
4つ目は、途中からの引き継ぎがしやすいことです。/codex:rescue は --resume を持ち、直近の rescue スレッドを継続できます。さらに /codex:result では、利用可能なら Codex session ID が出て、codex resume <session-id> で Codex 本体に戻って再開できます。つまり、Claude 側から投げた作業を、あとで Codex 側に持ち替えることもできます。 (GitHub)
5つ目は、コストや速度をタスクごとに変えやすいことです。README では /codex:rescue --model gpt-5.4-mini や --model spark の例があり、「より速い/安い pass を小さいモデルで行う」用途が明示されています。つまり、重い設計議論は Claude 側、軽い切り分けや一次修正は Codex の小さめモデル、という使い分けができます。 (GitHub)
実務での言い換えをすると、委譲のメリットは次の3つに集約できます。
「会話を止めずに裏で走らせられる」、「調査だけでなく修正まで任せられる」、「別モデル・別コスト帯で再挑戦できる」ことです。これが、通常のレビュー依頼とのいちばん大きな差です。 (GitHub)
ただし弱点もあります。README でも、長時間タスクはバックグラウンド推奨で、レビューゲートのような仕組みは使用量を早く消耗しうると警告されています。また、Codex プラグインの利用は Codex usage limits に加算されます。なので、メリットは大きいですが、「全部を委譲する」のではなく、詰まりやすい所だけ切り出すほうが実務向きです。 (GitHub)
かなり短くまとめると、
レビューは「見てもらう」ためのもの、
委譲は「やってもらう」ためのもの、
という違いです。 (GitHub)
OpenAIが公式に Claude Code 用の Codex プラグインを、「Claude Code のワークフローの中で使うもの」として案内した真意
下記のように回答してもらいましたが、OpenAIが、Codexのプラグイン直接利用ではなく、なぜ、他社のClaude Codeを想定した使い方を公式に出しているのですか。その真意を知りたいです。
OpenAIが公式に出しているのは Claude Code 用の Codex プラグインで、README でも「Claude Code のワークフローの中で Codex を使う」ものとして案内されています。
ChatGPT 5.4 Thinkingの回答
率直に言うと、OpenAIの「真意」を外部から断定することはできません。 私が確認した公開資料の中で、OpenAIが明言しているのは次の一点です。
「すでに Claude Code を使っている人に、同じワークフローの中へ Codex を簡単に持ち込むため」 です。告知文にはそのまま、“If you already use Claude Code, this Codex plugin is a simple way to bring Codex into the same workflow.” とあります。さらに用途も、通常レビュー、より懐疑的なレビュー、別エージェントへの委譲、の3つに絞って説明されています。 (OpenAI Developer Community)
まず大事なのは、これは「Codexのプラグイン直接利用の代わり」ではないという点です。OpenAIは同時に、Codex本体向けの公式プラグイン機能もちゃんと出しています。Codexの公式ドキュメントでは、プラグインは Codex app の Plugins 画面や CLI の /plugins から直接使う前提で説明されており、Gmail・Google Drive・Slack のような連携もここで案内されています。つまり、OpenAIは直接利用も公式に推していて、そのうえで Claude Code 向けも追加した、という構図です。 (OpenAI Developers)
この前提に立つと、公開情報からかなり強く推測できる狙いは3つあります。
1つ目は、他社ツールの利用者に対する導入障壁を下げることです。告知文の主語が「Codexユーザー」ではなく “If you already use Claude Code” になっているので、OpenAIは明らかに「いま別の開発フローにいる人」に向けて出しています。これは、Claude Codeをやめさせるというより、Claude Codeの中でまず Codex を試してもらうための入り口だと読むのが自然です。 (OpenAI Developer Community)
2つ目は、Codexを“アプリ”ではなく“組み込み可能なエージェント基盤”として広げたいことです。OpenAIの公式 docs では、Codex app server は “Embed Codex into your product” と書かれており、認証、会話履歴、承認、イベント配信まで含む深い統合用インターフェースとして公開されています。さらに Codex は MCP サーバーとしても起動でき、OpenAI自身が “build multi-agent development workflows” のために他の MCP クライアントから接続する使い方を案内しています。つまりOpenAIは、Codexを「自社UIの中だけで閉じる製品」ではなく、他の製品やエージェントから呼ばれる中核部品としても育てようとしている、と読むのがかなり妥当です。 (OpenAI Developers)
3つ目は、実装コストの低い“配布面の拡張”だった可能性です。Claude Code向けプラグインの告知では、これは別ランタイムではなく、ローカルの Codex CLI と Codex app server をそのまま使うので、既存の認証・設定・環境・MCP 設定を再利用できる、と説明されています。言い換えると、OpenAIはCodex本体を作り直してClaude向け専用品を作ったのではなく、既存のCodex基盤を他のフローから呼べるよう薄く差し込んだわけです。これなら、比較的少ない追加コストで新しい利用面を増やせます。 (OpenAI Developer Community)
なので、私の見立てをはっきり言うと、OpenAIの意図は「Codexの直接利用をやめてほしい」ではなく、「Codexを直接使う人も、他社IDE/他社エージェントから使う人も両方取り込みたい」だと思います。これは、Codex app / CLI の公式導線を維持しつつ、Claude Code 連携も同時に出していることと整合します。 (OpenAI Developer Community)
逆に、公開資料からは言えないこともあります。
たとえば「Claude Codeの人気に便乗したかった」「Codex単体では弱いから他社経由で売りたかった」「Anthropic対抗のためだった」といった話は、今回確認した OpenAI の一次資料には出ていません。そこまで言うのは推測が強すぎます。公開情報だけで安全に言えるのは、OpenAI自身が“Claude Codeの既存ユーザーに、同じ流れでCodexを持ち込む”と明言していること、そして Codexを他製品へ組み込める設計にしていることです。 (OpenAI Developer Community)
かなり短くまとめると、こうです。
OpenAIの真意として公開資料から最も自然に読めるのは、「Codexを単体製品として売るだけでなく、他社ワークフローの中にも入り込ませること」です。 そして Claude Code 向け公式連携は、その方針を示す分かりやすい実例です。 (OpenAI Developer Community)
OpenAIが、法人に強いClaude Codeを意識しているという状況が垣間見得た。確かにClaude Codeのセカンドオピニオンの役割を果たせるのは、実力的にみてChatGPTぐらいしかないような気もするので、OpenAIの案内は現実的。
「レビュー」に絞って、Codex直利用と Claude→Codex の差を表で整理してください
ChatGPT 5.4 Thinkingの回答
はい。
まず前提として、OpenAI が公式に出している「Claude→Codexでレビュー」は、通常のClaudeチャットではなく Claude Code 用プラグインです。 その前提で、レビュー用途だけに絞って差を表にすると、次のとおりです。 (GitHub)
| 比較項目 | Codex直利用 | Claude→Codex |
|---|---|---|
| 入口 | Codex app / CLI で /review を使います。Codex app には review pane (補足:レビュー画面)もあり、未コミット変更・ベースブランチ差分・直前ターン差分を見られます。 (OpenAI Developers) | Claude Code から /codex:review を呼びます。OpenAI 公式プラグインは「Claude Codeの同じワークフローにCodexを持ち込む」ものとして案内されています。 (GitHub) |
| レビュー対象 | Codex直利用の /review は、ベースブランチとの差分、未コミット変更、コミット単位レビューに対応します。 (OpenAI Developers) | /codex:review は、現在の変更や --base main のようなブランチ差分を対象にできます。README の例は /codex:review と /codex:review --base main です。 (GitHub) |
| レビュー指示の細かさ | Codex直利用の /review は、公式ベストプラクティスで custom review instructions に対応すると案内されています。さらに GitHub 連携では @codex review for security regressions のような一時的な注目点も渡せます。 (OpenAI Developers) | /codex:review は steerable ではなく、custom focus text を取れません。 注目点を足したい場合は別コマンドの /codex:adversarial-review を使う設計です。 (GitHub) |
| 返ってくる体験 | Codex app では review pane で差分を見ながら、特定の行をクリックしてフィードバックを次ターンの文脈に戻せます。 CLI でも /review が組み込みコマンドです。 (OpenAI Developers) | Claude Code 側では、レビュー結果が Claude Code の同じセッション内 に返ります。 加えて /codex:status と /codex:result で進捗確認と結果取得ができます。 (GitHub) |
| バックグラウンド実行 | Codex 本体はバックグラウンド実行や並列実行のあるクラウド作業もサポートしていますが、/review 自体の説明で前面に出ているのはレビュー機能そのものです。 (OpenAI Help Center) | /codex:review --background が明示されていて、Claude Code で作業を続けながら結果待ちできます。これは plugin README の分かりやすい利点です。 (GitHub) |
| レビューの立ち位置 | Codexを主役にしてレビューします。OpenAI のベストプラクティスでも /review は「Codexでコードを確認する有用な選択肢」として紹介されています。 (OpenAI Developers) | Claudeが主役で、Codexを「セカンドパスのレビューアー」として差し込みます。OpenAI の告知でも、標準レビューは Claude Code プラグインの主要用途の1つです。 (OpenAI Developer Community) |
| 高リスク変更への広げ方 | Codex直利用でも review guidance や one-off focus を足せますし、GitHubレビューでは AGENTS.md の review guidelines も効きます。 (OpenAI Developers) | Claude→Codex 側では、通常レビューで足りないときに /codex:adversarial-review へ切り替える流れが明確です。つまり「通常レビュー」と「より懐疑的なレビュー」がコマンドで分かれています。 (GitHub) |
| 費用の乗り方 | Codex直利用なら、主に Codex の使用枠 / credits を見ればよいです。Codex はプラン内利用枠があり、上限後は credits で継続します。 (OpenAI Help Center) | Claude→Codex では、Codex usage limits に加算されるうえ、Claude Code 自体も Claude 側のプラン利用枠または API credits を使います。つまり、実務上は両方の使用量を気にする必要があります。 (GitHub) |
実務向けに一言でまとめると
- Codex直利用が向く
レビュー自体を主作業にしたいときです。差分を見ながら細かくフィードバックしたい、レビュー指示を直接足したい、GitHubレビューや AGENTS.md の方針を素直に使いたい場面に向きます。 (OpenAI Developers) - Claude→Codex が向く
Claude で実装や会話を進めたあと、別エージェントのセカンドパスを差し込みたいときです。特に--background、/codex:status、/codex:resultがあるので、Claude Code の流れを止めずにレビューだけ Codex に振りやすいです。 (GitHub)
かなり短く言うと、
レビューの自由度と“Codexを主役にする感”は Codex直利用が上、Claudeの流れの中にレビューを差し込むやりやすさは Claude→Codex が上です。 (OpenAI Developers)
必要でしたら次に、これをさらに絞って 「個人利用ならどちらが現実的か」 を、費用と手間だけで表にします。
ClaudeからCodexに委譲するメリットを教えてください
ChatGPT 5.4 Thinkingの回答
あります。
ただし、**いちばん明確な利点が公式に説明されているのは「Claude Code から Codex に委譲する場合」**です。OpenAI の公式プラグイン README では、この連携は **「すでに使っているワークフローの中で Codex を始めやすくする」**ためのものとして説明されています。 (GitHub)
主なメリットは次のとおりです。
1. Claude の流れを止めずに、別作業を Codex に渡せる/codex:rescue で、バグ調査、修正の試行、前回タスクの続きなどを Codex に渡せます。つまり、Claude 側で会話や設計を続けながら、Codex 側には「原因調査」や「最小修正」を別枠でやらせやすい、ということです。 (GitHub)
2. 長い処理をバックグラウンドに回せる
README では、レビューや委譲タスクは時間がかかることがあり、--background の利用が推奨されています。さらに /codex:status と /codex:result で進捗確認と結果取得ができます。Claude の画面を主軸にしつつ、重い仕事だけ Codex に裏で走らせられるのが利点です。 (GitHub)
3. 修正まで含めて任せられる/codex:review や /codex:adversarial-review は読み取り専用ですが、/codex:rescue は「バグを調べる」「修正を試す」用途として案内されています。つまり、委譲は単なる査読ではなく、実際に手を動かす作業まで任せられます。 (GitHub)
4. 小さいモデルで安く・速く試せる
README では、/codex:rescue --model gpt-5.4-mini や --model spark の例があり、より速い/安いパスを小さめモデルで回す用途が明示されています。重い本番レビューは後回しにして、まず軽く切り分ける、という使い分けができます。 (GitHub)
5. Codex を“セカンドパス役”にできる
OpenAI はこのプラグインで、通常レビュー、より懐疑的なレビュー、委譲を主用途として挙げています。つまり、Claude を主役にして考えさせ、Codex を「別視点の実務担当」や「第二のレビュー担当」に回せるのが利点です。 (GitHub)
6. 必要なら Codex 本体へ引き継げる/codex:result では、利用可能なら Codex session ID が表示され、codex resume <session-id> で Codex 側に戻って再開できます。最初は Claude から委譲し、途中から Codex 主体に切り替える流れも取れます。 (GitHub)
逆に言うと、**Claude から委譲する最大の利点は「Codex の能力が増えること」ではなく、「Claude を司令塔にしたまま Codex を作業者として差し込めること」**です。OpenAI の告知でも、これは Claude Code ユーザーが今の流れのまま Codex を使い始めるためのものだと説明されています。 (GitHub)
注意点として、使用量は Codex 側の利用枠にも加算されますし、レビューゲートのような仕組みは使用量を早く消耗しうると README で警告されています。なので、全部を委譲するより、詰まりやすい作業だけ切り出すほうが実務向きです。 (GitHub)
ひとことで言うと、
Claude から Codex に委譲するメリットは、「会話は Claude、実務の切り分けや重い作業は Codex」という役割分担を作れることです。 (GitHub)
Claude CodeがCodexのプラグインでGmail連携を行う事例を紹介したが、Claude CodeがCodexを経由せずにGmailと連携できるのかを確認した。
Claude Codeは、Gmailを使えるか
Claude Codeは、Gmailを使えますか
ChatGPT 5.4 Thinkingの回答
はい、現在の Claude Code は Gmail を使えます。
その点は補足したほうが正確でした。Anthropic の Claude Code リリースノートには、「Claude Code で claude.ai MCP connectors を使えるようにした」とあり、その後の更新でも 「claude.ai MCP connectors(Slack、Gmail など)」 についての不具合修正が複数書かれています。つまり、Gmail は Claude Code 側でも使える接続経路がある、ということです。 (Claude API Docs)
なので、今の整理はこうです。
まず結論
Claude Code には Gmail を使う道が2本あります。
A. Claude Code → Claude側のGmailコネクタ
B. Claude Code → Codexプラグイン → ローカルのCodex → CodexのGmailプラグイン
この2つは似ているようで別物です。(Claude API Docs)
違いを図っぽくすると
[Claude CodeでGmailを使う]
1) Claude Code直
Claude Code
└─ claude.ai MCP connectors
└─ Gmail
2) Codex経由
Claude Code
└─ Codexプラグイン
└─ ローカルのCodex
└─ CodexのGmailプラグイン
何が違うのか
| 観点 | Claude Codeで直接Gmail | Claude CodeからCodex経由でGmail |
|---|---|---|
| どこが主役か | Claude Code自身 | Codex本体 |
| Gmailに触るのは誰か | Claude側の connector / MCP 経路 | Codex の Gmail plugin |
| 必要なもの | Claude Code と claude.ai connector 設定 | Claude Code + Codexプラグイン + ローカルCodex + Codex側認証 |
| 意味合い | Claude Code が自分の道具として Gmail を使う | Claude Code が 別の作業者として Codex を呼び、その Codex が Gmail を使う |
この違いは、OpenAI の Codex プラグイン README が、Claude Code 用プラグインは別ランタイムではなく、同じローカルの Codex install / auth / config / MCP setup を使うと説明していることからも確認できます。つまり、Codex経由のときは、実際に働いているのはClaude Codeの中身ではなくローカルのCodexです。 (Claude API Docs)
分かりやすく言うと
- Claude Code直
Claude Code が自分で Gmail を使う - Codex経由
Claude Code がCodex に「代わりにやって」と頼み、Codex が Gmail を使う
です。(Claude API Docs)
だから、前の文の正しい読み方
前に出てきた
「Gmail連携を使う際、Claude Code の Codex プラグインは別ランタイムではなく、ローカルの Codex を呼びます」
という文は、
「Claude CodeはGmailを使えない」という意味ではありません。
そうではなく、
「Codexプラグイン経由でGmailを使う場面では、Gmailを触っている主体はClaude CodeではなくCodexだ」
という意味です。
Claude CodeにはClaude Code自身のGmail経路もありますが、Codexプラグインを使った瞬間は“Codex側の道具立て”で動いている、という切り分けです。 (Claude API Docs)
実務でどう考えればいいか
- Claude Codeでそのまま Gmail を使いたい
→ Claude Code直の connector 経路が自然です。Anthropic は Claude Code で claude.ai MCP connectors を使えるようにしたと案内しています。 (Claude API Docs) - Codex のレビュー・委譲・プラグイン群を主役にして Gmail も使いたい
→ Codex経由です。この場合、Claude Codeは窓口で、実作業はCodexです。 (Claude API Docs)
かなり短くまとめると、
はい、Claude CodeもGmailを直接使えます。
ただし、Codexプラグイン経由の話をしているときは、Gmailを使っている主体がClaude CodeではなくCodexに切り替わる、というのがポイントです。 (Claude API Docs)
必要でしたら次に、「Claude Code直のGmail」と「Claude Code→Codex→Gmail」を、設定・費用・向く用途の3列で表にします。
ClaudeからCodexを呼び出しプラグインを使用する例を紹介したページ
OpenAIが、ClaudeからCodexを呼び出しプラグインを使用する例を紹介したページのURLを教えてください
ChatGPT 5.4 Thinkingの回答
はい。OpenAI が 「Claude Code から Codex を呼び出して使う」 例として案内している主な公式ページは、次の2つです。告知ページが 1つ、実際の導入手順とコマンド例が載っている README が 1つあります。 (OpenAI Developer Community)
告知ページ
https://community.openai.com/t/introducing-codex-plugin-for-claude-code/1378186
このページが、OpenAI のコミュニティ告知として
“Introducing Codex Plugin for Claude Code” を紹介しているページです。 (OpenAI Developer Community)
実際の公式リポジトリ / README
https://github.com/openai/codex-plugin-cc
こちらが OpenAI 公式の GitHub リポジトリで、README に/codex:review、/codex:adversarial-review、/codex:rescue などの具体例が載っています。 (GitHub)
必要なら、次に README 内の「Claude Code から Codex を呼ぶ具体的なコマンド例」 だけ抜き出して整理します。
Claude Code から Codex を呼ぶ具体的なコマンド例
README 内の「Claude Code から Codex を呼ぶ具体的なコマンド例」を教えてください
ChatGPT 5.4 Thinkingの回答
README に出ている、Claude Code から Codex を呼ぶ具体的なコマンド例は主に次のとおりです。すべて OpenAI 公式の openai/codex-plugin-cc README に載っている例です。 (GitHub)
まず導入と初期確認です。Claude Code 側でマーケットプレイス追加、プラグイン導入、再読込、セットアップ確認という流れです。 (GitHub)
/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup
Codex を自分で入れる場合や、まだログインしていない場合の例も README にあります。 (GitHub)
npm install -g @openai/codex
!codex login
README が最初の試運転として挙げているのは、バックグラウンドでレビューを流し、状態確認し、結果を見る流れです。 (GitHub)
/codex:review --background
/codex:status
/codex:result
通常レビューの例はこの3つです。現在の変更を見る、main との差分を見る、バックグラウンドで回す、という使い分けです。通常レビューは読み取り専用で、コード変更はしません。 (GitHub)
/codex:review
/codex:review --base main
/codex:review --background
より懐疑的なレビューでは、追加の焦点テキストを付けられます。設計判断やリスク領域を疑わせたいときの例として、README には次が載っています。これも読み取り専用です。 (GitHub)
/codex:adversarial-review
/codex:adversarial-review --base main challenge whether this was the right caching and retry design
/codex:adversarial-review --background look for race conditions and question the chosen approach
委譲に使う /codex:rescue の例はかなり多いです。バグ調査、最小修正、前回の続き、小さめモデルでの再実行、バックグラウンド実行などです。 (GitHub)
/codex:rescue investigate why the tests started failing
/codex:rescue fix the failing test with the smallest safe patch
/codex:rescue --resume apply the top fix from the last run
/codex:rescue --model gpt-5.4-mini --effort medium investigate the flaky integration test
/codex:rescue --model spark fix the issue quickly
/codex:rescue --background investigate the regression
README には、スラッシュコマンドではなく自然文で委譲する例もあります。 (GitHub)
Ask Codex to redesign the database connection to be more resilient.
状態確認・結果確認・キャンセルの例は次のとおりです。特定ジョブIDを指定する形もあります。 (GitHub)
/codex:status
/codex:status task-abc123
/codex:result
/codex:result task-abc123
/codex:cancel
/codex:cancel task-abc123
レビューゲートの有効化・無効化も README にあります。Claude の応答後に Codex レビューを走らせる設定です。 (GitHub)
/codex:setup --enable-review-gate
/codex:setup --disable-review-gate
README の「Typical Flows」に出ている、まとまった使い方の例も挙げておきます。出荷前レビュー、問題の委譲、長時間ジョブ開始の例です。 (GitHub)
/codex:review
/codex:rescue investigate why the build is failing in CI
/codex:adversarial-review --background
/codex:rescue --background investigate the flaky test
/codex:status
/codex:result
必要でしたら次に、これらを
「何をしたいときにどのコマンドを打つか」 という日本語の早見表にして並べます。
コマンド早見表(目的別)
「何をしたいときにどのコマンドを打つか」 という日本語の早見表にしてください
ChatGPT 5.4 Thinkingの回答
はい。「何をしたいときに、どのコマンドを打つか」だけに絞った早見表です。すべて OpenAI 公式の codex-plugin-cc README に基づいています。 (GitHub)
導入・初期確認
| やりたいこと | 打つコマンド |
|---|---|
| Claude Code に公式マーケットプレイスを追加したい | /plugin marketplace add openai/codex-plugin-cc |
| Codex プラグインを入れたい | /plugin install codex@openai-codex |
| プラグインを再読込したい | /reload-plugins |
| Codex が使える状態か確認したい | /codex:setup |
| Codex を自分で入れたい | npm install -g @openai/codex |
| Codex にログインしたい | !codex login |
この流れでセットアップし、最初の試運転としては /codex:review --background → /codex:status → /codex:result が README で案内されています。 (GitHub)
レビューしたい
| やりたいこと | 打つコマンド |
|---|---|
| 今の変更を普通にレビューしてほしい | /codex:review |
main との差分をレビューしてほしい | /codex:review --base main |
| レビューを裏で回したい | /codex:review --background |
/codex:review は通常の読み取り専用レビューで、コードは変更しません。追加の注目点は渡せません。 (GitHub)
設計や判断を厳しく疑ってレビューしたい
| やりたいこと | 打つコマンド |
|---|---|
| 実装方針そのものを疑って見てほしい | /codex:adversarial-review |
main との差分について、特定の設計判断を疑ってほしい | /codex:adversarial-review --base main challenge whether this was the right caching and retry design |
| race condition など特定のリスクを重点的に疑ってほしい | /codex:adversarial-review --background look for race conditions and question the chosen approach |
こちらも読み取り専用ですが、/codex:review と違って追加の焦点テキストを渡せます。 (GitHub)
Codex に作業を委譲したい
| やりたいこと | 打つコマンド |
|---|---|
| テストが落ちた原因を調べてほしい | /codex:rescue investigate why the tests started failing |
| 最小限で安全な修正を試してほしい | /codex:rescue fix the failing test with the smallest safe patch |
| 前回の続きからやってほしい | /codex:rescue --resume apply the top fix from the last run |
| 小さめモデルで軽く調べてほしい | /codex:rescue --model gpt-5.4-mini --effort medium investigate the flaky integration test |
| できるだけ速く当たりを付けてほしい | /codex:rescue --model spark fix the issue quickly |
| 委譲タスクを裏で回したい | /codex:rescue --background investigate the regression |
/codex:rescue は、バグ調査、修正の試行、前回タスクの継続、速い/安いモデルでの再実行に向いています。自然文で「Ask Codex to …」と依頼する形も README にあります。 (GitHub)
進捗や結果を見たい
| やりたいこと | 打つコマンド |
|---|---|
| 今動いている仕事を確認したい | /codex:status |
| 特定ジョブの状態を見たい | /codex:status task-abc123 |
| 直近の完了結果を見たい | /codex:result |
| 特定ジョブの結果を見たい | /codex:result task-abc123 |
/codex:status は進捗確認、/codex:result は完了後の保存済み出力の確認に使います。 (GitHub)
裏で動かした仕事を止めたい
| やりたいこと | 打つコマンド |
|---|---|
| 今動いているジョブを止めたい | /codex:cancel |
| 特定ジョブだけ止めたい | /codex:cancel task-abc123 |
/codex:cancel はアクティブなバックグラウンドジョブを止めるコマンドです。 (GitHub)
まずこれだけ覚える版
- 普通にレビュー:
/codex:review(GitHub) - 厳しめレビュー:
/codex:adversarial-review(GitHub) - 作業を委譲:
/codex:rescue ...(GitHub) - 進捗確認:
/codex:status(GitHub) - 結果確認:
/codex:result(GitHub) - 停止:
/codex:cancel(GitHub)
必要でしたら次に、これを 「レビュー用」「委譲用」「普段使い用」 の3枚に分けて、さらに見やすく整理します。
コマンド早見表(用途別)
「レビュー用」「委譲用」「普段使い用」 の3枚に分けて、さらに見やすく整理してください
ChatGPT 5.4 Thinkingの回答
もちろんです。
OpenAI公式 README の内容だけを、見やすく 「レビュー用」「委譲用」「普段使い用」 の3枚に分けて整理します。コマンド名、用途、補足はすべて codex-plugin-cc README に基づいています。 (GitHub)
レビュー用
通常レビューと、設計判断まで疑う厳しめレビューを使い分けるときの早見表です。/codex:review は通常の読み取り専用レビュー、/codex:adversarial-review は追加の焦点テキストを渡せる読み取り専用レビューです。 (GitHub)
| やりたいこと | 打つコマンド | ひとこと |
|---|---|---|
| 今の変更を普通にレビューしてほしい | /codex:review | まずはこれ |
main との差分をレビューしてほしい | /codex:review --base main | ブランチ比較用 |
| レビューを裏で回したい | /codex:review --background | 待ち時間を減らせる |
| 実装方針そのものを疑って見てほしい | /codex:adversarial-review | 厳しめレビュー |
main との差分で、特定の設計判断を疑ってほしい | /codex:adversarial-review --base main challenge whether this was the right caching and retry design | 設計の妥当性確認 |
| race condition など特定リスクを重点的に見てほしい | /codex:adversarial-review --background look for race conditions and question the chosen approach | リスク領域を絞れる |
使い分けの目安
- まず確認したい →
/codex:review - 設計ミスや隠れた前提まで疑いたい →
/codex:adversarial-review(GitHub)
委譲用
/codex:rescue は、レビューではなく Codex に仕事を渡すためのコマンドです。README では、バグ調査、修正の試行、前回の続き、より速い/安いモデルでの再実行に向くと説明されています。 (GitHub)
| やりたいこと | 打つコマンド | ひとこと |
|---|---|---|
| テストが落ちた原因を調べてほしい | /codex:rescue investigate why the tests started failing | 原因調査 |
| 最小限で安全な修正を試してほしい | /codex:rescue fix the failing test with the smallest safe patch | 小さく直したいとき |
| 前回の続きからやってほしい | /codex:rescue --resume apply the top fix from the last run | 再開用 |
| 小さめモデルで軽く調べてほしい | /codex:rescue --model gpt-5.4-mini --effort medium investigate the flaky integration test | 軽めの調査 |
| できるだけ速く当たりを付けてほしい | /codex:rescue --model spark fix the issue quickly | スピード優先 |
| 委譲タスクを裏で回したい | /codex:rescue --background investigate the regression | 長い作業向け |
| 自然文で委譲したい | Ask Codex to redesign the database connection to be more resilient. | スラッシュなしでも可 |
使い分けの目安
- 調べるだけでなく、直すところまで任せたい →
/codex:rescue - 長くかかりそうなら
--backgroundを付ける (GitHub)
普段使い用
導入直後や、日常的に確認・回収・停止するときの基本セットです。README では、最初の試運転として /codex:review --background → /codex:status → /codex:result の流れも示されています。 (GitHub)
| やりたいこと | 打つコマンド | ひとこと |
|---|---|---|
| プラグインのマーケットプレイスを追加したい | /plugin marketplace add openai/codex-plugin-cc | 最初の一歩 |
| Codex プラグインを入れたい | /plugin install codex@openai-codex | インストール |
| プラグインを再読込したい | /reload-plugins | 読み込み直し |
| Codex が使える状態か確認したい | /codex:setup | セットアップ確認 |
| Codex を自分で入れたい | npm install -g @openai/codex | 手動インストール |
| Codex にログインしたい | !codex login | 認証 |
| 動いている仕事を確認したい | /codex:status | 進捗確認 |
| 特定ジョブの状態を見たい | /codex:status task-abc123 | ID指定 |
| 直近の完了結果を見たい | /codex:result | 結果確認 |
| 特定ジョブの結果を見たい | /codex:result task-abc123 | ID指定 |
| 動いているジョブを止めたい | /codex:cancel | 停止 |
| 特定ジョブだけ止めたい | /codex:cancel task-abc123 | ID指定停止 |
最初に覚える最小セット
- レビュー開始:
/codex:review --background - 進捗確認:
/codex:status - 結果確認:
/codex:result(GitHub)
迷ったときの最短ルール
- 見てもらうだけなら
review - 厳しく疑ってほしいなら
adversarial-review - やってもらうなら
rescue - 様子を見るなら
status - 結果を見るなら
result - 止めるなら
cancel(GitHub)
必要でしたら次に、これをさらに詰めて 「初心者向け5コマンドだけ版」 にします。
