- 導入：Android Studioが「なんか壊れてる」時、消す順番が超重要
- 前提：本当に「キャッシュ破損」かどうかをざっくり見分ける
- 消す前に守るルール：消してOKなもの／慎重なもの
- 安全な削除の順番：上から順にやる
- 比較表：どこを消すと何が起きる？
- 症状別：どのStepから入るべき？
- やりすぎ事故あるある
- デバッグ/確認チェックリスト
- よくある質問（Q&A）
- まとめ：迷ったらこの順番
導入：Android Studioが「なんか壊れてる」時、消す順番が超重要
Android Studio、たまにありますよね。
- Gradle Sync が急に通らない
- 補完が死ぬ、検索が遅い、インデックスがおかしい
- Layout Preview が真っ白
- Androidビューの表示が崩れる、モジュールが消えた風になる
- 昨日まで動いてたのに、急に謎のエラーが出る
こういう「キャッシュ破損っぽい」症状は、焦って全部消すと泥沼になりがちです。
この記事では、安全な順番で「どこまで消すか」を整理します。
同じ削除でも、順番が違うと被害がまったく違います。
先に結論（3行）です。
- まずは IDE 内のキャッシュリセット（再起動まで含めて）
- 次にプロジェクト側（build/.gradle/.idea）を段階的に消す
- 最後にユーザー側キャッシュ（~/.gradle など）を最小範囲で消す
前提：本当に「キャッシュ破損」かどうかをざっくり見分ける
キャッシュ破損“っぽい”症状は、コードのバグと混ざります。
まずは次の特徴があるか確認してください。
- エラー内容が毎回ちょっと違う（再起動で変わる）
- 同じブランチでも「このPCだけ」おかしい
- CIでは通るのに手元だけ失敗する
- Android Studio / AGP / Kotlin の更新直後に発生した
逆に、同じ操作で必ず同じ例外が出るなら、キャッシュというより設定・コードが原因の可能性が高いです。
消す前に守るルール：消してOKなもの／慎重なもの
削除の手順に入る前に、ここだけ押さえると事故率が下がります。
基本的に消してOK（復元される）
- 各モジュールの build/
- プロジェクト直下の .gradle/（プロジェクト用）
- .idea/（ただし消し方にコツあり）
- *.iml（残っている場合）
慎重に扱う（消すと戻らない／困ることがある）
- keystore（署名鍵）
- local.properties（SDKパスなど）
- gradle.properties（チューニングや社内設定が入っていることがある）
- 個人だけのRun/Debug設定（共有していない場合）
「全部消したら直ったけど、別の地獄が始まった」は避けたいですよね。
安全な削除の順番：上から順にやる
ここからが本題です。
下に行くほど「効くけど重い」「戻すのが面倒」になります。
Step 0：状況を固定する（最短で戻せるようにする）
- Android Studio を閉じる（重要）
- 今の状態をコミット or ブランチを切る
- エラー文をメモ（スクショでもOK）
「何をしたら直ったのか」を追えるようにするのが一番大事です。
Step 1：IDEのキャッシュをリセット（まずこれ）
最初は IDE が用意しているキャッシュリセットを使います。
ここで直るなら、プロジェクトを荒らさずに済みます。
- キャッシュをリセットして再起動
- 再インデックスが走るので少し待つ
直ったかどうかは、Syncが通るかだけでなく「補完が戻ったか」「検索がまともか」も見ます。
Step 2：Gradle周りの軽いリセット（消さずに試す）
Gradleの状態が変なだけなら、削除より先にこれで片付くことがあります。
Gradleデーモンを止める
./gradlew --stop依存解決をやり直す（ネットワーク前提）
./gradlew clean --refresh-dependenciesここで改善するなら、「キャッシュ破損」というより「依存取得や解決が中途半端」だった可能性が高いです。
Step 3：プロジェクト配下の build/ と .gradle/ を削除（安全度高い）
ここは鉄板です。
- 各module/build/
- プロジェクト直下の .gradle/
削除後に Sync / ビルドを実行します。
中間生成物が壊れている系は、ここでかなり直ります。
Step 4：.idea と *.iml を再生成（効くけど、手順を守る）
モジュール構成が壊れて見える、補完が壊れる、Androidビューが変、みたいな時に効きます。
ただし、やり方を間違えると設定を巻き込みます。
おすすめ手順（削除ではなく“退避”）
- Android Studio を閉じる
- .idea をリネーム（例：.idea_bak）
- *.iml があれば削除
- Android Studioで開き直してSync
いきなり削除してもいいですが、退避しておくと「戻したい」ができます。
Step 5：ユーザー側の Gradle キャッシュを削る（最後の一歩手前）
ここから一気に重くなります。
ただ、依存関係の破損・zipの途中取得・謎の解決失敗にはよく効きます。
基本は「cachesだけ」
- ~/.gradle/caches を削除
~/.gradle を丸ごと消すのは、環境依存の設定を置いている場合に事故りやすいので後回しにします。
Step 6：IDE本体のSystemキャッシュを消す（最終手段）
Step 1 をやっても直らない場合、IDEのキャッシュディレクトリ自体が壊れていることがあります。
この場合は IDE を閉じた状態で、System（キャッシュ）だけを退避します。
- Systemディレクトリをリネームして退避（削除ではなく）
- 起動して再インデックスを待つ
設定（Config）まで消すのは最後です。
キーマップやプラグイン状態も飛ぶので、復旧コストが跳ねます。
比較表：どこを消すと何が起きる？
| 対象 | 効きやすい症状 | 副作用 | おすすめ |
|---|---|---|---|
| IDEキャッシュリセット | 補完崩れ/検索遅い/インデックス不調 | 再インデックスで少し待つ | まずやる |
| build/ と project .gradle/ | 突然のビルド失敗/生成物破損 | 初回ビルドが遅くなる | かなり効く |
| .idea / *.iml | モジュール認識崩れ/Androidビュー崩れ | IDE設定が一部戻る場合 | 次にやる |
| ~/.gradle/caches | 依存取得の破損/謎の解決失敗 | 再DLで時間がかかる | 重いが強い |
| IDE System | IDE自体がおかしい/起動後に不調 | 再構築が重い | 最終手段 |
症状別：どのStepから入るべき？
全部上からやるのが基本ですが、症状で近道できることもあります。
- 補完・検索・ジャンプが変 → Step 1 → ダメなら Step 4
- Syncだけ失敗、依存解決が怪しい → Step 2 → Step 5
- モジュールが消えた風、Androidビューが壊れた → Step 4
- 突然ビルドが怪しい（生成物っぽい） → Step 3
やりすぎ事故あるある
- SDKまで消してしまい、復旧に時間がかかる
- ~/.gradle を全消しして環境依存の設定が飛ぶ
- .idea を消して個人のRun設定が消える
- 闇雲に消して、原因が分からないまま再発する
「退避（リネーム）」を基本にするだけで、事故率が下がります。
デバッグ/確認チェックリスト
- Android Studioを閉じてから作業したか
- まずIDEキャッシュリセットを試したか
- build/ と project .gradle/ を消したか
- .idea は削除ではなく退避で試したか
- ~/.gradle は caches だけにしたか
- IDE System を消すのは最後にしたか
- 直ったStepを記録したか（再発対策）
よくある質問（Q&A）
Q. 「IDEキャッシュリセット」だけで直らない時は何を疑う？
インデックス以外が原因の可能性が高いです。生成物破損なら Step 3、プロジェクト構造が怪しいなら Step 4、依存取得の破損なら Step 5 が効きやすいです。
Q. .idea を消すと何が困る？
プロジェクトのIDE設定が再生成されます。共有していないRun設定や、個人のIDE設定が戻ることがあります。削除ではなくリネームで退避すると安全です。
Q. ~/.gradle を丸ごと消すのはダメ？
最終手段としてはアリですが、まずは caches だけを推奨します。丸ごと消すと、環境依存の設定を置いている場合に痛いです。
Q. どれを消しても直らない場合は？
キャッシュではなく、Gradle/AGP/Kotlin/プラグインの相性や設定変更が原因の可能性があります。直前の変更差分と、エラーログの安定性（毎回同じか）を見直すのが近道です。
まとめ：迷ったらこの順番
- IDEキャッシュリセット（再起動まで）
- build/ と project .gradle/ を削除
- .idea / *.iml を退避して再生成
- ~/.gradle/caches を削除
- IDE System を退避（最終手段）
迷ったらこれ：「軽いところから順に。削除ではなく退避。」
この方針で、復旧速度と事故率がかなり変わります。
コメント