本番サーバーの「何かが重い」を5分で切り分ける初動チェック手順

サイトが突然重くなったとき、何から確認すればいいか迷っていませんか？ITが苦手な担当者でも5分で原因を絞り込める、実践的な初動チェック手順を解説します。

「重い」と言われても、どこを見ればいいの？

こんな経験はありませんか？

「なんか今日のサイト、重くないですか？」と社内から連絡が入った。急いで確認しようとするも、何をどこから見ればいいかわからず、とりあえずサーバー会社に電話してみたら「特に異常はない」と言われた——。

本番サーバーの「重さ」は、原因が一箇所に限らないのがやっかいです。CPU・メモリ・ディスク・ネットワーク・アプリケーション側のバグ・外部APIの遅延など、複数の要因が絡み合うことも珍しくありません。しかし、正しい順番で確認すれば、専門家でなくても5分以内に原因をおおよそ絞り込めるのも事実です。

この記事では、ITの専門知識がなくても実践できる「初動チェックの手順」を、実際にあったクライアントの事例を交えながら解説します。焦って再起動するのは最後の手段——まずは落ち着いて原因を確認することが、最速の解決につながります。

なぜ「重くなる」のか？原因の全体像を知る

本番サーバーが重くなる原因は、大きく4つのレイヤーに分類できます。この構造を頭に入れておくと、どこを見るべきかが自然と絞れます。

flowchart TD
    A[サイトが重い] --> B{ネットワーク層}
    A --> C{サーバーリソース層}
    A --> D{アプリケーション層}
    A --> E{外部依存層}
    B -->|回線・DNS障害| B1[CDN・ホスト障害を確認]
    C -->|CPU/メモリ/ディスク逼迫| C1[top / df コマンドで確認]
    D -->|クエリ・コード起因| D1[スロークエリ・エラーログを確認]
    E -->|外部API・広告タグ遅延| E1[外部リクエストを一時無効化]

ネットワーク層はホスティング会社側の障害や、CDN（コンテンツ配信ネットワーク）の不具合が原因。自分では直せないが、早期に判断して問い合わせることが重要です。

サーバーリソース層は、CPUやメモリが限界に達している状態。突発的なアクセス集中や、メモリリークを起こしているプロセスが原因のことが多いです。

アプリケーション層は、データベースの重いクエリやPHPの処理ボトルネックが原因。Webサービスの改修後に発生しやすく、見落とされがちです。

外部依存層は、決済サービスや地図API、広告タグなど、外部サービスの遅延が自サイトのページ表示に影響するケース。「うちのサーバーは正常なのに遅い」という状況の多くはここが原因です。

5分で切り分ける！初動チェック手順

Step 1：まず「どこが遅いか」を1分で確認する（ネットワーク層）

サーバーにログインする前に、外部からの視点で状況を把握します。以下を確認してください。

• ホスティング会社のステータスページを見る（例：さくらインターネット、AWS、Xserverなど、ほとんどの会社が公開しています）
• Downdetector や GDST で広域障害が出ていないか確認する
• ブラウザの開発者ツール（F12）を開き、「ネットワーク」タブで最初のHTTPレスポンスに時間がかかっているか、特定のリソースで詰まっているかを確認する

ホスト側の障害であれば、自社でできることは何もありません。焦ってサーバーを再起動するのはここで我慢するのが正解です。

Step 2：サーバーリソースを2分で確認する（リソース層）

SSHでサーバーにログインできる環境であれば、以下のコマンドを順番に打ちます。

# CPU使用率とメモリ使用量をリアルタイムで確認
top

# または見やすいhtopがインストールされていれば
htop

# プロセス別にCPUを食っているもの上位10件を確認
ps aux --sort=-%cpu | head -10

# ディスク使用量の確認（Use%が90%超えていたら危険）
df -h

