Laravel・PHP開発についてよくある質問

個人開発では、この種の小さな認識違いが後から大きな手戻りになります。パッケージの互換性、PHPの実行環境、Dockerコンテナの状態、デプロイ先との差分。どれも最初は見えにくい。しかし、確認する場所とコマンドを分ければ、問題の切り分けはかなり速くなります。

この記事では、Laravel・PHP開発で頻繁に遭遇するバージョン確認の疑問を起点に、Laravelプロジェクト、Laravel Installer、Composer、Laravel Sail、アプリケーションコードの違いを整理します。単にコマンドを暗記するのではなく、どの数字が何を意味しているのかまで掘り下げます。

Laravelのバージョン確認で最初に使うコマンド

Laravelプロジェクトのルートディレクトリに移動して、まず実行するのは次のコマンドです。

php artisan --version

短縮形でも構いません。

php artisan -V

このコマンドで確認できるのは、現在のプロジェクトにインストールされているLaravelフレームワークのバージョンです。Laravel開発で「このプロジェクトは何を使っているのか」を確認したい場合、最も標準的な入口になります。

ここで大切なのは、Laravelのプロジェクトディレクトリで実行することです。別のディレクトリで実行すれば、artisanファイルが見つからない、あるいは意図したプロジェクトとは別の環境を見てしまう可能性があります。

一般的な確認の流れは、次のようになります。

1. 対象プロジェクトのルートディレクトリへ移動する

2. php artisan -Vを実行する

3. 表示されたLaravelのバージョンを確認する

4. 必要であればComposerの依存関係も確認する

たとえば、プロジェクトに移動してから次のように実行します。

cd プロジェクト名

php artisan -V

この手順は単純ですが、個人開発の現場では「どのディレクトリでコマンドを打ったか」が意外と重要です。複数のLaravelプロジェクトを並行していると、ターミナルの現在地を取り違えます。新しいプロジェクトを作った直後や、古い案件を久しぶりに開いたときほど、この確認を最初に行うようにしています。

php artisan -Vで確認できるもの

php artisan -Vが対象にしているのは、プロジェクト側にインストールされたLaravelです。

つまり、確認している対象は次のようなものです。

• 現在のLaravelプロジェクトで利用されているフレームワーク
• Composerによって解決された依存関係
• vendorディレクトリにインストールされたLaravel関連コード
• composer.lockの内容に基づいて構築された実行環境

ここには、グローバルにインストールしたツールのバージョンは直接関係しません。Laravel Installerのバージョンが新しくても、既存プロジェクトのLaravelが自動的に新しくなるわけではありません。

Laravelのバージョンを知りたいなら、まずプロジェクト内のartisanを確認する。グローバルツールの数字を見て、アプリケーション本体のバージョンだと判断しないこと。

laravel -Vとの違いで混乱しやすい理由

Laravelのバージョン確認で最も多い混乱が、php artisan -Vとlaravel -Vの違いです。

ターミナルで次のコマンドを実行したとします。

laravel -V

この場合に返されるのは、Laravelフレームワーク本体ではありません。Laravel Installerのバージョンです。

Laravel Installerは、新しいLaravelプロジェクトを作成するときに利用するコマンドラインツールです。一方、php artisanは、すでに作成されたLaravelプロジェクトの中で動作するアプリケーション側のコマンドです。

役割が違います。

この違いを理解せずにlaravel -Vだけを見ていると、既存サービスの環境を誤認します。

たとえば、Laravel Installerがあるバージョンであっても、既存プロジェクトのcomposer.lockが別のLaravelバージョンを固定していれば、アプリケーションはその固定された依存関係で動作します。Installerはプロジェクトの作成を補助する道具であり、プロジェクト内のフレームワークを常に代表する存在ではありません。

Laravel Installerのバージョンを確認する場面

laravel -Vが不要という意味ではありません。新しくプロジェクトを作成する環境を整える場合には、Installerのバージョン確認も役に立ちます。

