ログ
Log ・ ろぐ
システムが残す出来事の記録。障害調査の一次資料であり、運用の目になる。
✦ 30秒で試す — 航海障害調査の味方が、そのまま情報漏えいの入口になるログに残すと、いちばん危ないのはどれ？予想してみる概要
ログは、システムが自分の身に起きた出来事を「いつ・どこで・何が起きたか」の形で書き残した記録です。リクエストを受けた、処理に成功した、エラーが起きた、誰かがログインした。ソフトウェアは動作の節目ごとにこうした1行を書き出し、ファイルや専用の基盤にためていきます。航海日誌（logbook）が語源で、文字どおり「システムの日誌」です。
障害が起きたとき、エンジニアが最初に開くのがログです。ユーザーからの「エラーになった」という報告だけでは何も分かりませんが、ログにはその瞬間のサーバの中で起きたことが時系列で残っています。逆に言えば、ログがない場所で起きたバグは推理するしかありません。「後から調べられるように書き残しておく」こと自体が、運用の質を決める設計の行為です。
なぜ生まれたか
プログラムの実行は一瞬で過ぎ去り、何も残しません。開発中ならデバッガで止めて中を覗けますが、本番で動くシステムの「昨夜3時に一度だけ起きたエラー」を再現することはほぼできません。過ぎ去った出来事を調べられるようにするには、実行の痕跡を記録として残しておくしかない。ログはこの必要から、コンピュータの黎明期とともに生まれた、いちばん古い運用技術のひとつです。1980年代には Unix の syslog が「どのプログラムが・どの重要度で」書いたかを添えてログを1か所に集める仕組みを整え、ログレベルの考え方もここから広まりました。
ログの用途は障害調査にとどまりません。誰がいつ何をしたかを残す監査証跡（不正アクセスの調査や法令対応の根拠）、アクセス傾向の分析、性能劣化の追跡にも使います。「記録がなければ、起きたことは無かったことと同じ」という原則が、あらゆるシステムにログを書かせています。
詳細
ログレベル — 重要度で振り分ける
すべての出来事を同じ重みで記録すると、重大なエラーが大量の些細な記録に埋もれます。そこでログには重要度のレベルを付けるのが標準です。細かいものから順に、DEBUG（開発時の詳細）、INFO（正常な動作の節目）、WARN（今は動いているが怪しい兆候）、ERROR（処理が失敗した）、FATAL / CRITICAL（システムを続けられない）が典型です。本番では INFO 以上だけを出し、調べるときだけ DEBUG に切り替える、ERROR 以上を監視のアラートの材料にする、といった運用がレベル分けで可能になります。ただし「ERROR が1行出たら人を呼ぶ」はアラート疲れの元です。エラーの件数を数えて率にし、ユーザー影響で鳴らすほうが実用的です。
構造化ログ — 人間向けから機械向けへ
伝統的なログは「2026-07-17 03:12:45 ユーザー12345のログインに失敗」のような自由な文章でした。人間には読めますが、機械で検索・集計するのには向きません。そこで現在は、各行を JSON で書く「構造化ログ」が主流です。{"time": "...", "level": "error", "event": "login_failed", "user_id": 12345} のようにフィールドを持たせれば、「user_id が12345の ERROR だけ抜き出す」「エラーの種類ごとに件数を数える」といった操作が確実にできます。ログは人間が目で読むものから、基盤に取り込んで機械が検索・集計するデータへと性格を変えました。
集約基盤 — 散らばったログを1か所に
システムが複数のサーバやコンテナに散らばると、1台ずつログインしてログファイルを見る方法は破綻します。とくにコンテナは、破棄されるとローカルのログごと消えます。このためアプリはログをファイルに書かず標準出力へ流し、集めるのは実行基盤に任せる、というのが12 Factor App 以来の定石です。各サーバのログを収集エージェント（Fluentd・Fluent Bit など）で集め、検索できる基盤（Elasticsearch と Kibana、Grafana Loki、CloudWatch Logs、Datadog など）にまとめるのが現代の標準構成です。全サーバのログを1つの画面から時系列で横断検索できる状態が、分散システムを調べる出発点になります。
何を書き、何を書かないか
良いログの条件は「調べる未来の自分が必要とする文脈が入っていること」です。エラーの記録に「失敗しました」とだけあっても手がかりになりません。何の処理が、どの入力で、どんな理由で失敗したかを含めます。分散システムでは、1つのリクエストに一意なID（リクエストID・トレースID）を発行して全サービスのログに埋め込み、サービスをまたいで追えるようにするのが定石です。この発想を発展させたものが分散トレーシングで、同じトレースIDをログにも書いておけば、トレースで見つけた遅いスパンから、その瞬間のログへ飛べます。
一方で、書いてはいけないものもあります。パスワード、クレジットカード番号、セッションの ID やアクセストークンなどの秘密情報・個人情報をログに残すと、ログ基盤そのものが漏えいの火種になります。ロガーの側で決まったフィールドを伏せ字にする仕組みを入れておくと、うっかりを防げます。
量を抑える — サンプリング・レート制限・ローテーション
ログは書けば書くほど、ストレージの費用と検索の速さを圧迫します。障害のときほどエラーが大量に出て、ログ基盤への転送が詰まり、肝心の瞬間のログが欠ける、ということも起きます。そこで量を抑える手当てを組み合わせます。正常なリクエストのログは一部だけ残す（サンプリング）、同じメッセージが1秒に何百回も出たら最初の数件と件数だけを書く（レート制限）、といった工夫です。エラーのログは間引かず、正常系を間引くのが基本です。
サーバのローカルに書くログは、日付やサイズで新しいファイルに切り替え、古いものを圧縮・削除する「ローテーション」（Linux の logrotate など）をしないと、いつかディスクを使い切ってサービスが止まります。集約基盤の側でも、直近は検索の速い場所に、古いものは安いストレージに移し、保持期間が来たら消す、という寿命を決めておきます。何を残し、何を落とし、いつ捨てるか。ログは監視と並んで、システムを「どれだけ観測できるか」を決める運用の基礎です。
試問
Web サービスのログに流れてくる情報が9つあります。ログは1か所の検索基盤に集められ、社内の多くの人が読めます。量が多すぎると費用がかさみ、障害のときに転送が詰まります。それぞれを、そのまま残すか、伏せ字にするか、一部だけ残す（間引く）かに振り分けてください。
ログに流れる9つの情報を、そのまま残す・伏せ字にする・一部だけ残す（間引く）に仕分けよ
項目を選んでから、入れる箱を選びます