Unity Addressablesを別リポジトリで運用する��
最終更新：
orika_ex_miyako 2026年06月15日(月) 11:00:46履歴
Unity プロジェクトのリポジトリと Addressables リポジトリを分離する 
はじめに
Unity でゲーム開発を行う場合、多くのプロジェクトでは Git(Github) を利用してソースコードやアセットを管理します。
一般的には、
GameProject ├ Assets ├ Prefabs ├ Resources ├ Scripts ├ Scenes ├ Packages ├ ProjectSettings
のように、ゲームのソースコードや各種リソース(音楽、画像、Prefab など)の設定までを 1つの Git のリポジトリで管理します。
もちろんこの方法でもゲーム開発は可能です。
しかし、Addressables を利用して運用を始めると、別の問題が見えてきます。
Addressables をゲームプロジェクトと同じリポジトリで管理する場合
Addressables はゲームに含まれる画像や音声、動画などのデータをアプリ本体とは別に管理し、アプリ外部のサーバーから配信することができる仕組みです。
これにより例えば、スマホゲーム開始時の追加ダウンロードなどの仕組みを提供することが可能です。
例えば、
＜配信データ例＞
・新しいイベント画像を追加する ・ボイスデータを追加する ・バランス調整用のデータを更新する
といったものです。
仮にこれらに変更であった場合、ゲーム本体(ソースコードなど)の変更はないため、本来であればストアへの更新手続きをしなくても配信できます。
しかし、Addressables の成果物をゲームプロジェクトと同じリポジトリで管理している場合、
・ゲーム本体 ・Addressables の配信データ
が１つの Git のリポジトリに混在することになります。
そのため、「Addressables のデータだけ更新したい」というケースであっても、それは「ゲーム本体の更新」として扱う必要が出て来てしまいます。
ゲーム本体の更新にはストア申請が必要になる
その状態の何が問題なのか、という部分ですが、スマートフォン向けゲームの場合、ゲーム本体を更新するためには、App Store や Google Play への申請が必要になります。
そのため、「画像を 1 枚差し替えただけ」「ボイスを追加しただけ」といった小さな更新でも、ストアへの申請や審査を経る必要があります。
つまり、【ゲーム本体と配信アセットでは、更新頻度が違う】ということが分かってきます。
すべてを１つのリポジトリで扱うと、更新頻度が高いがストアへの申請が不要である配信アセットの更新だけであっても、ストアへの申請が発生してしまう状態になる訳です。
これは運用を続けるほど手間が大きくなっていくため、問題として浮彫りになってきます。
データ更新のたびにアプリ更新が必要になるのは無駄な作業であるので、これは避けたい所です。
Addressables 配信用のリポジトリを分離する
そこでよく採用されるのが、【ゲームプロジェクト用リポジトリと、Addressables 配信用リポジトリを分離する構成】です。
例えば、【Unity の Project】と【Addressables Content】のように、用途ごとに Git リポジトリを分けて管理します。
ゲーム本体は従来通りストアへ配信し、Addressables の成果物だけを別のリポジトリで管理して CDN へアップロードします。
Addressables 配信先としては、
・Unity CCD(ストレージ + CDN) ・AWS S3(ストレージ) + CloudFront(CDN)
などの構成が一般的です。
次回
次は Addressables 配信用の GitHub リポジトリを作成し、GitHub Actions を利用して S3 へ自動配信する仕組みを構築する方法を説明します。
→ Unity Addressablesを別リポジトリで運用する��
コメントをかく