case_1230

Claude CodeのLSP設定|プラグインの入れ方と動かない時

Claude CodeのLSP設定|プラグインの入れ方と動かない時

Claude CodeのLSP設定は、言語サーバーの本体と公式プラグインの2つを入れて使います。13個の公式プラグインの対応表、入れ方、Executable not foundなど動かない時の確認を公式情報で整理しました。

Claude Code で LSP(Language Server Protocol)を使うには、言語サーバーの本体を自分のマシンに入れたうえで、Anthropic の公式マーケットプレイスからその言語のコードインテリジェンス用プラグインを入れる。2つがそろうと、Claude は自分の編集で生じた型エラーや import の漏れを、ビルドを走らせる前に受け取れるようになる(Code intelligence plugins)。

2026年10月9日に、公式ドキュメントと v2.1.295 までの CHANGELOG を確かめてまとめた(確認日:2026年10月9日・Claude Code CHANGELOG)。プラグインだけ入れて動かない、推奨のダイアログを閉じてしまった、モノレポで身に覚えのないエラーが出る、といったつまずきを順に片づけていく。

この記事の要点

  • 必要なもの:言語サーバーの本体と公式プラグインの2つ。プラグインに本体は入っていない(公式)。
  • 入れ方:本体を入れる→/plugin install <プラグイン名>@claude-plugins-official→型エラーを1つ作らせて診断が出るか見る(公式)。
  • 増えること:編集のたびに届く診断と、記号で定義や参照をたどる LSP ツール。
  • 動かない時:/plugin の Errors タブに Executable not found in $PATH があれば、本体が PATH に無い。
  • 使えない場所:クラウドセッションでは言語サーバーが起動しない。
  • チーム:enabledPlugins で有効にできるが、本体の導入は各自。
  • 対象読者:編集後の型エラーを減らしたい開発者、大きなリポジトリで Claude の読み込みを減らしたい開発リード。

Claude CodeのLSPとは|プラグインで言語サーバーにつなぐ

コードインテリジェンス用のプラグインは、エディタが持っている診断と定義ジャンプを Claude にも渡す仕組みだ。プラグインは1つの言語を受け持ち、Claude Code とその言語の言語サーバーを LSP でつなぐ。プラグインは公式マーケットプレイスから、言語サーバーの本体は自分のマシンに入れる(Code intelligence plugins)。LSP 自体は、エディタと言語サーバーのやり取りを決めた共通の規約だ(Language Server Protocol)。Claude Code に LSP ツールが加わったのは v2.0.74 で、その後も修正が続いている(Claude Code CHANGELOG)。

上段のClaude CodeとLSP ツール、中段のプラグインと公式マーケットプレイス、下段の言語サーバーと自分のマシンを重ね、中段から下段へLSPでつながることを示した3層の図
Claude Code、プラグイン、言語サーバーの3層。プラグインは公式マーケットプレイスから、本体は自分のマシンに入れる

LSPで増える2つのこと

公式ドキュメントが挙げる変化は2つある(Code intelligence plugins)。

  • 編集後の診断:Claude がそのサーバーの受け持つファイルを編集・作成するたびに、サーバーが報告したエラーと警告が Claude に届く。型エラー、import の漏れ、構文エラーを、コンパイラを走らせずに知る。
  • コードのナビゲーション:Claude に LSP ツールが加わり、文字列の検索ではなくサーバー経由で記号を調べる。このツールは読み取り専用だ。

LSP ツールで調べられるのは、記号の定義へのジャンプ、参照の一覧、ある位置の型情報、ファイル内の記号の一覧、ワークスペース全体での記号名の検索、インターフェースの実装の検索、呼び出し階層の追跡の7つ。ツールの一覧では、実行に許可が要らない側に分類されている(Tools reference)。

大きなリポジトリで効く理由

