Claude CodeのLSPとは？設定方法・対応言語・動かないときの対処

「Claude CodeでLSPを使うと、何が良くなるのか」「LSPのプラグインを入れたのに動いているか分からない」と迷っている方もいるのではないでしょうか。

LSP（Language Server Protocol）は、エディタが持っている「定義へ移動」「エラーの表示」といった機能を、プログラミング言語ごとの言語サーバーから受け取るための共通の決まりです。Claude Codeでは、この言語サーバーにつなぐと、Claudeがコードを直した直後に型のエラーや読み込みの間違いを自分で見つけ、シンボル（関数名や変数名）をたどってコードを調べられるようになります。

この記事では、LSPで何が変わるのかを最初に整理したうえで、公式プラグインがある言語、入れ方、動いているかの確認方法、うまくいかないときの対処、公式にない言語の足し方までを順に解説します。内容は2026年10月時点の公式ドキュメントをもとにしています。Claude Codeは更新が早いため、設定の前には公式ページもあわせて確認してください。

Claude CodeのLSPとは

Claude Codeには、公式のコード解析用プラグイン（コードインテリジェンスプラグイン）があります。このプラグインは、言語ごとの言語サーバーとClaude Codeをつなぐ役割をします。公式ドキュメントでは、エディタが持つ診断と「定義へ移動」の機能をClaudeにも持たせるものと説明されています。

つなぐと、Claudeは大きく2つのことができるようになります。

編集のたびに、エラーを自動で受け取る

Claudeがファイルを編集するたびに、言語サーバーが見つけたエラーや警告がClaudeに届きます。型の間違い、読み込み（import）の抜け、文法の誤りを、ビルドやテストを実行しなくてもその場で知ることができます。公式ドキュメントでも、別のビルド工程なしで問題を直せると説明されています。

たとえば、関数の引数を1つ増やしたのに呼び出し側を直し忘れたとします。LSPがない状態では、テストや実行で初めて分かります。LSPがあれば、編集した直後にエラーがClaudeへ届くので、そのまま続けて修正できます。

文字の検索ではなく、シンボルで調べる

もうひとつは、Claudeが使えるLSPツールです。ふつうの検索（Grep）は文字列を探すだけですが、LSPツールは言語サーバーを通してシンボルそのものを調べます。公式ドキュメントでは、次の操作ができると書かれています。

このツールは読み取り専用で、ファイルを書き換えることはありません。公式のツール一覧でも、実行のたびの許可は不要なツールとして載っています。ただし、読み取りの権限ルール（Read(...)）は、LSPツールにも適用されます。

対応言語と必要な言語サーバー

公式のマーケットプレイス（claude-plugins-official）には、次の言語のプラグインが用意されています。プラグインに言語サーバー本体は含まれていません。「どのコマンドで言語サーバーを起動するか」「どの拡張子を担当するか」を教えるだけなので、右端の言語サーバーは自分で入れる必要があります。

Anthropicが保守しているのは、liquid-lspを除くすべてのプラグインです。liquid-lspはShopifyが保守していて、公式マーケットプレイスに掲載されています。

言語サーバーの入れ方の例

言語サーバーの入れ方は、各プラグインのREADME（GitHubのclaude-plugins-official）に載っています。2026年10月に確認できた主な例を挙げます。READMEは更新されることがあるので、実際に入れるときはリンク先の最新の内容を確認してください。

PythonのREADMEには入れ方が3通り載っていて、pipxでの導入が推奨と書かれています。公式の言語一覧の表にある実行ファイル名はpyright-langserverなので、入れたあとにPATHでこの名前が見つかることを確かめてください。Liquidについては、READMEの内容までは確認できていません。

設定の手順

設定は、言語サーバー、プラグイン、確認の3つの順で進めます。ここではTypeScriptを例にします。

1. 言語サーバーを入れる前章の表で、使っている言語の言語サーバーを入れます。TypeScriptならnpm install -g typescript-language-server typescriptです。
2. PATHで見つかるか確認する入れた実行ファイルが、claudeを起動するシェルのPATHにあることを確かめます。which typescript-language-server（PowerShellではGet-Command typescript-language-server）で確認できます。
3. プラグインを入れるターミナルでclaudeを起動し、/plugin install typescript-lsp@claude-plugins-officialを実行します。言語に合わせて、プラグイン名を表のものに変えてください。
4. 有効にするインストールの完了メッセージに、すぐ使えるか、/reload-pluginsが必要かが書かれています。必要なら指示どおりに実行します。
5. 動くか確かめる対象の言語のファイルをClaudeに編集してもらい、診断の表示が出るかを見ます（次の章で説明します）。

