なぜ古いPHPのバージョンアップに工数がかかるの？1人月を超えることもある3つの理由を、PHP公式の情報から解説します

2026年11月12日

こんにちは。セルバの中山です。

2026年10月、PHPに深刻な脆弱性（PHP2Shell）が見つかったことを受けて、セルバではPHPの緊急セキュリティアップデート支援を行っています。たくさんのご相談をいただく中で、すぐに終わるものもあれば、見積もりが1人月を大きく超えるものもあります。

「PHPのバージョンを上げるだけなのに、なぜそんなにかかるの？」と思われるのは当然だと思います。そこでこの記事では、PHP公式のマニュアルや仕様変更の提案（RFC）、各フレームワークの公式ドキュメント、Red HatやMySQLの公式資料をもとに、その理由を説明します。

先に結論を言うと、理由は次の3つです。

理由1：PHPに互換性がない：新しいPHPでは、昔の書き方がエラーになったり、同じコードでも結果が変わったりする。PHP 8.0の移行ガイドだけでも、互換性のない変更が数十件並ぶ
理由2：フレームワークが古い：Zend Framework 1は2016年にサポート終了。CodeIgniter 4は公式に「アップグレードではなく、アプリの変換と考えて」と書いている。フレームワークを変えると、実質的に作り直しになる
理由3：古いPHPを使っているとOSも古い：CentOS 6の標準はPHP 5.3、CentOS 7は5.4。新しいPHPを使うにはOSを何世代も上げる必要があり、データベースやWebサーバーの変更も一緒についてくる

そして、そもそもなぜ互換性のないバージョンが出るのかというと、PHPをより安全に、より速く、バグが起きにくい言語にするためです。最後に、その背景も紹介します。

前提：PHPは毎年新しくなり、4年でサポートが終わる

PHPは毎年1回、新しいバージョンが出ます。PHP公式によると、各バージョンは2年間のフルサポートと、その後2年間のセキュリティ修正を受けられます。つまり、1つのバージョンは約4年で寿命を迎えます。

主なバージョンのサポート終了日は次のとおりです。

PHP 5.6：2018年12月31日
PHP 7.4：2022年11月28日
PHP 8.0：2023年11月26日
PHP 8.1：2025年12月31日
PHP 8.2：2026年12月31日（あと2か月）

10年前に作ったシステムがPHP 5系のまま動いていれば、最新の8.5まで10近いバージョンを一気に飛び越えることになります。PHP公式も、サポートが終わったバージョンを使い続けると脆弱性にさらされるおそれがあるとして、最新バージョンへのアップグレードを強く勧めています。

理由1：PHPに互換性がなく、新しいバージョンだとエラーや挙動が変わる

PHPは、バージョンが上がるたびに古い機能の削除や、動きの変更を行っています。PHP公式マニュアルには、バージョンごとに「後方互換性のない変更点」がまとめられています。影響の大きいものを抜き出すと、次のとおりです。

PHP 5.6 → 7.0：データベース接続の書き方が使えなくなった

mysql_で始まる関数がすべて削除された。古いシステムでよく使われていた、MySQLへの接続や検索の書き方が丸ごと使えなくなった
ereg関数がすべて削除された（正規表現の書き方の変更が必要）
多くの致命的なエラーが「例外」に変わり、自作のエラー処理が呼ばれなくなる場合がある

PHP 7.x：少しずつ厳しくなる

7.1：自分で定義した関数の引数が足りないと、警告ではなくエラー（ArgumentCountError）で止まるようになった
7.2：数えられない値にcount()を使うと警告が出るようになった。暗号化でよく使われたMCryptが標準から外れた（2007年から更新されていなかったため）。each()やcreate_function()が非推奨に
7.4：括弧のない三項演算子の入れ子や、$var{$idx}という書き方などが非推奨に

PHP 7.4 → 8.0：同じコードで結果が変わる

8.0は、特に影響が大きいバージョンです。

数値と文字列の比較の結果が変わった：たとえば0 == “foo”は、7.4まではtrueだったのが、8.0からはfalseになった
たくさんの警告がエラー（例外）に変わった。今まで警告を出しながら動いていた処理が、止まるようになった
エラー表示の初期設定がすべてのエラーを出す設定（E_ALL）になり、@演算子で致命的なエラーを隠せなくなった
each()、create_function()などが削除された
matchが予約語になり、同じ名前の関数やクラスが使えなくなった

