Agentic codingツールであるClaude Codeは、コードベース全体に対してコードの記述、リファクタリング、デバッグが可能です。しかし、デフォルトではgrepと同じようにコードをプレーンテキストとして読み取ります。

Language Server Protocol（LSP）はそれを変えます。これはIDEが使用するのと同じコードインテリジェンス層であり、エージェントに組み込むことで、文字列マッチではなく意味に基づいてコードを読み取れるようになります。コードベースが大きいほど、シンボルに関する誤った推測のコストは高くなり、構造的なビューによる恩恵も大きくなります。

Claude CodeのLSPサポートが組み込まれました。ここでは、LSPとは何か、なぜ役立つのか、そして数分で試す方法を紹介します。

Language Server Protocol（LSP）とは？

How Language Server Protocol (LSP) works diagram

Language Server Protocol（LSP）は、JSON-RPC標準であり、Visual Studio CodeのためにMicrosoftが作成し、2016年にオープンソース化したものです。これにより、任意のエディタが言語サーバーと通信し、コードインテリジェンス（定義への移動、参照の検索、ホバータイプ、診断、安全な名前変更）を提供できます。1つのサーバーが多くのエディタで動作するため、各エディタが各言語ごとにこれらの機能を再構築する必要がなくなります。

LSP以前は、すべてのエディタがすべての言語に対して独自の統合が必要でした。10個のエディタと10個の言語では100個の別々の実装が必要でした。LSPでは、各言語が1つのサーバーを提供し、各エディタが1つのクライアントを提供し、共通のプロトコルで通信します。Go言語サーバーを一度作成すれば、Neovim、VS Code、Emacs、Claude Codeのすべてで利用できます。

言語サーバーが実際の作業を行います。ソースコードを構文木と完全なシンボルテーブルに解析し、コンパイラが答えるような方法で質問に答えます。関数の定義場所を尋ねると、名前を含むすべての行ではなく、本当の1つの定義が返されます。

同じサーバーは、コードの変更に伴う型エラーや未インポートを報告し、シンボルが使用されるすべての場所をリストアップし、プロジェクト全体で安全に名前変更を行います。これらは定義への移動、参照の検索、タイポの下の赤い波線の背後にある操作です。

Claude CodeでLSPを使う理由

LSPはClaude Codeに役立ちます。なぜなら、確率的なテキスト検索を決定論的でコンパイラレベルの正確な回答に置き換えるからです。実質的に、エージェントにIDEでの開発者が持つ目を与えます。

LSPがない場合、エージェントはファイルを読み込み、テキスト検索を実行することでコードベースを探索します。これは機能しますが、推測です：createUserをgrepすると、エージェントは定義、呼び出し、コメント、同じ名前を持つ無関係なシンボルを取得し、どれがどれかを推論する必要があります。各推測はトークンを消費し、誤った編集のリスクを伴います。

言語サーバーは推測を排除します。単一の定義、参照の正確なリスト、任意の位置での解決された型を返します。

How Claude Code uses LSP to enhance efficiency diagram

LSPはプロジェクトの型グラフをメモリに保持しているため、編集によって導入された型エラーや未インポートをミリ秒単位で報告します。

大規模プロジェクトでは、完全な型チェックに数十秒かかることがあり、変更のたびに繰り返すには遅すぎます。言語サーバーはClaudeに同じシグナルを増分的に提供するため、後でビルドに失敗するコードを出荷するのではなく、同じターンで破損を修正できます。

同じチェックは幻覚的なAPIを抑制します：存在しない関数への呼び出しは、もっともらしい見た目のナンセンスにコンパイルされるのではなく、診断として表示されます。

Claude Codeは組み込みのLSPツールとCode Intelligenceプラグインを通じて言語サーバーに接続します。CIでの実際の型チェックやテスト実行を置き換えるものではありませんが、最も安価に修正できる時点で明らかな失敗をキャッチします。

Claude CodeでのLSPの設定

この例ではTypeScript LSPを設定しますが、同じフローを使用している言語サーバーにも適用できます。Claude Codeは11の言語向けの公式プラグインを提供しており、Python、Go、Rust、Java、TypeScriptが含まれます。各言語はそれぞれ独自のバイナリを$PATHに必要とします。プラグインマーケットプレイスに現在のセットがリストされています。

Claude CodeでのLSPの設定は3つのコマンドで行います：言語サーバーのインストール、一致するプラグインのインストール、リロードです。プラグインはLSP経由でTypeScript自身のtsserverを公開するコミュニティサーバーであるtypescript-language-serverをラップします。

まず、サーバーバイナリをインストールして$PATHに配置します：

