Laravelプロジェクトでcomposer.jsonを見るべきポイント

Laravelプロジェクトを引き継いだとき、あるいは新しく参加したとき、最初に見るべきファイルはどれかと聞かれたら、私は迷わずcomposer.jsonを挙げます。理由は単純で、composer.jsonには「このLaravelプロジェクトがどんな思想で作られ、どこにリスクが潜んでいるか」がかなり正直に書かれているからです。

見た目はただの依存関係定義ファイルですが、実際にはフレームワークのバージョン方針、チームの運用スタイル、将来の保守コストまで読み取れます。この記事では、Laravelプロジェクトでcomposer.jsonを見るときに、どこをどう見ればよいのかを、実務目線で整理します。

Laravelプロジェクトとcomposer.jsonの関係

LaravelはPHPフレームワークですが、その実体は「Composerで管理されるパッケージ群の集合体」です。laravel/framework自体もComposerパッケージの一つに過ぎません。

そのためcomposer.jsonを見るという行為は、単に依存ライブラリを確認するだけでなく、Laravelプロジェクト全体の設計思想を読む行為に近いものがあります。

特に以下のような場面では、composer.jsonを読む力がそのまま判断力につながります。

• バージョンアップ対応がどれくらい大変そうかを見積もるとき
• 本番障害が起きた際に、どのライブラリが影響しているかを切り分けるとき
• 「このプロジェクト、なんでこんなに壊れやすいんだろう？」と感じたとき

requireでまず確認すべきこと

PHPとLaravel本体のバージョン指定

最初に見るべきはrequireセクションです。中でも最重要なのがPHPのバージョン指定とLaravel本体の指定です。

{
  "require": {
    "php": "^8.1",
    "laravel/framework": "^10.0"
  }
}

この2行だけでも、多くのことが分かります。PHPの指定が^8.1なのか、>=8.1なのか、あるいは~8.1なのかで、運用の柔軟性が変わります。またLaravelのメジャーバージョンが固定されているかどうかで、将来のアップグレード難易度も予測できます。

実務では「Laravelは10系だけど、PHPはやたら古い」「PHPは新しいのにLaravelが古い」といったアンバランスな指定を見かけることも少なくありません。こうした状態は、長期的には確実に技術的負債になります。

laravel/framework以外の必須パッケージ

次に注目したいのが、Laravel以外に何がrequireされているかです。

• 認証系（sanctum, passportなど）
• ファイル操作系
• 外部API連携用SDK
• 独自に作られた社内パッケージ

ここで重要なのは「なぜこのパッケージが必要なのか」を想像することです。数が多いこと自体が即悪ではありませんが、用途が見えない依存が多い場合、ブラックボックス化している可能性があります。

バージョン制約の書き方から分かる運用レベル

^ と ~ と固定バージョン

composer.jsonの読みどころとして、バージョン制約の書き方は外せません。

• ^10.0
• ~10.2
• 10.3.1（完全固定）

^指定は比較的モダンで、セキュリティアップデートやマイナーアップデートを取り込みやすい指定です。一方、完全固定が多い場合は「とにかく壊したくない」「アップデートが怖い」という心理が透けて見えます。

実際にやると分かりますが、完全固定が多いプロジェクトほど、いざアップデートしようとしたときの衝撃は大きくなりがちです。

無意味に広い指定に注意

逆に注意したいのが、やたら広い指定です。

"some/package": "*"

この指定は一見楽そうに見えますが、環境差異や再現性の問題を生みやすくなります。Laravelプロジェクトでは、開発環境・CI・本番で挙動が変わる原因になりやすいため、基本的には避けたほうが無難です。

require-devから見えるチーム文化

require-devには、テストや開発支援ツールが並びます。

• phpunit/phpunit
• nunomaduro/larastan
• barryvdh/laravel-debugbar
• fakerphp/faker

ここを見ると、そのチームがテストや静的解析をどれくらい重視しているかが分かります。例えばテスト系が一切入っていない場合、「テストはほぼ書かれていない」と考えて大きく外れることはあまりありません。

逆に、larastanやphp-cs-fixerなどがきちんと入っている場合、一定の品質基準を保とうとしている可能性が高いです。

scriptsに書かれていることは必ず読む

composer.jsonのscriptsセクションは、見落とされがちですが非常に重要です。

"scripts": {
  "post-install-cmd": [
    "@php artisan key:generate"
  ]
}

ここには、インストール時やアップデート時に自動で実行される処理が書かれています。CIや本番デプロイ時の挙動に直結するため、「何が勝手に実行されるのか」は必ず把握しておく必要があります。

過去には、scriptsに書かれた処理のせいで本番環境の設定ファイルが書き換わる、といった事故も見てきました。

autoload設定から設計の癖を読む

autoloadセクションを見ると、プロジェクトのディレクトリ設計や思想が見えてきます。

• PSR-4がきれいに守られているか
• 独自namespaceが乱立していないか
• app配下以外に謎のディレクトリが追加されていないか

autoloadが整理されていないLaravelプロジェクトは、コードを追うだけでもストレスが溜まりがちです。composer.jsonでその兆候を事前に察知できるのは、大きなメリットです。

リスクとして必ず意識しておきたい点

composer.jsonは便利な反面、依存関係の塊でもあります。一つのパッケージ更新が、思わぬ不具合を呼ぶこともあります。

特に注意したいのは以下の点です。

• Laravel本体と互換性の怪しい外部パッケージ
• メンテナンスが止まっているライブラリ
• バージョン指定が極端に古い依存

これらはすぐに問題にならなくても、数年後に確実に効いてきます。composer.jsonを読む習慣は、将来の自分やチームを助ける保険のようなものです。

結局、composer.jsonはどう扱えばいいのか

Laravelプロジェクトでcomposer.jsonを見るべきポイントを一言でまとめるなら、「依存関係を眺めるのではなく、背景を読む」という姿勢が大切です。

バージョン指定の癖、入っているライブラリ、入っていないツール。その一つひとつが、過去の意思決定の結果です。composer.jsonを丁寧に読むことで、コードを読む前からプロジェクトの地雷原が見えてくることもあります。

Laravelに慣れてきた人ほど、composer.jsonを軽視しがちですが、実はここを読む力こそが、プロジェクト全体を安全に扱うための近道なのかもしれません。