Lombokとは？Java開発のコード量を激減させる使い方入門

Lombokとは、Javaの冗長なGetter・Setter・toString・コンストラクタなどを、アノテーション1つで自動生成してくれるライブラリです。

GetterやSetterを手で書く必要がなくなるのでクラスの記述量が大きく減り、本来書きたいビジネスロジックに集中できます。

この記事では、Lombokの導入方法から@Data・@Builder・@Valueなど実務で頻出するアノテーションの使い分け、さらにJava Recordとの比較まで、現場経験をもとにコード例付きで解説します。

Lombokとは？Java開発で何が楽になるのか

Lombokは、Javaの冗長なコードをアノテーション1つで自動生成してくれるライブラリです。

Javaを書く上で避けて通れないGetter、Setter、toStringといった「決まり切ったコード」を、コンパイル時にこっそり作ってくれます。

私は以前、Lombokを使わずに1,000行を超える巨大なEntityクラスを管理していました。

しかし、Lombokを導入した瞬間にそのクラスは100行まで縮小されたのです。

コードの量が減るということは、それだけバグが紛れ込む隙間がなくなることを意味します。

Lombokが提供する価値は、単なる「タイピングの削減」ではありません。

開発者が「ドメインロジック（本当に書きたい処理）」に集中できる環境を整えてくれる点にこそ本質があります。

昔の私は「IDEの自動生成機能があるからLombokなんて不要だ」と考えていました。

生成されたコードがソースファイルに残る以上、読み手はその「ノイズ」を毎回スルーしなければなりません。

Lombokを使えば、ソースコードは極限までクリーンに保たれます。これにより、レビューの質も向上し、チーム全体の開発スピードが底上げされるのです。

Javaで毎回書く「同じコード」が発生する理由

Javaという言語は、カプセル化やオブジェクト指向の原則を重んじる設計になっています。

そのため、フィールドを隠してメソッド経由でアクセスする文化が根付いています。

メソッド経由のアクセスが、GetterやSetterの大量発生を招く原因です。

2026年になっても、古い設計のシステムや特定のフレームワークでは、この構造が求められ続けています。

クラスを1つ作るたびに、私たちはコンストラクタやequals、hashCodeといったメソッドを定義しなければなりません。

これらは「ボイラープレートコード（お決まりの型）」と呼ばれ、開発者の創造性を奪う要因となります。

しかも、フィールドを1つ追加するたびに、これらすべてのメソッドを修正しなければなりません。

ボイラープレートの手作業が、Java開発を「重たいもの」にしている正体です。

Lombokが解決する問題と、導入する価値

Lombokを導入すれば、前述した「修正の連鎖」から完全に解放されます。

フィールドにアノテーションを添えるだけで、必要なメソッドがすべてバックグラウンドで生成されるからです。

メソッドの自動生成により、コードの保守性が飛躍的に高まります。

私が経験したプロジェクトでは、Lombokの導入によりクラスの行数が平均して60パーセント以上削減されました。

また、手書きによるタイポや実装漏れを防げるのも大きなメリットです。

例えば、equalsとhashCodeを片方だけ更新し忘れるというミスは、デバッグが困難なバグを引き起こします。

Lombokなら、そういった整合性の問題を機械的に解決してくれるのです。

ツールに任せられる部分は任せ、人間はより高度な設計に時間を使うべきだと私は確信しています。

Lombokを使い始めるまでの準備と注意点

Lombokを使い始めるには、単にライブラリを追加するだけでは不十分です。IDE（統合開発環境）との連携設定が必須であることを覚えておいてください。

私は初心者の頃、依存関係だけ設定して「コードが動かない！」と3時間ほど悩んだ苦い記憶があります。

Lombokはコンパイル時にコードを生成するという特殊な動きをするため、エディタ側にもLombokのコード生成を理解させる必要があります。

Lombokを使い始めるには、以下の3つの準備が必要です。

1. ライブラリ依存の追加（Maven / Gradle）
2. IDEプラグインの導入（IntelliJ IDEA / VS Code）
3. Annotation Processingの有効化

また、Lombokは強力ですが、プロジェクトのメンバー全員がその仕組みを理解している必要があります。

2026年の開発環境では標準的になりつつありますが、それでも「魔法のような動作」を嫌うエンジニアは存在します。