公式ドキュメントでは、/plugin installはセッション中に実行すると、すぐに入れるのではなくプラグインの詳細画面が開き、範囲（スコープ）を選んでから入れる流れになると説明されています。同じコマンドをシェルから実行するclaude plugin install ＜名前＞@＜マーケットプレイス名＞の形も用意されています。

公式の手順に、LSPを有効にするための環境変数の設定は出てきません。以前のブログ記事などに環境変数が書かれていても、まず現在の公式ドキュメントの手順で試してください。

インストールの範囲（スコープ）を選ぶ

プラグインの入れ方には、3つの範囲があります。

まず自分だけで試すなら、ユーザーかローカルで十分です。チームで使うときの注意は、あとの章で説明します。

VS Codeやデスクトップアプリで使う場合

VS Code拡張機能とデスクトップアプリでは、ターミナルのコマンドではなく、画面からプラグインを入れます。公式ドキュメントでは、デスクトップアプリの場合、プロンプト欄の「＋」から「Plugins」を選んで、プラグインの一覧から追加する手順が案内されています。ターミナル、デスクトップアプリのローカルセッション、VS Code拡張機能は、同じパソコン上では同じ設定ファイルを読むため、ユーザー範囲で入れたプラグインはどれでも使えます。JetBrainsのIDEでは、IDEのターミナルタブでClaude Codeを動かすので、ターミナルの手順で入れます。

動いているかの確認と推薦ダイアログ

言語サーバーは、対象の拡張子のファイルをClaudeが初めて編集したときに起動します。インストールしただけでは、まだ動いていません。

診断の表示で確かめる

確かめるには、Claudeにわざと型のエラーが出るような編集を頼み、そのあと直してもらいます。公式ドキュメントでは、編集の下に次のような行が出れば、言語サーバーが起動していると説明されています。

Found N new diagnostic issues in M files (ctrl+o to expand)

会話の画面には、この件数のまとめだけが表示されます。エラーの中身を読むには、Ctrl+Oを押します。

この行が出ないときは、/pluginを開いてErrorsタブを見ます。Executable not found in $PATH: "＜実行ファイル名＞"という行があれば、その名前の言語サーバーがPATHにありません。言語サーバーを入れたあと、次にClaudeが対象のファイルを編集したときに、Claude Codeが起動をやり直します。PATHに入っていないフォルダに入れた場合は、PATHが通っているシェルから新しくセッションを始めてください。

「LSP plugin recommendation」ダイアログ

言語サーバーがすでにPATH上にあり、対応するプラグインが未インストールのとき、Claude Codeは「LSP plugin recommendation」というダイアログでプラグインの導入を提案します。出る条件は公式ドキュメントで次のように決まっています。

• 編集したファイルの拡張子に合うプラグインが、追加済みのマーケットプレイスにある
• そのプラグインの言語サーバーが、すでにパソコンに入っている
• 1つのセッションで、最初に当てはまったファイルの1回だけ表示される
• クラウドのセッション（claude --cloudなど）では表示されない

ダイアログには4つの選択肢があります。

選ばずに30秒たつと、閉じられて「無視した」と数えられます。無視が5回たまると、「Disable all」を選んだのと同じ扱いになり、提案されなくなります。

公式にない言語を足す

表にない言語でも、言語サーバーがあれば自分でつなげます。公式ドキュメントの手順は、プラグインの中に.lsp.jsonというファイルを置き、そのプラグインを読み込むというものです。

.lsp.jsonの書き方

プラグインのフォルダ直下に.lsp.jsonを置きます。Goの言語サーバーを.goファイルに使う例が、公式ドキュメントに載っています。

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

ファイルは、サーバー名をそのまま設定につなげる形で書きます。全体を包む入れ物は不要です。設定できる主な項目は次のとおりです。

このほかにも、transport、initializationOptions、settings、workspaceFolder、shutdownTimeout、requestTimeout、maxRestartsがあります。詳しくは公式のプラグイン仕様（manifest reference）のlspServersの項を確認してください。

読み込み方と、つまずきやすい点

作ったプラグインは、claude --plugin-dir ＜フォルダ＞で、そのセッションだけ読み込めます。プラグインを配るなら、マーケットプレイスに公開します。プラグインの設定ファイル（plugin.json）は任意とされていて、なくても標準の配置にあるファイルは読み込まれます。

