レンタルサーバーからこんな案内が来たことはありませんか？

• 「古いPHPは提供終了のため、PHP8.xへ切り替えてください」
• 「セキュリティのため、PHPのバージョンを引き上げます」
• 「PHP7.xは近日中に利用できなくなります」

ECサイト運営者にとって怖いのは、“PHPだけ上がってEC-CUBEが動かなくなる”パターンです。特に EC-CUBE 2系／3系は、PHP8系と噛み合わず、管理画面や購入フローが突然停止するリスクがあります。

この記事では、レンタルサーバーのPHP更新をきっかけに、EC-CUBE本体をどう更新（延命／移行）すべきかを、2系／3系別に現実的な手順で解説します。

まず結論：PHP更新は「EC-CUBE更新の合図」

PHPはメジャーバージョンアップで仕様変更が入り、今まで“警告”だったものが“致命的エラー”になることがあります。結果として、

• 管理画面が白画面（500）
• カート投入・決済だけエラー
• メール送信や外部連携が落ちる
• プラグインが動かない

が起きやすいです。

本番で起きてから対応すると、原因切り分けが難しく、売上機会の損失にも直結します。
なので、サーバー側のPHP更新通知が来た段階で、EC-CUBE側も計画的に更新するのが最も安全です。

EC-CUBEの世代ごとに「対応PHP」が違う（ここが最重要）

まずは、公式のシステム要件を基準に判断します。

EC-CUBE 4.3（現行の主力）

EC-CUBE 4.3の要件は PHP 8.1〜8.3、DBは MySQL 8.0〜8.4 などが示されています。 EC-CUBE 4 開発者向けドキュメントサイト

EC-CUBE 3系

EC-CUBE 3.0系の要件は PHP 5.3.9〜7.1.x です。 EC-CUBE 開発ドキュメント
つまり、レンタルサーバーがPHP8へ上がると、3系は公式要件外になりやすいです。

EC-CUBE 2系（2.25.0）

EC-CUBE 2.25.0は公式ニュースで PHP 8.4対応が明記されています。 EC-CUBE
2系を“延命”したい場合の強い選択肢になります（ただし後述の注意点あり）。

PHPのサポート期限（EOL）も、更新判断の材料になる

「古いPHPを使い続ける」こと自体が、セキュリティ上の負債になります。PHP公式のSupported Versionsでは、たとえば 8.3はActive Supportが2025-12-31まで、Security Supportは継続、といった形で期限が整理されています。 PHP
（今日は 2026年1月6日なので、8.3はつい先日“Active Support終了”の扱いです）

レンタルサーバーがPHPを上げる背景には、こうしたサポート期限対応があります。
EC-CUBE側も足並みを揃えるのが、運用として正解になりやすいです。

ここから分岐：あなたのEC-CUBEは2系？3系？（対応方針）

以下のどちらかで読み進めてください。

• A：EC-CUBE 3系の方 → 「3系はPHP8と基本的に噛み合わない」ので“移行前提”が多い
• B：EC-CUBE 2系の方 → 「2.25でPHP8.4対応」なので“延命”か“移行”を選べる

A：EC-CUBE 3系の方（おすすめは4系へ移行）

なぜ3系は危険なのか

EC-CUBE 3系は公式要件がPHP 7.1.xまでです。 EC-CUBE 開発ドキュメント
レンタルサーバーがPHP8へ切り替わると、以下が起こりやすくなります。

• 管理画面がエラー（ログイン不可）
• プラグインが互換性NGで致命的エラー
• PHPの厳格化でテンプレートや独自改修が落ちる

3系ユーザーの現実的な選択肢

選択肢A-1：EC-CUBE 4.3へ移行（推奨になりやすい）

• 4.3はPHP 8.1〜8.3が要件 EC-CUBE 4 開発者向けドキュメントサイト
• 今後のセキュリティ運用の観点でも整合しやすい

注意：レンタルサーバーが「PHP8.4へ強制」タイプの場合、4.3の要件は8.1〜8.3なので、必ず事前検証が必要です。 EC-CUBE 4 開発者向けドキュメントサイト

選択肢A-2：EC-CUBE 4.2へ一旦移行して時間を稼ぐ（条件次第）

EC-CUBE 4.2の要件は PHP 7.4〜8.1 です。 EC-CUBE 4 開発者向けドキュメントサイト
サーバー都合で「今すぐ8.2/8.3にできない」などの事情がある場合に、検討余地が出ます。

ただし“最終的には4.3へ”が多いため、二度手間にならない設計が重要です。

3系→4系移行で、何がそのまま移せて何が作り直しになる？

ざっくり以下のイメージです。

• 比較的移行しやすい：商品・会員・受注などのデータ（移行ツールや変換で対応）
• 作り直しになりやすい：テンプレート（Twig化）、プラグイン、購入フロー改修、決済連携の改修

特に「決済」は最優先の検証対象です（支払いが通らない＝売上が止まるため）。

3系→4系移行の進め方（失敗しにくい手順）

1. 現状棚卸し
   • EC-CUBEのバージョン
   • プラグイン一覧（公式／独自）
   • カスタマイズ箇所（購入フロー、会員、受注、メール、CSV…）
2. 検証環境（ステージング）を作る
   • 本番DB・ファイルを複製
   • 予定PHPで動かす（ここで“落ち方”を確認）
