LSP & Tree-sitter エコシステム 2026 — ast-grep / Biome / Helix / Zed / Neovim Treesitter / 言語別 LSP 徹底ガイド

プロローグ — コードツールの二大標準

2010 年代のエディタ戦争はシンプルだった。「どのアプリを使うか」 がほとんど全てを決めた。VS Code か、JetBrains か、Vim か、Emacs か。それぞれが自前の補完・定義ジャンプ・リファクタリング・シンタックスハイライトを別々に実装し、新しい言語が出るたびに エディタ x 言語 分の作業が必要だった。

2026 年の絵は完全に違う。エディタ・IDE の本当の重心は、二つのプロトコル・ライブラリ に移った。

ここ 10 年の含意ははっきりしている。エディタを作るより、標準に乗るほうが圧倒的に安い。 だから Helix や Zed のような新しいエディタは、最初から LSP + Tree-sitter を 内蔵 で書く。Neovim は 0.5 から LSP クライアントをコアに入れ、VS Code は最初から LSP のリファレンス実装だった。

そしてこの二つの標準の上に、新しい生態系が爆発的に育っている — ast-grep(Tree-sitter ベースの構造検索・リライト)、BiomeJS(Rust で書き直された JS ツールチェイン)、Marksman(Markdown LSP)、Semgrep / CodeQL(セキュリティ・ポリシー検索)、Comby(言語中立リライト)。この記事はその全部を一冊にまとめる。

1. LSP — Microsoft 標準の立ち位置

1.1 なぜ LSP が必要だったか

2015 年以前: 新しい言語をサポートするには、エディタごとに別々のプラグインを書く必要があった。

言語が M 個、エディタが N 個あれば、M x N 個のプラグインが必要だった。しかも各プラグインが「定義ジャンプ」や「リネーム」のような機能を再実装し、品質はバラバラだった。

Microsoft の洞察: コード解析ロジックを 別プロセス(言語サーバ) に分離し、エディタとサーバが 標準 JSON-RPC メッセージ で会話するようにすれば、M + N に圧縮できる。

1.2 LSP のコアメッセージ

既定の転送層は stdin/stdout 上の JSON-RPC 2.0。TCP・ソケットも可能だが stdio が標準。

1.3 一行図

       ┌──────────────┐           ┌─────────────────────┐
       │   エディタ    │  JSON     │   言語サーバ(LSP)   │
       │ (クライアント) │◀────────▶│  rust-analyzer 等   │
       │  VS Code,    │   RPC     │  (別プロセス)        │
       │  Helix, Zed, │           │                     │
       │  Neovim ...  │           │  - パーシング        │
       └──────────────┘           │  - 型推論           │
                                  │  - インデックス      │
                                  └─────────────────────┘

エディタ側は 薄くなる。サーバ側は 厚くなる。そして一度よく書いたサーバは、全てのエディタで使える。

1.4 2026 年の LSP の地位

• 真面目なエディタは全て LSP クライアントを内蔵。 VS Code、JetBrains、Helix、Zed、Neovim、Emacs(eglot)、Sublime。
• 活発な言語は自前の LSP サーバを持つ。 rust-analyzer、gopls、pyright、typescript-language-server、clangd など。
• ベンダロックインが消えた領域。 「この言語は VS Code でしかまともに使えない」という言葉が、もう奇妙に響く。

2. Tree-sitter — Max Brunsfeld の増分パーサ

2.1 正規表現ハイライトの限界

2010 年代半ばまで、ほとんど全てのエディタのシンタックスハイライトは 正規表現 だった。TextMate 文法(.tmLanguage)が事実上の標準だった。

問題:

• 嘘をつく。 正規表現は本物のパーサではないので、ネストした文字列・複雑な補間・マクロで崩れる。
• 遅い。 大きなファイルで毎キーストロークごとに再マッチ。
• エラーに弱い。 コードが一時的に壊れるとハイライトが全壊する。

2.2 Tree-sitter の答え

Max Brunsfeld(元 Atom、GitHub)が作った Tree-sitter は、これらを同時に解く。

