Java標準ライブラリ「java.util.logging」を徹底解説！

アプリケーション開発において、System.out.println を使ってデバッグ情報を出力することは、手軽で直感的な方法です。しかし、商用環境や長期的な運用を視野に入れると、この方法には多くの限界が訪れます。

• 出力のON/OFFができない: デバッグが完了した後、すべての println を削除またはコメントアウトする必要があります。
• 出力レベルの制御ができない: 「通常のエラー」と「致命的なエラー」を区別して出力することが困難です。
– 出力先の変更が難しい: コンソールだけでなく、ファイルやネットワークなど、様々な場所に出力したいという要求に柔軟に対応できません。
• パフォーマンスへの影響: 大量の文字列結合を伴う出力は、アプリケーションのパフォーマンスを低下させる可能性があります。

これらの課題を解決するために存在するのが、ロギングフレームワークです。Javaには、標準で java.util.logging (以下、JUL) という強力なロギングAPIが用意されています。この記事では、JULの基本的な使い方から、その内部構造、カスタマイズ方法、そして実践的な活用術までを深く掘り下げて解説します。

JULを使用するための最初のステップは、Logger のインスタンスを取得することです。Logger.getLogger() メソッドを使用し、引数にはロガー名を指定します。一般的には、クラス名を指定することが推奨されています。

import java.util.logging.Level;
import java.util.logging.Logger;
public class BasicLoggingExample { // クラス名でロガーを取得するのが一般的 private static final Logger logger = Logger.getLogger(BasicLoggingExample.class.getName()); public static void main(String[] args) { // ログメッセージを出力する // 深刻なエラーを示す logger.severe("これはSEVEREレベルのメッセージです。"); // 警告を示す logger.warning("これはWARNINGレベルのメッセージです。"); // 一般的な情報を示す logger.info("これはINFOレベルのメッセージです。"); // 詳細なデバッグ情報（デフォルトでは表示されないことが多い） logger.fine("これはFINEレベルのメッセージです。"); // logメソッドを使うと、レベルを動的に指定できる logger.log(Level.CONFIG, "設定に関するメッセージです。"); }
}

JULには、重要度の高い順に7つの標準レベルが定義されています。加えて、すべてのログを有効にする ALL と、すべて無効にする OFF が存在します。

レベルによるフィルタリングの仕組み

ログが出力されるかどうかは、以下の2段階で判断されます。

1. Loggerのレベル: まず、発行されたログのレベルが、そのLoggerインスタンスに設定されたレベル以上であるかを確認します。そうでなければ、その時点で処理は中断されます。
2. Handlerのレベル: Loggerのレベルをクリアした場合、次にHandlerに設定されたレベル以上であるかを確認します。これをクリアして初めて、ログが出力されます。

JULには、いくつかの標準Handlerが用意されています。

• ConsoleHandler: システムエラー出力 (System.err) にログを出力します。デフォルトでルートロガーに設定されています。
• FileHandler: ログをファイルに出力します。ファイルのローテーション機能も備えています。
• StreamHandler: 任意の OutputStream にログを出力します。
• SocketHandler: ネットワーク経由で指定したホストとポートにログを送信します。
• MemoryHandler: メモリ上のリングバッファにログを保持し、特定のトリガー（例: SEVEREレベルのログ発生）があった場合に、指定した別のHandlerに出力します。

実践例: FileHandlerでログをファイルに保存する

FileHandler は、アプリケーションのログを永続化する際に非常に便利です。

