LASSIC Media らしくメディア
古いPHPフレームワークからの移行を外注で進める
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- CakePHP 2系は2021年6月15日に公式サポートが終了し、Zend Frameworkも2019年にLinux Foundation傘下のLaminas Projectへ移行しました。
- レガシーFWを使い続けると、PHP本体側のサポート期間(2年の積極サポート後さらに2年のセキュリティ修正のみ)との組み合わせで身動きが取りづらくなります。
- 移行アプローチは全面リライト・段階移行・ストラングラーパターンの3系統があり、外注先には資産調査から並行稼働までを一括で担える体制が求められます。
目次
レガシーPHPフレームワークとは何か——CakePHP1/2・Zend Framework・独自FWが直面する共通課題
レガシーPHPフレームワークとは、CakePHP 1系・2系、旧バージョンのZend Framework、古いメジャーバージョンのSymfony、あるいはフレームワークを使わずに独自実装された業務Webシステムの基盤を指す言葉として使われます。これらは開発コミュニティによる継続的な更新が止まった、または止まりつつあるPHP基盤という共通点を持ちます。
レガシーFWで運用を続ける現場では、いくつかの課題が重なって現れます。新しいPHP実行系で警告や致命的エラーが発生する、Composerの依存関係がバージョン不整合で解決できない、FW側から脆弱性への対応が提供されない、ドキュメントとコミュニティが縮小し社内に相談先が残らないといった状態です。個々には対処できても、積み重なると保守そのものが難しくなっていきます。
次章では、代表的なPHPフレームワークがどのタイミングでサポートを終えたか、公式情報をもとに整理します。
CakePHPからLaravelまで——主要PHPフレームワークのサポート終了(EOL)状況
CakePHP 2系は、CakePHP財団の公式ブログにおいて2021年6月15日にEnd of Lifeを迎えたと発表されています*2。これはCakePHP 4.0のリリースから18か月後、かつセキュリティ関連のみの対応期間6か月を経たタイミングです*2。1系についてはこの2系のような明確な終了表明自体が公式wiki上に見当たらず、実務上は2系よりも前からサポート対象外という位置付けで扱われています。
Zend Frameworkは、2019年4月17日の公式ブログで、フレームワーク本体とすべてのサブプロジェクトをLinux Foundation傘下の新プロジェクトへ移行すると発表しました*3。この新プロジェクトがLaminas Projectです*3。以降の新機能追加やセキュリティ修正は、旧来のZend Frameworkパッケージ名ではなくLaminasブランドのパッケージ側で提供される形に切り替わっています*3。
Symfonyは6か月ごとにマイナーバージョンを、2年ごとにメジャーバージョンをリリースする方式を採っています*4。通常のリリースは8か月間(バグ修正6か月+セキュリティ修正のみ2か月)しか維持されず、各メジャー系列の最終マイナー版だけがLTS(長期サポート)として3年間のバグ修正と4年間のセキュリティ修正を受けられます*4。裏を返せば、LTS版であっても発行から数年が経過した古いSymfonyは、この期間をすでに過ぎている可能性が高いということです。
移行先として選ばれることが多いLaravelは、年1回程度のペースでメジャーバージョンをリリースし、各バージョンでバグ修正18か月・セキュリティ修正2年という支援期間を明示しています*5。PHP本体についても、各リリース系列は2年間の積極的なサポート(バグ修正含む)の後、さらに2年間のセキュリティ修正のみの期間があり、合計4年でサポートを終了する方式が採られています*1。レガシーFWが動作要件として古いPHPバージョンを求めている場合、この4年という期限との組み合わせで選択の余地が狭まっていく点は見過ごせません。
| フレームワーク | 現状 | 移行先の傾向 |
|---|---|---|
| CakePHP 1系 | 公式な終了表明は確認できないが、2系より前からサポート対象外の扱い | CakePHP最新版またはLaravel等 |
| CakePHP 2系 | 2021年6月15日にEOL*2 | CakePHP最新版またはLaravel等 |
| Zend Framework | 2019年にLaminas Projectへ移行*3 | Laminas継続、またはLaravel等へ刷新 |
| 古いSymfony(LTS以外・期限切れLTS) | 標準版は8か月のみ、LTSでも最長4年で終了*4 | 最新Symfonyまたは他のモダンFW |
| 独自実装(フレームワークなし) | FW側のEOLは無いが仕様書・担当者の不在が課題化しやすい | Laravel等のモダンFWで再構築 |
移行を先送りするリスク——脆弱性対応・PHP本体との互換性・保守要員の不足
移行を先送りする際に想定しておきたいリスクは、大きく3つに分けられます。
第一に脆弱性対応です。サポートが終了したフレームワークでは、新たに脆弱性が報告されてもFW側から修正パッチが提供されない可能性があります。CakePHP 2系はセキュリティ関連の対応さえ2021年6月15日で終了しており*2、Zend Frameworkも旧パッケージ名での更新提供は2019年の発表以降止まっています*3。自社側でパッチを当てるか、脆弱性を承知のうえで運用を続けるかという選択を迫られます。
第二にPHP本体との互換性です。古いFWのコードは、最新のPHP実行系が求める言語仕様の変更に対応していないことがあります。動作を保つために古いPHPバージョンを使い続けると、PHP本体側の4年間というサポート期限*1ともいずれぶつかります。FWとPHP本体の両方が支援期間の外側にある状態は、脆弱性対応の選択肢がさらに限られる状況につながる点に注意が必要です。
第三に保守要員の不足です。CakePHP 1/2系やZend Frameworkを採用する新規プロジェクトは既にほとんど見られなくなっており、これらの経験を持つ人材を新たに育成しにくい状況が続いています。既存の担当者が異動・退職すると、仕様を把握する人がいなくなるおそれもあります。特に仕様書が更新されていない場合は、コードを読み解く作業自体が保守業務の大部分を占める事態になりやすいと言えるでしょう。
全面リライト・段階移行・ストラングラーパターン——3つの移行アプローチ
全面リライト——仕様を洗い出して新FWで再構築する方式
既存システムの仕様を洗い出し、新しいフレームワーク上でゼロから再実装する方式です。技術的負債を一度に解消できる一方、対象範囲が広いほど期間とコストが大きくなり、開発期間中も既存システムへの機能追加要望に追随する必要が生じます。業務範囲が比較的小さく、仕様が整理されているシステムに向いています。
段階移行——機能や画面の単位で新環境へ移す方式
画面や機能の単位で新フレームワークへ順次移し替え、旧環境と新環境を一定期間並行稼働させる方式です。リスクを分散できる利点がありますが、旧環境と新環境の両方を同時に運用・保守する複雑さが増えます。認証情報やセッションの共有方法など、境界部分の設計に手間がかかる場合があります。
ストラングラーパターン——新旧を振り分けながら旧側を縮小させる方式
ストラングラーフィグ(絞め殺しの木)パターンは、リバースプロキシやルーティングの仕組みで新旧システムへのリクエストを振り分け、対応済みの処理を徐々に新環境へ移しながら旧環境を縮小させていく手法です。Martin Fowler氏が2001年にオーストラリア・クイーンズランドで見た着生植物の様子から着想し、その後ブログで紹介したことで広まったとされています*6。停止時間を確保しにくい、稼働継続が前提の業務システムに向いた考え方です。
どの方式を選ぶかは、システムの停止可否、画面・機能同士の結合度、対象範囲の広さによって変わります。契約前にこの判断軸を委託先とすり合わせておくことが、移行後のトラブルを避けるうえで役立ちます。
ORM・ルーティング・テンプレートエンジンの置き換えとテスト戦略
移行作業の実務は、フレームワークが提供する3つの領域を置き換える作業に集約されることが多いです。ひとつはORM(モデル層)で、CakePHPのモデルクラスやZend Frameworkのテーブルゲートウェイを、移行先のORM(Laravelの場合はEloquent)の記法へ書き換えます。もうひとつはルーティングで、URLと処理の対応関係を新FWのルート定義ファイルへ移し替えます。最後はテンプレートエンジンで、CakePHPのctpファイルやZend Frameworkのphtmlファイルを、移行先のテンプレート記法(Laravelの場合はBlade)への変換が必要です。
これら3領域はいずれも既存の業務ロジックと密接に絡んでいるため、機械的な変換だけでは仕様の取りこぼしが生じやすい部分です。特にモデル層のリレーション定義やバリデーションルールは、旧FW独自の記法に依存している場合が多く、動作確認を伴う手作業が避けられません。
テスト戦略としては、移行前の挙動を記録する特性テスト(既存コードの入出力をそのままテストとして固定する手法)やE2Eテストを先に用意し、移行後の挙動と比較する進め方が広く採られています。単体テストが整備されていない現場では、まずE2Eテストで外形的な仕様を固定し、そのうえで機能単位のリライトへ進むという順序が現実的です。仕様書が失われている箇所は、既存コードの挙動そのものを仕様として扱う判断が必要になる場面もあります。
外注で進める移行の流れ——資産調査・依存整理・並行稼働
外注でレガシーPHPフレームワークの移行を進める場合、着手前の資産調査が土台になります。現行コードベースの構成、データベーススキーマ、外部システムとの連携方式、独自に実装された処理の範囲を洗い出す工程です。この工程が浅いと、移行途中で想定外の依存関係が見つかり、スケジュールに影響が出やすくなります。
続く依存整理では、Composerパッケージのバージョン、利用しているPHP拡張モジュール、サーバー環境側の設定依存を棚卸しします。移行先フレームワークが要求するPHPバージョンと、現行環境との差分もここで明確にします。その後、前章で整理した全面リライト・段階移行・ストラングラーパターンのいずれかを選定し、並行稼働の期間や切替の判断基準を設計する工程です。
委託先を選ぶ際は、資産調査から依存整理、移行方式の設計、テスト、並行稼働、切替後の運用保守までを一括で依頼できるかどうかが分かれ目になります。工程ごとに委託先が変わると、引き継ぎの過程で仕様理解の齟齬が生まれやすくなります。元請（プライムベンダー）として一連の工程を通しで担える体制かどうかは、契約前に確認しておきたい点です。
まとめ：レガシーPHPフレームワーク移行で押さえる3つの判断軸
本稿ではレガシーPHPフレームワークの移行について、公式情報をもとに整理しました。要点は3つに集約できます。第一に、CakePHP 2系は2021年6月15日にEOLを迎え*2、Zend Frameworkも2019年にLaminas Projectへ移行しています*3。第二に、移行アプローチは全面リライト・段階移行・ストラングラーパターンの3系統があり*6、システムの停止可否や対象範囲の広さによって適した方式が変わります。第三に、外注可否を判断する材料は、資産調査から依存整理・移行方式の設計・並行稼働・切替後の運用保守までを一括で任せられる体制かどうかという点に集約されます。
よくある質問
CakePHP 1系やZend Frameworkのままでも動作しているなら、移行を急ぐ必要はありますか。
動作自体が継続していても、フレームワーク側から新規のセキュリティ修正が提供されない状態です*2*3。新たな脆弱性が見つかった場合、FW側での対応は期待しにくくなります。PHP本体のサポート期間(2年の積極サポート後、さらに2年のセキュリティ修正のみ、合計4年)*1との組み合わせ次第で、対応の余地は年々狭くなっていく点を踏まえて検討することをお勧めします。
全面リライトと段階移行、どちらを選ぶべきですか。
システムの停止可否、画面・機能同士の結合度、対象範囲の広さによって適否が変わります。停止時間を確保しにくい業務システムでは、機能単位で新旧を並行稼働させる段階移行やストラングラーパターンが選ばれやすい傾向があります*6。
移行先はLaravelでなければいけませんか。
特に決まりはありません。Laravelは年1回程度のメジャーリリースがあり、バグ修正18か月・セキュリティ修正2年という支援期間が明示されている点が選ばれる理由の一つです*5。要件や既存の技術スタックによっては、他のモダンなPHPフレームワークも選択肢になります。
テストコードが無い状態でも移行できますか。
単体テストが整備されていなくても、移行前の挙動を記録する特性テストやE2Eテストを先に用意し、移行後との比較材料にする進め方が広く採られています。仕様書が失われている場合は、既存コードの挙動をテストとして固定する作業を移行初期に組み込む必要があります。
外注する場合、何を確認すればよいですか。
資産調査(現行コード・データベース・外部連携の洗い出し)から依存整理、移行方式の設計、並行稼働時の切替判断基準までを一括で依頼できるかを確認します。移行後の運用保守まで見据えた体制かどうかも、契約前の判断材料になります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：PHP「Supported Versions」（PHP公式サイト）（https://www.php.net/supported-versions.php）
- *2 出典：CakePHP公式Bakeryブログ「CakePHP 2.x End of Life」（2021年10月2日公開、EOL日2021年6月15日）（https://bakery.cakephp.org/2021/10/02/cakephp_2_eol.html）
- *3 出典：Zend公式ブログ「From Zend to Laminas」（2019年4月17日）（https://framework.zend.com/blog/2019-04-17-announcing-laminas.html）
- *4 出典：Symfony公式「Releases」（https://symfony.com/releases）
- *5 出典：Laravel公式ドキュメント「Release Notes」（https://laravel.com/docs/master/releases）
- *6 出典：Martin Fowler「StranglerFigApplication」（martinfowler.com bliki）（https://martinfowler.com/bliki/StranglerFigApplication.html）
