Java

Lombokとは?Javaのアノテーションでボイラープレートを削減する仕組みと使い方

Lombok(ロンボク)は、JavaのGetter・Setterやコンストラクタといった定型コード(ボイラープレート)を、アノテーション1行で自動生成するライブラリです。@Data@Builderを付けるだけでコンパイル時にメソッドが生成されるため、クラス定義からノイズが消え、ビジネスロジックに集中できます。この記事では、主要アノテーションの一覧、Maven・Gradle・IDEへの導入手順、実際のコード例に加え、Java 16以降のrecordとの使い分けや「非推奨では」という議論まで、最新版1.18.46を前提に整理します。

まとめ:Lombokの要点

先に結論をまとめます。詳細は各セクションで解説します。

  • Lombokはコンパイル時のアノテーション処理でGetter/Setter・コンストラクタ・toString等を生成するライブラリ。実行時の依存は残らない(providedcompileOnlyで十分)。
  • まず押さえるべきは@Data@Getter@Setter@Builder@NonNullの4つ。これだけで実務の大半をカバーできる。
  • 導入は依存追加だけ。IntelliJ IDEA 2020.3以降はLombokを標準同梱しておりプラグイン導入は不要。Eclipseはlombok.jarでIDEに組み込む。
  • 最新版は1.18.46。JDK 25のサポートは1.18.40(2025年9月)で追加され、Java 11〜25に対応。古い記事の1.18.20のまま使い続けない。
  • Java 16で正式化されたrecordが不変DTOの一部を置き換えるため、不変データはrecord、JPAエンティティはLombokという使い分けが現実的。

Lombokとは何か(読み方・同名のロンボク島との違い)

Lombokの正式名称はProject Lombokで、読み方は「ロンボク」です。インドネシアのロンボク島と綴りは同じですが無関係で、検索時は「lombok java」と添えると目的の情報にたどり着きやすくなります。

Lombokの役割は、Javaのアノテーションプロセッサとしてコンパイル時にバイトコードへメソッドを追加することです。@Getterを付けたフィールドにはgetXxx()が、@ToStringを付けたクラスにはtoString()が、ソースコードには現れないまま生成されます。手書きのGetter/Setterが数十行に膨らむエンティティでも、定義はフィールドとアノテーションだけで済みます。生成結果はあくまで通常のJavaメソッドなので、実行時にLombokのライブラリは必要なく、配布物に含める依存は最小限に抑えられます。

Lombokの主要アノテーション一覧

実務で使用頻度が高いアノテーションを、生成される内容と用途で整理します。迷ったときは、まず可変データクラスなら@Data、不変なら@Value、生成手段が欲しいなら@Builderを起点にすると判断が速くなります。

アノテーション 自動生成される内容 主な用途
@Getter / @Setter getter / setter メソッド フィールドアクセス
@ToString toString() ログ・デバッグ表示
@EqualsAndHashCode equals() / hashCode() オブジェクト比較・Set/Mapキー
@NoArgsConstructor 引数なしコンストラクタ JPA・フレームワーク要件
@AllArgsConstructor 全フィールド引数のコンストラクタ 初期化の簡略化
@RequiredArgsConstructor final/@NonNull のみのコンストラクタ DIコンストラクタ注入
@Data 上記Getter/Setter/ToString/Equals/RequiredArgs を一括 可変データクラス
@Value 全フィールドfinalの不変クラス 不変オブジェクト
@Builder ビルダーパターン 多引数オブジェクト生成
@NonNull nullチェック(例外送出) 引数・フィールドの非null保証
@SneakyThrows 検査例外の暗黙スロー try-catchの削減
@Slf4j / @Log ロガーのフィールド ロギング初期化の省略

この一覧のうち、@Dataは5つのアノテーションをまとめた複合アノテーションです。便利な反面、不要なSetterまで生成されるため、不変にしたいクラスでは後述の@Valueやrecordを選びます。

Lombokの導入手順(Maven・Gradle・IDE設定)

導入はビルドツールへの依存追加と、IDE側でのアノテーション処理の有効化の2点です。ビルドツールとIDEで作業が分かれるため、それぞれ分けて説明します。バージョンは最新の1.18.46を指定します。

Mavenでの導入(pom.xml・provided スコープ)

Mavenではpom.xmldependenciesに依存を追加します。実行時には不要なためprovidedスコープを指定し、配布物に含めないのが定石です。

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.18.46</version>
    <scope>provided</scope>
