Unity CI/CD入門｜GitHub Actionsでビルド・デプロイを自動化する方法

ゲームやアプリを作っていると、少し直したらすぐにビルドして動作確認したくなりますよね。でも毎回手作業でビルドしていると、待ち時間が長いうえに操作ミスも起こりやすくて、気づけば開発よりビルド作業に時間を取られていることも多いのではないでしょうか。

特にチームで開発していると、人によってビルド環境が微妙に違って「自分の環境では動くのに」というすれ違いが起きることもあります。こうした悩みは、UnityのCI/CDという仕組みを取り入れることで解消できる可能性があります。

この記事では、UnityのCI/CDにはどんな選択肢があるのか、そして自分の状況に合った方法をどう選べばいいのかを整理しながら、GitHub Actionsを使った具体的な導入手順まで丁寧にご紹介していきます。

---

UnityのCI/CDとは?CIとCDの違い

CI/CDという言葉は、実は2つの工程がセットになった略語です。ここを最初に整理しておくと、このあとの説明がぐっと分かりやすくなります。

CI(継続的インテグレーション)は、コードを変更するたびに自動でビルドやテストを実行してくれる仕組みのことです。誰かがコードを書き換えても、すぐに「ちゃんと動くビルドになっているか」を確認できます。

一方のCD(継続的デリバリー)は、そのビルドをテスト環境や本番環境にリリースするところまでを自動化する仕組みです。つまりCIが「作る・確かめる」担当で、CDが「届ける」担当というイメージですね。

この2つはセットで語られることが多いのですが、実際にはどちらか片方だけを導入することも可能です。たとえば「自動テストだけ回したい」ならCIだけでも十分ですし、リリースまで自動化したいならCDまで組み込む必要があります。

Unity開発の場合も同じで、まずは「ビルドとテストを自動化するCI」から始めて、慣れてきたら配布までを自動化するCDに広げていくという進め方が現実的です。

---

自分に合うCI/CD手法の選び方

UnityのCI/CDには、大きく分けて3つの選択肢があります。それぞれ得意なことが違うので、まずは全体像を比較しながら、自分の開発スタイルに近いものを見つけていきましょう。

	GitHub Actions(GameCI)	セルフホステッドランナー	Unity Build Automation
初期構築の手間	少ない	多い	少ない
ランニングコスト	無料枠あり	自前PC次第	プラン次第
ビルド速度	標準的	マシン次第で高速	標準的
プラットフォーム対応	幅広い	幅広い	幅広い
管理の柔軟性	設定はYAMLで管理	自由度が高い分、保守も必要	インフラ管理は不要

迷ったときは、次のような目安で選んでみてください。

• 個人開発や小規模チームなら、まずはGitHub Actions(GameCI)を無料枠から試してみる
• プロジェクトが大きく、頻繁にビルドを回すならセルフホステッドランナーでビルド速度を優先する
• インフラの管理にあまり時間をかけたくないならUnity Build Automationを検討する

ホステッドランナーとセルフホステッドランナーの違い

ここで少し混同しやすいポイントを整理しておきます。GitHub Actionsを使うとき、ビルドを実行してくれるコンピューターのことを「ランナー」と呼びます。

GitHubが標準で用意してくれているものがホステッドランナーで、特別な準備なしにすぐ使えるのが魅力です。ただし、マシンのスペックやストレージ容量には制限があるため、大規模なプロジェクトでは物足りなさを感じることもあります。

一方のセルフホステッドランナーは、自分で用意したパソコンをビルド専用のランナーとして登録する方法です。マシンスペックを自由に選べる分、環境構築やメンテナンスは自分たちで行う必要があります。

この記事では、まず取り組みやすいGitHub Actions(GameCI)を軸に、具体的な導入手順を解説していきます。

---

GitHub Actions導入前に知っておきたいこと

「YAMLもGitもよく分からないけど大丈夫かな」と不安に思う方もいるかもしれません。結論から言うと、細かい知識がなくても手順通りに進めれば設定はできますが、最低限の前提だけ先に押さえておくと理解がスムーズになります。

まずGitについては、コードの変更を記録して、GitHub上のリポジトリにpushする、という基本の流れだけ分かっていれば十分です。CI/CDは、このpushのタイミングをきっかけにして自動で動き出す仕組みだと考えてください。

次にGitHub Actionsのワークフローですが、これは「どんなときに」「何を実行するか」を書いたYAMLという形式の設定ファイルのことです。.github/workflowsというフォルダの中にこのファイルを置くと、GitHubが自動で読み込んで実行してくれます。

最後にUnityのバッチモードビルドという言葉も出てきます。これは、Unityエディタの画面を開かずに、コマンドだけでビルドを実行する方法のことです。人がボタンを押さなくてもビルドできるからこそ、自動化が成り立つというわけですね。

---

GitHub ActionsでUnityライセンスを設定する手順

GameCIを使ってUnityのビルドをGitHub Actions上で動かすには、まずUnityのライセンスを認識させる必要があります。ここが最初のハードルになりやすいので、順番に進めていきましょう。

ワークフローファイルを作成する

最初に、ライセンスをアクティベートするための設定ファイルを用意します。

1. UnityプロジェクトのリポジトリでGitHub上に .github/workflows というフォルダを作成する
2. その中に activation.yml などの名前でワークフローファイルを配置する