たとえば、次のような場面です。

• 新規プロジェクト作成時にコマンドが動作しない
• チーム内でLaravel Installerの挙動をそろえたい
• グローバルツールの更新後に生成内容が変わったか確認したい
• 既存の開発環境でどのInstallerを利用しているか調べたい

ただし、確認対象を明確にする必要があります。

「プロジェクトを作るためのツール」を知りたいならlaravel -V。「現在のアプリケーションが使うLaravel」を知りたいならphp artisan -V。この切り分けだけで、かなりの誤解を避けられます。

DockerとLaravel Sailでは実行場所が変わる

Docker環境、とくにLaravel Sailを利用している場合は、さらに一段階ややこしくなります。

ホストマシンで次のコマンドを実行しても、ホスト側にPHPがインストールされていない、またはプロジェクトで使っているPHPと異なることがあります。

php artisan -V

Laravel Sailでは、アプリケーションの実行環境がコンテナ側にあります。そのため、Sail経由でArtisanを実行します。

sail artisan -V

環境によっては、次の形式を使います。

./vendor/bin/sail artisan --version

この2つは、実質的にSailコンテナ内のLaravelプロジェクトに対してArtisanコマンドを実行するための方法です。

Sailのエイリアスに依存しすぎない

Laravel Sailを導入すると、sailという短いコマンドで操作できるように設定することがあります。入力が楽になる一方、環境によってはエイリアスが設定されていません。

その場合は、プロジェクト内の実体を直接呼び出します。

./vendor/bin/sail artisan -V

この書き方なら、現在のプロジェクトに含まれているSailを経由できます。個人開発で複数プロジェクトを扱う場合、グローバルなコマンドに頼らず、プロジェクト内の実行ファイルを明示するほうが原因を追いやすいケースがあります。

確認の観点は、Laravelだけではありません。Docker環境では、次の層を分けて考えます。

• ホストOSに入っているPHPのバージョン
• Dockerコンテナ内で実行されるPHPのバージョン
• Composerが依存関係を解決した条件
• プロジェクトにインストールされたLaravelのバージョン
• 実際にHTTPリクエストを処理しているコンテナ

ホスト側でphp -vを実行して確認できるのは、あくまでホストのPHPです。Sailのコンテナ内で動いているPHPを確認したいなら、Sail経由でPHPコマンドを実行する必要があります。

たとえば、環境によっては次のように確認します。

./vendor/bin/sail php -v

ここで表示されるPHPと、ホスト側でphp -vを実行した結果が異なっていても、不思議ではありません。むしろDockerを使う理由のひとつは、プロジェクトごとに実行環境を分離することです。

バージョン確認は環境差分の発見にも使える

Laravelのアップデートやパッケージ追加でエラーが発生したとき、Laravelのバージョンだけを見ていると問題の本体を逃します。

たとえば、次のような状態です。

• ホストのPHPでは動くが、コンテナのPHPでは動かない
• ローカルでは動くが、デプロイ先のPHP拡張が足りない
• composer install後に別のパッケージバージョンが入る
• composer updateを実行したことで依存関係が変わる
• Artisanは動くが、Webサーバー経由では別のコンテナを見ている

このとき必要なのは、単独のバージョン情報ではなく、実行経路の確認です。

「どのPHPが」「どのComposerで」「どのvendorディレクトリを使い」「どのコンテナから」Laravelを動かしているのか。ここまで分解すると、エラーの位置が見えてきます。

アプリケーションコードからLaravelのバージョンを取得する

ターミナルではなく、アプリケーションのコード内からLaravelのバージョンを取得したい場合もあります。

代表的なのは次の方法です。

app()->version()

または、次の形式です。

App::VERSION()

ControllerやBladeの中で、実行中アプリケーションのLaravelバージョンを参照できます。

この方法が有効なのは、実行環境そのものに関する情報をアプリケーションから確認したい場面です。たとえば、管理者向けの環境情報ページ、診断用の画面、運用時のログ、サポート対応用のデバッグ情報などです。

