---
title: LSP と Language Server
url: https://doc.liz6.com/ja/compilers/08-compilation-technology-applications/04-lsp-and-language-servers
locale: ja
area: compilers
tags:
- compilers
- compilation-technology-applications
date: 2026-06-30
modified: 2026-07-19
description: IDE の補完、ジャンプ、ホバー時の型表示、リファクタリング——これらのコードインテリジェンスはすべて Language Server から提供されます。Language Server は本質的に「コンパイラフロントエンド＋増分更新＋エラー許容パーサ」です。LSP は、字句・構文・シンボルテーブルの能力を JSON-RPC 経由でエディタに公開します。
---
# LSP と Language Server
> IDE の補完、ジャンプ、ホバー時の型表示、リファクタリング——これらのコードインテリジェンスはすべて Language Server から提供されます。Language Server は本質的に「コンパイラフロントエンド＋増分更新＋エラー許容パーサ」です。LSP は、字句・構文・シンボルテーブルの能力を JSON-RPC 経由でエディタに公開します。
## 概要
IDE のコードインテリジェンス——補完、定義へのジャンプ、ホバー時の型表示、リファクタリング——は、従来、各 IDE が対応する言語ごとに独自の解析ロジック（M × N）を実装していました。LSP（Language Server Protocol）は、MCP と同じ戦略を用いてこの問題を解決します。**各言語に対して 1 つの Language Server プロセスを提供し、IDE は JSON-RPC を通じてそれと通信する**のです。コンパイラ技術の観点から見ると、LSP はコンパイラフロントエンド（字句・構文・意味解析・シンボルテーブル）の直接的な消費者であり、Language Server は本質的に「コンパイラフロントエンド＋増分更新エンジン」です。ここでは、LSP プロトコルの主要なリクエストタイプ、Language Server が内部で前述のコンパイラフロントエンド技術を用いてインデックスを構築し応答する方法、そして「十分に速いこと」が「十分に正確なこと」よりも難しい理由について解説します。
## LSP はコンパイラではなく、ターゲットを少し変えたコンパイラフロントエンド
コンパイラが求めるもの：ソースコードから機械語を生成し、正しさを最優先とし、バッチ処理でファイル群を処理する。
Language Server が求めるもの：ユーザーが1文字入力するたびに <100ms 以内で補完・診断・ハイライトを更新し、**未完成またはエラーのあるコード**に対しても合理的な結果を出力し、変更された部分のみを再計算する。
この後者の要件により、Language Server はコンパイラパイプライン全体をそのまま実行することはできません。**増分更新**が必要であり、かつ**構文エラーを許容**する必要があります（ユーザーが途中まで記述している場合、ソースコードには必ず構文エラーが含まれるため）。
## 主要なリクエストタイプ：すべてシンボルテーブルと AST のクエリ
LSP におけるすべてのリクエストは、コンパイラフロントエンドのデータ構造に対するクエリです。
| リクエスト | 対応するコンパイラフロントエンド | クエリ内容 |
|------|---------------|-----------|
| `textDocument/completion` | シンボルテーブル + 型システム | 現在のスコープ内で、どのような名前が見えるか？それぞれの型とドキュメントは？ |
| `textDocument/definition` | シンボルテーブル | この識別子の定義はどの行にあるか？ |
| `textDocument/references` | シンボルテーブル（逆引き） | この定義はどの場所で参照されているか？ |
| `textDocument/hover` | シンボルテーブル + 型システム | この識別子の型は何？ドキュメントコメントには何が書かれているか？ |
| `textDocument/signatureHelp` | 型システム | 現在関数の引数リストとオーバーロードは？現在の引数は何番目か？ |
| `textDocument/rename` | シンボルテーブル（全参照） | この定義へのすべての参照の名前を新しい名前に変更する |
| `textDocument/publishDiagnostics` | 意味解析（型チェック） | このファイルにはどのような型エラーや未使用変数があるか？ |
**すべての機能は [シンボルテーブル](/compilers/03-semantic-analysis/01-symbol-tables-and-scopes.md) に由来します。** `definition` はシンボルテーブルの1回のルックアップ、`references` はシンボルの使用リスト、`completion` は現在のスコープにおけるシンボルテーブルの列挙、`hover` はシンボルの型とドキュメント文字列です。もしシンボルテーブルが「この名前がどこで参照されているか」という逆引きインデックスを保持していなければ、`references` や `rename` は効率的に行えません。そのため、シンボルテーブルの構築時には双方向の（定義から参照へ、参照から定義へ）データ構造を用います。
## インデックス：ファイルを開く前に、そのファイルが何をエクスポートしているかを知る
大規模プロジェクトでは数千ものファイルが存在し、ユーザーが `main.rs` を開いた時点で、Language Server がプロジェクト全体を解析している余裕はありません。そのため、**永続化されたインデックス**が必要です。
rust-analyzer は salsa（増分計算フレームワーク）を用いてこのインデックスを管理しており、変更が生じた場合でも影響を受けたファイルのみを再計算し、影響のないファイルはキャッシュから直接取得します。これが IDE の応答を <100ms に維持できる理由です——全量再計算ではなく、増分更新を行っているためです。
## エラー許容パーサ：構文エラーのある入力に対して結果を出力する
ユーザーが入力している間（`let x = some_struct.` など）、ソースコードは必然的に不完全です。パーサは `some_struct.` の後のドットを見て、フィールド名を期待しますが EOF（ファイル終端）に遭遇します。コンパイラはこの段階でエラーを出力して処理を停止します。しかし Language Server は**停止できず、エラーから回復して `.` の後に続く可能性のあるフィールドの補完を出力しなければなりません**。
これには、[AST 設計とエラー回復](/compilers/02-syntax-analysis/03-ast-design-and-error-recovery.md) で述べられたエラー回復の仕組みが必要です。不完全な式を見つけたパーサは、依然としてその式の AST ノードを構築し（エラーとしてマーク）、上位の意味解析はこの「エラーを含む AST」に対して部分的な型推論を行います。`some_struct` の型情報からフィールドリストを取得し、補完候補として返します。
```
ユーザー入力: let x = some_struct.
パーサ出力: Expr::Field { object: "some_struct", field: }
意味解析: シンボルテーブルから some_struct の型を参照 → StructFoo { a: i32, b: String }
補完: [a: i32, b: String]
```
エラー回復がなければ補完は存在しません——これら2つは Language Server において**一対の機能**です。区別できるのは「現在のトークンが完全な式である場合」と「現在のトークンが構文エラーである場合」だけであり、後者の場合、パーサが出力する AST ノードに「フィールドが欠落している」ことを示すフラグを設けることで、意味解析側がユーザーがその位置での補完を期待していることを知ることができます。
## Semantic Tokens: 構文ハイライトの別の実装方法
従来のハイライトは正規表現マッチ（Treesitter の `highlights.scm`）を用いていましたが、正規表現には意味の知識がありません。`foo` は `let foo = ...` 内では変数定義、`foo()` 内では関数呼び出し、`fn foo()` 内では関数宣言です。LSP の `textDocument/semanticTokens/full` は、**各トークンに意味カテゴリ（variable、function、keyword、type、comment...）を割り当て**、IDE がそのカテゴリに基づいて色付けを行います。
Language Server は AST とシンボルテーブルを用いて、各トークンに意味カテゴリを割り当てます。これには、レキサが出力するトークンが十分な情報を持っていること（識別子か？シンボルテーブルの逆引きで変数か関数か型か？）か、あるいは意味解析によって追加で注釈が付けられる必要があります。
## アーキテクチャ：シングルスレッド、マルチスレッド、増分スケジューリング
産業用の Language Server（rust-analyzer、clangd）の典型的なアーキテクチャは以下の通りです。
デバウンスとキャンセルはパフォーマンスの生命線です。ユーザーが高速に入力している間、`on_type` の頻度は1文字あたり約100ms です。もし1文字ごとにファイル全体を全量解析すると、Language Server は確実にフリーズします。デバウンスは「連続した N 回の入力」を「最後の入力の後に解析」にまとめ、キャンセルは古くなった中間結果を破棄します。
## 参考
- **LSP 3.17 specification**: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/
- **rust-analyzer**: https://github.com/rust-lang/rust-analyzer — Rust LSP サーバーのアーキテクチャドキュメントとソースコード
- **Clangd**: https://clangd.llvm.org — Clang フロントエンドに基づく C/C++ 用 LSP サーバー
*Keywords: LSP, Language Server Protocol, JSON-RPC, completion, go-to-definition, find-references, hover, diagnostics, semantic tokens, incremental parsing, index, debounce, cancellation, error-tolerant parsing, symbol table reverse lookup, rust-analyzer, clangd*