コード生成モデル Codex の野望と、MCP および Skill の次なる展開

この数ヶ月、Codex App や Cursor などの Agent アプリを集中的に使用していますが、ある事柄がますます面白く感じられてきました。

昨年はどのモデルが強いかで争っていましたが、今年はどうやら、ウィンドウの右側がどれだけ使いやすいかで争うようになったようです。

Codex、Claude デスクトップ版、Cursor 3.0、TRAE SOLO。これら最上位の Agent は、全く調整を行わずにほぼ同時に、同じインターフェースレイアウトへと収束しました：左側にプロジェクトと会話リスト、中央に Agent との対話エリア、右側がワークスペースで、ファイル閲覧、ウェブプレビュー、ファイル変更レビューなどの機能が配置されています。

明らかに互いの模倣ではなく、むしろ現在の Agent 相互作用における最適解であるように思われます。

なぜ三欄なのか

従来の Chatbot（チャットボット）では二栏で十分でした。左側に会話履歴、右側に会話ウィンドウがあり、質問して回答を受け取り、使い終われば終了です。

しかし Agent 時代になると、Agent は自らコードを書き、ファイルを変更し、ツールを呼び出せるようになりました。完了後には、それが正しく行われたかを確認する必要があります。右側のワークスペースはまさにそのために存在するのです。

しかし、これはまだ第一段階に過ぎません。

ユーザーがますます多くの時間を Agent の指揮に費やすようになり、VSCode などの専門ツールを開く時間が自然と減っていきます。いずれ必ず表面化する問題があります：Agent がコードや PPT を作成した後、数文字を微調整したい場合、わざわざ別のソフトウェアを開いて切り替える必要があるのでしょうか？

誰もそれを望みません。ユーザーの自然な期待は「Agent 内で直接編集できないか？」という点です。これが現在 Codex App で最も要望されている機能の一つでもあります（もう一つの要望が高いのはモバイル版で、まもなくリリースされます）。

そこで各社は右側のワークスペースを静かにアップグレードし、単なるファイル編集記録の閲覧から、多機能エリアへと進化させ始めています。Codex は 4 月 16 日の大規模バージョン更新において、右側ワークスペースの変更幅が全機能の中で最大でした。

インタラクションの詳細については各社で若干の違いがあります。Codex と Cursor は Tab キーで切り替え、Claude はフローティングパネルを使用します。私が実際に使用した限りでは Codex が最も使いやすく、Claude のフローティングパネルはデザイン性は高いものの実用性に欠け、いずれ変更を余儀なくされるでしょう。

Codex の真の野望

しかし、この変化を単なる「インターフェースデザインの進化」として読み取るだけでは、Codex を過小評価することになります。

Codex が 4 月の大規模バージョン発表時に掲げたスローガンは「Codex for (almost) everything」——ほぼあらゆるタスクに対応可能——でした。これを広告のスローガンと捉えることもできますが、むしろ製品の方針を示す声明のようにも受け取れます。

この言葉を現実のものとするためには、Codex は単にコード作成が得意な Agent であるだけでは不十分です。さまざまなファイル形式を処理し、各分野の専門ワークフローをサポートし、ユーザーが最終的な手動微調整を含む一連のプロセスをすべてその中で完結できるようにする必要があります。

現時点では Codex は最後のステップをまだ達成できていません：生成された後で編集できず、コード、Markdown、PPTX 形式いずれも対応していません。これは製品戦略上の意図的な自制、技術的にまだ完全には確立されていない、あるいは統一されたソリューションの出現を待っているのかもしれません。

私は第三种の可能性が高いと推測しています。

MCP と Skill は半分しか解決していない

Codex が何を待っているのかを理解するには、まず Agent の能力パズルにおいて現在どの部分が欠けているかを明確に考える必要があります。

• MCP は「接続」の問題を解決しました：Agent が統一された規範を通じてさまざまなツール、データベース、カレンダー、コードリポジトリにアクセスし、すべてを連携させることができます。

