本記事は『実務で役立つ ログの教科書 基礎知識から収集方法・分析手法・トラブルシューティング・パフォーマンス最適化・機械学習での活用まで』の「第1章 ログの基礎知識」から抜粋したものです。掲載にあたって編集しています。
ログに出力する内容
私たちは仕事で打ち合わせをすると議事録を作成しますし、何か学ぶときにはノートに記録します。経理担当者は簿記として入出金を記録しますし、病院では診察をしたときにカルテとして残します。プライベートで普段から日記を書いている人も多いでしょう。
個人では記録を残さなくても、会社員であれば組織として記録をつけることを求められることがあります。なぜこのような記録を残すのか、そしてログとの関係について考えてみましょう。
記録として残す意味
多くの人が作業内容などの記録を残す目的として、次のようなことが挙げられます。
- あとから振り返り、改善するため
- 思考を整理し、新たな発想につなげるため
- 自分が持つ知識を第三者と共有するため
- 作業の進捗状況を把握するため
- トラブル時に証拠として残すため
- 統計的な処理をするため
- 自分が忘れたときに備えるため
- 問題が起きたときに原因を調査するため
コンピュータで動作するプログラムについても、似たようなことを意識して作業内容を記録することを考えます。たとえば、パソコンを使っているときに、いつ、どのソフトウェアを使ったのか、どのファイルを開いたのかなどの情報が記録されていると、あとからその履歴を調べられます。
このため、プログラムの開発者は、そのプログラムが実行中にある処理が動作した経緯や、その状況についての情報を記録することを考えています。このような記録をログ(log)といいます。つまり、ログとはコンピュータに対する操作や動作状況、ネットワークの通信履歴などを指します(図1)。
どのタイミングで、どのような項目をログとして出力するかはプログラムの開発者が決めているため、その内容や粒度はプログラムによって異なります。しかし、トラブルが発生したときに、その原因を解明するために記録を残そうという考えは同じです。「いつ」「どこで」「誰が」「何を」操作したのかわからないと、プログラムが動いていたときの状況がつかめませんし、同じ問題が再発するかもしれないからです。
このような背景があり、プログラムの開発者の多くはあらゆる操作に対してログを出力できるようにしています。パソコンの起動や終了、ソフトウェアの起動や終了、ファイルの操作、キーボードやマウスの接続、キー入力、マウス操作、ネットワークでの通信の発生など、例を挙げるとキリがありません。
そして、これはパソコンだけではありません。スマートフォンやタブレット端末、ネットワーク上のルーターやハブ、IoT 機器、サーバーなどあらゆる電子機器でログを出力しています。当然、テレビやエアコン、冷蔵庫などの家電、街中で見かける自動改札や自動販売機、信号機など、あらゆる機器がログを出力しているでしょう。一般の利用者がそのログを目にすることは基本的にありませんが、それぞれに膨大なログが出力されています。
トラブル対応以外のログの目的
問題が発生したときには、管理者がログを調べることで原因を調査できます。パソコンやスマートフォンであれば、ログが保存されている場所さえわかれば、利用者がログを確認することもできます。
しかし、ログは問題が発生したときに出力されるだけではありません。正常時にも「問題なく動作していること」を示すログを出力しておかないと、どのような状況が正常なのかを判断できないからです。
そして、この「問題なく動作していること」を示すログを他の目的で使うこともあります。たとえば、パソコンやスマートフォンを使って利用者がWebブラウザでWebサイトを閲覧したときのことを考えましょう。このとき、誰がいつどのページを開いたのかがWeb サーバー側にアクセスログとして記録されています。このアクセスログを使うと、利用者の閲覧履歴を調べられるのです(図2)。
閲覧履歴から利用者の行動を把握できるのであれば、それをマーケティングなどに活かせないかと考える人がいます。つまり、アクセスログはデータ分析にも活用されています。
Web サイトのアクセス解析では、Web サーバーに残ったアクセスログを使って、どのページから入ってきて、どのページで離脱したか、どの地域の人がどれくらいアクセスしたかなどさまざまな分析が行われます。
その分析結果は、人が興味を持つようなページ作りや、見せたいページへ人をどのように導いていくか、いわゆる導線の張り方を考える材料などに用いられたりします。このように、ログは大きく分けて次の3つの目的で使われています。
- システム管理:システムの利用状況を調べる、トラブルの原因を調べる
- セキュリティ:攻撃の兆候を調べる、不正を抑止する
- ビジネス:利用状況を調べる
この1と2は主にITエンジニアが利用しますが、3については営業やマーケティングを担当する部署が利用することが多いものです。ITエンジニアはトラブルに備える目的でログを出力していても、ビジネスの視点では利用状況を把握するために使うなど、その目的があとから変わることもあります。
logという単語
ログは英語で「log」という単語です。この単語には「ログハウス」のように丸太や材木を表す意味のほか、「測程儀(そくていぎ)」という船の速度を測る器具や、「航海(航路)日誌」という意味もあります。
昔は船の速度を測るとき、木片を海に浮かべてその通過にかかった時間を測ったり、船から紐を垂らして一定の時間内に流れ出た紐の量で船の速度を測定したそうです。紐には一定の間隔で結び目をつけていたことから、日本語で「結び目」という意味がある「ノット」という言葉が船の速度の単位として使われています。そして、この木片が丸太であり、航海日誌(logbook)という言葉にもログが使われています。
このように、単に記録(record)ではなく、時間経過を表す継続的な記録を指すときはログという言葉が使われます。GPSもない時代には安全な航海において航海日誌が貴重な情報だったことがうかがえます。なお、個人的な日記を継続的に記録するときはjournalという言葉が使われることもあり、コンピュータでのログの記録にも「journal」が使われることが増えています。
ログに何が出力されているか
開発者がログを出力するときに考えていることは、ログを見ることであとから調査できるようにすることです。このために、「5W1H」の視点で記録することを意識していることが多いです。「5W1H」は次の6つの英単語の頭文字を取ったものです。
When(いつ)
基本的にはログを出力した時刻を記録しますが、その用途によって出力される精度は異なります。たとえば、Webサーバーへのアクセスログなど多くの場合は「秒」まで記録するだけで十分です。しかし、データベースでは多くの利用者がほぼ同時に更新する可能性もあるため、処理の順序を厳密に把握するため「ミリ秒」まで記録することもあります。
また、プログラムの処理時間を測定する目的や、リアルタイム性が求められるゲームでの記録であれば「マイクロ秒」まで必要なこともあります。
Where(どこで)
ログがどこから出力されたのか、その場所を特定できる内容を記録します。Web サーバーへのアクセスログでは、そのファイルの場所を示すURL がわかりやすいでしょう。プログラムでエラーが発生したときにエラーログを出力するのであれば、エラーが発生した位置(ソースコードの行番号など)が出力されます。
Who(誰が)
ログの出力が必要な操作をした人や端末などを特定できる内容を記録します。Webアプリであればアクセスしている利用者のIPアドレスやUser-Agent、ログインしていれば利用者のユーザーIDやセッションIDなどが考えられます。社内システムであれば、パソコンの端末IDやMACアドレス、社員番号などが記録されることもあります。
これを使って利用者の行動分析や、不正対策、トラブルへの対応などをするため、その目的に応じて必要な情報が記録されています。
What(何を)
どんなデータを操作したか、どんな情報がネットワーク経由で送信されたかを記録します。WebアプリではWebブラウザからWebサーバーへのリクエストの内容、デスクトップアプリであれば処理中のメモリ上に残っているデータをそのままダンプ(加工せずに出力)することもあります。出力する内容によっては容量が多くなることが想定されるため、必要な情報に限定して出力されます。
Why(なぜ)
ログとして出力が必要な理由を記録します。エラーであればエラーコードやエラーメッセージ、正常であれば問題ないことがわかるようにログの種類(警告、エラー、正常などのステータス)が出力されます。
How(どうやって)
どうやってその操作がされたかを記録します。「どのボタンを押したか」「どのリンクをクリックしたか」「どのプログラムから呼び出されたか」といった利用者の操作を識別できるように出力します。
ログの出力時に注意すること
ログには操作の内容が細かく記録されていることがわかりました。それなら、ログにあらゆる情報を出力しておけばよいと感じる開発者がいるかもしれません。
しかし、形式などを考慮せずになんでもログに出力してしまうと、さまざまな問題が発生します。具体的にどのような問題があるのか、そしてどのような形式で出力されていると使いやすいのかを考えます。
日付や時刻の形式
ログを出力するとき、日時の出力は必須です。しかし、この出力形式はプログラミング言語やライブラリによって異なります。日時の標準的な形式としてISO 8601という世界標準の規格があり、「20250801T123456+0900」や「2025-08-01T12:34:56+09:00」といった形式が考えられます。
しかし、単に「2025/08/01 12:34:56」のように人間が読みやすい形式で出力されることも多いものです。また、Unixtimeと呼ばれる1970年1月1日0時0分0秒からの経過秒数を使うこともあります。
文字コード
ログは特定のソフトウェアでしか読み込めないようなバイナリ形式で出力することもできますが、多くのソフトウェアで扱えるようにテキスト形式で出力されることは多いものです。
このようなテキスト形式でログを出力するときに注意しなければならないのが文字コードです。アルファベットや数字などASCII コードの範囲内でログを出力しているときはあまり気にする必要はありませんが、日本語や記号、絵文字などを含むときには、文字コードを意識しないと文字化けします。
最近はUTF-8で出力することが多いものの、古いシステムではShift_JISやEUC-JPなどが使われることもあります。このようなログを他のシステムと連携するときには、文字コードの変換が必要になります。
ログの出力先
ログを出力するディレクトリはOS やプログラムによって異なります。この出力先として、OS が用意している標準的なディレクトリで管理するか、プログラムで自由に変更できるようにするかを検討します。ソフトウェアの利用者(システム管理者)が設定ファイルなどで指定できるような機能があれば便利でしょう。
なお、ログの用途によって、出力先を複数のファイルに分けることもありま す。たとえば、アクセスログとエラーログは用途が違うため、分割しておくと 集計や分析が便利です。
保存期間と退避
長期間にわたってログを出力すると、それだけログの容量が大きくなり、ディスクの空き容量が減ります。これにより本来のサービスに必要なデータを保存できなくなると困ります。このため、ログを保存する期間を決めておきます。組織の業務内容によっては、内部統制などのルールにより保存期間が定められているログもあるため、要件を確認することが必要です。
また、ログのサイズが大きすぎると解析にも時間がかかるため、一定の期間でログを退避します。これをローテート2やローテーションといいます。日次(1日1回)や月次(月に1回)といった間隔でローテートすることが多いですが、一定のサイズを超えたらローテートする、数時間ごとにローテートする、といった方法も考えられます。
圧縮と分割
直近のデータは分析や調査に使うことが多いため、すぐにアクセスできる場所に保存する必要があります。しかし、過去のデータはそれほど使うことはなく、問題が発生したときに調査できれば十分でしょう。
ログはテキスト形式であることが多く、圧縮することでディスクの使用量を大幅に減らせます。ただし、巨大なファイルを圧縮すると、圧縮の処理にCPUを使うことで本来のサービスに影響が出る可能性があります。このため、ファイルを細かく分割するか、夜間などCPUの負荷が低い時間帯に圧縮処理を実行します。
粒度と種類
ログが細かく出力されていると詳細な分析ができる一方で、過剰にログを出力するとシステムのパフォーマンス低下やストレージの圧迫につながります。このため、ログをどの程度の粒度で出力するのか、種類(正常、情報、警告、エラーなど)をどうするのか調整します。また、開発環境ではすべての種類のログを出力し、本番環境では警告やエラーなど重要な種類だけを出力するように切り替える設定を用意することもあります。
ログに残してはいけない情報
あとから分析するためには細かな情報をログに出力しておくと便利ではありますが、セキュリティの観点から考えるとログに記録するべきでない情報があります。たとえば、顧客の個人情報や企業が持つ秘密情報があります。
顧客の個人情報
顧客の住所や氏名、電話番号などの情報はデータベースに保存されていることが多いです。このデータベースにアクセスしたプログラムが、読み込んだ内容をログに出力してしまうと、ログに個人情報が残ります。一般に、個人情報の管理においてログへの出力は想定されていないため、記録として残ってしまうことは問題です。
どのような情報を記録してよいかは組織によって異なるため、組織のセキュリティポリシーなどで定義を確認します。そのうえで、必要に応じてログとして出力するときには「*」や「■」といった記号に置き換えます。
企業が持つ秘密情報
企業の売上や人事情報、設計図などの情報を特定の部署以外が閲覧できてしまっては問題になることがあります。個別の値は出力しなくても、計算した結果をデバッグ情報として出力していることがありますが、その内容によってはログとして保存されると問題になることがあります。
開発環境のみで出力し、本番環境では出力しないように設定するなど、その管理には注意が必要です。
本書の第2章で解説するように、他のシステムにログを転送して一元管理するような技術を使用している場合は、出力されたログが複数のシステムに記録される可能性があるため、特に注意が必要です。
なお、ログには開発者がプログラムの動作を確認するために出力するものと、現場の運用担当者が使うために出力するものがあります。このため、開発者が独自に判断するのではなく、運用担当者と認識を合わせておく必要があります。