npm install -g typescript-language-server typescript

次に公式のコードインテリジェンスプラグインを追加してリロードします：

/plugin install typescript-lsp@claude-plugins-official
/reload-plugins

コードインテリジェンスプラグインをインストールすると、Claude Codeの組み込みLSPツールが有効になり、バイナリが$PATHに配置されると、TypeScriptプロジェクトを開くだけで追加設定なしでClaudeが言語サーバーに接続されます。

独自のCode Intelligenceプラグインの作成

11の公式プラグインは人気の言語をカバーしていますが、言語サーバーを持つ任意の言語を接続できます。Claude Codeはプラグインのルートにある.lsp.jsonファイル、またはplugin.jsonのlspServersフィールドからLSP設定を読み取ります。これはサーバー名を起動コマンドと処理するファイル拡張子にマッピングします。最小限のGoエントリは次のようになります：

{
  "go": {
    "command": "gopls",
    "args": ["serve"],
    "extensionToLanguage": { ".go": "go" }
  }
}

commandとextensionToLanguageのみが必須フィールドです。args、transport（デフォルトはstdio、またはsocket）、env、initializationOptionsはオプションです。commandを$PATH上の任意のLSPバイナリに向け、処理する拡張子をリストすると、Claudeはその言語に対して同じ診断とナビゲーションを取得できます。プラグインリファレンスに完全なスキーマが記載されています。

LSP vs grep：精度、トークン、および価値がある場合

Claude CodeがLSPを使用することで得られるものを理解するには、LSPを使用するClaudeとgrepを使用するClaudeのパフォーマンスを見る必要があります。言語サーバーがない場合、Claudeの組み込みコード検索はプレーンテキスト（コンテンツはgrep、ファイル名はglob）であるため、すべてのナビゲーション質問は文字列マッチになります。

LSPがgrepを上回るかどうかは、主にコードベースのサイズと複雑さに依存します：大規模でレガシー、または複数言語にまたがるリポジトリが最も恩恵を受け、小規模で整理されたプロジェクトでは違いが少ないことが多いです。2つは競合ではありません。LSPは意味的な質問（どこで定義されているか、何が呼び出しているか、この名前変更は安全か）に答え、grepはTODOコメントや設定文字列のようなリテラルテキストに適したツールです。

大まかな判断基準は次のとおりです：

LSPを使用する場合 grepで十分な場合
リポジトリが大規模、レガシー、または複数言語にまたがる場合 プロジェクトが小規模で馴染みがある場合
タスクがリファクタリング、名前変更、または呼び出し箇所の追跡の場合 ターゲットがリテラル文字列またはパターンの場合
誤ったシンボル編集を後で発見するコストが高い場合 迅速なテキストマッチで質問に答えられる場合

最も明確な利点は精度です。LSPはコンパイラのシンボルグラフから回答するため、grepが返す同名のメソッド、コメント、文字列リテラルをスキップして、参照の正確なセットを返します。grepはエージェントが読み取ってフィルタリングする必要があるスーパーセットを返すため、大規模なリポジトリではトークンを消費します。これが実際にどれだけ重要かを確認するため、独自のテストを実行しました。

テスト実施：2つのモデルでのLSP vs grep

Claude Code Intelligence comparing grep vs LSP benchmarking results

Claude Codeをvuejs/core（TypeScript約149K行）に対して実行し、重複ロードされたリアクティビティシンボルのすべての呼び出し箇所を、Opus 4.8とSonnet 4.6の両方で検索するよう依頼しました。

LSPをネイティブに使用することは、その仕事に任せることを意味します。Claudeはデフォルトでgrepを使用するため、プロジェクトのCLAUDE.mdに1つの指示を追加しました：

“For symbol navigation, prefer the LSP tool over grep; use grep only for literal text; and trust the language server's results rather than re-reading files to confirm them.”

最後の句は方法であり、脚注ではありません。LSPからの出力を信頼しなければ、ClaudeはfindReferencesを呼び出してからすべてのファイルを再オープンしてダブルチェックし、grepよりも多くのトークンを消費することになります。信頼されれば、言語サーバーは構築された通りのことを行えます。

ベンチマークから2つの結果が際立ちました。第一に、LSPは唯一ミスをしなかった構成でした。 Opusはどちらのツールでも正しく回答しましたが、Sonnetはgrepのみで他のパッケージの2つのtrigger参照をミスし（11中9）、effectを過小評価しました（260中249）。言語サーバーを使用すると、Sonnetはすべてのタスクですべての参照を見つけました。

モデルが弱いほど、LSPの助けが大きくなります。信頼性の最低限を果たします。

