Claude Codeのコードインテリジェンス(LSP)活用ガイド

Claude Codeのコードインテリジェンスとは何か

Claude Codeのコードインテリジェンスとは、言語サーバー(Language Server Protocol、VS Codeの補完や定義ジャンプを支えるのと同じ技術)をClaudeに接続するプラグイン群です。導入すると、Claudeはシンボルの定義へジャンプする・参照を探す・型エラーを見るといった操作を、ファイルツリーを総当たりでgrepする代わりに言語サーバーへの問い合わせで済ませられるようになります。

大規模なコードベースでありふれた関数名をgrepすると、何百件もヒットすることがあります。Claudeはどれが本命かを判断するために候補ファイルを開いて回るしかなく、そのたびにコンテキストと時間を消費します。言語サーバーは同じシンボルを指す参照だけを返すため、何かを読む前の段階で候補が絞り込まれます。

Claude Codeは内蔵のLSPツールを通じて、このプロトコルを話す言語サーバーへ接続します。エディタ用に言語サーバーをすでに導入している環境なら、同じバイナリにそのまま相乗りできます。

自分の言語で使えるか

公式マーケットプレイス(claude-plugins-official)には、13言語向けのコードインテリジェンスプラグインが並んでいます。プラグインが持つのは「どのコマンドで言語サーバーを起動し、どの拡張子を担当させるか」という接続設定だけです。言語サーバー本体のバイナリは各自のマシンに別途インストールします。

liquid-lspだけはShopifyが保守しており、公式マーケットプレイスには掲載されています。それ以外の12本はAnthropicの保守です。表にない言語向けには、後述の.lsp.jsonで自分で接続する経路があります。

導入で何が変わるか

言語サーバーが動き出すと、Claudeは2つの能力を得ます。

1つ目は自動診断です。Claudeがファイルを編集するたびに、言語サーバーがエラーや警告を返します。コンパイラを別途走らせなくても、Claude自身が埋め込んだ型エラーやインポート漏れに同じターンで気づけます。

2つ目はコードナビゲーションです。LSPツールは読み取り専用で、次の操作をサーバー経由で行います。

• シンボルの定義へジャンプする
• シンボルへの参照をすべて探す
• 指定位置の型情報を取る
• ファイル内のシンボルを一覧する
• ワークスペース全体でシンボルを名前検索する
• インターフェースの実装を探す
• 呼び出し階層をたどる

