📚 開発の常識・作法
← データベース適材適所 キャッシュ・非同期処理 →
📑 この章の目次

title: ログ・モニタリング icon: 📊 card_desc: 動いているシステムの状態を観察する作法 — ログレベル・構造化ログ・メトリクス・アラート・観測可能性 slug: 08-logging

08 ログ・モニタリング — 動いているシステムの状態を観察する作法

本番で動いているシステムは、外から見えない「箱」の中にあります。「いま正常に動いているか・問題が起きていないか」を知るには、システムが自分の状態を記録し・観察する仕組みが要ります。この章では、ログとモニタリングによる「観察の作法」を根本から理解します。

一言でいうと

ログは、システムが「何を・いつ・どうしたか」を時系列に記録したもの。モニタリングは、CPU使用率・レスポンス時間・エラー率等の状態を数値で常時監視すること。この2つで「動いているシステムの今の状態」と「問題が起きた時の原因」を把握します。これらを観測可能性（Observability／オブザーバビリティ）と呼びます。

1. なぜログ・モニタリングが必要なのか

本番環境で動くシステムは、手元のPCと違い外から中身が見えません。「たぶん動いているだろう」で放置するのは、目隠しして車を運転するようなものです。

これらに共通するのは、システムの状態を何らかの形で見える化しておく必要がある、ということ。それがログとモニタリングです。

💡 障害が起きた後で「ログを取っておけば分かったのに」と後悔するのは、現場で一番よくある光景です。障害対応の速さは、ふだんの観察の仕込みで決まります。ログ・モニタリングは「いざという時のため」でなく「日々の基本」です。

2. ログとは何か

ログは、アプリが動く中で起きた出来事を時系列に記録したものです。「誰が・いつ・何をしたか」「どこでエラーが起きたか」等を、後から追える形で残します。

開発中の print デバッグ（動作確認用の一時出力）と似ていますが、ログは本番環境で恒常的に出し続け・後から検索できる形にします。

ログの代表的な中身:

💡 スタックトレース（stack trace／「呼び出し履歴」）: エラーが起きた時、「どの関数のどの行で起きたか」の経路を示す情報。エラー原因を特定する最重要の手がかりです。

3. 🔑 ログレベル —— 記録の「重さ」を使い分ける

ここが本章の核心の1つ目です。すべてのログを同じ重さで出すと、大事な情報が埋もれて探せなくなります。ログには**「重さ（深刻度）」で分類したレベル**があります:

レベル 意味 例
DEBUG（デバッグ） 開発用の詳細。本番では通常出さない 変数の中身・処理の細かい経路
INFO（インフォ） 正常な動作の記録 サーバー起動・ユーザーログイン・注文完了
WARN（ワーン） 注意: 今は動いているが、将来問題になりうる リトライ発生・リソース残りわずか・閾値接近
ERROR（エラー） エラー発生: 処理は失敗したが、システム全体は動き続ける API呼び出し失敗・DB保存失敗
FATAL（フェイタル） 致命的: システム全体が停止・継続不可 必須サービス停止・起動失敗

使い分けの作法

重要 ログレベルは**「後から探す時のフィルタ」**です。障害時に「ERROR 以上だけ絞り込む」「WARN から時系列で見る」等、レベルがあるからこそ素早く原因に辿り着けます。すべて INFO で出すと、この絞り込みが効きません。

4. 構造化ログ —— 機械が処理しやすい形で出す

ログは後から検索・集計するために出します。人が読む文章（「ユーザーがログインしました」）より、機械が処理しやすい形（キーと値のセット）の方が、検索や分析が圧倒的に容易です。これが構造化ログです。

例: 非構造化 vs 構造化

# 非構造化（人が読む文章・探しにくい）
2026-07-10 12:34:56 ユーザーID=123 がログインに成功しました

# 構造化（JSON・フィールドで検索できる）
{"timestamp": "2026-07-10T12:34:56", "level": "INFO", "event": "login", "user_id": 123, "status": "success"}

構造化しておけば、「user_id が 123 のログだけ」「level が ERROR のログだけ」等、特定のフィールドで絞り込みができます。

