SLF4J＋Logback設定｜logback.xmlテンプレートとローテーション

SLF4J＋Logbackとは、コードはSLF4J（ログの共通API）だけに書き、出力先・書式・保存期間はLogbackの設定ファイル logback.xml で決める、Javaの定番ログ構成です。コードを変えずに「開発はコンソールにDEBUGまで」「本番はファイルに日付とサイズでローテーション」と切り替えられます。

この記事では、SLF4J 2.x＋Logback 1.5系（後継の1.6系もそのまま使えます）向けに、コピペで使える開発用・本番用 logback.xml の全文、パターン書式の一覧、{} と文字列連結の違い、「ログが出ない」原因一覧までをまとめました。コードと設定は Java 21.0.10 で実際に動かし、出力をそのまま掲載しています。

動作確認環境：OpenJDK 21.0.10、slf4j-api 1.7.32、logback-classic 1.2.11（Ubuntu の apt パッケージ）。SLF4J 2.x／Logback 1.5・1.6 で異なる箇所は、公式ドキュメントで確認した内容を注記しています。appender・rollingPolicy・encoder・パターンの書き方は1.2と1.5で共通です。Java 25 でも書き方は変わりません（Logback 1.6 は JDK 11 以上で動作と公式に記載。Java 25 での実行は未確認）。

SLF4J＋Logback設定の早見表

SLF4JとLogbackの関係

SLF4Jは「ログを書く窓口（API）」、Logbackは「実際に書き出す実装」です。アプリもライブラリもSLF4Jにだけ依存し、実装はクラスパスに置いたものが使われます。

SLF4J 1.7 と 2.x の違い（プロバイダ方式）

SLF4J 2.0から、実装の見つけ方が「StaticLoggerBinder」から「ServiceLoader（プロバイダ）」に変わりました。公式のエラーコード解説（slf4j.org/codes.html）でも、2.0.x 以降は static binder の仕組みを参照しないと説明されています。

slf4j-api 2.x に logback 1.2 を組み合わせると、プロバイダが見つからずログが出ません。Logback 1.5／1.6 を使えば、適切な slf4j-api 2.x が推移的に入ります。

導入：依存関係と設定ファイルの読み込み順

依存関係は logback-classic を1つ書くだけです。2026-10-02時点の公式ニュースでは最新が 1.6.5、1.5系の最終が 1.5.38 です。1.6系は「1.5系のドロップイン置き換え（Janino による <if> 条件式は削除）」とされているので、1.5向けの logback.xml は1.6でもそのまま使えます。

<!-- pom.xml（Gradle なら implementation 'ch.qos.logback:logback-classic:1.5.38'） -->
<dependency>
  <groupId>ch.qos.logback</groupId>
  <artifactId>logback-classic</artifactId>
  <version>1.5.38</version>
</dependency>

Logback は次の順で設定を探し、最初に見つかったものを使います（Logback 1.5 公式マニュアル）。

設定ファイルなしで実行すると6番になり、DEBUG まで出ます。

04:51:42.056 [main] DEBUG OrderApp - 注文を受け付けました: Order[id=A-100, qty=3]
04:51:42.071 [main] INFO OrderApp - 注文を確定しました id=A-100 qty=3

本番で DEBUG が大量に出るときは、logback.xml がクラスパスに入っていない可能性が高いです。

基本：ロガーの作り方とログの書き方

コピペで動くサンプル（OrderApp.java）

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.slf4j.MDC;

public class OrderApp {
    private static final Logger log = LoggerFactory.getLogger(OrderApp.class);

    record Order(String id, int qty) {}

    public static void main(String[] args) {
        MDC.put("requestId", "req-0001");
        MDC.put("userId", "u-42");
        try {
            Order order = new Order("A-100", 3);
            log.trace("trace: {}", order);
            log.debug("注文を受け付けました: {}", order);
            log.info("注文を確定しました id={} qty={}", order.id(), order.qty());
            log.warn("在庫が残りわずかです sku={} remaining={}", "SKU-9", 2);
            try {
                Integer.parseInt("abc");
            } catch (NumberFormatException e) {
                // 最後の引数に例外を渡すとスタックトレースが出る
                log.error("数量の変換に失敗しました input={}", "abc", e);
            }
        } finally {
            MDC.clear();
        }
        log.info("MDCクリア後のログ");
    }
}

実行は java -Dlogback.configurationFile=logback-dev.xml -cp slf4j-api.jar:logback-classic.jar:logback-core.jar OrderApp.java です（単一ファイル実行）。