</dependency>

追加後にmvn clean installを実行すれば依存が解決されます。バージョンを固定値で書く代わりに、親POMのdependencyManagementやSpring Bootの管理バージョンに委ねると、プロジェクト間でのずれを防げます。

Gradleでの導入(compileOnly と annotationProcessor)

Gradleでは、コンパイル時のみ参照するcompileOnlyと、アノテーション処理を担うannotationProcessorの両方に同じ依存を宣言します。片方だけだと「アノテーションは認識されるがメソッドが生成されない」状態になるため、2行セットが必須です。

dependencies {
    compileOnly 'org.projectlombok:lombok:1.18.46'
    annotationProcessor 'org.projectlombok:lombok:1.18.46'
}

テストコードでもLombokを使う場合は、testCompileOnlytestAnnotationProcessorにも同じ依存を追加します。

IDE設定(IntelliJ IDEAは標準対応・Eclipseはlombok.jar)

IntelliJ IDEAは2020.3以降でLombokプラグインを標準同梱しており、別途インストールは不要です。アノテーション処理も既定で有効になるため、依存を追加すればそのまま補完とコード解析が働きます。古い記事に残る「プラグインを検索してインストール」という手順は、現行バージョンでは不要になりました。

Eclipseの場合は、ダウンロードしたlombok.jarをインストーラーとして実行し、IDEへ組み込みます。

java -jar lombok.jar

起動したインストーラーでEclipseのインストール先を指定し、再起動するとアノテーションが認識されます。Eclipse自体の役割や設定をあわせて確認したい場合はEclipseとは?特徴と主な用途を徹底解説を参照してください。

主要アノテーションの使い方とコード例

使用頻度の高いアノテーションを、最小限のコード例とともに示します。いずれもフィールドとアノテーションだけを書き、生成されるメソッドはソースに現れない点が共通します。

@Getter・@Setter(AccessLevelでアクセス制御)

フィールドに@Getter@Setterを付けると、対応するgetter/setterが生成されます。クラスに付ければ全フィールドが対象です。

public class User {
    @Getter @Setter
    private String name;
    @Getter @Setter
    private int age;
}

AccessLevelで生成メソッドの可視性を変えられます。たとえば外部からの変更を防ぎたいフィールドは、getterはPUBLIC、setterはPRIVATEに分けます。

@Getter(AccessLevel.PUBLIC)
@Setter(AccessLevel.PRIVATE)
private String name;

@NoArgsConstructor・@AllArgsConstructor・@RequiredArgsConstructor(コンストラクタ生成)

コンストラクタ系は3種類あります。引数なしの@NoArgsConstructor、全フィールドを取る@AllArgsConstructorfinal@NonNullフィールドだけを取る@RequiredArgsConstructorです。JPAエンティティは引数なしコンストラクタを要求するため@NoArgsConstructorが、Springのコンストラクタインジェクションには@RequiredArgsConstructorが定番です。

@NoArgsConstructor
@AllArgsConstructor
public class User {
    private String name;
    private int age;
}

@Data・@Value(可変クラスと不変クラスの作り分け)

@DataはGetter/Setter・toStringequals/hashCode@RequiredArgsConstructorを一括適用する可変クラス向けです。一方@Valueは全フィールドをfinalにし、Setterを生成しない不変クラスを作ります。値が変わらないDTOには@Value、ORMのエンティティのように状態が変わるオブジェクトには@Dataを選びます。

@Data
public class User {
    private String name;
    private int age;
}

@Value
public class Address {
    String street;
    String city;
}

@Builder(多引数オブジェクトの生成)

@Builderはビルダーパターンを生成し、引数の多いオブジェクトを名前付きで組み立てられるようにします。コンストラクタ引数の順序を覚える必要がなくなり、可読性が上がります。

@Builder
public class User {
    private String name;
    private int age;
}

User user = User.builder()
    .name("John Doe")
    .age(30)
    .build();

@NonNull(null引数チェックの自動化)

@NonNullを引数に付けると、nullが渡されたときにNullPointerExceptionを送出するチェックが冒頭に挿入されます。Bean Validationの@NotNullがバリデーション基盤の実行を前提とするのに対し、Lombokの@NonNullはメソッド先頭で即座に弾く点が異なります。入口でnullを止めたいフィールドや引数に向きます。

public void setName(@NonNull String name) {
    this.name = name;
}

@SneakyThrows(検査例外の記述を省く・濫用に注意)

