LabHub

ブログ

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

2026-05-16 · 27 分で読めます · #lsp#tree-sitter#ast-grep#biomejs#marksman#helix-editor#zed#nvim-treesitter#lsp-zero#rust-analyzer#gopls#pyright#basedpyright#typescript-lsp#clangd#jdtls#solargraph#elixir-ls#hls#sumneko-lua#jedi#comby#semgrep#codeql#deep-dive#japanese

한국어English日本語

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

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

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

標準何を標準化したか誰が作ったか
LSP(Language Server Protocol)コードの「知能」 — 補完・定義ジャンプ・リネーム・診断・フォーマットMicrosoft(2016)
Tree-sitterコードの「構造」 — 増分パーサ・ハイライト・構造認識Max Brunsfeld(GitHub、2018+)

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

エディタ言語結果
VS CodeTypeScriptプラグイン A
VimTypeScriptプラグイン B(再実装)
EmacsTypeScriptプラグイン C(再実装)
AtomTypeScriptプラグイン D(再実装)

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

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

1.2 LSP のコアメッセージ

メッセージ何を尋ねるか
textDocument/completionカーソル位置の補完候補
textDocument/definitionシンボルの定義位置
textDocument/referencesシンボルを参照する全箇所
textDocument/hoverカーソル下のシンボルの型・ドキュメント
textDocument/renameシンボルの一括リネーム
textDocument/formattingドキュメント整形
textDocument/codeActionクイックフィックス・リファクタリング提案
textDocument/publishDiagnosticsサーバ -> クライアント(エラー・警告)

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

1.3 一行図

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

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

1.4 2026 年の LSP の地位

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 用途

2.4 誰が使っているか

ツールTree-sitter の使い方
Neovimnvim-treesitter プラグイン — ハイライト・フォールド・構造テキストオブジェクト
Helix内蔵。ハイライト・インデント・構造モーション全て TS ベース
Zed内蔵。ハイライト・アウトライン・構造検索
GitHubコード検索・ハイライト・シンボル抽出
ast-grep構造検索・リライトエンジン
Difftastic構造認識 diff

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 誰が作ったか、何が新しいか

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 どこに向いているか

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

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

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

両方とも素晴らしいが:

4.2 Biome のアプローチ

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

4.3 一行で見る差

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

# Biome
biome check . --apply

4.4 限界

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

5. Marksman — Markdown LSP

5.1 Markdown にも LSP が必要?

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

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

5.2 Marksman の位置

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

5.3 近隣の道具

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

6.1 Helix の設計判断

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

6.2 何が魅力か

項目Vim/NeovimHelix
LSP 統合プラグイン(nvim-lspconfig)内蔵
Tree-sitterプラグイン(nvim-treesitter)内蔵
設定数十〜数百行ほぼゼロ
初回体験急峻即動く
拡張性無制限(Lua)制限あり

「一時間で 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 統合。

7.2 誰に向くか

7.3 トレードオフ

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

8.1 Neovim の位置

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

代表プラグイン:

プラグイン役割
nvim-treesitterTree-sitter 統合 — ハイライト・インデント・テキストオブジェクト
nvim-lspconfig著名な LSP サーバの設定集
lsp-zeronvim-lspconfig + mason + cmp の事前統合 — 「一行で LSP を有効化」
mason.nvimLSP サーバ・フォーマッタ・リンタ・デバッガのインストーラ
nvim-cmp補完 UI エンジン
none-ls / null-lsLSP でない道具(eslint、prettier 等)を LSP のように見せる
telescope.nvimファジーファインダ(ファイル・シンボル・LSP 結果)

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

9.2 Go — gopls

9.3 Python — pyright / basedpyright / jedi / pylyzer

サーバ特徴
pyrightMicrosoft 製、速い型チェッカベースの LSP
basedpyrightpyright のフォーク。OSS フレンドリで厳格度を強化
jedi-language-serverjedi ベース。型アノテーションが少ないコードに強い
pylyzerRust 製の速い静的解析器 + LSP。初期段階だが期待値高

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

9.4 TypeScript / JavaScript

9.5 C/C++ — clangd

9.6 Java — jdtls

9.7 その他

言語LSP
RubySolargraph(伝統)、ruby-lsp(新興、Shopify)
Elixirelixir-ls、next-ls
Haskellhls(haskell-language-server)
Nimnimlsp
OCamlocaml-lsp
Luasumneko-lua / lua-language-server(Neovim 設定に必須)
Zigzls
Kotlinkotlin-language-server
Swiftsourcekit-lsp
Erlangerlang_ls
Bashbash-language-server
YAMLyaml-language-server(Red Hat)
JSONvscode-json-languageserver
Terraformterraform-ls
MarkdownMarksman

9.8 一つのパターン

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

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

10.1 Comby

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

10.2 Semgrep

10.3 CodeQL

10.4 並べて比較

道具パラダイム強み障壁
ast-grepTree-sitter AST マッチ・リライト速い、直観的、全 TS 言語低
Comby均衡構造マッチ・リライト新言語サポートが安い、一回限り強い低
SemgrepAST パターン + ポリシールールセット巨大セキュリティルールセット、CI 親和中
CodeQLデータフロー問い合わせ言語最強の解析、taint tracking高

選択の指針:

11. Tabnine vs 言語別補完

11.1 二つの流れ

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

種類出処例
言語ベースLSP サーバ。型・シンボルインデックスpyright、rust-analyzer
確率ベースLLM・ローカルモデルTabnine、Copilot、Codeium、Cursor Tab

11.2 Tabnine の位置

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

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

12. 韓国・日本の現場

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

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

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

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

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

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

13. 誰が何を選ぶべきか

13.1 シナリオ別の推奨

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

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

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

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

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

13.2 全員に共通すべきこと

項目推奨
補完LSP(言語ベース)+ LLM(確率ベース)両方
ハイライトTree-sitter
整形言語公式フォーマッタ(rustfmt、gofmt、ruff format、biome)
リント言語別標準 + 会社ポリシーは Semgrep
検索精度が必要なら ast-grep

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

14.1 よくある落とし穴

14.2 アンチパターン

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

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

この二つのおかげで:

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

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

参考 / References

原文を読む: https://www.youngju.dev/blog/culture/2026-05-16-lsp-tree-sitter-ecosystem-2026-ast-grep-biome-helix-zed-neovim-treesitter-deep-dive.ja

コメント

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

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