---
title: "Laravelのバージョン確認｜artisanとcomposerの違いとサポート期限"
url: "https://www.issoh.co.jp/tech/details/17116/"
published: 2026-08-29
updated: 2026-08-30
categories: ["Laravel"]
publisher: "株式会社一創"
---

# Laravelのバージョン確認｜artisanとcomposerの違いとサポート期限

php artisan –version と打つと、Laravel Framework 13.29.0 のような1行が返ってきます。ただしこの1行が答えになる場面と、ならない場面があります。composer.json の記述は許容範囲の宣言であって、いま動いている版そのものではありません。グローバルに入れた laravel コマンドの –version にいたっては、フレームワークではなくプロジェクト作成用インストーラの版を返します。確認方法ごとに何が見えているのかを切り分け、コマンドラインが使えない本番での手順、出た数字を公式のサポート期限表に照らして移行を決めるところまで扱います。

## まとめ：確認コマンドごとに見える対象と出た数字から決める移行判断

先に結論を並べます。数値は2026年8月29日時点のGitHubソースとReleases API、期限は公式のサポート表で確認したものです。

- 第一手は`php artisan --version`。返るのは`Illuminate\Foundation\Application::VERSION`の値で、実行中の本体の版です。
- composer.json の require は許容範囲の宣言です。実際に入っている版は composer.lock か`composer show`で見ます。
- `laravel --version`が返すのはインストーラの版。2026年8月25日リリースの v5.32.0 が最新で、本体の13系とは無関係な数字です。
- 環境ごと棚卸しするなら`php artisan about --only=environment`。Laravel版とPHP版が一度に並びます。
- 最新の本体は13系で、2026年8月25日リリースの v13.29.0。12系は同日の v12.68.0 です。
- サポートは全リリース一律でバグ修正18か月・セキュリティ修正2年。現行ポリシーにLTSという区分はありません。
- 12系のバグ修正提供は2026年8月13日で終了。残るのは2027年2月24日までのセキュリティ修正だけです。
- 11以下ならセキュリティ修正はすでに切れています。移行先の上限を決めるのはPHPの版です。

以下、各方法が何を見ているのかを順に整理します。

## Laravelで「バージョン」と呼ばれる対象の切り分けと確認コマンドの対応

つまずく原因は、コマンドを知らないことではありません。返ってきた数字が「どの対象の版か」を取り違えることです。フレームワーク本体、composer.json の制約、vendor の実体、作成用インストーラ。この4つは別物で、同じ言葉で呼ばれます。

### Laravelの6つの確認方法が返す値と、それぞれが指す対象

まず対応関係を押さえます。上の2行が日常的に使うもので、下の4行は状況に応じて使い分ける経路です。

| 確認方法                  | 返る値             | 使う場面      |
| --------------------- | --------------- | --------- |
| php artisan –version  | 実行中の本体の版        | 手元と本番での即答 |
| php artisan about     | 本体とPHPとComposer | 環境全体の棚卸し  |
| composer show（本体指定）   | 導入済みの版と説明       | 依存の内訳の確認  |
| composer.jsonのrequire | 許容する版の範囲        | 制約の設計意図   |
| composer.lockのversion | 固定された実際の版       | CLIが無い環境  |
| laravel –version      | インストーラの版        | 作成コマンドの更新 |

実務で問題になるのは4行目と5行目の差、そして6行目です。composer.json を見て報告した版が、本番の版と違っていた。この事故は珍しくありません。

### php artisan –versionが返すフレームワーク本体の版と出力形式

artisan スクリプトがあるプロジェクトのルートで実行します。`php artisan --version`でも`php artisan -V`でも結果は変わりません。

この形になる理由はソースを追うと分かります。`Illuminate\Console\Application`のコンストラクタが、Symfony Console の親クラスへ`parent::__construct('Laravel Framework', $version)`とアプリ名と版を渡しているためです。後半の実体は`Illuminate\Foundation\Application::VERSION`で、13.xブランチのソースではこの定数が2026年8月29日時点で ‘13.29.0’ になっています。

