1SIXAI NATIVE COMPANY
リプレイス・移行20分

PHP5からPHP8への移行は難しい？古いシステムを止めずにバージョンアップする方法

文：

「サーバー会社から、PHPのバージョンを上げてくださいと連絡が来た。」

「でも、作った会社はもういない。何か触ったら止まりそうで怖い。」

こうしたPHPの相談は、いまとても増えています。

相次ぐ情報漏えいや、レンタルサーバー会社など古いPHPの提供をやめる動きが、ここ数年で一気に進んだからです。

結論から言うと、PHP5のシステムでも、PHP8への移行はできます。

ただし「バージョンの数字を書き換えるだけ」では、サイトやシステムによっては、ほぼ確実に動かなくなります。

先に自分のサイトがPHP8.xの最新版で動くのかを調べ、動作しなくなる箇所を把握してから、業務を止めない順番でPHPを移す必要があります。

この記事では、何が動かなくなる可能性があるのか、どのように調べるのか、どの順番で移していくのかを、経営者の方が判断できる粒度で解説します。

経営者の、止まると売上が下がるという極限の緊張感や不安を最大限におさえるために、弊社はほぼ無停止の移行にこだわっています。権限制約下での無停止現代化方法(特許取得済み)

この記事でわかること
  • PHP5を使い続けると何が起きるのか
  • PHP8に上げると動かなくなる、典型的な書き方と「静かに壊れる」落とし穴
  • 独自開発・古いフレームワーク別の進め方と、調査に使える道具
  • 移行先は「8.4以上」を選ぶべき理由と、止めずに移す4つの手順

PHP5を使い続けることの問題点

PHP5は、2018年末にすべてのサポートが終わっています。

最後のPHP5系である5.6のセキュリティ修正は、2018年12月31日で終了しました。

サポートがおわったバージョンを、EOL（エンド・オブ・ライフ）と言います。マーケティングやサイトのUI / UXがキラキラしていても、内側がEOLのサイトは日本にたくさん存在しています。

全身ブランド物で揃えて、高級車にのって、カラダの中は、病気でズタボロ、上辺だけという状態です。

PHP5のサポートがおわってから8年。新しく見つかった弱点は、EOLでは一切直されていません。サポートしないという事です。

「でも、今日も普通に動いている」という声もよく聞きます。

そのとおりです。動いています。だから内側のシステムより、マーケティングにお金をかける。その気持ちはわかります。

ただ、サイトやシステムが動いていることと、そのシステムが安全であるのかどうかは全く別の話です。

サポートが終わったソフトウェアには、次のような問題が積み重なっていきます。

  • 新しく見つかった脆弱性（セキュリティの弱点）が直されない
  • レンタルサーバーが古いPHPの提供をやめ、ある日突然動かなくなる
  • 新しいライブラリや外部サービス（決済、地図、メール配信）との連携ができなくなる
  • データベースの新しい版と接続できなくなる
  • 直せる技術者が年々減り、修理代が上がっていく

2026年10月のマイナビニュース TECH+の記事では、マネーフォワードの記事を引いて、日本企業の6割超が旧式システムやサポート終了済みのソフトウェア、古いOSを使っていて、攻撃の侵入口となる危険があると書かれています（出典：マイナビニュース TECH+）。
古いPHPは、まさにこの「侵入口になりやすいもの」の代表です。

さらに2026年10月には、PHP本体の深刻な脆弱性「PHP2Shell」が公表されました。ログインなしで、外部からプログラムを実行されるおそれのある2件の弱点で、実際の攻撃も確認されています。

PHP公式が新しく修正版を公開したのは、サポート中のPHP8.2〜8.5だけです。PHP5を含む7.3以前には、公式の修正版がありません。ただ、レンタルサーバーが独自で対応をしたケースもあります。

EOLのまま動かし続けるというのは、こういうことです。

なぜPHP5からPHP8で動かなくなるのか。

PHP5に対応したコードが、PHP8で動かなくなる原因は、ほとんどが「パターン」で説明できます。

カンタンに例えると、古いiPhone 6で、最新のiOS 27を動かそうと思っても動きません。でも、iPhoneは動きます。電話もできれば、ウェブブラウザでサイトも見れる。

PHP5の次は7、そして8と進化しています（6は正式版が出ず、欠番です）。

PHPは7.0と8.0の2回のバージョンアップの時に、大きく作りが変わりました。

