サーバー契約を更新し続けるだけでは危ない——「知らない間に古くなる」インフラ問題を解説

毎年サーバー契約を更新しているだけで安心していませんか？PHPやOSのバージョン放置が招くセキュリティリスク・表示速度低下・突然の障害。実案件をもとに「インフラの老朽化」を防ぐ具体的な手順を解説します。

「更新ボタンを押しているだけ」で本当に大丈夫ですか？

こんな悩みはありませんか？

• サーバーの年間契約を毎年更新しているが、中身は触ったことがない
• WordPressやLaravelは動いているから問題ないと思っている
• セキュリティ警告のメールが来るが、何をすればいいかよくわからない
• 「古いPHPバージョンを使っています」という表示を見て不安になった

Web担当者や社内のITを兼務している方から、こうした相談をよくいただきます。サーバー契約を毎年更新していれば、インフラはそのまま維持されているように感じるかもしれません。しかし実際には、契約を更新するだけでは環境は一切アップデートされません。OSのバージョン、PHPのランタイム、ミドルウェアの設定——これらはすべて、契約当初のままで時間だけが過ぎていきます。

本記事では、こうした「放置インフラ」が引き起こす具体的なリスクと、現状確認から改善までの実践的な手順を解説します。

なぜインフラは「知らない間に」古くなるのか

サーバー契約と環境アップデートは別物

レンタルサーバーやVPSの契約更新は、あくまで「利用権の継続」にすぎません。たとえばさくらのVPSや ConoHa VPS を契約して3年が経過したとき、サーバー内のOS（CentOS、Ubuntuなど）やPHPのバージョンは契約時点のものが動き続けています。

特に問題になりやすいのが以下の組み合わせです。

PHP 7.4は2022年11月にEOL（サポート終了）を迎えており、セキュリティパッチが一切提供されていません。しかし弊社への相談案件の中では、2024年時点でもPHP 7.4や7.2を稼働させているサイトが珍しくありませんでした。

「動いているから大丈夫」の落とし穴

WordPressもLaravelも、古い環境でも動作すること自体は多くあります。エラーも出ていない。表示も問題ない。——ところが水面下では深刻な問題が進行しています。

• 既知の脆弱性を突かれる可能性：EOL済みバージョンはCVE（共通脆弱性識別子）が蓄積しており、攻撃者にとって格好のターゲットです
• パフォーマンスの劣化：PHP 8.xはPHP 7.xと比較してJITコンパイラの導入により処理速度が大幅に改善されています。古いバージョンを使い続けることは、速度面でも損をしている状態です
• ライブラリの非互換：ComposerやnpmのパッケージがPHPや Node.jsの最新バージョンを要求し始め、ある日突然アップデートが適用できなくなります

実案件から学ぶ：放置インフラが招いた問題

神奈川県内の製造業クライアントから「WordPressの管理画面にログインできなくなった」という緊急連絡を受けたことがあります。調査したところ、以下の状況が判明しました。

• サーバーOS：CentOS 7（2024年6月にEOL）
• PHP：7.2（2019年にEOL済み）
• WordPress：5.9（最新は6.x系）
• 最終バックアップ：1年以上前

直接の原因は、WordPressプラグインのひとつがPHP 7.2では動作しなくなり、管理画面全体がクラッシュしたことでした。しかし本質的な問題は、誰も環境を継続的に監視していなかった点にあります。

結果として、環境の再構築に3営業日、コンテンツの部分的な復元作業に追加で2日を要しました。もし定期的なバージョン管理とバックアップ体制が整っていれば、ダウンタイムは数時間で収まっていたはずです。

この経験から、当社では保守契約のクライアントに対してインフラ定期診断を標準メニューとして提供するようになりました。

現状確認から改善までの具体的な手順

Step 1：現在の環境を確認する

まずは自分のサーバーで何が動いているか把握することが最初の一歩です。SSHでログインできる環境であれば、以下のコマンドで基本情報を確認できます。

# OSバージョンの確認
cat /etc/os-release

# PHPバージョンの確認
php -v

# Apacheバージョンの確認
httpd -v  # CentOS系
apache2 -v  # Ubuntu系

# MySQLバージョンの確認
mysql --version

# サーバーの稼働時間（最後に再起動したのはいつか）
uptime

<?php
// phpinfo.php として一時的にアップロード
// ※確認後は必ず削除すること
phpinfo();

// または最小限の情報だけ確認する場合
echo 'PHP Version: ' . phpversion() . PHP_EOL;
echo 'Server Software: ' . $_SERVER['SERVER_SOFTWARE'] . PHP_EOL;

