【Unity】Addressablesで追加コンテンツを後から配信する：Remote設定・カタログ・更新ビルド

Addressablesの入門記事 で「アプリを更新せずにコンテンツを配信できる」と知り、アセットをAddressable化した。ところが、いざ「リリース後にイベント衣装を追加したい」と思って手を止めます—— 配信って、どこから何をするんだ？ ビルドしてみれば、Addressable化したアセットも結局ぜんぶアプリに同梱されている。差し替えても何も起きない。

種明かしをすると、Addressable化は配信の 準備 にすぎません。実際に「後から配信」を成立させるのは、 Remoteの置き場所設定・カタログ・更新ビルド という3点セットです。この記事では、イベント衣装を後日配信する題材で、この3点を一通り動かします。

この記事でわかること

• Addressable化しただけでは配信にならない理由（LocalとRemoteの違い）
• Build Path / Load Path の意味と、開発用・公開用URLの切り替え
• アプリと中身をつなぐ カタログ の役割と、起動時の 更新チェック の実装
• 変えてよいもの・凍結すべきものを分ける 更新ビルド（Update a Previous Build）
• オフライン時に遊べる範囲と、失敗時の見せ方

動作確認環境: Unity 2022.3 LTS / Unity 6（Addressablesパッケージ）

Addressable化しただけでは配信されない

まず現在地を確認します。Addressableなアセットは グループ 単位で管理され、各グループには「ビルドしたバンドルをどこへ置き、実行時にどこから読むか」の設定があります。そして既定はすべて Local ——つまりビルドと一緒にアプリ内へ同梱され、実行時もアプリ内から読む設定です。

Localのままなら、入門記事 で学んだロードとメモリ管理の恩恵はすべて受けられますが、 中身はアプリの一部 です。リリース後に差し替える手段はアプリ更新しかありません。「後から配信」を成立させる第一歩は、配信したいグループを Remote ——バンドルをサーバーへ置き、実行時にそこからダウンロードする設定——へ切り替えることです。

置き場所と取り先:Build PathとLoad Path

Remoteへの切り替えで触るのが、グループ設定の Build Path（ビルド成果物を書き出すフォルダ）と Load Path（実行時に読みに行く場所）です。値そのものは Profiles（Window > Asset Management > Addressables > Profiles）で一元管理されています。

• Remote.BuildPath: 既定は ServerData/[BuildTarget]。ビルドすると、ここにバンドルとカタログが書き出されます。 このフォルダの中身を丸ごとサーバーへアップロードする のが配信作業です
• Remote.LoadPath: アプリが読みに行くURL。例えば https://cdn.example.com/mygame/[BuildTarget]。[BuildTarget] はプラットフォーム名（StandaloneWindows64など）に展開されるので、プラットフォーム別の置き分けが自動で効きます

そして実運用で必ず欲しくなるのが、 開発用と公開用のURL切り替え です。Profilesは複数作れるので、Development（手元の検証サーバーや http://localhost ）と Production（本番CDN）の2つのプロファイルを用意し、ビルド前に切り替えるだけにしておきます。URLをコードに書かないことで、切り替え忘れ以外の事故がなくなります。

tips: 検証段階では、レンタルサーバーやクラウドストレージの静的ホスティングで十分です。要件は「HTTPでファイルが取れること」だけ——専用のゲームサーバーは要りません。

カタログ:アプリと中身をつなぐ目次

Remoteの仕組みの心臓部が カタログ（Catalog） です。カタログは「アドレス→どのバンドルのどのアセットか」を引くための 目次ファイル で、アプリはロード時にまずカタログを引き、必要なバンドルをダウンロードします。

「アプリ更新なしで配信できる」のからくりは、この目次にあります。 アプリは目次の場所しか知らず、中身は目次経由でしか知らない。だから、サーバー上の目次とバンドルを新しくすれば、アプリ本体はそのままで新しいコンテンツにたどり着けるのです。

このためにAddressables設定（AddressableAssetSettings）で Build Remote Catalog を有効にしておきます。これでビルド時にカタログ本体（.json）と、更新検知用の小さなハッシュファイル（.hash）がRemote.BuildPathへ出力されるようになります。初回のビルドは、Addressables Groupsウィンドウの Build > New Build > Default Build Script です。出力された ServerData の中身をサーバーへ置けば、配信の土台は完成です。

tips: 初回ビルドで Assets/AddressableAssetsData 以下に addressables_content_state.bin というファイルが生成されます。これは後述の更新ビルドの基準になる大事なファイルなので、 リリースごとにバージョン管理へ含めて保管 してください。

起動時の更新チェックを実装する

サーバーに新しいカタログを置いても、 アプリは勝手には見直しません。起動時に「新しい目次が出ていないか」を確認する処理を入れます。流れは決まりきっているので、そのまま使える形で示します。

using System.Collections;
using UnityEngine;
using UnityEngine.AddressableAssets;

public class ContentUpdater : MonoBehaviour
{
    private IEnumerator Start()
    {
        // 1. 新しいカタログが出ているか確認（.hashファイルの比較）
        var checkHandle = Addressables.CheckForCatalogUpdates(false);
        yield return checkHandle;

        var updatedCatalogs = checkHandle.Result;
        if (updatedCatalogs != null && updatedCatalogs.Count > 0)
        {
            // 2. 出ていれば目次を差し替える
            var updateHandle = Addressables.UpdateCatalogs(updatedCatalogs, false);
            yield return updateHandle;
            Addressables.Release(updateHandle);
            Debug.Log("カタログを更新しました");
        }

        Addressables.Release(checkHandle);

        // 3. 以降のLoadAssetAsyncは、新しい目次で新しい中身を引く
    }
}