ロガーは private static final でクラスごとに1つ、名前はクラスの完全修飾名にします。ロガー名がパッケージ階層になるので、<logger name="com.example.order"> のようにパッケージ単位でレベルを変えられます（Lombok の @Slf4j も同じフィールドを生成します）。

プレースホルダ {} と文字列連結の違い（実測）

{} を使うと、そのレベルが無効なときはメッセージの組み立て（toString や連結）が行われません。root=INFO（DEBUG無効）で、debug を100万回呼んで比べました。

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class CostDemo {
    private static final Logger log = LoggerFactory.getLogger(CostDemo.class);
    static int toStringCalls = 0, heavyCalls = 0;

    static class Item {
        @Override public String toString() { toStringCalls++; return "Item#1"; }
    }
    static String heavy() { heavyCalls++; return "heavy-result"; }

    public static void main(String[] args) {
        Item item = new Item();
        long t0 = System.nanoTime();
        for (int i = 0; i < 1_000_000; i++) log.debug("連結: " + item + " i=" + i);
        System.out.printf("文字列連結      : %4d ms, toString=%d回%n", (System.nanoTime() - t0) / 1_000_000, toStringCalls);

        toStringCalls = 0;
        t0 = System.nanoTime();
        for (int i = 0; i < 1_000_000; i++) log.debug("プレースホルダ: {} i={}", item, i);
        System.out.printf("プレースホルダ  : %4d ms, toString=%d回%n", (System.nanoTime() - t0) / 1_000_000, toStringCalls);

        for (int i = 0; i < 3; i++) log.debug("結果: {}", heavy());
        System.out.printf("{} でも heavy() は %d回 呼ばれた%n", heavyCalls);

        heavyCalls = 0;
        for (int i = 0; i < 3; i++) {
            if (log.isDebugEnabled()) log.debug("結果: {}", heavy());
        }
        System.out.printf("isDebugEnabled で囲むと heavy() は %d回%n", heavyCalls);
    }
}

実行結果（3回実行し、連結は171〜329ms、プレースホルダは11〜18msでした）：

文字列連結      :  319 ms, toString=1000000回
プレースホルダ  :   11 ms, toString=0回
{} でも heavy() は 3回 呼ばれた
isDebugEnabled で囲むと heavy() は 0回

{} は toString を遅らせるだけで、引数の式（heavy()）は評価されます。重い処理を引数に書くときは isDebugEnabled() で囲みます。

例外は最後の引数に渡す

上の CostDemo の main メソッドの末尾に次のコードを追加して実行した結果です。

Exception e = new IllegalStateException("在庫数が負になりました");
log.error("①メッセージだけ: " + e);
log.error("②{} に例外: {}", "SKU-1", e.getMessage());
log.error("③最後の引数に例外 sku={}", "SKU-1", e);

ERROR CostDemo - ①メッセージだけ: java.lang.IllegalStateException: 在庫数が負になりました
ERROR CostDemo - ②SKU-1 に例外: 在庫数が負になりました
ERROR CostDemo - ③最後の引数に例外 sku=SKU-1
java.lang.IllegalStateException: 在庫数が負になりました
    at CostDemo.main(CostDemo.java:41)
    ...

スタックトレースが出るのは③だけです。SLF4J は「{} の数より引数が1つ多く、最後が Throwable なら例外として扱う」ので、catch したら log.error("説明 key={}", value, e) の形にそろえます。例外処理の全体像は「Javaの例外処理」記事も参考にしてください。

SLF4J 2.x の fluent API（公式で確認・未実行）

手元の slf4j-api 1.7 にはないため、SLF4J 公式マニュアルに沿って記載します。

log.atInfo()
   .setMessage("注文を確定しました")
   .addKeyValue("orderId", order.id())
   .addKeyValue("qty", order.qty())
   .log();

log.atDebug().setMessage("集計結果={}").addArgument(() -> heavy()).log(); // 無効時は計算されない
log.atError().setCause(e).log("在庫の更新に失敗しました sku={}", sku);

addKeyValue は JSON 出力と相性がよく、後述の JsonEncoder では kvpList に出力されます。従来の log.info("...{}", x) も 2.x でそのまま使えます。

開発用 logback.xml（全文）

