Nakama と GS2 の違い：
ゲームサーバーを「自分たちで持つ」か「サービスとして使う」か

Nakama + Hiro は OSS ゲームサーバーとフレームワーク、
GS2 はゲーム機能 BaaS

Nakama の大きな強みは、オープンソースであり、ゲームサーバーを自分たちの要件に合わせて構築できることです。

Nakama は、ユーザーアカウント、チャット、ソーシャル、マッチメイキング、リアルタイムマルチプレイなどを備えたゲーム向けサーバーとして提供されています。GitHub 上でも、マルチプレイ、マッチメイキング、リーダーボード、チャット、ソーシャル機能を備えたスケーラブルなオープンソースゲームバックエンドとして紹介されています。サーバー側ロジックは Go、TypeScript、Lua で拡張できます。

そして Hiro が、この上にゲームプレイシステムの層を加えます。Hiro には、通貨・ストア・IAP 検証を扱うエコノミー、インベントリ、実績(Achievements)、クエストチェーンやスキルツリーを表現できる進行管理(Progression)、スタミナに相当するエナジー、連続ログイン報酬(Streaks)、シーズン制のイベントリーダーボードなどが含まれます。つまり Nakama + Hiro は、ゲームサーバーとゲームシステムの両方を、自分たちの手で組み立てて運用したいチームにとって、非常に強力な構成です。

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

機能の広がりだけを見れば、Nakama + Hiro と GS2 がカバーする領域はかなり重なります。違いは提供のかたちです。Nakama + Hiro は「自分たちのサーバー上で動かすフレームワーク」であり、構成・拡張・運用の主体はタイトル側です。GS2 は「マネージドなサービス群」であり、サーバーの構築や運用をせずに、ゲームサーバーで毎回作ってきた機能をそのまま利用できます。

Nakama + Hiro でも残りやすい課題

Nakama は強力なゲームサーバーフレームワークであり、Hiro はその上に多くのゲームシステムを提供します。それでも、実際のゲーム開発では次のような課題が残ることがあります。

1. OSS + フレームワークで自由に作れる一方、運用責任は自分たちに残る

Nakama の大きな魅力は、オープンソースであることです。セルフホストすれば、自分たちのインフラ上で自由に運用できます。GitHub でも Nakama は Apache 2.0 ライセンスのオープンソースプロジェクトとして公開されています。Hiro を使う場合も、Hiro のモジュールは自分たちの Nakama サーバー上で動かすことになります。つまり、セルフホスト構成では、ゲームサーバーの運用責任は自分たちに残ります。たとえば、次のような作業が必要になります。

• サーバー構築
• データベース構築
• スケーリング設計
• バックアップ
• 障害対応
• 監視
• Nakama / Hiro のアップグレード
• セキュリティ対応
• 負荷試験
• リージョン展開
• コスト最適化

Nakama には Heroic Cloud というマネージドな選択肢もあります。Heroic Labs は Heroic Cloud を、Nakama と Satori をホストするためのマネージドまたはプライベートクラウドとして案内しています。ただし、マネージドで使う場合でも、ゲームロジックや Hiro の各システムの構成・設計責任はタイトル側に残ります。

GS2 は、インフラ運用だけでなく、ゲームサーバーで毎回作る機能そのものをマネージドサービスとして提供します。サーバーを立てる、拡張する、保守するという負担なしに、インベントリ、ガチャ、ショップ、クエスト、報酬、ギフトボックスなどを利用できます。

2. Hiro がカバーする領域と、しない領域がある

Hiro の登場で、Nakama 単体ではランタイムコードでの自前実装になりがちだった多くの領域が、フレームワークとして提供されるようになりました。たとえば、次のような領域です。

• インベントリ(Hiro Inventory)
• 通貨・ストア・IAP 検証(Hiro Economy)
• 実績(Hiro Achievements)
• クエストチェーン・スキルツリー(Hiro Progression)
• スタミナに相当するエナジー(Hiro Energy)
• 連続ログイン報酬(Hiro Streaks)
• シーズン制イベントリーダーボード(Hiro Event Leaderboards)

一方で、ライブサービス運用で必要になる機能のすべてが揃っているわけではありません。たとえば、受け取り期限つきのギフトボックス、所持上限超過分の自動転送、メンテナンス補填や障害時の個別補填、シリアルコード(キャンペーンコード)の発行・失効管理、ニュース配信、バージョンチェック、メンテナンス制御、バフ補正、強化合成、装備編成、ガチャの天井や排出率表示といった領域は、Hiro を使っても自分たちでランタイムコードとして設計・実装することになりがちです。

