ログとは？——システム運用での役割から、構造化ログの実践までわかりやすく解説

basic

「エラーは起きているのに、grepで追いかけてもなかなか原因にたどり着けない」——そんな経験はありませんか？ この記事では、システム運用におけるログの役割から、オブザーバビリティの文脈での位置づけ、そしてトレースと相関させて読む実践的な使い方までを、基本からわかりやすく解説します。

目次

「ログはあるのに、原因にたどり着けない」のはなぜ？

障害が起きたときに、まず頼りにするのがログではないでしょうか。エラー、警告、リクエストの記録——アプリケーションやシステムが残す一次情報として、ログは開発・運用の現場で長く使われてきました。

一方で、こんな悩みを感じたことがある方もいるかもしれません。

  • どこのファイルを見ればいいのか毎回迷ってしまう
  • grepで追ってもリクエスト全体の流れが見えてこない
  • マイクロサービス構成で、複数サーバーのログをタイムスタンプだけで突き合わせるのが辛い

これらは、システムの複雑化とともに「ログ単体」で原因究明する限界が見えてきていることの表れとも言えます。この記事では、そうした悩みに答えるために、以下のポイントをまとめて解説していきます。

  • システム運用におけるログの役割と基本
  • 非構造化ログと構造化ログの違い、なぜいま構造化が重要になっているのか
  • オブザーバビリティの文脈でのログの位置づけ
  • ログをトレースと相関させて、リクエスト単位で文脈を読む実践

ログとは何か

ログとは、アプリケーションやシステムが、自身の動作やイベントを時系列で記録した文字情報のことです。「いつ、どこで、何が起きたか」を後から振り返るための一次情報として、次のような役割を担います。

  • 障害調査 エラー発生時に、そのときの状況を再現・把握するための手がかりになります。

  • 動作確認 開発・デプロイ後に、意図した動作が行われているかを確認するときに使います。

  • 監査・トレーサビリティ 「誰が・いつ・何をしたか」を記録し、後から追跡できるようにする役割です。

用途によって、ログは粒度や出力先、形式が分かれます。アプリケーションログ、アクセスログ、システムログ、監査ログなど、それぞれ担う役割は違っても、「事実を残す」という共通の目的で使われている点は同じです。

非構造化ログと構造化ログ

ログの「形式」は、大きく2種類に分けられます。

  • 非構造化ログ（プレーンテキストログ） 人間が読むことを前提にした、自由形式のテキストです。たとえば次のような形になります。
2026-07-16 10:23:45 ERROR [order-api] user_id=u_1234 failed to connect to database

書きやすく人間には読みやすい一方で、機械的な検索や集計には向かず、どうしてもgrepでの絞り込みに頼りがちになります。

  • 構造化ログ（structured log） 機械が解釈しやすい形式（多くはJSON）で出力したログです。同じ内容をJSONで書くと次のようになります。
{"timestamp":"2026-07-16T10:23:45Z","severityText":"ERROR","body":"failed to connect to database","resource.service.name":"order-api","attributes.user_id":"u_1234"}

上記のフィールド名は、OpenTelemetry Logsの仕様に沿った例です（詳しくは後述）。属性ごとに検索や絞り込み・集計がしやすくなり、ダッシュボード化やアラート化にも向きます。

オブザーバビリティ実践では、ログは構造化して出力するのが基本になってきています。「なんとなく残しておくログ」から、「後から意味のある問いに答えられるログ」へと、扱い方そのものが変わってきているとイメージするとわかりやすいかもしれません。

オブザーバビリティ文脈でのログの位置づけ

システム全体の状態を把握するとき、ログは唯一の情報源ではありません。オブザーバビリティの実践では、主要なシグナルを組み合わせて使います。オブザーバビリティそのものについては「オブザーバビリティとは」で詳しく解説しています。

  • メトリック CPU使用率やレスポンスタイムなどの数値データ。全体の傾向やしきい値超過を把握するのに向いています。

  • ログ アプリケーションやシステムが出力するイベントの記録。個別の事実を詳しく残せます。

  • トレース 1つのリクエストがシステム内をどのように処理されたかの記録。ボトルネックや障害箇所の特定に強みがあります。

ログは「何が起きたか」の詳細を最も精緻に残せるシグナルです。ただし、ログだけを見ていても、「全体としてどうだったのか」「そのときどのリクエストで起きたのか」までは、なかなか見えてきません。

そこで重要になるのが、ログを他のシグナルと相関させて読むという考え方です。とくにトレースとの相関は、オブザーバビリティ実践のなかで大きな価値を生む部分になります。

ログとトレースを相関させる——リクエスト単位で文脈を読む

多くの障害は、「あるリクエストの処理中」に発生します。そのリクエストがシステム内をどう流れたかがトレース、その途中で出力された詳細イベントがログです。この両者をつなぐ鍵が trace_id（トレースID） という識別子になります。

trace_idは1リクエストごとに付与され、関連するすべてのスパン（処理単位）とログにひもづけられます。ログに trace_id を含めて出力しておけば、「このエラーログが出たとき、システム全体で何が起きていたか」を1リクエスト単位で振り返れるようになります。

分散トレーシングそのものの仕組みについては、「分散トレーシングとは」もあわせてご覧ください。

調査の流れがどう変わるか