開発用は「コンソールに色つき、自分のパッケージは DEBUG まで」が使いやすい設定です。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>%d{HH:mm:ss.SSS} %highlight(%-5level) [%thread] %cyan(%logger{36}) - %msg [%X{requestId}]%n</pattern>
      <charset>UTF-8</charset>
    </encoder>
  </appender>

  <!-- 自分のコードだけ DEBUG（普段は com.example などパッケージ名） -->
  <logger name="OrderApp" level="DEBUG"/>

  <root level="INFO">
    <appender-ref ref="CONSOLE"/>
  </root>
</configuration>

実行結果（実際はレベル名とロガー名に色が付きます。色コードは除いて掲載）：

04:49:52.253 DEBUG [main] OrderApp - 注文を受け付けました: Order[id=A-100, qty=3] [req-0001]
04:49:52.275 INFO  [main] OrderApp - 注文を確定しました id=A-100 qty=3 [req-0001]
04:49:52.275 WARN  [main] OrderApp - 在庫が残りわずかです sku=SKU-9 remaining=2 [req-0001]
04:49:52.282 ERROR [main] OrderApp - 数量の変換に失敗しました input=abc [req-0001]
java.lang.NumberFormatException: For input string: "abc"
    at OrderApp.main(OrderApp.java:20)
    ...
04:49:52.283 INFO  [main] OrderApp - MDCクリア後のログ []

TRACE は OrderApp のレベルが DEBUG なので出ません。レベルは TRACE < DEBUG < INFO < WARN < ERROR の順で、設定したレベル以上だけが通ります。どのレベルに何を書くかは、別記事「ログレベルの使い分け」で扱っています。

本番用 logback.xml（全文テンプレート）

本番用は「ファイルに書く・日付とサイズで分割・自動削除・非同期・ERRORは別ファイル」をまとめます。値は ${名前:-既定値} で、システムプロパティや環境変数から上書きできます。

<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true" scanPeriod="60 seconds">
  <property name="LOG_DIR" value="${LOG_DIR:-logs}"/>
  <property name="APP_NAME" value="${APP_NAME:-order-app}"/>
  <property name="PATTERN"
            value="%d{yyyy-MM-dd'T'HH:mm:ss.SSSXXX} %-5level [%thread] %logger{40} [req=%X{requestId:-none} user=%X{userId:-none}] - %msg%n"/>

  <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>${LOG_DIR}/${APP_NAME}.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
      <!-- 日付ごと、maxFileSize を超えたら .0 .1 ... と分割し gzip 圧縮 -->
      <fileNamePattern>${LOG_DIR}/${APP_NAME}.%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>
      <maxFileSize>${LOG_MAX_FILE_SIZE:-100MB}</maxFileSize>
      <maxHistory>${LOG_MAX_HISTORY:-30}</maxHistory>
      <totalSizeCap>${LOG_TOTAL_SIZE_CAP:-3GB}</totalSizeCap>
      <cleanHistoryOnStart>true</cleanHistoryOnStart>
    </rollingPolicy>
    <encoder>
      <pattern>${PATTERN}</pattern>
      <charset>UTF-8</charset>
    </encoder>
  </appender>

  <!-- ERROR だけ別ファイルにも出す -->
  <appender name="ERROR_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>${LOG_DIR}/${APP_NAME}-error.log</file>
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
      <level>ERROR</level>
    </filter>
    <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
      <fileNamePattern>${LOG_DIR}/${APP_NAME}-error.%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>
      <maxFileSize>50MB</maxFileSize>
      <maxHistory>90</maxHistory>
      <totalSizeCap>1GB</totalSizeCap>
    </rollingPolicy>
    <encoder>
      <pattern>${PATTERN}</pattern>
      <charset>UTF-8</charset>
    </encoder>
  </appender>

  <!-- 書き込みを別スレッドに任せる -->
  <appender name="ASYNC_FILE" class="ch.qos.logback.classic.AsyncAppender">
    <queueSize>8192</queueSize>
    <discardingThreshold>0</discardingThreshold>
    <neverBlock>false</neverBlock>
    <includeCallerData>false</includeCallerData>
    <appender-ref ref="FILE"/>
  </appender>

  <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
      <level>WARN</level>
    </filter>
    <encoder>
      <pattern>${PATTERN}</pattern>
      <charset>UTF-8</charset>
    </encoder>
  </appender>

  <logger name="org.apache" level="WARN"/>
  <logger name="com.zaxxer.hikari" level="INFO"/>

  <root level="${LOG_LEVEL:-INFO}">
    <appender-ref ref="ASYNC_FILE"/>
    <appender-ref ref="ERROR_FILE"/>
    <appender-ref ref="CONSOLE"/>
  </root>

  <!-- 終了時に Logback を止め、非同期キューを書き切る（1.3以降の書き方） -->
  <shutdownHook/>