1. 増分(incremental)。 キー入力一回でツリー全体を再パースせず、変わった部分だけ再パース。
2. エラー回復。 コードが一時的に壊れていても、可能な限りパースし、残りはエラーノードに。
3. 一般化 LR(GLR)アルゴリズム。曖昧文法も扱える。
4. 言語中立。 文法は DSL(JS 風の文法定義)で書き、パーサは C で生成。
5. 速い。 本物のパーサでありながら、ハイライト用途に十分高速。

2.3 用途

• シンタックスハイライト: AST ベースで正確。
• コードフォールディング: 関数・ブロックを構造に基づいて折りたたみ。
• 構造選択: 「関数全体を選択」「式単位で選択拡張」のような操作。
• 検索・リライト: テキストではなく AST ノードでクエリ(ast-grep、Comby)。
• ハイライト以外のインデックス: 関数・クラス・インポートの抽出。

2.4 誰が使っているか

2.5 文法の配布

tree-sitter-rust、tree-sitter-python、tree-sitter-typescript ... ほぼ全ての人気言語が、別 npm/crates パッケージで文法を提供する。新しい言語をサポートするには文法を書くだけでよく、ハイライトクエリ(.scm)は短い。

3. ast-grep(sg) — 構造検索とリライト

3.1 grep の限界、ast-grep の答え

grep はテキストマッチだ。「console.log を呼ぶ全箇所」 を探すと、コメント・文字列・doc 内の console.log も一緒に拾う。さらに 「console.log の第一引数がオブジェクトの箇所だけ」 のような質問は、正規表現では事実上不可能だ。

ast-grep(sg)は違う。Tree-sitter でパースした AST の上で パターンマッチする。パターン言語はその言語のコードそのものに見え、$VAR でメタ変数を置く。

3.2 誰が作ったか、何が新しいか

• Herrington Darkholme が Rust で作成。
• 2024 年に外部投資(シードラウンド)を受け、「ast-grep カンパニー」として本格展開 — エンタープライズのコード移行・ポリシー検索がターゲット。
• Rust + Tree-sitter の組み合わせで 速く、Tree-sitter 対応の全言語で動く。

3.3 パターン例

# console.log をどんな引数でも呼んでいる全箇所
sg --pattern 'console.log($A)' --lang typescript

# 第一引数がオブジェクトリテラルの呼び出しだけ
sg --pattern 'console.log({ $$$ })' --lang typescript

# リライト: console.log(x) -> logger.debug(x)
sg --pattern 'console.log($A)' --rewrite 'logger.debug($A)' --lang typescript --update-all

$A は任意の式一つ、$$$ は任意のノード列を捕まえるメタ変数。

3.4 sgconfig.yml — コードベースのポリシー

ast-grep は YAML ルールセット でチームのポリシーを保存できる。CI でルールセットを走らせれば、「このパターンを使うな」といった規則が自動で検査される。

id: no-direct-fetch
language: typescript
rule:
  pattern: fetch($URL)
message: "fetch ではなく apiClient.get を使うこと"
severity: warning

3.5 どこに向いているか

• 大規模リファクタ。 「この API 呼び出しパターンを新 SDK に一括移行」。手作業なら 1 週間、ast-grep なら数分。
• コードベースのポリシー。 「このモジュールで console.log 禁止」「useEffect 内に fetch を書くな」のようなルール。
• 巨大コードベースの探索。 「このパターンを使う全箇所」のような質問に、grep よりはるかに正確。

4. BiomeJS — ESLint + Prettier の置き換え

4.1 JS ツールチェインに溜まった痛み

2010 年代半ば以降、JS 開発者が必ず使っていた二つの道具:

• ESLint — コード品質リンタ(JS で書かれている)
• Prettier — フォーマッタ(JS で書かれている)

両方とも素晴らしいが:

• 遅い。 巨大モノレポで Lint 30 秒、フォーマット 10 秒が日常。
• 設定が複雑。 ESLint config は plugin・preset・rule の迷路。
• 二つが別々に動く。 ESLint --fix と Prettier が衝突し、追加のプラグインが要る。
• 型情報なしで動く。 AST レベルでの検査なので限界がある。

4.2 Biome のアプローチ

Biome(元の Rome プロジェクトから分離・再出発)は、以下をまとめた。

• Rust で書かれている — 同じコードに対し、ESLint+Prettier 比で数十〜数百倍速い。
• 単一バイナリ — Lint + フォーマット + インポート整理 + コードアクションが一つの道具に。
• ほぼゼロ設定 — 良いデフォルト。biome.json 一つ。
• LSP サーバ内蔵 — エディタ統合が同梱。

