PHP5のまま放置は危険？移行すべきか判断する10項目

「うちのシステム、まだPHP5で動いているんだが大丈夫か」。情シス担当者がこの質問を受けたとき、即答できるだろうか。PHP5.6の公式セキュリティサポートは2018年12月に終了した。それから7年以上が経過した今も、旧バージョンのPHPで稼働し続けるシステムは少なくない。

本記事では、レガシーPHPシステムの移行要否を判断するためのチェックリストを、セキュリティ・パフォーマンス・人材確保の3つの観点で整理する。

レガシーPHPの診断が急務である背景

まず、古いPHPシステムを取り巻く状況を確認しておく。

PHPバージョンのサポート状況

2026年3月時点で、PHPの公式サポート状況は以下のとおりだ。

（出典：PHP公式 Supported Versions、2026年3月時点）

PHP5系は、最も新しい5.6ですら2018年末にサポートが切れている。PHP7系も全バージョンがEOL（End of Life）に達した。つまり、これらのバージョンに新たな脆弱性が見つかっても、公式からの修正パッチは提供されない。

フレームワークのサポート状況も深刻

PHPのバージョンだけでなく、フレームワーク側の問題も無視できない。

CakePHP 2.x は、CakePHP 3以降でORMが全面刷新された。データの受け渡しが配列からオブジェクトベースに変わり、モデル・ビュー・コントローラのすべてに影響が及ぶ（出典：CakePHP 3.0 Migration Guide）。CakePHP 2から最新版への移行は、事実上の作り直しに近い工数が発生する。

FuelPHP は、最後の安定版リリースが2019年6月の1.8.2だ。PHP 8.0以上に対応した正式リリースはなく、開発は事実上停止している（出典：bmf-tech.com「FuelPHPの2025年2月現在の現況」）。公式なEOL宣言すら出ていないが、実態としてはメンテナンス終了と同義である。

レガシーPHP診断チェックリスト｜セキュリティ編

最も優先度が高いのがセキュリティの観点だ。以下のチェック項目に1つでも該当する場合、移行の検討を強く推奨する。

チェック1: PHPバージョンがEOLに達している

PHP 8.1以前を使っている場合、公式のセキュリティパッチは提供されない。OS側のバックポート対応に依存することになるが、Amazon Linux 2023ではPHP5.x/7.xのパッケージ自体が存在しない（出典：tane-creative.co.jp「EOLになったPHPバージョンとOSによるバックポートについて」）。バックポートに期待できない環境では、脆弱性が放置される。

チェック2: 既知の脆弱性に未対応

2024年6月に公開されたCVE-2024-4577は、PHP CGIのリモートコード実行脆弱性だ。CVSSスコアは9.8（Critical）で、公開直後からランサムウェア攻撃への悪用が確認された（出典：IPA「PHPの脆弱性（CVE-2024-4577）を狙う攻撃について」）。IPAも緊急の注意喚起を発出している。古いPHPバージョンでは、この種の脆弱性に対するパッチ適用が困難だ。

チェック3: フレームワークの脆弱性対応が停止

FuelPHPのように開発が事実上停止したフレームワークでは、脆弱性が発見されても修正されない。CakePHP 2.xも同様に、セキュリティ修正は期待できない状況にある。

チェック4: 暗号化・認証方式が古い

PHP5時代のmcrypt拡張やSHA-1ベースのハッシュ関数は、現在の基準では安全とは言い難い。password_hash関数の導入以前に構築されたシステムでは、パスワード管理そのものが脆弱な可能性がある。

レガシーPHP診断チェックリスト｜パフォーマンス編

セキュリティの次に確認すべきは、パフォーマンスの観点だ。

チェック5: PHP7以降の性能向上を享受できていない

PHP7はPHP5.6比で約2倍の実行速度を実現した。PHP8ではJITコンパイラが導入され、さらに性能が向上している。古いバージョンのまま運用し続けることは、サーバーリソースの浪費に直結する。同じ処理をより少ないサーバー台数でさばけるなら、インフラコストの削減にもなる。

チェック6: レスポンスタイムが年々悪化

データ量の増加に対して、旧バージョンのPHPでは最適化の余地が限られる。PHP8.x系のFiber（非同期処理）やJIT最適化が使えないため、処理のボトルネックを解消しにくい。「以前は1秒で返っていた画面が、今は5秒かかる」という声があれば、要注意だ。

チェック7: 最新ライブラリ・サービスとの連携に制約

外部APIやSaaS連携で「PHP7.4以上が必要」と言われるケースは増えている。Composerで管理するパッケージも、PHP5対応を打ち切るものが大半だ。新しいサービスとの接続が技術的に困難になると、業務全体の柔軟性が損なわれる。

古いPHPシステムの構造、把握できているだろうか。

SysDockなら、AIマルチエージェントがソースコードの構造・依存関係・リスク箇所を1週間で可視化する。ソースコード非送信のローカル解析で、セキュリティの懸念なく診断を実施できる。

着手金0円・完全後払い。まずはお見積り → sysdock.genbacompass.com

レガシーPHP診断チェックリスト｜人材確保編

3つ目の観点は、人材の確保と維持だ。

チェック8: PHP5系・旧FW経験者の採用が困難

2025年上半期のITエンジニア転職市場は売り手市場が継続しており、求人倍率は11.6倍に達する（出典：レバテック「エンジニア採用が難しい理由」、2024年12月時点）。そもそもエンジニア採用が難しい中で、CakePHP 2やFuelPHPの経験者を見つけるのはさらに困難だ。モダンなLaravelやSymfony経験者は多いが、旧世代フレームワークのスキルを持つ人材は市場からほぼ消えている。

チェック9: 既存の保守担当者に依存