ただし、公開ページにそのまま表示する場合は慎重さが必要です。Laravelのバージョンは、構成情報の一部です。開発中のローカル画面や管理者限定の診断ページでは便利でも、誰でも閲覧できるページに常時表示する必要は通常ありません。

Controllerで確認する場合

Controllerでは、取得したバージョンをレスポンスやビューに渡せます。

たとえば、考え方としては次のようになります。

• app()->version()で現在のLaravelバージョンを取得する
• 必要な画面にだけ値を渡す
• デバッグや管理画面で確認する
• 本番環境での公開範囲を制限する

ここでのポイントは、バージョン取得のコード自体を目的にしないことです。プロダクトに必要な情報として使うのか、運用上の診断情報として使うのか。用途を先に決めるべきです。

プロダクトグロースの観点では、技術情報を画面に出すこと自体に価値があるわけではありません。ユーザーの痛みを解消するのか、運用担当者の調査時間を短縮するのか。目的がなければ、管理画面に情報を追加しただけで終わります。

Bladeで表示する場合

Bladeテンプレートでも、アプリケーションのバージョンを参照できます。開発中にフッターや管理画面へ表示する使い方は分かりやすいでしょう。

ただし、表示を常設するより、環境情報をまとめた診断ページとして管理するほうが運用しやすい場合があります。

診断ページに載せる候補は、次のような情報です。

• Laravelのバージョン
• PHPのバージョン
• アプリケーション環境
• データベース接続先の識別情報
• キャッシュやキューの稼働状態
• アプリケーションのリリース識別子

ここでも、秘密情報を表示しない設計が前提です。.envの内容をそのまま出すのは避け、確認に必要な情報だけを選びます。

Composerで依存関係を正確に確認する

Laravelのバージョン確認では、Composerを避けて通れません。LaravelはComposerによって依存関係を管理するため、フレームワークのバージョンだけでなく、周辺パッケージとの組み合わせを見る必要があります。

Laravel本体に関する情報を確認するなら、次のコマンドが使えます。

composer show laravel/framework

このコマンドでは、Composerが管理しているlaravel/frameworkパッケージの詳細を確認できます。

php artisan -Vは、実行中のLaravelを素早く知るためのコマンドです。一方、composer show laravel/frameworkは、依存関係の管理状況を調べるためのコマンドです。

両者は競合しません。用途が異なります。

composer.jsonだけでは判断しきれない

Laravelのバージョンをcomposer.jsonだけで判断するのは危険です。

composer.jsonには、依存関係の許容条件が記述されています。たとえば、特定のメジャーバージョンや範囲を指定していても、実際にインストールされている細かなバージョンまで一意に分かるとは限りません。

実際のインストール結果を確認するには、次の情報を見ます。

• composer.lockに固定された依存関係
• vendorディレクトリにインストールされた実体
• composer showで表示されるパッケージ情報
• 実行時にLaravelが返すバージョン

composer.jsonは「どの範囲のバージョンを許容するか」を見る場所。composer.lockは「今回の環境でどのバージョンを採用したか」を見る場所。この違いを押さえておく必要があります。

composer.jsonは希望条件、composer.lockは解決結果。Laravelのバージョン確認では、この2つを同じものとして扱わない。

個人開発では、動いている環境を自分ひとりで管理するため、ついcomposer.jsonだけを見て安心しがちです。しかし、開発用PCと本番環境、ローカルとDocker、手元のvendorとデプロイ先のvendorが一致しているとは限りません。

アップデートの前後では、バージョンを確認する場所を増やすことが、結果的に調査時間を減らします。

composer installとcomposer updateの違いを意識する

Composerの操作では、installとupdateの役割を混同しないことが重要です。

composer installは、既存のロックファイルをもとに依存関係をインストールするために使われます。開発環境の再構築やデプロイなど、決められた依存関係を再現したい場面に向いています。

