独立サイトのログ管理：アクセスログ、エラーログ、アプリケーションログの収集と分析
1. 3種類のログはそれぞれ役割が違う。混ぜて見ない
サーバー上のすべての.logファイルを「ログ」とひとまとめにして、障害のたびに片っ端から開く人が多くいます。しかし3種類のログは、まったく異なる3つの問いに答えるものです。アクセスログ（Nginx/Apacheのaccess.log）は「誰がいつ何をリクエストしたか」に答えます。エラーログ（Nginxのerror.log、PHP-FPMのエラー）は「サーバー側のどこでエラーが出たか」に答えます。アプリケーションログ（自分のコードに書いたlog）は「この注文がどこまで処理され、なぜ失敗したか」に答えます。
ここでの直感に反する判断はこうです。本番障害が起きたとき、最初に開くべきでないのがアクセスログです。アクセスログは量が多くノイズも多いため、先に見ると数千件の200に埋もれてしまいます。正しい順序は、まずエラーログで落ちた箇所を特定し、次にアクセスログで影響範囲（ユーザー数、URL）を確認し、最後にアプリケーションログで業務フローを再現する流れです。これはAIクローラーログ分析「誰が読んでいるかをまず見極める」と同じ考え方です。まず分類し、それから分析します。
| ログの種類 | 回答した質問 | 典型的な場所 | 推奨保存期間 |
|---|---|---|---|
| アクセスログ | 誰が、いつ、何をリクエストしたか | Nginx access.log | ホットデータ90日 |
| エラーログ | サーバー側のどこで、なぜエラーが出たか | Nginx error.log / PHPエラー | 1年 |
| アプリケーションログ | 業務フローがどこまで進み、どこで止まったか | コード独自のlog | 30日 |
| システムログ | サーバー自体のイベント | /var/log/messages | 30日 |
2. 収集パイプライン：各ファイルに散在する状態から一か所で検索できる状態へ
個人チームによくあるのは、Nginxのログ、PHPのログ、アプリ独自のログが別々のディレクトリに散らばり、サーバーが再起動したりマシンを移したりすると履歴が途切れる状態です。ログ管理の第一歩は分析ではなく、これらを一か所に集約することです。
ログの流れは4段階です。アプリがファイルに書き、日次でローテーションし、1か所に集約し、エラーにアラートを設定します。ローテーションは logrotate で日次分割と gzip 圧縮を行い、1ファイルが数GBになって開けなくなるのを防ぎます。集約はまず簡単に、rsyslog か軽量エージェントで専用マシンやクラウドのログサービスへ送るだけでも十分です。
1人チームが最初から ELK のような重量級スタックを導入する必要はありません。まずは集約ストレージと検索画面だけで十分で、量が増えてから検討しましょう。CDN サイトではエッジログとオリジンログの両方を取り込む必要があります。詳しくはCDNグローバル高速化。
| 工程 | やり方 | ツール / 設定 | やらない場合の結果 |
|---|---|---|---|
| ファイル出力 | 統一フォーマットで出力 | combined 形式 | 項目が揃わず解析スクリプトが書きにくい |
| ローテーション | 日次分割と圧縮 | logrotate | 単一ファイルが肥大化してディスクを圧迫 |
| 集約 | 1か所のストレージに集約 | rsyslog / クラウドログ | サーバー移行で履歴が途切れる |
| アラート | エラー率のしきい値で通知 | 監視プラットフォームのルール | 障害はユーザーの苦情で初めて気づく |
三、エラーログ：1人チームが最も注視すべき種類
3種類の中でエラーログは単位あたりの情報密度が最も高く、優先的に監視する価値があります。アクセスログは1日に数十万行あっても、エラーログは数百行程度。しかしその1行1行が実際の失敗です。エラーログを個別に集約し、個別にアラートを設定するのが最も費用対効果が高い方法です。
しきい値は具体的な数字で設定します。5xx エラー率が10分間連続で1%を超えたら即アラート。単発の異常エラー（データベース接続失敗や決済コールバック失敗など）は1回の発生でアラートし、累積を待ちません。エラーログはレベル分けが必要です。warning は定期的に確認、error と critical は必ずリアルタイム通知。PHP のようなアプリでは致命的エラーとスロークエリを個別に抽出します。
シナリオ例：ある日の午前、アラートが鳴り、5xx エラー率が0.1%から3%に跳ね上がりました。まずエラーログを開くと “PHP-FPM: unable to connect” が大量にあり、バックエンドのプロセスプールが満杯と判明。次にアクセスログでどの URL が引き金かを見ると、新規リリースした API のスロークエリがプロセスプールを圧迫していました。最後にアプリログでどの SQL かを確認。10分以内に特定できる。これがエラーログを優先する価値です。
| エラーレベル | 例 | 対応方法 | アラートしきい値 |
|---|---|---|---|
| critical | データベース接続不可、決済失敗 | 即時通知 | 1回の発生でアラート |
| error | 5xx、致命的エラー | リアルタイム通知 | 10分以内に > 1% |
| warning | スロークエリ、リトライ | 毎日まとめて確認 | ベースラインの2倍で集約 |
| notice | 正常な業務通知 | アーカイブのみでアラートなし | アラートなし |
四、アプリログ：業務フローを追跡可能にする
アクセスログとエラーログはサーバーの”客観的”な記録ですが、”この問い合わせがなぜ CRM に入らなかったのか”といった業務上の疑問には答えられません。そこで必要になるのがアプリログです。重要な業務ポイントで自分でログを書きます。問い合わせが送信された、データベースに書き込まれた、CRM に送信された、CRM からの応答が失敗した、といった具合です。
アプリケーションログで大事なのは、すべての行に業務を識別するIDを付けることです。たとえば問い合わせIDや注文番号です。こうしておけば、障害が起きたときにそのIDで検索するだけで、その業務が送信されてから完了するまでの流れを一本につなげられます。意味のないログ（「10行目まで実行」など）は書かず、各行が業務上の問いに答えられるようにします。ログ量は1日あたり数十MB以内に抑え、リクエストボディを丸ごと書き込むのは避けます。遅くなるうえに個人情報が漏れるからです。
パフォーマンス低下とログの関係も触れておきます。ログを書きすぎたり、リクエストごとに同期でディスクに書き込んだりすると、それ自体がレスポンスを遅くします。遅いレスポンスの指標の見方はCore Web Vitalsをご覧ください。監視とアラートの全体像はサイト監視とアラート。
| 業務の節目 | 記録すべき内容 | 付けるID | 障害時の調べ方 |
|---|---|---|---|
| 問い合わせ送信 | フォーム項目、参照元ページ | 問い合わせID | IDで送信記録を検索 |
| DB登録 | 書き込みの成功／失敗 | 問い合わせID | DBに保存されたか確認 |
| CRMへ連携 | APIの戻り値、所要時間 | 問い合わせID | CRMが受け取ったか確認 |
| メール通知 | 送信の成功／失敗 | 問い合わせID | 営業が受け取ったか確認 |
5. 落とし穴：ログ管理で最も多い3つのミス
1つ目の落とし穴は「ローテーションも保持もしない」です。1つのファイルに書き続けると、3か月後には数GBになり、障害調査でgrepしてもなかなか終わらず、ディスクを埋め尽くしてサイトを落とすこともあります。日次でのローテーションと保持ポリシーは最低ラインです。
2つ目の落とし穴は「リアルタイムだけ残してアーカイブしない」です。ディスクが一杯になると古いものから削除するので、2か月前の障害の起点を調べたくてもデータがありません。ホットデータは90日、期限を過ぎたら圧縮して少なくとも1年はアーカイブする。コストはごくわずかです。3つ目の落とし穴は「ログに機密情報を書く」です。ユーザーのパスワードやクレジットカード番号の全体をログに書くと、ログ基盤にもう1つ漏えい元を作るのと同じです。機密項目は必ずマスクするか、ディスクに残さないようにします。
| よくある誤り | 表面的な現象 | 本当の問題 | 正しい対処 |
|---|---|---|---|
| ローテーションなし | 単一ファイルが肥大化 | ディスク満杯、検索が遅い | logrotateで日次ローテーション |
| 履歴を残さない | ディスクが一杯なら削除 | 振り返りたいときにデータがない | ホット90日、アーカイブ1年 |
| 機密情報を書く | ログはデバッグに便利 | ログ基盤が漏えい元に | 機密項目をマスク |
| 3種類を混ぜて見る | 障害時に1つずつ探る | 特定が遅く、ノイズが多い | エラーを優先し、分類して検索 |
FAQ よくある質問
自社サイトにELKのようなログ基盤は必ず必要ですか？
アクセス、エラー、アプリの3種類のログを一緒に置いてはいけないのはなぜですか？
各種ログはそれぞれどのくらい保持すべきですか？
エラーログのアラートしきい値はどう決めますか？
アプリケーションログはどのくらい詳しく出すべきですか？性能に影響しませんか？
ログにユーザーのパスワードや決済情報を記録してもいいですか？
最後に
ログ管理の価値は「どれだけ保存したか」ではなく、「障害発生時に3分以内に特定できるか」にあります。個人運営の独立サイトなら、3種類のログを分け、日次で分割して集中管理し、エラー率が1%を超えたらアラートする。この基本を整えるだけで、日常のトラブル対応時間は「半日ログを探す」から「アラートを一瞥する」に短縮できます。本格的なログ基盤は規模が大きくなってからの話で、立ち上げ時の必須ではありません。
導入は3ステップ。第一に、アクセス・エラー・アプリの3種類のログを分けて保存し、日単位でローテーションしてそれぞれ保持期間を設定する。第二に、rsyslog かクラウドのログサービスで一か所に集約し、業務 ID で検索できるようにする。第三に、エラー率が10分で1%を超えたら、critical エラーは1回でも出たらアラートを上げる。この3ステップを終えれば、オンラインの状態を把握する感覚は「ユーザーからの苦情で初めて知る」から「自分たちが先に気づく」に変わる。運用のペースは次を参考に公式サイト保守期間一緒に並べよう。
覚えておきたい一言。ログは懐かしむために残すハードディスクのファイルではなく、事故現場のドライブレコーダーだ。普段から分類も集約もしていなければ、いざというときに勘で推測するしかない。