PHP フレームワークのバージョンアップ戦略：作り直さずに PHP 8 に対応する方法

「PHP のバージョンを上げたらシステムが動かなくなった」「使っているフレームワークが PHP 8 に対応していない」。こうした状況でも、すぐ「作り直し」に進む必要があるとは限りません。

フレームワークによっては、ソースコードの大部分を維持したまま PHP の新しいバージョンに対応できるアプローチがあります。これは、現行システムの価値を残しながら保守できる状態へ戻す「レガシーシステム再生」の具体的な選択肢の一つです。

この記事では、古い PHP システムを全面的に作り直す前に検討できる、フレームワーク別の移行戦略と支援ツールを整理します。あわせて、ツールで置き換えやすい部分と、業務を理解した技術者が確認すべき部分を分けて考えます。

なぜ「フレームワークが動かなくなる」のか

PHP はバージョンアップのたびに、古い書き方や関数が廃止されます。

代表的なのは PHP 7.0 での mysql_* 関数の削除です。mysql_connect() や mysql_query() を使っているコードは、PHP 7 以降では動きません。PHP 8 系でも、型の扱いが厳しくなり、以前は動いていたコードがエラーになるケースが増えています。

フレームワーク側が PHP の新バージョンに追いついていれば問題ありませんが、開発が止まった古いフレームワークはそのままでは動かなくなります。

バージョンアップには2種類の作業がある

古い PHP システムのバージョンアップでは、大きく分けて2種類の作業が発生します。

機械的に見つけやすい変更

廃止されたPHP関数や古い記法の置き換え
名前空間・クラス名・メソッド名の変更
Composerパッケージと依存関係の更新
フレームワークの設定ファイルやディレクトリ構成の変更
型宣言やメソッドシグネチャの変更

これらは公式の移行ガイド、静的解析、Rector、専用の移行ツール、AIなどで候補を洗い出しやすい部分です。変更量が多くても、一定の規則に従って処理できることがあります。

業務を理解しないと判断できない変更

税額・割引・手数料などの計算と端数処理
受注・承認・請求などのステータス遷移
締め日、対象期間、例外条件の判定
利用者の権限による表示・更新範囲
帳票や外部連携に必要なデータの意味

こちらは、コードが動くようになっただけでは正しさを確認できません。フレームワークのAPIに合わせて書き換えた結果、取得条件、保存順序、型変換、nullの扱いなどが変わると、画面上は動いていても業務結果が以前と異なることがあります。

バージョンアップの本当の難しさは、機械的な変更の数だけではなく、現在の業務ルールを壊さずに移行できるかにあります。

フレームワーク別の対応方針

CakePHP：メジャーバージョンごとの差が大きい

CakePHP 2 系は公式サポートが終了していますが、コミュニティによって PHP 8 対応パッチが公開されています。

kamilwylegala/cakephp2-php8

CakePHP 2 を PHP 8.x で動かすためのコミュニティ維持フォークです。全面的な移行に着手する前に、現在のアプリケーションを新しいPHP環境で動かすための選択肢にはなります。

ただし、これはCakePHP 2自体が公式サポートへ戻るという意味ではありません。アプリケーション固有のコード、プラグイン、認証、セッション、データベース処理まで無変更で動く保証もないため、延命・移行準備の手段として位置づける必要があります。

CakePHPは、メジャーバージョン間の変更が比較的大きいフレームワークです。

2 → 3 — 名前空間、Composer、ディレクトリ構成に加え、ORMが再設計されています。特にモデル・検索・保存処理は広範な修正が必要になります
3 → 4 — 3.xで非推奨になったAPIの削除、型やメソッドシグネチャの変更、ミドルウェア・認証まわりの整理が必要です
4 → 5 — PHP 8.1以降が前提となり、型の厳格化、日付・クエリAPI、認証関連などに変更があります

