CakePHP 2の移行先はCakePHP 5かLaravelか？選び方と費用・期間の目安

CakePHP 2で構築した業務システムやWebサービスが、今も現役で動いている。改修は続けているものの、フレームワークのバージョンは上げられず、PHPも7系のまま。保守会社や社内のエンジニアから「そろそろ限界です」と言われて移行を検討し始めた担当者の方に向けて書いています。

CakePHP 2からの移行は、同じCakePHPの最新版へ上げる場合でも、作り直しに近い作業になります。この記事では、CakePHP 2の現状と使い続けるリスクを整理したうえで、移行先をCakePHP 5とLaravelのどちらにするかの判断基準、段階的に上げるか一気に移るかの違い、費用と期間の目安、AIを使った移行の進め方を解説します。同じ構図にあるCodeIgniter 3からの移行にも1節を割きました。

CakePHP 2はサポートが終了し、対応するPHPも7系まで

CakePHP 2系は、公式の告知によれば2021年6月15日にサポートを終了しています。最後の系列は2.10で、2020年12月の2.10.24が最終リリースです。以降は不具合修正もセキュリティ修正も提供されていません。

動作するPHPのバージョンも問題です。公式ドキュメントの動作要件では、2.8以降がPHP 7に対応するとされる一方、「2.xはサポート終了で保守モードにあり、PHP 7.1以降に追加された機能は十分にサポートされない」と明記され、PHP 8への公式対応はありません。つまりCakePHP 2のシステムは新しくてもPHP 7.4で動いていることになりますが、そのPHP 7.4も2022年11月にサポートを終了しています。フレームワークとPHP本体の両方が、脆弱性が見つかっても修正されない状態です。

次の系列も安全圏ではありません。CakePHP 3系は2022年12月にサポートを終了しており、4系のセキュリティ修正も公式のサポート方針では2026年9月10日までとされています。現時点で移行先として成立するのはCakePHP 5だけで、現行の5.4系はPHP 8.2以上、8.5までに対応しています。

使い続けると何が起きるか

「動いているのだから、触らなければ大丈夫」と考えたくなりますが、周囲の環境は止まってくれません。

まず、PHP 7.4を動かせるOSやサーバー環境が減っていきます。クラウドのマネージドサービスやOSの新しい版はPHP 8系しか用意していないことが多く、サーバー更新やクラウド移行のたびに古いPHPを維持する追加コストがかかります。延長サポートを買って時間を稼ぐ手もありますが、根本の解決にはなりません。

次に、脆弱性と周辺部品です。フレームワークにもPHPにも修正が出ないため、新しく見つかった脆弱性は自分たちで塞ぐしかなく、外部公開しているシステムなら取引先のセキュリティチェックや監査の指摘対象にもなります。CakePHP 2向けのプラグインも開発が止まっているものが多く、決済や認証のように外側とつながる部品ほど、相手側の仕様変更に追従できなくなります。

そして人です。CakePHP 2を知るエンジニアは年々減り、新しく学ぶ人はほぼいません。仕様を知る担当者が退職すれば、そこから先はブラックボックスです。この構図は当社が移行を手がけたFuelPHPでもまったく同じで、放置するほど移行の難易度と費用が上がる点はFuelPHPからLaravelへの移行事例でも触れています。

CakePHP 5かLaravelか。判断基準は5つ

移行先の候補は、同じCakePHPの最新版であるCakePHP 5と、PHPで最も広く使われているLaravelの2つに絞られます。ここで知っておくべきなのは、CakePHP 5へ上げる場合でもコードの大半を書き直すことになる点です。

CakePHPは2から3へ上がる際に、データベースを扱うORM(オブジェクトとデータベースを対応づける仕組み)がゼロから作り直され、従来のモデル層は丸ごと置き換えられました。公式の移行ガイドも「新しいORMへの移行にはアプリケーションの広範な変更が必要」としています。リクエストの扱いやディレクトリ構成、クラスの命名も変わったため、2の資産をそのまま持ち上げることはできません。「同じフレームワークだから楽」という前提は、CakePHP 2には当てはまりません。

つまり、どちらへ移っても書き直しの規模は近い。そのうえで、次の5つの基準で判断することになります。

