目次
「Laravelのバージョン、いくつで動いてる？」。この質問に即答できない現場は多い。Laravel 5.x系で構築されたシステムがそのまま稼働し続けているケースは珍しくない。しかし、Laravel 5.8のバグ修正サポートは2019年9月に、セキュリティ修正も2020年3月に終了している（出典：Laravel Versions）。
放置するほど、改修コストは膨らみ続ける。本記事では、Laravel 5.x以前のレガシーコードを段階的にリファクタリングする具体的な手順を、情シス担当者・開発責任者向けに解説する。
Laravelレガシーコードのリファクタリングが必要な理由
まず、なぜ「動いているシステム」に手を入れるべきなのかを整理する。
全バージョンのサポートが終了している
2026年3月時点で、Laravel 5.x系は全バージョンがEOL（End of Life）に達している。最新の安定版はLaravel 12で、PHP 8.2以上が必須要件だ（出典：Laravel 12.x Release Notes）。
| バージョン | リリース日 | セキュリティ修正終了 | 状態 |
|---|---|---|---|
| Laravel 5.0 | 2015年2月 | 2016年8月 | EOL |
| Laravel 5.5 LTS | 2017年8月 | 2020年8月 | EOL |
| Laravel 5.8 | 2019年2月 | 2020年3月 | EOL |
| Laravel 10 | 2023年2月 | 2025年8月 | セキュリティのみ |
| Laravel 11 | 2024年3月 | 2026年9月 | サポート中 |
| Laravel 12 | 2025年2月 | 2027年2月 | 現行安定版 |
5.x系から現行版までの距離は7世代以上ある。この間にフレームワークのアーキテクチャは大きく変化した。
PHP本体のEOLとの二重リスク
Laravel 5.x系はPHP 7.x以前で動いているケースが大半だ。PHP 7.4の公式セキュリティサポートは2022年11月に終了している（出典：PHP公式 Supported Versions）。フレームワークとPHP本体の両方がEOLという二重のリスクを抱えた状態になる。
PHPのレガシーバージョンに潜むセキュリティリスクの詳細は、レガシーPHP診断｜古いPHPシステムの移行判断チェックリストで解説している。
人材確保が年々困難になる
Laravel 5.x系の開発経験を持つエンジニアは転職市場から減り続けている。求人に「Laravel 5対応」と書いても応募は集まりにくい。モダンなLaravel 10以降の経験者が主流であり、旧バージョンの設計思想やディレクトリ構成を理解できる人材は限られる。
Laravelレガシーのリファクタリング前に判断すべきこと
リファクタリングに着手する前に、「段階的にアップグレードするのか」「作り直すのか」を判断する必要がある。
アップグレードが適切なケース
以下の条件に該当する場合は、既存コードをベースにした段階的アップグレードが有効だ。
- テストコードがある程度整備されている
- Laravelの標準的なディレクトリ構成に準拠している
- Eloquent ORMやBladeテンプレートを標準的に使っている
- コード量が10万行以下で、依存パッケージが管理されている
作り直しが適切なケース
一方、以下に該当する場合は、新規に構築し直すほうが結果的に安くなる。
- フレームワークの規約を大きく逸脱したカスタマイズがある
app/配下に数千行のGodクラスが存在する- テストコードが皆無で、仕様書もない
- Laravel以外のPHPフレームワークからの移植コードが混在している
判断に迷う場合は、まず現行コードの構造を可視化することを推奨する。コードの依存関係や複雑度を客観的に把握できれば、判断の精度は格段に上がる。
Laravelレガシーコードのリファクタリング｜4段階の手順
段階的にアップグレードする場合の具体的な手順を解説する。一度にすべてを変えるのではなく、各段階で動作確認を挟みながら進めるのが鉄則だ。
段階1: 現行コードの構造把握とテスト整備
リファクタリングの最初のステップは、コードを変えることではない。現状を正確に把握することだ。
依存関係の洗い出し。composer.jsonを確認し、使用パッケージとそのバージョン制約を一覧化する。Laravel 5.x時代のパッケージは、すでにメンテナンスが終了しているものが多い。代替パッケージの有無も合わせて調査しておく。
テストの追加。テストコードが不十分な場合、まず主要な業務フローに対するFeatureテストを整備する。LaravelのHTTPテスト機能を使い、エンドポイント単位で期待するレスポンスを検証するテストを書く。完璧なカバレッジは不要だ。主要な業務ロジックの入出力を押さえるテストがあれば、以降の変更時に回帰バグを検知できる。
静的解析の導入。PHPStan（Larastan）を導入し、コード品質のベースラインを設定する。PHPStanはコードを実行せずに型エラーや未定義変数を検出するツールだ（出典：Medium「Supercharge Your Laravel Codebase with PHPStan」）。最初はレベル0から始め、段階的にレベルを上げていくのが実務的な進め方である。
段階2: PHPバージョンのアップグレード
Laravelのバージョンを上げる前に、PHPのバージョンを先行して引き上げる。Laravel 5.8はPHP 7.3まで対応しているが、まずPHP 7.3環境で安定動作を確認し、その後にLaravelのアップグレードに進む。
この段階で注意すべき点は3つある。
非推奨関数の置き換え。each()、create_function()など、PHP 7.2以降で非推奨となった関数が残っていないか確認する。Rectorを使えば、これらの置き換えを自動化できる。
型の厳密化による挙動変更。PHP 7.x系からPHP 8.x系への移行では、型チェックが厳密になる箇所がある。==と===の挙動差異や、nullの扱いが変わるケースに注意が必要だ。
拡張モジュールの互換性確認。mcrypt（PHP 7.2で削除）やmysql拡張（PHP 7.0で削除）を使っている場合、代替への書き換えが必須になる。
段階3: Laravelバージョンの段階的アップグレード
ここが改善作業の本丸だ。Laravel 5.xから現行版への移行は、1バージョンずつ順に上げていくのが安全な方法である。
Laravel Shiftの活用。Laravel Shiftは、Laravelアプリケーションのバージョンアップを自動化するサービスだ。4.2から最新版まで、各バージョン間の移行をPRとして自動生成してくれる（出典：Laravel Shift）。手作業では見落としがちな設定ファイルの変更やnamespaceの調整も検出する。
Rectorによる自動リファクタリング。Rectorは、PHPコードのAST（抽象構文木）を解析し、変換ルールに基づいて自動的にコードを書き換えるツールだ。Laravel専用のルールセット（rector/rector-laravel）が100以上提供されている（出典：Jump24「RectorPHP and Laravel」）。
各バージョン間の主要な破壊的変更を以下に整理する。
| 移行区間 | 主な破壊的変更 |
|---|---|
| 5.x → 6.x | PHP 7.2必須化、文字列・配列ヘルパの非推奨化 |
| 6.x → 7.x | Blade componentの刷新、ルート定義方法の変更 |
| 7.x → 8.x | モデルファクトリのクラスベース化、Jetstream導入 |
| 8.x → 9.x | PHP 8.0必須化、Flysystem 3.x移行 |
| 9.x → 10.x | PHP 8.1必須化、Process facade追加 |
| 10.x → 11.x | ディレクトリ構造のスリム化、設定ファイル統合 |
| 11.x → 12.x | PHP 8.2必須化、スターターキット刷新 |
1バージョン上げるたびにテストを実行し、全テストがグリーンになることを確認してから次に進む。この原則を守ることで、問題が発生した際の原因切り分けが容易になる。
Laravelレガシーの構造、把握できているだろうか。
SysDockなら、AIマルチエージェントがソースコードの構造・依存関係・リスク箇所を1週間で可視化する。ソースコード非送信のローカル解析で、セキュリティの懸念なく診断を実施できる。
着手金0円・完全後払い。まずはお見積り → sysdock.genbacompass.com
段階4: コード品質の継続的改善
バージョンアップが完了したら、コード品質そのものの改善に着手する。
Fat Controllerの分割。Laravel 5.x時代のプロジェクトでは、コントローラに業務ロジックが集中していることが多い。FormRequest、Service層、Actionクラスへの責務分割を進める。1コントローラ1メソッドの「Single Action Controller」も選択肢に入る。
N+1問題の解消。Eloquentの遅延読み込みに起因するN+1クエリは、パフォーマンス劣化の代表的な原因だ。Laravel 11ではpreventLazyLoadingメソッドが利用でき、開発環境でN+1を即座に検知できる。
設定ファイルとルーティングの整理。Laravel 11以降ではディレクトリ構造がスリム化された。不要な設定ファイルの削除、ルーティングの整理を行い、コードベースの見通しを改善する。
Laravelレガシーのリファクタリングで失敗しないための原則
段階的に進めるとはいえ、押さえるべき原則がある。
テストを書いてから変える
リファクタリングの定義は「外部から見た振る舞いを変えずにコードの内部構造を改善すること」だ。振る舞いが変わっていないことを保証するのがテストである。テストなしのリファクタリングは、ただの書き直しだ。既存の動作を壊すリスクが高い。
Laravelでは、Featureテスト（HTTPリクエスト単位の結合テスト）から着手するのが効率的だ。コントローラの中身がどう実装されていても、リクエストとレスポンスの対応関係を検証できる。
一括移行ではなく段階リリースを徹底する
前述の4段階は、それぞれ独立してリリース可能な単位で設計している。PHPのアップグレードだけで一度本番にデプロイし、問題がないことを確認してから次に進む。万一の切り戻しも、直前の段階まで戻せば済む。
ストラングラーフィグパターンの検討
大規模なLaravelアプリケーションの場合、全体を一度にアップグレードするのが難しいこともある。ストラングラーフィグパターンを適用すれば、旧システムを稼働させたまま、新しいLaravel環境で機能を一つずつ置き換えていくことが可能だ（出典：Medium「Migrating PHP Frameworks using Strangler Fig」）。
リバースプロキシでリクエストを振り分け、新機能は新環境、既存機能は旧環境で処理する。段階的に振り分け比率を変え、最終的にすべてのリクエストを新環境に向ける。
まとめ
Laravel 5.x系のレガシーコード改善は、一括リプレイスではなく段階的なアプローチが現実的だ。本記事のポイントを整理する。
- Laravel 5.x系は全バージョンがEOLを迎えている。 PHP本体のEOLと合わせた二重リスクの状態にある。放置するほど改修コストは増加する。
- リファクタリングは4段階で進める。 構造把握とテスト整備 → PHPアップグレード → Laravel段階的アップグレード → コード品質改善。各段階で動作確認を挟むことがリスク最小化の鍵になる。
- Laravel ShiftやRectorなどの自動化ツールを活用する。 機械的な変換を自動化し、人間は業務ロジックの検証に集中する。ただし、自動変換だけでは完結しない。事前の構造把握が不可欠だ。
改善を始める前に、まず自社のLaravelシステムが「今どうなっているか」を正確に把握すること。構造が見えれば、優先順位が決まり、計画が立つ。
Laravelシステムの構造、正確に把握できているか。
SysDockは、AIマルチエージェントがソースコードからモジュール構成・依存関係・外部連携を自動解析し、Word・PPT・React Flowフロー図の3点セットで1週間納品する。PHPを含む13言語/FWに対応。ソースコード非送信・完全後払いで、安心して依頼できる。
着手金0円・完全後払い。まずはお見積り → sysdock.genbacompass.com
よくある質問（FAQ）
Q. Laravel 5.xから一気にLaravel 12へ移行できるか？
A. 技術的には可能だが推奨しない。5.x → 6.x → 7.x → ... と1バージョンずつ上げるのが安全だ。各バージョン間の非推奨警告を順番に解消し、テストで動作確認を挟むことで問題の切り分けが容易になる。Laravel Shiftを使えば、各バージョン間の移行PRを自動生成できる。
Q. テストがまったくない状態から始められるか？
A. 始められる。まず主要な業務フローに対するFeatureテストを10〜20件程度書くところからスタートする。完璧なカバレッジは不要だ。重要なのは「壊れたら気づける」状態を最低限つくること。その上で段階的にテストを拡充していく。
Q. リファクタリングにかかる期間の目安は？
A. システム規模と既存コードの状態に依存する。中規模のLaravelアプリケーション（コントローラ50〜100個程度）で3〜6ヶ月が一般的な目安だ。テストの整備状況が期間を大きく左右する。テストがある程度揃っていれば、バージョンアップ自体は比較的短期間で進む。
Q. SysDockでLaravelのレガシーコード解析はできるか？
A. SysDockは13言語/フレームワークに対応しており、PHP（Laravel含む）も対象だ。ソースコードを外部に送信せず、ローカル環境で解析を行うため、セキュリティポリシーが厳しい環境でも利用できる。構造・依存関係・リスク箇所を1週間でレポート化する。料金はライト30万円から。
現場改善に役立つ関連ツール
GenbaCompassでは、SysDock以外にも現場のDXを支援するツールを提供している。