PHP 8.2 のサポートは 2026 年 12 月 31 日に終わり、残りは約 2 か月です。PHP プロジェクトは、2026 年 10 月 21 日 (UTC) に公開した PHP 8.2.35 の告知で、「PHP 8.2 は 2026 年 12 月 31 日に EOL (サポート終了) を迎え、それ以降はセキュリティ修正を出さない」と書きました。同じ告知は、重大な脆弱性 php2shell (CVE-2026-109618・CVE-2026-109619) を直した修正版の案内でもあり、サポートされている版への更新を計画するよう求めています。
PHP で動く会員サイトや予約システム、EC サイトを外部の制作会社や保守会社に任せていると、「期限は保守会社が見ているはず」と考えがちです。ただ、保守契約がない、契約の範囲に版の更新が入っていない、保守会社と連絡が取れない、といった事情で、誰も期限を見ていないこともあります。
この記事では、保守を外部に任せている担当者に向けて、公式のサポート期限、期限後に止まるもの、保守会社に聞くこと、見積もりの見方、保守会社が対応しないときの進め方を整理します。脆弱性の中身とサーバー上での確認方法は php2shell (CVE-2026-109618) 対応 に、EOL を迎えたシステム全般の選択肢は EOL・サポート終了への対応 にまとめています。
PHP 8.2 のサポートは 2026 年 12 月 31 日に終わる
PHP 8.2 から 8.5 のサポート期限
PHP の各系統は、最初の安定版から 2 年間のアクティブサポート (バグとセキュリティの修正) と、その後 2 年間のセキュリティサポート (重大なセキュリティ問題の修正だけ) を受けます。8.2・8.3 のような番号を系統と呼び、8.2.35 の末尾の番号は、同じ系統の中で出る修正版を表します。2026 年 10 月時点で公式がサポートしているのは、8.2〜8.5 の 4 系統です。
| 系統 | 公開日 | アクティブサポートの期限 | セキュリティサポートの期限 |
|---|---|---|---|
| 8.2 | 2022 年 12 月 8 日 | 2024 年 12 月 31 日 | 2026 年 12 月 31 日 |
| 8.3 | 2023 年 11 月 23 日 | 2025 年 12 月 31 日 | 2027 年 12 月 31 日 |
| 8.4 | 2024 年 11 月 21 日 | 2026 年 12 月 31 日 | 2028 年 12 月 31 日 |
| 8.5 | 2025 年 11 月 20 日 | 2027 年 12 月 31 日 | 2029 年 12 月 31 日 |
表は php.net の Supported Versions から転記しました (2026 年 10 月 23 日に確認)。
期限を過ぎてもサイトは止まらない。出なくなるのは公式の修正版
12 月 31 日を過ぎても、PHP 8.2 で動くサイトがその日に止まるわけではありません。止まるのは、PHP プロジェクトからの修正の提供です。php.net は、サポートを終えた系統の利用者は修正されていない脆弱性にさらされるおそれがあるとして、できるだけ早く更新するよう求めています。
問題になるのは、2027 年以降に重大な脆弱性が見つかったときです。php2shell は認証なしでリモートからコードを実行されうる脆弱性でしたが、8.2 には 8.2.35 という修正版が出ました。同じ規模の脆弱性が年明けに見つかっても、8.2 向けの修正版は公式からは出ません。
FIXIT動いているうちは、放っておいてもいい？
Shiori放っておけるのは、次の脆弱性が見つかるまでです。いつ見つかるかは選べません。
8.1 以前はすでにサポートの外
8.1 以前の系統は、すでに公式サポートを終えています。php.net の Unsupported Branches によると、終了日と最終版は次のとおりです。
| 系統 | サポート終了日 | 最終版 |
|---|---|---|
| 8.1 | 2025 年 12 月 31 日 | 8.1.34 |
| 8.0 | 2023 年 11 月 26 日 | 8.0.30 |
| 7.4 | 2022 年 11 月 28 日 | 7.4.33 |
| 7.3 | 2021 年 12 月 6 日 | 7.3.33 |
php2shell で通常の修正版が出たのは、8.2〜8.5 だけでした。7.4・8.0・8.1 にも、深刻さを踏まえて最小限の修正が例外的に公開されましたが、通常の修正版ではありません。次の脆弱性で同じ対応がある保証もありません。8.1 以前で動いているシステムは、8.2 より先に手当てが必要です。
まず、自社のシステムがどの PHP で動いているかを確認する
発注側の担当者が、自分でサーバーに入って調べる必要はありません。保守会社に次の 5 つを聞けば、状況が分かります。
保守会社に聞く 5 つの質問
- 本番の Web サイトを処理している PHP のバージョンは何か (8.2.35 のように、末尾の番号まで)
- 使っているフレームワーク (システムの土台になる部品の集まり。Laravel など) や CMS (WordPress・EC-CUBE などのサイト管理の仕組み) と、その版は何か
- サーバーは何で (レンタルサーバー・VPS・クラウドなど)、PHP の更新は誰が担当しているか
- 12 月 31 日までに、どの版へ、いつ上げる計画か。見積もりはいつ出せるか
- その作業は、いまの保守契約の範囲に入るか
保守会社には、本番の Web サイトで実際に使われている版を答えてもらってください。確認の観点は php2shell の記事の確認手順 にまとめています。
回答は「どのシステムが・どのサーバーで・どの版で・誰が・いつまでに上げるか」の表にして、社内に残してください。年明けに脆弱性が報じられたときも、どこから手を付けるかをすぐに説明できます。
要点
回答が返ってこない、「確認します」のまま進まない場合は、それ自体が判断材料です。PHP の期限を見ている人が、社内にも保守会社にもいない状態かもしれません。そのときの進め方は、この記事の後半で扱います。
レンタルサーバーやクラウドでは、修正の出どころが違う
PHP をレンタルサーバーやクラウドのサービスで使っている場合、修正を出すのはその提供元です。
そのため、8.2 をいつまで使えるかも提供元ごとに変わります。レンタルサーバーの管理画面で 8.2 を選べることと、8.2 に修正が届き続けることは別の話です。8.2 の提供をいつまで続けるか、修正をいつまで出すかを、提供元の告知で確認してください。提供元の期限が php.net より後でも、次の章で扱うフレームワーク側のサポートが先に切れることがあります。
8.3・8.4・8.5 から移行先を選ぶ
移行先の候補は 3 つで、セキュリティサポートの期限は 8.3 が 2027 年 12 月 31 日、8.4 が 2028 年 12 月 31 日、8.5 が 2029 年 12 月 31 日です。
8.3 に上げると、1 年後に同じ作業がもう一度要ります。期限だけを見れば 8.5 がいちばん長く使えますが、上げられる上限を決めるのは PHP ではなく、その上で動くフレームワークや CMS、プラグインです。
判断は、まずフレームワークや CMS が対応している上限を確かめ、その範囲で期限の長い版を選ぶ順に進めます。次の章で、よく使われる 3 つの対応状況を見ます。
フレームワークや CMS の対応状況
Laravel
Laravel は、版ごとに対応する PHP とフレームワークの修正期限を公開しています (Laravel のリリースノートの Support Policy)。各版のバグ修正は 18 か月、セキュリティ修正は 2 年です。
| Laravel | 対応する PHP | セキュリティ修正の期限 |
|---|---|---|
| 10 | 8.1〜8.3 | 2025 年 2 月 4 日 (終了) |
| 11 | 8.2〜8.4 | 2026 年 3 月 12 日 (終了) |
| 12 | 8.2〜8.5 | 2027 年 2 月 24 日 |
| 13 | 8.3〜8.5 | 2028 年 3 月 17 日 |
Laravel 10・11 は、フレームワークのセキュリティ修正がすでに終わっています。Laravel 11 は PHP 8.4 でも動きますが、フレームワーク側の修正は出ないため、PHP と一緒に Laravel の版も上げる計画になります。Laravel 12 も 2027 年 2 月 24 日に修正が終わるので、いまから上げるなら 13 が候補です。13 は PHP 8.2 に対応していないため、PHP を 8.3 以上へ上げることが前提になります。
WordPress
WordPress の推奨は PHP 8.3 以上です (WordPress の動作環境)。ただし、本体の版ごとに対応する PHP の範囲が決まっています (PHP Compatibility and WordPress Versions)。
本体が 6.9 以降なら PHP 8.5 まで、6.7・6.8 なら 8.4 まで対応しています。6.6 以前のままだと、PHP は 8.3 までしか上げられません。テーマとプラグインは本体の対応範囲とは別で、1 つずつ対応を見る必要があります。開発が止まったプラグインを使っている場合は、そのプラグインの置き換えも作業に入ります。
EC-CUBE
EC 事業者にとって影響が大きいのが EC-CUBE です。EC-CUBE 4 のシステム要件 では、対応する PHP は次のとおりです。
| EC-CUBE | 対応する PHP |
|---|---|
| 4.3 | 8.1〜8.3 |
| 4.2 | 7.4〜8.1 |
| 4.0・4.1 | 7.3〜7.4 |
最新の安定版である 4.3 でも、対応は PHP 8.3 までです。4.2 以前で動いているサイトは、PHP より先に EC-CUBE 本体を 4.3 へ上げる作業が要ります。4.2 が対応する上限の 8.1 は、すでにサポートを終えています。
PHP 8.2〜8.5 に対応した 4.4 は、2026 年 9 月に alpha 版 が出た段階です。4.3 と PHP 8.3 の組み合わせで動かす場合は、8.3 の期限が 2027 年 12 月 31 日なので、1 年後にもう一度更新する前提で計画します。
PHP を上げるとエラーになりやすい書き方
php.net の移行ガイド (8.3・8.4・8.5) には、版ごとの非互換と非推奨がまとまっています。発注者が細部を覚える必要はありませんが、見積もりに「影響調査」が入る理由は知っておくと話が早くなります。
非推奨の書き方は、すぐにエラーになるわけではなく、警告が出るようになります。一方、エラーコードで再接続を判断している処理などは、非互換の変更でそのままでは期待どおりに動かない場合があります。どこに影響が出るかは、コードを調べないと分かりません。
バージョンアップの費用と期間は、何で変わるか
この記事では金額の相場を示しません。公的な統計がなく、同じ「PHP の更新」でもシステムごとに作業量が大きく違うためです。代わりに、見積もりを読むための見方を示します。
費用が変わる 5 つの要因
| 要因 | 作業が増える状態 |
|---|---|
| 版の差 | 8.2 から 8.5 のように、またぐ版が多い |
| フレームワーク・CMS の版上げ | Laravel 11 以前や EC-CUBE 4.2 以前のように、本体の更新が先に要る |
| 自動テストの有無 | 自動テストがなく、動作確認を人の手で 1 画面ずつ行う |
| 外部連携 | 決済・配送・基幹システムなどとの連携があり、連携先との確認が要る |
| 検証環境 | 本番と同じ構成の検証環境がなく、作るところから始まる |
期間も同じ要因で変わります。見積もりを受け取ったら、この 5 つをどう見込んでいるかを保守会社に聞くと、12 月 31 日に間に合う計画かを判断しやすくなります。
見積もりに入っているべき作業
- 現状調査 (PHP・フレームワーク・ライブラリの版、サーバーの構成)
- 影響範囲の洗い出し (移行ガイドの変更点と、依存ライブラリの対応状況)
- 検証環境の用意
- コードの修正
- 動作確認 (業務の流れに沿った確認を含む)
- 本番の切り替えと、問題が出たときに元へ戻す手順の準備
見積もりが「PHP バージョンアップ一式」の 1 行なら、この 6 段階に分けてもらってください。どこまでが調査で、どこからが修正かが分かれば、金額を工程ごとに比べられます。6 の戻す手順が入っていない見積もりでは、切り替えで問題が出たときの対応が決まっていないことになります。
バージョンアップは保守契約に入っているか
システム保守費用の相場と根拠 の区分では、OS やライブラリの更新への追随を「保守」、新機能の追加や大幅な改修を「追加開発」の例として挙げています。PHP の更新はその中間にあたります。同じ系統の修正版の適用 (8.2.34 から 8.2.35 など) と、系統をまたぐ更新 (8.2 から 8.4 など) とでは、コードの修正量が違います。系統をまたぐ更新は、保守の範囲外として別に見積もられることがあります。
契約書の保守の範囲に「ミドルウェアのバージョンアップ」「脆弱性対応」などがどう書かれているかを確認してください。書かれていなければ、範囲内か範囲外かを保守会社に文書で回答してもらいます。
保守会社が対応しない・連絡が取れないとき
5 つの質問を送っても答えが返ってこない、「古いので対応できない」と言われた、見積もりに納得できない。こうした場合も、最初から乗り換えを決める必要はありません。順に手を打てます。
まず、断られた理由と、できる範囲を聞く
「対応できない」の中身は、いくつかに分かれます。フレームワークが古く、PHP を上げるには作り直しに近い作業が要るのか。保守会社にその技術の担当者がいないのか。年内に手が空かないだけなのか。理由によって、次の手が変わります。
時期だけの問題なら、外部からアクセスできる範囲を絞るなどの暫定策を一緒に決め、着手の時期を約束してもらう選択肢もあります。見積もりに納得できない場合は、前の章の 6 段階に分けた内訳を求め、それでも判断できなければ、同じ条件で他社にも見積もりを依頼して比べます。
連絡が取れない・終了を告げられたら、先に資産を確保する
保守会社と連絡が取れない、保守の終了を告げられた。そうした場合は、PHP の更新より先に、ソースコード、サーバーとドメインの管理権限、データベース、外部サービスのアカウントを手元に確保します。これらがないと、ほかの会社は PHP の版を調べることもできません。確保すべきものと、契約書で確認する条項は システム引き継ぎの進め方 で整理しています。
保守だけを他社に移す
システムが業務に合っていて、フレームワークの版を上げれば新しい PHP に対応できるなら、作り直さずに保守だけを他社へ移せます。引き継ぎ先は見積もりの前に現状調査を行い、PHP の更新にどれだけの作業が要るかを確かめます。旧保守会社と並行期間を置いて切り替える進め方は、システム保守の引き継ぎ にまとめています。
FIXIT保守会社に断られたら、もう作り直すしかないの？
Shiori分かれ目はフレームワークの版です。上げれば新しい PHP に対応できるなら、保守を移して更新できます。
FIXIT引き継ぎ先って、何から始めるの？
Shioriお手元のコードと権限の確認からです。両方がそろえば、更新の作業量を見積もれます。
いまの保守会社との契約が残っているうちに次の担い手を探したい場合は、開発会社の乗り換え・システム引き継ぎ で、30 分の無料診断からご相談いただけます。
12 月 31 日に間に合わないときの優先順位
期限まで約 2 か月です。対象のシステムが複数ある、年内に作業の枠が取れないなどの理由で、すべてを間に合わせられないこともあります。その場合は、次の順で手を打ちます。
- 外部に公開しているシステムから上げます。会員サイトや EC サイトのように、誰でも到達できるものを先にします
- 社内向けのシステムは、アクセスできる範囲を絞ります。VPN や IP アドレスの制限で、インターネットから直接届かないようにします
- 上げる日付を決めて、社内に記録を残します。暫定策は、いつまで使うかを決めてから入れます
WAF (不正な通信を手前で遮断する仕組み) やアクセス制限は、更新までの時間を稼ぐ手段です。php.net は php2shell の告知で、完全な緩和策はなく、更新が唯一の安全な選択だと書いています。暫定策を入れるときは、更新の日付も同時に決めてください。
PHP 7 系以前で動いている、フレームワークが何世代も前のまま、といったシステムでは、PHP を上げる作業が作り直しに近くなることがあります。その場合は、更新と作り直しの両方の見積もりを並べて比べます。延命・部分移行・全面刷新の判断軸は EOL・サポート終了への対応 で、作り直しの進め方は システム刷新・リプレイス で紹介しています。
FIXIT の進め方 — PHP の更新は、現状調査で作業量を確認してから決める
FIXIT は AI 駆動開発のクリエイティブスタジオとして、他社が作ったシステムの保守の引き継ぎや、古いシステムの作り直しをお受けしています。PHP の期限に関わる相談では、いきなり更新の作業に入らず、まずコード・サーバー・フレームワークの版を調べ、更新にどれだけの作業が要るかを見極めます。
調査では、コードの読み解きや依存ライブラリの洗い出しに AI を使い、影響を受けそうな箇所を早く絞り込みます。そのうえで、保守を引き継いで更新する場合と作り直す場合を並べ、どちらが妥当かをお伝えします。現状調査だけを切り出してご依頼いただくこともできます。
まとめ
PHP 8.2 のセキュリティサポートは 2026 年 12 月 31 日に終わり、2027 年 1 月 1 日以降は 8.2 向けの修正が公式から出ません。サイトはその日に止まりませんが、次の重大な脆弱性に修正が出ない状態になります。
最初にやることは、保守会社に 5 つの質問を送り、どのシステムがどの版で動き、誰がいつまでに上げるのかを表にすることです。上げる先の上限は Laravel・WordPress・EC-CUBE などの対応範囲で決まり、費用は版の差、本体の版上げ、自動テスト、外部連携、検証環境で変わります。回答が来ない、対応を断られた場合は、資産の確保と現状調査から始めてください。PHP の期限への対応を誰に頼むかで迷っている場合は、お問い合わせ から現状をお聞かせください。