Unity Gaming Services だけでは足りない
ゲームバックエンド領域を、GS2 はどう補うのか

UGS は Unity 連携に強いサービス群、
GS2 はゲームサーバー機能を網羅する BaaS

UGS は、Unity で作られたゲームにオンライン機能を追加するためのサービス群です。たとえば Cloud Save はプレイヤーデータやゲームデータをクラウドに保存するサービス、Leaderboards はスコアの保存・ソート・ランキングを扱うサービス、Relay は専用ゲームサーバーを用意せずにプレイヤー間接続を中継するサービスとして提供されています。

一方で GS2 は、ゲーム開発で頻出するバックエンド機能を、ゲームの概念に沿ったサービスとして提供します。たとえば、次のような領域をカバーしています。

UGS でも多くの領域は構築できます。しかし、UGS は比較的「汎用的な部品」を提供する設計です。実際のタイトルで必要になるゲーム内経済、報酬、ガチャ、ショップ、クエスト進行、補填配布、ランキング報酬などは、Cloud Code、Cloud Save、Economy、Remote Config などを組み合わせて実装する形になりやすくなります。GS2 は、これらをゲーム向けの機能単位として最初から提供します。

つまり GS2 は、単なるクラウド保存やサーバーレス実行環境ではありません。ゲームサーバーで毎回作ってきた機能を、ゲーム開発者が扱いやすいサービスとして提供するバックエンドです。

UGS だけでは残りやすい課題

UGS は便利なサービス群ですが、実際のゲーム開発では次のような課題が残ることがあります。

1. 「データを保存する」ことと「ゲーム機能として成立する」ことは違う

UGS の Cloud Save は、プレイヤーデータやゲームデータをクラウドに保存するためのサービスです。プレイヤーが端末を変えたり、ゲームを再インストールしたりした場合のデータ損失を軽減できることが説明されています。

しかし、ゲームバックエンドに必要なのは、単にデータを保存することだけではありません。たとえば、インベントリひとつを取っても、実際には次のような仕様が必要になります。

• アイテムの種類ごとの所持数管理
• スタック可能アイテムと非スタックアイテムの扱い
• 所持上限
• 装備中アイテムの制約
• アイテム付与時の重複処理
• 所持上限を超えた場合のギフトボックス送付
• 消費、交換、売却、強化、合成との連携
• 不正なクライアントリクエストの防止
• 二重実行やリトライ時の整合性確保

Cloud Save を使えば、これらを実装するための保存先は用意できます。しかし、インベントリ機能そのものはタイトル側で設計する必要があります。

GS2 では、インベントリはインベントリとして、課金通貨は課金通貨として、ショップはショップとして、ガチャはガチャとして扱えます。ゲーム開発者は、低レベルなデータ保存設計ではなく、ゲームデザインに近い概念でバックエンドを構築できます。

2. Economy はあるが、ゲーム内経済全体を組み立てる必要は残る

UGS には Economy があります。通貨やアイテムといった概念を扱えるため、ゲーム内経済の一部を構築できます。しかし、実際のゲーム内経済は Economy 単体では完結しません。たとえば、次のような処理が必要になります。

• 課金通貨を消費してガチャを引く
• ガチャ結果に応じて複数アイテムを付与する
• 重複アイテムを別素材に変換する
• ショップで購入回数制限を管理する
• イベント期間中だけ商品を切り替える
• クエスト達成報酬を一度だけ受け取れるようにする
• ログインボーナスを日付や連続ログインに応じて配布する
• 補填アイテムを全プレイヤーまたは対象者だけに配布する
• 受け取り期限つきのギフトを管理する

UGS でこれらを実現する場合、多くは Economy、Cloud Code、Cloud Save、Remote Config、Leaderboards などを組み合わせた実装になります。Cloud Code はサーバー側でゲームロジックを実行でき、Unity サービスと連携できるため強力ですが、最終的なゲーム仕様の設計・実装・テストはタイトル側に残ります。

GS2 では、ガチャ、ショップ、クエスト、ログインボーナス、ギフトボックス、報酬などが、ゲーム向けの機能として提供されています。そのため、「UGS の複数サービスをどう組み合わせて作るか」ではなく、「GS2 のどの機能を使ってゲーム仕様を表現するか」という発想で開発できます。

3. ガチャ、報酬、ギフトボックスのような運用機能は個別実装になりやすい

ライブサービス型ゲームでは、リリース後の運用で必要になる機能が多数あります。たとえば、次のようなものです。

• 期間限定ガチャ
• ピックアップガチャ
• ステップアップガチャ
• ショップ更新
• ログインボーナス
• イベント報酬
• ランキング報酬
• メンテナンス補填
• 障害時の個別補填
• ギフトボックス
• ニュース
• バージョンチェック

