サーバー契約の「自動更新」をそのまま続けていい？インフラ見直しのタイミングと確認ポイント

「契約してから何年も放置している」「何が動いているか把握していない」——そんなインフラの現状を整理し、自動更新を判断するための実践的な確認ポイントを解説します。

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

「サーバー契約、気づいたら毎年自動更新されてるけど……これって本当に必要なの？」

Web担当者として日々の業務に追われていると、インフラ周りは「動いてるならOK」と後回しにしがちです。しかし、2〜3年前に設定したサーバー構成が今のサービス規模や要件に合っているとは限りません。気づかないうちに無駄なコストを払い続けていたり、逆に性能不足のまま運用していたということは、実際の現場でよく起きています。

この記事では、インフラ見直しを先延ばしにすることのリスクと、今すぐできる確認ポイントを具体的に整理します。「自動更新を止めるべきかどうか」の判断基準として、ぜひ参考にしてください。

なぜ「とりあえず自動更新」が危ないのか

コストの問題だけじゃない

自動更新を放置することのリスクは、コストの無駄遣いだけではありません。大きく分けると以下の3つが挙げられます。

① サポート切れ・EOLのリスク OSやミドルウェアには「サポート終了日（End of Life）」があります。たとえばUbuntu 18.04 LTSは2023年4月にEOLを迎えました。自動更新で契約だけ続いていても、OS自体が放置されていると、セキュリティパッチが当たらない状態で動き続けるという非常に危険な状況になります。

② スペックの過不足 サービスの規模が変われば、必要なリソースも変わります。「ローンチ当時は月間PV1万程度だったが、今は10万を超えている」というケースでは、当初のプランでは明らかにスペック不足です。逆に、大きなキャンペーン用に借りたサーバーをそのまま放置しているケースもあります。

③ 設定の陳腐化 PHP 7.4で動いているシステムを放置していませんか？ PHPは8.xが主流となっており、7.4は2022年にセキュリティサポートが終了しています。Laravelも古いバージョンのまま動かしているプロジェクトは、依存パッケージごとセキュリティリスクを抱えます。

まず現状を把握する：インフラ棚卸しの手順

「見直したい気持ちはあるけど、何から手をつければいいか分からない」という方のために、実際に当社でも使っている棚卸しのステップを紹介します。

Step 1：稼働中のサーバーとサービスを一覧化する

まず、契約しているサーバー・ドメイン・SSL証明書をすべて洗い出します。コントロールパネルや請求明細を確認するのが手っ取り早いです。

flowchart TD
    A[請求明細・コントロールパネルを確認] --> B[サーバー・ドメイン・SSL一覧を作成]
    B --> C{各サービスは現在も使用中？}
    C -->|使用中| D[スペック・OS・ミドルウェアを確認]
    C -->|未使用| E[即時解約を検討]
    D --> F{EOL・サポート期限は？}
    F -->|期限切れ| G[優先度高：移行・更新対応]
    F -->|問題なし| H[スペックと費用のバランスを見直し]

Step 2：OS・ミドルウェアのバージョンを確認する

SSHでサーバーにログインし、現在の環境を確認します。

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

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

# Nginxバージョンの確認
nginx -v

# Apacheバージョンの確認
apache2 -v

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

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

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

# Nginxバージョンの確認
nginx -v

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

# インストール済みパッケージの確認
rpm -qa | grep -E "php|nginx|mysql"

Step 3：リソース使用状況を確認する

「スペックが余っていないか」「逆に逼迫していないか」を確認します。

# CPU・メモリの使用状況
top
# または見やすいhtopがあれば
htop

# ディスク使用量の確認
df -h

# メモリ使用量の詳細
free -m

# 直近のシステムログ（エラーの有無）
journalctl -p err --since "7 days ago"

この確認で「CPU使用率が常時10%以下、メモリも余裕あり」という状態であれば、ワンランク下のプランへのダウングレードが検討できます。逆にスワップが頻発しているようであれば、増強が必要なサインです。

Step 4：不要なプロセス・ポートの確認

長年稼働しているサーバーでは、いつの間にか不要なサービスが起動し続けていることがあります。

# 起動中のサービス一覧
systemctl list-units --type=service --state=running

# 外部に公開されているポートの確認
ss -tlnp
# または
netstat -tlnp

本来必要ないポートが開いていたり、使っていないデーモンが動いていた場合は、セキュリティリスクとコストの両面から対処が必要です。

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

あるクライアントから「WordPressサイトが急に重くなった」という相談を受けたのですが、調査してみると原因はコンテンツ増加ではなくサーバー環境の問題でした。

状況の概要：

• 4年前に構築したVPS（月額1,500円プラン）を自動更新で運用継続
• OS：Ubuntu 18.04（EOL済み）、PHP：7.2（EOL済み）
• MySQL 5.7 → バージョンによってはパフォーマンス改善オプションが使えない状態
• ディスク使用率が92%に達しており、MySQLの一時ファイルが正常に作られない場面があった

対応内容： 新しいVPS（同等スペック・月額1,800円）にUbuntu 22.04 + PHP 8.2 + MySQL 8.0で環境を構築し直し、サイトを移行しました。月額コストはほぼ変わらないのに、ページ表示速度が平均1.8秒 → 0.6秒に改善。加えてセキュリティ上の懸念もクリアになりました。

このケースで注目すべきは、「自動更新を続けていたこと自体」は問題ではなく、サーバーの中身を4年間一切見直していなかったことが問題だったという点です。

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

見直しのタイミングと判断基準

まとめ：自動更新を「意識的に続ける」か「見直すか」

「自動更新が悪い」わけではありません。問題なく動いているインフラを不用意にいじる必要はないですし、コストが適切であれば継続で構いません。

ただし、「とくに確認もせず何年も放置している」という状態は、セキュリティリスク・コスト無駄・性能劣化の三重苦につながる可能性があります。年に1回、せめて更新通知が来たタイミングで、今回紹介した棚卸し作業をひと通り行うことを習慣にしてください。

インフラの問題は「壊れるまで気づかない」性質があります。壊れてから慌てるより、定期点検でリスクを早めに摘んでおく方が、結果としてコストも時間も節約できます。

当社では、現状のサーバー環境の診断から移行作業・セキュリティ強化まで一貫して対応しています。「今の環境が正しいか自信がない」という方は、ぜひお気軽にご相談ください。

インフラ見直しチェックリスト