CakePHP 5を選ぶ利点は、規約や考え方の連続性です。命名規則やコードの自動生成(bake)、規約を優先する設計思想は2から引き継がれており、既存メンバーが読み解きやすい。公式のアップグレードツールが4系以降の版どうしの変更を自動化しているため、5に乗ってしまえば以後のバージョンアップは軽くなります。

Laravelを選ぶ利点は、人材と情報の厚みです。国内のPHP求人はLaravel案件が中心で、保守を引き継げるエンジニアを確保しやすく、周辺機能も公式パッケージとして揃っています。毎年メジャーバージョンが出て、公式のサポート方針では各バージョンに18か月の不具合修正と2年のセキュリティ修正が提供されます。現行のLaravel 13は2026年3月のリリースで、PHP 8.3から8.5に対応しています。

どちらが正解ということはありません。国内の公開事例にも、CakePHP 2から4へ段階的に上げた例と、Laravelへ移した例の両方があります。後者は3案を比べたうえで、メンバーのLaravel経験と保守の活発さを決め手にしています。自社の体制に当てはめて、上の5つの基準を順に埋めてください。

段階アップグレードか、直接移行か

次は経路です。CakePHP 5へ進む場合、2→3→4→5と段階的に上げる方法と、2から5へ一気に移る方法があります。Laravelへ移る場合は直接移行の一択です。

段階アップグレードでは、各段階でアプリケーション全体のテストが必要になります。しかも3つの壁の高さは均一ではありません。2→3が最も高く、ORMとモデル層の全面刷新で大半を書き直します。3→4は非推奨機能の整理とPHP 7.2以降への対応が中心で、公式ツールがある程度を肩代わりします。4→5も非推奨機能の削除と型宣言の追加が中心です。作業量の大半は最初の一段に集中し、そこを越えた後も2回のテストが残ります。

それでも段階アップグレードが選ばれるのは、内製チームが業務を止めずに少しずつ進めたい場合です。新旧のフレームワークを共存させ、リクエストを振り分けながら機能単位で移していく進め方で、CakePHP 2と4を共存させた公開事例もあります。ただし期間は長くなり、先ほどのLaravelへ移した事例でも当初半年の見込みが約1年に延びています。

直接移行は、外部に委託してまとめて移す場合や、3系・4系を経由する意味がない場合に向きます。3系はすでにサポートが終了し、4系も2026年9月でセキュリティ修正が終わるため、途中の系列に留まる選択肢は事実上ありません。テストは1回で済み、期間も短くなりますが、影響範囲が一度に全体へ及ぶため、新旧の動作を突き合わせる比較テストをどれだけ体系的に回せるかが品質を左右します。

費用と期間はどう決まるか

CakePHP 2からの移行費用は、ほぼ「書き直す量」で決まります。その量を左右するのは、次のような要素です。

• コントローラ・モデル・ビューの本数と、ソースコードの行数
• 独自に作り込んだコンポーネント・ビヘイビア・ヘルパーの数
• 使用しているプラグインのうち、移行先に後継があるもの・ないもの
• 外部システムとの連携数と接続方式
• テストコードと、新旧の動作を比較できる環境の有無

見落とされやすいのがビューとプラグインです。CakePHP 2のビュー(.ctpファイル)は画面ごとに書かれているため、画面数の多いシステムでは書き換えが工数のかなりの部分を占めます。後継のないプラグインは代替の選定と作り込みが必要で、1本でも見積を大きく動かします。

規模別のおおよその目安は、人手による従来手法のリライト方式で次のとおりです。内訳や方式による違いはシステムマイグレーションの費用相場と期間の目安にまとめています。

この目安に自社のシステムを当てはめるには、まず移行対象の棚卸しが要ります。次の図は、無料診断で当社が作る棚卸し表のイメージです。

※実案件のものではなく、当社で作成したサンプル資料です。

棚卸し表があると見積の根拠が「何をどう扱うか」の積み上げになり、複数の見積を比べるときに差の理由が見えます。内訳の読み方はマイグレーション見積の方法で解説しています。

CodeIgniter 3からLaravelへの移行も同じ構図