</configuration>

java -Dlogback.configurationFile=/etc/order-app/logback.xml \
     -DLOG_DIR=/var/log/order-app -DLOG_LEVEL=INFO -jar order-app.jar

OrderApp をこの設定で動かした logs/order-app.log の中身です（1.2.11 では shutdownHook の行を後述のとおり書き換えて実行）。

2026-10-02T04:49:55.957+09:00 INFO  [main] OrderApp [req=req-0001 user=u-42] - 注文を確定しました id=A-100 qty=3
2026-10-02T04:49:55.975+09:00 WARN  [main] OrderApp [req=req-0001 user=u-42] - 在庫が残りわずかです sku=SKU-9 remaining=2
2026-10-02T04:49:55.992+09:00 ERROR [main] OrderApp [req=req-0001 user=u-42] - 数量の変換に失敗しました input=abc
java.lang.NumberFormatException: For input string: "abc"
    ...
2026-10-02T04:49:55.992+09:00 INFO  [main] OrderApp [req=none user=none] - MDCクリア後のログ

コンソールには WARN と ERROR だけが出て、ERROR は order-app-error.log（813バイト）にも書かれました。MDC クリア後は %X{requestId:-none} の既定値 none になっています。

shutdownHook はバージョンで書き方が違う

Logback 1.3 以降は <shutdownHook/> だけで DefaultShutdownHook が使われます（公式マニュアル）。手元の 1.2.11 で同じ書き方をすると次のエラーになりました。

|-ERROR in ch.qos.logback.core.joran.action.ShutdownHookAction - Missing class name for shutdown hook. Near [shutdownHook] line 74

DefaultShutdownHook を明示しても 1.2.11 には存在せず ClassNotFoundException になります。1.2 系では <shutdownHook class="ch.qos.logback.core.hook.DelayingShutdownHook"/> と書きます。設定にエラーがあると Logback は内部ステータスを自動で表示するので、まずそこを読むのが近道です。

ローテーション：日付×サイズの動きを実行して確かめる

SizeAndTimeBasedRollingPolicy は「日付で切り替え、同じ日に大きくなったら連番で分割」します。%d と %i は両方必須です。maxFileSize を 50KB、totalSizeCap を 150KB にして、約120バイトの行を2,000行書きました。

設定は本番テンプレートの FILE アペンダーと同じ形で、<file>roll/app.log</file>、<fileNamePattern>roll/app.%d{yyyy-MM-dd}.%i.log</fileNamePattern>、maxFileSize 50KB、maxHistory 7、totalSizeCap 150KB にしています。

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class RollDemo {
    private static final Logger log = LoggerFactory.getLogger(RollDemo.class);
    public static void main(String[] args) throws Exception {
        String pad = "x".repeat(100);
        for (int i = 1; i <= 2000; i++) {
            log.info("item={} {}", i, pad);
            Thread.sleep(1);
        }
    }
}

実行後のファイルと先頭行（Logback 1.2.11）：

$ ls -l roll
-rw-r--r-- 1 root root 58368 Oct  2 04:50 app.2026-10-02.3.log
-rw-r--r-- 1 root root 58368 Oct  2 04:50 app.2026-10-02.4.log
-rw-r--r-- 1 root root 12312 Oct  2 04:50 app.log
roll/app.2026-10-02.3.log: INFO  RollDemo - item=1152
roll/app.2026-10-02.4.log: INFO  RollDemo - item=1536
roll/app.log: INFO  RollDemo - item=1920

1. 連番 .0〜.2 は totalSizeCap（150KB）を超えたため古い順に自動削除され、.3 と .4 が残りました。
2. 1ファイルが 58KB と、maxFileSize（50KB）を少し超えました。1.2系はサイズ確認を毎回は行わないためで、スリープなしで一気に書くと1ファイル148KBまで膨らみました。
3. Logback 1.5.8 以降は書き込んだバイト数を数える方式になり、checkIncrement は不要（非推奨）と公式マニュアルにあります。ただし「切り替えはログが書かれたときに行われ、一時的に超えることはある」とも書かれているので、ディスク見積もりには余裕を持たせると安心です。

OS の logrotate と Logback のローテーションはどちらか一方にします。logrotate 側で管理する場合は「logrotateの設定方法」記事を参照してください。

