エディタ比較を真面目にやった結果、たどり着いたのは「エディタはもうただのコードビューアでいい」でした。CodexのようなCLIエージェントを主戦力にすると、エディタが担っていた仕事は一つずつエージェント側とPR側へ移っていき、差分レビューをPRに寄せた瞬間、ZedかVS Codeかという問いそのものが消滅します。この記事は、その結論に至るまでの比較検証の記録です。
対象読者は、CodexやClaude CodeなどのCLIエージェントを開発の主戦力にし始めて、Cursor・Zed・VS Codeのどれにすべきか迷っている開発者です。持ち帰ってもらいたいのは個別の機能比較ではなく、「エージェントをエディタ統合で使うか、ターミナル運用にするか」「差分レビューをどこでやるか」の2つを先に決めると、エディタ選定は自動的に決まる——多くの場合「どれでもいい」に落ちる——という判断フレームです。
なお、エージェントのサブスクリプション対応や認証まわりは変化の速い領域です。本記事の記述は2026年8月時点の公式情報と検証に基づきます。
Codexをメインにしたら、ファイルツリーがなかった
発端は単純な不便でした。Codexをターミナルで主戦力にすると、CLI単体にはファイルツリーがありません。エージェントが書いたコードを眺める、プロジェクト構造を俯瞰する、たまに自分で1行直す。そのための「置き場」としてのエディタは依然として必要です。
そこで選択肢はZedかVS Codeか。見た目の好みだけならVS Codeでした。ただ、AIエージェント時代のエディタとしてはZedの評判をよく見かけます。乗り換えるだけの理由がZedにあるのか、真面目に調べることにしました。
Zedの本命はACP統合。ただしサブスク事情に非対称がある
ACPで外部エージェントを「挿すだけ」
調べていくと、Zedの強みの本命は個別のAI機能ではなくACP（Agent Client Protocol）統合でした。ZedはACP経由でCodex・Claude Code・Gemini CLIといった外部エージェントを接続できます。Codexは標準対応で、追加のアダプタ設定なしにエージェントパネルから選ぶだけです。
Zed公式ブログ: Codex is Live in ZedFrom the Zed Blog: OpenAI's Codex AI agent is now available in Zed via the Agent Client Protocol (ACP).zed.dev
実際の使い勝手として効きそうな点は3つありました。
- 同一ウィンドウの別スレッドで複数エージェントを並列実行でき、スレッド一覧で俯瞰できる。ターミナルを横に並べる運用だと数に限度があり、俯瞰もしづらいので、ここは明確な差
- 作業ディレクトリ・開いているファイル・シンボル参照が自動でエージェントへ渡る。ターミナル運用で毎回やっている「どのファイルの話か」の指定（@メンション相当）の手間が減る
- Codexの
config.tomlがそのまま設定の源として使われるので、CLI側で育てた設定を持ち込める
エージェントが出した差分をエディタのレビューUIで確認できる点も含めて、「エディタ内でエージェントを回す」体験を作り込むならZedが本命、というのが調査の中間結論でした。
決定的な論点はサブスク対応の非対称
ここで実務上いちばん重要な論点にぶつかります。どのエージェントを、どの課金形態でZedにつなげるかです。2026年8月時点で、CodexとClaude Codeの間には明確な非対称があります。
Codexは、ChatGPTのサブスクリプションでZedから使えます。 経路は3つあり、Zed組み込みエージェントへのChatGPTサインイン、codex-acpアダプタのブラウザOAuth認証、そしてターミナルでのCLI直叩き。いずれもサブスクの範囲で動き、従量課金にしたいときだけAPIキーを持ち込む形です。
Claude Codeは事情が違います。 Zed公式ブログの告知を引用した解説記事によると、「Terminal Threadsが、既存のClaudeサブスクリプションでClaude CodeをZedで使い続ける唯一の方法になった」とされています。断っておくと、私はこの制約を解説記事の引用経由で確認しており、告知原文への直接リンクは張れていません。Terminal ThreadsはZed内のターミナルでCLIを走らせる形で、同記事によれば、スラッシュコマンドやプランモードなどCLIの機能はそのまま使え、~/.claudeの設定・認証もターミナル版と共有されます。一方、ACP統合側の利点であるエディタの差分レビューUIとの密統合はサブスクの対象外で、ACP経由で接続する場合はAPI課金になるとされています。サブスク・課金まわりは特に変化が速い領域なので、導入判断の前にZed公式ブログ・公式ドキュメントの最新情報を必ず確認してください。
なお、Zedのドキュメントは外部エージェントの認証をエージェント側が所有する設計だと説明しています。エディタは認証情報を預からず、各エージェントの認証にそのまま乗る形です（External Agents）。
つまり「Zedに行けばエージェント体験が全部良くなる」わけではなく、手持ちのサブスクとエージェントの組み合わせで、Zedで得られる体験が変わる。Codexメインの私にとってZedのACP統合はサブスクの範囲で使えますが、Claude Codeも同じ土俵に乗せたければ課金形態から考え直しになります。
比較していたはずが、エディタの役割のほうが縮んだ
サブスク事情まで調べ終えたところで、口をついて出たのが冒頭の対話にある一言でした。「まあなら、IDEはただのソースコードをたまに読むだけのツールにならざるを得ないかな」。
エディタの優劣を論じていたはずが、比較を突き詰めた結果、縮んだのはエディタの役割そのものでした。実装はエージェントがやる。コンテキストの受け渡しはエージェント側の仕組みが担う。エディタに残る仕事は、たまにソースを読むこと。そうなると、機能比較表で優劣を付けていた項目の大半が、そもそも自分の運用では使われない機能だと気づきます。
これは負け惜しみの割り切りではなく、順序の話です。エージェント統合を最重視するならZedに行く理由は十分あります。ただ私の場合、Codexとのやり取りはすでにターミナルで完結していて、エディタに求めていたのは実質ファイルツリーと検索だけでした。使っていない機能で比較を続けても、答えは出ません。
最後に残っていたエディタの差は、差分レビュー体験でした。エージェントが出した変更をどこで確認するか。ここでもう一つの割り切りが効きます。差分レビューはPRでいい。
Codexで実装し、PRを作り、GitHub上でレビューする。この運用なら差分確認はブラウザで完結します。レビュー側にAIを挟む選択肢も増えていて、Codexのクラウドレビューや、Claude CodeをGitHub Actionsに載せてPRへ自動レビューコメントを付けさせる構成が知られています（この2つは私はまだ運用に載せておらず、未検証です）。ただ方向性として、実装AIとレビューAIの連携はローカルで直接つなぐよりPRを媒介にしたほうが責任分界がきれいに出る、と私は考えています。実装した本人（実装AI）とは別の目が、成果物（差分）だけを見て判定する形になるからです。
書き手と審査を分ける考え方は、このブログで書いたcriticサブエージェントの構成と同じ発想です。
Claude Codeのサブエージェントで公開前レビューを分離する｜critic実装記録Claude Codeのサブエージェントで、公開前レビューを執筆エージェントから分離した実装記録。読み取り専用のcritic定義、判定基準のファイル固定、PASS/FAILの機械判定、修正2回上限と隔離まで、実際に運用している構成を解説します。www.tentspace.net
こうして、エディタ内レビュー体験という最後の差も消えました。
「AI同士が会話する」の現在地
Zedの並列スレッドに触れたので、エージェント同士の連携についても調べた範囲を書いておきます。Zed自体には、エージェント同士が直接会話する機能はありません。並列スレッドはあくまで人間がハブになる構造です。
一方、MCP経由なら実現できるようです。「Codex Plugin for Claude Code」というOpenAI公式のプラグインが公開されており、Claude CodeからMCP経由でCodex CLIを呼び出してCodexをセカンドオピニオンにする使い方が想定されている、と解説記事が紹介しています。単発の問い合わせだけでなく、codex-replyで同一スレッドへの追質問や論点のすり合わせまで動作したという検証記事もあります。ただし同記事でも、両方のAIに自由編集させるのは危険で、Claude Code主導・Codexは相談役という役割固定が現実的とされています。いずれも私自身はまだ試していない構成なので、ここは調べた範囲の紹介にとどめます。
注意点として、これは「Claude Codeメイン」の向きです。私のような「Codexメイン」の逆向き、つまりCodexからClaude Codeを呼び出す公式プラグインは見当たらず、やるなら自前の工夫が要ります。ここも将来変わりうる部分です。
判断フレームは2問。答え次第で「どれでもいい」に落ちる
最終的な判断フレームはこうなりました。エディタを比較する前に「エージェントをエディタ統合で使うか」「差分レビューをどこでやるか」の2問に答えると、自分の運用が次の3つの分岐のどれかに落ちます。
- エージェントをエディタ統合で使いたい（並列スレッドの俯瞰、差分レビューUIとの統合が欲しい）→ Zedが本命です。ただしサブスク対応の非対称（Codexは可、Claude CodeはACP側だとAPI課金）を先に確認します
- ターミナル運用＋コードは読むだけ → どちらでも可。見た目で選んでよい段階です
- さらに差分レビューをPRへ寄せる → エディタ内レビュー体験という最後の差も消え、あとは見た目の好みの問題になります
分岐を書き出してみると、比較サイトの機能対照表がほぼ要らなくなっているのが分かります。拡張機能の数も、AI補完の賢さも、この分岐のどこにも登場しません。決めるべきは、エディタの機能ではなく自分のワークフローの側です。
私の答えは「ターミナル運用・レビューはPR」だったので、結論はVS Codeで開始でした。残る要件は起動の速さ・検索・読みやすさくらいで、それならVS Codeで困ることは何もありません。「読むだけ」用途なら実はZedの軽さがいちばん活きる構図ではあるのですが、乗り換えの学習コストを払う理由にはなりませんでした。将来、エディタ内で並列エージェントを回したくなったら、そのときZedを再検討すれば十分です。
身も蓋もない結論に見えますが、実務的にはここが要点だと思っています。エージェント主体の開発では、エディタ選定は成果に効く変数ではなくなりつつあります。効くのは、エージェントに何をどう任せるかの設計のほうです。選定で迷っている時間があったら、どちらでもいいので開いて、エージェントに最初の仕事を渡す。**選定の正解は「早く決めて手を動かすこと」**でした。
まとめ
- CLIエージェント主体の開発では、エディタの役割は「たまにソースを読むビューア」に収束する
- Zedの本命はACP統合（並列スレッド俯瞰・コンテキスト自動連携・差分レビューUI）。ただし2026年8月時点で、CodexはChatGPTサブスクで使える一方、Claude Codeのサブスク利用はTerminal Threads限定とされる非対称がある
- 「エディタ統合かターミナル運用か」「差分レビューをどこでやるか」の2問を先に決めれば、エディタ選定はほぼ自動で決まる
- 差分レビューをPRに寄せると、エディタ内レビュー体験の差は消え、選定は見た目の好みの問題になる。レビューAIをPR側に挟む構成とも相性がいい