同じ時期に普及したCodeIgniter 3でも、構図はまったく同じです。公式サイトはCodeIgniter 3を「レガシー版」と位置づけ、主にセキュリティ更新のみの保守モードとしています。最終版の3.1.13は2022年3月のリリースで、同時期の3.1.12でPHP 8.0・8.1向けの互換対応が入ったのを最後に、更新は止まっています。そのPHP 8.1も2025年12月にサポートを終了しました。

後継のCodeIgniter 4は、公式ガイドが「フレームワークの書き直しであり、後方互換性はない」と明記しています。CakePHP 2→3と同じく、3のコードをそのまま4へ持ち上げることはできず、選択肢はCodeIgniter 4へ書き直すか、Laravelへ書き直すかの2つです。判断基準は先ほどの5つがそのまま使えます。CodeIgniterは軽量で自由度が高かった分、独自の作り込みをLaravelの標準機能にどう置き換えるかが移行の中心になります。

AIマイグレーションでの進め方

当社のAIマイグレーションでは、最初にAIがソースコード全体を解析して、先ほどの棚卸し表にあたる情報を実測します。独自部品やプラグインへの依存、外部連携の箇所まで機械的に洗い出すため、仕様書がなくても現状を把握できます。設計書がない場合の進め方は仕様書がないシステムはAIで移行できる？で解説しています。

変換は、移行専用に開発したマルチAIエージェントが担います。解析・変換・テスト・ドキュメント生成を分担し、夜間も含めて「変換→検証→修正」を自律的に反復して品質を作り込みます。人は、AIの成果物のレビュー、業務上どちらの挙動が正しいかの判断、受け入れテストに集中します。CakePHP 2の配列ベースのデータ処理をオブジェクトベースに書き換えるような、量は多いが規則性のある変換はAIの得意分野です。

参考値になるのは、同じくサポートが終了したPHPフレームワークからの移行である当社のFuelPHP→Laravel案件です。変換対象約25万行の基幹システムをPHP 8系とLaravel 12へ移行し、従来手法の見積と比べて金額・工期とも約60%の削減になりました。既存システムの改修凍結期間は2週間です。AIによる変換は繰り返し実行できるため移行中の改修に追従でき、段階アップグレードの利点である「業務を止めない」ことと、直接移行の利点である「テストは1回」を両立できます。

CakePHPはFuelPHPとは別のフレームワークですので、無料診断では通常より厚めにサンプル変換を行い、実際のコードで技術的に適応できることを確認したうえで、次の工程へ進むかをご判断いただきます。

まとめ

CakePHP 2はサポート終了から5年が経ち、動作するPHPも修正が止まっています。移行先はCakePHP 5でもLaravelでも書き直しの規模は近く、5つの基準で自社に合う方を選ぶことになります。経路は、3系・4系が移行先として成立しない以上、直接移行が基本です。費用は書き直す量で決まるため、まず棚卸しで規模と依存関係を把握することが出発点です。

DEN-NOのAIマイグレーションサービスでは、NDA(秘密保持契約)を締結のうえシステム概要とソースコードの一部をお預かりし、現状リスクと移行可能性をまとめた診断レポートと概算費用を無料でご提示しています。仕様書・設計書のご準備は不要です。

AIマイグレーションサービスの詳細はこちら

よくある質問

Q. CakePHP 2のままPHP 8で動かすことはできませんか？

公式にはPHP 8への対応はなく、有志による互換パッチが公開されている状況です。動かせたとしても、フレームワーク本体の開発が止まっている事実は変わらず、次のPHPのサポート終了で同じ問題に直面します。移行までの時間稼ぎと割り切る場合に限られます。

Q. CakePHP 4まで上げて止めるのは現実的ですか？

おすすめしません。4系のセキュリティ修正は公式の方針で2026年9月10日までとされ、上げた直後にサポートが切れます。2→3の壁を越える工数は同じですので、進むなら5まで進むべきです。

Q. 移行中、既存システムの改修は止める必要がありますか？

長期間の凍結は不要なケースが多くなっています。AIによる変換は繰り返し実行できるため、既存システムの改修内容に移行作業を追従させられるからです。当社のFuelPHP案件では、改修凍結期間を2週間に抑えました。

Q. 概算を出すには何を用意すればよいですか？

システムの用途と利用者数、おおよその画面数がわかれば概算は可能です。無料診断ではソースコードの一部をお預かりして棚卸しと解析を行うため、仕様書・設計書のご準備は不要です。