導入前に、なぜLombokを使うのか、どのようなルールで運用するのかをチーム内で合意しておくことが、スムーズな開発への第一歩です。

準備を怠ると、コンパイルエラーの嵐に心を折られることになるので注意しましょう。

Lombok導入に必要なライブラリ設定（Maven／Gradle）

ビルドツールへの設定はシンプルです。

Mavenであれば pom.xml に、Gradleであれば build.gradle に依存関係を記述するだけです。

Gradle 5以降・MavenでannotationProcessorPathsを明示する構成では、アノテーションプロセッサとしての設定も明示的に行う必要があります。

Gradleの例

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

compileOnly を使うのがポイントです。Lombokは実行時には不要なライブラリなので、成果物のサイズを無駄に大きくしません。

こうした「開発時だけ助けてくれる」潔さが、私がLombokを愛用している理由の1つです。

Mavenの例

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

Lombokの最新バージョンとJava 25対応状況

上のコード例は、2026年9月時点のLombok 1.18.48をもとにしています。新しい版はMaven Centralで確かめて置き換えてください。

Lombokは新しいJDKが出るたびに対応版をリリースしています。公式のchangelogに記載されている主な対応状況は次のとおりです。

Java 25で使う場合は、少なくとも1.18.40以上が必要です。なお1.18.44では、JDK 25で val や @ExtensionMethod が誤ったエラーを出すことがある不具合も修正されています。

JDKのバージョンを上げたとたんにビルドが通らなくなった場合は、まずLombokのバージョンが新しいJDKに対応しているかを確認してください。

IDE設定でつまずきやすいポイント（IntelliJ IDEA中心）

IntelliJ IDEAを使用している場合、Lombokプラグインが有効になっていることと、「Annotation Processing」が有効になっていることを確認してください。

なお、IntelliJ IDEA 2020.3以降ではLombokプラグインがバンドル済みのため、別途インストールは不要です。

設定画面から Build, Execution, Deployment > Compiler > Annotation Processors を開き、チェックボックスをオンにしてください。

Annotation Processingの有効化を忘れると、エディタ上でGetterメソッドなどに赤線が表示されてしまいます。

コードは正しいのにエラーが出る状態は、精神衛生上よくありません。

VS Codeを使っている場合も、対応する拡張機能をインストールすることを忘れないでください。

環境構築さえ終われば、あとは快適なコーディングタイムが待っています。

Lombokの基本アノテーションと使い方

Lombokの機能は多岐にわたりますが、まずは主要な3つのグループを覚えれば十分です。3つのグループだけで、Javaコードの8割はスッキリします。

私は最初、すべての機能を一度に覚えようとして混乱してしまいました。実際の実務で頻繁に使うものは限られています。

基本をマスターすれば、クラス定義の冒頭を見るだけでそのクラスが何をするものか瞬時に判断できるようになります。

コードの「読みやすさ」は、チーム開発における最大の正義です。Lombokのアノテーションは、まるでコードに貼られた付箋のような役割を果たしてくれます。

ここからは、私が「これだけは外せない」と感じている基本機能を紹介しましょう。

@Getter / @Setterで何が自動生成されるのか

もっとも利用頻度が高いのが、この @Getter と @Setter です。

フィールドの上に書けばそのフィールド専用、クラスの上に書けばすべてのフィールドに対してアクセス用メソッドが作られます。

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

たったこれだけで、getName() や setAge() が使えるようになります。手書きなら20行ほど必要だったコードが、実質2行で済むのです。

アクセスレベルを AccessLevel.PROTECTED などで細かく制御できる点も、痒いところに手が届く設計だと感心します。

@ToString / @EqualsAndHashCodeの使いどころ

デバッグ時に役立つのが @ToString です。@ToStringを付けるだけで、オブジェクトの中身を綺麗に文字列として出力できるようになります。

私はログ出力の際、このアノテーションに何度も救われてきました。

また、オブジェクトの比較に欠かせない @EqualsAndHashCode も重要です。

すべてのフィールドを考慮した比較ロジックを自分で書くのは苦行ですが、Lombokなら一瞬です。

特定のフィールドを比較対象から外す設定も簡単にできるため、柔軟な設計が可能になります。

