ログレベルの使い分け｜ERROR・WARN・INFO・DEBUGの判断基準とログ設計

ログレベルとは、ログの「重要度」を表す区分です。ERROR・WARN・INFO・DEBUGなどのレベルを正しく使い分けると、障害のときに本当に見るべきログがすぐに見つかり、必要なときだけ人に通知できるようになります。

逆に、使い分けがあいまいだと、ERRORが毎日大量に出て誰も見なくなる、障害が起きたのに手がかりになるログがない、といった状態になりがちです。この記事では、各レベルの意味を整理したうえで、迷ったときの判断フローと、20の具体例、そしてJSON形式の構造化ログや、出してはいけない情報など、ログ設計の実務まで解説します。

ログレベルの早見表

レベルは TRACE < DEBUG < INFO < WARN < ERROR < FATAL の順に重要になります。出力のレベルを INFO に設定すると、INFO以上（INFO・WARN・ERROR・FATAL）が出力され、DEBUG・TRACEは出力されません。

迷ったときの判断フロー

判断の軸は、「このログを見た人が、何をすべきか」です。ERRORなら「対応する」、WARNなら「気にかける」、INFOなら「記録として残す」。対応が必要ないものをERRORにしないことが、使い分けで最も大切なルールです。

このログは何レベル？ 20の具体例

利用者の入力の誤り（#7・#9・#10）をERRORにしないのがポイントです。ERRORは「システム側が対応すべきこと」に限ると、ERRORの通知が来たときに必ず対応する、という運用ができます。

アラートとの対応を決める

ログレベルは、アラートのルールとセットで決めると意味を持ちます。「ERRORが出たら必ず誰かが見る」という約束があるからこそ、ERRORの基準を厳しく守る意味が出てきます。

環境ごとの出力レベル

本番で調査が必要になったときに、再起動せずに特定のクラスだけDEBUGに切り替えられる仕組み（Spring Bootの Actuator など）を用意しておくと便利です。

何をログに出すか

調査に役立つログには、次の情報が含まれています。

「何が起きたか」だけでなく、「どのデータで、どのリクエストで」がわかるようにしておくと、障害の調査が大きく早くなります。

構造化ログ（JSON形式）

ログをJSON形式で出すと、ログの管理サービス（CloudWatch Logs、Datadogなど）で、項目ごとに検索・集計できます。PythonでJSON形式のログを出力した実行結果です。

{"time": "2026-09-28T21:58:39+0900", "level": "INFO", "logger": "order", "message": "注文を受け付けました", "request_id": "req-7f3a", "user_id": 42, "order_id": 123, "duration_ms": 85}
{"time": "2026-09-28T21:58:39+0900", "level": "WARNING", "logger": "order", "message": "外部APIの応答が遅い（再試行1回目）", "request_id": "req-7f3a", "user_id": 42, "duration_ms": 3200}
{"time": "2026-09-28T21:58:39+0900", "level": "INFO", "logger": "order", "message": "確認メールを送信しました: t***@example.com", "request_id": "req-7f3a", "user_id": 42}
{"time": "2026-09-28T21:58:39+0900", "level": "ERROR", "logger": "order", "message": "決済金額の計算に失敗しました", "request_id": "req-7f3a", "user_id": 42, "order_id": 123, "error": "ZeroDivisionError: division by zero"}

• 出力レベルをINFOにしているため、同じプログラムで出したDEBUGのログ（SQLの内容）は出力されていません
• 3行目のメールアドレスは、マスキングの仕組みで t***@example.com に置き換えています
• request_id で検索すると、1つのリクエストの流れをまとめて追えます

"注文 123 を受け付けました" のように値を文章に埋め込むより、"order_id": 123 のように項目として分けると、「order_id=123 のログをすべて表示」といった検索ができます。

ログに出してはいけない情報

ログは、多くの人が見られる場所に、長期間保存されることが多いデータです。「リクエストのJSONをそのままログに出す」書き方は、意図せず個人情報やパスワードを残す原因になります。出す項目を選ぶ、マスキングの仕組みを入れるのが基本です。

Java（SLF4J）での書き方

private static final Logger log = LoggerFactory.getLogger(OrderService.class);

// ○ プレースホルダーを使う
log.info("注文を受け付けました orderId={} quantity={}", order.id(), order.quantity());

// × 文字列の連結（DEBUGが無効でも、文字列の組み立てが実行される）
log.debug("注文の詳細: " + order.toDetailString());

// ○ 例外は最後の引数に渡す（スタックトレースが出力される）
log.error("決済に失敗しました orderId={}", order.id(), e);

リクエストIDは、MDC（Mapped Diagnostic Context）に入れておくと、そのリクエストの処理中に出したすべてのログに、自動で付けられます。

よくある失敗

よくある質問

Q. WARNとERRORの境目がわかりません。 A. 「人がすぐに対応する必要があるか」で分けるのがおすすめです。処理が失敗して利用者に影響が残るならERROR、処理は続けられたが気にかけておきたいならWARNです。チームで具体例の表を作っておくと、判断がぶれにくくなります。

Q. ログはどれくらいの期間、保存すればいいですか？ A. 業務や契約、法令の要件によって異なります。調査用のログは数週間〜数か月、監査が必要なログは年単位など、ログの種類ごとに保存期間を決め、費用とのバランスを取ります。

Q. 本番でDEBUGを出したままにしてもいいですか？ A. ログの量が大きく増え、費用や性能に影響するほか、詳しい情報が出るぶん機密情報が含まれるリスクも高まります。調査のときだけ、対象を絞って一時的に有効にするのがおすすめです。

まとめ

• ログレベルは、「このログを見た人が何をすべきか」で決める
• ERRORは人の対応が必要なものだけ。利用者の入力の誤りはERRORにしない
• WARNは「処理は続いたが想定外」、INFOは「正常な節目」、DEBUGは「調査用」
• アラートのルールとセットで決める
• ログにはリクエストIDと業務のIDを含め、JSON形式の構造化ログで検索しやすくする
• パスワード・カード番号・個人情報は出さない。マスキングの仕組みを入れる

株式会社RJCでは、運用まで見据えたシステムづくりの工夫を、プロジェクトの中で仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。