一方、composer updateは依存関係を再解決します。条件の範囲内で、より新しいパッケージが選択される可能性があります。

この違いを理解せずに本番環境でcomposer updateを実行すると、意図せずLaravelや関連パッケージの組み合わせが変わることがあります。動作確認やロールバックの観点からも、更新操作は目的を明確にして行うべきです。

Laravelのバージョンを確認したいときは、まず現状を読む。アップデートしたいときは、変更対象と影響範囲を定める。確認と変更を同じ操作の中で済ませない。この分離が、地味ですが効きます。

新規Laravelプロジェクトを作る標準フロー

新しいLaravelプロジェクトを作成する方法として、Composerのcreate-projectが広く使われています。

composer create-project laravel/laravel プロジェクト名

プロジェクト作成後は、対象ディレクトリへ移動して、Laravelのバージョンを確認します。

cd プロジェクト名

php artisan -V

その後、PHPの内蔵サーバーを起動して動作を確認できます。

php artisan serve

この流れは、Laravelを学び始めた段階だけでなく、小さな個人開発を素早く立ち上げるときにも使いやすい構成です。

ただし、プロジェクト作成コマンドを実行しただけで、開発環境の検証が終わったわけではありません。実際にアプリケーションが起動するか、Composerの依存関係が解決されているか、必要な環境変数が設定されているか。最低限の動作確認まで行って、初めて開発のスタートラインに立てます。

作成直後に確認したいこと

新規プロジェクトを作成した直後は、次の順番で確認すると状況を把握しやすくなります。

1. PHPが実行できるか確認する

PHPの実行環境がない、または想定と異なる場合、Laravel以前の段階で止まります。

2. Composerの依存関係が解決されているか確認する

vendorが生成されているか、Composerの処理が途中で失敗していないかを見ます。

3. Artisanが起動するか確認する

php artisan -VでLaravelのバージョンを確認します。

4. 開発サーバーを起動する

php artisan serveでブラウザからアプリケーションへアクセスします。

5. 環境設定の不足を確認する

.envやアプリケーションキーなど、起動後に必要となる設定を確認します。

6. データベースを使う処理を試す

Laravelの画面が表示されても、データベース接続やマイグレーションが正常とは限りません。

この手順の良いところは、問題を一度に解こうとしないことです。PHP、Composer、Laravel、Webサーバー、データベースという層ごとに確認するため、どこで止まったかが分かります。

php artisan serveを使うときの位置づけ

php artisan serveは、ブラウザでLaravelの動作を確認するための手軽な方法です。初期開発や画面確認には便利ですが、本番運用のWebサーバー構成そのものを再現するコマンドではありません。

個人開発では、まず画面を表示できる状態にしてユーザーの痛みを確認することが優先される場面もあります。最初から完璧なインフラ構成を作ろうとすると、プロダクトの仮説検証に入る前に時間を使い切ってしまいます。

一方で、公開前には本番の実行環境との差分を確認する必要があります。

• PHPのバージョンが同じか
• 必要なPHP拡張が入っているか
• Composerの依存関係が一致しているか
• 環境変数が適切か
• キャッシュやキューの扱いが異なっていないか
• Webサーバー経由でも同じアプリケーションを見ているか

開発速度を上げることと、環境差分を放置することは別です。前者は仮説検証を速くしますが、後者はリリース直前の離脱要因になります。

バージョン確認をデバッグの入口にする

Laravelのバージョンを確認することは、単なる環境情報の収集ではありません。エラー調査の最初の一手として使えます。

たとえば、あるパッケージの導入でエラーが発生した場合、次の情報が不足していると原因を絞れません。

• Laravelのバージョン
• PHPのバージョン
• Composerの依存関係
• 実行している環境がホストかDockerか
• 開発環境か本番環境か
• パッケージを追加・更新したタイミング

