なぜ Zed エディタを使い始めたのか

Zed のチームが前に作っていたのは Atom です。

Atom は Chromium の fork で、その開発過程からついでに生まれたのが Electron でした。つまり後の VS Code の土台です。悪く言えば、VS Code が立っているその土地を掘ったのはこの人たち自身で、彼らは今その隣に、その土台を使わない家を建てたことになります。

Zed の 1.0 が出たのは 2026 年 4 月 29 日。五年かけて、百万行を超える Rust です。

私が VS Code から移った理由はそこまで詩的ではありません。ある日サーバーを 96°C まで焼いてしまい、そのあとで、これが自分のマシンに何を置いていたのかを測ってみただけです。

まず請求書を見る#

ローカル側、どちらもプロジェクトを一つ開いた状態で:

サーバー側の差はもっと大きくなります。リモート開発は接続先のマシンに自分のランタイムを置いていくもので、VS Code のそれはこうなっていました。

7.9 GB 対 107 MB。七十倍です。

VS Code の 7.9 GB を分解すると cli 3.2 GB、bin 2.9 GB、extensions 945 MB、data 412 MB。しかもその中にはrust-analyzer 拡張が二つのバージョンで並んで居座っていて、古いほうは誰にも掃除されていませんでした。

正直この数字だけで試してみる気になりましたし、実際の使用感もそれに見合っています。スクロール、ファイルを開く、検索、タブの切り替えがどれも即時で、あの「少し考えさせて」という引っかかりがありません。

公式の引っ越し手順がある#

これは後から知ったことですが、Zed には How to Migrate from VS Code to Zed という公式ドキュメントが一ページ丸ごとあり、初回起動のセットアップウィザードが VS Code の設定を取り込むか、どの AI と繋ぐかを聞いてきます。

ウィザードを飛ばしてもコマンドパレットから呼べます。

何を持ってきて、何を持ってこないか#

公式に対応表があります。いくつか抜粋すると:

タブ、ファイルエクスプローラ、Git、ターミナル、フォント、そしてエディタの設定の大半をカバーしています。

ただし拡張は持ってきませんし、キーバインドも持ってきません。 この二つは自分でやることになります。

キーマップ:デフォルトですでに VS Code#

base_keymap のデフォルト値がそもそも VS Code なので、何もしなくて構いません。確認したい、あるいは別のものに変えたいなら:

{ "base_keymap": "VSCode" }

選べるのは VS Code、Atom、Emacs(Beta)、JetBrains、Sublime Text、TextMate、Cursor、そして None。設定ウィンドウからも選べますし、コマンドパレットの zed: toggle base keymap selector でも切り替えられます。

日常的に一番押すものは完全に同じです。Ctrl + Shift + E でファイル一覧、Ctrl + Shift + G で Git。指の再訓練は要りません。

公式には「VS Code キーマップを選んでも違うもの」の一覧がありますが、その表は macOS 表記で書かれていて、しかも二つの列でプラットフォームが揃っていません。そのまま写すと混乱します。

Windows と Linux では Cmd を Ctrl に読み替えます。Zed のキーマップ定義にはまさにこのための secondary- という修飾キーがあります。実際に調べるなら、リポジトリにあるプラットフォームごとのデフォルトキーマップを見るほうが確実です。

もっと手軽なのは内蔵の Keymap Editor(Ctrl + K のあと Ctrl + S)で、全アクションと現在の割り当てが一覧でき、その場で変更できます。そこで行った変更は keymap.json に書き戻されます。

拡張 23 個が、移行後は 8 個#

この移行で一番手応えがあったのがここです。VS Code には拡張を 23 個入れていましたが、Zed に移って実際に「インストール」が必要だったのは 8 個だけでした。

機能が減ったからではありません。分類の切り方が違うからです。

basedpyright   bash-language-server   eslint   json-language-server
package-version-server   ruff   rust-analyzer   tailwindcss-language-server
vscode-css-language-server   vtsls   yaml-language-server

公式はこの点をかなり率直に書いていて、しかも私が失ったものにそのまま当たっています。

Zed does not offer as many extensions as VS Code. You won't find one-to-one replacements for every VS Code extension, especially if you rely on tools for DevOps, containers, or test runners.

逆方向として、「VS Code では拡張が要るが Zed では内蔵」のものも挙げられています。リアルタイム共同編集(Live Share 不要)、AI 支援、ターミナルパネル、プロジェクト全体のあいまい検索、タスクランナー、LSP による診断。

設定:GUI があり、しかも思っていたより完成度が高い#

Zed は JSON でしか設定できないと思い込んでいて、この記事を書いている途中で違うと気づきました。Ctrl + , で開くのは検索ボックス、カテゴリ、トグル、ドロップダウンを備えた完全な設定ウィンドウです。

