【Unity + DevOps】CI/CDを活用してビルド・デプロイを自動化する方法

Unityでゲームやアプリを開発していると、こんな瞬間はありませんか？

「ちょっと修正しただけなのに、またビルドか…」
「ビルド中はUnityエディタが使えなくて、作業が止まる…」
「設定ミスして、やり直し。もう一回ビルド……」

私自身、Unityを使った個人開発やチーム開発をしてきて、この“ビルド地獄”に何度も心を折られてきました。 特にプロジェクトが大きくなったり、WebGLやAndroidなど複数プラットフォームを扱い始めると、手動ビルドは一気に限界がきます。

そこで登場するのが、CI/CD（継続的インテグレーション / 継続的デリバリー）、いわゆるDevOpsの考え方です。

「CI/CDって、チーム開発や大規模プロジェクト向けでしょ？」
「Unityでやるのは難しそう……」

そう思われがちですが、実は最近のUnity開発では、個人開発でもCI/CDを導入するメリットがかなり大きいんです。 しかも、GitHub Actionsといった無料で始められる仕組みを使えば、思っているよりずっと現実的に導入できます。

この記事では、DevOpsやCI/CDにあまり詳しくない方でも大丈夫なように、

• Unity開発で、なぜCI/CDが役立つのか
• Unity Cloud Build以外に、どんな選択肢があるのか
• GitHub Actionsを使って、自動ビルド・テスト・デプロイをどう構築するのか

といったポイントを、できるだけ実践目線で、噛み砕いて解説していきます。

「毎回の手動ビルドから解放されたい」
「プッシュしたら勝手にビルドされる環境を作りたい」

そんな方は、ぜひこのまま読み進めてみてください。 Unity開発の作業フローが、かなりラクになりますよ🙂

---

結論：Unity CI/CDでできること・できないこと

まず最初に、この記事の結論からお伝えします。

UnityにCI/CDを導入すると、開発フローは確実にラクになります。 ただし、「何でもかんでも自動で解決！」という魔法ではありません。

ここを最初に整理しておくと、後半の内容がグッと理解しやすくなります。

Unity CI/CDで「できるようになること」

• GitHubにpushするだけで自動ビルドされる
• EditMode / PlayModeの自動テストを毎回実行できる
• WebGLやAndroid向けの成果物を自動生成できる
• ビルド手順・設定をコードとして固定できる
• チーム開発でも「誰の環境でも同じ結果」を再現できる

特に大きいのは、「人の手を介さず、同じ手順で必ずビルドされる」点です。 これだけで、ヒューマンエラーは一気に減ります。

Unity CI/CDで「できない・注意が必要なこと」

• 初期構築は少しだけ手間がかかる
• iOSビルドはmacOS環境が必須でコストが上がりやすい
• Unity特有のライセンス設定で詰まりやすい
• CI/CDを入れても、設計やコード品質が不要になるわけではない

特に初心者の方が誤解しやすいのが、
「CI/CDを入れれば、開発が全部うまくいく」わけではない、という点です。

CI/CDはあくまで開発を支える仕組み。 設計がグチャグチャなままだと、ビルドが自動化されても不具合は量産されます。

それでも導入する価値がある理由

それでも私がUnity CI/CDをおすすめする理由は、とてもシンプルです。

「一度作れば、ずっと自分を助け続けてくれる」からです。

最初は「ちょっと面倒そう」と感じるかもしれません。 でも、pushするだけでビルドが終わり、成果物まで揃っている環境を一度体験すると、 もう手動ビルドには戻れなくなります。

---

Unity開発でCI/CDが必要になる理由

「正直、今は手動ビルドでも困ってないんだけど……」

そう感じている方も多いと思います。 実はこれ、Unity開発あるあるなんですよね。

ただ、プロジェクトが少しずつ成長してくると、手動ビルドは確実にボトルネックになります。 ここではまず、その理由を整理してみましょう。

手動ビルド運用の限界

Unityの手動ビルドには、地味だけど効いてくる問題がいくつもあります。

• ビルド中はUnityエディタが占有され、作業が止まる
• プラットフォーム切り替えや設定変更の操作ミスが起きやすい
• 「前は通ったビルドが、なぜか今日は通らない」現象
• チーム開発では人ごとにビルド結果が違う

特にチーム開発や長期運用になると、

