`codex mcp-server` が非推奨に — Codex を「呼ばれる側」として組み込む経路が app server とプラグインへ寄る

要約

OpenAI が 2026-08-24、ChatGPT & Codex changelog（learn.chatgpt.com/docs/changelog）で codex mcp-server コマンドを非推奨（deprecated）にしたと告知しました。公式の記載はきわめて短く、代替として次の2点だけが示されています。

1. Codex app server を使うこと
2. Claude Code から Codex を使う場合は、Claude Code 用の Codex プラグインを使うこと

codex mcp-server は、Codex CLI を MCP サーバーとして起動し、他のエージェントやクライアントから Codex をツールとして呼び出せるようにするコマンドでした。Codex を「使う側」ではなく「呼ばれる側」として、別のエージェントの中に組み込むための入口です。マルチエージェント構成で Codex を一部の役割に据える、あるいは別の CLI から Codex に作業を投げる、といった使い方の土台になっていました。

今回の非推奨化が意味するのは、その入口が置き換わるということです。 汎用プロトコルである MCP でつなぐ経路から、ベンダーが用意した app server と、特定クライアント向けのプラグインへ寄せられます。MCP は「どのクライアントからでも同じようにつなげる」ことに価値がある仕組みなので、ベンダー提供の専用経路へ移るということは、その汎用性を一段手放すことでもあります。

もっとも実務上重要なのは、廃止（削除）の期日が公式に示されていない点です。告知されているのは「非推奨」という状態だけで、いつコマンドが動かなくなるかは書かれていません。期日が無いことを「まだ猶予がある」と読むのは危険です。 非推奨から削除までの間隔をベンダーが事前に約束していない以上、次のリリースで消えても告知としては筋が通ってしまいます。

同じ 2026-08-24 付の changelog には Codex CLI 0.149.1 のエントリも並んでいます。ただし 0.149.1 のリリースノート本文には変更内訳が無く（GitHub Releases は compare リンクのみ）、非推奨化がこのバージョンでコード上どう反映されたかは公式からは確認できません。日付が同じというだけで両者を同一の変更として扱わないでください。

なお、Claude Code から Codex を使う経路としてプラグインが名指しされた点は、以前から記録している事実の裏付けを強めます。「Claude Code から Codex へ簡単に移行できる」という話は公式には逆方向のみで、公式が整備しているのは Claude Code の中で Codex を使う方向です。今回の案内は、その方向をさらに明確にしたものと読めます。

何が変わったか

• codex mcp-server コマンドが非推奨になった（2026-08-24 付 changelog）
• 代替は Codex app server
• Claude Code から Codex を使う場合は、Claude Code 用の Codex プラグインが公式の案内
• 廃止（削除）の期日は記載なし。告知されているのは非推奨の状態のみ
• 公式の記載は changelog の当該エントリ2行のみで、移行手順の詳細は本文に含まれない
• 同日付で Codex CLI 0.149.1（npm install -g @openai/codex@0.149.1）のエントリが別に存在するが、変更内訳は非公開で、非推奨化との対応関係は公式からは確認できない

業務インパクト（一般企業向け）

まず棚卸しすべきは、Codex を MCP サーバーとして呼んでいる箇所です。 自社のエージェント構成に codex mcp-server が入っているかどうかは、設定ファイルを検索すればすぐ分かります。問題は、それが誰の手元にあるかです。 MCP の接続設定は開発者のローカルに置かれていることが多く、組織側の台帳に載っていません。「うちは使っていないはず」を確認せずに結論にしないでください。

期日が示されていないことは、対応を後ろ倒しにする理由になりません。 むしろ逆です。期日が明示されている廃止告知なら、その日までに動けばよい。期日が無い非推奨は、いつ動かなくなるかを自分で見積もれない状態です。すでに本番のワークフローに組み込んでいるなら、移行先（app server またはプラグイン）を動く状態まで検証しておくのが安全側の判断です。切り替え自体は後でよく、検証だけ先に済ませておく形で構いません。

移行先の選択には、汎用性を手放すかどうかの判断が含まれます。 MCP でつないでいたということは、原理的には他のクライアントからも同じ形で使えたということです。app server やプラグインへ移ると、その経路はベンダーが想定するクライアントに寄ります。複数のエージェント基盤を併用している組織ほど、この差は後で効いてきます。 単に置き換えるのではなく、「どのクライアントから Codex を呼ぶ必要があるのか」を先に整理してから移行先を決めてください。

エージェント連携の構成は、非推奨の告知が届きにくい領域です。 モデルの退役や API の破壊的変更はニュースになりますが、CLI のサブコマンド1つの非推奨は、changelog の2行にしか出ません。今回の告知が GitHub Releases 側には現れず changelog 側にしかなかったという事実は、監視の穴を示しています。エージェント連携を業務に組み込んでいる組織は、製品のリリースノートだけでなく、開発者向け changelog を巡回対象に入れる必要があります。

そして、この構図は Codex に限りません。 MCP はベンダー横断でつながることを狙った仕組みですが、各社が自社クライアント向けの専用経路を整えていけば、実態としては囲い込みに近づきます。「MCP で組んでおけば移植性が保たれる」という前提は、そろそろ点検が要ります。 連携先を1本に絞らず、抽象化のレイヤーを自分側に持っておく設計が、当面は保険になります。

副業・個人活用視点

個人でマルチエージェント構成を組んでいるなら、これは手戻りの予告です。 Codex を MCP 経由で別のエージェントから呼ぶ構成は、まさに「複数の AI を組み合わせて使う」ことに慣れた層が作りがちな形です。動いているうちに移行先を試しておくのが、結果的にいちばん安く済みます。壊れてから調べると、締切と重なります。

支援先へエージェント連携を納品している立場なら、いま連絡すべき案件があるかを確認してください。 納品時に codex mcp-server を使った構成を組んでいたなら、それはいずれ動かなくなる可能性がある成果物です。期日が出てから連絡するより、非推奨の段階で「こういう告知が出ています、移行先はこれです」と先に伝えるほうが、信頼としては明確に上回ります。告知を読んでいることを見せられる機会は、そう多くありません。

この一件は、提案の材料としても使えます。 「AI ツールの連携は、つないだ時点で終わりではない」という主張には、抽象論だと説得力がありません。非推奨の告知が changelog の2行にしか出ず、GitHub のリリースノートには載らなかったという具体例があれば、監視体制の必要性を数分で説明できます。伴走支援のメニューに「連携先の変更告知の巡回」を入れる根拠として、そのまま使える事例です。

教材の題材としても質が高い。 非推奨と廃止の違い、期日が示されない告知の読み方、汎用プロトコルとベンダー専用経路のトレードオフ。この3点は、エージェント連携を扱う研修で必ず通る論点でありながら、実例が無いと抽象的な話に終わりがちです。今回はその全部が1つの告知に詰まっています。