# ディレクトリ別の使用量（どのディレクトリが大きいか）
du -sh /var/log/*
du -sh /tmp/*

# ログが肥大化していないか確認
ls -lh /var/log/nginx/
ls -lh /var/log/mysql/

見るべきポイントはシンプルです。

• top でCPU使用率が90%以上に張り付いている → CPU枯渇
• top でメモリのusedがtotalに限りなく近い → メモリ不足
• df -h でUse%が90%超 → ディスクフル（ログが原因のことが多い）

あるクライアントでは、夜間バッチ処理の実装ミスで /tmp ディレクトリに数GBの一時ファイルが溜まり続け、ディスクがほぼ満杯になっていたことがありました。サーバー会社に問い合わせても「CPU・メモリは正常」と言われ続けていたのですが、df -h の一発で原因が判明。問題解決まで1時間以上かかっていたものが、コマンド1つで10分以内に解消できました。

Step 3：アプリケーションログを1分でスキャンする（アプリ層）

リソースに問題がなければ、アプリケーション側のログを確認します。

# 直近100行のエラーログを確認
tail -100 /var/log/nginx/error.log

# 直近のアクセスログでレスポンスタイムを確認（4列目がステータスコード）
tail -50 /var/log/nginx/access.log | awk '{print $7, $9}'

# スロークエリログが有効な場合（my.cnfで設定が必要）
tail -100 /var/log/mysql/mysql-slow.log

# 現在実行中のクエリを確認
mysql -u root -p -e "SHOW FULL PROCESSLIST;"

# Laravelアプリのエラーログ確認
tail -100 /var/www/html/storage/logs/laravel.log

# 直近のエラーだけ抽出
grep 'ERROR\|CRITICAL' /var/www/html/storage/logs/laravel.log | tail -30

Laravelを使っているプロジェクトであれば、laravel.log に CRITICAL や ERROR が大量に吐き出されているケースは要注意。N+1問題（ループの中で無数のSQLが発行される状態）がリリース後に初めて顕在化することもあります。

切り分け結果のまとめ

弊社の過去案件を振り返ると、ディスクフルとスロークエリ・メモリ不足で全体の75%以上を占めます。「なんか重い」の大半は、この3つを確認するだけで解決の糸口が見えます。

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

❌ 失敗1：原因不明のまま再起動してしまう

最もよくある「やりがちなミス」がこれです。確かに再起動で一時的に症状が消えることはあります。しかしログも消え、原因追跡ができなくなります。再起動は必ず「ログを保存してから」が鉄則。最低でも以下を控えてから実行してください。

# 再起動前にログを退避
cp /var/log/nginx/error.log /tmp/error_backup_$(date +%Y%m%d%H%M).log
cp /var/www/html/storage/logs/laravel.log /tmp/laravel_backup_$(date +%Y%m%d%H%M).log

❌ 失敗2：ディスクフルの対処で誤ったファイルを削除する

ディスクが満杯のとき、焦って rm -rf を使うと重要ファイルを消してしまう事故が起きます。ログファイルを安全に消すには truncate コマンドが安全です。

# ログファイルを中身だけ空にする（ファイル自体は残す）
truncate -s 0 /var/log/nginx/access.log

❌ 失敗3：「外部からは問題ない」と言われて調査を止める

サーバー会社の監視は、CPU・メモリ・死活監視が中心です。アプリケーション内部のスロークエリや、特定のページだけ遅いといった問題は検知されないことがほとんど。「インフラは正常」と「サービスが快適」はイコールではありません。

まとめ：迷ったらこの順番で確認する

「重い」と連絡が来たら、次の順番で確認を進めてください。この手順を踏むだけで、原因不明のまま時間を浪費するリスクを大幅に減らせます。

一人で対応するのが不安なら

今回紹介した手順は「初動の切り分け」に特化しています。原因が判明した後の対処——スロークエリのチューニング、メモリ設定の最適化、Laravelアプリのパフォーマンス改善——は、やはり専門的な知識と経験が必要です。

Fivenine Designでは、本番障害の緊急対応から、定期的なサーバー監視・運用保守まで対応しています。「自社サーバーの状態が心配」「重くなったときに頼れる窓口がない」という場合は、お気軽にご相談ください。初回相談は無料です。