500エラーが出たら最初に見る5つのログ｜場所と確認の順番
「サイトで500エラーが出てます」。 この連絡が来た瞬間、心臓がきゅっとなりますよね。落ちているのは分かる。でも、原因がアプリなのか、DBなのか、サーバーそのものなのか、エラー画面だけでは何も教えてくれません。
一人で保守運用をしていると、つい焦って、思いついたログを片っ端から tail してしまいがちです。 でも、5xxエラーは「サーバー側で何かがうまくいかなかった」という大きなくくりなので、見る場所を決めずに探すと、関係ないログの海で迷子になります。
この記事では、5xxが出たときに最初に見たい5つのログと、その場所を、確認する順番つきで一緒に整理します。考えなくても手が動く状態を作っておきましょう。
結論：5xxエラーが出たら、①Webサーバーのエラーログ → ②Webサーバーのアクセスログ → ③アプリケーションのログ → ④DB・外部連携のログ → ⑤サーバーのシステムログ・リソースの順に見ます。まず①で「どのステータス・どのURLか」、②で「いつから・全体か一部か」を押さえると、③以降のどこに潜ればいいかが一気に絞れます。やみくもに全部開かず、上から順に。
ログの名前や置き場所は、構成（Apache か nginx か、PHP-FPM かアプリサーバーか、クラウドかオンプレか）で変わります。 この記事の順番と場所は出発点として、自分の現場のパスに置き換えて使ってください。
まず「5xx」のどれかを見分ける
ひとくちに500エラーと言っても、5xx番台にはいくつか種類があり、見る場所のヒントになります。最初にここだけ押さえます。
- 500 Internal Server Error：アプリ側で何か例外が起きた、という最も広い合図。③のアプリログが本命。
- 502 Bad Gateway：前段（nginx等）の奥にいるアプリ（PHP-FPM・アプリサーバー）から、まともな応答が返ってこない。アプリが落ちている・詰まっていることが多い。
- 503 Service Unavailable：受け切れずに一時的に断っている。アクセス増・ワーカー不足・メンテナンス中など。
- 504 Gateway Timeout：奥の処理が時間内に返ってこない。重いクエリや外部API待ちが疑わしい（④へ）。
番号が分かるだけで、見るログの当たりがつきます。 まずはブラウザの表示か、次の①のログで、どの番号が出ているかを確認しましょう。
最初に見る5つのログと場所（順番に）
番号の見当がついたら、次の順番で上から見ていきます。 各ログで「ここに手がかりがあるか」を確認し、なければ次へ進みます。
① Webサーバーのエラーログ
まず、利用者にいちばん近いWebサーバーのエラーログを見ます。ここに、5xxを返した直接の理由が出ていることが多いです。
その前に一つだけ。「そのログを自分の権限で開けるか」を先に確かめておくと、本番で「パスは分かるのに開けない」で詰まりません。/var/log 配下は管理者権限が要ることが多いので、sudo が要るか、どの経路（SSHログイン・閲覧用アカウント等）で読むかを、一人運用なら平時に一度確認しておくと安心です。
- 場所の例：nginx は
/var/log/nginx/error.log、Apache は/var/log/httpd/error_logや/var/log/apache2/error.log。 - クラウドやマネージド環境（ロードバランサ・コンテナ・PaaS）では、
/var/log配下にファイルが無いことも多いです。その場合はコンソールのログ画面やログ管理サービス（CloudWatch 等）を見る、と分岐を覚えておきます（見方は使っている基盤の公式情報で確認）。 - 「upstream … failed」「connection refused」なら、奥のアプリ（PHP-FPM等）に届いていない合図（502系）。
- スクリプトの実行に失敗した記録があれば、③のアプリログへ進む手がかりになります。
② Webサーバーのアクセスログ
次に、同じWebサーバーのアクセスログで「広がり」を確認します。ここで全体障害か局所かが分かります。
- 場所の例：nginx は
/var/log/nginx/access.log、Apache は/var/log/httpd/access_log。 - ステータスコードの列を見て、5xxが出ているのが特定のURLだけか、全体か。1行ずつ目で追うのが大変なら、まず5xxだけ拾います。一例：
grep -E " 50[0-9] " access.log | tail（ステータスの列位置はログ形式で変わるので、自分の形式に合わせて調整してください）。 - いつから出始めたか、どのくらいの割合かを確認します。直前のリリースや設定変更と時刻が重なっていないかも、ここで気づけます。
「特定URLだけ」なら、そのURLが使う処理（③④）に当たりがつきます。「全体」なら、⑤の土台側も視野に入ります。
③ アプリケーションのログ
500の本命はここです。アプリが投げた例外やスタックトレースに、原因が直接書かれていることが多いです。
- 場所の例：フレームワークのログ（
storage/logs/、log/production.logなど）、PHP-FPM のエラーログ（/var/log/php-fpm/）、アプリを動かしている仕組みのログ。 - 例外メッセージ・スタックトレースの一番上を読むと、どのファイルのどの処理で止まったかが分かります。
- 「DBに接続できない」「Nullを参照した」「メモリ不足」など、ここで原因の種類が見えてきます。
エラーが「何かを待って失敗している」なら、その待ち先（④）へ進みます。
長いスタックトレースや見慣れない例外で当たりがつかないときは、そのエラーログやスタックトレースをAIに渡して、一次解析やあたりづけを手伝ってもらうのも一つの手です。「どの行で何を待って失敗していそうか」「次に見るべきログはどれか」を要約させると、潜る場所を絞る時間を短くできます。ただしAIの説明はそう見えるという仮説であって答えではありません。機微な情報（接続先・鍵・個人情報）は渡す前に伏せ、提示された原因は必ず実物のログで裏を取り、再現確認と最終判断は人がやる——この順番は崩さないでください。
④ データベース・外部連携のログ
アプリが「接続できない」「タイムアウトした」と言っているなら、その相手側を見ます。504はここが本命です。
- 場所の例：MySQL のエラーログ（
/var/log/mysql/error.log）、PostgreSQL のログ、決済・地図・メールなど外部APIの管理画面やステータスページ。 - DBが接続上限に達していないか、スロークエリで詰まっていないか。
- 頼っている外部サービス側で障害が起きていないか（相手の問題のこともあります）。
⑤ サーバーのシステムログ・リソース
ここまでで原因が見えないとき、土台のOS側を確認します。全体的に5xxが出ているときは、最初からここも疑います。
- 場所の例：
/var/log/messages、/var/log/syslog、dmesg。 - OOM Killer（メモリ不足でプロセスが強制終了された記録）が出ていないか。アプリが急に落ちた502の犯人のことがあります。
- ディスク使用率が100%近くになっていないか（
df -h）。書き込めずに各所でエラーが連鎖します。 - CPU・メモリが振り切れていないか、アクセスが急増していないか。
ひとつ注意です。原因調査の途中で、つい再起動やキャッシュ削除をしたくなりますが、戻し方とセットで。本番をいじる前に、できる範囲で今のログ・エラーの実物を手元に控えておくと、ローテーションで消える前に証拠を残せて、後の振り返りが楽になります。
具体例：3つの5xxのたどり方
順番に当てはめると、こんなふうにたどれます。
- 「リリース直後から全ページ500」：①エラーログにスクリプトエラー → ③アプリログにスタックトレース → 直前の変更が原因だった。②で「リリース時刻から」と裏づけ。
- 「ときどき502が混じる」：①に「upstream failed」 → ⑤のシステムログでOOM Killerを発見 → メモリ不足でアプリが落ちていた。
- 「特定の重い画面だけ504」：②で特定URLだけと判明 → ④でスロークエリ・外部API待ちを確認 → その処理がタイムアウトしていた。
大事なのは、①②で「どの番号・どこまで広がっているか」を先に押さえてから、③以降に潜ることです。入口が決まれば、開くログは自然と絞られます。
影響：見る順番を決めておくと、何が変わるか
5つのログと順番を1枚持っておくと、対応が速くなるだけでなく、気持ちが落ち着きます。
- 「どのログだっけ」で固まらず、上から手が動く。
- 関係ないログを延々と眺めずに済み、手がかりのない層は切り上げて先へ進める。
- 「①②までは確認できて、原因は③のここまで絞れています」と、調査中でも状況を説明できる。
- 自分以外の人が見ても同じ順番でたどれて、対応の品質が人や日によってブレにくくなる。
逆に、毎回ゼロから勘でログを探すと、同じ500でも対応する人や日によって、たどり着くまでの時間が大きく変わってしまいます。
明日やること：自分の環境で「5つのログの場所」を1枚にする
いきなり全部は要りません。明日できる、いちばん小さな一歩はこれです。
- 今いちばん止まると困るシステムを1つ選ぶ。
- 紙でもドキュメントでもいいので、「エラーログ・アクセスログ・アプリ・DB・システム」の5見出しを書く。
- 各見出しに、自分の環境での実際のパス（
/var/log/nginx/error.logなど）を、思い出せる範囲で書く。 - いちばん上に、5xxの番号の見分け方（500/502/503/504）を1行ずつメモしておく。
- 残りは、次に5xxが来たときに1行ずつ追記して育てる。
完成版を目指さなくて大丈夫です。5つの場所と番号の見分けだけでも、立派な調査メモの第一稿です。
「5xxエラー 最初に見るログ」チェックリスト
これは「調査メモが揃っているか」を平時に確かめるための確認用で、本番中に全部やる前提ではありません。コピーして、自分のメモに当ててみてください。
最低ラインは、①Webサーバーのエラーログと③アプリケーションのログのパスが書いてある——この2つが押さえてあれば、次に5xxが来ても入口で詰まりません。残りは余裕のあるときに足していけば十分です。
- まず5xxの番号（500/502/503/504）を確認する手順があるか
- Webサーバーのエラーログの場所（パス）が書いてあるか
- Webサーバーのアクセスログで「いつから／全体か一部か」を見る手順があるか
- アプリケーションのログの場所と、スタックトレースの読み方の一言があるか
- DB・外部連携のログ／ステータスを確認する手順があるか
- システムログ・OOM Killer・ディスク使用率を確認するコマンド／場所が書いてあるか
- 各手順に「見る場所（パス・コマンド・URL）」が具体的に書いてあるか
- 本番操作の前に「ログの実物を控える・戻せるか確認する」一言が入っているか
全部に○が付かなくても大丈夫です。○は全部つける必要はなく、半分でも、何もないときよりずっと落ち着いて潜れます。まずは最低ラインの2つから埋めていきましょう。
よければ、こちらも
5xxの調査は、障害対応全体の一部です。鳴った瞬間の段取りや、連絡の型、切り分けの順番もあわせて1枚にしておくと、当日とても楽になります。
- 障害対応runbookテンプレート｜初動・切り分け・連絡・記録を1枚に：今日のログ確認を、初動・連絡・記録とまとめて1枚にする型です。
- 「サイトが重い」の切り分け手順｜どこが遅いかを順番に絞る：5xxではなく「重い」ときの切り分け。層を順番に下りる考え方は共通です。
- 障害の第一報テンプレート｜誰に・何を・どの順で伝えるか：調査中でも出せる第一報の文面テンプレ。「①②まで確認済み」を伝えるときに使えます。
5xxエラーは、出た瞬間はとても怖いものです。でも、見るログと順番さえ決まっていれば、原因は必ずどこかのログが教えてくれます。 今日は5つのログの場所と、番号の見分けを書いておくだけで十分です。次に「500が出てます」と言われたとき、そのメモが、あなたを迷子にさせず原因まで案内してくれます。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。