LabHub

ブログ

エディタウォーズ 2026 — VS Code、Cursor、Zed、Neovim、Helix、Sublime、JetBrains、そして Claude Code

한국어English日本語

プロローグ — 2026年、エディタは再び面白くなった

10年前、エディタ市場は終わったと言われていた。VS Code がすべてを飲み込み、JetBrains は自分のポジションを守り、Vim/Emacs ユーザは自分の洞窟で幸せだった。それで終わりだと言われていた。

2026年、その予測は半分だけ当たった。VS Code は今も支配的だ。Stack Overflow Developer Survey 2024 では 73.6% の開発者が VS Code を使うと答え、その数字は 2025年も安定している。しかし、その下では興味深いことが起こった。

そしてこのすべての上に Claude Code がある。エディタの中に AI を入れるのではなく、AI の中にエディタを入れるという発想。terminal-native で、IDE に従属しない agent。

この記事は7つのツールを率直に比較する。マーケティング文句ではなく、実際に使ったときに何が良く、何が悪いか。最後には「あなたはどれを使うべきか」の decision framework を提示する。


1. VS Code — 今も default、しかし default が持つ重さ

なぜまだ勝っているのか

VS Code の強みは単純ではない。複数のレイヤーが同時に効いている。

  1. Extension ecosystem. Marketplace に 60,000 以上の extension があり、ほぼすべての言語/ツールが first-class サポートを受ける。
  2. Remote development. SSH、Container、WSL、Codespaces — リモート開発を標準化したのが VS Code だ。Remote-SSH を一度使うと他のエディタに戻りにくい。
  3. GitHub Copilot 統合. 2026年時点で Copilot Chat と Copilot Workspace はエディタ内で最も滑らかな AI 体験を提供する。Copilot Agent Mode が追加され、Cursor との差は縮まった。
  4. すべての OS と corporate 環境で動く. 会社が「許可されたエディタリスト」を持っている場合、十中八九 VS Code が入っている。

率直な欠点

誰が使うべきか

// .vscode/settings.json — VS Code を速くする最小設定
{
  "editor.minimap.enabled": false,
  "editor.formatOnSave": true,
  "files.exclude": {
    "**/node_modules": true,
    "**/.next": true,
    "**/dist": true
  },
  "search.useIgnoreFiles": true,
  "telemetry.telemetryLevel": "off"
}

2. Cursor — AI-first フォークが実際にシェアを獲得した最初の事例

何が違うのか

Cursor は VS Code の fork だ。UI/UX の 90% は VS Code と同じ。extension もほとんど互換。それなのになぜ VS Code + Copilot ではなく Cursor を使うのか?

差は detail にある。

価格とビジネスの現実

率直な欠点

誰が使うべきか


3. Zed — GPU rendering、multiplayer native、Rust で書き直された未来

Atom の亡霊から生まれたエディタ

Zed は Atom と Tree-sitter を作った GitHub の Nathan Sobo が創業した。Atom が 2022年に sunset された後、同じ人たちが「今回は Electron を使わない」と決めて、Rust で一から書き直した。

2026年の状況

率直な欠点

誰が使うべきか

// ~/.config/zed/settings.json — Zed 初期設定
{
  "theme": "One Dark",
  "vim_mode": true,
  "buffer_font_family": "JetBrains Mono",
  "buffer_font_size": 14,
  "format_on_save": "on",
  "assistant": {
    "default_model": {
      "provider": "anthropic",
      "model": "claude-sonnet-4-5"
    }
  }
}

4. Neovim — 本当に IDE になった Vim

なぜ 2026年に Vim を使うのか

Neovim は Vim の fork だ。2014年に始まり、2017年に 1.0、2024年に 0.10、2025年に 0.11 と、毎年メジャーリリースが安定して出ている。

差を作ったのは3つ。

  1. Built-in LSP client (0.5から)。もう coc.nvim や YouCompleteMe のような重いプラグインは要らない。nvim-lspconfig で1行設定。
  2. Tree-sitter built-in (0.5から)。syntax highlighting と text object が精密になった。
  3. Lua scripting (vimscript の代替)。プラグインが本当に速く、モダンに書けるようになった。

Distro — 参入障壁を壊した決定打

頑張って lua で設定ファイルを書く代わりに、distro を使えば 30 分以内にフル IDE 環境が出来上がる。

-- LazyVim で Rust サポートを有効化する1行
-- ~/.config/nvim/lua/plugins/rust.lua
return {
  { import = "lazyvim.plugins.extras.lang.rust" },
}

AI integration

率直な欠点

誰が使うべきか


5. Helix — Kakoune が着想を与えた post-modal エディタ

パラダイムの違う modal editing

