java.lang.ClassNotFoundExceptionの原因と解決法｜NoClassDefFoundErrorとの違いも解説

2026年3月11日

例外処理・デバッグ

Javaアプリケーションを開発・運用する中で、多くのエンジニアが一度は遭遇するのが java.lang.ClassNotFoundException です。

この例外は、プログラムが実行時に特定のクラスをロードしようとした際、指定された名前のクラスファイルが見つからない場合にスローされます。

一見単純なエラーに思えますが、ビルド環境や実行環境、クラスパスの設定、さらにはクラスローダーの仕組みが複雑に絡み合っている場合、原因の特定に時間を要することも少なくありません。

本記事では、ClassNotFoundExceptionの根本的な原因から具体的な解決策、さらには混同されやすいNoClassDefFoundErrorとの違いまでを専門的な視点で詳しく解説します。

目次 [ close ]

java.lang.ClassNotFoundExceptionとは何か

Javaの例外クラスの階層において、java.lang.ClassNotFoundException は java.lang.ReflectiveOperationException を継承した検査例外（Checked Exception）です。

これは、開発者がプログラム内で明示的に try-catch ブロックによる例外処理を記述するか、メソッドの throws 節で宣言する必要があることを意味します。

この例外は、主に以下のメソッドを使用して、クラス名を文字列（String）として指定し、動的にクラスをロードしようとした際に発生します。

Class.forName(String className)
ClassLoader.loadClass(String name)
ClassLoader.findSystemClass(String name)

Javaの実行環境（JRE）は、プログラムの実行中に必要に応じてクラスをメモリ上にロードします。

この「動的ロード」のプロセスにおいて、指定された完全修飾名（パッケージ名を含むクラス名）に合致する .class ファイルがクラスパス上に見つからない場合、JVMは「このクラスをどうやってロードすればよいかわからない」という状態になり、この例外をスローします。

ClassNotFoundExceptionが発生する主な原因

この例外が発生する理由は多岐にわたりますが、多くは構成ミスや環境の不整合に起因します。

代表的な原因を整理して解説します。

1. クラス名の記述ミス（タイポ）

最も基本的かつ頻繁に見られる原因です。

Class.forName("com.example.MyService") のように文字列でクラスを指定する場合、コンパイラはクラスの存在を確認できません。

そのため、大文字・小文字の打ち間違いやパッケージ名の不足があっても実行時までエラーが表面化しません。

2. 依存ライブラリ（JARファイル）の不足

外部ライブラリ（JDBCドライバやサードパーティ製フレームワークなど）を使用している場合、そのライブラリが含まれる .jar ファイルが実行時のクラスパスに含まれていないと、この例外が発生します。

特にビルドツール（MavenやGradle）を使用している環境で、スコープ設定を誤ったり、デプロイパッケージにライブラリを含め忘れたりした場合に発生しやすくなります。

3. クラスパス（Classpath）の設定不備

Java実行時のコマンドライン引数 -classpath（または -cp）や、環境変数 CLASSPATH の設定が正しくないケースです。

カレントディレクトリが含まれていない、あるいはライブラリのパスが絶対パスで正しく記述されていない場合、JVMはクラスファイルを探し出すことができません。

4. クラスローダーの階層構造による問題

Javaには親クラスローダーがロードしたクラスを子クラスローダーが参照できるという階層構造があります。

しかし、子クラスローダーがロードしたクラスを親クラスローダーが直接参照することはできません。

アプリケーションサーバー（TomcatやWildFlyなど）上で動作する複雑なシステムでは、共有ライブラリとアプリケーション固有のライブラリの配置場所によって、この可視性の問題が発生し、特定のクラスが見つからない状況に陥ることがあります。

ClassNotFoundExceptionとNoClassDefFoundErrorの違い

Java初学者が最も混乱しやすいポイントの一つが、java.lang.ClassNotFoundException と java.lang.NoClassDefFoundError の違いです。