2026年6月25日時点では、CakePHP 3は公式サポートが終了しています。CakePHP 4も4.3〜4.5のセキュリティ修正が2026年9月9日までとされているため、これから移行先を決める場合、3や4を最終到達点にするのではなく、CakePHP 5までの経路を考える必要があります。

CakePHP 2から一気に5へ書き換えるより、移行ガイドに沿って段階ごとの差分を確認する方が、問題の切り分けはしやすくなります。ただし、2 → 3の変更が大きいため、システムの規模とテスト状況によっては、新しいCakePHP 5の土台へ機能単位で移植する方が整理しやすい場合もあります。

Zend Framework → Laminas

Zend Framework は開発終了し、Linux Foundation 主導の Laminas Project として引き継がれました。

laminas/laminas-migration

Zend Framework 2 / 3からLaminasへの移行は、CakePHPのメジャーバージョンアップとは性質が異なります。LaminasはZend Frameworkの公式な後継フォークであるため、アプリケーション構造やMVCの考え方を別のものへ作り替える移行ではありません。

公式の移行ツールは、主に次の機械的変更を行います。

Zend\からLaminas\への名前空間・クラス参照の変更
Composerパッケージ名と依存関係の更新
テンプレートや設定キーの変更
依存パッケージをLaminas版へ解決するための設定追加

そのため、同等世代のZend FrameworkからLaminasへ名前と依存関係を移す作業自体は、比較的小さいと考えられます。

ただし、「Laminasへ名前を移すこと」と「古いアプリケーションを現在のPHPで安全に動かすこと」は別の作業です。古いPHP記法、独自モジュール、外部ライブラリ、Composer依存関係まで更新する場合は、影響範囲が大きくなることがあります。移行ツール実行後も、差分確認とテストは必要です。

また、Laminas MVCは現在、機能追加を行わないセキュリティ修正のみの保守モードです。公式にはPHP 8.4のセキュリティサポートが終了する2028年12月31日までの継続が示されています。Laminasへの移行は、既存システムを安定させる現実的な手段ですが、より長期的な構成を検討する場合は、その先の方針も合わせて考える必要があります。

Laravel

Laravel はバージョンアップの速度が速く、古いバージョン（5.x 系など）を「そのままで PHP 8 に追いつかせる」互換フォークは存在しません。ただし、アップグレードを支援するツールが充実しています。

Laravel Shift（有償）

Laravelのバージョンアップを支援するサービスです。対象バージョン間の変更に合わせた差分を生成し、機械的な修正作業を減らせます。Laravel公式のアップグレードガイドからも、自動化の選択肢として案内されています。

Rector / rector-laravel（オープンソース）

RectorはPHPコードを構文木として解析し、ルールに従って書き換える自動リファクタリングツールです。rector-laravelはLaravel向けのコミュニティ製ルールセットで、Laravel公式ツールではありません。

Laravel向けのルールでは、次のような変更を支援できます。

古いヘルパー関数や廃止APIの置き換え
旧形式のモデルファクトリからクラス形式への変更
Controller Actionやルーティング記法の変更
テストAPIや一部のEloquent記法の更新
PHP自体のバージョンアップに伴う構文変更

一方、Rectorだけでは完了しない作業もあります。

サードパーティーパッケージの互換性確認・代替選定
認証方式、フロントエンド構成、設定値の意味的な変更
アプリケーション固有のサービスクラスや独自拡張の修正
実行時にしか現れない挙動差の確認
ビジネスロジックの結果が以前と同じかという判断

Rectorは「Laravelを最新版へ自動移行するツール」ではなく、公式アップグレードガイドに沿って進める際の機械的な書き換えを減らすツールと考えるのが適切です。古いLaravelから複数のメジャーバージョンを上げる場合は、一段ずつ依存関係を更新し、各段階でテストする方が原因を切り分けやすくなります。

Symfony