• 言語サーバーは別に入れる：プラグインは接続の設定だけを持ち、言語サーバー本体は入れません。見つからないと起動に失敗し、claude --debugにLSP server ＜名前＞ failed to startと記録されます
• 1つの拡張子につき、使われるサーバーは1つ：同じ拡張子を担当するサーバーが2つ有効になっていると、先に登録された方が使われます。Errorsタブに「このサーバーは○○ファイルには使われない」という警告が出ます
• 書式の間違いは、ファイルごと無視される：1件でも不正な項目があると、.lsp.json全体が読み込まれず、ErrorsタブにInvalid LSP server config for ".lsp.json"と出ます。claude plugin validateはこのファイルを検査しません

うまくいかないとき

よくある状況を、症状と対処の表にまとめました。多くは言語サーバーが見つからないことが原因です。

メモリを多く使うとき

rust-analyzerやpyrightのような言語サーバーは、プロジェクト全体を読み込んで索引を作ります。そのため、プロジェクトが大きいと、起動後しばらくメモリの使用量が増えます。公式ドキュメントでは、重くて困るときは/plugin disable ＜プラグイン名＞でそのプラグインを止め、Claudeの組み込みの検索ツールに頼るように案内しています。LSPがなくても、Claude Codeの基本の動作には影響しません。

モノレポで、存在するはずのimportが警告される

複数のパッケージを1つのリポジトリに入れている場合、言語サーバーがそのワークスペースの構成を知らないと、社内のパッケージを「見つからない」と報告することがあります。公式ドキュメントでは、これはClaude Code側で直すものではなく、診断が出ていてもClaudeのコード編集は止まらないと説明されています。警告が気になるときは、言語サーバー側のワークスペースの設定を見直してください。

チームや会社で使うときの注意

1人で試す分には、ここまでの手順で足ります。複数人や社内で使うときは、次の点を決めておくと混乱を防げます。

全員に同じプラグインを使わせる

リポジトリのメンバー全員に同じプラグインを有効にしたいときは、プロジェクト範囲のプラグインにします。公式ドキュメントでは、.claude/settings.jsonのenabledPluginsに入れてコミットする方法が案内されています。

ただし、この設定を共有しても、メンバーのパソコンにプラグインが自動で入るわけではありません。各メンバーがclaude plugin install ＜名前＞@＜マーケットプレイス名＞ --scope projectを1回実行する必要があります。さらに、言語サーバーの実行ファイルも、各メンバーのパソコンにそれぞれ入れる必要があります。READMEやチームの手順書に、入れる言語サーバーとコマンドを書いておくと、新しく入った人も迷いません。

クラウドのセッションでは動かない

公式ドキュメントでは、Claude Codeのクラウドのセッション（Webなど）では、プラグインの言語サーバーは起動しないと明記されています。そのため、クラウドではLSPツールは使えず、診断やコードの移動の機能も得られません。ターミナルのセッションでだけ使える機能です。

権限とセキュリティ

LSPツールの読み取りは、Readの権限ルールの対象です。たとえば、Read(~/secrets/**)のような拒否ルールは、LSPツールにも効きます。ただし、プラグインが起動する言語サーバー自体は、Claudeのツール呼び出しではないため、Claude Codeの権限ルールやサンドボックスの対象外で、ユーザーの権限で動きます。

プラグインは、フックや言語サーバーなど、パソコン上でコードを動かせる部品を含められます。公式ドキュメントでも、導入前にプラグインの内容を確認するよう勧められています。公式マーケットプレイスのclaude-plugins-officialから入れる場合でも、詳細画面の「Will install」の欄で、何が追加されるかを見てから入れましょう。

ネットワークが制限された環境

公式マーケットプレイスは、GitHubで公開されています。社内のネットワークでGitHubに接続できない場合は、社内のGitサーバーやローカルのパスにマーケットプレイスを追加する方法が案内されています。

よくある質問

まとめ

LSPは、Claude Codeが直したコードのエラーを、人が実行する前に見つけるための機能です。まずは使っている言語のプラグインを1つ入れ、診断が出るかを確かめるところから始めてみてください。

チームで使う設定のそろえ方や、社内の開発の進め方にClaude Codeを組み込む段階では、決めることが一気に増えます。INTERCREATE JAPANでは、Claude Code・Codexの導入から、社内で使い続けられる仕組みづくりまでをお手伝いしています。