AsyncAppender：非同期で書くときの設定

AsyncAppender はログをキューに積み、別スレッドで書き出します。公式マニュアルで確認した既定値です。

既定のままだと混雑時に INFO が黙って捨てられます。INFO も残したいなら discardingThreshold を 0 に、アプリの応答を優先するなら neverBlock を true にします。

includeCallerData=false だと行番号が「?」になる

パターンを %-5level [%thread] %class{0}.%method:%line - %msg%n にして AsyncAppender 経由で出した結果です。

### includeCallerData=false（既定）
INFO  [main] ?.?:? - 注文を確定しました id=A-100 qty=3
WARN  [main] ?.?:? - 在庫が残りわずかです sku=SKU-9 remaining=2

### includeCallerData=true
INFO  [main] OrderApp.main:17 - 注文を確定しました id=A-100 qty=3
WARN  [main] OrderApp.main:18 - 在庫が残りわずかです sku=SKU-9 remaining=2

非同期では呼び出し元情報が既定で取得されません。取得コストがかかるため、本番は %logger とメッセージで場所がわかる書き方にし、%line は使わないのが一般的です。スレッド名と MDC は非同期でも正しく引き継がれます。

MDC：リクエストIDを全ログに付ける

MDC（Mapped Diagnostic Context）は、スレッドごとに持てる「ログ用の付箋」です。処理の入口で MDC.put すると、以降のログに %X{キー} で出せます。

MDC.put("requestId", UUID.randomUUID().toString());
try {
    chain.doFilter(request, response);
} finally {
    MDC.remove("requestId"); // スレッドの再利用で値が残らないよう必ず消す
}

finally で消すことが大切です。スレッドプールのスレッドは再利用されるため、消し忘れると別リクエストのログに前の ID が付きます。ExecutorService などに処理を渡すと MDC は別スレッドに自動では引き継がれないので、MDC.getCopyOfContextMap() で取り出し、タスク内で MDC.setContextMap() します。なお Logback 1.5.22 以降は、名前に password・secret・confidential を含む MDC キーを出力しない変更が入っています（公式ニュース）。

パターン書式の一覧（実行結果つき）

com.example.order.service.PatternDemo で log.info("在庫を引き当てました count={}", 5)（MDC に requestId=req-7）を、書式を1つずつ変えて出力した結果です。

「ログが出ない」「二重に出る」原因一覧と再現

実装がない／複数ある（SLF4J 1.7 の実行結果）

slf4j-api だけで実行すると、ログは1行も出ず警告だけが出ます。

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

slf4j-simple と logback-classic を両方置いた結果です。

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/usr/share/java/slf4j-simple.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/usr/share/java/logback-classic-1.2.11.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Actual binding is of type [org.slf4j.impl.SimpleLoggerFactory]
[main] INFO OrderApp - 注文を確定しました id=A-100 qty=3

slf4j-simple が選ばれ、logback.xml は使われていません。どちらになるかはクラスパス順で決まるため、実装は1つだけにします。SLF4J 2.x では同じ状況で No SLF4J providers were found.／Class path contains multiple SLF4J providers. が出ます（公式 codes.html。どちらも例外ではなく警告なので、起動直後の SLF4J: の行は必ず確認しましょう）。

appender-ref の名前違い

<appender-ref ref="CONSOL"/> と1文字違えた結果です。

|-ERROR in ch.qos.logback.core.joran.action.AppenderRefAction - Could not find an appender named [CONSOL]. Did you define it below instead of above in the configuration file?
...
|-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.

この後アプリのログは1行も出ませんでした。ログが出ないときは、起動直後の |-ERROR in／|-WARN in の行を探します。

同じログが2回出る（additivity）

<logger name="OrderApp" level="INFO">
  <appender-ref ref="CONSOLE"/>
</logger>
<root level="WARN"><appender-ref ref="CONSOLE"/></root>

INFO  OrderApp - 注文を確定しました id=A-100 qty=3
INFO  OrderApp - 注文を確定しました id=A-100 qty=3
WARN  OrderApp - 在庫が残りわずかです sku=SKU-9 remaining=2
WARN  OrderApp - 在庫が残りわずかです sku=SKU-9 remaining=2

ロガーのログは自分のアペンダーに書いた後、親（root）のアペンダーにも渡されます。しかも root を WARN にしても INFO が root 経由で出ています。レベル判定はログを出したロガー（OrderApp=INFO）で1回だけ行われ、親では再判定されないためです。additivity="false" を付けると各行1回になりました。レベルだけ変えたいロガーにはアペンダーを付けず <logger name="..." level="DEBUG"/> とだけ書くのが簡単な防ぎ方です。

