Claude Code がひっそりとアップグレード、ついに"テキスト検索マシン"ではなくなった

コードを書くとき、こんなことを考えたことはありませんか？

なぜ VS Code で Ctrl + クリックすると、関数の定義に直接ジャンプできるのか？ なぜ関数にマウスオーバーすると、完全なパラメータの説明が表示されるのか？ なぜコードを実行する前に、エディタがどこが間違っているかを教えてくれるのか？

これらの機能を毎日使っていて、とても快適です。

しかし、その背後には LSP (Language Server Protocol) というものが支えていることを知らないかもしれません。

さらに重要なことに、Claude Code 2.0.74 バージョンから、LSP をサポートするようになりました。

これは何を意味するのでしょうか？

Claude Code がついに "テキスト検索マシン" から、コードを本当に理解する AI になったことを意味します。

LSP とは？わかりやすく言うと

LSP はマイクロソフトが作ったプロトコルで、目的は簡単です。

コードのインテリジェンス機能をどのエディタでも使えるようにすることです。

見てください：

• TypeScript の言語サーバーは、VS Code で使え、JetBrains で使え、Cursor で使える

• 今、Claude Code でも使える

LSP はあなたのエディタを賢くするものです：

• 関数名とパラメータの自動補完

• 定義へのジャンプ

• すべての参照を検索

• マウスオーバーでドキュメントを表示

• リアルタイムのエラーと警告

毎日コードを書いていて、これらの機能を何度も使っています。

しかし、それがどのように実現されているのか考えたことはないでしょう。

もう考える必要はありません。Claude Code にもこれらの能力が備わったことを知っておけば十分です。

Claude Code は以前どのように動作していたのか？

LSP をサポートする前、Claude Code が関数の定義場所を探すにはどうしていたのでしょうか？

grep 検索に頼っていました。

つまり、全テキスト検索で、"displayBooks" という文字列がどこにあるかを探していたのです。

これは使えるのでしょうか？使えます。

AI モデルは大量のコードを学習しているので、テキストから多くのことを推測できます。

しかし、問題はどこにあるのでしょうか？

コードの構造を本当に理解していないのです。

まるで、誰かに "張三" を探させるようなもので、彼は連絡先を 1 ページずつめくって "張三" という文字を探すしかありません。

しかし、あなたが携帯電話で "張三" を検索すると、データベースを直接呼び出して、すぐに結果が表示されます。

これが違いです。

以前の Claude Code：ファイルごとに読み込み、テキストマッチングに頼る 現在の Claude Code：言語サーバーに直接問い合わせ、正確に位置を特定

効率は比較になりません。

LSP は Claude Code に何をもたらしたのか？

5 つのコア能力、それぞれが効率的なツールです：

1. goToDefinition - 定義へのジャンプ

VS Code で Ctrl+Click をするとどうなりますか？関数の定義場所に直接ジャンプします。

現在、Claude Code も同じことができます。

"processRequest 関数はどこで定義されていますか？LSP を使用" と尋ねます。

すべてのファイルを愚かに検索することはありません。

言語サーバーに直接問い合わせ、ファイル名、行数、正確な位置をすぐに答えます。

2. findReferences - すべての参照を検索

これはキラー機能です。

関数をリファクタリングしたいのですが、変更すると他の場所が壊れるのではないかと心配で変更できません。

どうすればいいでしょうか？

以前は、Claude Code にファイルごとに読み込ませる必要があり、非常に時間がかかりました。

現在では、"displayError 関数はどこで呼び出されていますか？LSP を使用" と直接尋ねます。

言語サーバーはすべての参照位置を直接リストアップします。

速く、正確で、的確です。

3. hover - ドキュメントと型情報を取得

VS Code でマウスオーバーすると、関数シグネチャ、パラメータ型、ドキュメントの説明が表示されます。

Claude Code も現在見ることができます。

"displayBooks 関数はどのようなパラメータを受け入れますか？LSP を使用" と尋ねます。

推測する必要はなく、言語サーバーから返されたシグネチャを直接読み取ります。

特に Python のような動的言語では、以前は Claude はコンテキストから型を推測するしかありませんでした。 現在、LSPによりタイプ情報が一目瞭然です。

4. documentSymbol - ファイル内のすべてのシンボルをリストアップ

ファイル内にどのようなクラス、関数、変数が存在するかを素早く知りたいですか？

Claudeに「backend/index.jsにはどのようなシンボルがありますか？LSPを使って」と尋ねてください。

構造化されたリストが返され、明確に表示されます。

5. workspaceSymbol - プロジェクト全体のシンボル検索

これはさらに強力です。

テキストを検索するのではなく、シンボルを検索します。

"innerHTML"を含むすべてのメソッドを見つけたいですか？

言語サーバーが直接見つけ出します。文字列マッチングではなく、実際のコードシンボルです。

実践：LSPは一体何の問題を解決できるのか？

抽象的な話はやめて、実際の事例を見てみましょう。

事例 1：関数呼び出しの追跡

AseBook Finderというプロジェクトがあり、フロントエンドにdisplayBooks関数があります。

この関数がどこで呼び出されているかを知りたいとします。

以前はどうしていましたか？Claude Codeでgrepをかけていましたが、見落としや誤検出の可能性がありました。

今では直接「LSPを使ってdisplayBooksのすべての参照を探してください」と尋ねます。

結果：

• 関数の定義位置

• fetch成功後に呼び出される位置

