Java NullPointerExceptionの原因と対処

RJC Techチーム

NullPointerException（NPE）は、「中身が空（null）の参照に対して、メソッド呼び出しやフィールドアクセスをしようとした」ときにJavaが投げる例外です。Java入門者が最初に出会う例外であり、経験者でも本番障害の常連です。nullを考案した本人が後年「10億ドルの過ち」と振り返ったほど、この問題は根深いものです。

この記事では、エラーメッセージの読み方（Java 14以降はメッセージがnullだった変数を教えてくれます）、よくある原因の5パターン、そしてそもそもNPEが起きない設計——Optional・record・アノテーション——までを、一本で通して解説します。

まず、エラーメッセージを読む

NPEの調査は、スタックトレースを読むところから始まります。

Exception in thread "main" java.lang.NullPointerException:
    Cannot invoke "String.length()" because "user.getName()" is null
    at com.example.UserService.validate(UserService.java:42)
    at com.example.UserService.register(UserService.java:20)

読み方は3段階です。

1行目の例外名とメッセージ — 何が起きたか。上の例では「user.getName() がnullだったので String.length() を呼べなかった」と、nullだった式そのものが書かれています
at で始まる行の、自分のパッケージが最初に出てくる行 — 事故現場。UserService.java の42行目です
その下の行 — そこに至った呼び出し経路

Java 14以降は「何がnullだったか」を教えてくれる

Java 14で導入された Helpful NullPointerExceptions により、上の例のように「どの式がnullだったか」がメッセージに含まれるようになりました（Java 15以降は既定で有効）。

古いJavaでは「NullPointerException」とだけ出て、1行に複数の呼び出しがあると「どれがnullか」を自分で切り分ける必要がありました。メッセージに式が出ていない場合は、まずJavaのバージョンを確認してください。

よくある原因5パターン

1. 初期化していないフィールド

private List<String> items;   // 宣言だけ。newしていない
public void add(String s) { items.add(s); }  // NPE

対処：宣言時に初期化する（= new ArrayList<>()）か、コンストラクタで必ず代入する。final を付けると、代入忘れをコンパイラが検出してくれます。

2. メソッドの戻り値がnull

User user = repository.findById(id);   // 見つからないとnullを返す
user.getName();                        // NPE

対処：戻り値がnullになり得るメソッドかを、呼び出す側が確認する。根本対策は、後述のOptionalで「無いかもしれない」を型で表現することです。

3. Mapのgetで存在しないキー

Map<String, Integer> stock = ...;
int count = stock.get("apple");   // キーが無いとnull → intへの変換でNPE

対処：getOrDefault("apple", 0) を使う、または containsKey で確認する。プリミティブ型への自動変換（アンボクシング）がNPEの発生源になる、見落としやすいパターンです。

4. 文字列の比較で、変数側を左に書いている

if (status.equals("ACTIVE")) { ... }   // statusがnullならNPE

対処：定数を左に書く（"ACTIVE".equals(status)）。これならstatusがnullでも false が返ります。Objects.equals(a, b) を使えば、どちらがnullでも安全です。

5. 外部から来たデータ（JSON・DB・リクエスト）の項目が欠けている

String zip = request.getAddress().getZipCode();   // addressが無いとNPE

対処：境界（APIの入口・DBからの取得）で必須項目を検証する。「後続の処理は、nullが来ない前提で書く」と決めて、入口で守るのが定石です。

対症療法：nullチェックの書き方

if (user != null && user.getName() != null) {
    ...
}

これで例外は防げますが、コードが != null だらけになり、「本当にnullが来るのか」「来たら何が正しいのか」が読めなくなります。nullチェックは最後の手段にして、次の設計で「nullを作らない」方向に寄せるのが現代の書き方です。

予防設計1：Optionalで「無いかもしれない」を型で表す

// 戻り値に Optional を使う
public Optional<User> findById(String id) { ... }
// 呼び出し側は、無い場合の扱いを必ず書くことになる
String name = repository.findById(id)
        .map(User::getName)
        .orElse("（未登録）");

Optionalは、「値が無いかもしれない」ことを戻り値の型で宣言する仕組みです。呼び出す側は map / orElse / orElseThrow などで「無いときどうするか」を書かざるを得ないので、nullチェックの書き忘れが構造的に減ります。

使いどころの注意：Optionalは戻り値のためのものです。フィールドやメソッド引数にOptionalを使うのは推奨されていません。また、optional.get() を確認なしで呼ぶと結局NPE相当（NoSuchElementException）になるので、get() は避けて orElse 系を使います。

予防設計2：recordとfinalで「作った瞬間に揃っている」状態にする

public record Address(String zipCode, String city) {
    public Address {
        Objects.requireNonNull(zipCode, "zipCode");
        Objects.requireNonNull(city, "city");
    }
}

recordはフィールドが不変で、コンストラクタで検証すれば「不完全なオブジェクトが存在できない」状態になります。原因1（初期化忘れ）は、この設計で消えます。Objects.requireNonNull は、nullが渡された時点で、分かりやすいメッセージ付きで例外を出してくれるので、原因の特定が早くなります。