3. 移行方式の決定
   • 重要データを移す範囲
   • 旧サイトと同等の機能をどこまで再現するか
4. 最重要機能からテスト
   • カート投入→注文完了→決済→受注メール→出荷処理
   • 会員登録、ポイント、クーポン、定期購入（ある場合）
5. 本番切替
   • バックアップ
   • メンテ表示
   • 切替→動作確認→解除

B：EC-CUBE 2系の方（延命も移行も選べる）

2系は「2.25へ上げる」ことでPHP更新に追従できる可能性がある

EC-CUBE公式ニュースで、EC-CUBE 2.25.0の主な改善として PHP 8.4 対応が明記されています。 EC-CUBE
つまり、レンタルサーバーがPHP8系へ上がる際に、2系のままでも“止まりにくい形”に寄せられる可能性があります。

さらに、2.25へアップデートする具体手順の解説も公開されています（実務の参考になります）。

2系ユーザーの選択肢（おすすめの考え方）

選択肢B-1：EC-CUBE 2.25へ更新して延命（短中期で安定優先）

向いているケース：

• 今の2系が“かなり作り込まれていて”、移行が大工事になる
• まずはサーバーPHP更新に追従して停止リスクを下げたい
• 近いうちにリニューアル予定があり、今は延命したい

注意点：

• 2系のままでは、将来的に人材確保や改修の難易度が上がりがち
• 決済・外部連携の要件（3Dセキュア等）や、運用の拡張性で限界が来ることがある
  （※ここはサイト構成次第なので、棚卸しで判断します）

選択肢B-2：EC-CUBE 4.3へ移行（長期運用・拡張性重視）

向いているケース：

• 今後も機能追加・マーケ施策（タグ計測や外部連携）を増やす予定
• 保守性・セキュリティ運用をラクにしたい
• 既に2系の改修が“つぎはぎ”で、トラブルが増えている

4.3の要件（PHP 8.1〜8.3、MySQL 8.0〜8.4等）に合わせて設計できます。 EC-CUBE 4 開発者向けドキュメントサイト

2系→2.25（延命）をする場合の進め方

1. 現状把握
   • 2系のバージョン（2.13系、2.17系、2.24系など）
   • 文字コード、独自改修、テンプレ改造、独自プラグイン
2. 検証環境で2.25へアップデート手順を再現
   • 公開されているアップデート手順を参考に進める
3. 決済・メール・CSV周りを重点テスト
4. 本番反映（バックアップ→反映→確認）

共通：レンタルサーバー環境で“落とし穴”になりやすい点

1) DBのバージョンが要件を満たさない

EC-CUBE 4.3ではMySQL 8.0〜8.4が要件です。 EC-CUBE 4 開発者向けドキュメントサイト
レンタルサーバーによってはMySQLが古い／MariaDB固定などがあり、“PHPだけ上げても4系が載せられない”ことがあります。

→ この場合は「サーバー移転」も含めて検討した方が結果的に安いことがあります。

2) プラグイン互換性が最難関になりやすい

• 旧プラグインが最新PHPで落ちる
• 代替プラグインに置き換える必要がある
• そもそも同等品が無く“作る”になる

→ ここで工数が跳ねるため、棚卸し（プラグイン一覧化）が最優先です。

3) 「本番で試す」が一番危険

本番でPHPを切り替えてから不具合対応すると、

• 原因切り分け（PHP？EC-CUBE？プラグイン？改修？）が遅れる
• サイト停止時間が伸びる
• 決済会社との調整が必要になり泥沼化

→ 必ずステージング（複製環境）で先に検証しましょう。

ざっくり工数の目安（現場感のあるレンジ）

※サイト規模・改修量・決済種類で大きく変わるため、あくまで目安です。

• 2系→2.25延命：小〜中改修で 5〜20人日、大規模改修で 20〜40人日
• 3系→4系移行（標準機能中心）：20〜60人日
• 3系/2系→4系移行（購入フロー改修＋複数決済＋独自連携あり）：60〜120人日以上 もあり得る

「何にどれくらい工数がかかるか」は、結局 棚卸し結果で決まります。

まとめ：PHP更新は“EC-CUBE更新を始める最良のタイミング”

• EC-CUBE 3系はPHP 7.1.xまでが要件で、PHP8系と噛み合いにくい EC-CUBE 開発ドキュメント
• EC-CUBE 4.3はPHP 8.1〜8.3が要件（DB要件も要確認） EC-CUBE 4 開発者向けドキュメントサイト
• EC-CUBE 2系は2.25.0でPHP 8.4対応が公式に明記され、延命策になり得る EC-CUBE
• PHP自体もサポート期限があるため、サーバー都合の更新は避けられない PHP

まずはご相談ください

EC-CUBEのカスタマイズやバージョンアップはプロにお任せください。Amazon Pay標準搭載の最新版EC-CUBEにも対応可能です。私たちは、御社のビジネスモデルに合わせた最適なEC-CUBEのバージョンアップをご提案します。小規模な改修から大規模なシステム開発まで柔軟に対応可能です。

独自機能追加・業務効率化カスタマイズ・セキュリティ強化などや、デザイン改修などで、御社のECサイトを次のステージへ。