💡 大量の構造化ログを集めて検索・可視化する道具として、ELK（イーエルケー／Elasticsearch + Logstash + Kibana の頭文字）等のスタックがよく使われます。規模が大きくなると、ただの grep（文字列検索）では追いつかなくなり、専用のログ集計基盤が要ります。

5. 🔑 モニタリングとアラート —— 数値で常時監視し・人に気づかせる

ここが本章の核心の2つ目です。ログが**「詳細な文字の記録」なら、モニタリングは「全体の状態を数値（メトリクス）で常時監視」**することです。

メトリクス（指標）で見る

モニタリングは、システムの健康状態を数値で把握します:

メトリクス 何が分かるか
CPU・メモリ使用率 リソースが枯渇していないか
レスポンス時間 ユーザーを待たせていないか
エラー率 どれくらいの割合で失敗しているか
リクエスト数 どれくらいの負荷があるか

これらをダッシュボードで可視化し、常時変化を観察します。

アラート —— 閾値で人に気づかせる

モニタリングの目的は「見る」だけでなく**「異常を検知して人に知らせる」ことです。あらかじめ閾値**（しきいち／限界の値）を決めておき、超えたらアラート（通知）を飛ばします:

例えていうと: 車のメーターと警告灯

重要 ログは「詳細」・メトリクスは「全体」。この2つを使い分けます。「レスポンス時間が悪化している（メトリクスで検知）→ 該当時刻のエラーログを確認（ログで詳細）」のように、メトリクスで異常に気づき・ログで原因を掘るのが基本の連携です。

6. なぜ「ログ・モニタリング」が開発の作法なのか

ここまでを読むと、ログ・モニタリングが「動かす技術」でなく**「動いている状態を把握する技術（観測可能性）**」だと分かります。

作法として位置づけられる理由

  1. 障害対応の速さを決める: ログとモニタリングの有無で、復旧時間が何倍も変わる
  2. 「観測可能性」は品質: 内部状態を外部から把握できるシステムは、運用しやすく信頼される
  3. 事後でなく事前: メトリクスの傾き（ WARN の増加等）を見て、障害が起きる前に手を打てる

面接・実務での意味

「本番で障害が起きた時、どう調査しますか？」

この質問は、**「観測の仕組みを理解しているか」**を聞いています。「アラートで異常に気づき、該当時刻の ERROR ログとメトリクスを突き合わせて原因を絞る」と答えられる人は、現場で信頼されます。

💡 サービスの信頼性を表す指標として SLA／SLI／SLO（いずれもエスエル〜／合意・指標・目標）という概念もあります。「可用性99.9%」等の約束と実績を数値で管理する作法で、モニタリングはその計測基盤になります。

7. よくある落とし穴と対処

落とし穴 何が起きるか 正しい対応
ログを出しすぎる 保存コスト増・ノイズで重要情報が埋もれる 本番は DEBUG を絞り、必要な分だけ出す
個人情報をログに書く パスワード・カード番号等の漏洩 機密情報は絶対にログに出さない（マスキング）
ログレベルを適当に決める 絞り込みが効かず、原因追及が困難 意図を持って DEBUG/INFO/WARN/ERROR を使い分ける
非構造化のまま出す 検索・集計が困難 構造化ログ（JSON等）で出す
アラートを多用しすぎる 「アラート疲労」で重要な通知を見逃す 本当に対応が必要なものだけアラート化する
モニタリングを後回しにする 障害時に手がかりゼロで途方に暮れる 最初から基本メトリクスだけでも仕込む

💡 アラート疲労: アラートが多すぎると、人は次第に通知を無視するようになります。すると本当の重大障害の通知も見逃されます。「すべてにアラート」でなく**「対応が要るものだけ」**に絞るのが作法です。

まとめ

💡 次のステップ: システムの状態を「観察」する作法が見えました。次は、処理を速くする・後回しにする技術です。第9章では、キャッシュ（結果の使い回しで高速化）と非同期処理（時間のかかる処理を後回しにする）の使い分けを扱います。