これだけで「起動のたびに最新の目次へ更新」が動きます。バンドル自体は、この後 LoadAssetAsync した時に必要なぶんだけ自動でダウンロードされます（ロードとReleaseの作法は 入門記事 のままです）。

事前にまとめて落としたい場合は、Addressables.GetDownloadSizeAsync(key) でダウンロードサイズを調べ、0より大きければ DownloadDependenciesAsync(key) ——「◯MBの追加データがあります」という、あのモバイルゲームの起動画面はこの2つで作られています。

更新ビルド:変えてよいもの・凍結するもの

配信の仕組みは動きました。残る問題は 「既に遊ばれているアプリと矛盾しない更新ファイルをどう作るか」 です。ここで普通に New Build してしまうと、全バンドルが作り直されて名前も変わり、既存アプリのローカル同梱分との整合が壊れます。

答えは2段構えです。

• 初回リリース: Build > New Build で全体を作り、addressables_content_state.bin を保管する
• リリース後の更新: Build > Update a Previous Build を選び、保管しておいた .bin を指定する。すると 前回から変更されたアセットのバンドルだけ が新しく作られ、カタログも互換性を保ったまま更新されます。出力をサーバーへ上書きアップロードすれば配信完了です

もう1つ、グループの Update Restriction 設定で「リリース後に変えてよいグループか」を宣言しておきます。イベント衣装のような 変える前提のコンテンツはRemoteの変更可グループ に、本体の根幹アセットは 凍結（変更不可）グループ に分けておくと、更新ビルドが差分を正しく・小さく作れます。この「変えるものと凍結するものを先に分けておく」発想は、セーブデータの互換性 で「IDは凍結・表示は自由」と線を引いたのと同じ運用の知恵です。

実践:イベント衣装を後日配信する

通しでやってみましょう。「リリース済みのゲームに、ハロウィン衣装を後から追加する」——ソシャゲの期間限定衣装、buildの済んだ体験版へのステージ追加、シーズンイベントの小物。この型がそのまま使えます。

リリース時（準備）:

1. 衣装用のRemoteグループ EventCostumes を作る（Build/Load PathはRemote、Update Restrictionは変更可）
2. Build Remote Catalogを有効にして New Build → ServerData をサーバーへアップロード、.bin を保管
3. アプリには前述の ContentUpdater と、「アドレスで衣装をロードする」コードだけ入れてリリース

後日（配信当日）:

1. ハロウィン衣装のプレハブを EventCostumes グループに追加し、アドレス（例: costume_halloween）を付ける
2. Update a Previous Build（保管した .bin を指定）→ 出力をサーバーへ上書きアップロード
3. おしまい。 アプリ側の作業はゼロ です

プレイヤーのアプリは次の起動でカタログ更新を検知し、衣装選択画面が costume_halloween をロードすると、その時だけバンドルがダウンロードされて新衣装が現れます。配信前に一度、Profileを Development に切り替えて検証サーバーで同じ流れを通しておくと、本番はアップロードするだけになります。

動作確認では、わざと意地悪もしてみてください。機内モードで起動すると、更新チェックは失敗しますが キャッシュ済み・ローカル同梱の範囲は普通に遊べる はずです。まだ落としていない新衣装だけが取得できないので、そこには「オフラインのため取得できません」の表示を出します——更新失敗を エラーではなく「今回は見送り」 として扱い、ゲーム本編を止めないのが配信ものの作法です。

ポイントは2つ。 アプリは目次（カタログ）しか知らないから、サーバー側の差し替えだけで新コンテンツが届く こと。そして 初回の .bin を基準にした更新ビルドだから、既存アプリと矛盾しない差分だけを配れる ことです。

おまけ:先に知っておくと良いこと

• 必須コンテンツはローカルに残す: タイトルから最初のステージまでに要るものをRemoteにすると、初回起動が「ダウンロード待ち」になります。 本体進行はローカル、追加要素はリモート の線引きが快適さを決めます
• CDNのキャッシュに注意: カタログの .hash がCDNに古いままキャッシュされると、更新が届かない・逆に混ざる事故が起きます。配信基盤側のキャッシュ設定（無効化やパージ）は、本格運用の前に公式ドキュメントの「ContentUpdateWorkflow」とCDN側の資料で確認してください
• ロールバックは「前の出力を置き直す」: 更新に問題があった場合、サーバーの中身を前回の出力へ戻せばアプリは前の状態へ戻ります。そのためにも リリースごとの ServerData 出力と .bin を世代管理 しておくのが安全です
• ビルド全体の流れは別記事で: プラットフォームごとのビルド設定やビルド番号の管理は ビルド設定の記事 が土台になります

まとめ

• Addressable化は準備。「後から配信」は Remote設定・カタログ・更新ビルド の3点で成立する
• Build Path / Load Path はProfilesで管理し、開発用と公開用のURLをプロファイル切り替えにする
• アプリは カタログ（目次） しか知らない。Build Remote Catalogを有効にし、起動時に CheckForCatalogUpdates → UpdateCatalogs
• 更新は Update a Previous Build。初回の addressables_content_state.bin を必ず保管し、変える物と凍結する物をグループで分ける
• オフラインでも遊べる範囲を設計し、更新失敗は「見送り」として本編を止めない

アプリ更新の審査を待たずに、明日の朝イチで新衣装を届けられる体制ができました。あなたのゲームで最初に「後から届けたいもの」は何ですか？