大規模なコードベース向けの公式ページは、記号がどこで定義され、どこで使われているかを探すのに、多くのファイルの読み込みと grep が要ることがあると書いている。コードインテリジェンスのプラグインを入れると、Claude はツリーを読み回らずに定義へ飛び、参照を探し、型エラーを受け取れる。同じページは、claudeMdExcludes や Read の deny ルールとの相性がよいとも書いている。不要な中身をコンテキストから外し、残った範囲では定義を探すための読み込みを減らす、という分担だ(Set up Claude Code in a monorepo or large codebase)。大きなリポジトリでの読ませ方は、大規模コードベースの理解とオンボーディングの記事でも扱っている。

使える場所と使えない場所

  • ターミナルのセッション:使える。
  • クラウドセッション:Claude Code はプラグインの言語サーバーを起動しないため、診断もナビゲーションも無い(Code intelligence plugins)。クラウドセッションの全体像はWeb版・クラウドセッションの記事にまとめた。
  • VS Code 拡張とデスクトップアプリ:画面からプラグインを入れる。ターミナル、デスクトップアプリのローカルセッション、VS Code 拡張は同じ設定ファイルを読むので、ユーザー範囲で入れたプラグインはほかの2つでも使える(Install and manage plugins)。
  • claude -p などの非対話の実行:/plugin は動かないが、入れ済みのプラグインは読み込まれる(Install and manage plugins)。

言語ごとのプラグインと必要な本体

公式の13プラグイン

公式ドキュメントの表には、次の13個のプラグインが載っている。プラグイン名は /plugin install に渡す名前、本体は PATH から起動されるコマンド名だ(Code intelligence plugins)。

言語 プラグイン 本体(バイナリ)
C/C++ clangd-lsp clangd
C# csharp-lsp csharp-ls
Go gopls-lsp gopls
Java jdtls-lsp jdtls
Kotlin kotlin-lsp kotlin-lsp
Liquid liquid-lsp shopify(Shopify CLI)
Lua lua-lsp lua-language-server
PHP php-lsp intelephense
Python pyright-lsp pyright-langserver
Ruby ruby-lsp ruby-lsp
Rust rust-analyzer-lsp rust-analyzer
Swift swift-lsp sourcekit-lsp
TypeScript・JavaScript typescript-lsp typescript-language-server

13個のうち liquid-lsp は Shopify が保守し、公式マーケットプレイスが掲載している。残りの12個は Anthropic が保守している(Code intelligence plugins)。プラグインの中身は anthropics/claude-plugins-official で読める。

本体の入れ方を調べる場所

本体を入れるコマンドは、表の各プラグインの README に書かれている。TypeScript なら npm install -g typescript-language-server typescript だ。表に無い言語は、後半の「公式プラグインが無い言語を足す」で扱う。

入れ方|本体→プラグイン→起動の確認

公式ドキュメントの順番は、本体、プラグイン、起動の確認の3段だ。プラグインは「どのコマンドで言語サーバーを起動し、どの拡張子を受け持つか」を Claude Code に教えるだけで、言語サーバーそのものは含まない(Code intelligence plugins)。

言語サーバーの本体を入れる、プラグインを入れる、サーバーが起動したか確かめるの3つの箱を左から右へ矢印でつなぎ、それぞれの下にPATH、/plugin install、Found N new diagnostic issuesの札を置いた図
公式ドキュメントの順番は、本体、プラグイン、起動の確認の3段

手順1|言語サーバーの本体を入れる

表の行の本体を入れたら、claude を起動するシェルの PATH に載っているかを確かめる。

# macOS・Linux
which typescript-language-server

# PowerShell
Get-Command typescript-language-server

ここで見つからなければ、次の手順に進んでもサーバーは起動しない。

手順2|プラグインを入れる

ターミナルでは claude を起動し、プロンプトに次を入れる。typescript-lsp は表で自分の言語の行にあるプラグイン名に置き換える。

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

完了のメッセージに、すぐ有効になったか、/reload-plugins が要るかが出る。VS Code 拡張とデスクトップアプリでは、この入力ではなくプラグインの画面から入れる(Install and manage plugins)。