現行システムを維持できるのが社内の特定の担当者だけ、という状態はリスクが高い。その担当者が異動・退職すれば、システムの保守が立ち行かなくなる。IPAの調査でも、古いシステムを理解し運用できる技術者の高齢化と技術継承の困難さが繰り返し指摘されている。

チェック10: 新規機能の追加に時間がかかりすぎる

旧バージョンのPHPやフレームワークでは、開発に使えるツールやライブラリが限られる。テストフレームワーク、CI/CDパイプライン、静的解析ツールの多くがPHP8.x以上を前提としている。その結果、簡単な機能追加にも想定以上の工数がかかり、ビジネスの要求に開発スピードが追いつかない。

移行判断のフローチャート｜レガシーPHPの診断結果を活かす

上記10項目のチェック結果を踏まえて、移行判断の目安を示す。

即座に移行を推奨するケース

• セキュリティ編（チェック1〜4）で2項目以上に該当
• CVE-2024-4577のような重大脆弱性の影響範囲にある
• 顧客情報や決済情報を扱うシステムでPHP5/7系を使用

この場合、移行の優先度は「最高」である。セキュリティインシデントが発生してからでは、対応コストは桁違いに膨らむ。

計画的に移行を進めるべきケース

• パフォーマンス編で2項目以上に該当
• 人材編で1項目以上に該当
• 業務拡張の計画がある

半年〜1年の計画で移行ロードマップを策定するのが現実的だ。まず現行システムの構造を可視化し、移行の影響範囲を明確にした上で着手する。

現状維持が許容されるケース

• 外部公開のないイントラネット用途
• セキュリティチェックに該当しない
• 保守体制が安定している

ただし、この場合でも年1回の定期診断は欠かさないでほしい。状況は刻々と変わる。

Laravel（PHP）でのレガシーコード改善の具体的な進め方は、Laravel（PHP）のレガシーコード改善ガイドで詳しく解説している。

レガシーPHPからの移行で押さえるべきポイント

移行を決断した場合に、情シス担当者が押さえておくべき実務上のポイントを整理する。

移行先の選択肢を整理する

PHP8.x + Laravel が現時点で最も人材が豊富で、エコシステムも充実している。ただし、システムの特性によってはPHPに固執する必要はない。Go言語やPython（Django/FastAPI）へのリプレイスが適切なケースもある。

判断の軸は「現行システムの規模」「開発チームのスキル」「今後の拡張計画」の3つだ。

段階的移行を検討する

全面リプレイスは費用も期間も大きくなる。まず影響範囲の小さいモジュールから段階的に移行する「ストラングラーフィグパターン」が実務では有効だ。旧システムを段階的に新システムに置き換えていくアプローチで、ビジネスの継続性を担保しながら移行を進められる。

現行システムの構造を可視化してから着手する

移行プロジェクトで最も多い失敗は「現行システムの理解不足」に起因する。設計書が古い、もしくは存在しない場合、ソースコードから構造を読み解くところから始める必要がある。この工程を人手で行うと数週間〜数ヶ月かかるが、AI解析を活用すれば大幅に短縮できる。

移行判断の第一歩は、現行システムの「見える化」から。

SysDockは、PHP（Laravel、CakePHP等）を含む13言語/フレームワークに対応したAI構造解析サービスだ。Word・PPT・React Flowフロー図を1週間で納品する。着手金0円の完全後払い。

着手金0円・完全後払い。まずはお見積り → sysdock.genbacompass.com

まとめ

レガシーPHPシステムの移行判断は、「なんとなく古いから」ではなく、客観的な基準に基づいて行うべきだ。本記事のポイントを3つに整理する。

• セキュリティリスクが最優先の判断基準になる。 PHP5/7系はすでにEOLを迎え、CVE-2024-4577のような重大脆弱性への対応が困難だ。顧客データを扱うシステムは即座に移行を検討してほしい。

• パフォーマンスと人材の観点も見逃せない。 PHP8.xとの性能差は大きく、旧FWの経験者採用は年々難しくなっている。放置するほど移行コストは増加する。

• 移行の前に、現行システムの構造把握が欠かせない。 設計書がなくても、ソースコードから構造を可視化する手段はある。まず全体像を掴んでから計画を立てるのが失敗を防ぐ鍵だ。

よくある質問（FAQ）

Q. PHP5で動いているシステムだが、今まで問題なく稼働している。それでも移行すべきか？

A. 「問題が顕在化していない」ことと「安全である」ことは異なる。PHP5系は2018年にサポートが終了しており、既知の脆弱性が修正されない状態が7年以上続いている。外部公開しているシステムであれば、攻撃対象になるリスクは日々高まっている。

Q. CakePHP 2からLaravelへの移行は現実的か？

A. 技術的には可能だが、CakePHP 2とLaravelではアーキテクチャが大きく異なる。単純な書き換えではなく、設計を含めた再構築が必要になる。まず現行システムの構造とビジネスロジックを洗い出し、移行範囲と工数を見積もる工程が不可欠だ。

Q. 移行の費用感はどの程度か？

A. 規模や複雑度により大きく異なるが、中規模のPHPシステム（画面数50〜100程度）で数百万〜数千万円が一般的な相場だ。ただし、段階的移行を採用すれば年度ごとに予算を分散できる。まず構造解析で全体像を把握し、見積もりの精度を上げることが重要になる。

Q. SysDockでレガシーPHPシステムの診断はできるか？

A. SysDockは13言語/フレームワークに対応しており、PHPも対象に含まれる。ソースコードを外部に送信せずにローカルで解析するため、セキュリティポリシーが厳しい環境でも利用可能だ。構造・依存関係・リスク箇所を1週間でレポート化する。

現場改善に役立つ関連ツール

GenbaCompassでは、SysDock以外にも現場のDXを支援するツールを提供している。