導入：「依存関係が解決できない」は原因が広すぎてしんどい
Gradleビルドで突然出てくる、あの系のエラー。
- Could not resolve all files for configuration
- Could not find xxx
- Failed to transform / Could not HEAD / PKIX path building failed
これ、慣れてても嫌です。原因が広いし、環境差も出るし、再現性も怪しい。
ただし、落ち着いて見ると「疑う順番」は決まっています。
この記事では、依存が解決できない時にまず疑うべき5つを、実務で使える切り分け手順としてまとめます。
先に結論（3行）です。
- まずは「リポジトリ設定と順番」→ 次に「ネットワーク（Proxy/HTTPS）」
- 証明書系（PKIX）は環境依存なので、JDK/TrustStore/中間CAを疑う
- 最後にキャッシュ・競合・ミラー（社内）を潰す
まず疑うべき5つ（一覧）
先に全体像です。依存解決エラーは、基本この5カテゴリに落ちます。
- mavenリポジトリ設定（URL/順番/宣言場所）
- HTTPS/証明書（PKIX、SNI、TLS、社内CA）
- プロキシ/VPN/フィルタ（社内ネットワーク）
- バージョン競合・解決戦略（BOM、依存ツリー）
- キャッシュ破損・ミラー不整合（Gradleキャッシュ）
以降はこの順番で、確認ポイントとコマンドを出します。
1) mavenリポジトリ設定（URL/順番/宣言場所）
まずここです。依存が取れない時、根本は「どこから取るか」が壊れてるケースが多い。
チェック1：repositories はどこで宣言している？
最近は settings.gradle(.kts) 側でリポジトリ管理する構成が増えています。
プロジェクトによっては build.gradle で書いても無視されることがあります。
まずは以下を確認します。
- settings.gradle(.kts) に dependencyResolutionManagement があるか
- repositoriesMode が “FAIL_ON_PROJECT_REPOS” などになっていないか
- build.gradle の repositories が効いている構成か
チェック2：mavenCentral() / google() の順番
順番が原因で解決が遅くなったり、到達できないリポジトリを先に見に行って詰まることがあります。
実務的には、
- google()
- mavenCentral()
- （社内maven / jitpack 等）
の順が安定しやすいです。怪しいリポジトリ（落ちやすい、遅い）を先頭に置くのは避けます。
チェック3：リポジトリURLが http になっていない？
http は最近の環境だと弾かれることがあります。
https でアクセスできるなら必ず https に寄せます。
チェック4：リポジトリが落ちている/ブロックされている
「自分のPCだけ」ならネットワーク差分ですが、全員落ちているなら単純にリポジトリ障害のこともあります。
その場合は無理に直そうとせず、まず状況共有が早いです。
2) HTTPS/証明書（PKIX、SNI、TLS、社内CA）
次に多いのが証明書系です。
Gradleの依存取得は最終的にHTTPS通信なので、証明書が怪しいと一瞬で詰みます。
典型エラー
- PKIX path building failed
- unable to find valid certification path to requested target
- handshake_failure / SSLHandshakeException
チェック1：Gradleが使っているJDKはどれ？
証明書は JDK の trust store に依存します。
つまり「どのJDKでGradleが動いているか」が超重要です。
- Android StudioのGradle JVM
- CIのJavaバージョン
ローカルはJDK 17、CIはJDK 11、みたいなズレがあると、証明書エラーが片方だけで出ます。
チェック2：社内CA（中間証明書）を使っている？
社内ネットワークでSSL検査（MITM）や独自CAを使っていると、外部mavenへのHTTPSが証明書エラーになります。
この場合、端末（ブラウザ）では開けても、Gradleでは落ちる、が起きがちです。
対策の方向性は大きく2つです。
- 正しいCAをJDKのtrust storeに入れる（管理された手順で）
- 社内ミラー（Nexus/Artifactory等）経由に寄せる
後者の方が運用は安定しますが、環境依存になります。
チェック3：TLSバージョン・SNIの相性
古い環境や特殊なプロキシでTLSのネゴが壊れることがあります。
この場合はJDK更新で直ることも多いです。
「証明書っぽいけど実はTLS」もあるので、JDKを揃えるのは早めが吉です。
3) プロキシ/VPN/フィルタ（社内ネットワーク）
次はネットワーク経路です。
プロキシやVPNが絡むと、「ある人だけ取れない」が起きやすい。
チェック1：Gradleがプロキシ設定を見ているか
プロキシ環境では、gradle.properties に proxy を設定しているケースがあります。
ただ、設定が古い/誤っていると逆に詰まります。
「会社のネットでだけ落ちる」「家だと通る」なら、ほぼここです。
チェック2：VPN/セキュリティソフトの影響
VPNがDNSや経路を変えて、mavenCentralへの到達が不安定になることがあります。
セキュリティソフトがHTTPS検査をしているケースも同様です。
切り分けとしては、
- VPNを切って試す
- 別ネットワーク（テザリング等）で試す
が強いです。これで通るなら、Gradle設定よりネットワーク要因が濃厚です。
チェック3：名前解決（DNS）が怪しい
依存取得の失敗が「タイムアウト」「UnknownHost」系なら、DNSや経路が怪しいです。
証明書より先にネットワークを疑います。
4) バージョン競合・解決戦略（BOM、依存ツリー）
ここまでで「取れない（通信できない）」が潰れると、次は「取れたけど解決できない」です。
典型症状
- 依存のバージョンが噛み合わず解決不能
- 同じgroupの別バージョンが衝突
- BOMと直指定が混在して地獄
まずやる：依存ツリーを出す
./gradlew :app:dependenciesマルチモジュールなら、落ちているモジュール単位で出すのがコツです。
次にやる：BOMを使うものはBOMで揃える
FirebaseやComposeなど、BOM前提のものはBOMで揃えると解決が安定します。
直指定が混ざると、解決結果が想定とズレます。
最後にやる：resolutionStrategyで強制固定（最終手段）
強制固定は効きますが、隠れた不整合を生みます。
どうしても必要な時だけにして、後で正しく直す前提で使うのが現実的です。
5) キャッシュ破損・ミラー不整合（Gradleキャッシュ）
最後はキャッシュです。
依存取得が途中で壊れたり、ミラーが中途半端な状態を返してきたりすると、同じ依存が永遠に取れません。
まずは軽く：依存再取得
./gradlew --refresh-dependencies次に：Gradleデーモン停止
./gradlew --stop最後：~/.gradle/caches の削除（重い）
本当に最後です。再ダウンロードが走るので時間がかかります。
最短で原因に辿り着くための「調査の順番」
もう一度まとめます。迷ったらこの順番で。
- repositoriesの宣言場所と順番（settings/build）
- ネットワーク（別回線で通るか）
- 証明書（JDK差分、社内CA）
- 依存ツリー（競合/解決戦略）
- キャッシュ（refresh → caches削除）
「いきなり caches 削除」は気持ちは分かりますが、根本原因が残るので再発しやすいです。
デバッグ/確認チェックリスト
- repositories の宣言場所（settings.gradle）を確認した
- google/mavenCentral の順番が妥当
- HTTPではなくHTTPSのURLになっている
- 別ネットワークで試して差分を見た
- Gradle JVM のJDKがローカル/CIで揃っている
- 社内CA/SSL検査の有無を把握した
- dependenciesタスクで競合を確認した
- –refresh-dependencies を試した
よくある質問（Q&A）
Q. 会社のネットだけ取れないです
プロキシ/VPN/SSL検査の可能性が高いです。まず別回線（テザリング等）で通るか確認すると、切り分けが一気に進みます。
Q. PKIXって出たら何をすればいい？
まずGradleが使っているJDKを確認します。次に社内CAや中間証明書の問題を疑います。JDKが違うだけで片方だけ落ちることが多いです。
Q. –refresh-dependenciesでも直りません
キャッシュ破損が強いなら ~/.gradle/caches を消すのが手ですが、その前にネットワークと証明書の切り分けが終わっているか確認した方がいいです。根本が残ると再発します。
まとめ：依存が取れない時は「上から順に潰す」
- まずmaven設定（宣言場所/順番）
- 次にネットワークと証明書（JDK差分）
- 最後に競合とキャッシュを潰す
迷ったら：別回線で試す → JDKを揃える。
この2つで原因が一気に絞れることが多いです。