名称は似ていますが、発生するタイミングや意味合いが大きく異なります。

根本的な違いの比較表

項目	ClassNotFoundException	NoClassDefFoundError
型	検査例外（Exception）	エラー（Error）
発生のきっかけ	明示的な動的ロード（`Class.forName`等）	通常のインスタンス化やメソッド呼び出し
発生タイミング	文字列による指定時（実行時）	コンパイル時は存在したが、実行時に見つからない
原因の主眼	指定されたクラス名自体が存在しない	クラス定義の読み込みに失敗した（依存関係の破綻）

ClassNotFoundExceptionの詳細

こちらは「動的な検索失敗」です。

プログラムが「”A” という名前のクラスを今すぐ探して持ってきてください」と要求し、それに応えられなかった場合に発生します。

多くの場合、プログラムのロジックや設定ファイルの記述ミスが原因です。

NoClassDefFoundErrorの詳細

こちらは「実行時の定義喪失」です。

コンパイル時にはクラスパス上にそのクラスが存在し、コードとして正常にコンパイルできたにもかかわらず、実行時にそのクラスをロードしようとしたら見つからなかった、あるいはロード中にエラーが発生したという状況を示します。

例えば、クラスAがクラスBに依存している場合、クラスAをコンパイルする際にはクラスBが必要です。

しかし、実行時にクラスBを含むJARファイルを除去してクラスAを実行しようとすると、JVMはクラスBの定義を見つけられず、このエラーをスローします。

具体的なコード例と解決策

ここでは、実際に ClassNotFoundException が発生するコードの例と、それをどのように修正・回避すべきかについて解説します。

例外が発生するシナリオ

以下のプログラムは、JDBCドライバを動的にロードしようとして失敗する典型的な例です。

Java

public class DatabaseLoader {
    public static void main(String[] args) {
        try {
            // 存在しない、またはパスが通っていないJDBCドライバをロードしようとする
            // 本来は "com.mysql.cj.jdbc.Driver" などが正しい
            Class.forName("com.mysql.jdbc.DriverMissing");
            System.out.println("ドライバのロードに成功しました。");
        } catch (ClassNotFoundException e) {
            // 例外のスタックトレースを出力
            System.err.println("エラー: クラスが見つかりませんでした。");
            e.printStackTrace();
        }
    }
}

実行結果

エラー: クラスが見つかりませんでした。
java.lang.ClassNotFoundException: com.mysql.jdbc.DriverMissing
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
    at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
    at java.base/java.lang.Class.forName0(Native Method)
    at java.base/java.lang.Class.forName(Class.forName.java:375)
    at DatabaseLoader.main(DatabaseLoader.java:7)

解決のためのステップ

この問題を解決するためには、以下の手順でデバッグを行います。

ステップ1：クラス名の完全修飾名を確認する

まず、Class.forName() に渡している文字列が、パッケージ名を含めて完全に正しいかを確認します。

IDE（IntelliJ IDEAやEclipse）の検索機能（Ctrl+N など）を使用して、プロジェクト内にそのクラスが存在するかどうかを確認するのが確実です。

ステップ2：クラスパスの確認と修正

コマンドラインから実行している場合、-cp オプションで必要なJARファイルやディレクトリが含まれているか確認します。

Shell

# Windowsの場合の例（セミコロン区切り）
java -cp ".;lib/mysql-connector-java.jar" DatabaseLoader

# Linux/macOSの場合の例（コロン区切り）
java -cp ".:lib/mysql-connector-java.jar" DatabaseLoader

ステップ3：ビルドツールの設定を見直す

Mavenを使用している場合は、pom.xml の <dependency> セクションを確認します。

特に <scope> が provided になっている場合、実行環境のサーバー側でそのライブラリが提供されている必要があります。

もし提供されていない環境で動かそうとしているなら、compile スコープに変更するか、依存関係を含めた「Fat JAR（Uber JAR）」を作成する必要があります。

XML

