エラーログの読み方｜初心者が最初に確認するポイント

エラーログとは？原因を調べるための記録

ログとは、アプリやシステムで起きた出来事の記録です。そのうち、処理の失敗や問題について残された記録を、エラーログと呼びます。

画面に「保存に失敗しました」としか出なくても、ログには「どのファイルを開けなかったか」など、詳しい情報が残っていることがあります。ただし、ログは原因を調べる手がかりであり、必ず解決方法まで書かれているわけではありません。

エラー専用のファイルに記録される場合もあれば、通常の動作記録と同じ場所に混ざる場合もあります。

読む前に、操作とログの場所を確認する

まず「いつ、どこで、何をしたら、どうなったか」をメモします。たとえば「9月12日14時32分ごろ、テスト用の画面で保存ボタンを押したら失敗した」という形です。

次に、そのアプリの手順書でログの確認場所を探します。場所が分からなければ、担当者に「この画面の保存処理のログは、どこで確認できますか」と聞いて構いません。

• 自分のPCで動かすプログラム：実行結果が出る画面や、指定されたログファイル。
• 仕事で使うシステム：チーム指定のログ閲覧画面や、アプリが動いているコンピューター内のログファイル。
• ブラウザー上の問題：開発者ツールにあるConsole（動作中のメッセージを確認する画面）が手がかりになる場合もある。

ブラウザー側と、その裏で処理するアプリ側では、記録される情報が異なります。画面でエラーが出たからといって、ブラウザーだけで原因が分かるとは限りません。

テスト用の環境と、利用者が実際に使う本番環境も区別しましょう。閲覧する権限がない場合は、担当者に該当部分の確認を依頼します。

エラーログを読む4つのステップ

探す範囲を日時で絞り、文面と場所を読み、最後に前後の記録をつなげます。最初からファイル全体を読み切る必要はありません。

STEP1 発生日時を合わせる

ログ閲覧画面の日時指定や、ファイルを開くアプリの検索機能で、問題が起きた時刻の近くを探します。まずは前後数分を目安にし、見つからなければ範囲を広げてください。

日付と時刻の基準も確認します。たとえば日本時間の14時32分は、UTC（世界の時刻の基準）では同日の5時32分です。ログがUTC表示なら、日本時間をそのまま探しても一致しません。

記録に「+09:00」があればUTCより9時間進んだ時刻です。時刻の基準が書かれていない場合は、閲覧画面の設定や手順書で確認しましょう。

STEP2 エラーの文面を読む

該当時刻の近くで、ERRORなどの目印と、その後にある説明文を探します。ERRORのような重要度の区分を「ログレベル」といいます。代表的な読み方は次のとおりです。

• DEBUG：詳しい調査用の情報。
• INFO：処理の開始・完了など、通常の動作に関する情報。
• WARN／WARNING：注意が必要な状態を知らせる記録。
• ERROR：処理の一部が失敗したことなどを示す記録。

名称や使い分けはシステムによって異なります。ERRORがあるだけで「システム全体が停止した」とは判断せず、何の処理が失敗したかを文面で確認します。ログレベルの基本的な考え方はPython公式のLogging HOWTOでも説明されています。

英語は、まず短いまとまりで読めば大丈夫です。たとえば「Permission denied」は「権限がなく拒否された」、「No such file or directory」は「指定されたファイルやフォルダーが見つからない」という手がかりです。どの対象について書かれているかも、併せて見てください。

STEP3 ファイル名や行番号を見る

プログラムのファイル名と行番号が出ていれば、エラーが表面化した場所を探す手がかりになります。たとえば「File “report.py”, line 18」は、report.pyというファイルの18行目を示します。

複数のファイル名や行番号が続く部分は、処理がどこを通ってきたかの記録です。「スタックトレース」と呼ばれ、Pythonでは「Traceback」という見出しで表示されます。最初はエラーの種類・説明と、自分たちが作ったファイル名があるかを確認しましょう。

その行に渡された値や設定が間違っている可能性もあります。表示された行番号は、必ずしも修正すべき場所とは限りません。コードが手元になくても、ファイル名と行番号を控えておけば相談に役立ちます。Pythonの表示例は公式チュートリアルの「Errors and Exceptions」で確認できます。

STEP4 同じ処理の前後をたどる

ERRORの行が見つかったら、その前後の行も確認します。ERRORだけに絞り込んでいる場合は、いったん絞り込みを緩め、処理開始などの記録も表示してください。

複数の利用者の記録が混ざるときは、「request_id」などの識別用の番号が役立ちます。これは、ひとつの処理を追いかけるための目印です。同じ番号で探すと、その処理の開始から失敗までを追いやすくなります。

この番号が出ないシステムもあります。その場合は日時や機能名などを組み合わせます。時刻が近いだけの別の処理を、同じ出来事と決めつけないようにしましょう。