PHP 8.0の「後方互換性のない変更点」のページを数えてみると、PHP本体だけで約50件、ページ全体では100件ほどの項目が並んでいます（筆者が数えたおおよその数です）。

PHP 8.1以降：非推奨の警告が増える

8.1：PHPの標準関数に、nullを渡すことが非推奨に（例：str_contains(“foobar”, null)）。PHP 9.0ではエラーにする予定
8.2：クラスで宣言していないプロパティを動的に作ることが非推奨に。”${var}”形式の文字列の埋め込みや、utf8_encode()も非推奨に
8.4：T $a = nullという書き方（暗黙的なnullable型）が非推奨に。IMAPやOCI8（Oracle接続）などの拡張がPHP本体から外れた
8.5：バッククォート演算子や、(integer)などの古いキャストの書き方が非推奨に

なぜ工数がかかるのか

ポイントは、エラーになる変更より、黙って結果が変わる変更のほうが怖いことです。関数が削除されたなら、エラーが出るので気づけます。ですが、0 == “foo”のように比較の結果が変わる変更は、エラーが出ないまま、画面の表示や計算結果、検索の条件が静かに変わってしまうことがあります。

そのため、コードを直すだけでなく、画面や機能を一つひとつ動かして、結果が変わっていないかを確かめるテストが欠かせません。古いシステムほど自動テストがなく、仕様書も残っていないことが多いので、この確認に大きな工数がかかります。

理由2：フレームワークが古い

多くのPHPのシステムは、フレームワークを使って作られています。そして、古いフレームワークは新しいPHPに対応していないことがほとんどです。PHPを上げるには、フレームワークも新しいバージョンに上げるか、別のフレームワークに乗り換える必要があります。

Zend Framework 1：2016年にサポート終了、公式の移行手順もない

Zend Framework 1は、2016年9月28日にサポートが終了しました。最後のバージョンは1.12.20で、GitHubのリポジトリも読み取り専用になっています。PHP 8はサポート終了より後に出たバージョンなので、当然対応していません。

Zend Frameworkの後継は、Linux Foundation傘下のLaminasですが、Laminasの公式の移行ガイドが対象にしているのは、Zend Framework 2と3（とApigility、Expressive）で、Zend Framework 1には触れていません。Zend Framework 1からの公式な移行手順はなく、実質的に作り直しになります。

CakePHP：2.xと3.xはPHP 8に非対応

CakePHPの公式のサポート表によると、2.xはPHP 5.3〜7.4、3.xはPHP 5.6〜7.4が対象で、セキュリティ修正もそれぞれ2021年6月、2022年12月に終わっています。現在のCakePHP 5はPHP 8.2以上が必要です。CakePHPの3.0への移行ガイドには、データベースまわりの仕組み（ORM）が新しくなったため、大規模な変更が必要になると書かれています。

CodeIgniter：4は「書き直されたフレームワーク」

CodeIgniter 3は、現在ほぼセキュリティ更新だけの保守状態です。後継のCodeIgniter 4はPHP 8.2以上が必要ですが、公式のアップグレードガイドには、CodeIgniter 4はフレームワークを書き直したもので、後方互換性がないと書かれています。そのうえで、「アップグレード」ではなく「アプリの変換」と考えるべきだとしています。

Laravel・Symfonyも、メジャーバージョンごとに変更が必要

比較的新しいフレームワークも、ずっと同じバージョンで使えるわけではありません。Laravelは、各バージョンのバグ修正が18か月、セキュリティ修正が2年です。2026年3月に出たLaravel 13はPHP 8.3以上が必要で、Laravel 12はセキュリティ修正のみ（2027年2月まで）、Laravel 11以前はすでにサポートが終わっています。Symfonyも、メジャーバージョンには互換性を壊す変更が含まれることがあり、アプリ側の修正が必要になる場合があるとしています。

ライブラリや開発ツールも

フレームワーク以外の部品も同じです。テンプレートエンジンのSmartyは、PHP 8への対応がバージョン4からで、そのときにテンプレート内の{php}タグが廃止されました。PHPのパッケージ管理ツールComposerの最新版も、PHP 7.2.5以上が必要です。