手順3|サーバーが起動したか確かめる

言語サーバーは、Claude がそのプラグインの拡張子のファイルを初めて編集した時に起動する。確かめるには、その言語のファイルにわざと型エラーを入れさせ、続けて直させる。

src/utils/date.ts の formatDate の戻り値を、わざと number 型にしてから元に戻して。
間に出た診断の行を見せて。

エラーを入れた編集の下に Found N new diagnostic issues in M files (ctrl+o to expand) の行が出れば、サーバーは起動している。診断の中身は Ctrl+O で開く。行が出なければ /plugin の Errors タブを見る。Executable not found in $PATH: "<binary>" の行があれば、そこに書かれた本体が足りない(Code intelligence plugins)。

足りない本体を入れると、Claude Code は次に Claude が該当のファイルを編集した時に起動をやり直す。本体を入れた場所が、claude を起動したシェルの PATH に無い場合は、PATH の通ったシェルから新しいセッションを始める(Code intelligence plugins)。

「LSP plugin recommendation」が出た時の選び方

本体はすでに PATH にあるのに対応するプラグインが入っていないと、Claude Code は LSP plugin recommendation という題のダイアログで、プラグインを入れるかどうかを聞いてくる(Code intelligence plugins)。

左のLSP plugin recommendationの箱から、中央の関門を通って右のYes, install、No, not now、Never for this plugin、Disable all LSP recommendationsの4つの箱へ分かれ、左の箱の下に30秒、右下に5回無視の札を置いた図
ダイアログの4つの選択肢。何も選ばないと30秒で閉じ、5回無視すると推奨が止まる

ダイアログが出る条件

  • Claude がファイルを編集した後に出る。
  • 追加済みのマーケットプレイスか、Claude Code が登録した公式マーケットプレイスに、そのファイルの拡張子向けのプラグインがあり、本体が入っている時に出る。
  • 複数のマーケットプレイスに候補があれば、公式マーケットプレイスのものを示す。
  • 1つのセッションで出るのは最大1回で、最初に当てはまったファイルの時だけ(Code intelligence plugins)。
  • claude --cloud で始めたものなど、クラウドセッションにつないでいる時は出ない。

4つの選択肢

ダイアログの選択肢は4つで、選んだ後の動きは次のとおりだ(Code intelligence plugins)。

選択肢 起きること
Yes, install ユーザー範囲に入り、<plugin> installed · restart to apply と出る。新しいセッションで読み込まれる
No, not now 閉じるだけ。後のセッションでまた出ることがある。Esc も同じ
Never for this plugin そのプラグインについては出なくなる。ほかの言語では出る
Disable all LSP recommendations すべての言語で出なくなる

何も選ばないと30秒で閉じ、「無視した」と数えられる。この回数はセッションをまたいで残り、5回無視すると、Disable all LSP recommendations を選んだのと同じく推奨が止まる(Code intelligence plugins)。

止めた推奨を戻す

推奨を止めた後で戻したい時は、Claude Code 自身の設定ファイル ~/.claude.json を開く(Code intelligence plugins)。

  • すべて止めた、または5回無視した:lspRecommendationDisabled と lspRecommendationIgnoredCount のキーを消す(公式)。
  • Never for this plugin を選んだ:lspRecommendationNeverPlugins の一覧から、そのプラグインの name@marketplace を消す。

動かない時の確認

公式のトラブルシューティングが言語サーバーについて挙げている症状は、起動しない、メモリを使いすぎる、誤った診断が出る、の3つだ(Troubleshoot plugins)。ここに、よく出るエラー文と設定による拒否を加えて整理する。

/plugin の Errors タブ、Executable not found in $PATH、本体を入れる、新しいセッションの4つを時計回りの輪でつなぎ、Errors タブの横にclaude --debug、本体を入れるの横にwhichの札を置いた図
言語サーバーが起動しない時の切り分けの流れ

