［開発者向け］Cursor・Claude Code・Codexが「AIコーディングスタック」を形成——誰も設計しなかった3層構造の正体

2026-04-13

はじめに

　2026年4月第1週、AIコーディングツールの市場に大きな変化が起きました。Cursorがエージェント管理に特化した新インターフェースを発表し、OpenAIがAnthropic競合製品であるClaude Code向けの公式プラグインを公開、そして開発者たちは両者を同時に使い始めています。The New Stackが2026年4月12日に報じた内容をもとに、この動きが示す新たなスタック構造を解説します。

参考記事

タイトル: Cursor, Claude Code, and Codex are merging into one AI coding stack nobody planned
著者: Janakiram MSV
発行元: The New Stack
発行日: 2026年4月12日
URL: https://thenewstack.io/ai-coding-tool-stack/

要点

2026年4月第1週にCursor 3・OpenAI Codexプラグイン・早期採用者による複合利用が重なり、誰も設計していないAIコーディングスタックが自然発生的に形成されつつある
スタックはオーケストレーション層(Cursor)・実行層(Claude Code / Codex)・レビュー層(クロスプロバイダーレビュー)の3層に分化している
OpenAIがAnthropicの競合製品Claude Code向けに公式プラグイン「codex-plugin-cc」を公開し、ロックインではなくインターオペラビリティを戦略として選択した
Claude Codeは906名を対象としたPragmatic Engineer調査で「最も利用されているAIコーディングツール」として46%の支持を獲得し、公開GitHub コミットの約4%を占めるとされる
Codexのプラグインが実現した「クロスプロバイダーレビュー」は、同一モデルが自分のコードを採点する構造的限界に対する有力な対策として注目されている

詳細解説

1週間で起きた3つのリリースと1つの構造変化

　The New Stackによれば、2026年4月2日にCursorはバージョン3(コードネーム「Glass」)をリリースしました。従来のComposerペインを廃止し、複数のAIエージェントを並列管理するための専用インターフェース「Agents Window」を新設しています。デスクトップ・モバイル・Slack・GitHub・Linearなど複数の起点から起動したエージェントをサイドバーで一元管理でき、Agent Tabsにより複数の会話をグリッド表示で並べることも可能です。同じプロンプトを複数モデルに送って比較する /best-of-n コマンドや、ブラウザ内UIに直接アノテーションを付けてエージェントに指示できるDesign Modeも追加されました。

　その3日前、OpenAIはGitHub上に codex-plugin-cc を公開しています。このプラグインはClaude Code——Anthropicが提供するターミナルベースのコーディングエージェント——に直接インストールして使うもので、6つのスラッシュコマンドを提供します。/codex:review は標準的なコードレビューを実行し、/codex:adversarial-review は認証・データ損失・競合状態といった観点から実装を厳しく検証します。/codex:rescue はタスクをCodexサブエージェントに引き渡し、バグ調査や別解の探索を委ねます。Apache 2.0ライセンスで提供され、開発者の既存ローカルCodex CLIと認証情報を共有するため、新たなランタイムや課金契約は不要です。

　本ブログでは以前Claude Codeのプラグインシステム導入を取り上げました（→ https://jobirun.com/claude-code-plugins-customize-share-workflows/ ）。今回のOpenAI公式プラグインはその延長線上にあたり、サードパーティ統合の枠を超えて競合企業間の相互運用を実現した事例と言えます。

3層スタックの構造

　記事では、早期採用者が形成しつつある構成を「オーケストレーション層」「実行層」「レビュー層」の3層として整理しています。

　オーケストレーション層ではCursor 3が中心的な役割を担います。Agents Windowは単なるエディタにAIを付加したものではなく、エージェント群を管理する「コントロールプレーン」として設計されています。Cursorは2023年にVS Codeをフォークして市場に参入しましたが、今回のバージョン3ではVS Codeとの差別化を意図的に進めています。同様にGoogleも2025年11月にAntigravityを発表しており、こちらも「Editor View」と「Manager Surface」を分離した2面構成をとっています。2社が独立して同じ結論に至ったことは、エージェント管理インターフェースの必要性が開発者の間で広く認識されていることを示していると考えられます。

