新しい Codex は何が変わったのか：なぜ今は開発環境に近いのか
Codex の印象が 2025 年半ばで止まっているなら、今の Codex を開いたときにかなり違って見えるはずです。
単に機能が二つ三つ増えたという話ではありません。最初の Codex は「依頼したタスクをクラウド環境で実行して、結果を返す強力なコードエージェント」と捉えれば十分でした。
OpenAI 自身も 2025 年 5 月 16 日の紹介 で、Codex を cloud-based software engineering agent と説明しています。当時の使い方も分かりやすく、タスクを渡すと隔離環境で処理し、最後に変更や結果を返してくれる。中心にあったのは「代わりに実行する」能力でした。
その性格は今も残っています。ただ、現在の Codex をそれだけで説明するのは足りません。
2025 年 9 月 15 日の Introducing upgrades to Codex では terminal、IDE、GitHub といった入口がより強くつながり始めました。さらに 2026 年 2 月 2 日の Introducing the Codex app では、parallel agents、worktrees、task inbox、skills、automations が一つの流れとして提示されています。
ここまで来ると、Codex は単発タスク用のチャットというより、開発作業をまとめて扱う command center に近く見えます。
OpenAI は同じ Codex app の発表で、2025 年 12 月半ばに GPT-5.2-Codex が登場して以降 Codex 全体の利用量が倍増し、直近 1 か月では 100 万人を超える開発者が利用したとも説明しています。
利用者が増えるほど、毎回長い prompt でルールを説明する方法には限界があります。そのため最近の Codex が Skills、Plugins、Automations、各種統合を厚くしているのは自然な流れだと感じています。
注目すべきなのは Skills だけではなく、「配布できる形」ができたこと
Codex を何か月か使っていると、Skills が便利な理由はすぐ分かります。
リポジトリ固有のルール、コードスタイル、テスト条件、リリース境界、危険操作の確認形式、ディレクトリ規約。こうした内容を毎回 prompt に書くことはできますが、運用すると簡単にブレます。
ある日は詳しく書き、別の日は一行抜ける。すると同じモデルでも挙動が変わります。
Skills は、よく使う作業方法を再利用可能な形にまとめる層です。単一リポジトリや特定ワークフローで、自分の作業手順を育てていく用途に向いています。
ただし、今回の変化を Skills だけで見ると小さく捉えすぎます。OpenAI がさらに追加した重要な層が Plugins です。
Codex Plugins の公式ドキュメント では、plugin を reusable Codex workflows の installable bundle と説明しています。
つまり plugin は単なる UI ボタンではなく、複数の要素をまとめてインストール・共有できる配布単位です。
一つの plugin には、例えば次をまとめられます。
Skills：Codex が必要に応じて発見し、利用するワークフロー指示Apps：アプリ連携や connector mappingMCP servers：ワークフローで必要になるリモートツールや共有コンテキスト
この構造を見ると、今の Codex を「コードを書いてくれるチャット」ではなく、「チームやプロジェクトの作業方法を載せる環境」と捉えた方が分かりやすくなります。
Skills と Plugins は同じものではない
初めて Plugins を見ると「Skill の名前が変わっただけでは」と思うかもしれませんが、役割は違います。
大まかに言えば、Skill は局所的な能力、Plugin は配布単位です。
Skill が向くのは、例えば次のような状況です。
- 一つのリポジトリだけで繰り返し使う
- 個人的、またはプロジェクト固有のルールが多い
- まだ実験段階で、外部配布するほど固まっていない
一方 Plugin は次のような用途に向きます。
- 複数プロジェクトで同じ設定を使いたい
- Skills、MCP、アプリ統合を一つにまとめたい
- チームで同じ構成をバージョン管理しながら配りたい
公式ドキュメントでも、ローカル skills は単一リポジトリや実験的ワークフローに、plugins はチームや複数プロジェクトで共有する用途に向くという整理になっています。
そのため、skill は plugin を構成する一部で、外部に配る主要な単位は plugin と考えると理解しやすいです。
Plugin はすでに「パッケージ」として設計されている
個人的に印象的だったのは、OpenAI が概念だけで終わらせず、ディレクトリ構造や manifest、配布方法までかなり具体的に定義していることです。
最小構成では、入口として .codex-plugin/plugin.json を置きます。その上でルート以下に次のような要素を持てます。
skills/.app.json.mcp.jsonassets/
manifest には、例えば次のような情報を持たせられます。
- 識別情報：
name、version、description - コンポーネント参照：
skills、mcpServers、apps - 表示情報：
displayName、shortDescription、category、capabilities、brandColor、screenshots
パスは plugin root からの相対パスとして ./ で始める、といった細かい規約もあります。画像などは ./assets/ にまとめるのが推奨されています。
公式では、組み込みの @plugin-creator skill を使ってローカル plugin の雛形を作る方法も案内されています。
ここまで決まっているなら、単なる「将来こんな機能があると良い」という段階ではなく、再利用可能なワークフローをソフトウェアパッケージとして扱う方向がはっきりしています。
Marketplace がチーム利用で効いてくる
AI ツールのカスタマイズでよくある問題は、「自分だけは便利になったが、チームに同じものを配れない」ことです。
長い prompt や設定をコピーして共有すると、少しずつ差分が生まれます。元を書いた人だけが正しい意図を理解している状態にもなりやすいです。
Codex の marketplace は、その問題をかなり直接的に解こうとしています。
公式ドキュメントでは、Codex は次の marketplace を扱えます。
- 公式ディレクトリ
- リポジトリ単位：
$REPO_ROOT/.agents/plugins/marketplace.json - 個人単位：
~/.agents/plugins/marketplace.json
例えば自分のリポジトリに marketplace を置き、チームで使う plugin をそこにまとめることができます。個人用 marketplace に、自分が普段使うワークフローを集約することもできます。
インストールした plugin は ~/.codex/plugins/cache/$MARKETPLACE_NAME/$PLUGIN_NAME/$VERSION/ にキャッシュされ、ローカル plugin では local がバージョン名になります。Enable / disable の状態は ~/.codex/config.toml で管理されます。
こうしたインストール先、キャッシュ、バージョン、状態管理まで決められていることが重要です。そこまで揃って初めて、plugin は単なる紹介用機能ではなく、チームの基盤として使えます。
なお、公式 Plugin Directory へのセルフサービス公開は、現時点ではまだ全面開放されておらず coming soon とされています。
まずローカル、リポジトリ、組織内での配布モデルを整え、その後公開マーケットへ広げる流れに見えます。
開発者にとって何が一番大きいのか
私がこの一連の変化を重要だと思う理由は、単純な「モデル性能向上」とは別のところにあります。
以前の Codex は、非常に強い一回限りの外部メンバーに近い存在でした。タスクを渡せばかなりのところまでやってくれる一方、次回またルール、境界、ツール、好みを説明し直す必要がありました。
今の Codex が厚くしているのは、そうした反復説明を長期的なワークフロー資産に変える層です。
Skills が一段目、Plugins が配布と共有の二段目、Automations はそれらを時間や条件に応じて実行する方向へ進めます。
開発者が見るべきなのは「この関数を書けるか」だけではなく、「自分やチームのやり方で安定して働けるか」に変わってきます。
vibe coding のような使い方でも同じです。毎回ゼロから prompt を積み上げるのではなく、気に入った作業方法を保存し、パッケージ化し、再利用できます。
これまで AI コーディングツールの弱さは、モデルそのものより、周囲の環境が薄いこと、ワークフローが分断されること、再利用しにくいことにありました。
最近の Codex が埋めようとしているのは、まさにこの部分です。
そのため、今の Codex を一言で表すなら、以前より「コードエージェントらしくなった」ではなく、技能、plugin、自動化、チーム設定を載せられる開発ワークフロープラットフォームに近づいたという方がしっくりきます。