⚠️ phpinfo() をそのままアップロードして放置するのは厳禁です。サーバーの詳細設定が外部から丸見えになるため、確認後は必ずファイルを削除してください。

Step 2：EOL状況をチェックする

確認したバージョン番号を、以下のサイトで照合します。

• PHP：https://www.php.net/supported-versions.php
• Ubuntu：https://ubuntu.com/about/release-cycle
• CentOS：CentOS 7は2024年6月30日にEOL済み（移行が急務）

Step 3：バックアップ体制を先に整える

バージョンアップの前に、必ずバックアップを取得してください。これを怠るとアップデート中のトラブルで取り返しのつかない状態になります。

# MySQLデータベースのフルバックアップ
mysqldump -u root -p --all-databases > /backup/all_db_$(date +%Y%m%d).sql

# Webファイル一式の圧縮バックアップ
tar -czf /backup/webroot_$(date +%Y%m%d).tar.gz /var/www/html/

# バックアップファイルの存在確認
ls -lh /backup/

これをcronで自動化しておくと、定期バックアップが担保されます。

# crontabに追記（毎日午前3時に実行）
crontab -e

# 以下を追加
0 3 * * * mysqldump -u root -p'パスワード' --all-databases > /backup/db_$(date +\%Y\%m\%d).sql 2>> /var/log/backup.log

Step 4：PHPバージョンアップの流れ

PHPのバージョンアップは、いきなり本番環境で行うのではなく、ステージング環境で動作確認してから本番に反映するのが鉄則です。

flowchart TD
    A[現在のPHPバージョンを確認] --> B[ステージング環境を用意]
    B --> C[ステージングでPHPをアップグレード]
    C --> D{動作確認}
    D -->|問題あり| E[コード・プラグインを修正]
    E --> D
    D -->|問題なし| F[本番でメンテナンスモードON]
    F --> G[本番のPHPをアップグレード]
    G --> H[動作確認]
    H --> I[メンテナンスモードOFF]
    I --> J[完了・監視継続]

# Ubuntu系でPHP 8.2をインストールする例
sudo apt update
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php
sudo apt install php8.2 php8.2-fpm php8.2-mysql php8.2-mbstring php8.2-xml php8.2-curl

# Apacheのモジュールを切り替え
sudo a2dismod php7.4
sudo a2enmod php8.2
sudo systemctl restart apache2

# PHPバージョンが切り替わったか確認
php -v

よくある失敗パターンと対処法

失敗1：「本番で直接アップグレードしてサイトが落ちた」

PHP 8.xでは、PHP 7.x時代に許容されていた曖昧な型処理や、廃止された関数が**致命的エラー（Fatal Error）**を引き起こします。WordPressプラグインの非対応が原因であることが多く、特に長期間更新されていないプラグインは要注意です。

対処法：ステージング環境でのテストを必須にする。error_log を確認し、deprecated 警告が出ているコードを事前に修正する。

失敗2：「CentOS 7からの移行を先送りにしている」

CentOS 7は2024年6月にEOLを迎えています。「動いているから」と放置しているケースが非常に多いですが、セキュリティパッチが提供されない状態は事実上の無防備です。AlmaLinuxやUbuntu LTSへの移行を早急に検討してください。

対処法：移行先はAlmaLinux 9またはUbuntu 22.04 LTS（2027年4月までサポート）が現実的な選択肢です。

失敗3：「バックアップはあるが復元テストをしていない」

「バックアップは毎日取っています」という方に「復元テストはしていますか？」と聞くと、ほぼ全員が「していない」と答えます。バックアップファイルが壊れていた、復元手順を誰も知らなかった——という事態は実際に起こります。

対処法：四半期に1度、ステージング環境でリストア訓練を行う。

まとめと次のステップ

サーバー契約を更新し続けるだけでは、インフラのセキュリティも性能も維持されません。重要なのは「動いているかどうか」ではなく、「適切にメンテナンスされているかどうか」です。

特にCentOS 7の利用継続、PHP 7.x系の放置は、今すぐ対応すべき優先課題です。まずは現状確認から始め、EOLに達しているコンポーネントをリストアップするだけでも、大きな一歩になります。

「自分たちで全部やるのは難しい」と感じた場合は、保守・運用のプロに任せることも現実的な選択肢のひとつです。当社では現状のインフラ診断から移行計画の策定、実施まで一貫してサポートしています。お気軽にご相談ください。