その間に「もう使えないプログラムの書き方」が整理されたため、古いコードの場合は、PHPのバージョンをあげると、まとめて動かなくなってしまいます。

代表的なものを表にまとめます。ただ、この表は覚える必要はありません。PHP5はPHP8と違うということだけ経営者の方は覚えておいてください。

よくある書き方PHP8での扱い起きること
mysql_connect() などの mysql_* 関数PHP7.0で削除データベースに接続できず、画面が真っ白になる
ereg() split() などの古い文字列関数PHP7.0で削除入力チェックや文字列処理が動かない
mcrypt による暗号化PHP7.2で削除パスワードや個人情報の暗号化・復号ができなくなる
クラス名と同じ名前のコンストラクタPHP8.0で通常のメソッド扱い初期化処理が呼ばれず、データが空のまま進む
each() / create_function()PHP8.0で削除ループや動的処理の途中でエラー
$str{0} のような波カッコの文字アクセスPHP8.0で削除構文エラーでファイル全体が読み込めない
数値と文字列のゆるい比較PHP8.0で比較の規則が変更エラーは出ないが、条件分岐の結果が変わる
関数に想定外の型の値を渡すPHP8.0でエラー（TypeError）に7.xでは警告で済んだ処理が、画面ごと止まる

特に注意したいのが、「比較の規則の変更」と「想定外の値」の2つです。エラーが出ていないのに、ブレーキ踏んでもブレーキではないかもしれない、といった形の認識で良いです。

エラーが出ないまま、計算や判定の結果だけが変わる。

これがいちばん怖いパターンです。

たとえばPHP5では、0 == "abc" は「同じ」と判定されていました。

PHP8ではこの判定は「違う」になります。

画面は表示されるので、誰も気づかないまま、金額や在庫の判定がずれていく可能性があります。

まっすぐ進んでいるつもりでも、ハンドルが2cm右に傾いていたら、まっすぐには進まないという認識で良いです。

もう一つの「想定外の値」は、普段の操作では起きません。

空欄のまま送信された、数字の欄に文字が入った、古いデータに欠けた項目がある。

そういうときに、PHP5や7では警告だけで進んでいた処理が、PHP8では止まります。

この記事のあとのほうに書いてある「我々がヒリヒリした話」に、まさにこの話が出てきます。

だからこそ「とりあえず上げて、エラーが出たら直す」というやり方は危険なんです。

技術の話を詳しく書きましたが、細かいところは覚えなくて大丈夫です。記事を見てもらいたいのは経営者や社長さんです。

独自開発システムや古いフレームワークでも移行できる？

はい、できます。ただし、フレームワークの世代によって、どう移行させるのか進め方が変わります。

PHPのシステムは、大きく次の3つに分かれます。

種類例進め方
フレームワークを使わない独自開発社内や個人の開発者が一から書いたものどのように直すかを、自分たちで決められる。意外と移しやすい
開発が止まった古いフレームワークCakePHP 1〜2系、CodeIgniter 2系、Zend Framework 1系、Symfony 1系フレームワークごとの判断が必要。有志が保守するPHP8対応版があるものも
いまも開発が続くフレームワークLaravel、Symfony公式の移行手順に沿って、フレームワークを順に上げる

いちばん悩ましいのが2番目です。

フレームワーク自体がPHP8に対応していないため、PHPだけでなくフレームワークごと、PHP8に対応するように、入れ替える判断が必要になります。

ただ、ここで諦めるのは早い。

Zend Framework 1系やCakePHP 2系のように、開発元が止めたあとも有志がPHP8対応版を保守しているフレームワークがあります。

バイクでいう、CBRやケッチやホークが動くという認識くらいでとらえていてください。動かせないことはない。

そのPHP8対応版に差し替えれば、画面や機能はそのままに、土台だけを新しくできることがあります。

この場合は「PHP8対応版のフレームワークに上げる」か「画面と機能を保ったまま、新しい土台で作り直す」かを比べて決めます。

「もう作り直すしかない」と言われたシステムでも、本当にそうかは調べるまでわかりません。

まずは現状を確認してから判断しましょう。

調査に使えるAI。全部を人が読む必要はない。

動かなくなる箇所の多くは、AIやツールを使って機械的に洗い出せます。

ただし、実際の業務で正しい結果になるかどうかは、最後まで人間が確認する必要があります。