ログとトレースを相関させると、障害調査の流れは次のように変わります。

  • Before エラーログを発見 → 関連しそうな別サービスのログを時刻で照合 → 熟練者の知見や粘り強い突き合わせで原因を絞り込み

  • After エラーログを発見 → trace_id から対応するトレースを開く → どのサービス・どの処理で詰まったかを一望

開発エンジニアにとっては、自分のサービスのエラー原因が別サービスにあるといった切り分けが容易になります。SREにとっては、複数サービスのログを手作業で突き合わせる時間を大幅に削減できます。

ログを活用するための実践ポイント

ここまでの内容を踏まえて、実践するときに意識しておきたいポイントをまとめます。

  • 構造化して出力する アプリの出力ログは、JSONなどの構造化形式に揃えていきましょう。多くの言語・フレームワークに、標準的な構造化ロガーが用意されています。

  • ログレベルを使い分ける DEBUG/INFO/WARN/ERRORを意図をもって設計し、本番でノイズになるものは抑えるようにしましょう。レベルの基準がチーム内で揃っていないと、重要なログが埋もれたり、不要なアラートが飛んだりする原因になります。

  • 調査に役立つ属性（フィールド）を意識的に付与する 構造化ログの強みを活かすには、後から絞り込みや相関に使える属性を意識的に足すことがポイントです。

    • trace_id / span_id：トレースとの相関の要。これらがあることで「このログを含むリクエスト全体」を追えるようになります
    • user_id / request_id：特定ユーザー・特定リクエスト単位で挙動を再現するときの入口になります
    • リクエスト経路（HTTP methodやpathなど）：どのエンドポイントで起きたかを絞り込めます
    • 個人情報（PII）を含む属性の取り扱いには注意し、必要に応じてマスキングを検討してください

  • 量を見て、出すべきものを残す 「全部出力する」ことを目指すと、コストも読みやすさも損なわれがちです。後から意味のある問いに答えられる粒度で残すことを意識しましょう。

  • OpenTelemetry Logs で標準化する ここまで挙げた実践を、チームやサービスを横断して統一的に行うための仕様が OpenTelemetry Logs です。ログレベルは severityNumber として標準化されており、フィールド名も Logs Data Model に沿って揃えることで、ツールを問わず同じ方法で検索・集計できるようになります。さらに、ログ・トレース・メトリックを同じ規約で収集できるため、シグナル間の相関も自然に実現できます。OpenTelemetryについては「OpenTelemetryとは」で詳しく解説しています。

ログ活用でつまずきやすいポイント

現場でよくつまずきやすいのは、次のようなパターンです。

  • 「とりあえず出力する」だけになっている 出力はしているものの、検索性や属性設計を考えていないと、結局はgrepの山になってしまいます。まずは構造化と属性設計から始めるのがおすすめです。

  • サービスごとに形式がバラバラ 複数サービスを横断して調査するとき、ログ形式やフィールド名が揃っていないと突き合わせに手間がかかります。チームや組織でフィールド命名規約を揃えておくと、後々の調査効率が変わってきます。

  • ログだけで全部やろうとする ログは強力ですが、システム全体の傾向把握はメトリックが、リクエスト追跡はトレースが得意な分野です。それぞれの役割分担を意識することで、無理なく使い分けができるようになります。

  • トレースとのひもづけがない trace_id の伝播がないと、せっかくのトレース機能と分断されてしまいます。OpenTelemetryの計装やフレームワーク連携で、リクエスト単位のIDが自動で載る状態にしておきましょう。

Mackerelで実現する、トレースと相関したログ活用

Mackerelは、サーバーやインフラのメトリック監視・アラート通知に加え、APM（アプリケーションパフォーマンス管理） によるトレース機能を提供しています。今回、これに加えてログ機能（β版）の提供を開始しました。

Mackerel APMのログ機能では、次のような体験を提供しています。

  • 構造化ログを画面から直感的に検索 属性ベースの絞り込みを画面上から操作でき、クエリ言語を書く必要はありません。

  • 検索条件の保存・チーム共有 チームでの障害調査に活用でき、検索履歴も自動で記録されるため、あとから経緯を振り返るのにも役立ちます。

  • ログとトレースを双方向に行き来できる エラーログを起点にリクエスト全体の流れ（トレース）を確認したり、逆にトレースの気になる区間から「そのときどんなログが出ていたか」を関連ログとしてまとめて開いたりできます。障害調査の起点を、ログ・トレースのどちらからでも組み立てられます。

ログに関連するトレースをその場で開けます
ログに関連するトレースをその場で開けます

既存のメトリック・トレース監視とあわせて、開発エンジニアもSREも、同じ情報基盤で原因究明を進められる——それを目指した機能設計になっています。

Mackerelは無料トライアルでお試しいただけます。ログ機能β版もあわせて、ぜひMackerelでのオブザーバビリティ実践を体験してみてください。

＼Mackerelを無料で体験／

Mackerelは、サーバーやアプリケーションの状態を可視化し、システム全体の状況を把握できるサービスです。 トライアルでは、メトリックやアラート、ダッシュボードなどの機能を実際の画面で確認しながら、Mackerelによる監視や可視化を体験できます。
14日間無料で、全機能をご利用いただけます。

無料で始める