java.lang.NoClassDefFoundErrorの原因と対策｜ClassNotFoundExceptionとの違いまで解説

2026年3月12日

例外処理・デバッグ

Javaアプリケーションの開発や運用において、多くのエンジニアを悩ませるのが「クラスが見つからない」というトラブルです。

その中でも特に、コンパイルは通るのに実行時に突如として発生する java.lang.NoClassDefFoundError は、原因の特定が難しく、修正に時間を要することが少なくありません。

本記事では、このエラーが発生する根本的なメカニズムから、混同されやすい ClassNotFoundException との決定的な違い、そして現代のJava開発（MavenやGradle、モダンなランタイム環境）において遭遇しやすい具体的な原因と対策まで、プロの視点で徹底的に解説します。

この記事を読み終える頃には、クラスロードに関するトラブルシューティングのスキルが一段階向上しているはずです。

目次 [ close ]

java.lang.NoClassDefFoundErrorとは何か

java.lang.NoClassDefFoundError は、Java仮想マシン (JVM) が特定のクラスをロードしようとした際に、その定義が見つからなかった場合にスローされるエラーです。

最大の特徴は、「コンパイル時にはそのクラスが存在しており、正常にビルドが完了していた」という点にあります。

Javaのコンパイラは、ソースコード内で参照されているクラスがクラスパス上に存在するかをチェックします。

しかし、プログラムの実行段階において、何らかの理由でそのクラスファイル (.class) にアクセスできなくなった場合に、このエラーが牙を剥きます。

Javaの例外階層において、これは java.lang.Exception ではなく java.lang.Error のサブクラスとして定義されています。

Javaにおける「Error」は、アプリケーション側でキャッチして回復することを想定していない、実行環境における致命的な問題を意味します。

そのため、単なるコーディングミスというよりも、環境構築や依存ライブラリの管理、ビルドプロセスの不備に起因することがほとんどです。

NoClassDefFoundErrorとClassNotFoundExceptionの違い

Java初学者が最も混乱しやすいポイントの一つが、名前の似ている ClassNotFoundException との使い分けです。

これらは発生するタイミングも原因も明確に異なります。

根本的な発生メカニズムの比較

ClassNotFoundException は、プログラムが実行中に明示的にクラスをロードしようとした時に発生します。

例えば、Class.forName() や ClassLoader.loadClass() を使用し、文字列で指定したクラス名が見つからない場合です。

これは「チェック例外」として扱われ、try-catchによるハンドリングが強制されることもあります。

対して NoClassDefFoundError は、JVMが通常の処理（メソッド呼び出しやインスタンス化）の流れで、暗黙的にクラスをロードしようとして失敗した時に発生します。

多くの場合、コンパイル時には存在していたクラスが、実行時のクラスパスから消えていることが原因です。

比較表

以下に、両者の違いを整理しました。

特徴	java.lang.ClassNotFoundException	java.lang.NoClassDefFoundError
型	Exception (チェック例外)	Error (致命的なエラー)
発生タイミング	実行時に動的にロードを試みた時	コンパイル時は存在したが実行時に消失した時
主なトリガー	`Class.forName()`、`loadClass()`	newによるインスタンス化、メソッド呼び出し
原因の所在	クラス名のタイポ、動的なパス指定ミス	クラスパス設定不備、ビルド漏れ、初期化失敗
解決の難易度	比較的容易（指定ミスを探す）	やや困難（環境や依存関係を調査）

NoClassDefFoundErrorが発生する主な原因

このエラーを解消するためには、なぜ「実行時にだけ」クラスが消えてしまうのかを理解する必要があります。

主な原因は以下の3点に集約されます。

1. 実行時のクラスパス不足

最も一般的な原因は、コンパイル時に使用したJARファイルやクラスディレクトリが、実行時の環境（クラスパス）に含まれていないことです。

例えば、外部ライブラリ (A.jar) に依存するプログラムを開発し、ローカル環境ではIDEの設定でパスが通っていても、サーバーにデプロイした際に A.jar を配置し忘れたり、起動スクリプトの -cp オプションに含め忘れたりすると発生します。

2. 依存ライブラリのバージョン競合

MavenやGradleなどのビルドツールを使用している場合、複数のライブラリが同じクラスの異なるバージョンを要求することがあります。

ビルドツールによる依存関係の解決の結果、特定のクラスが含まれないバージョンのJARが選ばれてしまうと、コンパイルは成功しても、実行時にそのクラスを探しに行った際に「定義が見つからない」という事態に陥ります。

3. 静的初期化ブロックでの例外 (重要)

意外と見落とされがちなのが、クラスの静的初期化子 (staticブロック) で例外が発生した場合です。

Javaでは、あるクラスのロードに一度失敗（具体的には ExceptionInInitializerError が発生）すると、その後の実行過程で同じクラスを再度参照しようとした際、JVMは「ロードに失敗したクラス」として記憶しているため、2回目以降のアクセスでは NoClassDefFoundError を投げます。

この場合、本当の原因はログのさらに上の方に隠れている初期化エラーにあります。

具体的な発生ケースとコード例

ここでは、原因の特定が難しい「静的初期化子の失敗」によるケースをコードで再現してみましょう。

まず、初期化時に必ず例外を投げるクラスを作成します。

Java

public class ProblematicClass {
    // 静的初期化ブロック
    static {
        // 実行時に何らかの理由で例外が発生したと仮定
        if (true) {
            throw new RuntimeException("静的初期化中に重大なエラーが発生しました");
        }
    }

