メインコンテンツへスキップ
Laravelの起動時に登録されるサービスプロバイダーは、たとえその機能をリクエスト中に一度も使わなくても毎回読み込まれます。遅延サービスプロバイダー(Deferred Service Provider)はこの問題を解決し、サービスが実際に使われるまで読み込みを後回しにできます。
このページはパッケージ開発の基礎の知識を前提としています。サービスプロバイダーの基本的な仕組みを理解してから読むことをおすすめします。

なぜ遅延プロバイダーが必要か

通常のサービスプロバイダーはすべてのリクエストで register()boot() が呼ばれます。メール送信、キュー、キャッシュなど、すべてのページで使わない機能まで毎回初期化するのは無駄です。
このプロバイダーを遅延化すると、レポートを実際に生成するリクエストでのみ初期化されます。

DeferrableProvider インターフェース

Illuminate\Contracts\Support\DeferrableProviderprovides() メソッドひとつを持つシンプルなインターフェースです。
このインターフェースを実装するだけで、プロバイダーは遅延モードになります。

基本的な実装

遅延プロバイダーの実装は3ステップです。
1

DeferrableProvider を implements する

2

register() でサービスをバインドする

通常のプロバイダーと同様に register() にバインドを記述します。
3

provides() で登録したサービスを返す

provides()register() でバインドしたすべてのサービスを返す必要があります。Laravelはこのリストを元に「どのサービスを要求したときにこのプロバイダーを読み込むか」を判断します。

サービスマニフェストの仕組み

Laravel は起動時に bootstrap/cache/services.php というマニフェストファイルを生成します。このファイルに遅延プロバイダーが提供するサービスの一覧が保存されています。
このマニフェストにより、Laravelはファイルを読み込まずに「このサービスはどのプロバイダーが提供するか」を把握できます。実際のプロバイダーは対象サービスが初めて解決されたときだけ読み込まれます。
プロバイダーを追加・変更した場合はマニフェストを再生成してください。

内部動作のフロー


provides() メソッドの重要性

provides()登録漏れがあると、そのサービスは永遠に解決されません。
$bindings / $singletons プロパティを使っている場合も同様に provides() に含めます。

遅延プロバイダーの制約

遅延プロバイダーはコンテナへのバインディング登録だけを目的としたプロバイダーに向いています。以下のようなことを boot() で行うプロバイダーは遅延にできません。
遅延プロバイダーに boot() メソッドを書くことは可能ですが、その内容はサービスが解決されるまで実行されません。ルートやミドルウェアのような「常に必要な処理」を boot() に書くと、予期しない動作になります。

when() メソッド — イベントトリガーによる登録

when() メソッドを使うと、特定のイベントが発火したときにプロバイダーを登録できます。これは、ジョブ処理系など特定のコンテキストでのみ必要なプロバイダーに使えます。
when() に返したイベントが発火すると、サービスが直接解決されていなくてもプロバイダーが読み込まれます。

パッケージ開発での活用

サードパーティパッケージとして配布するときも、遅延プロバイダーはユーザーのアプリケーションのパフォーマンスに貢献します。

推奨パターン

mergeConfigFrom() は設定のキャッシュ有無を内部でチェックしているため、遅延プロバイダーの register() の中で呼んでも安全です。ただし設定がキャッシュ済みの場合は何もしません。

runningInConsole() で Artisan コマンド登録を分離する

コマンド登録は Artisan 起動時のみ必要なので、runningInConsole() で条件分岐します。ただしコマンドを提供するプロバイダーを遅延にする場合は、コマンドクラスも provides() に含めるか、コマンド専用のプロバイダーを別に用意してください。

Laravel コアでの使用例

Laravelのコアプロバイダーの多くは遅延プロバイダーです。毎リクエストで使わないサービスをすべて即時読み込みしないための設計です。 API エンドポイントのみのアプリケーションでは、MailServiceProviderBroadcastServiceProvider がリクエスト中に一度も読み込まれないこともあります。

遅延化すべきかの判断基準

  • すべてのリクエストで使われるわけではないサービス(メール、レポート、外部 API クライアントなど)
  • 初期化に外部接続やファイル読み込みが必要なサービス
  • 重いオブジェクトグラフを持つサービス
  • CLI でのみ使うコマンドを提供するプロバイダー
  • ルートを登録するプロバイダー(loadRoutesFrom など)
  • 常時機能するミドルウェアや例外ハンドラーを登録するプロバイダー
  • Eloquent のグローバルスコープやオブザーバーを登録するプロバイダー
  • リクエストの大半で使われる軽量なサービス(遅延のオーバーヘッドの方が大きくなる場合)

関連ページ

パッケージ開発の基礎

サービスプロバイダーを核としたLaravelパッケージの開発方法を解説します。

パッケージのバージョン互換性管理

LaravelとPHPのメジャーバージョンアップに対応するパッケージのメンテナンス戦略を解説します。
最終更新日 2026年6月5日