Executable not found in $PATH が出る

Claude Code は、プラグインに書かれたコマンド名で本体を PATH から起動する。/plugin の Errors タブには Executable not found in $PATH: "<binary>" のように理由が出て、claude --debug で起動すると、ログに LSP server <name> failed to start: <reason> が残る。本体を入れ、claude を起動するターミナルの PATH にあることを which で確かめてから、新しいセッションを始める(Troubleshoot plugins)。

Marketplace “claude-plugins-official” not found が出る

/plugin install がこのメッセージで止まったら、/plugin marketplace add anthropics/claude-plugins-official で公式マーケットプレイスを足してから入れ直す。プラグイン名が見つからないと言われた時は、名前の綴りを確かめる(Set up Claude Code in a monorepo or large codebase)。

メモリを使いすぎる

rust-analyzer や pyright のような言語サーバーは、プロジェクト全体を索引する。重さが気になる時は、セッションの中で /plugin disable <plugin> を実行してプラグインを止め、Claude の組み込みの検索ツールに任せる(Troubleshoot plugins)。

モノレポで誤った診断が出る

ワークスペースに合わせた設定になっていない言語サーバーは、内部パッケージの import を「解決できない」と報告することがある。公式ドキュメントは、Claude Code の側で直すものは無く、この診断があっても Claude の編集は止まらないと書いている(Troubleshoot plugins)。直すなら言語サーバー側の設定を見直す。モノレポ全体の進め方はモノレポ・マルチパッケージの記事にある。

作業フォルダの外でLSPが断られる

設定 permissions.blockReadsOutsideWorkingDirectories を有効にしていると、作業ディレクトリの外のパスに対する Read、Grep、Glob、LSP の呼び出しは拒否され、Claude は /add-dir でそのディレクトリを足すよう頼んでくる。この設定は v2.1.257 以降で使える(Settings reference)。外のフォルダを参照する作業なら、/add-dir で足してから続ける。設定の考え方は作業フォルダ外の読み取り制御の記事で解説した。

古い版で直った不具合に当たっていないか

CHANGELOG には、言語サーバーまわりの修正がいくつも並ぶ。v2.1.74 では Windows でファイルの URI が崩れて言語サーバーが動かなかった不具合、v2.1.274 では言語サーバーがプロジェクト全体の大量のファイルに診断を出した時に毎ターン遅くなる不具合、v2.1.288 では言語サーバーが応答しないと LSP ツールの呼び出しが止まったままになる不具合が直り、60秒でタイムアウトするようになった(Claude Code CHANGELOG)。似た症状なら、先に版を上げる。更新の方法はアップデートと自動更新の記事にまとめた。

切り分けに使う起動方法

  • claude --debug:言語サーバーが起動しない理由がログに残る(Troubleshoot plugins)。
  • claude --safe-mode:プラグイン、言語サーバー、フック、MCP サーバーなどを読み込まずに起動する。環境変数 CLAUDE_CODE_SAFE_MODE=1 でも同じだ(Environment variables)。設定が壊れていないかを見る時に使う。

チームで同じLSPを使う設定

入れる範囲の選び方

プラグインを入れる範囲は3つあり、どの設定ファイルに「有効」と書かれるかが変わる(Install and manage plugins)。

左下のユーザー(~/.claude/settings.json)から、プロジェクト(.claude/settings.json)、右上のローカル(.claude/settings.local.json)へ上がる3段の階段の図
同じプラグインが複数の範囲にある時の優先順。上の段ほど優先される
範囲 書かれる場所 有効になる相手
ユーザー ~/.claude/settings.json 自分。このマシンのすべてのプロジェクト
プロジェクト .claude/settings.json(コミットする) このリポジトリで作業する全員
ローカル .claude/settings.local.json 自分。このリポジトリだけ