実際にセルバでご相談いただいている案件でも、PHP 5.4・Zend Framework 1・CentOS 6で動いているシステムを、AlmaLinux 10・PHP 8.4・Laravelに移す検討をしています。PHPのバージョンだけでなく、フレームワークもOSもまとめて入れ替えることになるので、どうしても大きな工数になります。

理由3：古いPHPを使っているとOSも古い

OSに付いてくるPHPのバージョンが決まっている

サーバーのOSには、標準のPHPが付いてきます。Red Hatによると、RHEL 6（CentOS 6）はPHP 5.3、RHEL 7（CentOS 7）はPHP 5.4です。一方、最新のRHEL 10やAlmaLinux 10では、標準のphpパッケージを入れるとPHP 8.3が入ります（RHEL 10.2からは8.4も選べます）。古いPHPが動いているサーバーは、OSそのものも古いことが多いのです。

そして、そのOSもサポートが終わっています。

CentOS 6（RHEL 6）：2020年11月30日（RHEL 6のメンテナンスサポート終了日）
CentOS 8：2021年12月31日
CentOS 7：2024年6月30日

古いOSの上で新しいPHPを動かすのは難しく、外部のリポジトリも古いOS向けの更新を止めています。結局、OSも新しくする必要が出てきます。

OSは1世代ずつしか上げられない

RHEL系のOSは、今あるサーバーのままメジャーバージョンを上げる方法（インプレースアップグレード）も用意されています。ただし、Red HatのLeappはRHEL 7.9から8.10へのように1つ上のメジャーバージョンに上げるもので、AlmaLinuxのELevateも1回で1世代ずつ上げる仕組みです。ELevateは、CentOS 7から上げる場合は作業を分けて行う必要があると説明しています。CentOS 6から最新のAlmaLinux 10まで上げるなら、何段階もの作業と、そのたびの確認が必要になります。AlmaLinuxも、本番の前に仮想マシンなどで試すなど、慎重に進めるよう呼びかけています。

そのため実務では、新しいサーバーを用意して、アプリとデータを移す方法を選ぶことが多くなります。サーバーの構築、データの移行、切り替えの作業が、PHPのコード修正とは別にかかります。

データベースやWebサーバーも一緒に変わる

OSを新しくすると、MySQLやApacheなどのミドルウェアのバージョンも大きく上がります。ここにも互換性の問題があります。

MySQL 5.7：初期設定で、厳密なモード（STRICT_TRANS_TABLES）と、GROUP BYのあいまいな書き方を認めないモード（ONLY_FULL_GROUP_BY）が有効になった。以前は通っていたSQLがエラーになることがある
MySQL 8.0：標準の文字コードがlatin1からutf8mb4に変わった。新しい認証方式が標準になり、古い接続方法では接続できない場合がある。予約語が増え、テーブル名や列名がそのまま使えなくなることがある
MySQL 8.4：古い認証方式（mysql_native_password）が初期設定で無効になった
Apache 2.4：アクセス制御の書き方が、Order/Allow/DenyからRequireに変わった

PHPのコードだけでなく、SQLや設定ファイルの見直し、データの文字コードの変換まで必要になることがあります。

3つが重なると、1人月を超える

ここまでの3つの理由は、たいてい同時に起きます。PHP 5系で動いているシステムは、フレームワークも古く、OSも古いからです。そうなると、作業は次のように積み上がっていきます。

調査：どのコードが、どのバージョンの変更に引っかかるかを洗い出す
コードの修正：削除された関数や書き方を、新しいものに置き換える
フレームワークの移行：場合によっては、別のフレームワークへの作り直し
サーバーの構築：新しいOS、PHP、データベース、Webサーバーの準備
データの移行：文字コードの変換や、新しいデータベースへの移し替え
テスト：画面や機能を一つずつ動かして、結果が変わっていないかを確認
切り替え：本番の切り替えと、その後の確認

このうち、規模に比例して増えるのがコードの修正とテストです。画面や機能が多いシステムほど、確認すべき項目も増えます。これが、見積もりが1人月を大きく超えることがある理由です。

そもそも、なぜ互換性のないバージョンが出るのか

「互換性を保ってくれれば、こんなに苦労しないのに」と思いますよね。ですが、PHPが互換性を壊すのには理由があります。

互換性を壊すのは「メジャーバージョン」のときだけ、が原則

