Addressablesの入門記事 で「アプリを更新せずにコンテンツを配信できる」と知り、アセットをAddressable化した。ところが、いざ「リリース後 にイベント衣装を追加したい」と思って手を止めます—— 配信って、どこから何をするんだ？ ビルドしてみれば、Addressable化したアセットも結局ぜんぶアプリに同梱されている。差し替えても何も起きない。
種明かしをすると、Addressable化は配信の 準備 にすぎません。実際に「後から配信」を成立させるのは、 Remoteの置き場所設定・カタログ・更新ビルド という3点セットです。この記事では、イベント衣装を後日配信する題材で、この3点を一通り動かします。
この記事でわかること
- Addressable化しただけでは配信にならない理由（LocalとRemoteの違い）
- Build Path / Load Path の意味と、開発用・公開用URLの切り替え
- アプリと中身をつなぐ カタログ の役割と、起動時の 更新チェック の実装
- 変えてよいもの・凍結すべきものを分ける 更新ビルド（Update a Previous Build）
- オフライン時に遊べる範囲と、失敗時の見せ方
動作確認環境: Unity 6 (6000.x)・Addressables 2.x
Addressable化しただけでは配信されない
まず現在地を確認します。Addressableなアセットは グループ 単位で管理され、各グループには「ビルドしたバンドルをどこへ置き、実行時にどこから読むか」の設定があります。そして既定はすべて Local ——つまりビルドと一緒にアプリ内へ同梱され、実行時もアプリ内から読む設定です。
Localのままなら、入門記事 で学んだロードとメモリ管理の恩恵はすべて受けられますが、 中身はアプリの一部 です。リリース後に差し替えるには、ふつうはアプリを出し直します。「後から配信」を成立させる第一歩は、配信したいグループを Remote ——バンドルをサーバーへ置き、実行時にそこからダウンロードする設定——へ切り替えることです。
置き場所と取り先:Build PathとLoad Path
Remoteへの切り替えは、グループ設定の Build & Load Paths で Remote を選ぶだけです。これで、そのグループの Build Path（ビルド成果物を書き出すフォルダ）と Load Path（実行時に読みに行く場所）が、まとめてRemote用の値になります。値そのものは 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をコードに書かないことで、切り替え忘れ以外の事故がなくなります。
http:// のサーバーで確かめるときは、もう1つ設定があります。Unity 6 では Edit > Project Settings > Player > Other Settings の Allow downloads over HTTP が既定で許可されていないので、Allowed in Development Builds にして、Development Buildで確かめます。実機で試すなら、localhost ではなくPCのIPアドレスを書きます（実機の localhost は実機自身を指します）。
tips: 検証段階では、レンタルサーバーやクラウドストレージの静的ホスティングで十分です。要件は「HTTPでファイルが取れること」だけ——専用のゲームサーバーは要りません。
カタログ:アプリと中身をつなぐ目次
Remoteの仕組みの心臓部が カタログ（Catalog） です。カタログは「アドレス→どのバンドルのどのアセットか」を引くための 目次ファイル で、アプリはロード時にまずカタログを引き、必要なバンドルをダウンロードします。
「アプリ更新なしで配信できる」のからくりは、この目次にあります。 アプリは目次の場所しか知らず、中身は目次経由でしか知らない。だから、サーバー上の目次とバンドルを新しくすれば、アプリ本体はそのままで新しいコンテンツにたどり着けるのです。
このためにAddressables設定（AddressableAssetSettings）で Build Remote Catalog を有効にしておきます。これでビルド時にカタログ本体（Addressables 2.xの既定では catalog_ で始まる .bin。設定で .json にもできます）と、更新検知用の小さなハッシュファイル（.hash）がRemote.BuildPathへ出力されるようになります。初回のビルドは、Addressables Groupsウィンドウの Build > New Build > Default Build Script です。出力された ServerData の中身をサーバーへ置けば、配信の土台は完成です。
tips: 初回ビルドで
Assets/AddressableAssetsData/<プラットフォーム名>/にaddressables_content_state.binというファイルが生成されます（カタログの.binとは別のファイルです）。これは後述の更新ビルドの基準になる大事なファイルなので、 リリースごとにバージョン管理へ含めて保管 してください。
起動時の更新チェックを実装する
サーバーに新しいカタログを置くと、Addressablesは既定では初期化のときに自動で確認し、新しい目次へ差し替えます。ただ、確認できなかったときの扱いや「◯MBの追加データがあります」のよう な画面を作るなら、確認は自分で書きます。Addressables設定で Only update catalogs manually をオンにして（オフのままだと自動の確認が先に済み、自分の確認はいつも0件になります）、起動時に「新しい目次が出ていないか」を確認する処理を入れます。流れは決まりきっているので、そのまま使える形で示します。
using System.Collections;
using UnityEngine;
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement.AsyncOperations;
public class ContentUpdater : MonoBehaviour
{
private IEnumerator Start()
{
// 1. 新しいカタログが出ているか確認（.hashファイルの比較）
var checkHandle = Addressables.CheckForCatalogUpdates(false);
yield return checkHandle;
// オフラインなどで確認できなかったら、今回は見送って手元の目次のまま進む
if (checkHandle.Status != AsyncOperationStatus.Succeeded)
{
Addressables.Release(checkHandle);
yield break;
}
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 してしまうと、カタログの名前（既定ではビルドした日時入り）が変わり、既存のアプリは新しい目次を見つけられません。バンドルの名前も変わることが多く、既存アプリに同梱したLocal分との整合も崩れます。
答えは2段構えです。
- 初回リリース: Build > New Build で全体を作り、
addressables_content_state.binを保管する - リリース後の更新: Build > Update a Previous Build を選び、保管しておいた
.binを指定する。ビルド自体は毎回全体を作り直しますが、カタログは互換性を保ったまま更新され、 既存のプレイヤーが落とすのは、前回から変えたアセットの入ったバンドルだけ です。出力をサーバーへ上書きアップロードすれば配信完了です。更新ビルドでは.binは書き換わらないので、次の更新でも同じ初回の.binを使います
もう1つ、グループの Content Update Restriction にある Prevent Updates で、出荷したバンドルを凍結するかどうかを決めておきます。オンのグループは、中のアセットを変えても出荷したバンドルはそのまま残り、変えたアセットだけが新しいRemoteのバンドルへ移されて配られます。オフのグループは、変えたアセットを含むバンドルごと作り直されます。アプリに同梱した Localグループはオン にします（オフだと、作り直したLocalバンドルは既存アプリの中に無いので、ロードに失敗します）。イベント衣装のように丸ごと差し替える前提のRemoteグループは、オフのままで構いません。この「変えるものと凍結するものを先に分けておく」発想は、セーブデータの互換性 で「IDは凍結・表示は自由」と線を引いたのと同じ運用の知恵です。
実践:イベント衣装を後日配信する
通しでやってみましょう。「リリース済みのゲームに、ハロウィン衣装を後から追加する」——ソシャゲの期間限定衣装、buildの済んだ体験版へのステージ追加、シーズンイベントの小物。この型がそのまま使えます。
リリース時（準備）:
- 衣装用のRemoteグループ
EventCostumesを作る（Build & Load PathsはRemote、Prevent Updatesはオフ） - Build Remote CatalogとOnly update catalogs manuallyを有効にして New Build →
ServerDataをサーバーへアップロード、.binを保管 - アプリには前述の
ContentUpdaterと、「アドレスで衣装をロードする」コードだけ入れてリリース
後日（配信当日）:
- ハロウィン衣装のプレハブを
EventCostumesグループに追加し、アドレス（例:costume_halloween）を付ける - Update a Previous Build（保管した
.binを指定）→ 出力をサーバーへ上書きアップロード - おしまい。 アプリ側の作業はゼロ です
プレイヤーのアプリは次の起動でカタログ更新を検知し、衣装選択画面が costume_halloween をロードすると、その時だけバンドルがダウンロードされて新衣装が現れます。配信前に一度、Profileを Development に切り替えて検証サーバーで同じ流れを通しておくと、本番はアップロードするだけになります。
動作確認では、わざと意地悪もしてみてください。機内モードで起動すると、更新チェックは失敗しますが キャッシュ済み・ローカル同梱の範囲は普通に遊べる はずです。まだ落としていない新衣装だけが取得できないので、そこには「オフラインのため取得できません」の表示を出します——更新失敗を エラーではなく「今回は見送り」 として扱い、ゲーム本編を止めないのが配信ものの作法です。
ポイントは2つ。 アプリは目次（カタログ）しか知らないから、サーバー側の差し替えだけで新コンテンツが届く こと。そして 初回の .bin を基準にした更新ビルドだから、既存アプリと矛盾しない差分だけを配れる ことです。
おまけ:先に知っておくと良いこと
- 必須コンテンツはローカルに残す: タイトルから最初のステージまでに要るものをRemoteにすると、初回起動が「ダウンロード待ち」になります。 本体進行はローカル、追加要素はリモート の線引きが快適さを決めます
- CDNのキャッシュに注意: カタログの
.hashがCDNに古いままキャッシュされると、更新が届かない・逆に混ざる事故が起きます。配信基盤側のキャッシュ設定（無効化やパージ）は、本格運用の前に公式ドキュメントの「ContentUpdateWorkflow」とCDN側の資料で確認してください - 上げる順番はバンドル → カタログ →
.hash: アプリが更新の合図にするのは.hashです。先に.hashを上げると、アプリはまだ届いていないファイルを読みに行き、ロードに失敗することがあります - ロールバックは「前の出力を置き直す」: 更新に問題があった場合、サーバーの中身を前回の出力へ戻せばアプリは前の状態へ戻ります。そのためにも リリースごとの
ServerData出力と.binを世代管理 しておくのが安全です - ビルド全体の流れは別記事で: プラットフォームごとのビルド設定やビルド番号の管理は ビルド設定の記事 が土台になります
まとめ
- Addressable化は準備。「後から配信」は Remote設定・カタログ・更新ビルド の3点で成立する
- Build Path / Load Path はProfilesで管理し、開発用と公開用のURLをプロファイル切り替えにする
- アプリは カタログ（目次） しか知らない。Build Remote Catalogを有効にし、起動時に
CheckForCatalogUpdates→UpdateCatalogs - 更新は Update a Previous Build。初回の
addressables_content_state.binを必ず保管し、変える物と凍結する物をグループで分ける - オフラインでも遊べる範囲を設計し、更新失敗は「見送り」として本編を止めない
アプリ更新の審査を待たずに、明日の朝イチで新衣装を届けられる体制ができました。あなたのゲームで最初に「後から届けたいもの」は何ですか？
