ソフトウェア技術者のためのバグ百科事典（10）デバッグの強力な手掛かり「ログ」のバグ：山浦恒央の“くみこみ”な話（131）（1/3 ページ）

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第10回は、デバッグの強力な手掛かりとなる「ログ」にまつわるバグを取り上げます。

[山浦恒央 東海大学 大学院 組込み技術研究科 非常勤講師（工学博士），MONOist]

※本記事はアフィリエイトプログラムによる収益を得ています

1．はじめに

　バグ百科事典では、筆者が気になったバグを紹介し、読者の皆さまに「バグの早期発見」と「バグの未然防止」に役立てていただくものです。本コラムによって、より良いソフトウェア開発のお役に立てればと思います。

⇒連載「山浦恒央の“くみこみ”な話」バックナンバー

2．ログの有効性

※写真はイメージです

　プログラマーは、日々、自分のプログラムの動作不良に悩みます。例えば、状態が思ったように遷移しなかったり、プログラムが止まったりします。この時に、強力な手掛かりとなる情報の一つが「ログ」です。

　ログとは、プログラム実行時の変数の値をテキストファイルなどに記録したもので、気になる箇所にログを埋め込み、バグの原因を分析します。

　ログは、デバッグ以外でも、データの計測や分析にも使用します。例えば、工場のセンサーのデータを長時間計測し、保存しておきたい時などです。ログを取ると、センサー値が時間付きで記録できますし、さまざまなデータ分析に活用できます。

3．ログ特有の問題

　ログのバグは、ほかのバグと比べて軽微で、大きな問題に発展することはほとんどありませんが、特有の問題があります（ログはデバッグの手段である場合が多く、機能ではないので、「バグ」という表現が適切ではないかもしれません）。

　筆者がログに関して難しいと思うことは、さまざまな箇所にログを仕込まないといけないことです。例えば、機器の異常が発生した場合、ログに「ステータス：異常」と出力するプログラムを考えます。この場合、ログの記述が数個ならば問題がありませんが、さまざまなプログラムの条件式に異常処理用のログの記述を書かねばなりません。その結果、あらゆる場所にログが散在することになります。

　上記のような「ステータス情報」であれば、ログがなくても問題がないかもしれませんが、バグが起きた際の手掛かりが少なくなり、苦労します。その場合は、関連しそうな箇所にログを埋め込み、再現するかを確認したり、場合によってはログを入れ込んだまま様子を見たりすることもあるでしょう^※1）。

　たいていは入れ込んだログを分析し、プログラムを修正して終わりなのですが、たまにログ特有のバグに頭を悩ませることがあります。

※1）昔、航空機の墜落事故を取り扱ったテレビ番組を見たことがあります。事故原因を見つける事故調査チームが最も気に掛けていたのは、墜落した航空機の「ブラックボックス」を見つけられるかどうかでした。航空機のブラックボックスは、ソフトウェア開発におけるブラックボックスとは別物で、フライトレコーダーとボイスレコーダーの総称です（実際は、オレンジ色です）。直近の2時間分のデータを記録します（エンドレスで上書きします）。航空機が空中爆発すると、ブラックボックスがどこに落ちたか分からなくなるので、最長30日間、信号を出す仕組みになっています（海中の深度6000mからでも発信するそうです）。その番組では、ブラックボックスを森の中から探し当て、解析し、事故原因を究明していました。航空機でも、ソフトウェア開発と同様に原因究明の基本はログの解析だと共感しました。それにしても、2014年3月8日に消息を絶ったマレーシア航空370便が今でも見つかっていません。航空機史上、最大の謎になっています。