Laravel IDE Helperでエディタ補完を強化する開発環境整備
概要
Laravel は Facade やマジックメソッド、動的プロパティを多用するため、素の状態ではエディタ(VS Code の Intelephense や PhpStorm)が型を解決できず、補完が効かなかったり「未定義メソッド」の警告が大量に出たりします。barryvdh/laravel-ide-helper を導入すると、補完用のスタブファイルを自動生成でき、補完・定義ジャンプ・静的解析の精度が一気に上がります。
本記事では、Laravel IDE Helper の導入から 3 種類の生成コマンドの使い分け、Eloquent モデルへの型注釈、チーム運用での注意点までをハンズオン形式でまとめます。
環境
- PHP 8.1 以上
- Laravel 10 / 11(9 以前でも概ね同様)
- Composer 2 系
- エディタ: VS Code + Intelephense、または PhpStorm
発生した問題
Laravel で開発していると、エディタ上で次のような状態に遭遇します。
Auth::user()やDB::table()などの Facade 呼び出しが「未定義メソッド」扱いになり、補完候補が出ない$user->nameのように、マイグレーションで定義したカラムをモデルのプロパティとして参照すると警告が出るUser::where(...)->first()のクエリビルダのメソッドチェーンで補完が途切れるconfig('app.name')のコンテナ解決結果の型がmixedになり、以降の補完が効かない
これらは Laravel が「実行時にメソッドやプロパティを動的に解決する」設計であることに起因します。コードとしては正しく動きますが、静的解析ツールやエディタは解決先を追えません。
原因
Laravel の Facade は __callStatic() で実体のインスタンスにメソッドを委譲しています。そのため Cache::get() と書いても、Cache クラス自体に get() は定義されていません。
同様に Eloquent モデルは、__get() / __set() でテーブルカラムを動的プロパティとして扱い、where などのクエリメソッドも __call() 経由で Builder に委譲しています。
静的解析はソースコードの定義情報だけを頼りにするため、こうした動的解決を追えず「未定義」と判断します。Laravel IDE Helper は、この「エディタに見えていない情報」を別ファイルのスタブとして出力することで橋渡しをします。実行コードには影響しません。
対応方法
1. インストール
開発時のみ使うパッケージなので --dev で入れます。
composer require --dev barryvdh/laravel-ide-helper
Laravel 5.5 以降は Package Discovery が効くため、config/app.php へのプロバイダ登録は不要です。
2. 3 つの生成コマンドを理解する
このパッケージの肝は、役割の異なる 3 つのコマンドです。
| コマンド | 生成物 | 役割 |
|---|---|---|
ide-helper:generate |
_ide_helper.php |
Facade のスタブ。Auth:: などの補完を解決 |
ide-helper:models |
モデルへの PHPDoc(または別ファイル) | Eloquent のカラム・リレーション・スコープの型 |
ide-helper:meta |
.phpstorm.meta.php |
コンテナ解決(app() / resolve())の型 |
3. Facade スタブを生成する
php artisan ide-helper:generate
プロジェクト直下に _ide_helper.php が生成され、Cache::get() や Route::get() などが正しく補完されます。
4. コンテナ解決のメタ情報を生成する
php artisan ide-helper:meta
.phpstorm.meta.php が生成され、app(SomeService::class) の戻り値型が正しく推論されます。ファイル名に phpstorm とありますが、これは PhpStorm のための補助ファイルです。
実装例
Eloquent モデルへの型注釈を追加する
最も恩恵が大きいのがモデルへの型注釈です。
php artisan ide-helper:models --write
実行すると、モデルのクラス DocBlock にカラム・リレーション・スコープの型が書き込まれます。
/**
* App\Models\User
*
* @property int $id
* @property string $name
* @property string $email
* @property \Illuminate\Support\Carbon|null $created_at
* @property-read \Illuminate\Database\Eloquent\Collection<int, \App\Models\Post> $posts
* @method static \Illuminate\Database\Eloquent\Builder|User where($column, $operator = null, $value = null)
*/
class User extends Authenticatable
{
// ...
}
これで $user->email や User::where('email', $value)->first() が補完対象になります。
モデル本体を汚したくない場合
--write-mixin を使うと、モデルには @mixin を 1 行だけ残し、本体の注釈は別ファイルに逃がせます。
php artisan ide-helper:models --write-mixin
composer スクリプトで自動化する
毎回コマンドを打つのは面倒なので、composer.json の scripts にまとめておきます。
{
"scripts": {
"ide-helper": [
"@php artisan ide-helper:generate --ansi",
"@php artisan ide-helper:meta --ansi",
"@php artisan ide-helper:models --nowrite --ansi"
],
"post-update-cmd": [
"Illuminate\\Foundation\\ComposerScripts::postUpdate",
"@ide-helper"
]
}
}
post-update-cmd に @ide-helper を含めておくと、依存更新のたびにスタブが追従します。
確認方法
_ide_helper.php/.phpstorm.meta.phpが生成されていること- エディタを再読み込み(VS Code なら「Developer: Reload Window」)してインデックスを再構築
Auth::user()にホバーして型が表示されること$user->emailで補完候補が出て、警告が消えること- カラム変更後は
php artisan ide-helper:models --resetでリセットして再生成し、反映を確認
注意点
生成ファイルをコミットするか
自動生成物は .gitignore に入れ、各自が生成する運用が一般的です。
_ide_helper.php _ide_helper_models.php .phpstorm.meta.php
一方、--write でモデル本体に書き込んだ DocBlock はソースの一部としてコミットします。ここを曖昧にすると、人によって補完精度が違ったり、無駄な差分が増えたりして混乱します。
本番環境に含めない
開発補助なので本番に含める必要はありません。プロバイダ登録をローカル限定にするなら AppServiceProvider で分岐します。
public function register(): void
{
if ($this->app->isLocal()) {
$this->app->register(\Barryvdh\LaravelIdeHelper\IdeHelperServiceProvider::class);
}
}
composer install --no-dev で本番ビルドしていれば、そもそも dev 依存は入りません。
静的解析ツールとの相乗効果
PHPStan(Larastan)や Psalm と併用している場合、モデルの @property 注釈は静的解析の精度向上にも効きます。ただし注釈と実テーブルがずれると誤った型を与えてしまうため、スキーマ変更時の再生成は必須です。
まとめ
- Laravel の補完が効かないのは、Facade・Eloquent の動的解決が原因
generate(Facade)・models(Eloquent)・meta(コンテナ)の 3 本柱で補う- モデル注釈は
--write-mixinでコードをすっきり保てる composer.jsonのpost-update-cmdに組み込むと運用が自動化できる- 生成ファイルは
.gitignore、モデル本体の DocBlock はコミット、というルールをチームで統一する
地味なツールですが、補完と静的解析の精度は開発体験と品質に直結します。新規プロジェクトの初期セットアップに組み込んでおく価値は高い施策です。