ユーザーから厳しいフィードバックを受けたとき、原因が機能そのものではなく、環境差分や例外処理の不足だったということがあります。エラーメッセージだけを追いかけても、前提条件が違えば検証結果はぶれます。

そこで、障害や不具合が出たら、最初に環境情報をそろえます。これは特別なテクニックではありません。仮説の精度を上げるための準備です。

Laravelのメジャーバージョンだけで判断しない

Laravelのバージョンが分かっても、それだけで互換性の問題を判断できるとは限りません。

同じLaravelのメジャーバージョンでも、PHPのバージョン、データベース、Composerパッケージ、PHP拡張、OSやコンテナ構成が異なれば、結果は変わります。

Laravelのアップデートを検討するときは、次のように情報を並べて見ます。

• Laravelフレームワークのバージョン
• PHPのバージョン
• laravel/framework以外の主要パッケージ
• composer.jsonの依存条件
• composer.lockの更新状況
• DockerイメージやSailの構成
• マイグレーションやキュー処理への影響

とくに古いLaravelプロジェクトでは、サポート状況を確認する必要があります。Laravel 6.xのセキュリティサポートは2022年9月に終了しています。古いバージョンを使い続けている場合、単に「動いているから問題ない」とは言い切れません。

もちろん、すぐにアップデートできない事情はあります。既存パッケージが対応していない、仕様変更の影響が大きい、テストが不足している。そうした現実を無視して、最新化だけを押し付けるのは実務的ではありません。

必要なのは、現在のバージョンを正確に把握したうえで、更新できない理由を分解することです。対応可能なパッケージから更新するのか、テストを追加するのか、段階的にLaravelを上げるのか。ここからが施策です。

よくある確認ミスと、切り分けの考え方

Laravel・PHP開発で発生するバージョン確認のミスは、コマンドの知識不足だけが原因ではありません。確認した数字の意味を取り違えていることが多いです。

1. laravel -VをプロジェクトのLaravelだと思う

これは最も典型的なミスです。

laravel -VはLaravel Installerのバージョンを返します。既存アプリケーションのLaravelを確認するなら、プロジェクト内でphp artisan -Vを実行します。

2. composer.jsonの記述だけで実際のバージョンを決める

composer.jsonは依存関係の条件を示すファイルです。正確なインストール結果を見るには、composer.lockやcomposer show laravel/frameworkも確認します。

3. Docker利用中にホスト側のPHPを確認する

Sailを使っているなら、ホスト側のphp -vだけでは不十分です。Sail経由でArtisanやPHPを実行し、コンテナ内の実行環境を確認します。

4. Laravelだけ確認してPHPを見ない

Laravelのバージョンが同じでも、PHPのバージョンが異なれば動作結果は変わります。Laravelの確認と同時に、実際にコードを実行するPHPも確認します。

5. 更新コマンドを実行してから状態を確認する

現在の状態を知りたいだけなのに、先にcomposer updateを実行すると、確認前に環境が変わってしまいます。

調査では、まず読む。次に仮説を立てる。その後に変更する。この順番を崩さないことが、再現性のある開発につながります。

Laravelのバージョン確認をチームや運用に組み込む

個人開発では、自分が覚えていれば何とかなるように見えます。しかし、時間が経つと自分自身が過去の自分のコードを引き継ぐことになります。

数か月前に作ったアプリケーションを再開したとき、どのPHPを使っていたのか、なぜそのComposerパッケージを選んだのか、どのLaravelバージョンで動作していたのかが分からない。これは珍しくありません。

そこで、バージョン確認を手作業の記憶に頼らず、プロジェクトの運用に組み込んでおくと効果があります。

READMEに開発環境を残す

プロジェクトのREADMEには、最低限次の情報を残しておくと再開時に役立ちます。

• Laravelの確認コマンド
• PHPの想定バージョン
• DockerやLaravel Sailの起動方法
• Composerのインストール手順
• データベースの準備方法
• 開発サーバーの起動方法
• マイグレーションの実行手順