経営者の方がAIを触る必要はありませんが、「そういう使い方がある」と知っているだけで、移行させるべきかどうかの判断基準になります。

  • 互換性チェックの道具：ソースコード全体を機械的に検査し、「削除された関数」「変わった書き方」を一覧にする。PHP_CodeSniffer向けのPHPCompatibilityなどが代表です
  • 自動書き換えの道具：古い書き方を新しい書き方に機械的に直す。Rectorなど。すべては直せませんが、単純な置き換えはここで片付きます
  • 構文チェック：PHP8で読み込めないファイルを、動かす前に見つける
  • 本番の記録：PHPが出している警告の記録を集めると、どの画面で何が起きているかが先に分かる

「調査に何日もかかる」と言われたら、こうした道具を使っているかを聞いてみてください。
人がすべてのファイルを目で読む見積もりなら、やり方を変える余地があります。

システムを止めずに段階的に移行する方法

システムの移行は「AIで調査 → なんども検証環境で再現する → 部分的に移行 → 切り替え」の4段階で進めます。かなりざっくりの説明です。

いきなり本番のPHPを上げるのではなく、検証環境、そして本番で動くシステムとまったく同じもう一つのシステム環境を用意して、確認をしながら、そして確かめながら進めます。

1. 現状を調査する

最初に、いまどのように動いているのかを、正確に把握します。

  • PHPのバージョンと、使っている拡張機能
  • フレームワークとライブラリの種類・バージョン
  • データベースの種類とバージョン（MySQL 5.xから8への移行が同時に必要なこともあります）
  • 外部サービスとの連携（決済、メール配信、地図など）
  • 定期的に動く処理（決められた動作など）。画面には出ないので、忘れられがちです。

前の章のAIやツールを使えば、「削除された関数」などは一覧で洗い出せます。

自社でつくっていない場合、見ているものだけを判断材料にすると、必ず動かない箇所がでてきます。もしサーバーに入れたら、その設定・環境のすべてを読み取りで確認をします。

2. 検証環境で動かす

本番とは別に、PHP8が入った検証用のサーバーを用意します。

本番データが必要な場合は、個人情報を適切に保護・加工し、外部サービスへの誤送信も起きないようにしたうえで、画面を一つずつ操作して確かめます。

ここで大事なのは「いつもの業務」を通しで試すことです。経営者に話を聞いて、スタッフの方にどのように使っているのかを聞いて、我々が社員だったらこのように使うだろうな、ユーザーだったらこう使うだろうなと考えて試します。

受注から請求まで。依頼や予約からその依頼達成や記録まで。例として、受発注のあるシステムなら、発注、受注、仕事完了、そしてその後の入金確認までの動作を、すべてPHP8のモードで試します。

普段の流れで操作すると、動かないなどの不具合が見つかります。

そして、わざと変な値も入れてみます。

空欄、文字の混ざった数字、途中で戻るボタン。

「想定外の値」で止まる箇所は、こうしないと見つかりません。

検証する時には、攻撃者の目で見て、攻撃できるかという視点も取り入れてシステムを作り変えます。移行する時に一緒に強くしていきます。

3. 直せるところから直す

動作を確認しながら、洗い出した箇所を直していきます。

PHP5とPHP8の両方で動く書き方に寄せていくと、途中で元に戻しても困りません。

古い版でも動く書き方を保つ。これが戻り道になります。

そのため、PHP8でも動くが、PHP5でも動くという事を途中で行うこともあります。

4. 切り替えと、切り戻しの準備

システムの切り替えは、会社で使う管理画面やシステムであれば、社員が使わない時間帯。ウェブアプリケーションなら、ユーザーの少ない時間帯に行います。

そして必ず「元に戻れる手順」を用意してから、切り替えます。圧倒的にびびりながら移行させます。そのくらいが上手くいきます。起こり得るすべての最悪を想定して切り替えを行います。

戻す手順は、書くだけでなく、検証環境で試しておきます。

戻れる準備があるから、安心して前に進める。

移行で失敗しない会社は、例外なくここを丁寧にやっていると思います。2つか3つ戻れるようにしておいてから無停止移行にとりかかります。

ソースコードや設計書が残っていなくても、あきらめる必要はありません。

画面・帳票・データベースが残っていれば、そこから仕様を組み立て直せる場合があります。

制作会社と連絡が取れない場合の進め方は、開発会社・制作会社と連絡が取れないときの手順で詳しく解説しています。

移行先はPHP8.4以上を選ぶ

