Lombok、便利ですよね。クラスに@Dataを付けるだけでコードが一気に短くなって、「おお、楽！」ってなりがちです。
ただその一方で、「このクラス、どんなメソッドがあるの？」「レビューで説明できない…」「自分の環境だけ赤線が出るんだけど？」みたいなモヤっとした経験、ありませんか？
それ、けっこう多くの人が通る道です。Lombokは“コードを自動で作ってくれる”反面、“見えなくなる”というクセもあります。何となく使っていると、あとから困ることもあるんですよね。
この記事では、Lombokの代表的なデメリットを具体例つきで整理しつつ、「使わない方がいい場面」と「使っても問題になりにくい場面」を分かりやすく説明します。さらに、チーム開発で揉めないためのルール作りチェックリストも紹介します。
読み終わるころには、「自分はどう使うべきか」がちゃんと判断できるようになりますよ。
Lombokって結局なに？まずは「楽になる理由」を整理
Lombok（ロンボック）は、ひとことで言うと「Javaのコードを書く手間を減らしてくれる道具」です。
とくに初心者のうちは、「同じようなコードを何回も書いているな…」と感じることが多いと思います。Lombokは、そこを助けてくれる存在なんです。
たとえば、普通にJavaでクラスを書くと、変数ごとにGetterやSetterを書く必要がありますよね。
これを毎回手で書くと、正直ちょっと面倒です。そこでLombokを使うと、クラスの上にアノテーション（目印みたいなもの）を1行書くだけで、必要なメソッドを自動で作ってくれます。
イメージとしては、「ボタン1つで宿題を代わりに書いてくれる代筆係」みたいな感じです。
自分は書いていないけど、裏ではちゃんとノート（＝コード）が作られています。
ここで大事なのは、「コードを書かなくていい＝コードが存在しない」わけではない、という点です。
Lombokはサボっているのではなく、見えないところで勝手に作ってくれているだけなんですね。
この仕組みのおかげで、コードは短くなり、書くスピードも上がります。
ただし、「何を自動で作っているのか」を知らないまま使うと、あとで混乱しやすくなります。
便利なのは事実ですが、「便利＝いつでも正解」ではない、という前提をまず押さえておきましょう。
Lombokの代表的デメリット7つ（具体例つき）
ここからは、「便利だけど、ここが困る」というLombokのデメリットを見ていきます。
全部ダメ、という話ではなく、「こういう場面で起きやすいよ」という現場あるあるだと思って読んでくださいね。
コードが見えず、理解に時間がかかる
起きること
クラスを見ると、変数と@Dataしか書いていない。
困る理由
「このクラス、どんなメソッドがあるの？」とパッと分かりません。
頭の中で「たぶんGetterとSetterがあって…」と想像する必要が出てきます。
こう避ける
初心者のうちは、まず手書きでコードの形を覚えるのが安全です。
IDE設定が必要で、環境差でつまずく
起きること
AさんのPCでは動くのに、自分のPCでは赤線だらけ。
困る理由
Lombokは、IDE（開発ツール）にプラグインや設定が必要な場合があります。
入っていないと、「存在しないメソッド」扱いされてしまいます。
こう避ける
チームでは、IDE設定をREADMEに必ず書くようにしましょう。
エラー原因が追いにくい（どこで作られた？が分からない）
起きること
エラーが出ているけど、エラー元のコードが見当たらない。
困る理由
実際のメソッドはLombokが裏で作っているので、「この処理どこ？」となりがちです。
こう避ける
生成される内容を一度は確認し、「裏で何が作られるか」を理解しておくことが大切です。
自動生成が“意図しない動き”をすることがある
起きること
思っていない項目まで比べられたり、勝手に全部セットできたりする。
困る理由
自分が書いていないコードなので、「そんな動きすると思わなかった！」が起きやすいです。
こう避ける
まとめて自動生成するアノテーションは、使いどころをかなり選びましょう。
レビューで読みづらい／議論が増える
起きること
レビューで「このクラスの責任って何？」と質問が増える。
困る理由
見えないコードが多いと、読む側の負担が増えます。
結果、レビュー時間も長くなりがちです。
こう避ける
レビュー重視のチームでは、Lombokを最小限にするのが無難です。
依存が増える（ビルド・ツール・方針の影響）
起きること
「このライブラリ、今後も使い続ける？」という話が出る。
困る理由
Lombokに依存すると、将来やめづらくなります。
方針変更のコストが意外と高いです。
こう避ける
「やめたくなったら消せるか？」を最初に考えておきましょう。
学習の近道が、基礎の穴になりやすい
起きること
GetterやSetterの仕組みを説明できない。
困る理由
便利な近道を使いすぎると、基礎が身につきにくくなります。
こう避ける
学習中は「まず自分で書く → その後で楽をする」がおすすめです。
ここまで見ると、「思ったよりクセがあるな…」と感じたかもしれません。
次は、とくに初心者がハマりやすいポイントを、Spring Boot開発あるあるとして整理していきますよ。
初心者がハマりやすいポイント（Spring Boot開発あるある）
ここでは、「エラーは出てない。でも正直よく分かってない…」となりがちなポイントをまとめます。
Spring Boot × Lombok あるある、かなり多いですよ。
「動くけど分からない」状態になりやすい
Spring Bootは設定が少なくても動きますし、Lombokを使うとコードも短くなります。
その結果、「とりあえず動いた！」で先に進めてしまいがちです。
ただ後から、「この値、どこで入ってるの？」「誰が呼んでるの？」と聞かれると説明できない…。
これ、Lombokで見えない処理が増えているのが原因なことが多いです。
@Dataの多用で、クラスの責任があいまいに
初心者がやりがちなのが、「とりあえず全部@Data」です。
便利ボタン感覚で付けてしまうんですね。
すると、
といった状態になります。
クラスの役割がぼんやりすると、あとで直すのが一気に大変になります。
DTO / Entity / Form の違いが崩れやすい
Spring Bootでは、
でクラスを分けるのが基本です。
でもLombokで一気に自動生成すると、「全部同じでよくない？」となりがちです。
結果、1つのクラスに責任が集まりすぎて、修正が怖くなります。
チームに入った瞬間、方針の違いで混乱する
個人開発では問題なかったのに、チームに入ったら
「@Dataは禁止です」
「ここはGetterだけにして」
と言われて戸惑うケースも多いです。
Lombokはチームごとに考え方が分かれやすいので、事前に方針を知らないと混乱しやすいんですね。
次の章では、「じゃあ、どんなときは使わない方がいいの？」をハッキリさせますよ。
Lombokを使わない方がいいケース（迷ったらここを優先）
「結局、自分は使うべき？使わないべき？」と迷ったら、まずはここをチェックしてください。
次の条件に当てはまるなら、無理にLombokを使わない方が安全です。
学習中（基礎を身につけたい時期）
Javaを覚えている最中なら、まずは手でコードを書くのがおすすめです。
GetterやSetterを自分で書くことで、「この処理は何をしているか」が体で分かってきます。
Lombokを使わないのは遠回りに見えますが、実は基礎体力づくりとしては近道です。
レビュー重視・保守重視のチーム
「あとから読む人」を大事にするチームでは、見えないコードが増えると困りがちです。
レビューで毎回「これは自動生成です」と説明が必要になるなら、負担は減りません。
読みやすさ優先なら、Lombokは見送る判断も十分アリです。
仕様変更が多い／安全性を重視する領域
仕様がコロコロ変わるときや、ミスが許されない処理では、
「勝手に作られる動き」が怖くなることがあります。
細かく制御したいなら、自分でコードを書く方が安心です。
「自動生成を知らない人」が増えそうな環境
新人が多い、途中参加が多いチームでは、Lombokの前提知識がバラバラになりがちです。
毎回説明が必要なら、使わない方がシンプルです。
よくある反論で「書くのが遅くなりません？」と言われますが、
読めないコードで止まる時間の方が、あとでずっと高くつきます。
次は、「条件つきなら使ってもOKなケース」を見ていきましょう。
Lombokを使っても問題になりにくいケース（条件つき）
ここまで読むと、「じゃあLombokって使わない方がいいの？」と思ったかもしれません。
でも実際は、条件がそろっていれば問題になりにくいケースもあります。
個人開発・小規模で意思決定が速い
1人、または少人数で作る場合は、判断も修正も自分たちですぐできます。
「この書き方やめよう」と思ったら、すぐ変えられるのは大きな強みです。
この場合は、Lombokのデメリットが表に出にくいです。
“読みやすさ”より“書く速さ”が優先の場面
短期間の検証や、まず動くものを作りたい段階では、書くスピードが大事になります。
このフェーズなら、コードが多少見えにくくても問題になりにくいです。
使う範囲を狭く決められるチーム
「DTOだけ」「Getterだけ」など、使う場所をきちんと決められるなら話は別です。
全部に使うのではなく、限定することで事故はかなり減らせます。
Lombokは、
だと思っておくと、チーム内の対立も減りますよ。
次は、使うと決めた場合に最低限守りたいルールをチェックリスト形式でまとめます。
使うならこれだけ守る！注意点チェックリスト（チーム向け）
「使わない」も正解ですが、「使う」と決めたならルール作りが超重要です。
ここでは、そのままコピペして使えるレベルのチェックリストを用意しました。
最低限のルール例（禁止／許可の線引き）
まずは、やらないことを決めるのがおすすめです。
「全部ダメ」ではなく、「ここまではOK」を決めるのがポイントです。
@Dataをむやみに使わない代替案
@Dataは便利ですが、やりすぎになりやすいです。
代わりに、必要なものだけ付けるのがおすすめです。
こうするだけで、「勝手に動く感」はかなり減ります。
事故を減らすレビュー観点
レビューでは、こんな点を見ると安心です。
Lombokを使っているかどうかより、意図が説明できるかを重視しましょう。
導入・運用の手順（IDE/ビルド/ドキュメント）
最後に、運用ルールです。
これだけで、「自分だけ動かない問題」はかなり防げます。
次は、Lombokを使わなくても困らない代替手段を紹介しますよ。
Lombokなしで困らない代替手段（「無理に使わない」選択肢）
「Lombokを使わないと、コードが長くて大変そう…」
そう感じる人も多いですが、実は無理に使わなくても楽になる方法はあります。
IDEの自動生成（Getter / Setter / equals など）
多くのIDEには、コードを自動で作ってくれる機能があります。
ボタン操作だけで、GetterやSetter、比較用のメソッドをまとめて作れます。
ポイントは、生成されたコードがそのまま見えることです。
あとから読んでも「ここでこうしてるんだな」と分かるので、学習中やレビュー重視の場面と相性がいいです。
Javaの仕組みでスッキリ書く工夫（設計・役割分け）
そもそもクラスの役割を小さく分けると、書くコード自体が減ります。
「1クラスで何でもやらない」が基本です。
を分けるだけでも、必要なGetterやSetterはかなり減ります。
結果的に、「Lombokがないとツラい」状態になりにくくなります。
どうしても面倒なら“限定的に使う”という折衷案
完全に使わない、も正解ですが、
「ここだけは楽したい」という場合もありますよね。
その場合は、
など、範囲をガチガチに限定するのがおすすめです。
これなら、見えなくなりすぎず、楽もできます。
次はいよいよまとめです。
「結局どう決めればいいの？」をスパッと整理しますよ。
まとめ：結論は「目的しだい」。迷うなら小さく始めよう
ここまで読んでいただき、ありがとうございます。
Lombokについての結論は、とてもシンプルです。
「便利だから使う」「みんな使ってるから使う」ではなく、
何を大事にしたいかで選ぶのがポイントです。
もしチームで使うなら、最初に決めておくとラクなテンプレがあります。
これを最初に1回決めるだけで、あとがかなり楽になります。
迷っているなら、まずは使わない状態からスタートしてみてください。
必要になったら、小さく・限定的に取り入れる。
それくらいの距離感が、Lombokとはちょうどいいですよ。
よくある質問
- QLombokって、使わないとダメなんですか？
- A
いいえ、まったくダメじゃないです。
Lombokは「必須ツール」ではなく、「便利な選択肢の1つ」です。使わなくても、JavaやSpring Bootの開発は普通にできますし、
学習中なら「使わない方が分かりやすい」ことも多いです。
- Q@Dataって、そんなに危険なんですか？
- A
危険というより、便利すぎて事故りやすいです。
Getter・Setter・比較用メソッドなどを一気に作るので、- 触ってほしくない値が変えられる
- 思ってない比較が行われる
といったことが起きやすくなります。
理由なくポン付けするのは避けた方が安心です。
- Qチームで使うなら、まず何を決めればいいですか？
- A
最初はこれだけでOKです。
細かいルールより、最低限の共通認識が一番大事です。
- QLombokを途中でやめるのって大変ですか？
- A
正直に言うと、使い方しだいです。
あちこちで大量に使っていると、消すのはちょっと大変です。でも、
こうしていれば、やめるコストはかなり低くなります。
- Q初心者は、いつからLombokを使えばいいですか？
- A
目安としては、
**「自分でGetterやSetterを書いて説明できるようになってから」**です。仕組みが分かっていれば、
「これはLombokで楽していいな」
という判断もちゃんとできるようになります。