カテゴリは十五。そして各項目の横に「Edit in settings.json」があり、そのまま生ファイルへ飛べます。GUI と JSON は同じ設定への二つの入口で、二者択一ではありません。

ファイルを直接編集したいなら、コマンドパレットの zed: open settings file、あるいは Ctrl + Alt + , です。

プロジェクト単位の設定はかなり少ない#

これは実際に使っていて必ずぶつかる制約です。設定ウィンドウの上部でスコープを切り替えられますが、プロジェクト側に切り替えるとカテゴリが十五から五に落ちます。

プロジェクト設定はプロジェクト内の .zed/settings.json に置かれ、そこに書けるのはエディタの挙動と言語ツール系だけです(tab_size、formatter、format_on_save など)。

なので「このプロジェクトだけ auto_fold_dirs を切りたい」「ここだけ Auto Reveal を切りたい」といった要求は、今のところグローバルでしか変えられません。VS Code のヘビーユーザーである同僚が最初にぶつかったのがこれでした。

パネルの位置#

ついでに書いておくと、パネルを反対側へ移すのに設定を開く必要はありません。パネルのアイコンを右クリックすれば出てきます。

settings.json で各パネルの dock を固定することもできて、私はそうしています。

私の設定、そのまま持っていってください#

レイアウトと配色が気に入ったなら、丸ごと持っていって編集してください。リモート接続の部分は抜いて、コメントのテンプレートにしてあります。

{
  // base_keymap はデフォルトで VSCode。この行は明示しているだけ
  "base_keymap": "VSCode",

  // CLI からファイルを開くとき、新規ウィンドウではなく既存のものを使う
  "cli_default_open_behavior": "existing_window",

  // リモート接続(host は ~/.ssh/config のエイリアス)
  // "ssh_connections": [
  //   {
  //     "host": "my-server",
  //     "args": [],
  //     "projects": [
  //       { "paths": ["/home/you/projectA"] },
  //       { "paths": ["/home/you/projectB"] }
  //     ]
  //   }
  // ],

  // パネルの位置
  "project_panel": { "dock": "left" },
  "git_panel": { "tree_view": true, "dock": "left" },
  "collaboration_panel": { "dock": "left" },
  "outline_panel": { "dock": "right" },
  "agent": { "sidebar_side": "right", "dock": "right" },

  // 外部 agent(次の節で説明します)
  "agent_servers": {
    "claude-acp": {
      "type": "registry",
      "default_config_options": { "fast": false }
    }
  },

  // 外観
  "theme": {
    "mode": "dark",
    "light": "Gruvbox Light",
    "dark": "Catppuccin Macchiato - No Italics"
  },
  "icon_theme": {
    "mode": "dark",
    "light": "Zed (Default)",
    "dark": "Material Icon Theme"
  },
  "ui_font_size": 16,
  "buffer_font_size": 15,
  "minimap": { "show": "always" },

  "telemetry": {
    "diagnostics": true,
    "metrics": false,
    "anthropic_retention": false
  },

  // リモートプロジェクトを開くたびに信頼確認が出るのは面倒だが、
  // これは全 worktree を無条件に信頼する意味になる。各自で判断のこと
  "session": { "trust_all_worktrees": true }
}

二点だけ補足すると、telemetry.metrics は切ってあります。session.trust_all_worktrees は便利ですが、その確認手順を放棄することでもあるので、そこは自分で天秤にかけてください。

インターフェースの違い#

VS Code はあちこちにボタンがあります。たとえばファイルエクスプローラのヘッダにある、新規ファイル・新規フォルダ・更新・すべて折りたたむの列。

Zed は逆方向で、ほとんどの操作はコマンドパレットと右クリックにあります。最初は何かが足りない気がしますが、慣れると手がキーボードから離れなくなります。

正直なところ、この移行で一番大きなコストがこれでした。機能ではなく、習慣です。 実際の機能差はごく少数(後述)で、最初の二日間の違和感はほぼ全部、筋肉記憶が追いついていないだけでした。

リモート開発#

私にとってはここが出発点なので、少し詳しく書きます。

リモートのプロジェクトは設定ファイルの ssh_connections に直接書きます。host は ~/.ssh/config のエイリアスなので、鍵も踏み台も Port も SSH 側の仕事で、Zed が別系統を持つことはありません。

コールドスタートからコードを書き始めるまで:

初回接続でリモートサーバーを送り込み(先ほどの 107 MB がそれです)、以降そのプロセスは常駐するので再接続は速くなります。うちのマシンのリモートサーバープロセスは七日間連続で上がりっぱなしです。

切断が VS Code よりかなり安定している#