「〇〇さんのPCではビルドできる」
「自分の環境だとエラーが出る」

といった状況が、かなりの確率で発生します。 この調査に使う時間、実はかなりもったいないんですよね。

ここで重要になってくるのが、Gitでプロジェクトを正しく管理できているかです。

CI/CDは、Gitを前提とした仕組みなので、
.gitignoreの設定や、どこまでをリポジトリに含めるかがとても重要になります。

このあたりがまだ不安な方は、先にこちらの記事を一度チェックしておくと安心です。

CI/CDを導入すると何が変わるのか

CI/CDを導入すると、開発フローは次のように変わります。

• GitHubにpushすると、自動でビルドが走る
• 毎回同じ環境・同じ手順でビルドされる
• テスト失敗・ビルド失敗をすぐ検知できる
• 「ビルドする人」がいなくなる

ここでのポイントは、「人の作業」を「仕組み」に置き換えることです。

一度仕組みを作ってしまえば、

「今日は誰がビルドする？」
「設定これで合ってる？」

といった会話自体が不要になります。

CI/CDは派手な機能ではありませんが、 開発のストレスを静かに、確実に減らしてくれる存在なんです。

---

Unity DevOpsの主な選択肢と考え方

「UnityでCI/CDをやる」と聞くと、まず思い浮かぶ選択肢はいくつかあります。 ただし、全部を同じ目線で比較すると混乱しやすいので、ここでは考え方を整理しながら見ていきます。

結論から言うと、個人開発〜小規模チームであれば、

「GitHub Actions + GameCI」

が、最もバランスの良い選択肢になりやすいです。

GitHub Actions（＋ GameCI）

GitHub Actionsは、GitHubに標準で用意されているCI/CD機能です。 Unity専用ではありませんが、GameCIというコミュニティ製のActionを使うことで、Unity向けのCIがとても簡単に構築できます。

• 無料枠があり、個人開発でも始めやすい
• YAMLで設定を管理でき、再現性が高い
• Unity以外のプロジェクトにも応用できる
• WebGL / Windows / Androidなど幅広く対応

特に大きいのが、「設定そのものがコードになる」点です。 ビルド手順が属人化せず、「このリポジトリを見れば全て分かる」状態を作れます。

一方で、最初はYAMLの記述やライセンス設定で戸惑うこともあります。 ただ、これは一度乗り越えれば終わりの壁です。

Unity Build Automation（旧 Unity Cloud Build）

Unity公式が提供しているCIサービスが、Unity Build Automationです。

• Unity Editorとの連携が簡単
• GUI操作中心で設定できる
• Unity公式サポートがある安心感

「とにかく簡単に自動ビルドしたい」という場合には、かなり魅力的です。

ただし、

• 細かいカスタマイズがしづらい
• 配布（デプロイ）部分は用途が限られる
• プランによってはコストがかかる

といった点もあります。 開発フロー全体を自分で制御したい人には、少し物足りなく感じるかもしれません。

Azure DevOps / Jenkins などは誰向け？

これらは、

• 大規模チーム
• 社内インフラと連携したい
• オンプレミス環境が必須

といったケース向けです。

個人開発や少人数チームでは、構築・運用コストの方が重くなりがちなので、 本記事では深掘りしません。

迷ったらこの考え方でOK

選択に迷ったら、次の基準で考えるのがおすすめです。

• まずは無料で始められるか
• 設定がコードとして残るか
• 将来、拡張しやすいか

この条件を満たしやすいのが、GitHub Actions + GameCIです。

---

実践：GitHub ActionsでUnity CIを構築する流れ

ここからは、いよいよ実践編です。

「CI/CDって設定が難しそう…」と感じる方も多いのですが、 最初に全体の流れをつかんでしまえば、意外とシンプルに見えてきます。

この章では、細かいYAMLの書き方に入る前に、 GitHub ActionsでUnityのCIがどう動くのかを俯瞰していきます。

まずは全体像をつかもう

GitHub Actionsを使ったUnity CIの基本的な流れは、次のとおりです。

1. UnityプロジェクトをGitHubにpushする
2. pushをトリガーにGitHub Actionsが起動
3. Unityを起動してテストを実行
4. 指定したプラットフォーム向けにビルド
5. 生成された成果物を保存（Artifacts）

