第01回: サービスコンテナの解剖 — Laravelはなぜ「魔法のように」動くのか？

(Updated: )
1 min read

章: 第1章: Laravel内部と設計基盤

app(PaymentGateway::class) と書くだけで、設定ファイルも書かず、new もせずにオブジェクトが降ってくる。これはなぜでしょうか？Laravelを深く使うほど「どこで何が解決されているのか」が分からなくなる瞬間が来ます。サービスコンテナを理解すると、その霧が晴れます。

サービスコンテナは、Laravelの心臓部とも言える 依存解決エンジン です。ControllerがRepositoryを受け取り、RepositoryがDBConnectionを受け取る―この連鎖を自動で組み立てているのがコンテナです。これを理解すると、設計の自由度とデバッグ力が一気に上がります。

なぜサービスコンテナが重要なのか

依存解決の仕組みを理解していないと、次のような問題に直面します。

  • bind と singleton の使い分けが曖昧で、意図せず複数インスタンスが生成される
  • テスト時にモックへの差し替えができない
  • ServiceProviderの設計が膨らんで保守しにくくなる

チェックポイント: bind は呼ぶたびに新しいインスタンスを生成し、singleton は初回のみ生成して使い回します。まずこの差を手元で確認しましょう。

bind vs singleton — どちらを使うべきか

観点 bind singleton
インスタンス数 呼ぶたびに新規生成 初回のみ生成、以降は同じ
向いている用途 リクエストごとに状態が異なるオブジェクト 設定・DBコネクションなど共有したいサービス
テスト時の差し替え 容易 app()->instance() で上書き可能
典型的な誤用 セッション情報をsingletonに持たせる

実装例


<?php
app()->bind(App\Contracts\PaymentGateway::class, App\Services\StripeGateway::class);

$gatewayA = app(App\Contracts\PaymentGateway::class);
$gatewayB = app(App\Contracts\PaymentGateway::class);

var_dump($gatewayA === $gatewayB); // false（bindは都度生成）

singleton に変えると true になります。この差が、実務でのバグや設計判断に直結します。

確認の3ステップ

1. 同じクラスを bind で2回解決し、=== で比較して false を確認する

2. singleton に変えて true になることを確認する

3. テスト内で app()->instance(PaymentGateway::class, $mock) でモックに差し替え、正常に動くことを確認する

まとめ & 次のステップ

  • サービスコンテナはLaravelの依存解決エンジンであり、ControllerやJobが自動で組み立てられる基盤
  • bind は都度生成、singleton は使い回し ― この違いを押さえるのが第一歩
  • インターフェースとの組み合わせで、テスト時のモック差し替えが可能になる
  • ServiceProviderがコンテナへの「登録窓口」であることを意識すると全体像が見えてくる

次回は 第02回: Service Provider設計 で、コンテナへの登録をどこで・どう管理するかを学びます。

Related Articles