これは予期していなかった収穫でした。VS Code Remote-SSH は回線品質が悪いとき頻繁に再接続とウィンドウの再読み込みが必要になり、ときどき「Reconnecting...」のまま止まります。同じネットワーク環境で、Zed は再接続に失敗する回数が明らかに少なく、たいていは気づかないうちに繋がり直しています。

同じウィンドウでリモートプロジェクトを切り替える#

これは VS Code にありません。 VS Code で二つ目のリモートプロジェクトを開くと二つ目のウィンドウになり、ウィンドウとタブがどんどん積み上がります。Zed は同じウィンドウ内で入れ替えられるので、視覚的にかなり整理されます。ここは自分でも思った以上に気に入りました。

内蔵の Git が予想より完成している#

GitLens の代替を探すことになると思っていましたが、要りませんでした。Git パネルはツリー表示に切り替えられて、コミット履歴も diff もエディタの中で完結します。

インライン blame も内蔵で、ホバーするとカードが出ます。

Markdown プレビューが mermaid を描画する#

これは最初に心配した点です。記事を書くときに mermaid を多用していて、VS Code 側では拡張で支えていたからです。結果として Zed の内蔵プレビューはそのまま描いてくれました。

ACP:agent をエディタから切り出す#

これは移ってから初めて触れたもので、この記事で一番書きたかった部分でもあります。

ACP の立ち位置ははっきりしています。

LSP は「言語の知性」を IDE から切り出した。ACP は agent に対して同じことをやろうとしている。

LSP 以前は、どのエディタも各言語の補完や定義ジャンプを自前で実装する必要がありました。LSP 以降は、言語側が一度サーバーを書けばすべてのエディタが使えます。ACP が狙っているのはまったく同じ形の問題です。今はどの AI agent もエディタごとにプラグインを書く必要があり、ACP はそれを一度で済むようにします。

JetBrains、Google、GitHub がすでに参加していて、レジストリには二十五を超える agent があります。Zed の初回セットアップウィザードは、どこと繋ぐかを聞いてきます。

見た目はこうなります#

設定に agent server を足すと、サイドバーに agent が現れます。

右下の列に注目してください。Opus (1M context)、High、Fast mode。

この列こそが要点で、ACP の分担を説明しています。 公式ドキュメントはこう書いています。

Zed hosts the thread in the Agent Panel, while the External Agent usually owns its own runtime, auth, model selection, tools, and native configuration.

つまりモデル選択、認証、ツール、設定はすべて agent 側のもので、Zed が貸しているのはインターフェースだけです。スレッドの表示、複数ファイル編集、プロジェクトの文脈、diff レビュー。

私の最初の疑問は「agent panel 経由と CLI 直接では、モデルが違うのか」でした。いくら調べても答えが出ず、後になって気づきます。その問い自体が間違っている、と。ACP はモデルにまったく触れていません。どちらも同じものを動かしています。

過去の会話を取り込める#

これは少し奥まったところにありますが便利です。Ctrl + Alt + J で Threads Sidebar を開き、Ctrl + G(または左下の時計アイコン)で Thread History を開きます。

その中に Import Threads ボタンがあります。

取り込む agent を選ぶと、Zed が ACP 経由でその agent がローカルに残した過去のセッションを取りに行き、履歴へ追加してくれます。取り込まれたものはアーカイブ状態なので、開けばそのまま続きから話せます。すでに履歴にあるものは自動でスキップされるため、重複して取り込んでも安全です。

Terminal Threads:実はどちらかを選ぶ必要がない#

「ネイティブの agent panel を使う」と「ターミナルで CLI を回す」は二者択一だと思い込んでいましたが、Zed はすでにこれを解決していました。

Terminal Threads を使うと、Agent Panel の + メニューから Terminal を選べます。開いたターミナルは Threads Sidebar の中の一つのスレッドになります。そこで claude でも amp でも codex でも好きなものを回せますし、サイドバーのタイトルは動いているプログラムに合わせて自動で更新されます。

Zed 自身の agent スレッドや ACP スレッドと自由に混在させられて、キーボード操作も通知もまったく同じです。つまりCLI 本来の環境と利用枠を保ったまま、Zed のインターフェースを得られるわけです。

それでも CLI は普通のターミナルに置いている#

理由は一つだけです。

/rc(remote control)は CLI にしかない。

差は機能の多寡ではなく、セッションを誰が持っているかです。

私はセッションを開くたびに自動で /rc が走るようにしています。どこにいても Claude Desktop でタブを一つ開けば同じセッションを引き継げて、向こうのマシンで Zed が起動している必要すらありません。

動画の Resume session (2 of 27) という選択画面がまさにこの仕組みで、セッションはエディタから独立して存在している、エディタはその入口の一つにすぎない、ということです。