Symfonyは、移行経路が比較的明確なフレームワークです。次のメジャーバージョンへ進む前に、現在のメジャーバージョンの最終マイナーへ上げ、非推奨警告を解消するという手順が公式に整理されています。

Symfony PHPUnit Bridgeでテスト実行時の非推奨箇所を検出でき、Rectorで一部を自動修正することもできます。非推奨を段階的に解消してからメジャーバージョンを上げる設計は、変更箇所と理由を追いやすく、移行する側に安心感があります。

Symfonyについては、LTS、非推奨警告、Flex、Rectorを組み合わせた進め方を別の記事で詳しく扱う予定です。

Drupal：7以前と8以降で移行の考え方が異なる

DrupalはCMSですが、Drupal 8以降はSymfonyコンポーネントを基盤としており、PHPフレームワークのバージョンアップと共通する考え方があります。

Drupal 7からDrupal 11へ

Drupal 7からDrupal 11への移行は、既存のコードベースをそのまま更新する作業ではありません。Drupal 11の新しい環境を構築し、DrupalのMigrate APIを使ってコンテンツやユーザーなどのデータを移す、再構築に近い作業です。

移行しやすいのは、主に次のようなコンテンツデータです。

記事・固定ページなどのコンテンツ
ユーザー
タクソノミー
ファイルや画像
フィールドに保存されたデータ

一方、次の要素は新しいDrupal 11側での再設計・再作成が必要になりやすい部分です。

Viewsなどの画面・一覧設定
テーマ
Drupal 7向けの独自モジュール
Drupal 7で直接改変された本体・拡張モジュール
現在使っているがDrupal 11版が存在しない拡張モジュール

したがって、Drupal 7のサイトは、Drupal 11で新しくサイトを構築し、データと必要な業務ロジックを移植する方針が現実的です。「全部をゼロから作り直す」というより、コンテンツデータは移行し、構成・表示・独自機能は現在の要件に合わせて作り直す、と整理するのが正確です。

Drupal 8からDrupal 11へ

Drupal 8以降は、Drupal 7以前とは異なり、メジャーバージョン間の継続的なアップグレード経路が用意されています。ただし、Drupal 8から11へ直接上げることはできません。Drupal公式も、各メジャーバージョンを飛ばさず順番にアップグレードする方針を示しています。

公式の方針では、次のように各メジャーバージョンを順番に通します。

Drupal 8 → Drupal 9 → Drupal 10 → Drupal 11

Drupal 10から11へ進む場合も、まずDrupal 10.3以降へ更新し、拡張モジュールと独自コードの互換性を確認してからDrupal 11へ上げます。

独自モジュールがDrupal APIに沿って作られており、各バージョンで非推奨になったAPIを順次置き換えていれば、ビジネスロジックの大部分を維持したまま移行できます。修正の中心は次のような箇所です。

非推奨になったDrupal APIやSymfony APIの置き換え
Composer依存関係の更新
Drupal 11に未対応の拡張モジュールへの対応
廃止されたコアモジュールの置き換え
テーマとTwigテンプレートの互換性対応

互換性の確認にはUpgrade Status、機械的なコード修正にはDrupal Rectorを利用できます。

Drupal 8以降で移行経路が安定している背景には、Symfonyの後方互換性と非推奨管理の考え方があります。ただし、Symfonyだけの恩恵ではありません。メジャーバージョンを一つずつ通すDrupal自身の方針、非推奨APIを事前に通知する仕組み、Composerによる依存管理、構成をYAMLで管理できるConfiguration Managementも、継続的なアップグレードを支えています。

そのため、「Drupal 8から10のサイトなら最小限の修正でDrupal 11へ移行できる」という認識は、独自コードと利用中の拡張モジュールが非推奨APIへ適切に追従している場合には妥当です。長期間アップデートされていない独自モジュールや、代替のない拡張モジュールが多い場合は、相応の修正が必要になります。

EC-CUBE：2・3系と4系では移行方針が異なる