UGS でも、Cloud Code や Remote Config などを使えば、これらの運用機能を構築できます。しかし、ガチャ、補填、ギフトボックス、報酬配布といった運用機能が、ゲーム向けの高レベルなサービスとして最初から揃っているわけではありません。その結果、タイトルごとに似たような実装を繰り返すことになりがちです。

GS2 は、こうしたライブサービス運用でよく必要になる機能を、あらかじめゲーム向けサービスとして提供します。ゲームリリース後に必要になる運用まで見据えて、短期間でバックエンドを構築できます。

4. マッチメイキングやロビーも、ゲーム全体の進行と一体で設計する必要がある

UGS には Lobby、Relay、Matchmaker などのマルチプレイ関連サービスがあります。Relay は、専用ゲームサーバーを用意せずに Relay サーバーをプロキシとして使い、プレイヤー間接続を成立させるサービスとして説明されています。

しかし、実際のマルチプレイゲームでは、マッチメイキングやロビーだけが独立して存在するわけではありません。マッチングの前後には、次のような処理が必要になります。

• プレイヤーのレートやランクを参照する
• 所持キャラクターや編成情報を参照する
• マッチ成立後にロビーへ遷移する
• ロビー内でチャットや準備状態を管理する
• ゲーム中にリアルタイム通信を行う
• 対戦結果を保存する
• ランキングやシーズン成績へ反映する
• クエストやミッション進行を更新する
• 勝敗に応じた報酬を配布する

これらは、マッチメイキング、ロビー、リアルタイム通信、ランキング、報酬、インベントリ、クエストなどの機能が密接に関係します。

GS2 は、マッチメイキング、ロビー、チャット、リアルタイム通信だけでなく、ランキング、報酬、インベントリ、クエスト、ショップ、ガチャなども提供しています。そのため、マルチプレイ部分だけを別サービスとして扱うのではなく、ゲーム全体のバックエンドとして一貫して設計できます。

5. Unity Multiplay の直接提供終了により、専用サーバー領域は選定注意が必要

UGS のマルチプレイ領域を検討する際、専用ゲームサーバーのホスティングについては注意が必要です。

Unity のステータス情報では、Unity による Multiplay Game Server Hosting は 2026年4月1日時点で deprecated となり、新しいゲームサーバーのスケールや新規 allocation はできないと案内されています。移行意思を示していた顧客については、Multiplay by Rocket Science への移行完了まで継続利用できる例外が示されています。

これは、UGS の Lobby、Relay、Matchmaker などがすべて使えなくなったという意味ではありません。しかし、専用ゲームサーバー運用まで Unity の中で完結させたい場合には、現在の提供状況と移行先を確認する必要があります。

GS2 を検討する場合は、ゲーム内経済、進行、報酬、ランキング、マッチメイキング、ロビー、チャット、リアルタイム通信を含めて、ゲームバックエンド全体をどう構築するかという観点で比較できます。単に「Unity で作っているから UGS」ではなく、ゲームの仕様と運用に必要なバックエンド機能を基準に選定することが重要です。

6. 料金の見積もりがサービスごとに分かれやすい

UGS の料金は、サービスごとにメーターが分かれています。たとえば Unity の料金ページでは、Cloud Save の保存容量、読み取り、書き込み、Economy の読み取り・書き込み、Cloud Code の invocation、compute、egress などが個別に示されています。Cloud Save は月 5GiB まで、読み取り・書き込みはそれぞれ無料枠があり、超過分は使用量に応じた課金です。Economy も読み取り・書き込みごとの無料枠と超過料金が設定されています。

これは小規模に始めるには便利です。一方で、実際のゲーム機能を構築する場合、1つのプレイヤー操作が複数サービスの課金につながることがあります。たとえば、ガチャを1回引く処理でも、設計によっては次のような処理が発生します。

• Cloud Code の invocation
• Economy の通貨読み取り
• Economy の通貨書き込み
• Economy のアイテム書き込み
• Cloud Save の状態保存
• Remote Config の設定参照
• ログや分析イベント

このように、ゲーム機能単位ではなく、サービス単位で料金を積み上げる必要があります。

GS2 は API リクエスト単位の従量課金を基本としています。ゲームバックエンド全体を「何リクエスト使うか」という観点で見積もりやすく、インベントリ、ガチャ、ショップ、クエスト、報酬、ランキング、マッチメイキング、ロビー、リアルタイム通信などを含めて、費用感を把握しやすいことがメリットです。

GS2 が向いているゲーム

GS2 は、特に次のようなゲームに向いています。