4.3 一行で見る差

# 従来
eslint . --fix && prettier --write .

# Biome
biome check . --apply

4.4 限界

• TypeScript 専用ルール は ESLint がまだ豊富(2026 年時点で急速に縮小中)。
• カスタムルール: ESLint の方が成熟。Biome も v2 からプラグイン拡張を強化。
• Vue・Svelte などの非標準構文: サポート中だが、ESLint ほど深くないことも。

それでも 新規 JS/TS プロジェクトの既定 は急速に Biome に移っている。

5. Marksman — Markdown LSP

5.1 Markdown にも LSP が必要?

最初は意外だ。Markdown はただのテキストでしょ? しかし、Markdown を本格的に使うウィキ・ノート・ブログ・ドキュメントサイトでは、次が要る。

• ファイル間リンクの 定義ジャンプ([foo](./other.md) を開く)。
• 見出し・アンカー・画像の 補完。
• 壊れたリンクの 診断。
• バックリンクの追跡。
• 名前変更時に全参照を一括更新。

これは LSP の用途そのものだ。

5.2 Marksman の位置

Marksman(F# 製)は Markdown 専用 LSP サーバ。Helix・Zed・Neovim・VS Code 全てで動く。

• [[wiki-link]] と [text](path.md) 両方をサポート。
• 見出し補完: [# まで打つと候補の見出しリストが出る。
• 壊れたリンクを表示。
• 見出しのリネームが全参照に伝播。
• ワークスペースシンボル: 全見出しが検索可能。

5.3 近隣の道具

• zk-lsp — Zettelkasten スタイルのノート。
• Obsidian — 独自インデックスを持つが、外部エディタで同じ vault を扱う際は Marksman が標準。

6. Helix エディタ — built-in LSP + Tree-sitter

6.1 Helix の設計判断

Helix は Rust 製のモーダルエディタ。Vim/Kakoune の後裔だが、決定的な違いがある。

• LSP クライアント内蔵。 プラグインなし。languages.toml にサーバを登録すれば終わり。
• Tree-sitter 内蔵。 ハイライト・インデント・構造モーション・テキストオブジェクト全て TS ベース。
• selection-first 編集モデル。 Vim の verb-object を反転して object-verb に。選択が常に先に見える。
• プラグインシステムがほぼ無い(設計意図)。コアが厚いので、ほとんど要らないようにしている。

6.2 何が魅力か

「一時間で IDE 級の環境」が Helix の約束。トレードオフは明確 — 深いカスタマイズは依然として Neovim が王。

6.3 languages.toml 例

[[language]]
name = "rust"
language-servers = ["rust-analyzer"]
auto-format = true

[[language]]
name = "python"
language-servers = ["basedpyright"]

これがほぼ全て。

7. Zed エディタ — Tree-sitter + LSP + リアルタイム協業

7.1 Zed の出自と野心

Zed は Atom・Electron 時代の共著者(Nathan Sobo ら)が一から作り直したエディタ。コアは Rust で書かれたネイティブエディタ + 協業編集(collab) + AI 統合。

• GPU 加速描画。 エディタとして非常に速い。
• Tree-sitter / LSP 内蔵。 Helix と同じ哲学。
• リアルタイム協業。 Google Docs 風のマルチカーソル・音声通話・画面共有まで一体化。
• AI 統合。 チャット・インラインアシスト・エージェント統合が内蔵。
• 拡張機能 は WebAssembly ベース。

7.2 誰に向くか

• VS Code の重さ(Electron、RAM、起動時間)に疲れた人。
• 協業編集をプロダクト級に よく使うペアプログラミングのチーム。
• AI 機能をエディタコアで 使いたい人。

7.3 トレードオフ

• 拡張機能の生態系は VS Code ほど深くない。
• 巨大モノレポの一部ワークフロー(特定デバッガ・テストランナー)は依然として VS Code 側が豊富。

8. Neovim 統合 — nvim-treesitter / lsp-zero / nvim-lspconfig

8.1 Neovim の位置

Neovim は Vim からフォークし、LSP クライアント内蔵(0.5+)、Lua ランタイム、Tree-sitter サポート(0.8+)をコアに入れた。結果として 無限のカスタマイズ が可能なエディタとして残った。

代表プラグイン:

8.2 lsp-zero の価値

Neovim の LSP セットアップは強力だが、最初は急峻だ。1) lspconfig でサーバ登録、2) mason でインストール、3) cmp で補完接続、4) キーマップ設定。lsp-zero はこの 4 ステップを良いデフォルトで一括にする。