第二に、ネイティブに使用した場合、LSPは最も困難な作業でも安価でした。 大規模でノイズの多いeffectタスクでは、両方のモデルでgrepよりも安価に260の呼び出し箇所すべてを見つけました（Opusで$0.50対$0.62、Sonnetで$0.24対$0.29）。ツール出力は2〜3倍スリムでした。なぜならfindReferencesは正確なセットを返し、grepはフィルタリングが必要な山を返すからです。

小規模なタスクでは2つのコストはほぼ同じで、LSPの唯一の固定オーバーヘッドはそれをロードするための単一のツール検索呼び出しでした。6つのタスクすべてで、LSPは価格とトークン使用量で優位でした：$1.88対grepの$2.02。

以下にモデルごとの内訳を示します。

Opus 4.8 LSP vs grep ベンチマーク

タスク（正解） ツール 時間 コスト ツール出力トークン
trigger (11) grep 70s $0.39 3,041
trigger (11) LSP 74s $0.40 3,666
track (20) grep 40s $0.25 2,868
track (20) LSP 56s $0.32 2,970
effect (260) grep 131s $0.62 12,764
effect (260) LSP 117s $0.50 6,280
合計 grep 241s $1.26 18,673
合計 LSP 247s (+2%) $1.22 (-3%) 12,916 (-31%)

モデル強度によって言語サーバーの価値が変わるため、両方のモデルで同じ3つのタスクを実行しました。Opusでは、利点はトークン節約に集中しています。しかしSonnetでは、LSPがすべての合計で優位であることがわかります。

Sonnet 4.6 LSP vs grep ベンチマーク

タスク（正解） ツール 時間 コスト ツール出力トークン
trigger (11) grep* 100s $0.23 2,577
trigger (11) LSP 97s $0.28 1,733
track (20) grep 101s $0.25 3,808
track (20) LSP 49s $0.14 491
effect (260) grep** 158s $0.29 6,212
effect (260) LSP 92s $0.24 6,256
合計 grep 359s $0.77 12,597
合計 LSP 238s (-34%) $0.66 (-14%) 8,480 (-33%)

すべての実行で参照が見つかりましたが、Sonnetでの2回のgrep実行を除く：*11中9が見つかった、**260中249が見つかった。

LSPのコスト：メモリ、コールドスタート、設定

LSPは無料ではありません：

  1. メモリ：言語サーバーはプロジェクトのシンボルグラフをメモリに保持します。rust-analyzerは大規模なワークスペースで数ギガバイトを一般的に使用し、pyrightのような重量級サーバーも同じ傾向に従います。
  2. コールドスタート：サーバーは最初の回答の前にコードベースをインデックスします。大規模モノレポの新規チェックアウトでは数分かかることがあり、その間のクエリは遅いか空で返ってきます。
  3. 設定：各言語は独自のサーバーバイナリを$PATHに必要とし、サーバーはプロジェクトルートを基準にするため、リポジトリルートの1レベル下のTypeScriptワークスペースではサーバーがまったくアクティブにならない場合があります。長いセッションはブランチ切り替えやコード生成の後で古くなり、再起動が必要になることがあります。

小規模で整理されたコードベースでは、エージェントはほとんどのファイルを安価に読み取れるため、LSPはプロジェクトが成長するにつれてその価値を発揮します。

結論

LSPはClaudeの内部ループをコンパイラレベルの正確なロジックに基盤づけることで、コード作成を効率化します。テキスト検索の推測に時間を浪費する代わりに、エージェントはコードベースを構造的にナビゲートし、より高速に正確な編集を提供します。

この基盤が整ったら、即時検証をエージェントワークフローに導入することでさらに進化できます。Claude CodeとCircleCIのChunk CLIを組み合わせることで、Chunkサイドカー——軽量で分離されたmicroVM——をエージェントのすぐそばで実行できます。

これにより、開発ループに強力な相乗効果が生まれます：

  • LSPはClaudeに、初回で正確なコードを書くための構造的インテリジェンスを提供します。

  • Chunkサイドカーは、ターゲットを絞ったマイクロビルドとユニットテストをその場で実行するための即時サンドボックスを提供します。

テストが失敗した場合、ClaudeはLSPを活用したコードベースの理解を即座に活用してログを読み、リアルタイムで自己修復します。2つを組み合わせることで、コードの記述と検証のギャップを埋め、1つの破損したコミットもリスクなく、ライトニングスピードでエージェントを動かします。

無料のCircleCIアカウントに今すぐサインアップして、Chunk CLIを試し、LSPを活用したエージェントワークフローを強化してください。