このファイルは、ライセンスの申請に必要な処理をGitHub Actionsに実行させるための指示書のような役割を持っています。

ライセンスリクエストファイル(alfファイル)を取得する

次に、Unity側にライセンスを申請するためのファイルを作ります。

1. 作成したワークフローファイルをデフォルトブランチにプッシュする
2. GitHub Actionsが自動的に実行される
3. 実行完了後、詳細画面の「Artifacts」から生成された alf ファイルをダウンロードする

Unityライセンス(ulfファイル)を取得する

ダウンロードしたalfファイルを使って、実際に使えるライセンスファイルを発行してもらいます。

1. ブラウザでUnityのライセンスアクティベーション専用ページにアクセスする
2. ダウンロード済みの alf ファイルをアップロードする
3. 用途に合ったライセンスを選択する
4. 発行された ulf ファイルをダウンロードする

取得したライセンスをGitHub Secretsに登録する

最後に、発行されたulfファイルの中身をGitHubに安全な形で登録します。

1. GitHubリポジトリの「Settings」から「Secrets」の登録画面を開く
2. Nameに UNITY_LICENSE と入力する
3. Valueに、ダウンロードした ulf ファイルの中身をそのままコピーして貼り付ける

ここまで完了すると、GitHub Actions上でUnityのライセンスを使ったビルドやテストが実行できる状態になります。

---

テスト・ビルドを自動実行する手順

ライセンスの設定が終わったら、いよいよテストとビルドを自動で走らせる段階です。ここでは、実際にワークフローを作って実行し、結果を確認するところまでを進めていきます。

テスト実行用のワークフローを作成する

まずは、コードの変更が正しく動くかを確認するためのテストを自動化します。

1. .github/workflows フォルダ内に、テスト実行用のワークフローファイルを作成する
2. ファイルをリポジトリにプッシュする
3. GitHub Actionsが自動的にテストを実行する

ビルド実行用のワークフローを作成する

テストの流れができたら、同じ要領でビルドを自動化するワークフローも用意します。

1. .github/workflows フォルダ内に、ビルド実行用のワークフローファイルを作成する
2. 対象プラットフォーム(AndroidやiOSなど)の設定を記述する
3. ファイルをリポジトリにプッシュし、ビルドを実行する

実行結果を確認する

ワークフローが動いたあとは、結果をきちんと確認する習慣をつけておきましょう。

• 「Artifacts」から、ビルドされた成果物をダウンロードして確認できる
• 「Test Results」から、テストが成功したか失敗したかを確認できる

もしビルドが失敗してしまった場合、原因がエディタ側の設定なのか、ワークフローの記述なのか切り分けが必要になります。ビルドがうまくいかない原因を一つずつ確認したい場合は、こちらの記事も参考にしてみてください。

ビルドが正常に完了することを確認できたら、あとは開発を進めるたびにコードをプッシュするだけで、テストとビルドが自動的に走る状態が整います。手作業でビルドしていたころと比べると、確認までのスピード感がかなり変わってくるはずです。

---

ビルド時間を短縮するキャッシュ設定

GitHub Actionsでビルドを自動化できても、実行のたびに毎回時間がかかっていると、せっかくの自動化のメリットを感じにくくなってしまいます。特にUnityはプロジェクトが大きくなるほど、ビルドにかかる時間も伸びていく傾向があります。

そこで役立つのが、ビルドに必要なデータを使い回すキャッシュという考え方です。UnityプロジェクトにはLibraryフォルダというインポート済みアセットの情報が保存されている場所があり、ここをキャッシュとして保持しておくことで、次回以降のビルドで一から読み込み直す手間を省けます。

具体的には、ワークフローファイルの中でLibraryフォルダをキャッシュ対象として指定しておく方法が一般的です。一度ビルドを実行してキャッシュが作られると、2回目以降のビルドではその情報を再利用できるようになります。

なお、キャッシュはあくまで「同じような状態のビルドを繰り返すときの時短」が目的です。

---

GitHub Actions以外が向くケース

ここまでGitHub Actions(GameCI)を中心に紹介してきましたが、プロジェクトの状況によっては他の選択肢の方が合っていることもあります。改めて、どんなときに乗り換えを検討すべきか整理しておきましょう。

セルフホステッドランナーが向くケース

プロジェクトが大きくなり、ビルドのたびに待ち時間がストレスになってきた場合は、セルフホステッドランナーが候補になります。自前のパソコンをビルド専用として登録することで、マシンスペックを自分たちの都合に合わせて選べるようになります。

ただし、その分ビルド用のパソコンを用意して常時稼働させておく必要があり、環境構築やメンテナンスの手間も発生します。頻繁にビルドを回すチームであれば、その手間を差し引いても速度面のメリットが大きいと感じやすい選択肢です。

Unity Build Automationが向くケース

一方で、インフラの管理そのものにあまり時間をかけたくない場合は、Unity Build Automationというクラウド型のサービスが選択肢になります。ローカルにビルド環境を用意しなくても、クラウド上でクロスプラットフォーム向けのビルドを実行できる点が特徴です。

どの方法を選ぶ場合も、いきなり大掛かりな仕組みを組む必要はありません。

---

よくある質問