local lsp_zero = require('lsp-zero')
lsp_zero.on_attach(function(client, bufnr)
  lsp_zero.default_keymaps({buffer = bufnr})
end)

require('mason').setup({})
require('mason-lspconfig').setup({
  ensure_installed = { 'rust_analyzer', 'gopls', 'basedpyright', 'tsserver' },
  handlers = { lsp_zero.default_setup },
})

8.3 nvim-treesitter

require('nvim-treesitter.configs').setup({
  ensure_installed = { 'rust', 'go', 'python', 'typescript', 'tsx', 'lua' },
  highlight = { enable = true },
  indent = { enable = true },
})

これを入れる瞬間に、正規表現ハイライトとは比べものにならない正確性が入ってくる。

9. 言語別 LSP カタログ

9.1 Rust — rust-analyzer

• Rust 公式推奨 LSP。
• マクロ展開・トレイト推論・ライフタイムヒントまでインライン表示。
• メモリ・CPU を少なからず食うが、それに見合う価値。

9.2 Go — gopls

• Go チームが直接維持。事実上の標準。
• gofmt・goimports と統合された速い整形。
• ジェネリクス導入後の安定化が速かった。

9.3 Python — pyright / basedpyright / jedi / pylyzer

2026 年時点: 新規コードベースの推奨は basedpyright。レガシーな untyped コードには jedi。

9.4 TypeScript / JavaScript

• typescript-language-server(長年の標準)。tsserver を LSP でラップ。
• vtsls — VS Code の TS 拡張に近い挙動の新興ラッパ。2026 年には多くの Neovim/Helix ユーザが vtsls に移行。
• フォーマット・リントは BiomeJS が急速に置き換え中。

9.5 C/C++ — clangd

• LLVM 陣営の標準。compile_commands.json をきちんと作れば、巨大コードベースでも動く。
• インデックスは遅くなりがちだが、一度作られれば応答は速い。

9.6 Java — jdtls

• Eclipse JDT を LSP として公開。Java 生態系の事実上の標準 LSP。
• メモリ使用量が大きい。Maven/Gradle 統合が深い。

9.7 その他

9.8 一つのパターン

• 言語チームが直接作った LSP(gopls、rust-analyzer、ruby-lsp、hls、ocaml-lsp)は、ほぼ常に最も深く正確。
• 私企業が作った LSP(pyright、sourcekit-lsp)もしばしば標準になる。
• 言語が静的型を持つと LSP の品質が飛躍的に良くなる — 型情報こそ LSP の素材だ。

10. 構造検索 — Comby / Semgrep / CodeQL

ast-grep に近い領域にある三つの道具。それぞれ少し違う位置を占める。

10.1 Comby

• 言語中立な構造マッチング。独自の小型パーサで「括弧・中括弧・引用符のような均衡構造」を認識。
• 新言語サポートが非常に安い — 本物の文法ではなく「言語のトークン形状」だけ登録すればよい。
• 小さく速い一回限りのリライトに強い。

comby 'foo(:[x])' 'bar(:[x])' file.py

10.2 Semgrep

• セキュリティ中心で出発。今は一般的なポリシー検索エンジン。
• パターンは その言語のコードそのもの に見える。$X.execute($Y) のようなメタ変数。
• 巨大なルールセット(数千のセキュリティルール)。CI に組み込む標準。
• 会社全体のコードポリシー — 「この API 呼び出し禁止」「この引数パターンを検査」 — に最適。

10.3 CodeQL

• GitHub(Microsoft)所有。「コードをデータベースとして見て、SQL 風クエリで検索」。
• パターンマッチではなく データフロー解析 まで行う。
• 非常に強力だが学習コストが高く、通常はセキュリティチームが使う。
• GitHub Code Scanning の既定エンジン。

10.4 並べて比較

選択の指針:

