何が同時に起きたか
Zedは IDE内の Terminal Threadsから Claude Code を呼び出せる統合を公開し、外部 agentとの接続には Agent Client Protocol (ACP) を採用している。ACPは Claude Agent・Gemini CLI・Codexを共通インターフェースで扱う設計で、IDEと agentの結合を protocolで外している。
一方 Warpは Oz という cloud agent orchestration platformを公開し、Claude Code・OpenAI Codex・Warp Agent自身を harness という抽象で横断実行する。docsには Codex with Oz、Warp Agent with Ozなど harness別のページが用意され、同じ taskを別 agentに振り分ける運用が前提になっている。
harness層という新しい競争軸
注目すべきは、両者とも『自社で最強の agentを作る』方向ではなく、『複数の他社 agentを束ねる入口』を取りに行った点である。Zedは OSSエディタ側から ACPで、Warpは商用ターミナル側から Ozで、それぞれ harness層を構築している。
この構造では、Anthropicや OpenAIの coding agentは交換可能なバックエンドとして扱われる。読者の調達判断は『Claude Codeか Codexか』の二者択一ではなく、『どの harness上で両方を走らせ、taskごとに切り替えるか』という二層構造に変わる。
落とし穴: 二層化した調達
単一 agent導入の感覚で harnessを選ぶと、ログ保持・権限境界・課金が harness側と agent側の二箇所に分散する。Zed (ACP) と Warp (Oz) では権限モデルも cloud実行の有無も異なるため、PoC段階で『同じ repoに同じ taskを投げて、どちらの harnessが介入回数と復旧時間で優位か』を実測する以外に判断材料がない。agent単体ベンチマークだけでは harness込みの運用コストは見えない。
