コントローラーにログを仕込む方法(Loggerの使い方)|Spring Bootでのログ出力設定を初心者向けに解説
新人
「Spring Bootのアプリを作っているんですが、コントローラにログを出す方法がよく分からなくて……」
先輩
「良いね。ログ出力は開発でも運用でも欠かせない仕組みだよ。Spring BootではLoggerを使って簡単にログを仕込めるんだ。」
新人
「Loggerってどうやって使うんですか?print文で代用しちゃダメですか?」
先輩
「print文でも動くけど、本番運用ではログをレベル別に管理できるLoggerの方が圧倒的に便利なんだ。まずはその仕組みから見ていこう。」
1. ログを仕込む目的(なぜコントローラにログが必要なのか)
Spring Bootの開発で「ログを仕込む」という言葉をよく耳にします。これは、アプリケーションの動作状況を記録するために行う作業のことです。特にコントローラでは、リクエストの受け取りやレスポンスの返却など、アプリ全体の入り口となる処理が多く、ログを出力しておくことで問題発生時の調査や動作確認がスムーズになります。
ログを使うと、単にSystem.out.println()で出力するよりも多くの情報を扱えます。例えば、エラーの発生場所や実行時間、ログレベル(INFO、DEBUG、ERRORなど)を指定できるため、後から分析する際に非常に役立ちます。特に、Spring BootではSLF4JとLogbackが統合されており、統一されたログ管理ができます。
初心者のうちは、つい画面出力で済ませたくなりますが、ログを正しく設定しておくと、開発チーム全体で同じ基準でデバッグや監視ができるようになります。これは、将来的にチーム開発や本番運用を意識する上でとても重要なポイントです。
たとえば、ユーザーが特定のボタンを押したときにどんなリクエストが送られたのか、どんな例外が発生したのかを追跡するには、ログが欠かせません。Spring Bootのログ出力を理解しておけば、コントローラ内で「いつ・どこで・何が起きたか」を簡単に記録できるようになります。
2. Spring Bootでログを出す仕組みの概要(SLF4JとLogback)
Spring Bootでは、標準でSLF4J(Simple Logging Facade for Java)という共通ログインターフェースを使用します。このSLF4Jは、実際のログ処理を担当するライブラリ(LogbackやLog4jなど)を内部で呼び出す仕組みです。つまり、SLF4Jが「表側の入り口」、Logbackが「裏側の処理担当」という関係になります。
Spring Bootをpleiadesで新規プロジェクトとして作成すると、自動的にspring-boot-starter-loggingが依存関係に含まれています。これは内部的にLogbackを使っており、特別な設定をしなくてもログ出力が動作します。Gradleの依存関係には、次のように表示されているはずです。
implementation 'org.springframework.boot:spring-boot-starter-logging'
このように、追加で設定する必要はほとんどありません。アプリケーションを実行すると、コンソールにINFOレベルのログが自動的に表示されます。Spring Bootでは、初期状態でINFOレベルのログを出力するように設定されており、開発中は十分な情報量を得られます。
また、SLF4Jはライブラリごとに異なるログ実装を統一的に扱うための仕組みでもあります。たとえば、あるライブラリがLog4j、別のライブラリがJava Util Loggingを使っていても、SLF4Jを介すことで一貫した出力フォーマットで扱うことができます。
ログを扱う上では、「どの層で何を出すか」を意識することが大切です。コントローラでは、リクエストの受付・レスポンスの内容・エラー内容などを記録します。サービス層では、ビジネスロジックの処理状況を出力します。このように、層ごとにログを分けることで、トラブルの原因をすぐに特定できるようになります。
実際に@Controllerでログを仕込むには、次のようにLoggerFactoryを使います。
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
@Controller
public class SampleController {
private static final Logger logger = LoggerFactory.getLogger(SampleController.class);
@GetMapping("/hello")
public String hello() {
logger.info("Helloメソッドが呼び出されました");
return "hello";
}
}
このように書くだけで、コンソールに「Helloメソッドが呼び出されました」というINFOレベルのログが出力されます。LoggerFactoryでクラスごとにログインスタンスを生成し、info()やerror()メソッドでメッセージを出力します。
この仕組みを理解すると、Spring Bootのログ出力が単なるテキスト出力ではなく、システム全体の状態を記録する強力なツールであることが分かるはずです。次の記事では、ログレベルの設定方法や、コントローラ内での実践的な使い分けを解説していきます。
3. Loggerの基本的な使い方(LoggerFactoryの取得方法)
ここからは、実際にSpring BootのコントローラでLoggerを使う方法を見ていきましょう。Spring Bootでは、org.slf4j.LoggerインターフェースとLoggerFactoryクラスを使用します。この2つを組み合わせることで、任意のクラス内でログを簡単に出力できます。
基本の流れはとてもシンプルです。まず、クラスの先頭でLoggerインスタンスを作成します。このときにLoggerFactory.getLogger(クラス名.class)を呼び出します。これにより、そのクラス専用のログ出力器が生成されます。
この構成は、pleiades環境でGradleプロジェクトを作成した場合でもすぐに動作します。追加の依存関係を設定する必要はなく、@Controllerクラスの中にそのまま記述できます。
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Controller;
@Controller
public class LogExampleController {
private static final Logger logger = LoggerFactory.getLogger(LogExampleController.class);
}
このようにしておけば、クラス内のどこからでもlogger.info()やlogger.debug()を呼び出せます。LoggerFactoryはスレッドセーフであり、毎回新しく生成する必要はありません。したがって、static finalとして定義するのが一般的なベストプラクティスです。
また、Spring Bootのログ設定は自動で初期化されるため、Loggerを定義した時点でコンソール出力が有効になります。これにより、アプリケーションの起動直後から統一されたフォーマットでログを確認できます。
4. 実際に@Controllerにログを仕込むコード例
次に、実際のコントローラクラスでログを出力する例を見てみましょう。ここでは、Spring MVCの@Controllerアノテーションを使い、URLリクエストを受け取るメソッドにログを追加します。
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
@Controller
public class HelloController {
private static final Logger logger = LoggerFactory.getLogger(HelloController.class);
@GetMapping("/log")
public String showLogExample() {
logger.info("INFOレベルのログを出力します。");
logger.debug("DEBUGレベルのログを出力します。");
logger.error("ERRORレベルのログを出力します。");
return "logView";
}
}
この例では、INFO、DEBUG、ERRORという3種類のログを出力しています。Spring Bootを起動して/logにアクセスすると、コンソールにログが出力されるのを確認できます。
pleiades環境では、実行中のアプリケーションの「コンソール」ビューにログが表示されます。実行結果は以下のようになります。
2025-10-25 14:32:01.123 INFO 12345 --- [nio-8080-exec-1] c.e.demo.controller.HelloController : INFOレベルのログを出力します。
2025-10-25 14:32:01.124 ERROR 12345 --- [nio-8080-exec-1] c.e.demo.controller.HelloController : ERRORレベルのログを出力します。
初期状態では、INFOレベル以上のログのみが表示され、DEBUGのメッセージは表示されません。これを変更したい場合は、application.propertiesに設定を追加します。
# 全体のログレベルをDEBUGに変更
logging.level.root=DEBUG
# 特定のパッケージのみDEBUGに設定する場合
logging.level.com.example.demo.controller=DEBUG
このように設定すると、同じコードでもDEBUGログが表示されるようになります。開発中はDEBUG、本番環境ではINFOにするなど、環境ごとに切り替えるのが一般的です。
また、LoggerFactoryを使うと、クラス単位でログレベルを制御できるため、アプリ全体で一貫した管理が可能になります。ログを使い分けることで、必要な情報だけを抽出して効率的にデバッグできるようになります。
5. INFOやDEBUGを使い分ける方法(実際のログ出力の違い)
Spring Bootでは、ログのレベルによって出力される情報量が変わります。主なレベルは、TRACE、DEBUG、INFO、WARN、ERRORの5種類です。これらをうまく使い分けることで、開発や運用の効率を大きく高めることができます。
例えば、DEBUGは開発中に細かな動作確認を行うときに便利です。変数の値や条件分岐の流れを確認する目的で使われます。一方、INFOはユーザーの操作や重要な処理の開始・終了を記録するために使われます。
@GetMapping("/process")
public String processTask() {
logger.info("処理を開始します。");
logger.debug("内部処理の詳細を確認中...");
logger.info("処理が完了しました。");
return "done";
}
上記のコードを実行すると、INFOレベルでは「開始」と「完了」だけが出力されますが、DEBUGを有効にすれば中間の処理内容も表示されます。開発時は詳細なログ、本番では必要最低限のログというように環境によってレベルを切り替えるのが理想的です。
さらに、Spring Bootではapplication.propertiesでクラスごとに設定を分けることも可能です。
# コントローラはDEBUGで詳細なログを出力
logging.level.com.example.demo.controller=DEBUG
# サービス層はINFOで出力
logging.level.com.example.demo.service=INFO
これにより、開発中はコントローラだけ詳細にログを確認しつつ、他の層の出力は控えめにするなど、柔軟な調整ができます。特に複数人での開発や大規模アプリケーションでは、役割に応じたログ設計が重要になります。
ログレベルを適切に使い分けることで、システムの動作を的確に把握でき、トラブル時の原因究明も早くなります。Spring Boot LoggerFactoryを理解して使いこなせば、開発現場での信頼性が格段に向上するでしょう。
6. 実行結果の確認方法(コンソール出力例)
ここでは、Spring Bootで実際にログを出力したときの結果を確認してみましょう。pleiades環境でGradleプロジェクトを実行すると、標準でコンソールにログが流れます。アプリを起動し、ブラウザでhttp://localhost:8080/logへアクセスすると、INFOレベルやERRORレベルのメッセージが表示されます。
実際の出力は以下のようになります。日付、スレッド名、クラス名が自動で含まれるため、問題の発生箇所を特定しやすいのが特徴です。
2025-10-25 14:32:01.123 INFO 12345 --- [nio-8080-exec-1] c.e.demo.controller.HelloController : INFOレベルのログを出力します。
2025-10-25 14:32:01.124 ERROR 12345 --- [nio-8080-exec-1] c.e.demo.controller.HelloController : ERRORレベルのログを出力します。
初期状態ではDEBUGは表示されませんが、application.propertiesに設定を追加することで確認できます。設定ファイルを次のように書き換えましょう。
logging.level.com.example.demo.controller=DEBUG
保存後にアプリを再起動すると、DEBUGレベルのログも表示されるようになります。Spring Bootのログは自動的に色分けされるため、pleiadesのコンソール上でも視認性が高く、どのレベルのメッセージなのかが一目で分かります。
また、ログの内容はファイルに出力することも可能です。application.propertiesに次のような設定を追加します。
logging.file.name=logs/app.log
この設定を行うと、アプリケーションの実行ディレクトリ内にlogsフォルダが作成され、app.logに出力内容が自動保存されます。ログファイルを残しておけば、過去のエラーやユーザー操作の履歴を後から見返すことができるため、運用時のトラブル対応にも役立ちます。
pleiades上で確認する際は、コンソールビューでリアルタイム出力を確認しつつ、logsフォルダを開いて過去の履歴を参照するのがおすすめです。これにより、Spring Boot ログレベル 設定の違いが実感でき、Logger デバッグ方法の理解も深まります。
7. よくあるミスと対処法(Logger未定義、import忘れなど)
ここからは、初心者がつまずきやすいポイントを紹介します。Spring Bootでログを設定するときに多いのが、「Loggerを定義していない」「import文を忘れている」「ログが出力されない」といったトラブルです。
まず最も多いのが、Loggerをクラスに定義していないケースです。コントローラ内でlogger.info()を書いても、変数が存在しなければコンパイルエラーになります。必ずクラスの先頭で次のように定義してください。
private static final Logger logger = LoggerFactory.getLogger(クラス名.class);
次に多いのが、import文の抜け漏れです。LoggerとLoggerFactoryはorg.slf4jパッケージに含まれています。pleiadesの自動補完でimportされない場合は、手動で次のように追加しましょう。
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
また、ログが出力されない場合は、application.propertiesの設定を確認します。特定のパッケージに対してlogging.levelが誤って指定されていると、期待するレベルのログが表示されません。例えば、次のように正しいパッケージ名を指定します。
logging.level.com.example.demo.controller=DEBUG
プロジェクト名やパッケージ構成を変更したときにこの指定がずれていると、ログが出力されなくなることがあります。特に、コントローラを新規作成したあとや、パッケージを移動した際にはこの設定を再確認してください。
さらに、Loggerのメソッド名をタイプミスするケースもあります。正しくはlogger.info()やlogger.error()であり、logger.log()やlogger.print()では動作しません。IDEの自動補完を活用して正確に入力する習慣をつけましょう。
これらのポイントを押さえておくことで、「コントローラ ログ出力 例」を再現するときにトラブルを防ぎやすくなります。初心者でも安定してログを扱えるようになり、Spring Boot ログレベル 設定の基礎を身につけられます。
8. 環境別のログ活用のコツ(開発環境・本番環境でのログレベル調整)
最後に、環境によってログレベルを切り替えるコツを紹介します。Spring Bootでは、application.propertiesに複数の設定ファイルを用意しておくことで、開発環境と本番環境でログの出力内容を変えることができます。
まず、開発環境ではDEBUGを有効にして、細かい動作を確認できるようにします。例として、src/main/resources/application-dev.propertiesに以下のように設定します。
logging.level.root=DEBUG
logging.level.com.example.demo.controller=DEBUG
一方、本番環境ではログ量が増えすぎると性能に影響するため、INFOまたはWARNレベルに制限します。次のようにapplication-prod.propertiesを用意します。
logging.level.root=INFO
logging.file.name=logs/production.log
これらの設定を自動で切り替えるには、application.propertiesの中でプロファイルを指定します。
spring.profiles.active=dev
これで開発中はDEBUGレベル、本番ではINFOレベルといったように切り替えが可能になります。pleiadesの実行構成でプロファイルを変更すれば、同じソースコードでも出力内容を柔軟に調整できます。
もう一つのポイントは、ログ出力先の管理です。開発中はコンソール出力で十分ですが、本番ではファイル出力や外部のログ管理ツールを組み合わせるのが一般的です。これにより、障害発生時に過去の履歴を追跡できるだけでなく、分析や監視の効率も向上します。
例えば、INFOレベル以上のログのみを本番ログに残し、DEBUGレベルの詳細ログは開発時のみ確認するようにすると、運用時のノイズを減らせます。Spring Bootではこの切り替えをlogging.levelの指定だけで実現できるため、環境ごとのメンテナンスが非常に簡単です。
また、複数の開発者が同じプロジェクトで作業する場合、それぞれのローカル環境で別々のログ設定を持たせるのも効果的です。個人開発ではapplication-dev.propertiesを自由に調整し、共有リポジトリにはapplication-prod.propertiesのみコミットしておくと安全です。
このように、Spring Bootのログ設定を環境ごとに分けることで、デバッグと運用の両立が可能になります。開発中は「Logger デバッグ方法」を意識しながら細かな挙動を記録し、本番では必要最小限のログでシステムの健全性を保つことが重要です。
これらの工夫を取り入れれば、コントローラのログ出力を効率的に活用でき、問題解析や品質向上に大きく貢献できます。特に、Spring Boot ログレベル 設定を理解しておくと、どんな環境でも最適なログ管理が行えるようになります。