• 一度よく書いてチームが検査し続ける -> Semgrep。
• 即席の大規模リファクタ -> ast-grep。
• 軽く一二箇所 -> Comby か ast-grep。
• 深いセキュリティ解析 -> CodeQL。

11. Tabnine vs 言語別補完

11.1 二つの流れ

補完は二つが混ざっている。

11.2 Tabnine の位置

• 初期は GPT-2 ベースのローカル補完で知られていた。
• 2026 年にはエンタープライズ自己ホスティング・コード学習の隔離に集中。「会社の社内コードだけ学習したモデル」を提供。
• Copilot が強大になった市場で、「プライバシ・オンプレ」のポジションを確立。

11.3 LSP 補完と LLM 補完は併走すべき

• LSP 補完は 正確な型・シンボル を知る。ハルシネーションがない。
• LLM 補完は 長いコンテキスト・パターン一般化 が強い。知らない名前も推測。
• 良いエディタ(Cursor、Zed、VS Code+Copilot、Neovim+lsp+ai プラグイン)は 両ストリームを同時に 見せ、ユーザが選べる。

補完 = LSP + LLM のハイブリッドが 2026 年の標準。

12. 韓国・日本の現場

12.1 韓国 — トス(Toss)の LSP・社内ツール活用

トスは社内ツール・プラットフォームチームのブログで頻繁に LSP・Tree-sitter ベースのツールに言及する。

• 巨大モノレポで 型認識 grep(ast-grep)を使った API 移行・deprecation 検索。
• vtsls + Biome の組み合わせで、フロントエンドの補完・整形を高速化。
• 自社デザインシステム・社内 SDK のための ESLint/Biome ルールを社内で維持。
• セキュリティチームは Semgrep ルールセットをコードベースポリシーとして運用。

要点は エディタの自由 だ。誰かは IntelliJ、誰かは Cursor、誰かは Neovim を使うが、LSP・Tree-sitter・Biome・ast-grep のような標準の上にあれば、チームのルールセットが全員に同じく適用される。

12.2 日本 — メルカリの Tree-sitter 活用

メルカリは社内技術ブログで Tree-sitter ベースのツールに次のように言及することが多い。

• コード検索・シンボルインデックス — 巨大モノレポからの正確な関数・シンボル抽出。
• GitHub Actions 上の ast-grep / Semgrep ルールセット を社内コードポリシーとして検査。
• Go + gopls・Rust + rust-analyzer が社内標準 LSP の組み合わせ。決済・検索などバックエンドの基本。
• モバイル側では kotlin-language-server / sourcekit-lsp がビルド基盤と紐づいて使われている。

日本の他の会社 — DeNA・CyberAgent・SmartHR・LINE — も似た絵だ。LSP・Tree-sitter は 2026 年の「当然のインフラ」として定着した。

13. 誰が何を選ぶべきか

13.1 シナリオ別の推奨

「VS Code をそのまま使い続けたい」

• VS Code + 言語別公式 LSP 拡張(rust-analyzer、gopls、basedpyright、...)。
• 補完: Copilot か Cursor フォーク。
• リント / 整形: Biome(JS/TS)、言語別標準(rustfmt、gofmt、ruff)。

「VS Code が重い、速いネイティブエディタへ」

• Zed。LSP・TS・協業・AI 内蔵。最も負担の少ない移行。
• Helix。さらに軽く、よりキーボード中心。モーダル編集に慣れているなら。

「無限のカスタマイズとキーボードワークフロー」

• Neovim + lsp-zero + nvim-treesitter + telescope + nvim-cmp。
• 初期セットアップは急峻だが、一度落ち着けば最強のワークフロー。

「巨大モノレポのリファクタ・ポリシー」

• コード検索・リライト: ast-grep。
• セキュリティ・ポリシー: Semgrep。
• 深い解析: CodeQL。
• 軽い一回限りのリライト: Comby。

「Markdown 中心の作業(ノート・ドキュメント・ブログ)」

• 任意のエディタ + LSP として Marksman。
• Obsidian ユーザは外部エディタ + Marksman の組み合わせも良い選択。

13.2 全員に共通すべきこと

14. 落とし穴とアンチパターン

14.1 よくある落とし穴

