Webサーバーの月次メンテナンスで最低限やるべき5つの確認項目

「サーバーのメンテナンスって何をすればいい？」という疑問に答える実践ガイド。20年以上の運用経験をもとに、月1回やるべき5つの確認項目をコード例付きで解説します。

「なんとなく動いているからOK」では、そのうち痛い目を見ます

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

• サーバーのメンテナンス、何をすれば良いのかよくわからない
• 「とりあえず動いているから問題ない」と思いながら、ずっと放置している
• インシデントが起きてから慌てて対応したことがある

Webサイトは公開した瞬間からリスクにさらされています。OSの脆弱性、ディスクの肥大化、SSL証明書の失効、そして気づかないうちに積み上がるエラーログ——。これらを定期的にチェックしないまま運用を続けると、「ある日突然サイトが落ちた」「個人情報が漏洩した」という事態に直面することになります。

FivenineDesignでは20年以上にわたって中小企業のWebサーバー運用に携わってきました。この記事では、その経験をもとに月1回のメンテナンスで必ずチェックすべき5つの項目を、実際の手順やコマンドとともに紹介します。「何から手をつければいいかわからない」という方に向けた、現場発の実践ガイドです。

なぜ月次メンテナンスが必要なのか

サーバーは「設置して終わり」の機器ではありません。OSやミドルウェアには日々新たな脆弱性が報告され、ログファイルやキャッシュは放置すればするほど肥大化します。また、SSL証明書には有効期限があり、更新を忘れれば訪問者のブラウザに「このサイトは安全ではありません」という警告が表示され、一瞬でブランドの信頼を損なう事態になります。

あるクライアント（神奈川県内の製造業・従業員50名）では、WordPressサイトの運用を特定の担当者に任せきりにしていました。その担当者が退職した後、誰もメンテナンスを引き継がず、半年後にはディスク容量が99%を超えてメールの送受信ができなくなるという障害が発生。復旧作業と原因調査で丸2日を費やすことになりました。

こうした事態を防ぐには、属人化を避けた「仕組み」としての定期確認が欠かせません。以下の5項目をチェックリスト化し、毎月1回実施するだけで、重大なトラブルの大半を未然に防げます。

確認項目① OSパッケージのアップデート状況

まず最初に確認すべきは、OSやインストール済みパッケージのアップデート状況です。セキュリティパッチが未適用のまま放置されているサーバーは、既知の脆弱性を突いた攻撃の格好の標的になります。

# アップデート可能なパッケージを確認
sudo apt update
apt list --upgradable

# セキュリティアップデートのみ適用する場合
sudo apt upgrade -y

# 適用後は再起動が必要なパッケージを確認
cat /var/run/reboot-required 2>/dev/null && echo "再起動が必要です"

# アップデート可能なパッケージを確認
sudo dnf check-update

# セキュリティアップデートのみ適用
sudo dnf update --security -y

# 再起動が必要か確認
sudo needs-restarting -r

注意点： アップデートを本番環境に適用する前に、必ずバックアップを取得してください。PHPのメジャーバージョンアップ（例：8.1→8.2）は、Laravelやプラグインとの互換性が崩れることがあるため、ステージング環境で動作確認してから適用するのが鉄則です。

確認項目② ディスク使用量とログの肥大化

ディスク使用率が90%を超えると、ファイル書き込みが失敗し始め、最終的にはWebサーバーやデータベースが停止します。特にログファイルとセッションキャッシュは意識しないと驚くほど膨らみます。

# ディスク全体の使用状況を確認
df -hT