数字だけを固定して書くより、確認コマンドを残すことが重要です。バージョン情報は更新される可能性がありますが、確認手順は後から状態を再取得できます。

デプロイ時に環境情報を記録する

デプロイのたびに、LaravelやPHPのバージョンをログに残す運用も有効です。

目的は監視画面を豪華にすることではありません。障害が起きたときに、どのリリースがどの環境で動いていたかを追跡できるようにすることです。

アプリケーションコードからapp()->version()を取得できるため、管理者向けの診断情報や内部ログに活用できます。公開ユーザーへ見せる必要がない情報は、管理範囲を限定します。

バージョン確認をリリース前の仮説検証に含める

新機能をリリースするとき、確認すべきなのは画面が表示されるかだけではありません。

「この機能は現在のLaravelとPHPの組み合わせで安定して動く」という仮説を立て、その仮説を確認します。

たとえば、次のような検証です。

• 開発環境と本番環境のLaravelが一致しているか
• Composerのロックされた依存関係を使っているか
• Docker環境と実際のデプロイ先の差が許容範囲か
• パッケージ更新後に既存機能が壊れていないか
• エラー発生時に環境情報を追跡できるか

技術的な確認は、プロダクトの目的から離れているように見えます。しかし、ユーザーが使えない機能は、どれだけきれいに実装してもコンバージョンにつながりません。

実務で使い分ける確認フロー

最後に、状況ごとの判断をまとめます。

既存Laravelプロジェクトのバージョンを知りたい

プロジェクトルートで次を実行します。

php artisan -V

DockerやLaravel Sailなら、次を使います。

./vendor/bin/sail artisan -V

Laravel Installerのバージョンを知りたい

グローバルに利用しているInstallerを確認するなら、次を実行します。

laravel -V

ただし、これはアプリケーション本体のLaravelバージョンではありません。

Composerの依存関係を詳しく知りたい

次のコマンドを実行します。

composer show laravel/framework

必要に応じて、composer.jsonとcomposer.lockも確認します。

アプリケーション実行時のLaravelを知りたい

ControllerやBladeなど、アプリケーションコード内では次を使います。

app()->version()

または次の形式です。

App::VERSION()

新規プロジェクトを作成したい

Composerを使う場合は、次のコマンドが基本です。

composer create-project laravel/laravel プロジェクト名

作成後にArtisanでバージョンを確認し、開発サーバーを起動します。

php artisan -V

php artisan serve

このフローを自分の中で固定しておくと、Laravelのバージョン確認が必要になったときに迷いません。

まとめ：数字を見る前に、確認対象を決める

Laravel・PHP開発でバージョンを確認するとき、最も重要なのはコマンドの数ではありません。いま何のバージョンを知りたいのかを決めることです。

• Laravelプロジェクト本体ならphp artisan -V
• Laravel Installerならlaravel -V
• Composerのパッケージ情報ならcomposer show laravel/framework
• アプリケーションコード内ならapp()->version()やApp::VERSION()
• Laravel SailならSail経由でArtisanを実行する
• 正確な依存関係はcomposer.lockも含めて確認する

この切り分けができれば、「表示された数字が違う」という混乱は、調査可能な情報に変わります。

個人開発では、すべてを完璧に管理するのは難しい。だからこそ、確認コマンドをREADMEに残し、Dockerとホストの実行環境を分け、Composerの更新前後で状態を記録する。泥臭い運用ですが、こうした小さな仕組みが、次の検証を速くします。

次に試したいことは、デプロイ時にLaravel・PHP・主要パッケージのバージョンを自動的に記録する仕組みです。ユーザーの反応を見ながら機能を改善するだけでなく、どの環境でその反応が生まれたのかまで追える状態にする。プロダクトの仮説検証を止めないために、開発環境の可視化も継続して整えていきます。

Related reading: Laravel・PHP開発を選ぶときの確認ポイント and Laravel・PHP開発をわかりやすく解説.