　実行層にはClaude CodeとCodexが位置します。Pragmatic Engineerが2026年2月に906名のソフトウェアエンジニアを対象に実施した調査では、Claude Codeが「最も利用されているAIコーディングツール」として46%の支持を集めたとされています。SemiAnalysisの推計によれば、2026年3月時点でGitHubの公開コミットの約4%にClaude Codeが関与しており、年末には20%に達するとする試算もあります。なお、アナリスト推計として年換算売上高が25億ドルを超えるとの報告もありますが、Anthropicは公式には確認していません。一方、OpenAI Codexは同月に週間アクティブユーザーが300万人を超え、1ヶ月前の200万人から急増しています。開発者の間では、Claude Codeが長いコンテキスト窓を活かした複雑な推論に強く、Codexは並列処理スループットで優位とする認識が広まっているとのことです。ただしこの評価を公平に裏付けるベンチマークはまだ存在しないため、あくまで現場の体感として捉えるのが適切だと思います。

　レビュー層は今回のプラグインが初めて実現した層です。Claude Codeがコードを書き、Codexがそれをレビューする構成では、レビュアーは執筆に関与していないため、同一の内部前提を持ちません。記事中の言葉を借りれば「自分の宿題を自分で採点させる」問題を構造的に回避できます。さらにCodexの「review gate」機能を有効にすると、Claude Codeの出力が確定する前に自動でCodexのレビューが走り、問題が見つかれば修正が完了するまで処理をブロックします。OpenAI自身もドキュメントで、この機能が長時間のループを引き起こし使用量を大幅に消費する可能性があると注意書きを加えています。

なぜロックインではなくインターオペラビリティを選んだか

　OpenAIが競合製品であるClaude Code向けのプラグインを公式に提供したことは、一見すると奇妙に映るかもしれません。記事はその経済合理性をこう説明しています。Claude Codeはプロ開発者の間に大きなインストールベースを持つため、その開発者が他社製品に移行するのを待つより、彼らがすでに使う環境にCodexを埋め込む方が効率的です。プラグイン経由で行われるレビューはすべて開発者のChatGPTサブスクリプションまたはAPIキーに課金されるため、OpenAIにとって獲得コストゼロで利用実績を積める構造になっています。

　この動きはAnthropicがMCPベースのオープンなプラグインアーキテクチャを採用したことで可能になりました。プラットフォームとアプリの間に生じがちな緊張関係が、ここではむしろ「両社が利益を得る相互補完関係」に転換しています。

開発者への実践的な示唆

　この構造変化が定着した場合、開発者の働き方には3点の変化が生じると考えられます。

　第一に、モデル選択がインフラ選択に近づきます。Cursor 3の /best-of-n コマンドは、データベース選択やクラウドプロバイダー選択と同様に、ワークロードの特性に応じてモデルを選ぶ考え方を体現しています。Claude・Codex・CursorのComposer 2(オープンソースのKimi K2.5ベース)をコスト感度に応じて使い分ける事例がすでに報告されています。

　第二に、テキストエディタが主役から退く可能性があります。Cursor 3のAgents WindowもGoogleのAntigravityも、「開発者がコードを書いてツールが助ける」という40年来の前提に疑問を投げかけています。エージェントを管理するインターフェースが、コードを書くエディタと同等かそれ以上の重要性を持ちつつあると言えます。

　第三に、レビューが「敵対的」になります。単一モデルによる自己レビューの限界に対し、異なるプロバイダーのモデルが独立した視点でコードを検証するクロスプロバイダーレビューは、CI/CDパイプラインの標準ステップになる可能性があります。

まとめ

　Cursor・Claude Code・Codexはそれぞれオーケストレーション・実行・レビューという異なる役割を担い、競合関係を保ちながら一つのスタックとして機能し始めています。インフラ分野でPrometheus・Grafana・PagerDutyが共存するように、AIコーディングツールも「統合」より「組み合わせ」の方向に向かっていると考えられます。この構造がどこまで定着するかは今後の動向次第ですが、開発者としては特定ツールへの依存より「層ごとに最適なツールを選ぶ」視点を持つことが、実践的な対応になるかもしれません。