    public static void doSomething() {
        System.out.println("メソッドが呼ばれました");
    }
}

次に、このクラスを呼び出すメインクラスを作成します。

Java

public class MainApp {
    public static void main(String[] args) {
        try {
            // 1回目のアクセス：ここではExceptionInInitializerErrorが発生する
            ProblematicClass.doSomething();
        } catch (Throwable t) {
            System.out.println("1回目のアクセスで捕捉: " + t);
        }

        System.out.println("--- 2回目のアクセスを試みます ---");

        // 2回目のアクセス：ここでNoClassDefFoundErrorが発生する
        ProblematicClass.doSomething();
    }
}

実行結果

1回目のアクセスで捕捉: java.lang.ExceptionInInitializerError
--- 2回目のアクセスを試みます ---
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class ProblematicClass
	at MainApp.main(MainApp.java:13)

この実行結果から分かる通り、1回目のアクセスでは初期化失敗が通知されますが、2回目以降は「クラス定義が見つからない」というエラーに変化します。

実際の運用環境で、ログの欠落などにより2回目以降のスタックトレースしか見られない場合、原因の特定が非常に困難になります。

NoClassDefFoundErrorの解決策

エラーが発生した際、どのように調査し、解決すべきか。

ステップバイステップで解説します。

ステップ1：クラスパスとJARの確認

まずは、エラーメッセージに表示されているクラスが、実行環境のどこに含まれているべきかを確認します。

実行コマンドの -classpath または -cp 引数は正しいか。
JARファイルが破損していないか、あるいは容量が0バイトになっていないか。
環境変数 CLASSPATH が意図しない設定になっていないか。

ステップ2：ビルドツールの依存関係ツリーを調査

MavenやGradleを使用している場合は、依存関係の競合を疑います。

意図したバージョンとは異なるライブラリがロードされている可能性があります。

ShellMavenの場合

mvn dependency:tree -Dverbose -Dincludes=パッケージ名.*

ShellGradleの場合

./gradlew dependencies

これらのコマンドを実行し、エラー対象のクラスを含むライブラリが、不適切なバージョンで上書き（omit）されていないかを確認してください。

もし古いバージョンが優先されている場合は、<exclusion> タグを使用して不要な依存を排除します。

ステップ3：ログを遡って初期化エラーを探す

前述のコード例のように、静的初期化の失敗が原因である場合、直近のスタックトレースだけを見ても解決しません。

アプリケーションの起動時までログを遡り、ExceptionInInitializerError や java.lang.UnsatisfiedLinkError (ネイティブライブラリのロード失敗) が出力されていないかを確認してください。

ステップ4：JVMの起動オプションでロード状況を可視化

どのクラスが、どのJARファイルから、どのタイミングでロードされているかを把握するために、JVMの診断オプションを利用するのが有効です。

Shell

java -verbose:class -cp . MainApp

このオプションを付けて実行すると、JVMがロードしたすべてのクラスのソース（JARのパスなど）が標準出力に表示されます。

これにより、「本来ロードされるべき場所ではない場所からクラスを読み込もうとしている」あるいは「そもそもロードの試行すらされていない」といった事実を突き止めることができます。

モダンなJava開発における注意点

現代のJava開発では、コンテナ化（Docker）やマイクロサービス化が進んでおり、新たな発生パターンも見られます。

1. Dockerイメージのレイヤ構造

Dockerイメージを作成する際、ライブラリをコピーするステップで特定のJARファイルが漏れてしまうケースがあります。

マルチステージビルドを利用している場合、ビルドステージから実行ステージへのファイルコピーに漏れがないか確認が必要です。

2. モジュールシステム (Project Jigsaw)

Java 9以降で導入されたモジュールシステムを使用している場合、クラスパス（Classpath）ではなくモジュールパス（Modulepath）の概念が登場します。

あるモジュールが別のモジュールを requires していない場合、たとえ物理的にファイルが存在していても、JVMはアクセスを拒否し、結果として NoClassDefFoundError に似た実行時エラーを引き起こすことがあります。

3. フレームワーク特有のクラスロード

Spring Bootの実行可能JAR (Fat JAR) や、Tomcatなどのサーブレットコンテナは、独自のクラスローダー階層を持っています。

親クラスローダーがロードしたクラスからは、子クラスローダーのクラスを参照できないという制約（親優先の原則）があるため、ライブラリを配置するディレクトリ（/lib なのか WEB-INF/lib なのか）を誤るとエラーが発生します。

まとめ

java.lang.NoClassDefFoundError は、コンパイル環境と実行環境の乖離を示すシグナルです。

このエラーに遭遇した際は、闇雲にコードを修正するのではなく、まずは「なぜ実行時にクラスが見つからないのか」という環境面の問題として捉えることが解決への近道です。

本記事で解説した主なポイントを振り返ります。

ClassNotFoundExceptionとの違い: 動的なロード失敗（例外）か、コンパイル時にあったはずのクラスの消失（エラー）か。
静的初期化の罠: 1回目の初期化失敗が、2回目以降にこのエラーとして現れる。
調査手法: mvn dependency:tree や -verbose:class を活用し、物理的な存在と依存関係を可視化する。

Javaのクラスロード機構は複雑に思えるかもしれませんが、その原理原則を理解しておけば、どんなに大規模なシステムであっても必ず原因を突き止め、解決することができます。

本記事の内容を、安定したシステム運用のためのトラブルシューティングにぜひ役立ててください。