同じプラグインが複数の範囲にある時は、ローカルがプロジェクトより、プロジェクトがユーザーより優先される(Install and manage plugins)。そのため、自分の ~/.claude/settings.json で false にしても、プロジェクトの .claude/settings.json が有効にしたプラグインは止まらない(Settings reference)。

プロジェクトの設定で有効にする

キーは enabledPlugins で、プラグイン名@マーケットプレイス名 に真偽値を対応させる(Settings reference)。

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

この設定をコミットしても、メンバーのマシンにプラグインが届くわけではない。各自が1回、シェルで claude plugin install typescript-lsp@claude-plugins-official --scope project を実行する(Install and manage plugins)。settings.json の全体像はsettings.json 設定ガイドで確かめられる。

本体と社内ネットワークの準備

言語サーバーの本体は、開発者それぞれのマシンに要る。公式マーケットプレイスからの導入には、マーケットプレイスが置かれている GitHub へのネットワーク接続が要る。接続が制限された環境では、社内の Git ホストやローカルのパスからマーケットプレイスを追加する(Set up Claude Code in a monorepo or large codebase)。チームで環境をそろえる手順は開発環境の標準化の記事も参考になる。

公式プラグインが無い言語を足す|.lsp.json

最小の書き方

表に無い言語でも、言語サーバーがあればつなげられる。プラグインのルートに .lsp.json を置き、サーバーの起動コマンドと受け持つ拡張子を書く。公式ドキュメントの例はこうだ(Add components to a plugin)。

中央の.lsp.jsonから、左のcommandとargs、右のextensionToLanguageと--plugin-dir、下のErrors タブへ線が伸びる図
公式プラグインが無い言語は、.lsp.json にコマンドと拡張子を書いてつなぐ
{
  "gopls": {
    "command": "gopls",
    "args": ["serve"],
    "extensionToLanguage": {
      ".go": "go"
    }
  }
}

サーバー名から設定へ直接対応させる形で、外側を包むオブジェクトは無い。command は本体の名前、引数は args に書く。extensionToLanguage には、. で始まる拡張子を1つ以上入れる(Add components to a plugin)。作ったプラグインは、--plugin-dir で1回のセッションだけ読み込んで試すか、マーケットプレイスに公開して入れる(Code intelligence plugins)。

よく使う項目

サーバーごとの設定は、決まった項目だけを受け付ける厳密な形で、知らないキーは不正として扱われる。主な項目は次のとおりだ(Plugin manifest reference)。

項目 必須 中身
command はい 本体のコマンド。/ で始まる時以外は空白を入れず、引数は args へ
extensionToLanguage はい 拡張子から LSP の言語 ID への対応。1つ以上
args いいえ サーバーに渡す引数
env いいえ サーバーのプロセスに渡す環境変数
startupTimeout いいえ 起動を待つミリ秒
requestTimeout いいえ 応答を待つミリ秒。既定は 60000。v2.1.288 以降
restartOnCrash いいえ 落ちた時に再起動するか。既定は true
maxRestarts いいえ 再起動を試す回数
diagnostics いいえ 編集後に診断をコンテキストへ入れるか。既定は true

つまずきやすい点

  • 検証の対象外:claude plugin validate は .lsp.json を読まない。1つでも不正な項目があると、ファイル全体が読み込みで飛ばされ、Errors タブに Invalid LSP server config for ".lsp.json" が出る(公式)。
  • 拡張子のぶつかり:1つの拡張子を受け持つサーバーは1つだけ。2つのサーバーが同じ拡張子を受け持つと、先に登録された方が使われ、Errors タブに LSP server "<name>" is not used for <ext> files が出る(公式)。
  • ログは標準エラーへ:Claude Code はサーバーの標準出力をプロトコルのメッセージとしてだけ読む。ヘッダーは 64 KiB、本文は 32 MiB までで、超えたり、プロトコル以外を標準出力に書いたりすると切断され、restartOnCrash と maxRestarts の上では落ちたものとして数えられる(Add components to a plugin)。
  • インストール後だけ動かない:入れたプラグインはキャッシュにコピーされるため、元のフォルダでしか通らないパスは壊れる。プラグインの中のパスは ${CLAUDE_PLUGIN_ROOT} で書く(Troubleshoot plugins)。