具体例で、分かることと未確認のことを分ける

テスト用の画面で「レポート作成」を押したときの、説明用の架空ログです。読みやすく短くしてあります。実際の書式や改行はシステムによって異なります。

2026-09-12T14:32:08+09:00 INFO
request_id=abc123 レポート作成開始
2026-09-12T14:32:09+09:00 ERROR
request_id=abc123 レポート作成失敗
FileNotFoundError:
No such file or directory: 'sales.csv'

この例から読めるのは、次の3点です。

• 日本時間の14時32分09秒に、レポート作成の失敗が記録された。
• abc123という同じ番号で、開始と失敗を結び付けられる。
• sales.csvというファイルを見つけられなかったことが示されている。

「FileNotFoundError」は、ファイルなどが見つからないことを示すPythonのエラー名です。この例では、ファイル名の後にある.csvはファイルの形式を表しています。

ここで「誰かがファイルを消した」とは、まだ断定できません。ファイルを置き忘れた、名前が違う、アプリが想定と違うフォルダーを探している、といった可能性があります。

次は手順書や設定と照らし合わせ、実際のファイルの置き場所・名前と、アプリが探す場所が一致しているかを確認します。自分で確認できない部分は、ログと一緒に担当者へ伝えましょう。

初心者が注意したいポイント

ログを見た直後に設定を変えるより、まず記録を残すことが大切です。次の点を意識すると、調査を進めやすくなります。

• エラーの1行だけでなく、日時や前後の関連する記録も残す。長いエラーを途中で切ると、手がかりが失われることがあります。
• 元のログは編集・削除しない。必要な部分を、チームが決めた保管先に保存します。
• 本番環境の再起動や設定変更は、担当者と手順を確認して進める。調査のための再操作も、重複登録などの影響がないか先に確認します。
• ログを外部へ貼る前に、個人情報・パスワード・アクセス用の秘密の文字列などが含まれていないか確認する。

検索や翻訳、AIへの相談では、社内の利用ルールに従い、会社名や個人情報を除いたエラー名・一般的な文面を使います。たとえば「Python FileNotFoundError No such file or directory」のように検索できます。機密情報の扱いについてはOWASPのログに含めないデータの指針も参考になります。

分からないときの相談メモ

原因を特定できなくても、確認した事実が伝われば調査は進みます。次の例を、自分の状況に置き換えて使ってください。

【日時】9月12日 14:32ごろ（日本時間）
【環境】テスト用の画面
【操作】「レポート作成」を押した
【結果】作成に失敗したと表示された
【ログの場所】チーム指定のログ閲覧画面
【ログ】14:32:09 ERROR／request_id=abc123
FileNotFoundError:
No such file or directory: 'sales.csv'
【確認済み】同じ番号で開始と失敗の記録がある
【未確認】ファイルの配置と、アプリが探す場所
【相談】この2点の確認方法を教えてください

実際に相談するときは、共有が許可された場所で前後のログも添えます。まだ確認していないことを「確認済み」と書かず、事実と推測を分けましょう。

よくある疑問

英語が苦手でも読めますか？

はい。まず日時、エラー名、対象のファイル名を拾えば、調査の入り口になります。全文を一度に訳すより、短いエラー文の意味を確かめましょう。翻訳の結果だけで原因を決めず、実際の操作や設定と照らし合わせてください。

ERRORが見つからなければ問題なしですか？

問題なしとは判断できません。見る場所・時間帯が違う、表示の絞り込みで隠れている、記録する設定になっていない、といった場合もあります。古い記録が別ファイルに分かれていることもあるため、対象期間のログか確認しましょう。

見つからない場合は、発生日時と操作を添えて担当者へ相談します。詳しいログを出す設定への変更は、手順を確認してから行ってください。

長いエラーは上と下のどちらから読みますか？

すべてに共通する向きはありません。Pythonの一般的なTracebackでは、末尾にエラーの種類と説明が出ます。ただし、複数のエラーがつながって表示される場合もあります。

まず種類と説明を探し、その前後のファイル名や行番号を確認してください。「一番下が必ず根本原因」と覚えるのではなく、関連するまとまりを残して読むことが大切です。

まとめ・関連記事

エラーログは、発生日時 → エラーの文面 → 発生場所 → 前後の流れの順で確認すると、読む範囲を絞りやすくなります。

最初の目標は、すべてを理解してすぐに直すことではありません。自分の操作に関係する記録を見つけ、「何が分かったか」「何が未確認か」を整理できれば、次の調査や相談につながります。

• エラーが出たら何から確認する？慌てないための対処手順5ステップ：ログ確認を含む、対処全体の流れを知りたい方へ。
• デバッグとは？意味やテストとの違いを初心者向けにやさしく解説！：原因を調べ、修正する作業の意味を知りたい方へ。