PHP 8.2 サポート終了（2026年12月31日）に制作会社がやること｜顧客への案内の順番と、年内に間に合わない案件の扱い【2026年版】
この記事は、PHP 8.2 サポート終了（2026年12月31日）を前に、制作会社が残り8週間で何を、どの順番でやるかを扱います。
結論から書きます。PHP 8.2 のセキュリティ修正は2026年12月31日で終わるため、今やることは「全件を年内に上げる」ことではなく、台帳で対象を洗い出し、危険の大きいサイトから案内し、間に合わない案件は「調査だけ年内、切り替えは年明け」と書面で合意することです。
全件を同時に追いかけると、どれも中途半端なまま年を越します。
PHP 8.2 のサポート期限は、いつまでか
php.net の Supported Versions のページで確かめた日付です（php.net、2026年11月5日確認）。
バージョン 初回リリース 通常サポート終了 セキュリティ修正の終了
PHP 8.2 2022年12月8日 2024年12月31日 2026年12月31日
PHP 8.3 2023年11月23日 2025年12月31日 2027年12月31日
PHP 8.4 2024年11月21日 2026年12月31日 2028年12月31日
PHP 8.5 2025年11月20日 2027年12月31日 2029年12月31日同じページでは、各バージョンは公開から2年の通常サポートと、その後2年のセキュリティ修正だけのサポートを受け、4年で終わる（EOL）と説明されています。
PHP 8.2 は、すでに通常サポートを終え、残っているのはセキュリティ修正だけです。それも、あと8週間ほどで終わります。
サポート終了とは何か、顧客にどう説明するかは、別の記事で扱っています。
▶ PHPのサポート終了を、顧客にどう説明するか──php.netで確かめた各バージョンの終了時期と、煽らずに伝える説明文の型
PHP 8.2 サポート終了への対応とは、残りの時間で「全件」ではなく「順番」を決める仕事である
黒字化の外科医です。PHP 8.2 サポート終了の直前に、制作会社が手を付ける順番を解剖します。
順番が先に要る理由は、三つあります。
第一に、残りの時間が、社内の手の数より短いから。
年末は、年末年始の休業準備や、駆け込みの改修も重なります。全件を年内に終える前提で動くと、どの案件も検証が浅くなります。
第二に、サイトによって、止まったときの痛みが違うから。
問い合わせフォーム、会員、決済のあるサイトと、情報を載せているだけのサイトでは、守る優先度が違います。
第三に、上げる先のバージョンが、CMSによって変わるから。
EC-CUBE 公式ドキュメントのシステム要件では、EC-CUBE 4.3 の対応PHPは 8.1〜8.3 です（EC-CUBE公式ドキュメント、2026年11月5日確認）。一方、WordPress の Hosting Team のハンドブックでは、WordPress 7.1 は PHP 8.2〜8.5 にも対応し、新規の環境には 8.4 か 8.5 を勧めています（make.wordpress.org、2026年11月5日確認）。一律に「8.4へ」とは言えないのです。
今すぐ試せる：PHP 8.2 のサイトを年内対応と年明け対応に分けるプロンプト
私はWeb制作会社の経営者です。PHP 8.2 で動いている保守先サイトを、年内に対応するものと、年明けに回すものに分けてください。
【前提】
・サイトの一覧（顧客名、CMSとバージョン、フォーム・会員・決済の有無、独自プログラムの量）：〔記載〕
・各サイトの対応の見込み時間（調査・検証・本番）：〔記載〕
・12月末までに社内で使える時間の合計：〔記載〕
・PHP 8.2 のセキュリティ修正の終了日：2026年12月31日（php.netで確認済み）
1. 決済・会員・フォームのあるサイトを上位にする。
2. 上位から順に、使える時間に収まるところまでを「年内」とする。
3. 収まらないサイトを「年明け」とし、年内にやる調査だけを書く。
4. サイトごとに、上げる先のPHPのバージョンの候補を、CMSの公式の動作環境で確かめる項目として示す。
私が記載していない日付や対応バージョンは、推測で書かないこと。結果は表で示すこと。PHP サポート期限の対応工場：8週間の進め方
1. 年内に回せる件数の計算（例）
PHP 8.2 で動いているサイト：12件（例）
1件あたりの対応時間：20時間（例：調査・検証・修正・本番）
必要な時間：12件 × 20時間 ＝ 240時間
12月末までに使える時間：週25時間 × 8週 ＝ 200時間（例）
足りない時間：240時間 − 200時間 ＝ 40時間
年明けに回す件数：40時間 ÷ 20時間 ＝ 2件数字はすべて例です。足りない分を残業で埋める計画は、検証を削る計画と同じ意味になります。
2. 案内の順番（週ごと）
第1週：台帳から PHP 8.2 のサイトを抜き出す（サーバーの管理画面で実際の値を確認）
第1週：決済・会員・フォームの有無で、優先度をA・B・Cに分ける
第2週：優先度Aの顧客へ、案内と見積もりを送る
第3週：優先度B・Cの顧客へ、案内を送る（年明けの枠も提示）
第3〜7週：返事の来た順に、検証環境で確認 → 本番の切り替え
第8週：切り替えの止め時。年内最後の本番作業は、休業の数日前までに年内最後の本番作業を、休業の直前に置かないことが大切です。切り替えた翌日に不具合が出ても、対応できる日を残します。
3. 年内に間に合わない案件の扱い
□ 年内に「調査」だけは終える（修正の量と、上げる先のバージョンを確定）
□ 年明けの切り替えの予定日を、顧客と決める
□ その間はセキュリティ修正のないPHPで動くことを、書面で伝える
□ サーバー事業者に延長の扱いがあるかを、公式の案内で確かめて伝える
□ 顧客の返事（了承・見送り）を、日付とともに記録する最後の記録が、あとで「聞いていない」と言われないための備えです。
なお私は弁護士ではありません。実務の指針として読み、個別の判断は専門家や公的な窓口に確認してください。
4. 上げる先のバージョンの選び方
WordPress のサイト
→ 使っているWordPressのバージョンとプラグインの対応を確認し、8.3か8.4を候補に
EC-CUBE 4.3 のサイト
→ 公式のシステム要件はPHP 8.1〜8.3。8.3が候補
EC-CUBE 4.2 以前のサイト
→ 公式のシステム要件で4.2はPHP 7.4〜8.1。本体の更新から考える
独自のPHPのサイト
→ php.net の移行ガイドで、非推奨と互換性のない変更を確認工程ごとの確かめ方は、PHP 8.3・8.4への移行手順にまとめました。
EC-CUBE の本体をどうするかは、EC-CUBE 4.3へのバージョンアップ判断で扱っています。
費用の出し方は、こちらの記事が土台です。
▶ PHPバージョンアップの費用は「相場」ではなく工数で出す──調査・検証環境・本番の工程別の見積もりと、時間単価×工数の計算例
構造的なリスク
逆説を指摘しておきます。
期限が迫ると、制作会社は「年内に全部やります」と言いたくなります。
けれど、間に合わせることを優先した切り替えは、確認の抜けを生み、年明けの障害対応に化けます。
期限は、開発元が公表した事実です。焦りを売り込みに使わず、「いつ、何を、どこまで」を正直に伝えた会社のほうが、年明けの工事も任されます。
PHPだけでなく、データベースやOSの期限もまとめて追う台帳は、別の記事で扱っています。
▶ EOLのソフトウェア管理、PHPだけ見ていないか──PHP・DB・OS・CMS・ライブラリのサポート終了を棚卸しし、1枚の台帳で追う
よくあるQ&A
Q. PHP 8.2 のサポート終了はいつ？
php.net の表示では、セキュリティ修正の終了は2026年12月31日です（php.net、2026年11月5日確認）。通常のサポートは、2024年12月31日にすでに終わっています。
Q. 2027年1月1日に、サイトは止まる？
止まるわけではありません。変わるのは、その後に見つかった脆弱性の修正が出なくなることです。ただし、サーバー事業者が古いPHPの提供を終える場合は、事業者の告知の日程で切り替わることがあります。
Q. PHP 8.3 と 8.4、どちらに上げるべき？
CMSの公式の動作環境で決めます。EC-CUBE 4.3 なら公式の要件は8.3までです。WordPressで8.4以上を選べるなら、セキュリティ修正の期限が2028年12月31日まで延びます。
Q. 年内に間に合わない顧客には、何を送ればいい？
年内の調査の結果、年明けの予定日、それまでの間に修正が出ないこと、の3点を書いたメールです。文例は、期限対応の顧客案内キットにまとめています。
最後に
PHP 8.2 のサポート終了は、2026年12月31日です。
残りの時間で全件を追わず、危険の大きい順に並べ、間に合わない案件を書面で年明けに送った会社だけが、期限を事故ではなく工事の予定に変えられるのです。
これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。
#Web制作会社 #PHP #サポート終了 #PHPサポート期限 #PHPEOL #PHPバージョンアップ #制作会社経営 #中小企業 #サイト保守 #セキュリティ
