Zedエディタがバージョン1.0をリリースした。ほとんどのメディア報道は「バージョン番号」に焦点を当てるが、本当のストーリーはそれとは全く異なる——Zed 1.0はACP（Agent Communication Protocol）を通じて、エディタをコード編集ツールから全Code Agentの統一オーケストレーションセンターに変えた。
何が起こったか
Zed 1.0のコア変更は3つのポイントにまとめられる：
1. ACPプロトコルネイティブサポート：エディタ内で直接Claude Agent、Codex CLI、OpenCode、Cursor CLI、Gemini CLIを起動——Kimi CLIやQoder CLIなどの国産ツールもすでにサポートリストに含まれている。これらのAgentはもはやVSCodeプラグインやターミナルウィンドウで個別に戦う必要がない——Zed内で同じコンテキスト認識レイヤーを共有する。
2. 並行Agentワークマネージャー：複数のAgentインスタンスを同時に起動でき、それぞれが異なるタスク（バグ修正、テスト作成、リファクタリング）を処理し、ZedのACPパネルがすべてのAgentの進捗を集約し、タスク完了時に通知する。これは「マルチAgentコラボレーション」が初めてエディタレベルでネイティブサポートされたことを意味する。
3. セッション履歴インポート：Zedは他のツールからのセッション履歴インポートをサポートしており、開発者がツールを切り替える際にコンテキストを失うことがなくなる。
なぜACPは「プラグインをたくさん入れる」より重要なのか
現在のAIエディタの普遍的な課題：各Agentが島になっている。
Claude Codeには独自のCLAUDE.md設定があり、Codexには独自の設定があり、Cursorには独自のAgentモードがある。Agent間で切り替えたい場合、再設定、コンテキストの再構築、プロジェクト理解のための再教育が必要になる。
ACPのアプローチは、Agentをプラグイン可能なプロセス層として標準化するものだ。
| 機能 | 従来のVSCodeプラグインモデル | Zed ACPモデル |
|---|---|---|
| Agent起動 | 各プラグイン独立プロセス | 統一ACPプロセス管理 |
| コンテキスト共有 | プラグイン間通信不可 | ACPプロトコル経由で共有 |
| 通知 | 各プラグイン独自のUI | 統一ACP通知パネル |
| セッション移行 | 不可能 | 他のツールの履歴インポート対応 |
| 並行実行 | 手動ターミナル切替が必要 | ネイティブ並行Agentワークマネージャー |
業界動向
Zed 1.0のリリースは、AIエディタ競争の新段階を告げている：
- Cursorの堀は「AIネイティブエディタ」ブランドだが、主にClaudeエコシステムに依存
- VSCode + プラグインはエコシステムの広さで勝るが、Agent体験は断片化
- Zedの戦略は「Agentを作らない、Agentのゲートウェイを作る」——より賢いポジショニング
エディタが同時にClaude、Codex、Kimi、Qoderをディスパッチできるなら、開発者が単一のAgentベンダーにロックインされる理由はない。ZedはAgent時代の「ユニバーサルリモコン」になりつつある。