ログレベルとは、各ログエントリに付ける重大度のラベルで、「何を記録し、何を表示し、何をアラートにするか」を制御します。標準的な規格では DEBUG、INFO、WARN、ERROR、FATAL の 5 段階があり、重大度が順に上がります。 レベル体系の核心的価値は、平常時はノイズを最小に抑えつつ、問題発生時にはレベルで素早く絞り込んでアラートできることです。
5 つの標準レベル早見表
| レベル | 意味 | 典型的な内容 | 本番環境 | アラート |
|---|---|---|---|---|
| DEBUG | デバッグ詳細 | 変数値、SQL 文、関数の引数 | オフ | なし |
| INFO | 正常なビジネス節目 | ログイン、注文作成、タスク開始 | オン | なし |
| WARN | 異常だが自動回復 | リトライ成功、フォールバック発動、低速リクエスト | オン | 集約して人間が確認 |
| ERROR | 操作が失敗し現在の処理に影響 | API 5xx、決済失敗、ヌルポインタ | オン | あり |
| FATAL | システム全体が使用不可 | DB に接続できない、サービスが起動しない | オン | あり（P0 対応） |
各レベルの判断基準
実務では、ログが足りないことよりレベルの誤用のほうがよく起きます。実行可能な判断基準は次のとおりです。DEBUG：開発者本人が見るためのもの
- 判断基準：システムが正常に動いている間は何の価値もなく、特定のバグ調査のときだけ役立つ情報；
- 典型的な内容：関数の引数と戻り値、途中計算結果、キャッシュヒット状況；
- 重要原則：本番環境ではデフォルトでオフ。削除ではなくフィルタしておく——問題発生時に一時的にオンにできます。
INFO：「システムが何をしているか」を見る人のためのもの
- 判断基準：半年後にこのログを読み返して、ユーザーの操作の軌跡を復元できる；
- 典型的な内容：重要なビジネスアクション（登録、注文、公開）、タスクの開始/終了と所要時間；
- 逆の例：HTTP 200 をすべて INFO で記録する——それはアクセスログの仕事であり、ビジネスログを汚染しないこと。
WARN：異常は起きたが、システムが持ちこたえた
- 判断基準：誰かが知るべきだが、夜中に飛び起きる必要はないもの；
- 典型的な内容：リトライ後の成功、レート制限/フォールバックの発動、しきい値超えのレイテンシ；
- リスクサイン：WARN の急増は ERROR の前触れであることが多い。トレンド監視につなげましょう。
ERROR：ユーザーの操作が失敗した
- 判断基準：直さなければ、ユーザーは再び同じ問題に当たる；
- 典型的な内容：外部サービス呼び出しの失敗、データ検証の例外、未捕捉例外；
- 重要な要件：すべての ERROR にコンテキストを付ける（URL、ユーザー/テナント ID、リクエストパラメータ、スタックトレース）。なければ対処不能なノイズにすぎません。
FATAL：システムがすでに落ちている
- 判断基準：サービス全体として正常な提供が不可能；
- 典型的な内容：DB 接続失敗、必須設定の欠落、起動失敗；
- 実務のコツ：Web アプリで FATAL は稀です。多くの「システムダウン」は ERROR の大量発生として現れるので「ERROR 急増アラート」でカバーし、FATAL を濫用して重大度を薄めないこと。
ブラウザ Console のログレベル
フロントエンドのレベルはバックエンドと同名ですが、できることは違います。Console がネイティブにサポートするのは次のとおりです。| メソッド | Console 上のレベル | 用途 |
|---|---|---|
console.debug() |
Debug（デフォルト非表示。Verbose を有効化） | 開発中のデバッグ |
console.log() |
Info | 通常出力 |
console.info() |
Info | 同上。意図を明示する書き方 |
console.warn() |
Warning、黄色 | 回復可能な問題のヒント |
console.error() |
Error、赤、スタックトレース付き | 失敗と未捕捉例外 |
console.log ではなく console.debug で書く——本番ビルドではデフォルトフィルタで自動的に隠れ、手動の掃除が不要になります；window.onerror / unhandledrejection）はデフォルトで ERROR レベルであり、本番調査の最初の手がかりになります。フロントエンド特有の難題：ユーザーはログを取ってくれない
バックエンドのログはサーバーに集約され、問題発生時にいつでも見られます。フロントエンドのログはユーザー一人ひとりのブラウザの中に散らばります。ユーザーが「ページが壊れた」と報告しても、Console エラーと失敗したリクエストはそのページセッションとともに消えます。ユーザーがチュートリアルに従って DevTools を開く頃（手順はブラウザコンソールの開き方）には、リロードでエラーはすでに流れ去っています。 したがってフロントエンドのログ戦略が答えるべき問いは「レベルをどう振り分けるか」ではなく、「壊れた瞬間のログをどう残すか」です。代表的な方式：| 方式 | 仕組み | 代償 |
|---|---|---|
| 自前の送信 | console の全出力をサーバーへ送り返す | ストレージ/プライバシーコストが高く、サンプリングの調整も難しい |
| フロント監視プラットフォーム | 全量収集＋セッションリプレイ | 従量課金で中小チームには高額 |
| オンデマンド収集（バグレポートに添付） | ユーザーがフィードバックを送信する際、その瞬間の Console/Network エラーが自動で添付される | コスト最小。「ユーザーからの自発的報告」という最大の情報源をカバー |
よくある誤り
| 誤り | 正しいやり方 |
|---|---|
すべて console.log で、公開後も掃除しない |
レベルを分ける：デバッグは debug、ビジネス節目は info、ビルド時に debug を落とす |
| 失敗を「運用を怖がらせないように」と INFO で記録 | 失敗は ERROR。アラートはレベルに依存するのであって、人がログを読むことに依存してはならない |
| ERROR がメッセージだけでコンテキストなし | URL、パラメータ、スタックトレースを必ず添付。なければ何も記録していないのと同じ |
| 調査の便利さから全ログで DEBUG をオン | レベルはフィルタです。普段は DEBUG をオフにし、問題発生時に必要な範囲だけオンに |
| WARN が大量に滞留し誰も手をつけない | WARN をトレンドアラートにつなぐ。急増は ERROR の前兆 |