• LSP サーバを入れすぎる。 Neovim で同じファイルに LSP 二つ(例: tsserver + vtsls)が同時に付くと、診断が重複しメモリが漏れる。一言語につき一つに絞る。
• 巨大モノレポでインデックスコストを軽視。 初回インデックスに 10 分かかるのは珍しくない。CI キャッシング・サーバ再起動の頃合いに気を配る。
• フォーマッタの衝突。 Prettier・Biome・ESLint --fix・言語公式フォーマッタを同時に有効化すると、保存のたびにコードが振動する。「フォーマット権威」は一つに絞る。
• Tree-sitter 文法のバージョン不一致。 エディタごとに文法バージョンが異なると、同じファイルが違って表示される。大きな問題ではないが紛らわしい。

14.2 アンチパターン

• 正規表現でリファクタ。 5 箇所以上なら、ast-grep / Comby / Semgrep がほぼ常に速くて安全。
• 手動でインポート整理。 LSP の organize imports か Biome で自動化。
• LSP 無しで巨大コードベースを探索。 定義ジャンプ・参照検索が無いと、失う時間が膨大。
• ローカルにだけ LSP、CI には無い。 リント・型チェック・ポリシー検査は CI にも一緒に住むべき。

15. まとめ — 標準の上に住む

2026 年のコードツール生態系は、二つの標準 の上に立っている。

• LSP — コード知能。
• Tree-sitter — コード構造。

この二つのおかげで:

• エディタを変えるコストは暴落した。
• 新しい言語をサポートするコストも暴落した。
• 会社のポリシーをコードで表現するコストも暴落した。

その上に育った生態系 — ast-grep、Biome、Marksman、Helix、Zed、Neovim の lsp-zero/treesitter チェーン、そしてうまく作られた言語別 LSP たち — は、すべてこの二軸の直接の子孫だ。

選ぶときに覚えておくこと一つ: 道具が LSP・Tree-sitter のような標準の上にあれば、間違った選択はほとんどない。いつでも乗り換えられるし、チームのルールセットも一緒についてくる。

参考 / References

• LSP 仕様 — https://microsoft.github.io/language-server-protocol/
• Tree-sitter — https://tree-sitter.github.io/tree-sitter/
• ast-grep(sg) — https://ast-grep.github.io/
• BiomeJS — https://biomejs.dev/
• Marksman — https://github.com/artempyanykh/marksman
• Helix editor — https://helix-editor.com/
• Zed editor — https://zed.dev/
• Neovim — https://neovim.io/
• nvim-treesitter — https://github.com/nvim-treesitter/nvim-treesitter
• nvim-lspconfig — https://github.com/neovim/nvim-lspconfig
• lsp-zero.nvim — https://github.com/VonHeikemen/lsp-zero.nvim
• mason.nvim — https://github.com/williamboman/mason.nvim
• rust-analyzer — https://rust-analyzer.github.io/
• gopls — https://pkg.go.dev/golang.org/x/tools/gopls
• pyright — https://github.com/microsoft/pyright
• basedpyright — https://github.com/DetachHead/basedpyright
• jedi-language-server — https://github.com/pappasam/jedi-language-server
• pylyzer — https://github.com/mtshiba/pylyzer
• typescript-language-server — https://github.com/typescript-language-server/typescript-language-server
• vtsls — https://github.com/yioneko/vtsls
• clangd — https://clangd.llvm.org/
• jdtls — https://github.com/eclipse-jdtls/eclipse.jdt.ls
• Solargraph — https://solargraph.org/
• ruby-lsp — https://github.com/Shopify/ruby-lsp
• elixir-ls — https://github.com/elixir-lsp/elixir-ls
• haskell-language-server — https://github.com/haskell/haskell-language-server
• nimlsp — https://github.com/PMunch/nimlsp
• ocaml-lsp — https://github.com/ocaml/ocaml-lsp
• sumneko/lua-language-server — https://github.com/LuaLS/lua-language-server
• zls — https://github.com/zigtools/zls
• Comby — https://comby.dev/
• Semgrep — https://semgrep.dev/
• CodeQL — https://codeql.github.com/
• GitLens(VS Code) — https://github.com/gitkraken/vscode-gitlens
• Difftastic — https://github.com/Wilfred/difftastic
• Tabnine — https://www.tabnine.com/
• トス技術ブログ — https://toss.tech/
• メルカリ Engineering Blog — https://engineering.mercari.com/