想定シナリオ|TypeScriptのモノレポで編集直後の型エラーを拾う

ここからは構成例で、実在の企業や個人(チーム)の事例ではない。TypeScript のモノレポで、Claude の編集のたびに型チェックを手で回していたチームが、LSP の診断に切り替える流れを置いてみる。

手順1|本体を各自のマシンに入れる

メンバーそれぞれが npm install -g typescript-language-server typescript を実行し、which typescript-language-server で PATH にあることを確かめる。

手順2|プロジェクトの設定で有効にしてコミットする

.claude/settings.json の enabledPlugins に typescript-lsp@claude-plugins-official を書いてコミットする。プラグインそのものは届かないので、各自が claude plugin install typescript-lsp@claude-plugins-official --scope project を実行する(Install and manage plugins)。

手順3|型エラーを作らせて確かめる

各自のセッションで、わざと型エラーを入れて直させ、Found N new diagnostic issues の行が出るかを見る。出ない人は /plugin の Errors タブを開き、Executable not found in $PATH の有無で本体の問題かどうかを分ける。

手順4|誤った診断とメモリを見張る

内部パッケージの import が「解決できない」と出るなら、言語サーバー側のワークスペースの設定を見直す。Claude の編集はその間も止まらない。索引でマシンが重くなる人は /plugin disable typescript-lsp で外し、組み込みの検索に戻す。

よくある質問

Claude CodeでLSPを使うには?

言語サーバーの本体を入れ、公式マーケットプレイスからその言語のプラグインを /plugin install <プラグイン名>@claude-plugins-official で入れる。TypeScript なら本体は typescript-language-server、プラグインは typescript-lsp だ(Code intelligence plugins)。

ENABLE_LSP_TOOLの設定は必要ですか?

2026年10月9日に確かめた公式の環境変数の一覧には、ENABLE_LSP_TOOL は載っていない(Environment variables)。公式ドキュメントは、言語に合うコードインテリジェンスのプラグインを入れるまで LSP ツールを無効のままにしておくと書いており、プラグインを入れれば使えるようになる(Tools reference)。

クラウドセッションやWeb版でも使えますか?

使えない。クラウドセッションでは、Claude Code がプラグインの言語サーバーを起動しないため、LSP ツールも無効のままになる(Tools reference)。

LSPツールの実行に許可は必要ですか?

要らない。ツールの一覧で LSP は許可の要らない側にあり、読み取り専用のツールだ(Tools reference)。ただし permissions.blockReadsOutsideWorkingDirectories を有効にしていると、作業ディレクトリの外への呼び出しは拒否される。

公式プラグインが無い言語でも使えますか?

使える。プラグインのルートに .lsp.json を書き、言語サーバーの起動コマンドと受け持つ拡張子を指定する(Add components to a plugin)。

言語サーバーが重い時はどうすればいいですか?

/plugin disable <plugin> でプラグインを止め、組み込みの検索ツールに任せる。公式ドキュメントは rust-analyzer と pyright を、プロジェクト全体を索引する例に挙げている(Troubleshoot plugins)。

あわせて読みたい

運営元 Uravation よりこの事例を自社の業務で試す場合のテーマ選定・評価・本番移行の確認項目を、無料のチェックリストにまとめています。 Claude Code業務自動化PoCチェックリストを受け取る(無料)

参考・出典

Next Step

この事例を、自社の業務に置き換える。

対象業務、利用データ、評価基準、社内展開の順番まで整理すると、AI開発ツール導入の失敗を減らせます。

導入を相談する

チームで学ぶなら: Claude Code 法人研修(2日間ハンズオン) / 1人で習得するなら: 個別指導(週1マンツーマン)