@SneakyThrowsは、throws宣言やtry-catchを書かずに検査例外を送出させます。記述は減りますが、呼び出し側から例外が見えなくなるため、握りつぶしと誤解されやすいのが難点です。使うのは、検査例外がほぼ発生しない初期化処理など範囲を限定し、業務ロジックの本筋では明示的に例外を扱うのが安全です。

@SneakyThrows
public void readFile(String path) {
    Files.readAllLines(Paths.get(path));
}

@Slf4j・@Log(ロガー宣言の省略)

@Slf4jをクラスに付けると、SLF4Jのロガーを保持するlogフィールドが生成され、log.info(...)をすぐ呼べます。ロギング基盤に応じて@Log4j2・標準の@Log@CommonsLogなども選べ、ロガー宣言の定型行を全クラスから消せます。

@Slf4j
public class OrderService {
    public void run() {
        log.info("started");
    }
}

Lombokを使うべき場面と避けるべき場面(record・非推奨論への回答)

Lombokには「もう非推奨では」「recordがあれば不要では」という議論が常にあります。結論から言えば、Lombokは公式に非推奨化されておらず最新Javaへの追従も続いていますが、用途によってはrecordや手書きの方が適切です。判断軸を具体的に示します。

不変のデータ運搬役(DTO・値オブジェクト)は、まずrecordを検討します。Java 16で正式化されたrecordは、不変フィールド・コンストラクタ・equals/hashCode/toStringを言語機能だけで賄えるため、外部ライブラリなしで@Value相当を実現できます。新規プロジェクトの単純な不変DTOにLombokを足す理由は薄くなりました。

状態が変わるJPAエンティティはLombokが優位です。recordは全フィールドを受け取るコンストラクタ(canonical constructor)が必須で引数なしコンストラクタを持てず、フィールドも書き換えられないため、引数なしコンストラクタとSetterを要求するORMフレームワークと相性が悪いのが実情です。エンティティには@Getter/@Setter@NoArgsConstructorを使い、外部公開する不変DTOにはrecordを使う、という併用が現実的な落としどころです。

避けるべきなのは、チームがLombokの挙動を共有していない場合の@SneakyThrowsや過剰な@Dataです。生成コードがソースに見えないぶん、規約が無いとデバッグやレビューで混乱します。導入時はアノテーションを限定し、ガイドラインで使用範囲を決めておきます。なお、Lombokから離脱したくなった場合はdelombokでアノテーションを実コードへ展開できるため、ロックインの不安は小さく抑えられます。JPAエンティティを多用する設計では、あわせてJava ORM(Object-Relational Mapping)の比較と選び方も検討材料になります。

よくある質問

Lombokの読み方は?

「ロンボク」と読みます。正式名称はProject Lombokで、Javaのボイラープレートを削減するライブラリです。インドネシアのロンボク島と綴りは同じですが、技術とは関係ありません。検索する際は「lombok java」と添えると目的の情報に絞り込めます。

Lombokの最新バージョンは?Java 21や25でも使えますか?

最新版は1.18.46です。JDK 25のサポートは1.18.40(2025年9月)で追加され、最新の1.18.46までJava 11〜25に対応しています。2024年頃の記事にある1.18.20のままだと新しいJavaでコンパイルエラーが出ることがあるため、依存のバージョンを最新へ更新してください。Javaバージョンの移行はJava 21からJava 25へのアップデート概要も参考になります。

Lombokは非推奨なのですか?

公式に非推奨化された事実はなく、最新Javaへの対応も継続しています。「非推奨では」という声は、recordの登場や生成コードの不透明さに対する懸念から来ています。プロジェクトの方針として使わない判断はあり得ますが、ライブラリ自体が廃止に向かっているわけではありません。

Java recordがあればLombokは不要ですか?

用途次第です。不変のDTOや値オブジェクトはrecordで賄えるため、その範囲ではLombokは不要になりつつあります。一方、Setterや引数なしコンストラクタが必要なJPAエンティティ、ビルダーやロガー生成などはrecordでは代替できず、Lombokが有効です。不変はrecord、可変・エンティティはLombokという併用が実務的です。

@Dataと@Valueの違いは?

@DataはGetterとSetterを生成する可変クラス向け、@Valueは全フィールドをfinalにしSetterを生成しない不変クラス向けです。状態が変わるオブジェクトには@Data、生成後に変更しない値オブジェクトには@Valueを使い分けます。

関連記事

資料請求

RELATED POSTS 関連記事