<!-- Mavenの依存関係例 -->
<dependency>
    <groupId>com.mysql</groupId>
    <artifactId>mysql-connector-j</artifactId>
    <version>8.0.33</version>
    <scope>runtime</scope> <!-- 実行時に必要 -->
</dependency>

高度なトラブルシューティング：クラスローダーの挙動を追う

単純な設定ミスではない場合、JVMがどのパスからクラスをロードしようとしているかを詳細に調査する必要があります。

-verbose:class オプションの活用

JVMの起動オプションに -verbose:class を追加すると、JVMがどのクラスをどの場所（JARファイルなど）からロードしたかを標準出力に表示します。

Shell

java -verbose:class MyMainClass

これにより、意図しない古いバージョンのライブラリが先にロードされていないか、あるいはロードが試行されている形跡があるかを確認できます。

実行時のクラスパスをプログラム内で出力する

問題が発生している環境で、実際に認識されているクラスパスを書き出して確認することも有効です。

Java

public class ClassPathChecker {
    public static void main(String[] args) {
        String classPath = System.getProperty("java.class.path");
        String[] paths = classPath.split(System.getProperty("path.separator"));
        
        System.out.println("現在のクラスパス一覧:");
        for (String path : paths) {
            System.out.println(path);
        }
    }
}

この出力結果をチェックし、期待しているJARファイルが含まれているか、またそのパスが物理的に存在するかを一つずつ検証してください。

java.lang.ClassNotFoundExceptionを防ぐためのベストプラクティス

トラブルを未然に防ぐためには、設計段階からのアプローチが重要です。

1. 文字列によるクラス指定を避ける

可能な限り、Class.forName("...") による動的ロードではなく、型安全な参照を使用してください。

リフレクションが必要な場合でも、インターフェースを定義し、ServiceLoader などの標準的なサービスプロバイダメカニズムを利用することで、コンパイル時のチェックの恩恵を受けやすくなります。

2. ビルドツールの依存関係管理を徹底する

ライブラリのバージョン競合（いわゆるJAR地獄）を避けるため、MavenやGradleの依存関係ツリーを定期的に確認しましょう。

mvn dependency:tree や gradle dependencies コマンドを実行することで、どのライブラリがどのバージョンをバイパスしているかを可視化できます。

3. デプロイメントパイプラインでの検証

CI/CD（継続的インテグレーション/継続的デプロイ）のプロセスにおいて、実行環境と同じ構成のコンテナやステージング環境で自動テストを実行します。

これにより、開発者のローカル環境では通るが本番環境ではライブラリが足りない、といった事態を早期に発見できます。

4. モジュールシステムの活用（Java 9以降）

Java 9で導入された Project Jigsaw（モジュールシステム） を活用すると、モジュール間の依存関係を module-info.java で厳密に定義できます。

これにより、必要なモジュールが欠落している場合は実行前（あるいは起動直後）にエラーとして検知できるため、実行途中で突如 ClassNotFoundException が発生するリスクを低減できます。

まとめ

java.lang.ClassNotFoundException は、Java開発において避けては通れない例外の一つですが、その本質は「JVMが実行時に指定された名前のクラスを見つけられなかった」というシンプルなメッセージです。

解決のためには、以下の3点を中心に確認を行うことが近道となります。

完全修飾名にタイポがないか（特に動的なロードを行っている箇所）。
クラスパスに必要なJARファイルやディレクトリが含まれているか。
NoClassDefFoundErrorとの混同がないか（コンパイル時と実行時の環境の差異を確認）。

現代のJava開発ではビルドツールやIDEが多くの部分をカバーしてくれますが、最終的にプログラムを動かすのはJVMです。

クラスロードの仕組みを正しく理解し、適切なパス設定と依存関係管理を行うことで、この例外に惑わされることなく、堅牢なアプリケーションを構築できるようになります。

エラーが発生した際は、焦らずスタックトレースを読み解き、JVMの視点で「どこを探しているのか」を問い直してみてください。