ポイントは、自分が何もしなくても勝手に進むところです。

一度設定してしまえば、

「pushしたら、あとはコーヒー飲んで待つだけ」

という状態を作れます。

ローカルビルドとの一番の違い

ローカルでのビルドと、CI環境でのビルドの違いは、

「毎回、まっさらな環境から始まる」

という点です。

ローカル環境では、

• 以前のLibraryが残っている
• Editorの状態が影響する
• 個人ごとの環境差分がある

といった要素が、知らないうちにビルド結果へ影響します。

一方、GitHub Actionsでは毎回クリーンな環境でビルドされるため、

• 再現性が高い
• 「なぜか通る／通らない」が起きにくい

というメリットがあります。

CI構築で最初に意識しておくこと

ここで大事なのは、最初から完璧を目指さないことです。

おすすめの進め方は、

• まずは自動ビルドだけを通す
• 次にテストを組み込む
• 最後にデプロイを自動化する

という段階的な導入です。

いきなり全部やろうとすると、 ライセンス・YAML・エラー対応で確実に混乱します。

---

リポジトリ準備と.gitignore

GitHub ActionsでUnity CIを回すうえで、 最初にやっておくべき超重要ポイントが「リポジトリの準備」です。

ここを雑にすると、

「CIは動いているのに、なぜかビルドが失敗する」

という、かなりしんどい状態に陥りやすくなります。

UnityプロジェクトはそのままGit管理しない

UnityプロジェクトをGitで管理する際、 すべてのフォルダをコミットしてはいけません。

特に注意したいのが、次のフォルダです。

• Library
• Temp
• Obj
• Build / Builds

これらはUnityが自動生成するもので、 環境差分やビルド失敗の原因になりやすい部分です。

CI環境では、これらを毎回クリーンな状態から再生成するのが基本になります。

.gitignoreがCIの安定性を左右する

.gitignoreは、「Git管理しないファイル・フォルダ」を定義する設定ファイルです。

Unity用の.gitignoreが正しく設定されていないと、

• 不要なファイルが大量にコミットされる
• ローカル依存のデータがCIに影響する
• 原因不明のビルドエラーが発生する

といったトラブルが起きやすくなります。

「CIを入れたら急にビルドが壊れた…」というケースの多くは、 実は.gitignoreの不備が原因だったりします。

Unity向けの.gitignore設定や、 Git管理の基本をしっかり押さえたい方は、こちらの記事も参考になります。

リポジトリ構成は「シンプル」が正解

CI用のリポジトリ構成で意識したいのは、

「誰が見ても、何が入っているか分かること」

です。

• Assets / Packages / ProjectSettings は必ず含める
• CI設定は .github/workflows にまとめる
• 手動ビルド用のスクリプトは分離する

この状態を作っておくと、 GitHub Actionsの設定も、その後のトラブル対応も、かなり楽になります。

---

Unityライセンス認証とSecrets管理（最大のつまずきポイント）

ここは、Unity CI/CDで一番つまずきやすいポイントです。

「YAMLは書けたのに、なぜかビルドが通らない…」
「エラーを見ても、何が悪いのか分からない…」

こういったケースの多くは、Unityライセンス認証まわりが原因になっています。

なぜCI環境でライセンス認証が必要なのか

ローカルPCでUnityを使う場合、 Unity Hubでサインインしていれば、ライセンスは自動的に有効化されています。

しかし、GitHub ActionsのようなCI環境では、

• Unityは毎回クリーンな環境で起動される
• Unity Hubも存在しない
• 当然、ライセンス情報も何も入っていない

という状態からスタートします。

そのため、CI上でUnityを起動するには、 「この環境でUnityを使っていいですよ」というライセンス認証を、 明示的に行う必要があります。

GitHub Secretsで管理する情報

Unity CIでは、ライセンス情報やアカウント情報を GitHub Secretsという仕組みを使って安全に管理します。

最低限、次の情報を登録するケースが多いです。

• UNITY_LICENSE：Unityライセンスファイル（.ulf）の内容
• UNITY_EMAIL：Unityアカウントのメールアドレス
• UNITY_PASSWORD：Unityアカウントのパスワード

これらは、リポジトリの

Settings → Secrets and variables → Actions

から登録します。

重要なのは、これらを絶対にリポジトリに直接書かないことです。