これらをセットで使うことで、クラスとしての完成度が一段階上がります。

@NoArgsConstructor / @AllArgsConstructorの役割

コンストラクタの生成もLombokにお任せしましょう。

引数なしの @NoArgsConstructor は、JPA（Java Persistence API）などを使う際に重宝します。

一方、すべてのフィールドを引数に取る @AllArgsConstructor は、テストコードを書くときに便利です。

「必須のフィールドだけを引数に取りたい」という場合は、@RequiredArgsConstructor を使いましょう。

@RequiredArgsConstructorは、初期化されていないfinalフィールドと、初期化されていない@NonNull付きのフィールドを引数に取るコンストラクタを作ります。

依存性の注入（DI）をコンストラクタで行う現代のJava開発において、このアノテーションはもはや必須装備です。

実務で頻出のLombokアノテーション

基本を押さえたら、次はもう少し踏み込んだ機能に目を向けてみましょう。

実務では、単なるGetter/Setter以上の仕組みが求められる場面が多々あります。

例えば、不変（Immutable）なオブジェクトを作りたいときや、複雑な生成ロジックをスッキリさせたいときです。

私は過去に、複雑なパラメータを持つクラスのインスタンス化で苦労した経験があります。

コンストラクタの引数が10個もあると、どの値が何を指しているのか混乱し、引数の順番を間違えてバグを出したこともありました。

そんなときに役立つのが、@Data・@Builder・@Valueの3つです。

これらを適切に使い分けることで、コードの安全性と表現力が格段に向上します。

@Dataは便利だが注意が必要な理由

@Dataは「全部入り」のアノテーションです。

@Getter, @Setter, @ToString, @EqualsAndHashCode, @RequiredArgsConstructorをまとめて適用します。

とにかく楽をしたいときには最適ですが、私は乱用を避けています。

理由は、意図しないメソッドまで公開されてしまうからです。例えば、以下のようなケースです。

// @Dataを使うと、passwordにもSetterが生成される
@Data
public class UserAccount {
    private String email;
    private String password;  // 外部から変更されたくない
    private LocalDateTime createdAt;
}

この場合、setPassword() が外部に公開されてしまい、意図しない箇所からパスワードが書き換えられるリスクがあります。

安全にするには @Getter のみをクラスに付け、変更可能にしたいフィールドだけに個別で @Setter を付ける方法が確実です。

便利さと安全性は常にトレードオフの関係にあります。

初学者のうちは @Data で始めても良いですが、慣れてきたら必要なものだけを個別に指定するスタイルに移行することをお勧めします。

@Builderでオブジェクト生成を安全にする考え方

複雑なオブジェクトを組み立てるなら @Builder が最強の味方です。メソッドチェーンのような形式で値をセットできるため、可読性が劇的に上がります。

User user = User.builder()
                .name("田中")
                .age(25)
                .email("test@example.com")
                .build();

Builderパターンなら引数の順番を間違える心配もありませんし、どのフィールドに何をセットしているかが一目瞭然です。

私は、特にテストデータを作成する際や、Web APIのレスポンス用DTO（Data Transfer Object）を作るときに多用しています。

一度この快適さを知ると、長い引数のコンストラクタには二度と戻れません。

@Valueで不変オブジェクトを表現する

現代のプログラミングでは「不変性（Immutability）」が重視されます。

状態が変わらないオブジェクトは、並列処理に強く、バグも入りにくいからです。

@Value は、そんな不変オブジェクトを簡単に作るためのアノテーションです。

@Valueを付けると、すべてのフィールドがデフォルトで private final になり、Setterも生成されません。

@Data の不変版だと考えるとわかりやすいです。

私は、値そのものを表すクラス（Value Object）を設計する際、必ず @Value を使うようにしています。

コードが「このオブジェクトは変わりませんよ」という強いメッセージを放つようになり、設計の意図が明確に伝わるようになります。

@Slf4j / @Logでロガーを自動生成する

実務で意外と重宝するのが、ロガーの自動生成です。

@Slf4j をクラスに付けるだけで、private static final Logger log = LoggerFactory.getLogger(クラス名.class); という定型コードが不要になります。