返るのは「PHPが実際にオートロードした本体の版」です。composer.json に何が書いてあっても、vendor の実体が答えになります。裏を返せば、vendor が無い環境やPHPのパスが違う環境では動きません。artisan で使える他のコマンドは[php artisan makeコマンド一覧と生成先・オプションの早見表](https://www.issoh.co.jp/tech/details/3759/)にまとめてあります。

### composer.jsonの制約とcomposer.lockの実際の版の食い違い

composer.json の require に書かれる`"laravel/framework": "^13.0"`は、13.0.0 以上 14.0.0 未満という範囲の指定です。Laravel は破壊的変更をメジャーの更新に限るため、公式ドキュメントもこのキャレット付きの制約を推奨しています。範囲であって、固定値ではありません。

実際に入った版は composer.lock 側に記録されます。packages 配列の laravel/framework エントリにある version キーに、v13.29.0 のような具体値が入る形です。制約が同じでも、`composer update`を回した日付で lock の中身は 13.0.0 にも 13.29.0 にもなります。

この差が表面化しやすいのは、他人のブランチをチェックアウトしたときと、デプロイ手順に`composer install`が抜けている本番です。突き合わせるなら`composer show laravel/framework`を実行してください。versions の行に現在の版が印付きで出ます。

### laravel –versionが返すのはインストーラの版という落とし穴

これが最も誤読されやすい経路です。`composer global require laravel/installer`で導入する laravel コマンドは`laravel new`で雛形を作るためのもので、フレームワーク本体とはリリースサイクルが別々に回っています。

インストーラの最新タグは、2026年8月25日リリースの v5.32.0 です。この状態で`laravel --version`を叩けば「5.32.0」が返ります。本体が13系であるにもかかわらず、です。ここで「うちはまだLaravel 5系なのか」と判断すると、調査の方向が根本から狂います。

切り分けの基準は単純です。プロジェクトの版を知りたいなら artisan、雛形を作るコマンド自体の版を知りたいときだけグローバルの laravel コマンド。インストーラを更新しても、既存プロジェクトの版には何の影響もありません。

### php artisan aboutで同時に確認するPHP版とComposer版

Laravel 9で追加された about コマンドは、環境の情報をセクション別にまとめて出します。ソース上の signature は`about {--only=} {--json}`で、Environment セクションに含まれる項目は次のとおりです。

- Application Name、Laravel Version、PHP Version、Composer Version
- Environment（app.env の値）、Debug Mode（有効なら ENABLED 表示）
- URL、Maintenance Mode、Timezone、Locale

Laravel の版と PHP の版が同じ画面に出るのが利点です。移行判断ではこの2つをセットで見るため、`php artisan about --only=environment`を1回叩くほうが、artisan –version と php -v を別々に打つより確実に揃います。棚卸しの自動化には`--json`を付けてください。Cache や Drivers には接続先の設定も並ぶため、出力をそのまま外部へ貼らない扱いが要ります。

## CLIが使えない本番・共有サーバーでバージョンを確認する経路

引き継いだ案件でSSHが通らない、コントロールパネルからファイルしか触れない。この状況でも版は特定できます。artisan に頼らない経路が3つあります。

### composer.lockとinstalled.jsonをファイルとして読む手順

FTPやファイルマネージャでソースを開けるなら、コマンドを使わずに確定できます。

1. プロジェクト直下の composer.lock を開き、packages 配列から laravel/framework のブロックを探す。
2. 同じブロック内の “version” の値を読む。v13.29.0 のような形で、これが lock された時点の版。
3. vendor/composer/installed.json を開き、同じパッケージの version を照合する。こちらは展開されている実体の記録。
4. 2つの値が違えば、composer install が走っていないか、vendor が手動で差し替えられている。

4番目の食い違いは、デプロイ手順の欠落を示す手がかりです。lock だけ新しくて installed.json が古いなら、動いているのは後者の版であり、判断の材料もそちらになります。

そのデプロイ手順にキャッシュ生成をどう組み込むかは、[Laravelのキャッシュクリア｜cache:clearとoptimize:clearの違いと本番デプロイの手順](https://www.issoh.co.jp/tech/details/17121/)でコマンドの順序として扱っています。

### Application::VERSION定数をtinkerと一時ルートで取り出す方法

REPL が使える環境なら`php artisan tinker`を起動して`app()->version()`を評価するのが最短です。tinker が入っていなければ開発用の依存として追加します。

コマンドラインがまったく無いなら、routes/web.php に確認用のルートを一時的に足し、`Illuminate\Foundation\Application::VERSION`の値を返させる手が残ります。定数を直接参照するため、アプリが起動できる状態なら確実に値が取れます。なおルートファイルの構成はLaravel 11で変わり、api.php や channels.php が既定では作られません。この前提の違いは[Laravel 11の変更点とサポート期限の整理](https://www.issoh.co.jp/tech/details/3437/)で扱っています。

### 確認用ルートやデバッグ表示でバージョンを外部露出させない後始末

ここは手順の一部として組み込んでください。確認のために足したルートは、値を取り終えた時点で削除します。残せば版が誰でも取得できるエンドポイントになり、既知の脆弱性を持つ版なら攻撃者に探索の手間を省かせるだけです。

同じ理由で、版を調べるために APP\_DEBUG を true にする対処は避けてください。デバッグ画面のスタックトレースには版とファイルパスが出ます。about の出力も同様で、チャットやチケットへ貼るときは Environment セクションだけに絞る運用が安全です。

## 確認した版から読むサポート期限とLTSが存在しない現行ポリシー

数字が分かっただけでは判断になりません。その版がどの段階にいるのかを、公式のサポート表に当てて読みます。

### Laravel 10から13までのサポート期限一覧と対応PHPバージョン

公式ドキュメントのサポート表を、2026年8月29日時点の記載どおりに整理したものが次の表です。

| バージョン      | 対応PHP     | リリース       | バグ修正期限     | セキュリティ修正期限 |
| ---------- | --------- | ---------- | ---------- | ---------- |
| Laravel 10 | 8.1 – 8.3 | 2023年2月14日 | 2024年8月6日  | 2025年2月4日  |
| Laravel 11 | 8.2 – 8.4 | 2024年3月12日 | 2025年9月3日  | 2026年3月12日 |
| Laravel 12 | 8.2 – 8.5 | 2025年2月24日 | 2026年8月13日 | 2027年2月24日 |
| Laravel 13 | 8.3 – 8.5 | 2026年3月17日 | 2027年第3四半期 | 2028年3月17日 |

見落とされやすいのは対応PHPの下限です。13系だけが8.3以上を要求しており、8.2で動いている環境はLaravelだけを13へ上げられません。上限側の8.5は12と13の両方が受けています。

### LTS表記がLaravel 6で消えた経緯と全リリース一律18か月・2年

「Laravel 11 LTS」「LTS版はどれか」という調べ方が続いていますが、現行のサポートポリシーに長期サポート版という区分はありません。公式ドキュメントの記述は、全リリース一律でバグ修正18か月・セキュリティ修正2年という定めです。版ごとに期間の長短を設ける仕組みがないため、どれかを選べば延命できるという前提が成り立ちません。

サポート表で(LTS)の表記が付いた最後の版は、2019年9月リリースのLaravel 6でした。7以降は表からその表記が消えています。見るべきは、いま使っている版のセキュリティ修正期限が何年何月何日か、という1点だけです。

### 12系のバグ修正が2026年8月13日で終わった直後の位置づけ

確認結果が12系だった読者には、直近の変化が効いてきます。12のバグ修正提供が終わったのは2026年8月13日、この記事の執筆時点はその2週間後です。

残っているのは2027年2月24日までのセキュリティ修正だけで、動作不良に当たっても本体側の修正は来ません。11から12への移行をこれから計画するなら、それは「バグ修正の窓を買う」判断ではなく「セキュリティ修正が続く残り18か月弱を買う」判断になります。12系の要件と11からの変更点は[Laravel 12の対応PHPバージョンと動作要件・アップグレードの変更点](https://www.issoh.co.jp/tech/details/5637/)に一覧があります。版が変わるとコードの書き方も動く例として、[FormRequestの設定が13系で属性指定になった変化](https://www.issoh.co.jp/tech/details/17118/)も確認しておくと移行後の混乱を減らせます。

### Packagistのタグの新しさをサポート継続と読み違えない判定

版を調べたあと、Packagist や GitHub のリリース一覧を見て「まだ更新されているから安全だ」と結論づける読み方には落とし穴があります。12系はバグ修正期限を過ぎた2026年8月25日にも v12.68.0 のタグが打たれ、同日には13系の v13.29.0 も出ました。日付だけなら、両者は同じように保守されて見えます。

タグが増えることと、一般利用者向けの修正が供給されることは別の話です。11系でも期限後にタグが打たれ続けた実例があり、その中身は[EOL後も残る未修正の脆弱性と11.xタグの実態](https://www.issoh.co.jp/tech/details/3437/)で検証しています。判定基準は一つに絞ってください。リポジトリの更新頻度ではなく、公式サポート表に記載された期限です。

## 確認した版ごとの移行先の決め方と、上げない判断が成立する条件

ここからは判断です。出た数字ごとに、次に何をすべきかを条件付きで示します。

### 先にPHPの版を確定させる理由と、8.2のままなら12が上限になる根拠

順序を間違えると手戻りが出ます。Laravelのメジャーを決める前に、PHPをどの版まで上げられるかを確定させてください。13.xの最低要件はPHP 8.3、12.xは8.2から8.5です。PHP 8.2から動かせない事情があるなら、この時点で移行先は12に確定します。検討の余地はありません。

PHPを8.3以上へ上げられるなら13まで進めます。セキュリティ修正が2028年3月17日まで続き、次の移行作業を最も先へ送れるからです。機能の新旧は後回しで構いません。`php artisan about --only=environment`でLaravel版とPHP版を並べて取れば、この判定は1画面で終わります。

### 確認結果が11以下のときに移行の先送りがもう成立しなくなる理由

11のセキュリティ修正は2026年3月12日、10は2025年2月4日で終わっています。ここは条件を付けずに言い切ります。公開されているアプリケーションを11以下で運用し続ける判断は、もう取れません。

修正版が供給されない実例がすでに出ているためです。2026年6月に公開された2件のアドバイザリは、影響範囲に11系が含まれる一方、修正版として案内されたのは12系と13系だけでした。内訳と回避策の検討は[Laravel 11のEOLと12・13への移行判断](https://www.issoh.co.jp/tech/details/3437/)にまとめてあります。予算や人員の都合で移行が今すぐ組めない場合でも、それは「上げない判断」ではなく「暫定措置を置いたうえで期限を切る」対応として扱ってください。

### 13へ一気に上げないほうがよい場面と、12で止める判断の条件

13が最新だから常に13が正解、とはなりません。公式のアップグレードガイドはメジャー単位で、11から13へ直接移す手順が存在しないためです。11から12、12から13と段階を踏みます。

12で止める判断が成立するのは、PHP 8.2から動かせない環境である場合と、2027年2月24日までに次の作業枠を確保できる見込みがある場合の2つです。どちらかを満たすなら、12への移行で区切って構いません。逆に、PHPを8.3へ上げられるのに「13は出たばかりで不安だから」という理由で止めるのは、1年以内に同じ作業をもう一度やる選択。13は破壊的変更を抑えることに重点を置いた版で、多くのアプリはコードをほとんど変えずに移行できると公式も明記しています。13で入った機能は[Laravel 13で正式安定版になったAI SDKの全体像](https://www.issoh.co.jp/tech/details/11482/)で扱っています。

### 確認と更新を運用に組み込む頻度とcomposer outdatedの使い所

版の確認は、困ったときに調べる作業ではなく定期の工程にするほうが安く済みます。メジャーは年1回、おおむね第1四半期。マイナーとパッチは週単位のこともあります。

月次で`composer outdated laravel/framework`を回して直接依存の差分を見る、年1回の第1四半期に移行枠を確保する。この2つで、セキュリティ修正期限に追われる状況は避けられます。確認自体が数年に一度という環境ほど、いざ上げるときに複数メジャーをまたいで工数が跳ね上がる。更新を回す体制が社内に無いなら、[保守運用と内製化支援](https://www.issoh.co.jp/service/system/maintenance/)のように版の追跡と更新作業を継続的に預ける選択肢もあります。技術選定そのものを見直す段階なら、[Laravelの将来性をEOL・単価・AI対応のデータで判断する](https://www.issoh.co.jp/tech/details/5469/)も併せて確認してください。

## よくある質問

検索で多く見られる質問に答えます。数値は2026年8月29日時点の実測です。

### Laravelの最新バージョンはいくつですか？

最新のメジャーは13系で、2026年3月17日にリリースされました。パッチを含めた最新タグは2026年8月25日の v13.29.0、同日には12系の v12.68.0 も出ています。メジャーは年1回、おおむね第1四半期のサイクルです。自分の環境の版を知りたい場合は、この数字ではなくプロジェクト内で php artisan –version を実行した結果を見てください。

### php artisan –versionとcomposer showはどちらを見ればよいですか？

版の数字だけが要るなら artisan で足ります。実行中の本体の版が1行で返るため、手元でも本番でも判断が早く済みます。composer show は、依存パッケージの内訳まで確認したいときに使ってください。両者がズレることはありません。ただし composer.json の記述とは食い違います。そこにあるのは許容範囲の宣言だからです。

### laravel –versionとphp artisan –versionの違いは何ですか？

返す対象が別物です。laravel コマンドはグローバルに入れる作成用ツールで、–version はインストーラ自身の版を返します。2026年8月25日時点の最新は v5.32.0 のため、本体が13系でも 5.32.0 という表示。php artisan –version のほうがプロジェクト内の本体の版で、こちらが探している値です。5系という数字を見てLaravel 5だと判断しないよう気をつけてください。

### LaravelにLTS版はありますか？

現行のサポートポリシーに長期サポート版の区分はありません。全リリース一律でバグ修正18か月・セキュリティ修正2年と定められています。(LTS)の表記が付いた最後の版は2019年9月リリースのLaravel 6で、7以降は表記そのものが消えました。「LTSだから据え置いてよい」という前提は成り立ちません。判断はバージョン名ではなく、セキュリティ修正期限の日付で行ってください。

### 使っているバージョンのサポートが切れているか、どこで確認できますか？

公式ドキュメントのリリースノートにあるサポート表と、php artisan –version の結果を突き合わせます。2026年8月29日時点では、10と11がセキュリティ修正も終了済み、12はバグ修正が同年8月13日で終わりセキュリティ修正が2027年2月24日まで、13は2028年3月17日までです。タグが新しいことを保守継続の根拠にしないでください。期限後もタグは打たれ、中身が一般利用者向けの修正とは限りません。

## 関連記事

- [Laravelの最新バージョンは13｜対応PHPバージョン・サポート期限一覧とアップグレード判断](https://www.issoh.co.jp/tech/details/5637/)：11だった場合の移行先の要件です。
- [Laravel 11の変更点とサポート期限｜EOL後も残る未修正の脆弱性と12・13への移行判断](https://www.issoh.co.jp/tech/details/3437/)：EOL後に何が起きているかの検証です。
- [Laravel 13で正式安定版になったAI SDKの全体像と導入判断の前提知識](https://www.issoh.co.jp/tech/details/11482/)：最新メジャーで加わった機能です。
- [Laravelの将来性を2026年データで判断｜EOL・単価・AI対応](https://www.issoh.co.jp/tech/details/5469/)：継続採用を見直す際の材料です。
- [Laravel Boost 2.0とは？概要とできること｜Laravel開発にAIを統合する新ツールの全貌](https://www.issoh.co.jp/tech/details/10856/)：13への移行を支援するツールです。

---

出典: [Laravelのバージョン確認｜artisanとcomposerの違いとサポート期限](<https://www.issoh.co.jp/tech/details/17116/>)（株式会社一創）