• Agent Skills は「どのように行うか」という問題を解決しました：Agent は訓練されていない分野の知識やベストプラクティスを習得します。例えば、特定のスタイルで文章を書く方法や、ある種の複雑なタスクを処理する方法などです。

この 2 つの取り組みはどちらも概ね良好に進んでいます。しかし、常に埋められていない欠落部分があります：ユーザーによる二次編集です。

AI に記事を書かせた後でも、最終的には自分でエディターを開いて数箇所修正する必要があります。多くの場合、最後の 5% の精度を確保するのは、自分自身で手を動かすことしかできないからです。将来 AI がさらに賢くなっても、100% ユーザーの意図を理解することはできず、手動での修正は避けられないでしょう。

そのため最近、Markdown エディターが再び注目されています。Vibe Coding（雰囲気コーディング）によって生み出されたさまざまな Markdown 製品があふれかえっています。

しかし Codex が独自に Markdown エディターを作るわけではありません。なぜなら、人々の好みはそれぞれ異なるため、作っても誰かが不満を抱えることになるからです。さらに、各垂直分野の専門エディターをすべて統合することは不可能です。

最も合理的な道は、プラグイン機構です。

下一步：Agent 版 App Store

Agent をプラットフォーム化し、コミュニティにプラグインの提供を委ねるのです。VSCode や Chrome のようにです。

Codex は Agent のスケジューリング層にのみ集中し、ファイルプレビュー、二次編集、垂直分野における専門能力はすべてプラグインによって拡張させます。ユーザーは必要に応じてインストールします。デザインをする人はデザイン用プラグインを、文章を書く人はライティング用プラグインをインストールすればよいのです。

プラグイン機構はまた、長年答えが出なかった問題の解決にも役立ちます：Skill の商業化が困難であることです。

私の baoyu-skills はすでに 2 万スターを超えていますが、そこから得られた収益は 0 ドルです。Skill というものはほぼ透明で、Agent にとっても人間にとっても透明であり、複製コストは極めて低いです。どれだけ優れたものを書いても、参入障壁（護城河）は浅いままです。

プラグインは異なります。App Store や Chrome プラグイン市場では、すでに課金と著作権保護の仕組みが確立されています。これを Agent プラグイン市場に移行させることは十分に可能です。優れたプラグインには料金を設定でき、開発者が継続的に磨き上げる動機が生まれ、生態系が実際に回るようになります。

Codex にはすでに非常に原始的なプラグイン市場が存在します。成熟した有料プラグイン生態系に至るまでにはまだ長い道のりがありますが、方向性は正しいです。

この取り組みを行うのは Codex だけではありません。Cursor にも同様の兆候が見えます。唯一、Claude Code と Cowork については、現時点でそのような方向性の製品迹象は確認されていません——おそらく彼らはそれを軽視しているか、あるいはまだその段階に至っていないのでしょう。

中小チームに残された窗口

もし Codex が本当にプラグイン生態系を確立したなら、それは中小チームにとって何を意味するのでしょうか？

独自に垂直分野の Agent を作るほかに、もう一つの道があります：Codex のようなプラットフォーム上でプラグインを作ることです。Agent のスケジューリング層を自ら構築する必要も、トークン接続の問題を解決する必要もありません。ユーザーへの配布もプラットフォームに任せればよいのです。あなたが集中すべきは「最後の 1 キロメートル」のみ——ユーザーが Agent が生成した結果を適切に処理し、編集し、使いやすくすることです。

この窗口（機会）は長くは開いていません。先に参入した者は冷戦開始の红利（初期成長の恩恵）を得られ、後から参入する者は既存市場での競争に直面することになります。

そのタイミングは遠くありません。おそらく数ヶ月以内でしょう。

Codex の野心はそこにある、「ほぼあらゆるタスク」というスローガンが真に実現されるためには、プラグイン機構は避けて通れない一歩である。もし OpenAI がこの件で引き続き躊躇するなら、それこそが本当の失策となるだろう。

このプラグイン生態系において、最終的にどの企業が先に軌道に乗せるとお考えですか？あるいは、Agent にとってより適した製品表現形態があるとお考えでしょうか。コメント欄でぜひ共有してください！