Vim の modal は「動詞 + 名詞」だ。d w は「削除 + 単語」。Helix (とその inspiration である Kakoune) は「名詞 + 動詞」だ。w d は「単語選択 + 削除」。つまり 選択が先、動作が後

なぜこれが重要か? 視覚的フィードバックが即時に伴う. w を押すと単語がハイライトされ、その状態で d を押すと削除される。Vim では dw を押して「これで合っているか?」を予測しなければならない。

Built-in LSP

Helix の決定的差別化点は LSP がコアであること。別 plugin システムすらない (2026年現在 plugin システムは design 中で v25 でも一般ユーザ向けはまだ)。Rust、Go、TS、Python — LSP server をインストールしていればそのまま動く。

v25 から v26 へ

2025年後半の v25.x リリースサイクルで入った大物:

率直な欠点

誰が使うべきか

# ~/.config/helix/config.toml — Helix 基本設定
theme = "onedark"

[editor]
line-number = "relative"
cursorline = true
true-color = true
bufferline = "multiple"

[editor.lsp]
display-messages = true
display-inlay-hints = true

[keys.normal]
# space-space でファイル picker
space.space = "file_picker"

6. Sublime Text 4 — 生き残った者

なぜ死ななかったか

Sublime Text は 2008年に初めて出て、ST4 は 2021年に出た。その間の4年間でほぼ死んだと言われた。2026年に生きている理由は1つ — 速いから。それも狂ったように速い。

ST4 のアップグレード

率直な欠点

誰が使うべきか


7. JetBrains — 大規模コードベースの絶対王者

IntelliJ ファミリーはなぜ依然として勝つのか

JetBrains IDE は大規模コードベースで他のどのエディタよりも優れている。理由は単純だ。

  1. Static analysis が深い. 単純な LSP ではなく、IntelliJ 自社のコードインデックスエンジンがプロジェクト全体を意味単位で理解する。
  2. Refactoring が本当に安全. Rename、Extract Method、Move Class — 数百ファイルにわたる変更を単一アクションで。
  3. デバッガが最高. マルチスレッド、async、JVM bytecode、native debugging まで — VS Code/Cursor が追いつきにくい領域。
  4. 言語特化 IDE. IntelliJ IDEA (Java/Kotlin)、PyCharm、WebStorm、GoLand、RustRover、CLion など — それぞれがその言語に最適化。

AI Assistant と Junie

JetBrains は 2024年に AI Assistant をリリースし、2025年に Junie という agent を発表した。2026年時点で Junie は Cursor の Composer/Agent と似たポジショニング。

率直な欠点

誰が使うべきか


8. Claude Code — エディタではなく「agent surface」という発想

別カテゴリ

これまでの6つはすべて「エディタ + AI 補助」だった。Claude Code は逆だ。AI agent + テキスト編集能力

なぜこれが重要か

エディタに従属した AI はそのエディタを離れると無力になる。Cursor は Cursor 内でのみ、Copilot は VS Code/JetBrains/Vim の extension がある場所でのみ動く。Claude Code にはそのような従属はない. SSH で入ったサーバ上でも、tmux split 内でも、dotfiles repo の横でも動く。

統合パターン

率直な欠点

誰が使うべきか


9. 比較表 — 7つのツールを一目で

次元VS CodeCursorZedNeovimHelixSublime 4JetBrains
編集パラダイム非モーダル非モーダル非モーダル (vim mode)modal (Vim)post-modal (Kakoune-like)非モーダル (vim package)非モーダル (IdeaVim)
AI integrationCopilot extension (deep)first-class、マルチモデルinline + assistant (Anthropic/OpenAI)プラグイン (avante、copilot、claude-code.nvim)外部ツール依存外部ツール依存AI Assistant + Junie
LSPextension ベース、成熟extension ベース (VS Code 互換)built-inbuilt-in (0.5+)built-in (コア)package で追加独自分析エンジン + LSP
パフォーマンスElectron、重いElectron、重いGPU rendering、超高速terminal、超高速terminal、超高速独自 GUI、超高速JVM、重い
学習コスト
ターゲットユーザfull-stack、チーム標準AI pair programming ヘビー速度信奉者、pair 作業modal ベテラン、SSH workflowmodal 入門者、ミニマリスト巨大ファイル、高速テキスト作業モノレポ、シニア
Extension ecosystem60,000+VS Code 互換 (ほぼ)WASM ベース、成長中Lua プラグイン (数千)ほぼなしPackage Control (停滞)JetBrains Marketplace
価格無料無料/Pro 20 USD/月無料 (Pro 20 USD/月)無料、OSS無料、OSS99 USD (3年)無料 (Community) / 有料
Remote 開発Remote-SSH 標準Remote-SSH 互換SSH betaネイティブ (terminal)ネイティブ (terminal)弱いGateway

