💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

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

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 Code | TypeScript | プラグイン A |

| Vim | TypeScript | プラグイン B(再実装) |

| Emacs | TypeScript | プラグイン C(再実装) |

| Atom | TypeScript | プラグイン 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 の地位

- **真面目なエディタは全て 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 誰が使っているか

| ツール | Tree-sitter の使い方 |

| --- | --- |

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

- **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 何が魅力か

| 項目 | Vim/Neovim | Helix |

| --- | --- | --- |

| 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 統合**。

- **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+)をコアに入れた。結果として **無限のカスタマイズ** が可能なエディタとして残った。

代表プラグイン:

| プラグイン | 役割 |

| --- | --- |

| **nvim-treesitter** | Tree-sitter 統合 — ハイライト・インデント・テキストオブジェクト |

| **nvim-lspconfig** | 著名な LSP サーバの設定集 |

| **lsp-zero** | nvim-lspconfig + mason + cmp の事前統合 — 「一行で LSP を有効化」 |

| **mason.nvim** | LSP サーバ・フォーマッタ・リンタ・デバッガのインストーラ |

| **nvim-cmp** | 補完 UI エンジン |

| **none-ls / null-ls** | LSP でない道具(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

- Rust 公式推奨 LSP。

- マクロ展開・トレイト推論・ライフタイムヒントまでインライン表示。

- メモリ・CPU を少なからず食うが、それに見合う価値。

9.2 Go — gopls

- Go チームが直接維持。事実上の標準。

- gofmt・goimports と統合された速い整形。

- ジェネリクス導入後の安定化が速かった。

9.3 Python — pyright / basedpyright / jedi / pylyzer

| サーバ | 特徴 |

| --- | --- |

| **pyright** | Microsoft 製、速い型チェッカベースの LSP |

| **basedpyright** | pyright のフォーク。OSS フレンドリで厳格度を強化 |

| **jedi-language-server** | jedi ベース。型アノテーションが少ないコードに強い |

| **pylyzer** | Rust 製の速い静的解析器 + LSP。初期段階だが期待値高 |

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 その他

| 言語 | LSP |

| --- | --- |

| Ruby | **Solargraph**(伝統)、**ruby-lsp**(新興、Shopify) |

| Elixir | **elixir-ls**、**next-ls** |

| Haskell | **hls**(haskell-language-server) |

| Nim | **nimlsp** |

| OCaml | **ocaml-lsp** |

| Lua | **sumneko-lua** / **lua-language-server**(Neovim 設定に必須) |

| Zig | **zls** |

| Kotlin | **kotlin-language-server** |

| Swift | **sourcekit-lsp** |

| Erlang | **erlang_ls** |

| Bash | **bash-language-server** |

| YAML | **yaml-language-server**(Red Hat) |

| JSON | **vscode-json-languageserver** |

| Terraform | **terraform-ls** |

| Markdown | **Marksman** |

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 二つの流れ

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

| 種類 | 出処 | 例 |

| --- | --- | --- |

| **言語ベース** | LSP サーバ。型・シンボルインデックス | pyright、rust-analyzer |

| **確率ベース** | LLM・ローカルモデル | Tabnine、Copilot、Codeium、Cursor Tab |

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 全員に共通すべきこと

| 項目 | 推奨 |

| --- | --- |

| 補完 | LSP(言語ベース)+ LLM(確率ベース)両方 |

| ハイライト | Tree-sitter |

| 整形 | 言語公式フォーマッタ(rustfmt、gofmt、ruff format、biome) |

| リント | 言語別標準 + 会社ポリシーは Semgrep |

| 検索 | 精度が必要なら ast-grep |

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/