PHP 8.3・8.4への移行手順｜WordPress・EC-CUBE・独自PHPで確認する項目と、検証の進め方【2026年版】
この記事は、PHP 8.3・8.4への移行手順を、WordPress・EC-CUBE・独自PHPの3種類に分けて、何をどの順で確かめるかを扱います。
結論から書きます。PHP バージョンアップの手順は「上げる先をCMSの公式の動作環境で決める→検証環境で非推奨の警告を集める→画面の確認表で旧と新を比べる→戻し方を用意して本番へ」の4段で、3種類のサイトで違うのは、最初の「上げる先の決め方」と、二つ目の「警告の出どころ」だけです。
ここを分けずに同じ手順で進めると、EC-CUBEを公式の要件にないバージョンへ上げてしまう、といった事故が起きます。
PHP バージョンアップの手順とは、互換性を「調べる順番」を固定することである
黒字化の外科医です。PHP 8.3・8.4への移行を、サイトの種類ごとに迷わず進める手順を解剖します。
調べる順番を固定すべき理由は、三つあります。
第一に、上げられる上限を決めるのは、PHPではなくCMSだから。
PHPに新しい版が出ていても、CMSの公式の動作環境に載っていなければ、動作は保証されません。
第二に、新しいPHPで壊れる箇所は、警告として先に現れるから。
php.net の移行ガイドには、各バージョンの「互換性のない変更」と「非推奨になった機能」が章ごとにまとまっています。非推奨の警告は、次の版でエラーになる候補の一覧です。
第三に、確認する画面を決めておかないと、検証が人の記憶に頼るから。
ベテランが頭の中で見ている画面を、表にして残します。
PHP 8.2 の期限が迫っている場合の、全体の進め方は、PHP 8.2 サポート終了に制作会社がやることにまとめています。
上げる先の決め方：WordPress・EC-CUBE・独自PHPのPHP互換性
一次情報で確かめた範囲です。
PHP の期限（php.net、2026年11月5日確認）
PHP 8.3：セキュリティ修正の終了 2027年12月31日
PHP 8.4：通常サポート終了 2026年12月31日／セキュリティ修正の終了 2028年12月31日
WordPress（make.wordpress.org Hosting Team ハンドブック、2026年11月5日確認）
WordPress 7.1（2026年8月19日公開）は PHP 7.4〜8.5 に対応
新規の環境には PHP 8.4 か 8.5 を推奨
WordPress.org の動作環境のページでは PHP 8.3 以上を推奨
EC-CUBE（EC-CUBE公式ドキュメント システム要件、2026年11月5日確認）
EC-CUBE 4.3：PHP 8.1〜8.3
EC-CUBE 4.2：PHP 7.4〜8.1ここから分かることは、二つです。
WordPress は本体を新しくしておけば、8.4まで上げる選択肢があります。EC-CUBE 4.3 は、公式の要件が 8.3 までです。
なお、GitHub の EC-CUBE のリリースページには、PHP 8.2〜8.5 対応をうたう 4.4.0 のアルファ版が公開されています（2026年11月5日確認）。アルファ版は本番の前提にせず、正式版と公式の要件の更新を待ちます。
今すぐ試せる：非推奨の警告を、直す順に並べるプロンプト
私はWeb制作会社のエンジニアです。検証環境で新しいPHPに切り替えたときのエラーログを貼ります。直す順番に整理してください。
【前提】
・今のPHPと、上げる先のPHP：〔例：8.2 → 8.4〕
・サイトの種類：〔WordPress／EC-CUBE／独自PHP〕
・ログ：〔貼り付け〕
1. 致命的なエラー、警告、非推奨（Deprecated）に分ける。
2. それぞれ、出どころ（本体、テーマ、プラグイン、独自のコード）を分ける。
3. 本体やプラグインが出どころのものは「更新で直る可能性」として分け、自社で直す箇所と混ぜない。
4. 自社で直す箇所に、修正の方針を一行で書く。
php.net の移行ガイドで確かめるべき項目には「要確認」と書き、推測で断定しないこと。PHP 移行手順工場：4段の進め方と、サイト別の確認項目
1. 共通の4段
① 上げる先を決める
CMSの公式の動作環境と、サーバーで選べるPHPを照合する
② 検証環境で警告を集める
本番のコピーを新しいPHPで動かし、エラーログを数日分ためる
③ 画面の確認表で比べる
旧PHPと新PHPで、同じ操作をして結果を記録する
④ 戻し方を用意して本番へ
ファイルとデータベースのバックアップ、旧PHPに戻す手順と、戻せない場合の手段2. WordPress で確認する項目
□ WordPress 本体を、先に新しい版へ上げたか
□ テーマとプラグインごとに、提供元が新しいPHPへの対応を示しているか
□ 最終更新が古いプラグインを、入れ替え候補として一覧にしたか
□ 管理画面のログイン、投稿の保存、メディアの追加を確かめたか
□ フォームの送信と、届いたメールを確かめたかプラグインの棚卸しの考え方は、こちらで扱っています。
▶ WordPress プラグイン 脆弱性の対応が追いつかない制作会社へ──入れる前の選定基準と、入れたあとの棚卸しで守る対象を減らす
3. EC-CUBE で確認する項目
□ 本体のバージョンが、上げる先のPHPを公式の要件に含むか
（4.2のままなら PHP 8.1 まで。8.2以上には本体の更新が先）
□ 入れているプラグインが、本体とPHPの両方に対応しているか
□ カート、注文完了、決済、会員登録、管理画面の受注一覧を確かめたか
□ 注文メールと、管理者への通知メールを確かめたか4. 独自PHPで確認する項目
□ php.net の移行ガイド（互換性のない変更・非推奨の機能）を、上げる幅の分だけ読んだか
（8.2 → 8.4 なら、8.3 と 8.4 の2つ）
□ 8.4 で非推奨になった「暗黙の null 許容の引数」（型付き引数の初期値が null）を検索したか
□ 8.4 で非推奨になった trigger_error() の E_USER_ERROR 指定を検索したか
□ Composer の依存ライブラリが、新しいPHPに対応した版になっているか8.4 の非推奨の2項目は、php.net の移行ガイドの「Deprecated Features」で確かめた内容です（php.net、2026年11月5日確認）。
5. 画面の確認表の数え方（例）
主要な画面と操作：20項目（例）
比べる環境：旧PHP と 新PHP の2つ
確認の回数：20項目 × 2環境 ＝ 40回
1回あたり：6分（例）
確認の時間：40回 × 6分 ＝ 240分 ＝ 4時間この4時間を見積もりから削ると、検証は「動いたように見えた」で終わります。工程ごとの費用の出し方は、こちらの記事に任せます。
▶ PHPバージョンアップの費用は「相場」ではなく工数で出す──調査・検証環境・本番の工程別の見積もりと、時間単価×工数の計算例
構造的なリスク
逆説を指摘しておきます。
手順を固定するほど、「手順どおりにやったから大丈夫」という油断が生まれます。
確認表にない画面、たとえば月に一度しか動かない定期処理や、CSVの書き出しは、表から漏れやすいのです。
だから、確認表は案件ごとに顧客に見せ、「普段使っていて、ここにない操作はありますか」と一度だけ聞きます。その答えが、表を育てます。
同じ系列の中での小さな更新（末尾の数字を上げる更新）は、別の記事で扱っています。
▶ PHPのパッチは「8.3のまま、末尾の数字を上げる」更新──同じ系列のセキュリティ修正の当て方と頻度、レンタルサーバーとVPSで違う責任の線
よくあるQ&A
Q. PHP 8.3 と 8.4、どちらに移行すべき？
CMSの公式の動作環境に載っている中で、期限の長い方を選びます。EC-CUBE 4.3 は公式の要件が 8.3 までです。
Q. 8.2 から 8.4 へ、一気に上げてもいい？
上げられます。ただし、php.net の移行ガイドは 8.3 と 8.4 の両方を読み、両方の非推奨を確かめます。
Q. 検証環境は必ず必要？
必要です。本番で警告を集めると、顧客の画面で不具合が起きます。検証環境を標準にする考え方は、ステージング環境の記事で扱っています。
Q. 戻せないサーバーの場合はどうする？
サーバーによっては、上げたPHPを元に戻せない場合があります。ファイルとデータベースのバックアップから、別の環境に戻せる手順を先に確かめます。
最後に
PHP 8.3・8.4への移行は、どのサイトも4段で進み、違うのは上げる先の決め方と、警告の出どころだけです。
CMSの公式の動作環境で上限を決め、警告を集め、画面の確認表で比べた会社だけが、バージョンアップを「上げてみたら壊れた」ではなく、予定どおりの工事にできるのです。
これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。
#Web制作会社 #PHPバージョンアップ #PHPバージョンアップ手順 #PHP互換性 #PHP移行 #WordPress #制作会社経営 #中小企業 #ECCUBE #サイト保守