• その他すべての参照場所

正確、迅速、そして漏れがありません。

事例 2：関数パラメータの理解

ClaudeにdisplayError関数を呼び出すコードを生成させたいとします。

しかし、この関数がどのようなパラメータを受け取るか分かりません。

「displayErrorはどのようなパラメータを受け取りますか？LSPを使って」と尋ねてください。

言語サーバーが直接、messageパラメータを受け取ると返します。

Claudeはそれを理解し、生成されるコードはエラーを起こしません。

事例 3：API呼び出しの検索

プロジェクト内のどこで/api/recommendationsインターフェースが呼び出されているかを知りたいとします。

Claudeに「LSPを使って/api/recommendationsのすべての参照を探してください」と尋ねてください。

fetch呼び出しの位置を特定し、行まで正確に示します。

API問題のデバッグ、データフローの追跡に非常に役立ちます。

事例 4：事前にエラーを発見

コードをリファクタリングしている際に、誤って変数名をスペルミスしたとします。

通常、コードを実行して初めて気づきます。

しかし、LSPがあれば、言語サーバーがリアルタイムでチェックし、問題を発見するとすぐにClaude Codeに報告します。

Claudeはコードを実行する前に、ここにエラーがあると教えてくれます。

どうやって設定する？5ステップで完了

慌てないでください。設定は簡単です。

第 1 歩：LSPツールを有効にする

シェル設定ファイル（.bashrcまたは.zshrc）に次の行を追加します：

export ENABLE_LSP_TOOLS=1そしてsource ~/.zshrcを実行して有効にします。

第 2 歩：言語サーバープラグインをインストールする

Claude Codeを開き、次のように入力します：

/plugin使用している言語に対応するプラグインを見つけます：

• Python：pyright-lspを選択

• TypeScript/JavaScript：vtslsまたはtypescript-lspを選択

• Go：goplsを選択

• Rust：rust-analyzerを選択

「Install for me only」を選択してインストールします。

第 3 歩：言語サーバーのバイナリファイルをインストールする

プラグインはインターフェースに過ぎず、実際に作業を行うのは言語サーバー自体です。

Python:

pip install pyrightTypeScript/JavaScript:

npm install -g @vtsls/language-server typescriptGo:

go install golang.org/x/tools/gopls@latestRust:

rustup component add rust-analyzer

第 4 歩：Claude Codeを再起動するclaude

ステップ 5：動作確認

/pluginと入力し、"Installed"タブを確認して、プラグインが表示されていればOKです。

テストしてみましょう：

LSPを使ってsomeFunctionのすべての参照を探すもしClaude Codeがgrepではなくfind_referencesツールを使っていれば、成功です。

いつLSPを使うべきか？いつ使うべきでないか？

LSPは万能ではありません。

LSPを使うのに適した場面：

• 大規模プロジェクト（数百のファイル）

• ファイルを跨いだ関数呼び出しの追跡

• 正確な関数シグネチャが必要な場合（特に動的言語）

• コードをリファクタリングする際に、バグを発生させたくない場合

LSPを使うのに適さない場面：

• 小規模プロジェクト、簡単なスクリプト

• 簡単なテキスト検索

• 単に文字列がどこにあるかを探す場合

要するに、grepが速い場合はgrepを使い、LSPが正確な場合はLSPを使うということです。

ツールは人のためにあるのであり、使うことが目的ではありません。

いくつかの落とし穴、事前に伝えておきます

落とし穴 1：言語サーバーはPATHに入っている必要がある

もしClaude Codeが"No LSP server available"と言う場合、おそらく言語サーバーが正しくインストールされていないか、PATHに入っていません。

ターミナルでwhich pyright（またはあなたの言語サーバー）を実行して、見つかるかどうか確認してください。

落とし穴 2：プラグインをインストールしたら再起動が必要

新しいプラグインをインストールしたり、言語サーバーをアップデートしたりしたら、必ずClaude Codeを再起動してください。

言語サーバーは起動時にロードされます。

落とし穴 3：時には明確に"LSPを使う"と言う必要がある

もしClaude Codeがまだgrepを使っていて、LSPを使っていないことに気づいたら、"LSPを使う"という一言を加えてください：

LSPを使ってauthenticateUserのすべての参照を探すこれで、言語サーバーを使うべきだと認識します。

落とし穴 4：可視化されたヒントがない

VS Codeとは異なり、Claude CodeはLSPサーバーが実行されているかどうかを教えてくれません。

ステータスバーのアイコンも、通知もありません。

唯一の確認方法は、実際にテストすることです。

最後に一言

Claude CodeがLSPをサポートすることは、小さなアップデートではなく、質的な変化です。

以前は"テキスト検索 + AI推論"でした。

今は"言語サーバー + AI理解"です。

まるで電話帳をめくっていたのが、検索エンジンを使うようになったかのようです。

効率の差は、天と地ほど違います。

もしあなたがClaude Codeで本格的なプロジェクトに取り組んでいるなら、5分かけてLSPを設定してください。

この5分は、価値があります。

行動リスト：

• shellの設定にexport ENABLE_LSP_TOOLS=1を追加する

• Claude Codeを開き、/pluginを実行して言語プラグインをインストールする

• 対応する言語サーバーのバイナリファイルをインストールする

• Claude Codeを再起動する

• "LSPを使ってXXXのすべての参照を探す"をテストする

インストール後、あなたは気づくでしょう：原来 Claude Code 还能这么快。