@Slf4j
public class OrderService {
    public void processOrder(Order order) {
        log.info("注文処理開始: {}", order.getId());
    }
}

SLF4J以外にも、@Log（java.util.logging）、@Log4j2（Log4j 2）など、使用しているロギングフレームワークに応じたアノテーションが用意されています。

プロジェクトのロギング基盤に合わせて選択してください。

私のプロジェクトでは @Slf4j を標準としており、全クラスで1行ずつ節約できるのは地味ですが確実な効率化です。

@NonNull / @Withの使いどころ

ここまでのアノテーションに加えて、覚えておくと便利なのが @NonNull と @With です。

@NonNull をフィールドや引数に付けると、Lombokがnullチェックのコードを自動で挿入します。nullが渡された時点で NullPointerException が発生するため、不正な値が奥の処理まで入り込むのを防げます。

@With は、特定のフィールドだけを変更した「新しいインスタンス」を返す withXxx() メソッドを生成します。元のオブジェクトは変更しないので、@Value で作った不変オブジェクトと組み合わせると相性が良いです。

import lombok.NonNull;
import lombok.Value;
import lombok.With;

@Value
public class User {
    @NonNull String name;
    @With int age;
}

// 使用例
User taro = new User("太郎", 20);
User olderTaro = taro.withAge(21); // ageだけ変えた新しいインスタンス
User invalid = new User(null, 20); // NullPointerExceptionが発生

不変オブジェクトを使いつつ一部の値だけ変えたい場面では、Setterの代わりに @With を使うと安全に書けます。

Lombokの注意点と安全な使い方

Lombokは強力なツールですが、それゆえに「魔法」と勘違いしてはいけません。

裏側で何が起きているのかを理解せずに使っていると、予期せぬトラブルに見舞われることがあります。

私はかつて、Lombokの仕様を誤解したまま継承関係のあるクラスに @EqualsAndHashCode を使い、正しく比較が行われないというバグを仕込んでしまったことがあります。

ツールに使われるのではなく、ツールを使いこなす。そのためには、Lombokが生成するコードの「振る舞い」を常に意識する必要があります。

また、コードが読みやすくなる一方で、エディタ上で「定義が見えない」という側面があることも忘れてはいけません。

チーム開発において、Lombokをどのように活用し、どこで制限をかけるべきか。その設計思想について解説します。

Lombokは「魔法」ではなくコード生成だという前提

Lombokの正体は、コンパイル時にJavaの抽象構文木（AST）を書き換えるライブラリです。

javacがソースコードをclassファイルに変換するまでの流れの中で、Lombokがどこに割り込んでいるかを図にすると次のようになります。

つまり、最終的に出力されるクラスファイルには、私たちが省略したGetterやSetterがしっかりと書き込まれています。

これを理解していれば、リフレクションなどでメソッドを探す際にも戸惑うことはありません。

「魔法」だと思っていると、ライブラリのバージョンアップで挙動が変わったときに対処できなくなります。

私は時折、コンパイル後のクラスファイルをデコンパイルして、Lombokがどのようなコードを生成したか確認するようにしています。

自分の意図通りにツールが動いているかを確認する作業は、プロフェッショナルとして欠かせないプロセスです。

可読性が下がるケースとその回避策

「コードが短くなる＝読みやすくなる」とは限りません。例えば、クラスに10個以上のアノテーションが並んでいる光景は、初見のエンジニアを混乱させます。

また、Lombokが生成したメソッドは、ソースコード上には存在しないため、IDEの「宣言へジャンプ」機能を使っても飛び先はフィールドやアノテーションで、具体的な実装は見えません。

可読性低下を回避するには、複雑なロジックが必要なメソッドだけは手書きにするという柔軟な姿勢が大切です。

Lombokは、手書きのメソッドが既に存在する場合は、そのメソッドの自動生成をスキップしてくれます。

すべてをLombokに委ねるのではなく、要所要所で手書きを混ぜる。このバランス感覚こそが、美しいコードを生む秘訣です。

チーム開発で合意しておきたい利用ルール

チームでLombokを導入する際は、必ずコーディング規約を設けましょう。

例えば「Entityクラスには @Getter と @Setter を使い、DTOには @Value を使う」といった指針です。

ルールがないと、人によって @Data を使ったり使わなかったりと、コードの統一感が失われてしまいます。