• スマートフォンゲーム
• F2P タイトル
• ライブサービス型ゲーム
• ガチャやショップを持つゲーム
• インベントリや装備、育成要素を持つゲーム
• ログインボーナスや期間限定イベントを運用するゲーム
• 補填配布やギフトボックスが必要なゲーム
• ランキングやシーズン制イベントを持つゲーム
• マッチメイキングやロビーを必要とするゲーム
• チャットやリアルタイム通信を必要とするゲーム
• サーバー開発チームを大きく持たずにオンライン機能を実装したいゲーム
• Unity 以外のクライアントや複数エンジン展開も視野に入れているゲーム

これらのゲームでは、単にクラウドにデータを保存したり、サーバーレス関数を実行したりするだけでは不十分です。プレイヤーの所持品、課金通貨、ショップ、ガチャ、クエスト、報酬、ランキング、マッチメイキング、ロビー、チャット、リアルタイム通信、運用機能まで、一体で扱う必要があります。GS2 は、その領域を広くカバーしています。

UGS が向いているケース、GS2 が向いているケース

UGS と GS2 は、どちらもゲームバックエンドを支えるサービスです。ただし、強みの出方は異なります。

UGS は、Unity プロジェクトと密接に統合しながら、Authentication、Cloud Save、Cloud Code、Economy、Leaderboards、Lobby、Relay、Matchmaker、Vivox などを活用したい場合に向いています。Unity エディタや Unity Dashboard を中心に、Unity 開発の延長線上でオンライン機能を導入したいチームに適しています。GS2 は、ゲーム内経済、進行、報酬、ガチャ、ショップ、ランキング、マッチメイキング、ロビー、チャット、リアルタイム通信など、ゲームで必要になるバックエンド機能を、ゲーム開発者が扱いやすい単位で構築したい場合に適しています。

機能単位でのより網羅的な比較は、トップページの機能カバレッジ比較表をご覧ください。

UGS と GS2 は併用もできる

UGS をすでに利用している場合でも、GS2 を併用する選択肢があります。

たとえば、UGS を Authentication、Cloud Save、Analytics、Remote Config、Relay などに利用しながら、ゲーム内経済、ガチャ、ショップ、インベントリ、クエスト、報酬、ランキング、マッチメイキング、ロビー、チャット、リアルタイム通信を GS2 で構築する構成です。この場合、Unity との統合のしやすさを活かしつつ、UGS だけでは実装負担が残りやすいゲーム機能領域を GS2 で補えます。

特に、すでに UGS を導入しているプロジェクトでも、次のような課題がある場合は GS2 の導入を検討する価値があります。

• Cloud Code のロジックが増え続けている
• Cloud Save のデータ構造がゲーム仕様に引きずられて複雑化している
• ガチャやショップの実装がタイトルごとに重複している
• 課金通貨やアイテム付与の整合性管理に不安がある
• 報酬配布や補填対応の運用負荷が高い
• クエストやミッションの実装が個別実装になっている
• ランキング報酬やシーズン制イベントの実装が複雑になっている
• マッチメイキング後のロビーやチャット、報酬反映までの連携が複雑になっている
• 機能追加のたびにバックエンド開発がボトルネックになっている

GS2 は、UGS を置き換えるだけでなく、UGS では実装負担が残りやすいゲーム機能領域を補完するサービスとしても活用できます。

まとめ：Unity で作っていても、
ゲームバックエンドまで Unity に閉じる必要はありません

UGS は、Unity でオンラインゲームを作るうえで便利なサービス群です。Authentication、Cloud Save、Cloud Code、Economy、Leaderboards、Lobby、Relay、Matchmaker、Vivox など、多くの機能を Unity 開発の延長線上で利用できます。

しかし、ゲーム開発で本当に手間がかかるのは、クラウド保存やサーバーレス実行環境そのものだけではありません。ガチャ、ショップ、報酬、クエスト、ギフトボックスといったゲーム固有の仕様に近いバックエンド機能を、どう安全に構築し、リリース後も運用し続けるかが大きな課題になります。UGS を使っていても、これらの機能をタイトル側で組み立てる必要がある場合、ゲームサーバーの実装量が思ったほど減らないことがあります。

GS2 は、この課題を解決するために、ゲームで繰り返し必要になるバックエンド機能をサービスとして提供しています。

ゲーム開発者が本当に時間を使うべきなのは、アイテム付与処理の排他制御や、報酬受け取りの二重実行対策や、ガチャ結果の保存処理や、マッチング後の状態管理ではありません。本当に時間を使うべきなのは、ゲームの面白さ、継続率、イベント設計、プレイヤー体験です。

Unity 開発の延長線上でオンライン機能を導入したいなら UGS。ゲーム仕様そのものをサービスに任せたいなら GS2。GS2 を使うことで、ゲームバックエンドの共通機能を短期間で構築し、安全に運用できます。Unity で開発している場合でも、バックエンドまで Unity に閉じる必要はありません。UGS だけでは実装負担が残りやすいゲーム機能領域を補い、サーバー開発の負担を減らしたいなら、GS2 は実践的な選択肢です。