import java.io.IOException;
import java.util.logging.FileHandler;
import java.util.logging.Level;
import java.util.logging.Logger;
import java.util.logging.SimpleFormatter;
public class FileHandlerExample { private static final Logger logger = Logger.getLogger(FileHandlerExample.class.getName()); public static void main(String[] args) { try { // デフォルトのConsoleHandlerを無効にする // これをしないとコンソールとファイルの両方に出力される logger.setUseParentHandlers(false); // FileHandlerのインスタンスを作成 // %t: システムの一時ディレクトリ, %u: 競合回避のためのユニークな番号, %g: 世代番号 // 1024*1024: ファイルサイズ上限(1MB), 5: ファイル数, true: 追記モード FileHandler fileHandler = new FileHandler("%t/myapp-log.%u.%g.log", 1024 * 1024, 5, true); // 出力フォーマットを設定 fileHandler.setFormatter(new SimpleFormatter()); // ハンドラのログレベルを設定 fileHandler.setLevel(Level.ALL); // LoggerにHandlerを追加 logger.addHandler(fileHandler); // Loggerのレベルを設定（これより低いレベルのログはHandlerに渡されない） logger.setLevel(Level.INFO); logger.info("アプリケーションを開始しました。"); logger.warning("設定ファイルが見つかりません。デフォルト値を使用します。"); logger.fine("このメッセージはファイルには記録されません。"); // LoggerのレベルがINFOのため logger.severe("データベース接続に失敗しました。"); } catch (IOException e) { logger.log(Level.SEVERE, "FileHandlerの初期化に失敗しました。", e); } }
}

Formatterは、LogRecordオブジェクトを受け取り、人間が読める文字列に変換します。標準では2つのFormatterが提供されます。

• SimpleFormatter: 1行のシンプルなテキスト形式で出力します。デフォルトの書式は java.util.logging.SimpleFormatter.format プロパティで変更可能です。
• XMLFormatter: DTDに準拠した詳細なXML形式で出力します。ログを他のシステムで解析する場合に便利です。

SimpleFormatterの書式をカスタマイズする

SimpleFormatter のデフォルト書式は、時として情報が不足していたり、冗長だったりします。書式はシステムプロパティまたはロギング設定ファイルで変更できます。

例えば、以下のような書式を指定できます。

# [日時] [ロガー名]
# [レベル]: メッセージ
java.util.logging.SimpleFormatter.format = [%1$tY-%1$tm-%1$td %1$tH:%1$tM:%1$tS.%1$tL] [%4$s] %2$s: %5$s%6$s%n

各プレースホルダの意味は以下の通りです。

• %1$t...: LogRecordの日時 (java.util.Formatter形式)
• %2$s: ロガー名
• %3$s: ソース（不明な場合はロガー名）
• %4$s: ログレベル
• %5$s: フォーマットされたメッセージ
• %6$s: 例外のスタックトレース
• %n: プラットフォーム依存の改行コード

この設定を適用すると、ログ出力は以下のようになります。

[2025-07-12 01:24:00.123] [SEVERE] com.example.MyClass: データベース接続に失敗しました。
java.sql.SQLException: 接続タイムアウト at ...

ロガーは、その名前によって親子関係を持つことができます。例えば、com.example.service というロガーは、com.example ロガーの子であり、com ロガーの孫となります。この階層構造には、重要な特性があります。

• レベルの継承: あるロガーにレベルが明示的に設定されていない場合、親のレベルを継承します。どの親にも設定がなければ、最終的にルートロガーのレベル（デフォルトはINFO）が適用されます。
• Handlerの継承: デフォルトでは、ロガーに記録されたログは、そのロガーにアタッチされたHandlerだけでなく、親のHandlerにも伝播していきます。この動作は logger.setUseParentHandlers(false) で無効にできます。

この仕組みを利用すると、非常に効率的な設定が可能です。

public class LoggerHierarchyExample { public static void main(String[] args) { // 親ロガー Logger parentLogger = Logger.getLogger("com.example"); parentLogger.setLevel(Level.WARNING); // 子ロガー Logger childLogger = Logger.getLogger("com.example.service"); // 子ロガーにはレベルを設定していないが、親のWARNINGを継承する childLogger.info("このメッセージは出力されない (INFO < WARNING)"); childLogger.warning("このメッセージは出力される (WARNING >= WARNING)"); }
}

Javaの実行環境は、起動時に logging.properties という設定ファイルを読み込み、ロギングシステムを構成します。このファイルは通常、JREの lib ディレクトリに置かれていますが、JVMの起動オプションで独自のファイルを指定することもできます。

java -Djava.util.logging.config.file=/path/to/my-logging.properties -cp . com.example.MyApp

logging.properties の書き方

以下は、実践的な設定ファイルの例です。

# ルートロガーに適用するハンドラを指定
# この例では、コンソールとファイルの両方に出力
handlers = java.util.logging.ConsoleHandler, java.util.logging.FileHandler
# すべてのロガーのデフォルトレベル
.level = INFO
# ---- ConsoleHandlerの設定 ----
java.util.logging.ConsoleHandler.level = INFO
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
# ---- FileHandlerの設定 ----
java.util.logging.FileHandler.level = ALL
java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter
java.util.logging.FileHandler.pattern = /var/log/myapp/application-%g.log
java.util.logging.FileHandler.limit = 50000
java.util.logging.FileHandler.count = 5
java.util.logging.FileHandler.append = true
# ---- 特定のパッケージのロガーレベルを設定 ----
# com.example.data パッケージ以下は、より詳細なログを出力する
com.example.data.level = FINE
# 特定のクラスのログは出力を抑制する
com.example.noisy.ThirdPartyClass.level = WARNING

JULはJavaの標準APIであり、追加のライブラリ依存なしに使えるという大きなメリットがあります。しかし、多くの大規模プロジェクトでは、SLF4J というロギングファサードと、その実装である Logback や Log4j 2 が好んで使われます。その理由とJULの立ち位置を比較してみましょう。

JULの使いどころ

以上の比較から、JULが特に適しているのは以下のようなケースです。

• 小規模なアプリケーションやツール: 外部ライブラリへの依存を増やしたくない場合。
• Java SE環境で完結するライブラリ: ライブラリ利用者に特定のロギング実装を強制したくない場合。
• Java EE / Jakarta EE 環境: アプリケーションサーバーが標準でJULの高度なインテグレーションを提供している場合。

一方で、多数のライブラリが混在する大規模なアプリケーションでは、SLF4Jを使ってロギング実装を統一するアプローチが一般的です。幸い、jul-to-slf4j というブリッジライブラリを使えば、JULのAPI呼び出しをSLF4J経由にリダイレクトすることも可能です。

java.util.logging は、単なる System.out.println の代替ではありません。Logger, Handler, Formatter, Level といったコンポーネントからなる、柔軟で強力なフレームワークです。その階層構造と外部設定ファイルの仕組みを理解すれば、コードの可読性や保守性を損なうことなく、アプリケーションの振る舞いを詳細に把握することが可能になります。

他の高機能なロギングフレームワークが存在する中でも、Java標準であるというJULの強みは揺るぎません。依存関係をシンプルに保ちたい場合や、Javaの基本的な機能を深く学びたい開発者にとって、JULは依然として価値のある選択肢です。この記事が、あなたのロギング戦略を一段階引き上げる一助となれば幸いです。