こんにちは、エンジニアのオオバです。
Unity 6000.3 のプロジェクトで、Addressables 2.9.1 を使っていました。
パッケージレジストリを眺めると、Addressables はすでに 4.x まで出ています。
「2.9.1 って、もしかしてだいぶ古い？」
パッケージマネージャーで数字の大きいバージョンを見かけると、そわそわしますよね。
そこで2026年10月、「今のままでいいのか、最新に上げるべきか」をきちんと調べてみました。
本記事は、そのときの調べ方と判断の記録です。
4.xは見送り、効く修正が入った2系の保守版を選んだ
結論から言うと、最新の 4.x には上げませんでした。
選んだのは、2系の保守版です。
判断の材料にしたのは、次の3つです。
- エディタ本体が同梱・推奨しているバージョン
- 自分たちが継承・拡張しているAddressablesの内部API
- CHANGELOGに今の作業へ効く修正があるか
パッケージレジストリで出ているバージョンを確認する
まずは、どのバージョンが出ているのかを確認しました。
見たのは、Unity のパッケージレジストリ（packages.unity.com/com.unity.addressables）です。
レスポンスの versions と time を見ると、次の系統が並行して出ていました。
- 2.10.x・2.11.x（2系の保守版）
- 3.x
- 4.x（最新は 4.1.1）
つまり 2系は、3.x や 4.x が出た後も保守版として更新が続いています。
「最新の2系」と「最新のメジャー」は別の選択肢として並んでいる、ということですね。
Unityパッケージレジストリ（com.unity.addressables）エディタ同梱版を見ると2.9.1は古くなかった
次に確認したのが、エディタ本体の同梱版です。
Unity エディタのインストール先にある PackageManager/Editor/manifest.json には、そのエディタが同梱・推奨しているパッケージのバージョンが書かれています。
開いてみると、Unity 6000.3.23f1 が同梱・推奨している Addressables は 2.9.1 そのもの でした。
プロジェクトで使っていたバージョンと同じです。
レジストリだけを見ていると「2つもメジャーが遅れている」ように見えます。
でもエディタの基準で見ると、2.9.1 はこのエディタにとっての標準でした。
「古いから上げなきゃ」という焦りは、ここでいったん消えました。
4.xを見送った理由
ここからは、各バージョンの tgz を落としてきて CHANGELOG を読み比べました。
そのうえで 4.x を見送った理由は、大きく2つあります。
独自ビルドスクリプトが内部APIに依存している
いちばん大きかったのが、アセットビルドの仕組みです。
このプロジェクトのビルダーは、CRI が提供している独自のビルドスクリプトを使っています。
BuildScriptPackedMode を継承して、ProcessAllGroups と DoBuild を override している作りです。
3.x・4.x では、ビルドスクリプト周りの内部が変わっています。
継承して override しているクラスの中身が変わると、コンパイルが通っても、ビルド結果が変わる可能性があります。
自分たちが書いたコードではない部分なので、壊れたときに追いかけるのも大変です。
内部APIを継承しているかどうか は、パッケージを上げるときに真っ先に確認したいポイントだと感じました。
メジャーアップデートの破壊的変更
もう1つは、メジャーバージョンでの破壊的変更です。
CHANGELOG には、たとえば次のような変更が並んでいました。
- Include in Build の設定がグループ側へ移動
- バイナリカタログの変更
さらに 3.0 では実際に破壊的変更が入り、3.1.1 で revert されています。
メジャーの初期は、まだ揺れている時期があるということです。
4.1には魅力的な修正もあった
とはいえ、4.1 の CHANGELOG には、うれしい修正もありました。
- 設定を変えるたびに
AddressableAssetSettingsの Hash 行が書き換わる問題の修正（Git のノイズが消える） - キャッシュ判定の高速化
GetDownloadSizeAsync/DownloadDependenciesAsyncの修正
特に Hash 行の問題は、以前ハマった件とも関係していて、正直かなり欲しい修正です。
👉 【Addressables】AssetGroupにアセットを追加したのにロード失敗する件
それでも、独自ビルドスクリプトが壊れるリスクと比べると、今回は見送りという判断になりました。
2系の保守版を選んだ理由
では、2系のまま何もしないのか。
CHANGELOG を読むと、2系の保守版にも、今の作業に効く修正が入っていました。
2.10.0：LoadAssetAsyncとDownloadDependenciesAsyncの同時実行
同じ bundle に対して LoadAssetAsync と DownloadDependenciesAsync が同時に走ると、エラーやエディタのクラッシュになる問題が修正されています。
ちょうどこれから「ロード前の差分ダウンロード」を作る予定でした。
まさに踏みそうな組み合わせです。
実装してから原因を探すことにならずに済むのは、大きいですね。
2.10.1：Domain Reload無効時の再初期化
Domain Reload が無効のとき、エディタで Addressables を再初期化する修正です。
このプロジェクトは Domain Reload を無効にしているので、こちらも直接関係します。
2.10.0：その他の修正
ほかにも、ラベルを追加したときのソートや、BinaryFormatter の廃止が入っています。
2.11系はScriptable Build Pipelineの変化が大きい
2系の保守版の中でも、2.11 系は依存している Scriptable Build Pipeline（SBP）が 3.0 系に上がります。
ビルドの土台が変わるので、変化が大きい。
一方 2.10.3 なら、SBP は 2.6.2 で、変化は小さく収まります。
独自ビルドスクリプトへの影響を考えると、ここでも「ビルド周りが大きく変わらないか」が判断の軸になりました。
| 系統 | 効く修正 | リスク |
|---|---|---|
| 2.10.x | 同時実行の修正、Domain Reload無効時の修正 | SBP 2.6.2で変化が小さい |
| 2.11.x | 2.10.xの修正を含む | SBPが3.0系に上がる |
| 3.x / 4.x | Hash行の修正、キャッシュ判定の高速化など | ビルドスクリプト周りの内部が変わる、破壊的変更 |
学び：「最新にすべきか」は3つの材料で決める
今回の調査で、パッケージを上げるかどうかの判断の仕方が整理できました。
数字が大きいバージョンを見ると、つい「上げなきゃ」と思ってしまいます。
ただ、実際に判断に効いたのは次の3つでした。
- エディタの同梱版：今のエディタにとっての標準はどれか
- 継承・拡張している内部API：自分たちのコードやミドルウェアが、パッケージの内部にどこまで依存しているか
- CHANGELOGに今の作業へ効く修正があるか：これからやる作業で踏みそうな不具合が直っているか
3つ目は特におすすめです。
CHANGELOG を「何が変わったか」の一覧として読むと、量が多くて途中で疲れます。
「今の作業で踏みそうなものはどれか」と目的を持って読むと、必要な行がすっと目に入ってきました。
まとめ
本記事では、Addressables 2.9.1 を使っているプロジェクトで、最新の 4.x に上げるかどうかを調べ、2系の保守版を選んだ話をしてきました。
簡単に全体をまとめます。
- パッケージレジストリでは2系の保守版・3.x・4.xが並行して出ていた
- Unity 6000.3.23f1が同梱・推奨しているのは2.9.1だった
- BuildScriptPackedModeを継承した独自ビルドスクリプトがあるので4.xは見送った
- 2.10系にはロードと差分ダウンロードの同時実行やDomain Reload無効時の修正が入っていた
- 2.11系はSBPが3.0系に上がるので変化が大きい
パッケージのバージョンアップは、上げること自体が目的になりがちです。
エディタの基準、自分たちの依存、今の作業に効く修正。
この3つを見てから決めるようにすると、焦らずに選べると思います。
Addressables に限らず、パッケージを上げるか迷っている方の参考になればうれしいです。
筆者のXをフォローしよう
- Unity 6000.3 / Addressables 2.9.1