序章：依存関係の「闇」を断つ —— なぜあなたのJavaビルドは遅いのか
エンタープライズJavaアプリケーションの寿命が長くなるにつれ、プロジェクトの根幹を蝕む「静かなる癌」がある。それが 推移的依存関係（Transitive Dependencies）の肥大化と、それに伴う「隠れた依存関係（Unused Declared Dependencies）」 だ。
「とりあえず動くから」と `pom.xml` や `build.gradle` に追加されたライブラリ、あるいはフレームワーク（Spring Boot等）が自動的に引き込んだ巨大なサードパーティ製ライブラリの群れ。これらはコンパイル時のクラスパスを無駄に汚染し、Javacのシンボル解決フェーズにおけるメモリスラッシングを引き起こし、最終的なFat JAR/WARのバイナリサイズを数百メガバイトへと膨れ上がらせる。
さらに深刻なのは、Dockerコンテナへのパッケージング、K8sクラスターへのデプロイ、そしてCI/CDパイプラインにおけるネットワーク転送コストへの悪影響だ。数MBのコードに対して数百MBの依存関係を毎回ビルド・転送するのは、エンジニアリングの怠慢に他ならない。
本稿では、Mavenの `dependency:analyze` および Gradleの `Dependency Insight` を極限まで使い倒し、さらにこれをCI/CDパイプラインとDocker環境に完全に組み込んで「未使用依存関係の侵入を物理的にブロックする」ための実践的アーキテクチャを解説する。
—
1. 内部メカニズムの解剖：なぜビルドツールは未使用ライブラリを検知できるのか
ツールを使いこなすには、その内部で何が起きているかを知る必要がある。
Mavenの `dependency:analyze` や Gradleのプラグインが「未使用」を判定するアルゴリズムは、単なるテキストマッチングではない。彼らは以下の2つのレイヤを突合している。
1. 宣言された依存関係（Declared Dependencies）: `pom.xml` や `build.gradle` に記述され、リポジトリからダウンロードされたJAR/AARのリスト。
2. 実際に使用されている依存関係（Used Dependencies）: ソースコードのコンパイル結果（`.class` ファイル）に含まれる Constant Pool や Bytecode（`INVOKEVIRTUAL`, `CHECKCAST` 等）が、どの外部クラスを参照しているか（Bytecode Analysis）。
コンパイル後のバイトコードをASM等のバイトコード操作ライブラリを用いて解析し、「宣言されているが、バイトコード上から一度も参照されていないパッケージ・クラス」を抽出する。これが「隠れた依存関係」の正体である。
—
2. Maven環境における徹底解析と自動排除
`dependency:analyze` の限界と正しい活用
Maven標準の `maven-dependency-plugin` には `dependency:analyze` ゴールが存在する。しかし、デフォルトのまま実行すると、Spring BootやLombokなどのアノテーションプロセッサ、動的ロード（SPI機構）を行うライブラリを誤検知（False Positive）してしまう。
これを回避するため、CI/CDで実用に耐えうる厳格な設定を `pom.xml` にマウントする。
実行コマンドと出力の読み方
mvn clean verify
実行が失敗した場合、以下のようなログが出力される。
[WARNING] Used undeclared dependencies found:
[WARNING] com.google.guava:guava:32.1.3-jre
[WARNING] Unused declared dependencies found:
[WARNING] commons-io:commons-io:2.11.0
- Used undeclared dependencies: 「推移的依存関係として偶然入ってきたが、コード内で直接使っているため、明示的に `pom.xml` に書くべきもの」。これを放置すると、将来親依存関係がバージョンアップでそれを削除した瞬間にビルドが破壊される（Fragile Build）。
- Unused declared dependencies: 「`pom.xml` に書いたが、コードから一度も呼ばれていないもの」。これこそが今回のターゲットであり、即座に削除すべき肥大化の原因である。
—
3. Gradle環境における高度な依存関係監査
GradleにはMavenのような単一のプラグインだけでなく、より高度なエコシステムが存在する。特に `com.autonomousapps.dependency-analysis` プラグインは、JVMエコシステムにおける依存関係分析の最高峰である。
プラグインの導入と厳格な設定
`build.gradle.kts`（Kotlin DSL）を使用し、プロジェクト全体のエントリポイントに依存関係分析プラグインを適用する。
plugins {
java
// 依存関係分析の業界標準プラグイン
id(“com.autonomousapps.dependency-analysis”) version “1.31.0”
}
dependencyAnalysis {
issues {
all {
// 未使用の依存関係を検出した場合にビルドを失敗させる（エラーレベルへ昇格）
onUnusedDependencies {
severity(“error”)
}
// 宣言されていないが使用されている依存関係を検出
onDeclaredUnusedDependencies {
severity(“error”)
}
// 間違ったスコープ（implementationにすべきものをapiにしている等）の検出
onIncorrectConfiguration {
severity(“warn”)
}
}
}
}
実行コマンド
./gradlew buildHealth
このコマンドを実行すると、プロジェクト全体の依存関係の健全性がスコア化され、問題のあるモジュールやライブラリがJSONおよびコンソール出力で丸裸にされる。
> Task :buildHealth
Aŋalysis complete. 1 issue found.
Unused dependencies:
- commons-io:commons-io:2.11.0 (project ‘:app’)
Advice:
In project ‘:app’, remove the following dependencies:
implementation(“commons-io:commons-io:2.11.0”)
—
4. 成果の定量化：ビルド時間と配布サイズの削減効果を計測する
「本当にライブラリを削る意味があるのか？」という経営層やチームメンバーからの疑問に対し、エンジニアは数値で証明しなければならない。ここでは、最適化前後のメトリクスを計測するシェルスクリプトの断片を示す。
1. 配布サイズ（Fat JAR）の比較測定
最適化前のサイズを記録
du -sh build/libs/app-all.jar > before_size.txt
最適化後のサイズを記録
du -sh build/libs/app-all.jar > after_size.txt
差分を計算して表示
echo “— Fat JAR Size Optimization Result —”
diff before_size.txt after_size.txt
実測値の例：ある中規模マイクロサービスにおいて、未使用のAWS SDKモジュール群とApache Commonsのレガシーユーティリティを削除したところ、Fat JARのサイズが 84MBから31MBへと約63%削減された。
2. ビルド時間のスループット計測
Javacはクラスパスに含まれるJARファイルの数（厳密には含まれるクラスファイルのインデックス構築コスト）に比例してメモリ消費とスキャン時間が増加する。
Gradleのビルドプロファイルを取得しつつクリーンビルド時間を計測
./gradlew clean build –profile
生成される HTML レポート（`build/reports/profile/profile-.html`）から、`JavaCompile` タスクの実行時間を抽出する。クラスパス肥大化によるI/O待ちとインメモリキャッシュのヒット率低下が解消されるため、CI環境でのコンパイル時間が 15%〜30%短縮 することが確認できる。
—
5. CI/CDパイプラインとの完全統合：汚染の再発を防ぐ防壁
ローカル環境で一度綺麗にしても、数週間後には別の開発者が「便利だから」と使わないライブラリを再び持ち込む。これを人間のコードレビューで防ぐのは不可能に近い。パイプラインに自動検知の網を張り、ルール違反のコードはマージすらさせないアーキテクチャを構築する。
GitHub Actionsワークフローの実装例
以下のYAMLを `.github/workflows/dependency-audit.yml` として配置する。
name: Dependency Architecture Audit
on:
pull_request:
branches: [ main, develop ]
push:
branches: [ main ]
jobs:
audit:
runs-on: ubuntu-latest
steps:
- name: Checkout Repository
uses: actions/checkout@v4
- name: Set up JDK 17
uses: actions/setup-java@v4
with:
distribution: ‘temurin’
java-version: ’17’
cache: ‘gradle’ # Gradleキャッシュを有効化し、パイプラインを高速化
- name: Run Dependency Health Check (Gradle)
run: |
# 依存関係に問題がある場合はここで非ゼロ終了コードが返り、CIが失敗する
./gradlew buildHealth –no-daemon
- name: Archive Dependency Report
if: always() # 成功・失敗に関わらずレポートをアーティファクトとして保存
uses: actions/upload-artifact@v4
with:
name: dependency-analysis-report
path: build/reports/dependency-analysis/
このパイプラインが稼働していれば、未使用ライブラリを含んだPull Requestは自動的にRed（ビルド失敗）になり、マージボタンがロックされる。
—
6. Dockerコンテナ環境における最適化ハック
マルチステージビルドを採用しているコンテナ環境においても、依存関係の最適化はコンテナイメージのレイヤーサイズとセキュリティ脆弱性（CVE）の削減に直結する。
— ステージ 1: ビルド環境 —
FROM gradle:8.5-jdk17 AS builder
WORKDIR /workspace
依存関係キャッシュを効率化するためにソースコードより先に設定ファイルをコピー
COPY build.gradle.kts settings.gradle.kts /workspace/
COPY gradle /workspace/gradle
依存関係の事前ダウンロード（ソース変更の影響を受けないレイヤー）
RUN gradle dependencies –no-daemon
ソースコードをコピーしてビルド＆依存関係検証を同時に走らせる
COPY src /workspace/src
RUN gradle buildHealth build -x test –no-daemon
— ステージ 2: ランタイム環境 —
FROM eclipse-temurin:17-jre-jammy
WORKDIR /app
肥大化していない最小限のFat JARのみをコピー
COPY –from=builder /workspace/build/libs/app-all.jar /app/app.jar
EXPOSE 8080
ENTRYPOINT [“java”, “-XX:+UseG1GC”, “-XX:MaxRAMPercentage=75.0”, “-jar”, “/app/app.jar”]
この構成により、アプリケーションコンテナに不要なクラスやライブラリが一切混入しなくなる。結果として、Dockerイメージの総容量が劇的に小さくなり、コンテナレジストリからのプル時間、K8sノードへのデプロイ速度、そして何より脆弱性スキャナー（TrivyやAqua Security等）が検知するCVEの数を最小限に抑え込むことができる。
—
結語：クリーンな依存関係は、エンジニアリングの品格である
「動けばいい」という時代は終わった。現代のDevOpsエンジニアにとって、コードベースの美しさはソースコードだけに留まらない。それを支える依存関係のトポロジー、ビルドの速度、コンテナの軽量性、そのすべてがシステムの品格を決定づける。
Mavenの `dependency:analyze` や Gradleの `dependency-analysis` プラグインをCI/CDの血肉とし、未知の肥大化をシステム的に排除し続けること。それこそが、持続可能で強靭なエンタープライズJavaアーキテクチャを維持唯一の道なのである。