実装できることと、実装しなくてよいことは違います。フレームワークが土台を提供しても、その上に組むタイトル固有仕様の設計、テスト、運用、障害対応、仕様変更対応の負担は残ります。

GS2 は、こうしたゲームバックエンドで頻出する処理を、運用機能まで含めて機能単位のサービスとして提供します。ゲーム開発者は「Hiro とランタイムでどう実装するか」ではなく、「GS2 のどのサービスを組み合わせてゲーム仕様を表現するか」を考えることができます。

3. ゲーム内経済の整合性は、構成・実装側の責任になりやすい

ゲーム内経済では、アイテムや通貨の増減が非常に重要です。たとえば、次のような問題が起きると、ゲーム運営に大きな影響を与えます。

• 課金通貨が二重に消費される
• 報酬が二重に受け取られる
• ガチャ結果とアイテム付与に不整合が起きる
• 購入回数制限が回避される
• 所持上限を超えたアイテムが失われる
• ランキング報酬が誤配布される
• イベント終了後に本来受け取れない報酬が受け取られる

Hiro のエコノミーやインベントリは、この領域の土台を提供します。Nakama のストレージエンジンには複数更新をまとめて実行する仕組みもあります。それでも、重複アイテムの変換、所持上限超過時の挙動、補填配布、イベント期間の制御といったタイトル固有の仕様は、Hiro の設定とランタイムコードを組み合わせて自分たちで設計することになります。自由度が高い構成では、冪等性、排他制御、二重実行防止、不正リクエスト対策、ロールバック設計を考える場面がその分増えます。

GS2 は、ゲーム内経済を扱うための機能を、個別のマネージドサービスとして提供します。インベントリはインベントリとして、課金通貨は課金通貨として、ショップはショップとして、ガチャはガチャとして、ギフトボックスはギフトボックスとして扱えます。ゲーム内経済を安全に運用するための単位で、機能をそのまま利用できます。

4. マッチメイキングやリアルタイム通信は強いが、前後のゲーム進行は設計が必要

Nakama は、マッチメイキングやリアルタイムマルチプレイに強みがあります。authoritative multiplayer では、マッチの実行中に必要なゲーム状態を保持するためのインメモリ領域も提供されます。リアルタイムマルチプレイを自分たちで構築したいチームにとって大きなメリットです。

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

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

Hiro のイベントリーダーボードや実績・進行管理は、この連携の一部を支えます。それでも、対戦結果をどの報酬・クエスト・レーティングへどう反映するかというゲーム固有の連携は、ランタイムコードとして自分たちで設計することになります。

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

5. 「自分たちで持てる」ことは強みだが、チーム体制を選ぶ

Nakama + Hiro は、自分たちでゲームサーバーとゲームシステムをコントロールしたいチームに向いています。たとえば、次のようなチームには相性がよいでしょう。

• サーバーエンジニアが十分にいる
• Go / TypeScript / Lua でサーバーロジックを書ける
• インフラ運用に慣れている
• Kubernetes やクラウド運用に知見がある
• リアルタイムマルチプレイの authoritative server を自社で作りたい
• OSS とフレームワークをベースに柔軟に拡張したい

一方で、サーバー開発チームを大きく持たないゲーム開発では、フレームワークの自由度がそのまま負担になる場合があります。ゲームサーバーを構築できることは重要です。しかし、多くのゲームで繰り返し必要になる機能を、自分たちのサーバー上で組み立てて運用し続ける必要があるかは、別の問題です。

GS2 は、サーバー開発チームを大きく持たなくても、ゲーム内経済、進行、報酬、ランキング、マッチメイキング、ロビー、チャット、リアルタイム通信などを利用できるように設計されています。

6. コストは「ライセンス費」だけでなく「運用・開発コスト」まで見る必要がある

Nakama はオープンソースとして利用できます。セルフホストすれば、ライセンス費を抑えながらゲームサーバーを構築できます。一方で、実際のコストはライセンス費だけではありません。セルフホストする場合、次のようなコストが発生します。

• サーバー費用
• データベース費用
• ネットワーク費用
• 監視・ログ基盤
• バックアップ
• 障害対応
• 負荷試験
• セキュリティ対応
• Nakama / Hiro のバージョンアップ対応
• サーバーエンジニアの工数

Heroic Cloud を利用すればマネージドな形で Nakama を運用できます。また、Hiro は商用のゲームフレームワークとして提供されており、利用形態に応じた契約が必要になります。ただし、マネージド化やフレームワーク導入によっても、タイトル固有のゲーム機能の設計・実装・運用が不要になるわけではありません。

