Eclipse から Zed へ：ある開発者のエディタ進化史

ありふれた仕事の日でした。

3つのプロジェクトを同時に進めていました——Next.js のフロントエンド、FastAPI のバックエンド、そして Flutter のモバイルアプリ。VS Code は5つのウィンドウを開き、Chrome がさらに大量のメモリを食いつぶしています。ファンが唸り始め、マウスがカクつき始め、イライラが募ります。

「たかがテキストエディタが、なぜ 3GB もメモリを食うんだ？」

その瞬間、自分の開発ツールを見直す時が来たと気づきました。

振り返ってみると、最初のコードを書いた時から今まで、エディタは何度も乗り換えてきました。一回一回の切り替えは、単にソフトを変えるだけではなく、ワークフロー全体が変わることを意味していました。

Java 時代：Eclipse → IntelliJ IDEA

私のプログラミング人生は Java から始まりました。Microsoft の同期機能のおかげで、数年前の学習ノートもまだ見つけることができます。

プログラミングを学び始めた頃、Eclipse は Java 開発のほぼ標準装備でした。正直なところ、Eclipse の機能は一通り揃っていましたが、あの時代の Eclipse には独特の「重さ」がありました——起動が遅い、UIが野暮ったい、プラグインはすぐに競合する。Eclipse を開くたびに、小型サーバーを起動しているような気分でした。

その後、自分であれこれ試しているうちに、IntelliJ IDEA を見つけました。

初めて開いた時、思わず目を見張りました。コード補完がこんなに賢いの？リファクタリングがこんなにスムーズなの？以前 Eclipse で十数ファイルを手動で修正していたリファクタリング操作が、IntelliJ ではショートカットキー一つで完了しました。

その感覚は、Nokia から iPhone に乗り換えた時のようでした。

とはいえ、正直 Java はそれほど長く学ばないうちに Python に転向しました。でも IntelliJ の体験は JetBrains に対する好印象を残し、その後自然とファミリー全体に広がっていきました。フロントエンドは WebStorm、Python は PyCharm、データベースは DataGrip。各 IDE にはそれぞれの言語に特化した深い最適化があり、本当に快適でした。後に VS Code に移行してからも、これらの JetBrains 製品はずっとパソコンに入れたままにしていました。ほとんど開かないのに、削除する気にはなれませんでした。

フルスタックへの道

転機は、フルスタック開発を始めた時に訪れました。

フルスタックとは、すべてを少しずつ知っていなければならないということです。バックエンドで Python を書き、フロントエンドで Vue と React を学び、モバイルで Flutter を触り、たまに Shell スクリプトを書き、それに加えて Docker や各種設定ファイルなど雑多なものが山ほどあります。言語が増えるにつれて、ツールを変えるべきかと考え始めました。もちろん、IntelliJ IDEA 自体もプラグインで多くの言語をサポートできますが、やはり重すぎます。それに個人的には、ブロックを積み上げるように、自分で少しずつ開発環境を構築していく感覚が好きで、あらかじめ全部揃った IDE を使うのとは違うのです。

「汎用型」のエディタが必要でした。

VS Code を見つける前に、他のものも試しました。

Sublime Text をダウンロードして使ってみましたが、確かに速い。でも中身があまりにもシンプルすぎました。唯一の利点は速さだけで、他の面では JetBrains との差が大きすぎます。Notepad++ も見ましたが、あれはただの高機能メモ帳であって、私が求めている開発ツールではありませんでした。

VS Code の黄金時代

VS Code の登場が、私の問題を完璧に解決してくれました。

一つのエディタに様々なプラグインをインストールするだけで、すべての言語に対応できます。Python には Pylance、Flutter には Dart プラグイン、Vue には Volar——すべてが一つのウィンドウで完結します。

そして、長い「カスタマイズ」の旅が始まりました。

テーマは10回以上変え、アイコンパックも何セットも試し、ショートカットキーは設定しては変更、変更しては再設定。コードスニペット、Git プラグイン、Docker プラグイン、各種 Linter と Formatter......気づけば、200以上のプラグインがインストールされていました。

あの頃は、VS Code のカスタマイズそのものが楽しみでした。コミュニティやフォーラムで便利なプラグインを探し回り、一つ見つけるたびに「お宝を発見した」ような興奮がありました。正直に言って、プラグインマーケットは本当に豊富で、どれも確実に生産性を向上させてくれます——Python の開発環境プラグインだけでも、10個以上はインストールしていたかもしれません。もちろん、vscode-pets のようなユニークなプラグインもありました。エディタの中で小さなペットを飼うというもので、生産性とは全く無関係ですが、つい入れてしまうのです。

すべての作業を VS Code に集約するために、データベースプラグインの有料会員まで購入しました——Database Client です。VS Code 内で直接各種データベースに接続し、データのプレビューや操作ができる、とても便利なプラグインです。これを導入してからは、DataGrip を開く必要すらなくなりました。

今でもさまざまなプラグインをいじり続けています。このカスタマイズ作業自体が楽しみの一部なのです。