言い換えると、私はより統合されたインターフェースを捨てて、どのマシンにも縛られないことを取りました。マシンをまたぐ必要がないなら、agent panel でも Terminal Threads でもそちらのほうが快適なので、止めはしません。

足りないもの#

この節は移行を検討している人向けです。自分でぶつかったものと、調べて出てきたものを合わせるとこのあたりになります。

逆に、Dev Container は 2026 年 1 月にサポートされました。ネット上の比較的古い Zed のレビューはこれを欠点として挙げがちですが、その項目はもう消せます。そしてそれが次の節の話でもあります。

繁体字中国語のコミュニティ版#

公式は着手する気配がありませんが、コミュニティには zed-i18n があります。

ただし無痛ではありません。いくつかの機能が失われますし、追加の設定も必要です。 同僚が Windows 11 の右クリックメニュー周りでハマった記録を書いているので、入れるなら先に読んでおくことを勧めます。

ただしこのリストの賞味期限は短い#

上に挙げた欠落について、私はあまり心配していません。理由は時間軸です。

Zed がオープンソースになってまだ数年で、1.0 は 2026 年 4 月 29 日に出たばかりです。五年の開発、百万行を超える Rust。今はほぼ毎週のように新バージョンが出ていて、この記事を書いている最中にも「調べたときは無いと書かれていたのに、実際に開いたらあった」に二度ぶつかりました。設定 GUI が一度、Terminal Threads がもう一度。Dev Container も今年一月に追加されたものです。

そこまで速く動ける理由は土台にあります。Zed のチームは 1.0 の記事でその経緯をはっきり書いています。

Atom は Chromium の fork であり、その過程で Electron を生み、Electron は後に VS Code の土台になった。ウェブ技術は出荷を容易にしたが、同時に天井も設けた —— どれだけ努力しても、Atom を、それが乗っているプラットフォームより良くすることはできなかった。

そこで彼らはやり直し、エディタ全体をビデオゲームのように書きました。データを GPU 上のシェーダに流し込み、UI フレームワークの GPUI も自前でゼロから彫っています。冒頭の「4 GB 対 200 MB」は最適化で削り出した数字ではなく、最初からその荷物を背負っていないというだけの話です。

Rust 開発者に特に優しい#

ここは私見です。自分が Rust を書くので入れました。

Zed はそれ自体が Rust で書かれていて、チームは自分たちのヘビーユーザーでもあります。ただしはっきりさせておくと、以下はRust 専用の作り込みではなく、LSP 経路全体に対する工学です。rust-analyzer が重いことで有名なので、たまたま一番恩恵を受けているだけです。

なので結論は正確にこう言うべきです。rust-analyzer は速くなっていないし、メモリも相変わらず食う。 変わったのは、その隣にいるエディタが余分な負担ではなくなったことで、リモート開発においてはそれが差のすべてになります。

万物は Rust でよい。今回は異論ありません。

VS Code は消していません#

ここまで書くと販促のように読めるので、はっきり言っておきます。この記事は確かに Zed 寄りです。 あのリソースの数字は説得力がありすぎますし、実際に使っても本当に快適だからです。

ただし両方残していて、場面で分けています。

• 自宅で LAN 経由 —— VS Code Remote-SSH。同一セグメントで遅延が低く、拡張も慣れた UI もそのまま。しかもマシンのすぐ横にいるので、燃え始めても見えますし止められます。
• 外から長時間繋ぐとき —— Zed と Claude CLI。リモートの遅延は VS Code をかなり使いにくくしますし、前の記事でサーバーを 96°C まで焼いた三つの犯人はどれも「繋いでいるうちに勝手に燃えてくる」タイプです。その場にいないのが最悪の状況になります。

こう分けているのは、この二つのツールはコスト構造が違い、そして自分にはたまたま性質の違う二つの使い方があるからです。

移るべきかどうかについての私の見方はこうです。VS Code に深く縛られていないなら、障害は機能ではなく習慣です。 私はヘビーユーザーではなく、特定の拡張に依存したワークフローも持っていないので、移行はほとんど痛みなく済みました。ただ毎日 File Nesting を使う、データベースを開く、プロジェクトごとに設定を細かく変える —— そういう使い方をしているなら、今の Zed はまだ受け止めきれません。

この移行の最大の収穫を挙げるなら、節約できた数 GB ではありません。23 個の拡張を全部見直すことを強制されたことです。うち五個は Python エコシステムの重複した積み重ねで、二個は同じ拡張の別バージョンが掃除されずに残ったもの、そしていくつかはなぜ入れたのかすら思い出せませんでした。この棚卸しは普段やりません。ツールを変えるときにだけ、強制的にやることになります。