JSONで出力する（公式で確認・未実行）

ログ収集基盤に送るなら 1行1JSON が扱いやすくなります。持たせる項目の設計は別記事「構造化ログ（JSON）設計」で扱っているので、ここでは設定方法だけ示します。手元の 1.2.11 には JsonEncoder がないため、公式ドキュメントに沿った未実行の設定です。

<!-- Logback 標準（1.3.8／1.4.8 以降）。FILE アペンダーの encoder を差し替える -->
<encoder class="ch.qos.logback.classic.encoder.JsonEncoder">
  <withFormattedMessage>true</withFormattedMessage>
  <withMessage>false</withMessage>
  <withArguments>false</withArguments>
</encoder>

<!-- logstash-logback-encoder（対応バージョンは公式 README で確認） -->
<encoder class="net.logstash.logback.encoder.LogstashEncoder">
  <customFields>{"app":"order-app"}</customFields>
</encoder>

Spring Boot の logback-spring.xml との違い

Spring Boot では logback-spring.xml という名前にすると、プロファイル切り替えや application.yml の値の参照が使えます。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <include resource="org/springframework/boot/logging/logback/defaults.xml"/>
  <include resource="org/springframework/boot/logging/logback/console-appender.xml"/>
  <springProperty scope="context" name="APP_NAME" source="spring.application.name" defaultValue="app"/>

  <springProfile name="local | dev">
    <logger name="com.example" level="DEBUG"/>
    <root level="INFO"><appender-ref ref="CONSOLE"/></root>
  </springProfile>

  <springProfile name="prod">
    <!-- 本番用テンプレートの FILE / ASYNC_FILE をここに置く -->
    <root level="INFO"><appender-ref ref="CONSOLE"/></root>
  </springProfile>
</configuration>

Spring Boot アプリで logback.xml という名前にすると、Spring より先に読まれるため <springProfile> が効きません。レベル変更だけなら application.yml の logging.level.com.example: DEBUG で十分です。プロファイルの切り替え方は「Spring Bootプロファイル切り替え」記事を参照してください。Spring Boot の jar が手元にないため、この節は Spring Boot 公式リファレンスに沿った未実行の内容です。

よくある質問

Q. SLF4J だけ入れれば Logback の設定は不要ですか？ A. いいえ。SLF4J は API だけなので、実装がないと警告が出てログは出ません。logback-classic を依存に追加すれば slf4j-api も一緒に入ります。

Q. maxHistory と totalSizeCap はどちらを設定すればよいですか？ A. 両方設定するのがおすすめです。maxHistory は「何周期分残すか」、totalSizeCap は「アーカイブ合計の上限」で、公式マニュアルでは totalSizeCap は maxHistory とあわせて使うと説明されています。ログが急に増えた日もディスクを使い切らずに済みます。

Q. 非同期にすると何が変わりますか？ A. アプリのスレッドがファイル書き込みを待たなくなり、応答時間が安定しやすくなります。一方で既定では混雑時に INFO 以下が捨てられ、行番号は ? になります。discardingThreshold=0 と <shutdownHook/> を組み合わせてください。

Q. logback.xml と logback-spring.xml を両方置いたらどうなりますか？ A. 標準名の logback.xml が先に使われます。Spring Boot アプリでは logback-spring.xml だけを置くと混乱がありません。

まとめ

• SLF4J は API、Logback は実装。依存は logback-classic だけで、Logback 1.5／1.6 には slf4j-api 2.x を組み合わせる
• ログは {} で書く。100万回の DEBUG 呼び出しで、連結は toString が100万回、{} は0回だった
• 例外は最後の引数に渡すとスタックトレースが出る。重い引数は isDebugEnabled() か 2.x の Supplier で
• 本番は SizeAndTimeBasedRollingPolicy。%d と %i が必須、maxHistory と totalSizeCap を両方設定
• AsyncAppender は既定で INFO 以下を捨てることがある。discardingThreshold=0 と <shutdownHook/> をセットで
• ログが出ないときは起動直後の SLF4J: と |-ERROR in を読む。実装なし・複数実装・名前違い・additivity が代表例
• Spring Boot では logback-spring.xml にすると <springProfile> で環境別に切り替えられる

株式会社RJCでは、SLF4JとLogbackによるログ設定を仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

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