あれは VS Code の黄金時代でした。正確に言えば、ツールいじりの効率が最も高かった時期でもありました。

AI プログラミング時代の到来

私が最初に AI プログラミングに触れたのは、GitHub Copilot を通じてでした。

移動

当時の Copilot にはまだ Chat 機能がなく、コードを書いている時に、次に何を書くかをそっと提案してくれるだけでした。コメントを一つ書くと、自動的にコードの一段落全体を補完してくれます。初めて見た時は本当に驚きでした——こいつは私が何を書きたいか、どうしてわかるんだ？

もちろん、今振り返ると、これらはすでに AI プログラミングの基本機能になっています。

移動

その後、Cursor が話題になりました。正直に言うと、私は参入が少し遅れました。当時は Copilot の学生パックを無料で使えていましたし、Cursor は本質的に VS Code の Fork であり、GitHub Copilot こそが本当の意味で最初に AI プログラミングに取り組んだものだったので、Copilot が最高だと思い続けており、乗り換える動機がありませんでした。

同僚に Cursor を試してみなよと勧められるまでは。

ダウンロードして使ってみると、VS Code 内の Copilot よりはるかに強力だとわかりました。インタラクション全体がよりスムーズで、AI のコンテキスト理解もより深い。Copilot がなぜあのような出来になったのか、本当に理解できません——明らかに先発だったのに、体験では後発に引き離されてしまいました。

さらにその後、Claude Code が登場しました。

移動

Claude Code を使ってコードを書き始めた時、すべてがまた変わりました。以前のコーディングフローは：エディタで書く → ターミナルで実行する → エディタで修正する、でした。今は：ターミナルで AI に何が欲しいか伝える → AI が書く → レビューする、に変わりました。

ターミナルの使用頻度が急増しました。

以前、ターミナルは npm run dev や git push を実行するだけの場所でしたが、今やメインのプログラミングインターフェースになりました。ほとんどの時間を Claude Code との対話に費やし、コードを書いてもらい、バグを直してもらい、リファクタリングをしてもらっています。エディタはむしろ二番手に退き、「コードを見る」ためのツールになりました。

同時に、AI がプログラミングのスピードを上げたことで、同時に進めるプロジェクトの数も増えていきました。以前は月に1つのプロジェクトでしたが、今は3〜4つを同時並行で進めることもあります。

これが直接、次の問題を引き起こしました。

VS Code が耐えられなくなった

複数プロジェクトの同時開発 + 200以上のプラグイン = 災害。

VS Code のウィンドウを一つ増やすたびに、数百MBのメモリが追加で消費されます。5つのウィンドウを開くと、簡単に 3GB を突破します。MacBook のファンが全力で回り始め、UIがカクつき始め、タイピングにも遅延を感じるようになりました。

これは私だけの問題ではありません。ネットで "VS Code high memory usage" と検索すると、大量の同様の不満が見つかります。Electron アーキテクチャ + 大量のプラグイン + 複数ウィンドウでは、メモリの爆発はほぼ必然です。

さまざまな最適化方法を試しました——使っていないプラグインの無効化、Profile 機能でプロジェクトごとに異なるプラグインセットをロード、バックグラウンドプロセスの制限。改善はしましたが、根本的な解決にはなりませんでした。

結局のところ、VS Code は Electron ベースのアプリケーションです。Electron ということは、各ウィンドウが完全な Chromium インスタンスを実行しているということです。5つのウィンドウを開けば、Chrome を5つ開いているのと同じことです。

ターミナルこそ王道：Warp との出会い

プログラミング作業のほとんどがすでにターミナルで行われているなら、ターミナル自体が使いやすくなければなりません。

macOS 標準の Terminal はあまりにもシンプルすぎ、iTerm2 は長く使ってきましたが少し古臭さを感じていました。そんな時、Warp を見つけました。

移動

Warp の第一印象は、とにかく速いということでした。起動が速い、レンダリングが速い、レスポンスが速い。そして Block のデザイン——各コマンドとその出力が独立した「ブロック」を形成し、テキストエディタのように選択、コピー、検索ができます。

日常的に使っていると、もう戻れません。いくつかの細かいポイントを挙げると：

入力欄は本物のエディタで、マルチカーソル、シンタックスハイライト、自動補完をサポートしています。以前、ターミナルで長いコマンドを打ち間違えた時は、矢印キーで少しずつ移動する必要がありましたが、今はマウスで間違った箇所をクリックして修正するだけ——当たり前に聞こえますが、従来のターミナルではできなかったことです。

各 Block の右上にある小さなボタンで、出力全体をワンクリックでコピーできます。以前はターミナル内のテキストを選択するために、マウスを非常に正確にドラッグする必要があり、少しでもずれると多すぎたり少なすぎたりしていました。今はその心配が全く不要です。

ヘビーなターミナルユーザーにとって、これらの体験の向上は非常に大きいものです。

この段階で、私のワークフローはこうなりました：90% の時間は Warp ターミナルで Claude Code を使ってプログラミングし、VS Code は Git 履歴を確認する必要がある時だけ開く——主に GitLens で誰がいつ何のコードを変更したかを見るためです。

