PHPのバージョンが古いと何が起きるのか？中小企業の実例で解説

「動いているから大丈夫」は危険な思い込みです。古いPHPが招くセキュリティ侵害・サイト停止・機能劣化を実際の事例とコードで具体的に解説します。

「動いているから大丈夫」——その認識が最大のリスクです

こんな状況、心当たりはありませんか？

サーバーのPHPバージョンを確認したことがない
WordPressの管理画面に「PHPのアップデートを推奨します」と出ているのに放置している
開発会社に「古いバージョンです」と言われたが、何が問題なのかピンとこない

Web担当者や開発者の方でも、「サイトが表示されているうちはOK」と考えがちです。しかし現実は、PHPのバージョンが古いサイトは今この瞬間も攻撃対象として狙われており、ある日突然、深刻な事態に陥ることがあります。

この記事では、PHPの旧バージョンを使い続けることで「具体的に何が起きるのか」を、実際のクライアント事例・エラーメッセージ・コードを交えながら解説します。抽象的な「危ない」ではなく、現場で起きた事実をもとにお伝えします。

なぜ古いPHPは問題になるのか——背景と構造を理解する

PHPには各バージョンに**「サポート期限」**が定められています。期限を過ぎると、脆弱性が発見されてもセキュリティパッチが提供されなくなります。

赤色のPHP 7.4・8.0はすでにサポートが終了しており、現時点で既知の脆弱性が修正されない状態です。国内のWordPressサイトの調査では、2024年時点でもPHP 7.x系を使用しているサイトが全体の約30%存在するというデータもあり、これは決して他人事ではありません。

問題は単なる「バージョンが古い」という抽象的な話ではなく、以下の3層にわたって具体的な障害が発生します。

セキュリティの穴が塞がれない（攻撃・改ざんリスク）
最新のプラグイン・ライブラリが動作しない（機能劣化）
パフォーマンスが低下する（速度・ユーザー体験の悪化）

それぞれを実例とともに見ていきましょう。

バックエンド開発でお困りですか？

API設計・DB最適化・システム構築など、ご相談ください

無料で相談する

実際に起きたこと——3社の事例から学ぶ

事例1：不動産会社のWordPressサイトが改ざんされた

神奈川県内の不動産会社からご相談いただいたケースです。ある朝、社員がサイトを開くと、トップページが英語の怪しい広告ページに差し替えられていました。

調査の結果、使用していたPHP 7.2には当時すでにCVE-2019-11043という深刻な脆弱性（リモートコード実行）が公開されており、それを突いた攻撃が行われていたことが判明。攻撃者は脆弱性を利用してサーバーにアクセスし、index.phpを書き換えていました。

問題のあったサーバー環境では、以下のようなリクエストが無防備に通過していました。

# 攻撃者が送ったHTTPリクエスト（簡略化）
GET /index.php?a=1+%0D%0A%0D%0A%3C?php+system($_GET['cmd']);?> HTTP/1.1
Host: example.com

このリクエストにより、任意のコマンドがサーバー上で実行できる状態になっていました。PHP 7.4以降ではこの脆弱性はパッチで修正済みでしたが、7.2はすでにサポート終了後であったため、修正が適用されていなかったのです。

対応にかかったコスト：サイト復旧作業 + 原因調査で約15万円、サイト停止期間2日間

事例2：ECサイトで決済プラグインが突然動かなくなった

横浜市内のアパレルECサイトを運営するクライアントから「カートに入れても購入ボタンが押せない」という緊急連絡がありました。

原因を追ったところ、WooCommerceの最新バージョンがPHP 7.4以降を必須要件としているにもかかわらず、サーバー環境がPHP 7.2のままだったことが発覚。プラグインの強制アップデート後に非互換が生じていました。

// WooCommerce側のコード（PHP 8.x以降の型宣言を使用）
function get_price(): float|false {
    // ...
}
// PHP 7.2ではユニオン型（float|false）は未サポート → Fatal Error発生

管理画面のエラーログには次のようなメッセージが残っていました。

Fatal error: Unrecognized type 'float|false' in /wp-content/plugins/woocommerce/src/Internal/Admin/ProductForm/Field.php on line 42

この状態が土日を挟んで約48時間続き、推定売上損失は約30万円に上りました。

事例3：問い合わせフォームから個人情報が漏洩した

製造業のコーポレートサイトで、問い合わせフォームに入力した内容が第三者に転送されていることが発覚したケースです。PHP 5.6（！）が稼働しており、メール送信関数 mail() に関連した脆弱性を悪用したメールヘッダーインジェクションが行われていました。

// 問題のあった古いコード（PHP 5.x時代の書き方）
$to = $_POST['email'];
$headers = "From: " . $_POST['name'];  // ← ここが脆弱
mail($to, $subject, $body, $headers);
// $_POST['name'] に改行コードを仕込むと任意のメールヘッダーを注入できる

顧客30名分の個人情報が流出したとみられ、個人情報保護委員会への報告対応や顧客への謝罪対応も含めると対応総コストは50万円超。もちろん信頼損失という数字で表せないダメージも伴いました。

