「自前エージェントを作らない」設計が標準になる
Zedの Terminal Threads とWarpの Oz はアプローチが異なるが、根は同じだ。Zedは Agent Client Protocol (ACP) を介して Claude Agent / Gemini CLI / Codex を External Agents として同列に扱い、エディタ内のエージェントパネルから呼び分ける。Warpは Universal Agent Support で複数のCLIエージェント (ハーネス) を束ね、Ozがクラウド側で並列実行を統括する。
両者に共通するのは、IDE/ターミナル側が独自のエージェントモデルを抱え込まず、Anthropic や OpenAI のCLIエージェントを差し替え可能なバックエンドとして接続する という設計判断だ。Zed公式ドキュメントの External Agents ページが Claude / Gemini / Codex を並列に列挙していること、Warpブログが「single pane of glass for managing all of your cloud agents」と表現していることが、この役割分担を裏付ける。
競争軸はエージェント本体からUI層へ
この構造変化は調達側に効く。これまでCursorのような統合型AIエディタは「エディタ＋エージェント」を一体で売っていたが、Zed/Warpの路線では エージェントは別契約のCLI、IDEはそれを走らせる器 という分業になる。読者が選定で見るべきは、エージェント性能ではなくIDE側の「呼び出し方式・並列実行・ログ取得・送信先制御」の作り込みだ。
落とし穴: データ送信先が分岐する
外部エージェント統合は便利な反面、コードがAnthropic・OpenAI・Googleと複数ベンダーに分岐して送信されうる。企業導入では、どのエージェントを有効化するかをIDE設定で明示的に絞り、監査ログを取れる構成にしておく必要がある。Zedの Agent Settings やWarpのドキュメントで送信境界を確認することが、PoC前の必須作業になる。
なお元となったX投稿は本文取得が一部不可で、詳細仕様は公式ブログとドキュメントに依拠している。