また、新しいメンバーが入ってきたときの教育コストも考慮すべきです。

Lombok独自の挙動（例えば @Builder.Default の使い方など）は、知らないとハマりやすいポイントです。

私がリーダーを務めるプロジェクトでは、Lombokのベストプラクティスをまとめたドキュメントを用意し、誰でも同じ品質でコードを書けるように工夫しています。

具体的には、プロジェクトルートに lombok.config ファイルを置くことで、チーム全体の挙動を統一できます。

# lombok.config（プロジェクトルートに配置）
config.stopBubbling = true
lombok.addLombokGeneratedAnnotation = true
lombok.extern.findbugs.addSuppressFBWarnings = true

addLombokGeneratedAnnotation を有効にすると、生成されたコードに @Generated アノテーションが付き、JaCoCoなどのカバレッジツールが自動生成コードを除外してくれます。なお1.18.34以降は、この設定を書かなくても既定で @Generated が付きます（1.18.48で確認）。

地味な設定ですが、テストカバレッジのノイズを減らすのに効果的です。

Lombokは非推奨？使わない方がいいと言われる理由

「Lombokは非推奨」「使わない方がいい」という声を見かけることがありますが、Lombok自体が公式に非推奨（deprecated）になったわけではありません。2026年9月にも新しいバージョンがリリースされており、開発は継続しています。

それでも慎重論が出る主な理由は、次の3つです。

• JDKの内部の仕組みに依存している：Lombokはコンパイラの内部に入り込んでコードを生成するため、新しいJDKが出るたびにLombok側の対応版を待つ必要がある
• 生成コードがソース上に見えない：前述のとおり、実装がアノテーションの裏に隠れるため、仕組みを知らないメンバーには挙動が追いにくい
• 標準機能で代替できる場面が増えた：不変なデータの入れ物ならJava標準のrecordで十分に書ける

もし将来Lombokをやめたくなっても、公式ツールの delombok を使えば、アノテーションを展開した通常のJavaコードに変換できます。「いつでも抜けられる」逃げ道が用意されている点は、導入判断の安心材料になります。

LombokとJava Recordの比較と使い分け

2026年の今、Java開発においてLombokは唯一の選択肢ではありません。

Java 16で導入された「Record」をはじめ、言語そのものがボイラープレートを削減する方向に進化しているからです。

私は、新しくプロジェクトを立ち上げる際、あえてLombokを使わないという選択肢も真剣に検討します。

ツールの導入には常に依存関係のリスクが伴います。ライブラリの脆弱性や、将来的なメンテナンス停止の可能性もゼロではありません。

Lombokが提供する便利さと、標準機能だけで戦うシンプルさ。どちらがプロジェクトの長期的な利益になるかを天秤にかける必要があります。

以下では、Java Recordとの比較を通じて、Lombokの立ち位置を再確認してみましょう。

Record（Java 16以降）との役割の違い

Recordは、不変なデータを保持するためだけに特化したクラス形式です。

Java 14でプレビュー機能として登場し、Java 16（JEP 395）で正式機能になりました。recordの書き方やclassとの違いは「Javaのrecordとは？classとの違い・使い方」で詳しく解説しています。

短く書けるのが特徴で、Lombokの @Value に近い役割を持っています。

標準機能であるため、ライブラリを追加する必要がなく、IDEとの相性も抜群です。

しかし、Recordには「継承ができない」「すべてのフィールドが強制的にfinalになる」「JPA/Hibernateのエンティティとして使えない（no-argコンストラクタ・Setter不在のため）」といった制約があります。

一方でLombokは、既存のクラス構造を保ったままコードを削減できるため、柔軟性は圧倒的に高いです。

私は、単純なデータ転送にはRecordを使い、複雑なロジックや状態変化を伴うクラスにはLombokを使う、という使い分けを推奨しています。

手書きコードとLombok、どちらを選ぶべきか

究極の選択ですが、私は「基本はLombok、ただし極小規模なツールなら手書き」というスタンスを取っています。

大規模な開発で手書きに固執するのは、現代では非効率だと言わざるを得ません。

手書きの安心感よりも、Lombokがもたらす「変更への強さ」の方が価値が高いからです。