Secrets管理でやってはいけないこと

初心者の方がやりがちなNG例がこちらです。

• YAMLにメールアドレスやパスワードを直書きする
• ライセンスファイルをGit管理してしまう
• Secretsの値をログに出力してしまう

これらは情報漏洩のリスクが非常に高く、 最悪の場合、アカウント停止などにつながる可能性もあります。

CI/CDは便利な反面、 セキュリティ意識がないと危険でもある、という点は覚えておいてください。

ここを越えれば、かなり楽になる

正直に言うと、Unity CI/CDは

「ライセンス設定を越えたら勝ち」

です。

ここさえ正しく設定できれば、 あとはYAMLの調整やビルド設定を少しずつ整えていくだけになります。

---

YAMLで書くCIワークフローの中身

ライセンス認証ができたら、次はいよいよCIの本体です。

GitHub Actionsでは、.github/workflows 配下に置く YAMLファイルで「何を、どんな順番で実行するか」を定義します。

最初に言っておくと、 YAMLを完璧に理解する必要はありません。

大事なのは、

「この行は、何をしているのか」

がざっくり分かることです。

最低限押さえておきたいワークフロー構成

Unity CIで、まず必要になる構成要素は次の5つです。

1. リポジトリのチェックアウト
2. キャッシュの設定
3. 自動テストの実行
4. Unityビルド
5. 成果物（Artifacts）の保存

この流れを毎回、同じ手順で実行するのがCIの役割です。

① リポジトリのチェックアウト

まずは、GitHub上のコードをCI環境に持ってきます。

これはほぼ定型で、actions/checkout を使います。

ここでやっているのは、

「いつも自分がローカルで clone / pull しているのと同じこと」

だと思ってOKです。

② Libraryフォルダのキャッシュ

Unity CIでビルド時間を大きく左右するのが、Libraryフォルダです。

毎回ゼロから生成すると時間がかかるため、 actions/cache を使ってキャッシュするのが一般的です。

ただし、

• Unityバージョンを変えた
• 大きくアセット構成を変えた

といった場合は、キャッシュが原因でビルドが壊れることもあります。

「怪しかったらキャッシュを疑う」 これはUnity CIあるあるなので、覚えておくと助けになります。

③ 自動テストの実行

GameCIには、EditMode / PlayModeテストを実行するActionが用意されています。

ここでテストを通しておくことで、

• 明らかに壊れている変更を早期に検知できる
• 「動いたと思ったら実は壊れてた」を防げる

というメリットがあります。

CI上でテストが落ちたときは、 ログを読む力がとても重要になります。

Unityのログの見方や、エラーの追い方に不安がある場合は、 こちらの記事も合わせて参考にしてみてください。

④ Unityビルドの実行

テストが通ったら、いよいよビルドです。

game-ci/unity-builder を使うことで、

• Windows
• WebGL
• Android

といったプラットフォーム向けのビルドを、 ほぼ設定だけで実行できます。

「どのプラットフォームをビルドするか」は、 YAML内のパラメータで明示的に指定します。

⑤ 成果物（Artifacts）の保存

ビルドが終わっただけでは、CIとしては少し不十分です。

生成された成果物を あとからダウンロードできる形で保存しておくことで、

• テストプレイ用に配布できる
• 過去ビルドと比較できる
• デプロイ処理につなげられる

といった運用が可能になります。

ここまでできれば、 「push → 自動ビルド → 成果物生成」 というCIの基本形は完成です。

---

CD編：ビルド後のデプロイ自動化

CIで「自動ビルド」までできるようになると、 次にやりたくなるのがデプロイ（配布）の自動化です。

ここまで来ると、

「pushしたら、テストもビルドも配布も終わっている」

という、かなり快適な開発体験が手に入ります。

この章では、Unity開発で特に使われることが多い

• WebGLの自動デプロイ
• Androidビルドの自動配布

この2パターンに絞って解説します。

WebGLの自動デプロイ（GitHub Pages / Netlify）

WebGLは、CI/CDとの相性がとても良いプラットフォームです。

理由はシンプルで、

• ビルド成果物が静的ファイル
• 署名やストア審査が不要
• アップロードするだけで公開できる

という特徴があるからです。

GitHub Actionsでは、

• CIでWebGLビルド
• Artifactsとして出力
• gh-pagesブランチにpush

