Claude Codeのコードインテリジェンス(LSP)活用ガイド
Claude Codeのコードインテリジェンスプラグインは言語サーバーをClaudeに繋ぎ、定義ジャンプと自動診断でgrep頼みの探索を置き換えます。対応言語・導入手順・チーム展開・トラブル対処までまとめます。
Claude Codeのコードインテリジェンスとは何か
Claude Codeのコードインテリジェンスとは、言語サーバー(Language Server Protocol、VS Codeの補完や定義ジャンプを支えるのと同じ技術)をClaudeに接続するプラグイン群です。導入すると、Claudeはシンボルの定義へジャンプする・参照を探す・型エラーを見るといった操作を、ファイルツリーを総当たりでgrepする代わりに言語サーバーへの問い合わせで済ませられるようになります。
大規模なコードベースでありふれた関数名をgrepすると、何百件もヒットすることがあります。Claudeはそのうちどれが本命かを判断するために候補ファイルを開いて回るしかなく、そのたびにコンテキストと時間を消費します。言語サーバーは同じシンボルを指す参照だけを正確に返すため、Claudeが何かを読む前の段階で候補が絞り込まれます。定義へのジャンプ1回が、grepと複数候補ファイルの読み取りをまとめて置き換える計算です。
この仕組みを支えるのはLanguage Server Protocol(LSP)そのものです。VS Codeやその他のエディタが補完・定義ジャンプ・ホバー情報を実装するのに使っているプロトコルと同じもので、Claude Codeは内蔵のLSPツールを通じてこのプロトコルを話す言語サーバーへ接続します。エディタ用に言語サーバーをすでに導入している開発環境であれば、Claude Code側で新しい仕組みを覚える必要はなく、既存の言語サーバー資産にそのまま相乗りする形になります。
言語ごとのプラグインと必要なバイナリ
公式マーケットプレイス(claude-plugins-official)には、主要言語向けのコードインテリジェンスプラグインが11種類用意されています。プラグイン自体は言語サーバーへの接続設定だけを持ち、言語サーバー本体のバイナリは各自のマシンに別途インストールする必要があります。
| 言語 | プラグイン名 | 必要なバイナリ |
|---|---|---|
| TypeScript | プラグイン名typescript-lsp | 必要なバイナリtypescript-language-server |
| Python | プラグイン名pyright-lsp | 必要なバイナリpyright-langserver |
| Go | プラグイン名gopls-lsp | 必要なバイナリgopls |
| Rust | プラグイン名rust-analyzer-lsp | 必要なバイナリrust-analyzer |
| C/C++ | プラグイン名clangd-lsp | 必要なバイナリclangd |
| C# | プラグイン名csharp-lsp | 必要なバイナリcsharp-ls |
| Java | プラグイン名jdtls-lsp | 必要なバイナリjdtls |
| Kotlin | プラグイン名kotlin-lsp | 必要なバイナリkotlin-language-server |
| Lua | プラグイン名lua-lsp | 必要なバイナリlua-language-server |
| PHP | プラグイン名php-lsp | 必要なバイナリintelephense |
| Swift | プラグイン名swift-lsp | 必要なバイナリsourcekit-lsp |
表にない言語向けには、自分でLSPプラグインを作成する経路も用意されています。すでに対象言語の言語サーバーをエディタ用に導入済みなら、プロジェクトを開いたときにClaudeが対応プラグインのインストールを提案してくることもあります。
導入すると何ができるようになるか
言語サーバーが動き出すと、Claudeは2つの能力を得ます。1つは自動診断です。Claudeがファイルを編集するたびに、言語サーバーがエラーや警告を返してくるため、コンパイラやリンターを別途走らせなくても型エラーやインポート漏れに気づけます。Claude自身がミスを埋め込んだ場合も、同じターン内で気づいて直せます。
もう1つはコードナビゲーションです。定義へのジャンプ、参照の検索、ホバーでの型情報取得、シンボル一覧、実装の検索、呼び出し階層の追跡が、言語サーバー経由で行えるようになります。grepベースの検索より精度の高いナビゲーションですが、対応の充実度は言語や環境によって差があります。
診断結果を自分の目で確認したい場合は、Claude Codeが「Found 3 new diagnostic issues in 2 files」のような表示を出したタイミングでCtrl+Oを押します。診断のための追加設定は不要で、プラグイン導入だけで有効になります。ただしクラウドセッション(Claude Code on the web)ではプラグインの言語サーバー自体が起動しないため、診断もナビゲーションも使えません。
以下の早見表で、効く場面と効かない場面を切り分けておくと導入判断がしやすくなります。
| 場面 | 効くか |
|---|---|
| ローカルのターミナル・IDE拡張での定義ジャンプ・参照検索 | 効くか効く |
| ファイル編集直後の型エラー・インポート漏れの自動診断 | 効くか効く |
| 表にある11言語(バイナリ導入済み)でのシンボル一覧・呼び出し階層 | 効くか効く |
| Claude Code on the web(クラウドセッション) | 効くか効かない(言語サーバーが起動しない) |
| バイナリ未導入の言語・環境 | 効くか効かない(プラグインだけでは動かない) |
| モノレポでワークスペース設定が未整備な内部パッケージimport | 効くか誤検知が出ることがある |
インストール手順とチーム展開
個人で試すだけなら、Claude Codeセッション内で1コマンド実行するだけです。
/plugin install typescript-lsp@claude-plugins-officialインストールが失敗した場合は表示されるメッセージで原因が分かれます。Marketplace "claude-plugins-official" not foundと出たら/plugin marketplace add anthropics/claude-plugins-officialでマーケットプレイスを追加してから再実行します。プラグイン名が見つからないというメッセージなら、名前の綴りを見直します。マーケットプレイスからのインストールにはGitHubへのネットワークアクセスが要るため、アクセスが制限された社内ネットワークでは、内部Gitホストやローカルパスからマーケットプレイスを追加する経路に切り替えます。
リポジトリの全員に同じプラグインを有効化したい場合は、.claude/settings.jsonのenabledPluginsプロジェクト設定に追加します。ただしenabledPluginsはあくまで「有効化する」という宣言であり、インストールそのものを肩代わりするものではありません。claude-plugins-officialはGitHubでホストされた外部ソースのマーケットプレイスのため、他の開発者のマシンにこの設定だけでプラグインが入るわけではなく、そのプラグインは「未インストール」と表示され、claude plugin installの実行が案内されます。
{
"enabledPlugins": {
"typescript-lsp@claude-plugins-official": true
}
}この設定はコミットしてリポジトリで共有できますが、各開発者はそれぞれ自分のマシンでclaude plugin installによるプラグイン本体のインストールと、言語サーバーのバイナリ導入という2つの作業が必要です。オンボーディング手順には「①プラグインのインストール」「②言語サーバーのバイナリ導入」の2項目を明記しておくと導入時のつまずきが減ります。
enabledPluginsはどの設定ファイルに書くかでスコープが変わります。個人の好みなら自分の~/.claude/settings.json、リポジトリ全員に共有するならプロジェクトの.claude/settings.json、マシン単位の一時的な上書きなら.claude/settings.local.jsonです。組織の管理設定でプラグインをfalseに固定すると、どのスコープからもインストールできなくなり、マーケットプレイスの一覧からも隠れます。
導入後に「このプラグイン、誰か使っているのか」を確認したくなったら、/pluginの「Installed」タブに「Not used recently」という区分があります。言語サーバーは、診断を返すかナビゲーション要求に答えるだけで使用中とみなされるため、バックグラウンドで動いているLSPプラグインは「Not used recently」の一覧には並びません。
grep主体の探索とどう組み合わせるか
コードインテリジェンスは、ファイル読み取りを絞る他の設定と組み合わせると効果が重なります。生成物やベンダーコードへのRead拒否ルール、パッケージ単位のsparsePathsといった除外設定は「読ませない範囲」を減らす側で、コードインテリジェンスは「残った範囲の中で何かを探す手間」を減らす側です。この2つを合わせた設定例はClaude Codeのコンテキスト管理にまとめています。
対話の進め方そのもの、つまり広い質問から徐々に絞り込むという型は、コードインテリジェンスの有無にかかわらず有効です。Claude Codeで大規模コードベースを探索するコツの3段階と組み合わせると、初日から実行フローの追跡までスムーズに進みます。パッケージ単位で権限や規約を分けているモノレポでは、Claude Codeモノレポ設計のディレクトリ構成と合わせて、パッケージごとに使う言語のプラグインだけを有効化する運用が現実的です。
よくあるトラブルと対処
言語サーバーが起動しない場合、対象言語のバイナリが実際にインストールされ$PATHから見えているかを確認します。/pluginのErrorsタブに詳細が出るので、まずそこを見ます。Executable not found in $PATHと表示されている場合はバイナリ未インストールが原因です。
メモリ使用量が大きい場合、rust-analyzerやpyrightのような言語サーバーは大規模プロジェクトで相応のメモリを消費します。問題が出るなら/plugin disable <plugin-name>でプラグインを無効化し、Claude組み込みの検索ツールに切り替えます。
モノレポで見せかけの診断エラーが出る場合、ワークスペースの設定が整っていないと、内部パッケージへのimportが未解決エラーとして報告されることがあります。この種の誤検知はClaudeの編集能力そのものには影響しません。
プラグインのスキルが表示されない場合、rm -rf ~/.claude/plugins/cacheでキャッシュを消してからClaude Codeを再起動し、プラグインを入れ直します。
よくある質問
コードインテリジェンスプラグインは無料で使えますか
プラグイン自体の追加費用はありません。言語サーバーのバイナリもほとんどがオープンソースで無償配布されています。マシンのCPU・メモリを消費する点はコストとして考慮します。
複数の言語プラグインを同時に有効化できますか
できます。TypeScriptとPythonが混在するリポジトリなら、両方のプラグインをenabledPluginsに並べて登録すれば、それぞれのファイルを開いたときに対応する言語サーバーが動きます。
ローカルとクラウドセッションで挙動は違いますか
違います。ローカルのターミナルやIDE拡張ならプラグインが言語サーバーのプロセスをマシン上で起動できますが、ブラウザから使うクラウドセッションはその起動元がありません。同じリポジトリでも、開く環境によって診断やナビゲーションの有無が変わる点は覚えておきます。
独自の内製言語や社内DSLにも対応できますか
対応する言語サーバーの実装さえあれば、自分でLSPプラグインを作成して同じ仕組みに乗せられます。既存の11言語向けプラグインの設定が参考になります。
言語サーバーを止めたら診断機能はどうなりますか
/plugin disableでプラグインを無効化すると、自動診断もコードナビゲーションも両方止まります。Claudeは組み込みのRead・Grep・Globツールでの探索に戻るため、機能自体が使えなくなるわけではなく、絞り込みの精度が下がる形です。
まとめ
Claude Codeのコードインテリジェンスは、言語サーバーをClaudeに繋いで定義ジャンプと自動診断を使えるようにするプラグイン機構です。対象言語のプラグインと言語サーバーのバイナリを両方インストールする必要がある点、クラウドセッションでは使えない点を押さえておけば、大規模なコードベースでのgrep依存を大きく減らせます。個人で試すなら/plugin install一発、チーム展開するならenabledPluginsへの追加が入り口です。