NoSuchMethodErrorの原因と直し方｜Javaのライブラリ競合

java.lang.NoSuchMethodError は、コンパイルしたときには存在したメソッドが、実行時に読み込まれたクラスには存在しなかったときのエラーです。 ほとんどの場合、同じライブラリの別の版が実行時に使われている（ライブラリの版の競合）のが原因です。

確認環境：Java 21、Apache Maven 3.9.11、Gradle 8.14.3（確認日 2026年10月11日）。メソッドを1つ追加した自作ライブラリの 1.0 と 2.0 を作って再現しました。

再現：コンパイルは通るのに、実行で落ちる

アプリの pom.xml は、textlib 1.0 と reportlib 1.0 に依存しています。

<dependencies>
  <dependency><groupId>com.example</groupId><artifactId>textlib</artifactId><version>1.0</version></dependency>
  <dependency><groupId>com.example</groupId><artifactId>reportlib</artifactId><version>1.0</version></dependency>
</dependencies>

$ mvn compile        → 成功
$ java -cp ... com.example.app.Main
[見出し       ]
Exception in thread "main" java.lang.NoSuchMethodError: 'java.lang.String com.example.text.TextUtil.pad(java.lang.String, int)'
    at com.example.report.Report.line(Report.java:4)
    at com.example.app.Main.main(Main.java:7)

reportlib は textlib 2.0 でコンパイルされているのに、実行時には textlib 1.0 が使われたため、pad(String, int) が見つかりませんでした。 コンパイルは自分のコードだけを見るので通り、実行して初めて分かります。

エラー文の読み方

原因を探す1：dependency:tree

$ mvn dependency:tree -Dverbose
com.example:app:jar:1.0
+- com.example:textlib:jar:1.0:compile
\- com.example:reportlib:jar:1.0:compile
   \- (com.example:textlib:jar:2.0:compile - omitted for conflict with 1.0)

omitted for conflict with 1.0 が、競合の印です。reportlib は textlib 2.0 を求めていますが、1.0 と競合したため 2.0 は使われませんでした。

ライブラリが多いときは、エラー文のクラスが入っているライブラリで絞り込みます。

mvn dependency:tree -Dverbose -Dincludes=com.example:textlib

Maven は「最も近い定義」を使う

Maven は、同じライブラリの複数の版があると、依存の木の中で、自分のプロジェクトに最も近い定義を使います（Apache Maven 公式ドキュメント）。版の新しさでは選びません。

Gradle で同じ依存を書くと、結果は逆でした。Gradle は競合したとき、新しいほうの版を選びます。

$ gradle dependencies --configuration runtimeClasspath
+--- com.example:textlib:1.0 -> 2.0          ← 1.0 を指定したが、2.0 が使われた
\--- com.example:reportlib:1.0
     \--- com.example:textlib:2.0

Gradle では実行も成功しました。同じ依存関係でも、Maven では落ち、Gradle では動くことがあります。

原因を探す2：どの jar から読まれたか

ビルドツールの外（アプリケーションサーバー・lib フォルダー・fat jar）で起きている場合は、実行時に実際に読み込まれた jar を確かめます。

java -verbose:class -cp ... com.example.app.Main | grep com.example.text

[0.042s][info][class,load] com.example.text.TextUtil source: file:/.../textlib/2.0/textlib-2.0.jar

コードの中で確かめるなら、次の1行です。

System.out.println(TextUtil.class.getProtectionDomain().getCodeSource().getLocation());
// file:/.../textlib/2.0/textlib-2.0.jar

同じ jar が2つあると、先にあるほうが使われる

同じクラスが複数の jar にあると、クラスパスの先にあるほうが使われました。 lib フォルダーに以前の版の jar が残っていると、置き方の順番しだいで落ちたり動いたりします。以前の版の jar を消します。

直し方

1. 自分の pom.xml の版を上げる（または直接の指定を消す）

<dependency><groupId>com.example</groupId><artifactId>textlib</artifactId><version>2.0</version></dependency>

+- com.example:textlib:jar:2.0:compile
\- com.example:reportlib:jar:1.0:compile
   \- (com.example:textlib:jar:2.0:compile - omitted for duplicate)
...
[見出し       ]
佐藤      300                      ← 実行できた

自分のコードで textlib を直接使っていないなら、直接の指定を消して、reportlib が求める版に任せる方法もあります。

2. dependencyManagement で版をそろえる

複数のモジュールやライブラリが同じものに依存するなら、dependencyManagement で版を1か所で決めます。間接的な依存（推移的な依存）の版にも効きます（Apache Maven 公式ドキュメント）。

<dependencyManagement>
  <dependencies>
    <dependency><groupId>com.example</groupId><artifactId>textlib</artifactId><version>2.0</version></dependency>
  </dependencies>
</dependencyManagement>
<dependencies>
  <dependency><groupId>com.example</groupId><artifactId>textlib</artifactId></dependency>   <!-- 版は書かない -->
  <dependency><groupId>com.example</groupId><artifactId>reportlib</artifactId><version>1.0</version></dependency>
</dependencies>

+- com.example:textlib:jar:2.0:compile
\- com.example:reportlib:jar:1.0:compile
   \- (com.example:textlib:jar:2.0:compile - version managed from 2.0; omitted for duplicate)

Spring Boot を使っている場合は、Spring Boot が多くのライブラリの版を dependencyManagement（BOM）で管理しています。Spring Boot が管理しているライブラリに、自分で版を書くと競合の原因になることがあるため、版を書く前に dependency:tree で確かめます。

3. 実行環境の jar を確かめる

似たエラーとの違い

確認の手順（チェックリスト）

よくある質問

Q. clean してビルドし直したら直ることがあります。なぜですか。 A. 以前のビルドの成果物（以前の版でコンパイルしたクラスや、コピーされた jar）が残っていると起きることがあります。clean で消えると、依存関係どおりの版でビルドし直されます。それでも出るなら、dependency:tree で競合を確かめます。

Q. Gradle では、どう調べますか。 A. gradle dependencies --configuration runtimeClasspath で依存の木を表示します。1.0 -> 2.0 のように矢印があれば、別の版に置き換えられています。特定のライブラリを調べるなら gradle dependencyInsight --dependency textlib です。

まとめ

• コンパイル時にあったメソッドが、実行時のクラスに無い。原因はほぼライブラリの版の競合
• mvn dependency:tree -Dverbose の omitted for conflict で競合を見つける
• Maven は「最も近い定義」を使う。直接書いた以前の版が優先される。Gradle は新しい版を選んだ
• 実際に読まれた jar は -verbose:class で確かめる。同じ jar が2つあると、先にあるほうが使われる
• 直し方は版を上げる・直接の指定を消す・dependencyManagement でそろえる

参考・出典

確認日はいずれも 2026年10月11日です。

• Apache Maven「Introduction to the Dependency Mechanism」：https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。