といった流れを組むことで、 自動的に最新バージョンを公開できます。

Netlifyを使う場合も考え方は同じで、 CI完了後にNetlify CLIを使って成果物をアップロードします。

ただし、WebGLはCIに乗せると

「ローカルでは動くのに、CIだと失敗する」

という落とし穴にもハマりやすいです。

WebGL特有のビルドエラーや文字化けなどに遭遇した場合は、 こちらの記事も参考になります。

Androidの自動配布（Firebase App Distribution）

Android向けのビルドは、 「ストア公開前の配布」を自動化すると特に効果が高いです。

おすすめなのが、Firebase App Distributionを使った配布フローです。

CIでAndroidビルド（APK / AAB）を作成し、

• Firebase CLIをインストール
• サービスアカウントキーをSecretsに登録
• コマンドで自動アップロード

という流れを組むことで、

「pushしたら、テスターに最新ビルドが届く」

という状態を作れます。

これにより、

• 手動アップロードの手間がなくなる
• 配布漏れ・配布ミスがなくなる
• テストサイクルが一気に早くなる

といったメリットがあります。

最初から完璧なCDを目指さなくてOK

ここで一つ、大事な考え方があります。

CDは「余裕が出てから」で問題ありません。

まずは、

• CIで自動ビルドできる
• 成果物を誰でも取得できる

この状態を作るだけでも、 開発効率は大きく変わります。

---

運用フェーズで効いてくる最適化ポイント

CI/CDは「作って終わり」ではありません。 むしろ本番は、運用し始めてからです。

ここでは、Unity CI/CDを回し続ける中で あとから効いてくるポイントをまとめておきます。

ビルド時間を短縮するためのキャッシュ戦略

Unity CIで一番時間を食いやすいのが、 やはりLibraryフォルダの生成です。

キャッシュを有効にすることでビルド時間は大きく短縮できますが、

• Unityバージョンを上げた
• Render Pipelineを切り替えた
• 大量のアセットを追加・削除した

といったタイミングでは、キャッシュが原因でビルドが壊れることもあります。

そんなときは、

「一度キャッシュを捨てる」

これだけで解決するケースも少なくありません。

並列ビルド（Matrix）で待ち時間を減らす

Windows / WebGL / Android など、 複数プラットフォームをビルドする場合は、

Matrix戦略

を使うことで、ビルドを並列実行できます。

これにより、

• ビルド待ち時間の短縮
• プラットフォーム差分の早期発見

といったメリットがあります。

ただし、GitHub Actionsの無料枠では 同時実行数や実行時間に制限がある点には注意が必要です。

iOSビルドはコストと相談しよう

iOS向けビルドは、 どうしてもmacOSランナーが必須になります。

GitHub ActionsのmacOS環境は、

• 実行時間の消費が大きい
• 無料枠がすぐ減る

という特徴があるため、

「iOSだけは手動 or 別CI」

という選択も、現実的な判断です。

CIログを「読める人」になると強い

CI/CDを安定運用できるかどうかは、

ログを読めるかどうか

に大きく左右されます。

エラーが出たときに、

• どのステップで落ちたか
• Unityのログに何が出ているか

を冷静に追えるようになると、 CIは一気に「怖くない存在」になります。

---

おすすめ学習リソース（理解が一気にラクになる）

ここまで読んで、

「CI/CDの流れは分かったけど、途中で出てくる用語や設定がちょっと難しい…」

と感じた方もいるかもしれません。

正直に言うと、それはとても自然な感覚です。

UnityのCI/CDでは、

• Unityプロジェクトの構造
• C#やビルド設定の基礎知識
• エディタと実行環境の違い

といった基礎知識の理解度が、そのまま設定の理解度に直結します。

そこで、CI/CDに取り組む前後で手元にあると、 かなり助けになる一冊を紹介します。

Unityゲーム プログラミング・バイブル 2nd Generation

✅ Amazonでチェックする
✅ 楽天でチェックする

この本は、いわゆる「チュートリアル本」ではなく、

Unity開発の辞書・リファレンス的な立ち位置

の一冊です。

CI/CDを設定していると、

• この設定、Unityのどこに影響してるんだっけ？
• ビルド時に何が実行されているの？
• そもそも、このエラーはUnityの仕様？