EC-CUBEも完成されたECサイト構築システムですが、EC-CUBE 3・4はPHPフレームワークを基盤としているため、フレームワークの世代差が移行方針へ大きく影響します。

2026年6月25日時点の最新系列はEC-CUBE 4.3で、最新リリースは4.3.1-p1です。

EC-CUBE 2・3系から4.3へ

EC-CUBE 2系、3系、4系では、内部構造、データモデル、プラグイン、テンプレート、カスタマイズ方法が大きく異なります。そのため、2系・3系のコードをそのまま4.3へ段階的に更新する考え方は現実的ではありません。

基本方針は、EC-CUBE 4.3を新しく構築し、次の要素を選別して移すことになります。

商品・会員・受注などのデータ
現在も必要なデザインと画面構成
決済・配送・在庫などの外部連携
独自に追加された購入条件・価格計算・受注処理
既存カスタマイズのうち、現在も業務上必要なもの

特に、購入フロー、税・送料・手数料、ポイント、会員ランク、在庫引当などのロジックは、そのままコピーするのではなく、現在のEC-CUBE 4.3のPurchaseFlow、Entity、Repository、イベントなどへ合わせて移植する必要があります。

したがって、「使えるロジックは活かすが、システムとしてはEC-CUBE 4.3で作り直す」という認識が妥当です。既存コードをそのまま移すのではなく、業務ルールを読み解き、新しい構造へ実装し直す作業になります。

EC-CUBE 4系から4.3へ

EC-CUBE 4系には、4.0から4.1、4.1から4.2、4.2から4.3への公式な本体バージョンアップ手順とマイグレーションガイドがあります。順番に適用することで、2系・3系からの移行よりは明確な経路で4.3へ上げられます。

EC-CUBE 4.3ではSymfony 6への対応も行われています。EC-CUBE 4系がSymfonyを基盤としていることは、依存関係、サービス、Controller、Entityなどの構造を継続しながら更新できる点で有利です。

ただし、次の条件がある場合は「容易」とは限りません。

EC-CUBE本体を直接変更している
独自プラグインが多い
利用中のプラグインが4.3へ対応していない
PurchaseFlowやEntityを大きく拡張している
テーマやJavaScriptが本体の内部実装へ強く依存している

本体のカスタマイズをプラグインや推奨された拡張方法へ分離できているサイトほど、4系内のアップデートは進めやすくなります。逆に、本体へ直接修正を重ねたサイトでは、公式差分と独自差分を切り分ける調査が先に必要です。

CodeIgniter

CodeIgniter 3 → 4 は互換性のない大幅な書き直しで、自動移行ツールもほぼありません。しかし、それより古い 1.x 系も含め、AI によるコード修正という選択肢が実用的になってきています。

当事務所では、CodeIgniter 1.7 で動いていたシステムを PHP 8 向けに移植した際、コードの修正を AI に依頼しました。移植の過程で SQL インジェクションの脆弱性も見つかり、合わせて AI に修正してもらっています。完全にすべての脆弱性が解消されているとは断言できませんが、定期的に AI によるセキュリティチェックを継続する運用で対応しています。

AI に任せられるのは主に次のような作業です。

PHP 8 で廃止された関数・記法の書き換え
型エラーや警告の修正
古い SQL 操作（mysql_* 関数など）の書き換え
XSS・SQLインジェクションなど既知の脆弱性パターンの修正

ただし、AI が修正したコードが意図どおり動くかどうかは、人間が動作確認する必要があります。また、業務ロジックに関わる部分は AI の修正内容を注意深くレビューすることが重要です。

フレームワーク問わず使えるツール

PHPCompatibility

PHPCompatibility は PHP_CodeSniffer のルールセットで、指定した PHP バージョンで動かないコードを一覧で出力します。以前はバージョンアップ前の事前チェックとして活用していました。