「PHP8なら何でもいい」は間違いです。いま選ぶなら8.4以上です。

PHP8にも、すでにサポートが終わった系列があります。

2026年11月時点の公式のサポート状況は、次のとおりです。

バージョンセキュリティ修正の終了2026年11月時点
8.02023年11月終了
8.12025年12月31日終了
8.22026年12月31日あと2か月で終了
8.32027年12月31日セキュリティ修正のみ
8.42028年12月31日通常のサポート中
8.52029年12月31日通常のサポート中

PHP8.2に移しても、2026年がおわる2か月後にはまたサポートが切れます。

移行にかかる時間を考えると、いまから選ぶなら8.4か8.5が現実的です。

「8.3と8.4で、手間は変わるの？」

私たちの経験では、7系から上げる場合、PHP8.3と8.4の手間の差は小さいです。ただ、それはどのようなシステムかによります。

PHP8.4では、四捨五入などの丸め処理に使える指定方法が増え、間違った指定をした場合の動作も変わりました。金額の計算を行うシステムでは、旧版との結果を突き合わせて確認をする必要があります。

手間が同じなら、PHPのサポートの長いほうを選ぶ。EOLにならないように、エンド・オブ・ライフにならないようにする。それだけです。

レンタルサーバーによっては、選べるバージョンが限られることもあります。

経営者の方は、8.4以上と覚えておいてもらえれば、後は制作業者がおこなってくれます。ただ、現時点で8.2で8以上にしたといわれても、2026年12月31日に、EOLとなります。

移行の費用と期間を左右する条件

ここで一番大切なお話も書いておきます。いくらかかるの？どれくらいで出来るの？です。

費用と期間は、システムの大きさよりも「中身の古さ」と「情報の残り具合」で決まります。

正直にお伝えすると、一律の相場はありません。世の中の仕事はすべて大変なので、特にシステム開発が大変という考えもしていません。

ただ、同じ画面数でも、次の条件となった場合に、難易度が何倍にも跳ね上がるからです。作れても無停止で事故なくそのまま再現できるのかの難易度が変わる、となります。

  • 古いフレームワークを使っているか（ほぼ全て入れ替えが必要か）
  • ソースコードや設計書の断片が残っているか
  • 外部サービスとの連携がいくつあるか
  • その外部サービスが海外と連携しているのか。自社完結か。
  • テストに協力してもらえる、業務を知っている人がいるか
  • 移行中に、新しい機能の追加も同時に求めるか

最後の項目は、費用だけでなく成功率を左右します。

PHPを上げる作業に「ついでの改善」を混ぜると、不具合が出たときに原因を切り分けられません。

一度に変えるのは一つ。システムの改善は、PHPのバージョンが上がってからです。

逆に言えば、最初の調査でこれらを確認すれば、見積もりの前提はかなりはっきりします。

調査の前は「いくらかかるか、どのくらいの期間でできるか、答えられない」が正直な答えです。

ただ、経営者の売上の不安や事業を一番に大切にしているため、分からないとはいえ極力ご協力できるようにしています。

よくある質問

Q1. 今の委託先のサーバーの契約期限まで1か月しかありません。

1か月で全部を移せるかは、システムの状態によります。正直、調査していない段階では約束できません。本当は協力したいのですが、その場合は先に、サーバー会社に「期限後はどうなるのか」「延長の有料オプションはあるか」を確かめてください。

セキュリティを考えて新しく移行させたいとお考えだと思います。同時にWAFやEDRを入れたり、入口を制限したりして守りを固めながら、移行の計画を立てます。ただ、WAFやEDRは古いPHPの弱点そのものを直すものではなく、あくまでも時間を稼ぐ補助です。

管理画面の問題の場合、ゼロトラストや端末認証で外から見えなくし、二段階認証で入口を固めることもできます。

Q2. PHP5から、いきなり8に上げられますか？

技術的には、7を経由せずに8へ上げられます。5から順番に上げる必要はありません。

ただし、PHP7.0とPHP8.0の両方の変更点をまとめて調査して作り直すことになるので、作業の量は増えます。そのため、見積もりも少しあがります。

AIやツールで一覧にして、検証環境で通しの業務を試す。そして、無停止で移行させる。手順は同じです。

我々はPHPのバージョンよりデータベースを全ての真実とします。そのため、同時に必要な場合を除き、古いデータベースを新しくするのではなく、そのまますべて受け止めます。そして、新しくしたあとにデータベースを変更します。

