Laravel LSPは、Laravelアプリケーションの構造を理解し、コード補完、診断、ホバー表示、定義への移動などを複数のエディタへ提供する公式の言語サーバーです。
Laravel Newsの発表記事によると、Laracon US 2026の壇上で公開され、Laravelチームが管理する独立したサーバーとして利用できるようになりました。
これまで公式のLaravel向け編集支援はVS Codeを中心に整備されていました。
Laravel LSPは標準化された通信方式を採用するため、Sublime Text、Zed、Neovim、Cursor、OpenCodeなどでも、Laravel固有の情報を使った編集支援を受けやすくします。
ただし、導入しただけでコードの正しさが保証されるわけではありません。
一般的なPHPの型解析、テスト、静的解析、コードレビューを置き換える道具ではなく、Laravel特有の文字列参照や規約をエディタ上で見つけやすくする補助として評価するのが適切です。
Laravel LSPが解決する編集上の問題
Laravelでは、ルート名、ビュー名、設定キー、翻訳キー、ミドルウェア名などを文字列で参照する場面が多くあります。
例えば、route('orders.show')という呼び出しを見ただけでは、一般的なPHP解析ツールが対応するルート定義を特定できないことがあります。
Laravel LSPはプロジェクトを索引し、こうしたLaravel固有の参照をエディタから問い合わせられる形にします。
Laravel公式GitHubリポジトリでは、次の範囲が対応機能として示されています。
| 対象 | 主な編集支援 | 実務上の利点 |
|---|---|---|
| ルート | 補完、ホバー、診断、リンク | ルート名の入力ミスを実行前に見つけやすい |
| ビューとBlade | 補完、診断、リンク、修正候補 | 存在しないビューやコンポーネントへの参照を追いやすい |
| 設定と環境変数 | 補完、ホバー、診断、リンク | 設定キーの綴り違いと定義場所を確認しやすい |
| 翻訳 | キー、ロケール、引数の補完とホバー | 翻訳漏れや引数の不一致を減らしやすい |
| ミドルウェアと認可 | 補完、診断、ホバー、リンク | 別名と実装の対応をたどりやすい |
| サービスコンテナ | バインディングの補完、診断、ホバー、リンク | 抽象と実装の登録関係を確認しやすい |
| Eloquent | 補完 | モデルを使った記述の候補を得やすい |
| InertiaとLivewire | ページやコンポーネントの補完、診断、リンク | PHP側と画面側の参照を往復しやすい |
とくに効果が見込めるのは、PHPのクラスやメソッドではなく、文字列で結び付いている箇所です。
サービスコンテナの設計自体を見直したい場合は、サイト内のLaravelのサービスコンテナと依存性注入の解説も参照してください。
LSPがエディタの選択肢を広げる仕組み
Language Server Protocol（LSP）は、エディタやIDEと、言語機能を提供するサーバーの間で交わすメッセージを標準化したプロトコルです。
MicrosoftのLSP公式資料が説明するように、同じ言語サーバーを複数の開発ツールから再利用できる点に意義があります。
Laravel LSPは標準入出力を通じてエディタと通信します。
そのため、各エディタがLaravelのルートやBladeの解析を一から実装するのではなく、共通の言語サーバーを起動して結果を受け取れます。
この構成は、すべてのエディタで同じ画面や操作感になることを意味しません。
補完候補の表示、診断の見せ方、クイックフィックスの操作はLSPクライアント側にも依存するため、チームで採用する前に実際のエディタで確認する必要があります。
導入前に確認する要件
Packagistのlaravel/lspパッケージと公式リポジトリでは、PHP 8.2以降、Composer、Laravelアプリケーション、LSP対応エディタまたはクライアントが要件として示されています。
既存案件が古いPHPを使っている場合、Laravel LSPだけを先に入れるのではなく、アプリケーションの更新計画と分けて検討してください。
導入はComposerのグローバルパッケージとして行います。
composer global require laravel/lspインストール後は、Composerのグローバル実行ファイル用ディレクトリがPATHに含まれていることを確認します。
エディタが公式拡張機能を通じて起動する場合でも、laravel-lspコマンドを見つけられなければ接続できません。
Packagistでは0.0系として配布されており、初期段階の更新が続く可能性があります。
本番案件へ一斉導入する前に、対象バージョン、既知の問題、更新履歴を確認し、チームで使う版と更新手順を決めておくと混乱を抑えられます。
エディタごとの導入方法
公式リポジトリは、Sublime Text、Zed、VS Codeに公式拡張機能を案内しています。
CursorはVS Code拡張機能を利用でき、NeovimとOpenCodeはLSPクライアントからlaravel-lspを起動する設定を加えます。
| エディタ | 導入の入口 | 確認点 |
|---|---|---|
| VS Code | 公式Laravel拡張機能 | 既存のPHP拡張機能との診断重複 |
| Cursor | VS Code互換の公式Laravel拡張機能 | ワークスペース単位の有効化範囲 |
| Sublime Text | 公式Laravel拡張機能 | LSPクライアントとサーバー実行パス |
| Zed | 公式Laravel拡張機能 | プロジェクトルートの認識 |
| Neovim | Neovim 0.11以降のLSP設定 | artisanやcomposer.jsonをルート指標にする設定 |
| OpenCode | カスタムLSP設定 | .phpと.blade.phpの関連付け |
コンテナ内でPHPを動かす案件では、エディタがホスト側のPHPを誤って使わないようにします。
Laravel LSPのphpEnvironmentはHerd、Valet、Sail、Lando、DDEV、ローカルPHPを検出でき、必要ならphpCommandで実行コマンドを明示できます。
例えばSailを使うチームでは、自動検出に任せた結果が各開発者で異ならないかを確認します。
開発環境が統一されているなら、実行コマンドをチーム設定として固定する方が再現性を保ちやすくなります。
既存のPHP解析ツールとの役割分担
Laravel LSPの公式機能一覧は、ルート、ビュー、設定、翻訳、コンテナ、Eloquentなど、フレームワーク固有の知識に重点を置いています。
PHP言語全般の型推論、未使用コード検出、規約違反、脆弱性検査までを一つで担うとは説明されていません。
したがって、既存のPHP言語サーバーや静的解析を直ちに外す判断は避けた方が安全です。
まずは両方を有効にし、同じ診断が二重に表示される箇所、補完の競合、索引時のCPUとメモリ使用量を調べ、重複する機能だけを設定で無効にします。
Laravel LSPで参照先へ移動できても、その実装が業務要件を満たすとは限りません。
PestやPHPUnitによるテスト、PHPStanやLarastanなどの静的解析、レビュー、依存パッケージの監査は引き続き必要です。
安全に試験導入する手順
- 対象案件を一つ選ぶ：ルート、Blade、翻訳、設定を適度に含む代表的な案件で試します。
- 前提を確認する：PHP 8.2以降、Composer、エディタの対応版、プロジェクトルートを確認します。
- 既存ツールを記録する：PHP言語サーバー、静的解析、フォーマッター、テスト拡張機能の一覧を残します。
- 補完と診断を検証する：存在するルート名と意図的に誤ったルート名を入力し、候補と診断の差を確かめます。
- 定義への移動を検証する：ビュー、設定、翻訳、コンテナの参照から正しい定義へ移動できるかを確認します。
- 負荷と副作用を観察する：初回索引時間、CPU使用量、メモリ使用量、アプリケーション起動時の処理を確認します。
- チーム設定を固定する：PHPの実行方法、無効にする重複診断、更新手順をリポジトリの開発文書に残します。
検証では、便利な成功例だけでなく、誤った診断と補完されない参照も記録します。
対応範囲を把握すれば、開発者が「警告がないから正しい」と誤解するのを防げます。
実務で期待できる変化
Laravel LSPの価値は、コードを速く入力することだけではありません。
文字列で分断されていた定義と利用箇所をエディタ上で結び、変更時に確認すべき範囲を見つけやすくする点にあります。
例えばルート名を変更するとき、利用箇所から定義へ移動できれば、命名の意図や関連するミドルウェアを確認しやすくなります。
設定キーの診断が機能すれば、環境ごとの差として見過ごされやすい綴り違いをローカル作業中に発見できる可能性も高まります。
一方で、初期段階のツールは機能追加や設定変更が続くことがあります。
全員へ導入を義務付けるより、少人数で評価し、誤診断率と作業時間への影響を共有してから標準環境へ加える方が現実的です。
よくある質問
Laravel LSPだけでPHP開発環境は完成しますか
完成しません。
Laravel固有の補完と参照解決を担う一方、一般的なPHP解析、テスト、フォーマット、静的解析、セキュリティ確認には別の道具が必要です。
古いLaravel案件でも使えますか
まずPHP 8.2以降という実行要件を確認してください。
Laravel側の対応範囲は更新される可能性があるため、対象案件のバージョンと公式リポジトリの最新説明を照合してから試します。
チーム全員が同じエディタを使う必要はありますか
その必要はありません。
LSPは複数のエディタから同じサーバーを利用するための仕組みですが、表示と操作はエディタごとに異なるので、共通設定とエディタ別の補足を分けて文書化します。
最初に確認すると効果が分かりやすい機能は何ですか
ルート名、ビュー名、設定キー、翻訳キーの補完と診断です。
意図的な入力ミスを用意すると、Laravel LSPが検出できる範囲と、従来のPHP解析では捉えにくかった箇所を比較できます。
参考資料
- Laravel News「Laravel LSP: A First-Party Language Server Announced at Laracon US 2026」：発表内容、対応エディタ、機能の概要
- Laravel公式GitHubリポジトリ「laravel/lsp」：要件、導入方法、対応機能、設定項目
- Packagist「laravel/lsp」：Composerパッケージと配布状況
- Microsoft「Language Server Protocol」：LSPの目的と仕組み