# 容量を食っているディレクトリをトップ10で表示
du -sh /* 2>/dev/null | sort -rh | head -10

# /var/log 以下のログファイルサイズを確認
du -sh /var/log/*

# Laravelのlogファイル確認
du -sh /var/www/html/storage/logs/*

# 30日以上古いログを削除（確認してから実行）
find /var/log -name "*.log" -mtime +30 -exec ls -lh {} \;
# 問題なければ削除
find /var/log -name "*.log" -mtime +30 -delete

WordPressを運用している場合、wp-content/uploads の増加も要注意です。画像の最適化を怠っているサイトでは、1年も経たないうちに数GBに達することがあります。当社が支援した神奈川県内のECサイトでは、アップロードフォルダだけで15GBを超えていたというケースもありました。

確認項目③ SSL証明書の有効期限

Let's Encryptの場合、証明書の有効期限は90日です。自動更新（certbot）が設定されていても、更新スクリプトが何らかの理由で失敗していることは珍しくありません。

# 証明書の有効期限を確認
sudo certbot certificates

# opensslコマンドで直接確認する方法（example.comは自社ドメインに変更）
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates

# certbotの自動更新ログを確認
sudo journalctl -u certbot.timer --since "30 days ago"

# 手動で更新テストを実施（dry-runで本番環境に影響なし）
sudo certbot renew --dry-run

有効期限まで30日を切ったら即アクションを取ってください。期限切れ後に更新しても証明書は発行されますが、その間サイトへのアクセスがブロックされます。Google Analyticsのデータや問い合わせ数への影響は計り知れません。

確認項目④ バックアップの動作確認

「バックアップは取っている」と言いながら、実際にリストアできない状態になっているケースは非常に多いです。バックアップとは「復元できること」を確認して初めて意味を持ちます。

# MySQLダンプの動作確認（WordPressやLaravelのDB）
mysqldump -u root -p --single-transaction your_database > /tmp/test_backup_$(date +%Y%m%d).sql

# ダンプファイルのサイズと内容を確認
ls -lh /tmp/test_backup_*.sql
head -20 /tmp/test_backup_*.sql

# バックアップファイルが正常に保存されているか確認
ls -lhrt /path/to/backup/directory/ | tail -10

# 古いバックアップ（90日以上）を削除して容量節約
find /path/to/backup -name "*.sql" -mtime +90 -delete

バックアップ先はサーバー本体と別の場所（S3、外部ストレージ等）に保存することが大原則です。サーバー障害が起きた場合、同じサーバー上のバックアップは一緒に失われます。

flowchart TD
    A[月次メンテナンス開始] --> B[バックアップ取得]
    B --> C{バックアップ成功?}
    C -->|No| D[原因調査・修正]
    D --> B
    C -->|Yes| E[リストアテスト実施]
    E --> F{正常に復元できる?}
    F -->|No| G[バックアップ設定を見直す]
    G --> B
    F -->|Yes| H[他の確認項目へ進む]

確認項目⑤ エラーログの定期レビュー

最後に、Webサーバーとアプリケーションのエラーログを確認します。エラーログは「サーバーの診断書」です。致命的な障害が起きる前には、必ずといっていいほど予兆となるエラーが記録されています。

# Nginxのエラーログから直近のERROR/CRITを抽出
sudo grep -E "error|crit|alert|emerg" /var/log/nginx/error.log | tail -50

# Apacheの場合
sudo grep -E "error|crit" /var/log/apache2/error.log | tail -50

# PHPのエラーログ確認
sudo tail -100 /var/log/php8.1-fpm.log | grep -i error

# Laravelのログから直近のERROR/CRITICALを確認
grep -E "ERROR|CRITICAL" /var/www/html/storage/logs/laravel.log | tail -30

# MySQLのスロークエリログ確認（重いクエリの早期発見）
sudo tail -50 /var/log/mysql/mysql-slow.log

あるLaravelサイトの運用案件で、毎月のログレビュー時に「特定のAPIエンドポイントへの異常なリクエスト数」を検知しました。調査したところ、ボットによる総当たり攻撃（ブルートフォース）が始まっていたことが判明。ファイアウォールルールを追加することで、実被害が出る前に食い止めることができました。

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

まとめと次のステップ

月次メンテナンスは、「何か起きてから動く」から「未然に防ぐ」運用へのシフトです。今回紹介した5つの確認項目を毎月実施するだけで、突発的な障害リスクは大幅に下がります。

「項目はわかったけれど、実際にやるのは不安」「エンジニアが社内におらず属人化が心配」という場合は、定期メンテナンスをFivenineDesignにご相談ください。月次レポートの提出から障害時の一次対応まで、貴社のサーバー運用を包括的にサポートします。