Zed との出会い

問題は、VS Code はコードを見るためだけに使っても、メモリ消費は一向に減らないということです。

ある日、Twitter を見ていた時に Zed を見かけました。クリックして見ると——"A high-performance, multiplayer code editor from the creators of Atom and Tree-sitter"。創設チームは Atom エディタのオリジナル作者で、これには興味を引かれました。

ダウンロード、インストール、起動。

速い。非常に速い。

「なんとなく速くなった気がする」という程度の速さではなく、「これこそエディタあるべき速度だ」という速さです。起動、ファイルを開く、検索、ジャンプ、すべての操作が一瞬で完了します。

具体的にどれくらい速いのか？ネット上にはパフォーマンス比較データが多数あります：

データ出典：Zed vs VS Code Performance Benchmark (2024)

Zed は Rust で書かれており、ネイティブ GPU レンダリングで、Electron のようなオーバーヘッドがありません。そのため、十数個のプロジェクトを同時に開いても、メモリの合計が VS Code の1ウィンドウ分にも満たないのです。

さらに Zed は最近、macOS ネイティブウィンドウタブのサポートを追加しました。複数のプロジェクトウィンドウを一つのウィンドウに統合し、タブで切り替えることができます。私のように十数個のプロジェクトを同時に開く人間にとって、デスクトップがウィンドウで溢れなくなったのは本当にありがたいです。この機能はコミュニティからの要望が長く続いていたもので、ようやく実現しました。

有効にする方法はシンプルで、Zed の settings に "use_system_window_tabs": true の一行を追加するだけです。再起動は不要で、次に開くウィンドウから自動的に新しい動作が適用されます。macOS のシステム環境設定のタブ動作（常に / しない / フルスクリーン時）にも自動的に追従し、システムと一貫性を保ちます。

もちろん、正直に言うと、Zed にも不足な点はあります。最も目立つのはプラグインエコシステム——まだ若く、VS Code で当たり前に使っていた多くのプラグインが Zed では見つかりません。GitLens レベルの Git 可視化ツールはなく、一部の言語サポートもまだ十分ではありません。

しかし私にとっては、これらは致命的な問題ではありません。なぜなら、今のエディタに対する核心的なニーズは2つだけだからです：コードを読むことと軽い編集。重い作業はすべて Claude Code にターミナルで任せています。

今の私のワークフロー

この道のりを経て、現在の開発ツールの組み合わせはこうなっています：

Zed + Claude Code —— メインの開発ツール。Zed で十数個のプロジェクトを同時に開いても全く問題なく、コードの閲覧、小さな修正、定義へのジャンプに使っています。Claude Code も Zed の内蔵ターミナルで直接実行し、コード作成、バグ修正、リファクタリングまで、基本的にすべて一つのウィンドウ内で完結します。

Warp —— ターミナルが本来あるべき役割に戻りました。ただし、このターミナルは今まで使ったどのターミナルよりもはるかに使いやすく、真の意味でのモダンターミナルです。なぜ各 OS に標準搭載されているターミナルが、いまだに何十年も前のままなのか、全く理解できません。もちろん、時には Warp で直接 Claude Code を起動して作業することもあります。ファイルパネルや Git 表示が組み込まれているので、使い勝手も良いです。

VS Code —— たまにゲスト出演。主に GitLens で Git グラフを見る時に使います。正直なところ、使用頻度はどんどん下がっています。

それぞれが適材適所。Zed が「読む」と「書く」、Warp が日常コマンド、VS Code が「調べる」を担当しています。

このワークフローの核心的なロジックは：エディタの軽量化、ターミナルのヘビー化です。AI 時代、本当のプログラミングはターミナルで行われます。エディタに求められるのは、快適にコードを読み、素早く修正できることだけです。

Claude Code を使っている方には、「私の Claude Code ベストプラクティス」で効率的な使い方のコツを、「私の Claude Code 品質管理フロー」で AI 生成コードの品質を確保する方法をご覧いただくことをお勧めします。Claude Code の背後にある設計を深く理解したい方は、「Claude システムアーキテクチャ徹底解説」をご覧ください。

おわりに

このエディタ進化の道のりを振り返ります：

Eclipse → IntelliJ IDEA → JetBrains ファミリー → Sublime Text（通りすがり）→ VS Code + Copilot → Cursor → Claude Code + Zed + ターミナル

乗り換えのたびに、古いツールが悪くなったからではなく、自分の働き方が変わったからでした。

Java を書いていた時は、IntelliJ が最適解でした。フルスタックのマルチ言語開発の時は、VS Code が最適解でした。AI 時代のターミナルファーストの今日、Zed + Warp が最適解です。

永遠に最高のエディタなどありません。あるのは、今のワークフローに最も適したエディタだけです。

もし今、「まあこれでいいか」と感じるエディタを使っているなら、自分に問いかけてみてください：自分の働き方はもう変わっているのに、ツールはまだ追いついていないのではないか？

ツールは人のためにあるものです。ツールが足を引っ張り始めたら、それが変え時です。