10. Decision framework — あなたはどれを使うべきか

質問 1: AI pair programming が毎日 4 時間以上か?

質問 2: modal editing をすでに使っている、または 1〜2週間投資して学ぶ意思があるか?

質問 3: モノレポ、巨大な Java/Kotlin コードベース、深い refactoring が日常か?

質問 4: 会社/チーム標準が決まっているか?

質問 5: 速度がすべての上にあるか?

そして Claude Code はほぼ常に追加せよ

上の決定とは無関係に、Claude Code はメインエディタとは別に使える。terminal さえあれば動くから。自律 agent workflow (長い task を投げて結果を受ける) に慣れれば、どのエディタを使っていても生産性が跳ねる。


11. AI integration の 4 つのパターン — 2026年の標準化

2026年時点でエディタの AI integration は 4 つのパターンに収束した。

  1. Inline 自動補完 (Copilot、Cursor Tab、Zed Edit Prediction)。最も普遍的。すべてのエディタで何らかの形で提供。
  2. Inline chat / インストラクション編集 (Cmd+K)。コードの上で自然言語で修正指示。Cursor が一番上手い。
  3. Side panel chat (Copilot Chat、Cursor Composer、Zed Assistant)。Context を添付してマルチターン対話。
  4. Agent mode (Cursor Agent、Copilot Agent、JetBrains Junie、Claude Code)。Task を投げると自律的にマルチステップ実行。

各パターンがどのエディタで最も強いかをまとめると:

Claude Code が 4 でユニークなのは エディタから切り離されているから。他のすべての agent は特定のエディタ内で動くが、Claude Code はそうではない。


12. modal editing のルネサンス — なぜ今再び?

2026年に modal editing が再び注目される理由は興味深い。

  1. AI が autocomplete を上手くやってくれるので、タイピング自体が減った. しかしコードを「移動・選択・操作」する能力は依然として人間がやる。modal editing はまさにその領域で強い。
  2. Terminal workflow への回帰. Docker、Kubernetes、リモートサーバ — terminal 内で作業が増えた。terminal-native な modal editor が自然に合う。
  3. AI ツールが分離された. Claude Code のような外部 agent が強くなり、エディタ自体は「ただの速いテキストエディタ」で十分という認識が増えた。
  4. Helix の登場. Vim の参入障壁を下げた modal editor が modal editing を新世代に紹介した。

これは一時的流行か? いや。2024年の Stack Overflow Survey で Neovim はユーザ満足度 (loved) 1位、2025年も上位。Helix は新規ユーザ採用速度が最も速いエディタの 1 つだ。


13. アンチパターン — よくあるミス

アンチパターン 1: ツールを頻繁に変える

毎月新しいエディタに乗り換えると muscle memory が積まれない。一度決めたら最低 3 ヶ月は使え。

アンチパターン 2: AI 自動補完を無批判に受け入れる

Tab を押せば終わりではない。Autocomplete は hallucinate する。短い変数名を別の意味で、ライブラリ API を間違って、type を当てずっぽうで。レビューしない completion は負債だ。

アンチパターン 3: Extension を 50 個入れる

VS Code/Cursor でよく見るパターン。各 extension が 0.5 秒の起動遅延を作るなら、50 個で 25 秒。毎週使うものだけ残せ。

アンチパターン 4: distro (LazyVim 等) を入れた後 init.lua に手を出さない

Distro は出発点だ。自分の workflow に合わせて後続 tuning をしないと、distro の意見が自分の意見になる。良い場合もあるが、時間が経つともどかしくなる。

アンチパターン 5: エディタですべてをやろうとする

エディタはテキストエディタだ。CI/CD、クラウドオペレーション、データクエリ — 他のツールがより上手くやることが多い。すべてを IDE に引き込もうとする extension 暴走を警戒せよ。


エピローグ — 2026年の本当の変化

10年前の予測は半分だけ当たった。VS Code は勝った。しかしその上に新しいものが育った。

あなたが 2026年にコードを書くなら — 1 つのツールを愛しつつ、他のツールの存在を認識せよ。サイロ化は退場の始まり。Cursor だけ使う人も Neovim の modal editing を一度は体験してみよ。Vim ベテランも Cursor の Composer を 30 分触ってみよ。視野が広がる。

チェックリスト — 今のあなたのエディタ設定を点検

アンチパターン要約

次回予告

次回は Claude Code の internals — subagent、hook、Agent SDK の実装ディテール を扱う。1 つの terminal プロセスがどのようにマルチエージェント workflow を orchestrate するか、その下で MCP がどう動くか。


参考 / References

公式ホームページ

Distro / プラグイン

データ / トレンド

MCP / Agent 標準

コメント

まだコメントはありません。

ログインするとコメントできます