ただし、Lombokへの依存が強すぎると、Java本来の書き方を忘れてしまう恐れがあります。

特に若手エンジニアには、一度はLombokなしでクラスを完成させ、その苦労を知ってもらうようにしています。

不便さを知っているからこそ、ツールのありがたみが理解でき、適切な使いどころを見極める力が養われるのです。

Lombokに関するよくある質問

Lombokとは何ですか？

Lombokとは、Javaのgetter/setter・コンストラクタ・toString等の定型コードをアノテーション1つで自動生成してくれるライブラリです。@Getter・@Setter・@Data等を付けるだけでボイラープレートコードを大幅に削減できます。

LombokとJava Recordはどちらを使うべきですか？

単純な不変データの入れ物であればJava Record、可変フィールドやEntity（JPA）のように後からフィールドを追加・変更する可能性があるクラスにはLombokの@Dataや個別アノテーションが向いています。両者は排他ではなく、用途によって使い分けるのが実務的です。

Lombokを使う際の注意点はありますか？

@Dataを安易に使うと不要なsetterまで生成されカプセル化が崩れる、@EqualsAndHashCodeの自動生成がJPA Entityで循環参照（AとBが互いを参照し合い、比較処理が無限に呼び出され続けてスタックオーバーフローになること）を起こす等の注意点があります。IDE側でLombokのサポート（IntelliJ IDEA 2020.3以降はバンドル済みのプラグイン、VS Codeは拡張機能）が有効でないとコード補完が効かない点にも注意が必要です。

まとめ：Lombokの導入判断と使い方の指針

Lombokの要点を整理します。

• Lombokはアノテーション1つでGetter / Setter / toString等を自動生成するライブラリ
• 導入にはライブラリ追加＋IDEのAnnotation Processing有効化が必須
• @Getter / @Setter / @ToStringが基本。慣れたら@RequiredArgsConstructorに挑戦
• @Dataは便利だが意図しないSetterに注意。必要なものだけ個別指定がベスト
• @Builderで複雑なオブジェクト生成を安全に、@Valueで不変オブジェクトを表現
• @Slf4jでロガーの定型宣言も自動生成できる（SLF4J / Log4j2対応）
• 手書きメソッドが既にあればLombokは自動生成をスキップする（併用可能）
• 単純なデータ転送にはJava Record、複雑なクラスにはLombokと使い分ける

LombokはあなたのJava開発を間違いなく豊かにしてくれます。私自身、このツールに出会ってから、コードを書く喜びを再発見しました。

冗長な記述に悩まされず、ロジックの美しさを追求できる。それこそが、本来のプログラミングのあるべき姿です。

Lombokはあくまで手段であり、目的ではありません。ユーザーに価値を届けるソフトウェアを、素早く安全に作り上げることが目的です。

そのためにLombokが最適だと判断したなら、自信を持って導入してください。

初心者がまず押さえるべき使い方の指針

まずは、自分のプロジェクトのEntityやDTOに @Getter と @ToString を付けるところから始めてみてください。

それだけで、コードの見た目がスッキリし、ログ出力が格段に楽になるのを実感できます。背伸びをして難しいアノテーションに手を出す必要はありません。

慣れてきたら、コンストラクタ生成系の @RequiredArgsConstructor に挑戦しましょう。

これを使うことで、DI（依存性の注入）の記述が驚くほど綺麗になります。

一歩ずつ、自分が「便利だ」と心から思える範囲を広げていくのが、挫折しないコツです。

失敗を恐れず、まずは小さなクラスからLombokの力を試してみてください。

Lombokを使う・使わないを判断する基準

Lombokを使うべきなのは、ボイラープレートコードが開発のノイズになっていると感じるときです。

具体的には、フィールド数が多いクラスが頻繁に登場するプロジェクトや、スピード感が求められる開発現場などが挙げられます。

逆に、Javaの標準機能（Recordなど）だけで十分に要件を満たせる場合や、外部ライブラリの導入に厳しい制約がある環境では、無理に使う必要はありません。

2026年のエンジニアには、最新の言語仕様と外部ツールの特性を理解し、その場で「最適解」を選び取る柔軟性が求められています。

あなたのプロジェクトにとっての正解は、あなた自身の経験の中にあります。