Q3. 作った会社に「対応できない」と断られました。

その会社が悪いわけではなく、古いPHPを直せる技術者が減っているのが実情です。あとはAIで行えるとしても、多くのユーザーが使う状態でシステムの移行や無停止を行うと、かなりヒリヒリします。

作った会社に対応ができないと言われたら、一度ご相談ください。

ワンシックスは、既存の開発会社の乗り換え先として、この調査を引き受けています。

我々がヒリヒリした話。

PHPを8へ上げる作業を実際に担当した開発チームが、やったことを書きました。案件が特定されないよう、細部は伏せています。

どんな状態だったか。

古いPHPフレームワークで作られたWebサービスを、PHP7系からPHP8.4へ上げました。フレームワークは開発が止まっていましたが、有志が保守をしているPHP8の対応版がありました。

なぜ行ったのか。

2026年10月21日にPHP2Shellの修正版が緊急公開され、早急な対応が必要になったため。

何をしたのか。

  • まず、フレームワークをそのPHP8に対応したバージョンに変えて、すべての部品（ライブラリ）もPHP8で動く形にした
  • PHP8.3と8.4の両方で試したが、サポート期間の長い8.4を選んだ
  • 旧版と新版の検証環境を並べて、同じ画面に同じ操作を送って、結果を突き合わせた
  • 金額の計算は、PHPのバージョン差で計算結果が変わっていないか確認するため、旧版との一致を全件確かめた
  • 直したコードは旧版でも動く書き方にそろえ、いつでも戻せるようにした
  • サーバーの中のミドルウェアやカーネル、他すべての設定がPHP8.4で問題がないのかを確認した
  • 暫定でできる防御を行い、管理画面をゼロトラスト化し、EDRを導入した状態で無停止準備にとりかかった

やってみて、分かったこと

新しいバージョンで、止まった箇所の多くは、削除された関数ではなく「想定外の値が届いたとき」の扱いでした。旧版では注意で済んでいた書き方が、PHP8では「それだめだよ」とエラーになり画面・動作が止まります。普段の操作では起きないため、わざと崩した値を送って確かめました。あと、PHP2Shellや昨今のサイバーセキュリティの事情が大きくかわっているため、PHPのバージョンをあげる以外にも、できる対応をすべて行い、その関わる部品もすべて、EOL（サポート切れ）ではない形に整えました。

今回の無停止は、ブルー・グリーンでもDNSの切り替えでもなく、別ドメインで旧版と新版を並走させる形で行いました。

ただ、2つサイトを用意するだけでは無停止にはなりません。データベースの互換性、ログイン、外部サービス、定期処理までを確認し、問題が起きた場合には旧版へ戻せるように準備を確認をしてから移行しました。

あと、EDRやWAFなどは旧版も新版も、すべて導入してから移行をしました。

再度ですが、難しい話は覚えなくて大丈夫です。売上を止められない、でもセキュリティはしっかりしたい、この事業と売上をとめられない恐怖は経営者にしか分かりません。止めればいいとなるからです。でも、止められない。
そのような経営者の方向けに書いています。バイクでいうとCBR、ホーク、CBX、すべて外観同じで設計思想も参考にするけど、中身だけ新品だよ。といった形を、走りながら繰り返します。

まとめ

PHP5のシステムも、PHP8へ移行できます。

ただし、PHPのバージョンを書き換えるだけでは動かなくなります。

削除された関数、静かに結果が変わる比較の規則、想定外の値で止まる処理を、道具と検証環境で先に洗い出すことが大切です。

移行先は8.4以上とおぼえておいてください。

検証環境で通しの業務を試し、わざと崩した値も入れ、戻る準備をしてから切り替える。

改善は混ぜず、一度に変えるのは一つ。この順番を守れば、業務を止めずに新しくできます。

「うちのシステム、どれくらい古いのか分からない」

その段階からで大丈夫です。

現在の構成を確認し、どのようになおして・どのように作り直すかをご案内します。

PHP5のままで良いという選択肢はありません。変えるの一択です。どう変えるのか、もしくは止めるのか。その判断のお手伝いをします。

古いシステムについて無料で相談する

古いPHPのまま、すでに不審なアクセスが心配な場合は、セキュリティの外部担当 BOUNCER でも入口の点検を承っています。

出典・参考資料

記載に間違いがないように、下記の出典・資料を参考にしています。

関連記事

記事一覧へ