権限の面では、Read(~/secrets/**)のような拒否ルールはRead・Grep・Globに加えてLSPにも適用されます。読ませたくないパスは、grepだけでなく言語サーバー経由の探索からも外れます。

ローカルのターミナルセッションで使えます。クラウドセッション(Claude Code on the web)ではプラグインの言語サーバー自体が起動しないため、診断もナビゲーションも得られません。バイナリが未導入の言語では、対応するファイルへのLSP呼び出しがエラー結果になります。

導入手順とチーム展開

導入は「バイナリ → プラグイン → 起動確認」の順です。バイナリを先に入れておくと、確認の段階で迷いません。

Marketplace "claude-plugins-official" not foundと出たら、/plugin marketplace add anthropics/claude-plugins-officialでマーケットプレイスを追加して再実行します。VS Code拡張だけを使ってきた環境や、CLAUDE_CODE_DISABLE_OFFICIAL_MARKETPLACE_AUTOINSTALLを設定した環境では、公式マーケットプレイスが自動登録されません。claude pluginのシェルコマンドも登録はしないので、手動で追加します。

診断の中身を読みたいときは、この行が出た時点でCtrl+Oを押します。診断のための追加設定は要りません。

チームで揃える

リポジトリの全員に同じプラグインを有効にしたい場合は、プロジェクトの.claude/settings.jsonにenabledPluginsを書きます。

{
  "enabledPlugins": {
    "typescript-lsp@claude-plugins-official": true
  }
}

この設定をコミットしても、他の開発者のマシンにプラグインがダウンロードされるわけではありません。各自がclaude plugin install typescript-lsp@claude-plugins-official --scope projectを1回実行し、言語サーバーのバイナリも入れる必要があります。オンボーディング手順には「プラグインのインストール」と「言語サーバーのバイナリ導入」の2項目を書いておくと、つまずきが減ります。

enabledPluginsはどの設定ファイルに書くかでスコープが変わります。ユーザー設定の~/.claude/settings.jsonは自分の全プロジェクト、プロジェクトの.claude/settings.jsonはリポジトリの全員、.claude/settings.local.jsonは自分とそのリポジトリだけです。同じプラグインを複数のスコープで設定した場合は、ローカル、プロジェクト、ユーザーの順に優先されます。

導入を提案するダイアログの挙動

言語サーバーのバイナリがすでにPATHにあり、対応プラグインが未導入だと、Claudeがファイルを編集した後に「LSP plugin recommendation」ダイアログが出ることがあります。1セッションに1回までで、最初にマッチしたファイルの編集時だけです。クラウドセッションにつないだ端末には出ません。

選択肢は「Yes, install」「No, not now」「Never for this plugin」「Disable all LSP recommendations」の4つです。「Yes, install」を選ぶと<plugin> installed · restart to applyと出るので、新しいセッションを始めると有効になります。

30秒何も選ばないと「無視」と数えられます。この回数はセッションをまたいで通算され、5回になると推奨自体が止まります。止まった推奨を戻す手順はLSPプラグイン推奨ダイアログの止め方と戻し方にあります。

表にない言語は.lsp.jsonで繋ぐ

対応プラグインがない言語でも、言語サーバーがあれば自作のプラグインで繋げます。プラグイン直下の.lsp.jsonに、サーバー名をキーにして設定を書きます。必須なのはcommandとextensionToLanguage(拡張子と言語IDの対応。キーは.で始める)の2つです。

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

任意の項目にも、運用に効くものがあります。diagnostics(編集後に診断をコンテキストへ流すか。既定はtrue)、restartOnCrash(クラッシュ後に再起動するか。既定はtrue)、startupTimeout(起動待ちのミリ秒)などです。プラグインのマニフェストのlspServersキーに同じ設定を書くこともできます。

全項目の解説と自作プラグインの作り方は、Claude Codeプラグインに独自のLSPサーバーを組み込むが扱っています。ここでは導入と運用の切り分けに絞ります。

自作の設定はclaude plugin validateで確かめられます。v2.1.285で、マニフェストのlspServersにわざと誤りを入れて実行した結果が次のとおりです。

# 未定義のキーを混ぜた場合
  ❯ lspServers.go: Unrecognized key: "bogus"
✘ Validation failed
 
# commandに引数まで書いた場合("go pls")
  ❯ lspServers.go.command: Command should not contain spaces. Use args array for arguments.
✘ Validation failed
 
# extensionToLanguageのキーに"."を付け忘れた場合(公式の説明では、キーは"."で始める)
  ❯ lspServers: Invalid input
✘ Validation failed

引数はcommandに混ぜず、argsに分けます。3つ目のエラーは原因を名指ししないので、拡張子のキーが".go"の形か真っ先に見ます。

注意点が2つあります。まず、claude plugin validateが検証するのはマニフェストに書いたlspServersのほうで、.lsp.jsonは読みません。.lsp.jsonの中に不正なエントリが1つでもあると、ファイル全体が読み込まれず、/pluginのErrorsタブにInvalid LSP server config for ".lsp.json"と出ます。次に、拡張子ごとに動くサーバーは1つです。有効な2つのサーバーが同じ拡張子を担当すると、先に登録されたほうだけが使われ、後ろのサーバーについてErrorsタブにLSP server "<name>" is not used for <ext> filesと警告が出ます。

うまく動かないときの切り分け

診断が出ない、ナビゲーションがエラーになる場合は、/pluginのErrorsタブを開きます。Executable not found in $PATH: "<binary>"と出ていれば、そのバイナリを入れます。claude --debugのログにはLSP server <name> failed to start: <理由>と出ます。バイナリをclaudeを起動したシェルと別のPATHに入れた場合は、そのシェルから新しいセッションを始めます。バイナリを入れ直した後は、Claudeが次に対象ファイルを編集したときに再試行されます。

メモリ使用量が大きい場合は、rust-analyzerやpyrightはプロジェクト全体を索引するため、メモリを多く使います。/plugin disable <plugin>で無効にすると、Claude組み込みの検索ツールでの探索に戻ります。診断とナビゲーションは止まりますが、探索そのものは続けられます。

モノレポで見せかけの診断エラーが出る場合は、言語サーバーがそのワークスペース向けに設定されていないと、内部パッケージへのimportが未解決として報告されます。Claude Code側で直すことはなく、診断が出てもClaudeの編集は止まりません。

設定を一通り確認してもNo LSP server availableが消えない場合は、既知の競合状態を扱う「No LSP server available」の原因と直し方を参照します。

grep主体の探索と組み合わせる

コードインテリジェンスは、ファイル読み取りを絞る他の設定と組み合わせると効果が重なります。生成物やベンダーコードへのRead拒否ルールやclaudeMdExcludesは、読ませる範囲そのものを減らす側です。ワークツリーで作業するなら、worktree.sparsePathsでディスクに置くディレクトリも絞れます。コードインテリジェンスは「残った範囲の中で何かを探す手間」を減らす側で、この2つを合わせた設定例はClaude Codeのコンテキスト管理にあります。

対話の進め方、つまり広い質問から徐々に絞り込む型は、コードインテリジェンスの有無にかかわらず有効です。Claude Codeで大規模コードベースを探索するコツの3段階と組み合わせられます。パッケージ単位で権限や規約を分けているモノレポでは、Claude Codeモノレポ設計のディレクトリ構成に合わせて、パッケージごとに使う言語のプラグインだけを有効にする運用が考えられます。自作プラグインの配布まで進める場合は、プラグインとマーケットプレイスのガイドが入口です。

まとめ

導入の抜けは「プラグインだけ入れてバイナリがない」「チームの設定だけコミットして各自のインストールがない」の2か所に集中します。動かないときは、まず/pluginのErrorsタブを見てください。