PHPのリリースの方針（リリースプロセスのRFC）では、メジャーバージョン（7.0や8.0など）では後方互換性を壊してもよい、マイナーバージョン（8.1や8.2など）では互換性を保つことが原則です。現在の方針では、大きな互換性の変更は、前のメジャーバージョンでまず「非推奨」として警告を出してから行うことになっています。また、マイナーバージョンで互換性に関わる変更をする場合も、黙って動きが変わる形にはしないことが求められています。

つまり、非推奨の警告は「次のメジャーバージョンで使えなくなりますよ」という予告です。8.1や8.2で増えている非推奨の多くも、PHP 9.0で正式にエラーになる予定が示されています。

互換性を壊してでも変える理由

PHPの仕様変更は、RFCとして提案され、開発者の投票で決まります。主なRFCが挙げている理由を見ると、互換性を壊すのはPHPをより良くするためだと分かります。

速くするため：PHP 7.0は、PHP 5.6より最大2倍速く、メモリ使用量も大きく減った
安全にするため：mysql_関数は、MySQL 3.23向けに作られた古い仕組みで、保守が難しく、SQLインジェクション対策に役立つプリペアドステートメントにも対応していなかった。create_function()も、セキュリティ上の問題があるとして非推奨になった
バグを減らすため：数値と文字列の比較を変えたRFCは、0 == “foobar”がtrueになる旧来の動きを、最大のバグの原因だろうとし、セキュリティの問題にもつながりうるとした（44対1で可決）
書き間違いに気づけるようにするため：動的プロパティを非推奨にしたRFCは、$user->naneのような書き間違いでも、PHPが黙って新しいプロパティを作ってしまう問題を挙げている
一貫性のため：標準関数へのnullの受け渡しを非推奨にしたRFCは、自分で作った関数との動きの違いをなくすことを理由にしている（46対0で可決）

互換性のない変更は、開発者にとっては手間です。ですがその分、PHPは速く、安全に、バグが起きにくい言語に変わってきました。古いPHPを使い続けるということは、これらの改善をすべて受けられないということでもあります。

工数を抑えるためにできること

今後、同じような大きな工数をかけないために、日ごろからできることもあります。

2〜3年に1回は、PHPのバージョンを上げる：1つのバージョンの寿命は約4年。こまめに上げれば、1回ごとの変更は小さく済む
非推奨の警告を放置しない：非推奨の警告は、次のメジャーバージョンで使えなくなるという予告。ログに出ている警告を少しずつ直しておく
フレームワークもサポート期間を意識して上げる：LaravelやSymfonyのように、サポート期間が公開されているものは、計画的に更新する
自動テストを用意する：テストがあれば、バージョンアップ後の確認の工数を大きく減らせる
AIを活用する：セルバでも、古いPHPのコードを新しいバージョンに合わせて書き換える作業に、AIのコーディング支援ツールを活用しています。修正箇所の洗い出しや書き換えの効率は上がりますが、結果の確認とテストは人が責任を持って行う必要があります

まとめ：PHPのバージョンアップは「PHPだけ」の話ではない

古いPHPのバージョンアップに工数がかかるのは、PHPそのものの互換性の変化に加えて、フレームワークとOS、データベースまで、まとめて新しくする必要があるからでした。特にPHP 5系のまま長く動いてきたシステムは、3つの理由が重なり、実質的にシステムの作り直しに近い作業になることもあります。

一方で、互換性のない変更は、PHPをより安全で速い言語にするためのものです。今回のPHP2Shellのような脆弱性は、これからも出てきます。サポートの続くバージョンを使い続けられる状態にしておくことが、結果的に一番の対策になると思います。

セルバでは、PHPの緊急セキュリティアップデート支援として、脆弱性への暫定対応から、PHPのバージョンアップ、フレームワークの移行、新しいサーバーへの移行まで対応しています。「うちのシステムはどれくらいかかりそうか知りたい」「まずは現状を調べてほしい」といった段階からご相談いただけます。まずは、何をすべきかを一緒に整理する無料相談から始められますので、お気軽にお問い合わせください。

セルバに問い合わせる

中山健代表取締役

株式会社セルバ代表取締役。
学生時代にアルバイトでWEB製作会社に入りプログラムを覚える。大学卒業後SIerにて金融システムの開発に携わった後、再びWEB業界へ。

WEB系のプログラム言語とサーバー構築、さらにはCOBOLも出来ます！
最近ではシステム開発だけでなく、SEOやマネタイズなどのグロースハックや企画を担当する事が多いです。