AIによるコード解析・改修支援が実用的になってきた現在、非互換箇所の調査をAIで補助する場面も増えています。ただし、PHPCompatibilityはルールに基づいて再現可能な結果を出せるため、AIの代替というより、両方の結果を照合して抜けを減らす使い方が適しています。

Rector

前述のRectorはフレームワーク固有のルールだけでなく、PHPバージョンアップ対応の汎用ルールも持っています。対象バージョンに合わせたルールを指定することで、古い構文やAPIの一部を新しい書き方へ変換できます。

ただし、自動変換はすべてを解決しません。変更後に実際に動作するかの確認と、テストが不可欠です。

どのアプローチを選ぶか

状況	推奨アプローチ
CakePHP 2で動いている	コミュニティフォークでPHP更新の可否を調べつつ、CakePHP 5までの段階移行または機能単位の移植を比較
Zend Framework 2 / 3を使っている	`laminas/laminas-migration`でLaminasへ移し、PHP・依存パッケージ更新は別工程として確認
古いLaravelを使っている	公式アップグレードガイドに沿って一段ずつ更新し、ShiftやRectorで機械的変更を補助
Symfonyを使っている	各メジャーの最終マイナーで非推奨を解消してから、次のメジャーへ段階移行
Drupal 7を使っている	Drupal 11を新しく構築し、コンテンツデータを移行。テーマ・構成・独自機能は再設計・移植
Drupal 8〜10を使っている	メジャーバージョンを一つずつ通り、Upgrade StatusとDrupal Rectorで独自コードを更新
EC-CUBE 2・3系を使っている	EC-CUBE 4.3を新しく構築し、データと必要な業務ロジックを選別して移植
EC-CUBE 4系を使っている	公式の移行経路に沿って4.3へ段階更新。プラグインと本体カスタマイズの互換性を確認
CodeIgniter（1.x / 3.x）を使っている	AI によるコード修正・セキュリティ修正で PHP 8 移植。動作確認は人間が行う

共通して言えることは、バージョンアップ前に非互換箇所、依存パッケージ、テストの有無、業務上重要な処理を把握することです。何がどれだけ影響を受けるかを確認した上で、作業量とリスクを見積もります。

ツールや AI で自動修正できる範囲があっても、それだけで移行が完了するわけではありません。変更後の動作確認と、業務ロジックに影響がないことの確認は人間が行う必要があります。

当事務所が重視するのは、業務ロジックを理解することです

フレームワークの移行作業は、公式ガイドやツールによって効率化できる部分が増えています。一方、現行システムに蓄積された業務ルールは、フレームワークの外からは判断できません。

当事務所が特に支援したいのは、移行ツールを実行するだけでは終わらない、ビジネスロジック（ドメインロジック）の把握・修正・検証です。古いコードとデータベースを読み解き、次のような点を確認します。

どの処理が業務上重要なのか
条件分岐や計算式に、どのような意味があるのか
新旧の処理結果が一致しているか
現在の不具合まで「仕様」として移植しようとしていないか
将来の保守で触りやすい形に分離できるか

可能であれば、バージョンアップ前に主要な入力と出力、計算結果、データ更新をテストとして記録します。既存のテストがない場合でも、業務上重要な処理から現在の動作を確認できるテストを作ることで、フレームワーク変更後の結果と比較できます。

フレームワークを新しくすること自体が目的ではありません。システムが持っている業務上の価値を理解し、残すべき仕様と直すべき問題を分け、安全に変更できる状態へ戻すことが目的です。

「PHPのバージョンを上げたいが、業務への影響を判断できない」「フレームワークは更新できそうだが、独自の処理を誰も説明できない」という段階からご相談いただけます。現行コード・データ構造・実際の動作を確認し、移行できる部分、修正すべき部分、先に調査すべき部分を整理します。レガシーシステム保守・改善支援からご相談ください。

関連記事
古い PHP システムのバグ調査で最初に確認すること