GS2 は API リクエスト単位の従量課金を基本としています。インベントリ、ガチャ、ショップ、クエスト、報酬、ランキング、マッチメイキング、ロビー、リアルタイム通信などを含めて、ゲームバックエンド全体を「何リクエスト使うか」という観点で見積もりやすいことがメリットです。コストを見るときは、サーバー費用やライセンス費だけでなく、ゲーム機能を作る人件費、テスト工数、運用工数、障害対応コストまで含めて比較することが重要です。

GS2 が向いているゲーム

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

• スマートフォンゲーム
• F2P タイトル
• ライブサービス型ゲーム
• ガチャやショップを持つゲーム
• インベントリや装備、育成要素を持つゲーム
• ログインボーナスや期間限定イベントを運用するゲーム
• 補填配布やギフトボックスが必要なゲーム
• ランキングやシーズン制イベントを持つゲーム
• マッチメイキングやロビーを必要とするゲーム
• チャットやリアルタイム通信を必要とするゲーム
• サーバー開発チームを大きく持たずにオンライン機能を実装したいゲーム
• OSS ゲームサーバーとフレームワークを自前運用するより、マネージドなゲーム機能をサービスとして使いたいゲーム

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

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

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

Nakama は、OSS をベースに、自分たちでゲームサーバーを構築・拡張・運用したい場合に向いています。リアルタイムマルチプレイ、マッチメイキング、リーダーボード、チャット、ソーシャル機能を持ち、Go、TypeScript、Lua でサーバー側ロジックを実装できます。Hiro を加えれば、エコノミー、インベントリ、実績、進行管理、エナジー、連続ログイン報酬などのゲームシステムもフレームワークとして利用できます。GS2 は、ゲーム内経済、進行、報酬、ガチャ、ショップ、ランキング、マッチメイキング、ロビー、チャット、リアルタイム通信など、ゲームで必要になるバックエンド機能を、マネージドサービスとして扱いたい場合に適しています。

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

Nakama と GS2 は併用もできる

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

たとえば、Nakama を authoritative realtime multiplayer、カスタムマッチロジック、独自のサーバー拡張に利用しながら、ゲーム内経済、ガチャ、ショップ、インベントリ、クエスト、報酬、ランキング、ログインボーナス、ギフトボックスなどを GS2 で構築する構成です。この場合、Nakama の強みであるリアルタイムサーバーやカスタムロジックの柔軟性を活かしつつ、自前運用になりやすいゲーム機能領域を GS2 のマネージドサービスで補えます。

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

• ランタイムコードのゲームロジックが増え続けている
• ガチャやショップの仕様追加が重くなっている
• インベントリや課金通貨の整合性管理に不安がある
• 報酬配布や補填対応の運用負荷が高い
• ギフトボックスやシリアルコードなど、フレームワーク外の機能実装が積み上がっている
• ランキング報酬やシーズン制イベントの実装が複雑になっている
• マッチメイキング後のロビー、対戦結果、報酬反映までの連携が複雑になっている
• サーバー運用とゲーム機能開発の両方が負担になっている
• 「自分たちで作れる」よりも「作らずに運用できる」領域を増やしたい

GS2 は、Nakama を置き換えるだけでなく、Nakama + Hiro でも自前実装・自前運用になりやすいゲーム機能領域を補完するサービスとしても活用できます。

まとめ：Nakama + Hiro は自分たちで作って運用する基盤、
GS2 はゲームサーバー機能を使うための BaaS

Nakama は、ゲーム向けサーバーとして強力な選択肢です。オープンソースであり、リアルタイムマルチプレイ、マッチメイキング、リーダーボード、チャット、ソーシャル機能を備え、Go、TypeScript、Lua でサーバー側ロジックを拡張できます。さらに Hiro を加えれば、エコノミー、インベントリ、実績、進行管理、エナジー、連続ログイン報酬といったゲームシステムもフレームワークとして手に入ります。自分たちでゲームサーバーを持ち、柔軟に作り込みたいチームには魅力的な構成です。

一方で、ゲーム開発で本当に手間がかかるのは、ゲームサーバーやフレームワークを動かせることそのものではありません。タイトル固有の仕様をどう安全に構築し、リリース後も運用し続けるかが大きな課題になります。Nakama + Hiro を使っていても、ギフトボックス、補填、シリアルコード、ニュース、バージョンチェック、ガチャの天井といった領域を自分たちで組み立て、そのすべてを自分たちのサーバーとして運用し続ける必要があります。

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

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

Nakama + Hiro で自由に作って運用する。あるいは GS2 で作らない領域を増やす。どちらの思想が自分たちの開発体制に合っているかを見極めることが、ゲームバックエンド選定では重要です。ゲーム機能をなるべくマネージドなサービスとして利用し、サーバー開発と運用の負担を減らしたいなら、GS2 は実践的な選択肢です。