Javaのクラスパス(classpath)とは、JVMがクラスファイル(.class)やJarライブラリを探しにいく「場所のリスト」です。
今の値を確認するなら echo $CLASSPATH(Windowsは echo %CLASSPATH%)か、プログラム内の System.getProperty("java.class.path") を使います。
設定は java -cp オプションで指定するのが基本です。
仕組み・確認方法・設定方法(コマンドライン/IntelliJ・Eclipse・VSCode)に加えて、ClassNotFoundExceptionを切り分ける手順までコマンド付きでまとめました。
12年のJava開発経験をもとに、初心者がつまずきやすいポイントを重点的に取り上げています。
次のような疑問を持つJava初学者や、設定に自信がない中級者の方に向けた内容です。
Javaのクラスパスとは?JVMがクラスを探す場所

クラスパス(Classpath)とは、Javaのプログラム実行時に、必要なクラスファイル(.class)やライブラリ(.jar)を探すための道しるべ です。
Javaはソースコード(.java)をクラスファイル(.class)に変換します。
プログラムを実行すると、Java仮想マシン(JVM)が .class ファイルをメモリに読み込みます。
読み込むときにJVMが知っておく必要があるのが、「どのディレクトリやJarファイルを探せば、目的のクラスが見つかるのか」という情報です。
この「探す場所のリスト」こそが、クラスパスです。
JVMがクラスを探す順番
JVMはクラスを、次の3種類の場所から決められた順序で探索します。
- ブートストラップクラスパス: Javaの基本ライブラリ(Java 8以前の
rt.jarなど、Java実行環境の根幹をなすクラス群)が対象。通常、開発者が意識して設定する場所ではない - 拡張クラスパス: Javaの拡張機能が置かれる場所。(Java 9 でモジュールシステムが登場し、この仕組みは廃止)
- ユーザー定義クラスパス: 開発者が作成したクラスや、外部から持ってきたライブラリ(Jarファイル)を指定する場所。私たちが「クラスパスを設定する」と言う場合、通常はここを指す
JVMは、まずブートストラップ、次に拡張クラスパス(Java 8以前)、最後にユーザー定義クラスパスの順でクラスを探します。
目的のクラスが最初に見つかった時点で探索は終了し、見つかったクラスが使用されます。
Java 9以降はモジュールシステムの導入により、拡張クラスパスの仕組みは廃止されています。
クラスローダーの役割
実際にクラスパスをたどってクラスファイルを読み込む役割を担っているのが「クラスローダー(Class Loader)」です。
クラスローダーには階層構造(親子関係)があります。
Javaは「委譲モデル」を採用しています。クラスの読み込み要求があると、まず親のクラスローダーに処理を依頼します。
親が見つけられなければ、子クラスローダーが自分のクラスパスを探索して読み込みを試みる仕組みです。
クラスローダーがクラスを探す流れを図にすると、次のようになります。
クラスローダーは「まず親に任せる」(読み込むクラスを選んでください)
丸数字をタップすると、その段階で止めて確認できます。
環境変数CLASSPATHとは
クラスパスを設定する最も古い方法の一つに、OSの「環境変数 CLASSPATH」を利用する方法があります。
Windowsの「システムのプロパティ」や、Linux/Macの .bashrc などで CLASSPATH という名前の環境変数を設定します。
設定した値は、java コマンドを実行するたびに自動で読み込まれます。
設定例(Windows): C:\MyLib\library1.jar;C:\MyProject\classes
設定例(Linux/Mac): /home/user/lib/library1.jar:/home/user/project/classes
ただし、この方法はPC全体(あるいはユーザー全体)に影響を与えてしまいます。
プロジェクトごとにバージョンが異なる場合の管理が困難なため、2026年現在は推奨されません。
後述するコマンドラインでの指定や、IDE、ビルドツールの利用が一般的です。
クラスパスの確認方法(コマンド・プログラム)
クラスパスを設定したあとは、正しく設定されているか確認しましょう。
原因不明のエラーに直面したとき、まず「現在のクラスパスが何になっているか」を確認するだけで、問題の糸口が見つかることもよくあります。
環境変数CLASSPATHを確認する
OS上に設定した CLASSPATH 環境変数の内容は、以下のコマンドで確認できます。
Linux / Mac の場合:
Windows(コマンドプロンプト)の場合:
コマンドプロンプトで %CLASSPATH% という文字がそのまま表示されたら、環境変数 CLASSPATH は設定されていません(未設定の変数は展開されずに残ります。バッチファイルの中では空文字に展開され、「ECHO は <ON> です。」のような表示になります)。
現在推奨されている -cp オプションを使っている場合は、この出力が空でも問題ありません。
Javaプログラム内からクラスパスを確認する
実行中のプログラムに実際に渡されているクラスパスを確認したい場合は、System.getProperty() を使います。
-verbose:classでクラスのロード状況を確認する
「クラスパスは設定したはずなのに読み込まれない」というときは、-verbose:class オプションが役立ちます。
JVMがどのパスからどのクラスをロードしているかをリアルタイムで表示してくれます。
目的のクラスが期待したパスからロードされているか、あるいはまったく表示されないかで、クラスパスの設定ミスをピンポイントで特定できます。
クラスパスの設定方法(コマンドライン)
開発の基本として、コマンドラインでJavaのクラスパスを指定する方法を学びましょう。
環境変数 CLASSPATH よりも優先され、プロジェクトごとに設定を完結できます。
java実行時に-cpで指定する
java コマンド実行時に、-cp または -classpath オプションを使ってクラスパスを指定するのが最も確実な方法です。
どちらのオプションも機能はまったく同じです。
基本構文: java -cp [クラスパスの指定] [実行するメインクラス名]
例えば、カレントディレクトリ(.)にある Main.classを実行する場合は、カレントディレクトリ自体をクラスパスに含めます。
※-cp も環境変数 CLASSPATH も指定しない場合は、カレントディレクトリ(.)が既定のクラスパスになります。CLASSPATH を設定している場合は . は自動では含まれないため、明示的に指定するのが安全です
bin というディレクトリにコンパイル後の .class ファイルが置かれている場合は、次のように指定します。
※com.example.Main のようにパッケージ名を含めた完全修飾名で指定します
javacのコンパイル時に指定する
javac コマンドでもクラスパスの指定が必要になる場面があります。
自作クラスが外部ライブラリに依存している場合、コンパイル時にもそのライブラリの場所を教えてあげなければなりません。
-d オプションでコンパイル後の .class ファイルの出力先を指定できます。
コンパイル時と実行時のクラスパスは独立しているため、両方で同じライブラリを指定する必要がある点に注意してください。
複数のディレクトリを指定する
複数のディレクトリやJarファイルをクラスパスに含めたい場合は、OS固有の区切り文字で連結します。
例えば、./bin ディレクトリと、./lib ディレクトリの両方をクラスパスに設定したい場合は、次のように指定します。
Windowsの場合:
Linux / Macの場合:
※パスに空白が含まれる可能性がある場合は、全体をダブルクォーテーション " で囲むと安全です
Jarファイルをクラスパスに追加する
外部ライブラリ(Jarファイル)を利用する場合は、そのJarファイル自体をクラスパスに含めます。
例えば、./bin に自作のクラスがあり、./lib フォルダにある mysql-connector.jar を利用する場合です。
Windowsの場合:
Linux / Macの場合:
また、Java 6以降ではワイルドカード(*)が使えます。特定のディレクトリにあるすべてのJarファイルを一括で指定したい場合に便利です。
例(./lib 内のすべての .jar ファイルを指定):
注意点: ワイルドカード(*)は、そのディレクトリ直下のJarファイルのみを対象とします。サブディレクトリ内のJarファイルは含まれません。
java -jarで実行するときの注意点
java -jar app.jar で実行する場合、-cp オプションは無視される という重要な仕様があります。
Jarファイルの中にある META-INF/MANIFEST.MF に記述された Class-Path 属性だけが有効です。
もし MANIFEST.MF を編集したくない場合は、-jar を使わず直接メインクラスを指定する方法もあります。
IDEでのクラスパス設定方法(IntelliJ・Eclipse・VSCode)
現在のJava開発(Java 21/25 LTS環境)において、コマンドラインで直接クラスパスを管理することは稀です。
IntelliJ IDEAやEclipse、VSCodeといったIDE(統合開発環境)が、クラスパスの管理を大幅に簡素化してくれます。
IntelliJ IDEAでの設定
IntelliJ IDEAでは、クラスパスは主に依存関係として管理されます。
- プロジェクトを右クリックし、「Open Module Settings」(または
F4キー)を選択 - 左側のメニューから「Modules」を選び、中央のリストで対象のモジュールを選択
- 右側に表示されるタブから「Dependencies」タブを選択
- 「+」アイコンをクリックし、「JARs or directories...」を選択して、PC内のJarファイルやクラスファイルがあるディレクトリを指定。Maven/Gradleプロジェクトなら、この一覧にライブラリが自動で表示される
OKを押して設定を保存
IntelliJでは、GUIで指定した内容が .iml ファイルなどに保存され、実行やデバッグ時に自動でクラスパスが構成されます。
Eclipseでの設定(ビルドパス)
Eclipseでは、クラスパスは「ビルド・パス」と呼ばれます。
- プロジェクト・エクスプローラーで対象のプロジェクトを右クリック
- 「Build Path」 > 「Configure Build Path...」を選択
- 開かれたダイアログで「Libraries」タブを選択
- 右側のボタンを使う
- Add JARs...: プロジェクト内に既にあるJarファイルを追加
- Add External JARs...: プロジェクト外(PC内の任意の場所)にあるJarファイルを追加
- Add Library...: JRE System Library など、Eclipseが管理するライブラリを追加
- Add Class Folder...: クラスファイル(
.class)が含まれるフォルダを追加
- 追加後、「Apply and Close」で設定を保存
Eclipseでは、ビルドパスの設定内容は .classpath というファイルに記録されます。
VSCodeでの設定
VSCode (Visual Studio Code) でJava開発を行う場合、「Extension Pack for Java」のインストールが前提となります。
VSCodeでのクラスパス管理は、プロジェクトの種類によって異なります。
Maven/Gradleプロジェクトの場合
pom.xml (Maven) や build.gradle (Gradle) に依存関係を記述します。
VSCodeのJava拡張機能が pom.xml や build.gradle を認識し、必要なライブラリを自動でダウンロードし、クラスパスを構成します。
非Maven/Gradleプロジェクト(軽量プロジェクト)の場合
VSCodeはクラスパスの設定を .vscode/settings.json ファイルで管理できます。
設定例(.vscode/settings.json)
java.project.referencedLibrariesに、Jarファイルのパスや、ディレクトリ(ワイルドカード使用可)を指定します。
クラスパスが原因のエラーと解決方法
Java開発でクラスパスが正しく設定されていないと、コンパイルは成功しても、実行時に「クラスが見つからない」というエラーが発生します。
ClassNotFoundExceptionの原因と対処
ClassNotFoundException は、プログラム実行中に、動的にクラスをロードしようとしたが見つからなかった場合に発生する例外(チェック例外)です。
発生する主な場面
Class.forName("com.example.Hoge")のように、リフレクションを使ってクラス名を文字列で指定してロードしようとした時- JDBCドライバのロード時(例:
Class.forName("com.mysql.cj.jdbc.Driver"))
原因
- クラスパスが通っていない: 必要なJarファイル(例:MySQLのJDBCドライバのJar)が、実行時のクラスパス(
-cpやIDEの設定)に含まれていない - クラス名のタイプミス:
Class.forName()に渡すクラス名(完全修飾名)が間違っている
対処法
- 実行時のクラスパス設定を再確認し、必要なJarファイルやクラスの出力先ディレクトリが正しく含まれているか確認する
- IDEを使っている場合は、プロジェクトの依存関係(ビルドパス)の設定を見直す
- クラス名が正しいか(パッケージ名、大文字小文字)をしっかり確認する
実務では、以下の3ステップで原因を特定するのが最速です。
- エラーメッセージに表示されたクラス名(完全修飾名)をコピーする
for j in lib/*.jar; do jar tf "$j" | grep -q "クラス名" && echo "$j"; doneのように1つずつ確認し、どのJarにそのクラスが含まれるかを調べる(jar tf *.jarと書くと、Jarが複数あるときは2つ目以降がファイル名として扱われ、正しく調べられない)-verbose:classオプションで実行し、そのJarが実際にロードされているか確認する
この手順を踏めば、「Jarが足りないのか」「Jarはあるのにパスが通っていないのか」を短時間で切り分けられます。
NoClassDefFoundErrorの原因と対処
NoClassDefFoundError は、コンパイル時には確かに存在していたクラスが、実行時に見つからなかった場合に発生するエラーです。
ClassNotFoundException と似ていますが、原因がクラスパスの設定漏れだけとは限らず、クラスの初期化失敗まで疑う必要があります。
典型例は、JVMがクラスAを読み込むときに、Aが依存するクラスBの定義が見つからないケースです。
原因
- 実行時のみに存在する依存関係の欠如: コンパイル時はクラスBが存在したが、実行時のクラスパスにはクラスB(またはそれを含むJar)が含まれていなかった。
- 静的初期化子でのエラー: クラスBの静的初期化ブロック(
static { ... })で例外が発生し、クラスBのロードに失敗した。JVMは初期化に失敗したクラスの初期化をやり直さない。そのため、次にクラスAがクラスBを使おうとした瞬間にNoClassDefFoundErrorが発生する。
解決アプローチ
ClassNotFoundExceptionと同様に、実行時のクラスパス設定を徹底的に見直します。- エラーメッセージに「caused by(原因)」として別の例外(例:
ExceptionInInitializerError)が表示されていないか確認する。もし表示されていれば、そちらが根本原因。 - 依存しているライブラリが、さらに別のライブラリに依存している場合がある。その「孫」ライブラリが不足していないか確認する。
よくあるパス設定ミス
初歩的なミスですが、最も多い原因の一つです。
- 区切り文字の間違い: Windowsはセミコロン(
;)、Linux/Macはコロン(:)です。開発環境(Mac)と本番環境(Windowsサーバー)が異なるときに、区切り文字を直さずにスクリプトを流用するとエラーになる - 相対パスの基点ミス:
java -cp ../lib/hoge.jar Mainのような相対パスの基点は、javaコマンドを実行したカレントディレクトリです。実行する場所が変われば、同じ相対パスでも指す先が変わります。スクリプトから実行する場合は、スクリプトの場所を基準に絶対パスへ変換するか、実行ディレクトリを固定する - タイプミス: 単純なスペルミス(lib を libs と書くなど)もエラーの原因
特にCI/CD環境(JenkinsやGitHub Actions)では、ビルドのワーキングディレクトリがローカルと異なるため、相対パスが原因のClassNotFoundExceptionが起きやすくなります。
CI環境では絶対パスか、ビルドツール(Maven/Gradle)に依存解決を任せるのが確実です。
クラスパスとモジュールパスの違い(Java 9以降)
Java 9 からJigsawプロジェクトの一環でモジュールシステムが導入され、「モジュールパス」という概念が登場しました。
クラスパスとモジュールパスの比較
どちらを使うべきか
モジュールパスを使うべきケース
- Java 9以降の環境(現在のLTS: Java 21/25)で、新規に大規模なアプリケーションを開発する場合
- 厳密なカプセル化や、信頼性の高い依存関係の管理が求められる場合
- 将来的にJLink(必要なモジュールだけを組み込んだカスタムJREを作成するツール)を使いたい場合
使わない方がいいケース(クラスパスを使い続けるケース)
- 既存のJava 8以前のプロジェクトを保守する場合
- 使用するライブラリの多くが、まだモジュールシステムに対応していない(
module-info.javaを持たない)場合 - 小規模なアプリケーションや、学習目的の場合
2026年現在、多くのライブラリはクラスパス方式(名前なしモジュールとして動作)でも利用可能なため、無理にモジュール化する必要はありません。
しかし、Javaの今後の方向性として、モジュールシステムの存在は知っておくべきです。
クラスパス管理のベストプラクティス
クラスパスの手動管理は、ミスが多く非効率です。特にプロジェクトが大きくなるにつれて、依存するJarファイルは数十、数百に達することもあります。
書くのは1つ、クラスパスに並ぶのは全部(Mavenの例)
Jarのファイル名は簡略表記です。区切り文字はLinux/Macの「:」で表示しています(Windowsは「;」)。
Maven/Gradleに管理を任せる
現代のJava開発では、Maven や Gradle といった「ビルドツール(依存関係管理ツール)」を使うのが一般的です。
MavenとGradleは、クラスパス管理の次の4つの手間をまとめて引き受けてくれます。
- 依存関係の宣言: pom.xml (Maven) や build.gradle (Gradle) という設定ファイルに、「どのライブラリ(例: MySQL Connector)の、どのバージョン(例: 8.0.30)が必要か」を記述する
- ライブラリの自動ダウンロード: ビルドツールが、インターネット上のリポジトリ(Maven Centralなど)から、必要なJarファイルを自動でダウンロードしてくれる
- 推移的依存の解決: MySQL Connectorが、さらに別のライブラリ(例: Protobuf)を必要とする場合(推移的依存)、それも自動でダウンロードしてくれる
- クラスパスの自動設定: コンパイル時や実行時に、ダウンロードしたすべてのJarファイルを含む、適切なクラスパスを自動で設定して java コマンドを実行してくれる
開発者は、pom.xml を書くだけで、-cp オプションの長い呪文から解放されます。
MavenとGradleのどちらを選ぶべきか迷う場合や、Gradleの基本コマンドを押さえたい場合は以下も参考にしてください。
標準のプロジェクト構成に従う
ビルドツールを使う場合でも、標準的なプロジェクト構成に従うことがトラブル回避の鍵です。
- Mavenの標準ディレクトリ構成:
src/main/java: 自作のJavaソースコード(.java)src/main/resources: 設定ファイルなど(クラスパスのルートにコピーされる)src/test/java: テストコードsrc/test/resources: テスト用設定ファイルtarget/classes: コンパイルされた.classファイル(自動生成。Mavenの場合。Gradleではbuild/classes/java/main)
この構成に従うだけで、IDEやビルドツールは「どこにソースコードがあり、どこにクラスファイルが出力されるか」を自動で認識し、クラスパスを適切に設定してくれます。
大規模開発での依存管理
大規模なシステムでは、システム全体を機能ごとに複数の「モジュール(プロジェクト)」に分割します。
例えば、「Web層」「ビジネスロジック層」「データアクセス層」のように分けます。
この場合、Web層はビジネスロジック層に依存し、ビジネスロジック層はデータアクセス層に依存します。
MavenやGradleは、このようなモジュール間の依存関係も管理できます。
Web層のクラスパスには、ビジネスロジック層のJar(または classes)と、データアクセス層のJarが自動で含まれるように設定できます。
これにより、各モジュールは必要な依存関係だけを持つことができ、クラスパスが不必要に肥大化するのを防ぎます。
Java歴12年の実務経験から言えるのは、「クラスパスを手動で管理する場面は年々減っている」ということです。
Maven/Gradleが普及した現在、クラスパスの仕組みを深く理解すべきタイミングは主に3つです。
- ClassNotFoundExceptionのデバッグ時
- レガシーシステムの保守時
- カスタムクラスローダーを書くとき
それ以外の場面では、ビルドツールに任せるのがおすすめです。
クラスローダーやモジュールシステムの内部設計をより体系的に押さえておきたい方には、以下の書籍が参考になります。
モジュール設計やAPI境界の考え方は、クラスパス・モジュールパスの理解にもつながります。
よくある質問
Q1. クラスパスとは何ですか?
A1. クラスパスとは、Javaが実行時やコンパイル時に「.classファイルやJarファイルをどこから探すか」を指定するパスのことです。JVMはクラスパスに指定された場所を順に探索して必要なクラスを読み込みます。
Q2. クラスパスの確認方法は?
A2. 環境変数は echo $CLASSPATH(Windowsは echo %CLASSPATH%)で確認できます。実行中のプログラムに渡された値は System.getProperty("java.class.path") で出力します。
どのJarからクラスが読み込まれたかまで見たい場合は、-verbose:class を付けて実行します。IDE(IntelliJ IDEA・Eclipse・VSCode)では、プロジェクト設定画面の依存関係・ビルドパスで確認できます。
Q3. ClassNotFoundExceptionが出たらどうすればいい?
A3. 対象のクラスファイルやJarファイルがクラスパスに含まれているか確認します。パッケージ名を含めた完全修飾名で指定しているか、Jarファイルのパスが正しいかを見直すのが第一歩です。
Q4. クラスパス方式とモジュールパス方式はどちらを使うべき?
A4. Java 9以降のモジュールシステムを積極活用する新規プロジェクトはモジュールパス、既存資産の多いプロジェクトや依存関係がシンプルな場合はクラスパス方式が現実的です。多くの現場ではまだクラスパス方式が主流です。
Q5. Maven/Gradleを使えばクラスパスを意識しなくていい?
A5. 依存関係の解決や自動的なクラスパス構築は任せられますが、仕組みそのものを理解しておくと、ビルドエラーやIDEの警告に遭遇したときの原因究明が格段に速くなります。
まとめ
クラスパスは、JVMがクラスやJarを探しにいく場所のリストです。確認・設定・エラー対応の要点は次の3つです。
- 確認方法: 環境変数は
echo $CLASSPATH(Windowsはecho %CLASSPATH%)、実行中の値はSystem.getProperty("java.class.path") - 設定方法: コマンドラインは
java -cp、IDEは依存関係・ビルドパスの設定画面、実務ではMaven/Gradleに任せる - エラー時:
jar tfでクラスの所在を確かめ、-verbose:classで実際に読み込まれているかを確認する
クラスパスを理解するとエラー対応が速くなる
ClassNotFoundException や NoClassDefFoundError は、Java初学者が特に時間を取られやすいエラーです。
クラスパスの仕組みを知っていれば、こうしたエラーにも落ち着いて対処できます。
「なぜこのJarが必要なのか」「IDEは裏で何をしているのか」が分かれば、エラーメッセージを見た瞬間に、原因が「設定ミス」なのか「ライブラリ不足」なのか、あるいは「バージョンの競合」なのか、あたりをつけられます。
この「あたりをつける」スピードが、開発効率に直結します。
| REV. | DATE | 内容 |
|---|---|---|
| 4 | 2026-10-04 | 記載内容の事実確認と修正 |
| 3 | 2026-09-04 | 2026年9月時点の情報で全体を見直し |
| 2 | 2026-05-18 | 2026年5月時点の情報で全体を見直し |
| 1 | 2025-11-16 | 初版 |