といった疑問が、必ず出てきます。

そういうときに、この本があると 「調べる → 腑に落ちる」までの距離が一気に短くなります。

最初から全部読む必要はありません。 分からないところをピンポイントで引けるのが強みです。

CI/CDは「設定を写す」だけでも動きますが、 理解しながら触れるようになると、トラブル対応力が段違いになります。

その土台作りとして、 こういった体系的なリファレンスを1冊持っておくのは、かなりおすすめです。

---

よくある誤解・注意点

ここまで読んで、「よし、CI/CD入れてみよう！」と思った方に向けて、 事前に知っておいてほしい注意点をまとめておきます。

このあたりを知らずに進めると、 「思ってたのと違う…」となりやすいポイントでもあります。

CI/CDを入れれば、すべて自動で安心になる？

これはよくある誤解です。

CI/CDは、

• ビルド手順を自動化する
• ミスを減らす
• 問題に早く気づく

ための仕組みであって、

バグを勝手に直してくれるわけではありません。

設計が破綻していたり、 テストを書いていなければ、そのまま壊れた状態でビルドされます。

最初から完璧な構成を目指さなくていい

CI/CD導入で一番やりがちな失敗が、

「最初から全部自動化しようとする」

ことです。

おすすめなのは、

• まずは自動ビルドだけ
• 次にテストを追加
• 余裕が出たらデプロイ

という段階的な導入です。

小さく成功体験を積み重ねた方が、 結果的に長く使えるCI/CDになります。

CIが落ちた＝悪いこと、ではない

CIが失敗すると、 つい「失敗した…」とネガティブに感じがちですが、

CIが落ちるのは、むしろ正常

です。

問題がある変更を、 本番に行く前に止めてくれたという意味では、 CIはきちんと仕事をしています。

「CIが落ちた＝修正ポイントが分かった」 このくらいの感覚で向き合うと、ストレスも減ります。

CI/CDは「開発を楽にするための投資」

最初の設定には、多少の時間と学習コストがかかります。

ただし、その投資は、

プロジェクトが長く続くほど、必ず回収できます。

---

まとめ

今回は、Unity開発におけるCI/CD（DevOps）導入の考え方から実践までを、一通り解説してきました。

内容を振り返ると、ポイントは次のとおりです。

• Unity開発でも、CI/CDは個人開発から十分に効果がある
• 手動ビルドは、プロジェクトが成長するほど限界がくる
• GitHub Actions + GameCIは、現実的で始めやすい選択肢
• 最初は「自動ビルドだけ」でも導入する価値がある
• CI/CDは魔法ではなく、開発を支える仕組み

私自身の経験としても、 CI/CDを入れてから一番変わったのは、

「ビルドするかどうかを考えなくなった」

ことでした。

pushすれば勝手にビルドされ、 問題があればCIが教えてくれる。

この状態を一度体験すると、 「なぜ今まで手動でやってたんだろう？」と感じるようになります。

もし今、

「ちょっと面倒そうだな…」
「今のプロジェクトには早いかも…」

と感じているなら、 まずは自動ビルド1本だけでも試してみてください。

それだけでも、Unity開発のストレスは確実に減ります🙂

---

参考文献・参考リンク

• Unity公式：CI/CD for Unity
• Unity公式（日本語）：Unity CI/CD ソリューション
• Unity Documentation：Automation（Unity Services）
• Unity DevOps Documentation
• Anchorpoint：GitHub Actionsを使ったUnity CI/CD構築ガイド
• DEV.to：Automating Unity Builds with GitHub Actions
• Codemagic Blog：なぜUnityゲーム開発にCI/CDを使うのか（日本語）
• GitHub：Unity CI Templates（Avalin）
• GitHub Marketplace：Setup Unity Action
• GameCI：unity-builder（公式）
• GitHub Marketplace：Unity Build Action
• Qiita：GitHub ActionsでUnityプロジェクトをビルドする方法
• Qiita：Unity × GitHub Actions CI構築メモ
• Stack Overflow：Unity Project Structure for Cloud Build / GitHub Actions
• Reddit：Unity開発者は何でビルド自動化している？
• YouTube：Unity CI/CD with GitHub Actions 解説動画
• YouTube：GameCIを使ったUnity自動ビルドチュートリアル

---

よくある質問（FAQ）