よくある失敗パターンと、やってはいけない対処法

失敗1：「PHPだけ」上げてサイトが壊れた

最も多いトラブルです。PHPをアップデートすれば解決すると思い、確認なしにサーバーの設定を変更→WordPressプラグインが一斉にエラーを起こす、というパターンです。

**正しい手順は必ずステージング環境（本番の複製）で動作確認してから本番に反映すること。**本番環境で直接バージョンを変更するのは絶対に避けてください。

失敗2：composerの依存パッケージを無視した

Laravelなどのフレームワークを使っている場合、PHPバージョンを上げるとcomposer.jsonで定義したパッケージが一部非対応になることがあります。

# バージョンアップ前に必ず互換性チェックを行う
composer outdated

# PHP 8.2との互換性を事前確認する（--ignore-platform-reqs は使わない）
composer update --dry-run

--ignore-platform-reqsオプションで「とりあえず通す」開発者を見かけますが、これは問題を先送りするだけで本番環境では必ずほころびが出ます。

失敗3：エラー表示を本番環境でONにした

デバッグ目的でPHPエラーを画面表示にする設定を本番に残してしまうケースです。PHPのバージョン警告を確認しようとして、意図せずこの設定を入れてしまうことがあります。

// 本番環境ではエラーを画面表示しない（php.iniまたは.htaccess）
display_errors = Off
log_errors = On
error_log = /var/log/php_errors.log

エラーが画面に表示される状態は、攻撃者に「使用しているフレームワーク」「ファイルパス」「ライブラリバージョン」を教えてしまう行為です。

PHPバージョンアップの正しい進め方

flowchart TD
    A[現在のPHPバージョン確認] --> B[使用プラグイン・ライブラリの対応表確認]
    B --> C{ステージング環境はあるか？}
    C -->|ない| D[ステージング環境を用意する]
    C -->|ある| E[ステージングでPHPバージョンを変更]
    D --> E
    E --> F[動作確認・エラーログチェック]
    F --> G{問題なし？}
    G -->|エラーあり| H[コード・プラグインを修正]
    H --> F
    G -->|問題なし| I[本番環境のバックアップを取得]
    I --> J[本番環境のPHPバージョンを変更]
    J --> K[本番動作確認・監視]

バージョンアップはこのフローを守るだけで、大半のトラブルを防ぐことができます。特に「ステージング環境で先に試す」という工程をスキップするケースが非常に多く、そこで失敗が起きています。

<?php
// PHP 8.1以降で使える新機能の例（型安全性向上）
enum Status: string {
    case Active = 'active';
    case Inactive = 'inactive';
}

// readonly プロパティ（PHP 8.1+）
class User {
    public function __construct(
        public readonly int $id,
        public readonly string $name,
    ) {}
}

// Null安全演算子（PHP 8.0+）
$city = $user?->getAddress()?->getCity();

<?php
// PHP 7.4での書き方 - 動くが脆弱性パッチなし
class User {
    private int $id;
    private string $name;

    public function __construct(int $id, string $name) {
        $this->id = $id;
        $this->name = $name;
    }
}

// Null安全演算子が使えないため冗長になる
$city = $user ? ($user->getAddress() ? $user->getAddress()->getCity() : null) : null;
// ↑ このバージョンはセキュリティサポートが2022年末に終了

バックエンド開発でお困りですか？

API設計・DB最適化・システム構築など、ご相談ください

無料で相談する

開発・運用でお困りなら

システム開発

設計から運用まで、堅牢なシステムを構築します

200件以上の制作実績顧客満足度97% 初回相談無料

サービス詳細 30秒で送信 — 無料で相談する

※ 通常1営業日以内にご返信します

まとめ：今すぐ確認すべきこと

「動いているから問題ない」という状態が最も危険です。今日確認できることから始めてください。

PHPのバージョンは、WordPressの場合は管理画面の「ダッシュボード → サイトヘルス」から確認できます。Laravelプロジェクトであればターミナルで php -v を実行すれば即座に確認可能です。

PHP 8.1未満のバージョンで稼働しているサイトは、今すぐアップグレード計画を立てることを強く推奨します。

現在のPHPバージョンを確認する（WordPress: サイトヘルス / Laravel: php -v）

PHPのサポート状況を公式サイト（php.net/supported-versions）で確認する

使用中のWordPressプラグイン・テーマのPHP対応バージョンを確認する

composerを使っている場合は composer outdated で依存パッケージを確認する

ステージング環境を用意してバージョンアップを事前検証する

本番環境のバックアップを取得してからバージョンアップを実施する

本番反映後にエラーログを24時間監視する

display_errors = Off が本番環境に設定されているか確認する

Fivenine Designでは、PHPバージョンアップの調査・ステージング環境構築・本番移行までワンストップで対応しています。「まず現状を把握したい」という段階からご相談いただけますので、お気軽にお問い合わせください。サイトの改ざん被害・突然の機能停止が起きてからでは、復旧コストも精神的負担も大きくなります。できれば「何も起きていない今」に着手することをお勧めします。