【Unity】バックエンドサービスは終了することもあるので代替策も検討

昔作ったアプリでは、ニフティクラウドのmobile backendを使っていたり、GameSparksを使っていたりしました。どちらも2025年現在では終了してしばらく経つものですが、作ったゲームのバックエンドとして外部サービスを使う場合には終了するリスクがあることも想定しておくと安心です。

使っているバックエンドサービスが終了した場合、クライアント側(スマホアプリやSteam向けのビルド)などでも対応が必要になるため、大きな工数がかかったりします。仕組みから変えるので、しょうがない部分もあるとはいえ、他にもやるべき作業がある中でこうした修正が発生すると泣きそうになるので、事前に代替サービスを想定しておくことで対処が早くなるかもしれません。

ニフティクラウドのmobile backendの思い出

昔作ったアプリでニフティクラウドのmobile backendを使っていたことがありました。mobile backendではプッシュ通知の機能や、アプリのユーザ管理機能、データストアなどが提供されていて、当時は「プッシュ通知でアプリの起動を促そう！」みたいな意図で導入した覚えがあります。

このサービスは2024年3月末で終了することがアナウンスされており、他のサービスに移行できる期間が用意されていました。といっても私のアプリでは結局プッシュ通知の機能も使わずだったので、アプリの実行に影響がない範囲で済んだのが不幸中の幸いでした。データストアの機能を使っていたら、データのエクスポート、別のサービスへのインポート、別のサービス側でのAPI準備など、たくさんの作業があったことを思うとまだマシだったように思います。

mobile backendはunity1weekでゲームを作る際にも導入しやすいサービスだったのでありがたい存在でした。

GameSparksの思い出

こちらも昔作ったアプリでGameSparksのバックエンドサービスを使っていたことがありました。ゲーム情報を発信するWebメディアと名前が似ていますが、それとはまた別のサービスです。ランキング機能やサーバ側の処理の実装、APIの実装などを行うことができたため、ランキング機能を実現するために導入しました。

2022年9月に終了していて、Amazon GameSparksとして生まれ変わる話もあったのですが、その後はどうなったか把握できていません。Amazon GameLiftに組み込まれたのでしょうかね？(無知)

インディーデベロッパーは無料で使えるというのが非常にありがたい部分で、お金のかかるバックエンドサービスを使わずに導入できることで、ランキング機能などのバックエンドが必要なゲームのアイディアとしても組み込みやすい点が助かりました。

ランキング機能としてがっつりアプリの機能として組み込んでいたため、とても影響が大きかったのを覚えています。といってもアプリのユーザ数も悲しいかな減っていた頃なので、ランキング機能のクローズ後、アプリの運用も終了する方向で進めました。考えようによっては、Firebaseなどを導入してランキング機能を自分で実装するチャンスだったかもしれませんが、リリースしているアプリでそれをやる勇気はなかったのでやめて良かったと思います。遊んでくれているユーザさんに迷惑はかけられませんからね。

サービス停止に備える手段

バックエンドサービスはサービスが終了する可能性も考えておく必要があります。バックエンドに限らず外部のサービスは終了するリスクもあるので、あらかじめそのリスクに備えることを考えておくと安心です。その備えとして考えられるのは以下のものです。

• 代替サービスの検討
• ラッパークラスを噛ませる
• 自力実装

代替サービスの検討

バックエンドサービスとしてどのサービスを導入するか検討する段階で、「もしこのサービスが終了したらこっちを使おう」と代替のサービスを考えておくと良いかと思います。検討時にはいくつかサービスをピックアップしていることが多いかと思いますので、機能面、費用面、サービス継続性などいくつかの判断材料を用意しておいて、それによって自分のゲームにあったサービスを並べていけば代替時の切り替えも想定できます。

基本的に大きな資本が入っているサービスなら終了する可能性も低いように思いますが、外資だと不採算事業を畳むのが早いので継続性についてはよく確認しておきたいところです。導入実績が紹介されていることも多いので、そのゲームやアプリを見て判断するのも良いかもしれません。

といいつつニフクラでは有名アプリの名前もあったりしたんですよね。ニフクラの場合は資金面の問題ではなく会社の合併に伴うサービスの統合と変更によるもので、外部からこれを読むのは難しいのが正直なところです。

どれが継続するかは読めないので、やはり複数のサービスを候補として挙げておいて、何かあったらこちらに切り替える、という準備をしておくのが開発者側でできる対策かもしれません。

困ったらFirebaseかAWSを使っておけば終了することはないんじゃないかなーと個人的には思います。

ラッパークラスを噛ませる

ゲーム内の実装に関しては、バックエンドサービスの機能を呼び出す処理はなるべく別のクラスに分けておくと良いかと思います。

例えば1ゲーム終了時の得点をバックエンドに送信するなら、ゲームロジック側のクラスから直接APIを叩くのではなく、ラッパークラスを用意して、RegisterScore()のようなメソッドを用意しておいてこちらの内部でAPIを呼ぶ形にするとグッド。不幸にもバックエンドサービスが終了したとしても、修正対象の処理はラッパークラス側にまとまっているので、影響範囲を特定しやすくなります。

ゲームロジック側のクラスに書かれていると、自分の書いたコードとAPIを呼ぶコードが混ざってごっちゃになりやすかったり、見落としが発生しやすかったりするので、事前に切り離しておくのが得策です。修正箇所を特定するならプロジェクト内のSDKを削除してコンパイルエラーになっている部分を修正する、という力技もあったりしますが、切り替える先のバックエンドサービスのAPIの呼び方によってはロジックの変更が必要になったりするので、あらかじめクラスを分けておくと対処もしやすくなります。

バックエンド側の応答によって処理を分けたりすることもあるので、成功時のコールバック、失敗時のコールバックもあらかじめ準備しておけば、多くの場合ゲームロジック側の修正もそこまで多くなくて済むのではと思います。

自力実装

「バックエンドサービスを外部に依存するから未来の自分が困るのだ！　自力で実装すれば問題ない！」という根性ベースの考えもあります。データセンターでサーバを用意して……といったレベルまではいかずとも、AWSやFirebaseを使ってバックエンド側を実装しておけばサービス終了に怯える可能性を減らせます。

費用面ではFirebaseが有利で、従量課金ではあるものの無料枠もあったりして、思ったより安く済むことも多いです。AWSの方はもう少し費用が高くなりますが、機能的には充実しています。

ニフクラのようにモバイルのバックエンドとして使うならFirebaseが近い感覚で使えるかもしれません。Firebaseを導入するケースは多いかと思いますので、他の人のゲーム作りを手伝うときにも知識が役立ちます。Unity向けのSDKもあるので、導入の難易度は比較的低いように思います。たまに公式ドキュメントの内容が分かりにくいこともありますが、使っている人も多いためかその解決策は調べれば出てくることも多いです。

AWSを使うのはゲームというよりはWebサービスなどが多い印象ですが、LambdaでAPIを用意したり、DBの扱い方だったりを知っておくと、ゲーム以外にも活かせる知識になります。Firebaseに比べると自分で実装する部分は多くなりますが、大規模なゲームを作るならAWSでしっかりとバックエンドを作り込んだ方が良いかもしれません。

まとめ

外部のサービスを使っていると、そのサービスが終了することもあります。それに備えて、

• 代替サービスを検討しておく
• コードを整理して修正しやすいようにする

といった準備をしておくと安心です。

もう少し頑張れるならFirebaseなどを使うことで、次のゲームを作るときや、他の人のゲームを作るときにも応用しやすい知識が手に入るので、こちらを検討してみるのも良いかもしれません。