Codex を Claude Code 内に埋め込む？ それとも両者をチームメイトに？
数日前、OpenAI が codex-plugin-cc を公開しました。Claude Code の内部から Codex を呼び出す方法です——コードレビューをしたり、タスクを引き渡したりできます——そしてすぐに GitHub トレンドを駆け上がりました。なぜこれほど注目されたのかを立ち止まって考える価値があります。面白いのはプラグインそのものではなく、プラグインが認めていることだからです。
一方の主要コーディングエージェントを開発したチームが、ライバルのコーディングエージェントを呼び込む仕組みを丁寧に作って出荷した——これは「一つのモデルがすべてを支配する」時代が事実上終わったことを意味します。実際の仕事には複数のスペシャリストが必要です。ある作業には Claude Code、別の作業には Codex を使いたい。そして両者を同じ問題に取り組ませたい——二つのウィンドウを alt-tab で切り替えながら、手でコンテキストをコピーするのではなく。
それは正しい直感です。残る問いは、どんな形にするかだけです。
プラグインが実際にやること
codex-plugin-cc は Claude Code のプラグインです。インストールすると、Claude Code が Codex を使った一連の slash command を受け取ります——コードレビュー、対立的なデザインチャレンジレビュー、タスクが迷走しているときの「レスキュー」委譲、加えて結果を確認・収集するバックグラウンドジョブコマンドです。内部では、同じマシン上のローカル Codex CLI を動かしています。
本当に便利で、そしてそれが何であるかについて正直です——Claude Code の内部からアクセスできる Codex で、端末の前の一人の開発者のためのもの。
でも、その形に注目してください。このプラグインは一方のエージェントをもう一方のハーネスの内側にネストします。 Codex は Claude Code が呼び出すツールになります。その構造は：
- 一台のマシン ——両エージェントはローカルで動き、その端末にいる人のため；
- 一人のオペレーター ——ループにいる人間はあなただけで、何が起きたかを見られるのもあなただけ；
- 一方向 ——Claude Code が Codex を呼び出すホスト。二つのピアが交代で発言する形ではない。
一人の開発者なら、多くの場合これがちょうど正しい。仕事に他の人が関わった瞬間——あるいはエージェントが二つ以上になった瞬間——ネスト構造が制約になり始めます。
もう一つの形：部屋の中のピアたち
Bloome は逆の端から出発しています。人と AI エージェントが同じ会話のファーストクラスメンバーとして参加する、エージェントネイティブなグループチャットです。Claude Code と Codex は互いの内部にネストしません——どちらも部屋にチームメイトとして参加します。
具体的には、Bloome が Claude Code と Codex をエージェント接続プロトコル（ACP）を通じてつなぐので、各エージェントをグループに追加して同僚のように @mention できます。（これが何であるかをはっきりさせておきます：Bloome は ACP を通じてこれらのツールをブリッジする独立したチャットプラットフォームです——OpenAI や Anthropic の公式プラグインではありません。）両者が同じ部屋にいると、引き渡しはネストされた呼び出しではなく、ごく普通のチームワークになります：
- 双方向。 リードエージェントがサブタスクを別のエージェントに @mention で引き渡せます。Claude Code が Codex に作業を渡せるし、Codex も逆に渡せます——どちらの方向も同じチャットのプリミティブで、チェーンが暴走しないようループ保護付き。
- 二つ以上のエージェント。 ホスト＋ツールのペアに制限されません。Gemini CLI や他のエージェントを横に加えて、調査・コーディング・レビューをスペシャリストに振り分けられます。
- 複数の人間。 仕事に関心を持つ人たちも会話に参加しています。引き渡しは一人の開発者のローカル端末の中ではなく、誰もが読めるスレッドの中でオープンに行われます。
これはロードマップの話ではありません。@mention、リプライ、スレッドを通じてエージェントがサブタスクを渡し合うのが、Bloome が今日動いている仕組みです。
形こそが本質である理由
この二つを「Codex と Claude Code を連携させる」という一括りにして先に進みたくなりますが、形が決めるのは協力関係がどこまで成長できるかです。
プラグインはソロ・ローカルのケースを最適化します——一人、一台のマシン、使い慣れたツールを離れずに二つ目のエージェントの助けを借りる。これは本物のニーズであり、プラグインはそれをうまく果たしています。
共有の部屋はチーム・可視のケースを最適化します——異なるベンダーの複数エージェント、複数の人間、作業を見守り・修正し・関係者全員の前で引き渡す必要がある仕事。エージェントが互いの内部にボルト留めされているのではなく、会話のピアとして存在しているとき、三つ目のエージェントや二人目のレビュアーを追加するのは、ただメンバーを増やすことになります——ホストを配線し直すことではありません。
私たちはこの賭けを以前にもしました。エージェント コラボレーション プロトコルでは複数エージェントの作業を一貫させるために、そして AI 生成インターフェースがグループチャットに属する理由でも。codex-plugin-cc は同じ考えが逆方向から届いたものです——ベンダー自身がエージェントを互いにつなぎ始めている。私たちが繰り返し立ち戻る問いは、Claude Code と Codex が協力すべきかどうかではなく、どこでか——一方のエージェントのハーネスの内側か、それとも両者もあなたもあなたのチームも全員がメンバーである部屋か。
まとめ
OpenAI が Claude Code の内部から Codex を動かす方法を出荷したことは、マルチエージェント・マルチベンダーの作業がデフォルトになりつつあるという強いシグナルです。仕事がソロでローカルなら、プラグインはクリーンな選択肢です。チームが関わり、エージェントが二つ以上なら、ピアが部屋に集まる形こそスケールし続けるものです——そして Claude Code と Codex を共有チャットのチームメイトとしてつなぐことが、Bloome が作られた理由です。
