Lombokでコードを劇的にシンプルに｜〜Javaの「長い」を「読みやすい」に変える、正しい使い方〜

Javaを学び始めて、最初に感動するのはこういう瞬間です。

クラスが書けるようになった
オブジェクトを作って動かせた
Springで画面やAPIが作れた

でも少し慣れてくると、別の悩みが出てきます。

「同じようなコードばかり書いてる気がする……」

たとえば、こんなコードです。

getter
setter
コンストラクタ
toString
equals / hashCode

もちろん必要な場面はあります。
ただ、毎回これを手で書いていると、こうなりがちです。

本質のロジックを書く時間が減る
重要な処理が“雑音”に埋もれる
コピペでミスが混ざる
読む人が疲れる

ここで登場するのが Lombok です。

Lombokをうまく使うと、Javaのコードは「短く」なるだけではありません。
読みやすく、変更に強くなりやすい方向へ進みます。

この記事では、Lombokを

便利ツールとしてではなく
設計を助ける道具として

理解できるように、丁寧に解説します。

Lombokとは何か

Lombokを一言で言うなら、こうです。

「Javaでよく出てくる定型コードを、書かなくてよくする仕組み」

ポイントは、ただ省略するのではなく、
**コンパイルのときにコードが“補われる”**ところです。

つまり、Lombokを使うと

ソースコードは短く
でも動くものはちゃんと揃う

という状態になります。

ここで大事なのは、Lombokは「Javaの文法を壊す魔法」ではないことです。
Javaはもともと

設計を大切にする
型を大切にする
大規模開発で耐える

という強みがあります。

Lombokは、そのJavaの強みを邪魔せずに、
余計な定型作業を減らす道具です。

なぜLombokで「劇的に」変わるのか

Lombokの価値は、単なる時短ではありません。

本当の価値は「ノイズが減る」こと

Javaのクラスは、きれいに設計すると読みやすくなります。
でも定型コードが増えると、こうなります。

本当に読みたい処理が見つけにくい
クラスの役割が見えにくい
変更点が目立たない

Lombokで定型を消すと、こう変わります。

クラスの意図が見える
レビューが楽になる
ミスが入りにくい

つまり、チーム開発で効きます。

Lombokがしていることを、やさしく理解する

難しい言い方をしないで説明します。

Lombokは、あなたが書いたクラスを見て、

「getterが必要そうだね」
「コンストラクタも必要そうだね」

と判断し、
裏側で“必要なコードを足してから”コンパイルするイメージです。

だから、実行時に何か変なことをしているわけではありません。
「実行中に勝手に変わる」ではなく、
ビルド時点で形が決まるのが安心ポイントです。

よく使うLombokを、目的別に覚える

Lombokはアノテーションを付けるだけで使えます。
でも、ここで多くの人が失敗します。

「便利そうだから全部付ける」

これは危険です。
Lombokは、使い方次第で設計が崩れます。

なので、目的別に整理します。

getterだけ欲しいとき

データを外に見せたいが、勝手に変えられたくない。
こういうときは、getterだけ付けます。

import lombok.Getter;

@Getter
public class UserName {
    private final String value;

    public UserName(String value) {
        this.value = value;
    }
}

ここでのポイントは、setterを付けていないことです。
「値は作るときに決めて、あとから変えない」
こういう設計は、Javaが得意な堅い設計です。

コンストラクタを楽にしたいとき

Springでは、依存注入でコンストラクタが長くなりがちです。
そんなときに便利なのが、必要なものだけ受け取るコンストラクタを作るアノテーションです。

import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;

@Service
@RequiredArgsConstructor
public class OrderService {

    private final OrderRepository orderRepository;
    private final PaymentGateway paymentGateway;

    public void placeOrder(OrderRequest request) {
        orderRepository.save(request);
        paymentGateway.pay(request);
    }
}

この形は、Springの設計と相性がとても良いです。

依存が見える
差し替えしやすい
テストしやすい

つまり、Lombokが“設計の良さ”を助ける代表例です。

toStringが欲しいとき

ログを見やすくしたいとき、toStringは便利です。
ただし、個人情報や機密が含まれる場合は注意が必要です。

その場合は「全部出す」ではなく、出していいものだけを意識します。
「便利だから全部」ではなく、責任を持って出すのが現場流です。

いちばん注意したいアノテーション

便利に見えて、事故が起きやすいものがあります。
ここを避けられると、あなたは一気に“現場で信用される側”になります。

なんでもまとめるアノテーションに注意

「これ付けとけば全部そろう」系は、確かに楽です。
でも、現場ではこういう問題が出がちです。

意図しないsetterが増える
equals / hashCode が勝手に変わる
ログに出してはいけない値が混ざる
モデルが“何でもできる箱”になってしまう

つまり、便利な一方で、
設計のブレーキが壊れやすいのです。

Lombokは「短くする道具」ではなく、
設計をきれいに保つ道具として使うほうが強いです。

Lombokを使うと設計が良くなる理由

ここからが、いちばん伝えたい話です。

Lombokの価値は、
「書く量が減る」ではなく、
責務が見えることです。

責務とは何か

責務は、簡単に言うと

「このクラスの仕事は何か」

です。

Lombokで定型コードが減ると、クラスに残るのは

本当に必要なフィールド
本当に必要なメソッド
そのクラスの意図

になります。

結果、レビューでこう言えるようになります。

「このクラスは何のためにあるか分かる」
「依存がはっきりしていて良い」
「変更しても影響が読みやすい」

これは、Javaが大規模開発に強い理由そのものです。
Lombokは、その強さを引き出しやすくします。

Lombokが嫌われる理由の正体

「Lombokは嫌われる」と聞いて不安になる人がいます。
でも、嫌われるのはLombokそのものではありません。

嫌われるのはたいてい、次のような状態です。

なんとなく全部付ける
何が生成されるか理解していない
設計が崩れているのに気づかない
クラスの責務が曖昧

つまり、Lombokが原因ではなく、
使い方と設計の問題です。

逆に言えば、理解して使えば、Lombokは強い味方です。

DTO・Entity・ドメインでの使い分け

現場では「どこに付けるか」が重要です。
ここを整理できると、事故が減ります。

DTOの考え方

DTOは「運ぶ箱」です。
運ぶ箱は、形が決まっていて、扱いやすいのが正義です。

値を受け取る
値を返す

という目的がはっきりしているなら、Lombokは相性が良いです。

Entityの考え方

Entityはデータベースと結びつきます。
ここはプロジェクトの設計方針によって判断が変わりますが、共通して言えるのは、

何を公開するか
何を変更可能にするか

を意識しないと、設計が壊れやすいという点です。

ドメインの考え方

ドメインは「業務のルール」を持つ中心です。
ここをただのデータ箱にすると、プロジェクトは弱くなります。

ドメインでは、
「とりあえず全部setter」みたいな使い方は避け、
意図が見える設計を優先すると強いです。

レビューで使えるチェックリスト

チーム開発で強い人は、Lombokを見るときにここを見ます。

見るポイント	何を確認するか	ありがちな事故
目的が説明できるか	なぜこのアノテーションか	便利だからで付ける
依存が見えるか	コンストラクタで分かるか	依存が隠れて読めない
変更が安全か	setterを必要以上に付けていないか	どこでも書き換え可能になる
情報漏れしないか	ログに出して良い値だけか	機密がtoStringに混ざる