『SINoALICE ーシノアリスー』が『シノアリスだったナニカ』に移行するまで。アプリサーバーなしで7年間のプレイ記録を後続アプリへ引き継ぐ【CEDEC2024】

登壇したのはポケラボ クライアントエンジニアの高田 美里氏。2020年に中途入社し、『SINoALICE ーシノアリスー（以下、シノアリス）』のクライアントエンジニアとしてクローズ周りを担当。『シノアリス』のプレイヤーでもあり、クライアントメイン実装も担当しています。

『シノアリス』は、ヨコオタロウ氏が原案・クリエイティブディレクターを手掛ける、スマートフォン向けダークファンタジーRPGです。

童話をモチーフとしたキャラクターが、自身の作者を蘇らせる為に殺し合いをしていくというダークなメインストーリーとは対照的に、季節ごとのイベントではキャラクターがメタ的な発言を行うなど、自由な世界観が『シノアリス』の魅力であると高田氏は語ります。

本作は2017年にリリースされ、2024年にサービスが終了しました。

ユーザーの手で『シノアリス』を終わらせるエンディング体験

『シノアリス』には、立ち上げ当初から「しっかりとしたエンディングを必ず作る」構想があったそうです。

サービス終了をお祭りとして最後まで楽しんでほしいという思いの下、エンディングは新規ユーザーや復帰ユーザーも楽しめるように設計されました。

このエンディングは「『シノアリス』フィナーレ計画」と開発内部で呼称され、「ユーザー自身の手で『シノアリス』を終わらせる」「『シノアリス』の息の根を止める権利をあなたに」の2点を目標に開発が進められました。

上記の2点を実現するために、進行に応じてギルドチャットなどのソーシャル機能が制限されたり、これまで獲得したキャラクターが消えたりするなど、『シノアリス』の崩壊を想起させるギミックが盛り込まれました。最後は、ギルドメンバーと同じ時間にレイドバトルに参加して『シノアリス』を終わらせる形に。

エンディングをクリアしたユーザーの『シノアリス』アプリは、サービス終了後も『シノアリス』における一部のデータを引き続き閲覧できるアプリ『シノアリスだったナニカ（以下、ナニカ）』に変化します。

『ナニカ』に変化する際、アプリのアイコンがお墓に変わる。なお、『シノアリス』のサービス終了後も、『ナニカ』は各ストアページからダウンロードが可能

メインストーリー、ミニゲーム、プレイデータ――『ナニカ』でアクセスできるデータ仕様

『ナニカ』ですべてのユーザーがアクセスできる内容は以下の通りです。

上記に加え、エンディングを自力でクリアしたユーザーは、以下に示す自身のプレイデータが閲覧できます。

このほか、自身がフォローしていたユーザーなども閲覧できる

エンディングを通して最もユーザーに体験してほしかったのは、「シノアリスはユーザー自身の手で破壊された」、つまり、ユーザーがストーリーを進めることで『ナニカ』にアプリが変化することだったと高田氏は言います。

上記の体感を実現するために、サービス期間中に『ナニカ』になったユーザーと『シノアリス』のままのユーザーが混在する期間を用意することが、開発する上でのポイントとなりました。

エンディングにあたる7章が公開された12月中旬からサービス終了までの約1か月間は、「エンディング未クリア」と「クリア済み」の2種類のユーザーが存在します。その間は、本番環境にも『シノアリス』と『ナニカ』が混在している状況です。

講演では、『シノアリス』と『ナニカ』が混在する期間への対応や、サービス終了時に『ナニカ』へ完全移行する際のプロセスを解説しました。

配信コンテンツとアプリの状態を示したスケジュール

『シノアリス』のサービス終了時点におけるサーバー運用体制

プレイヤーのログイン情報やゲーム内ロジックの判定など、ソーシャルゲームの運営に必要なサーバー機能を担う「アプリサーバー」は、一般的なソーシャルゲームと同様に運用を停止します。

一方で、ストレージシステムであるAkamaiやAmazon S3は運用コストも比較的安価であったことや、『ナニカ』で有用であったことから、サービスを残しました。

サービス終了後もアプリの状態をある程度ハンドリングできるよう、『ナニカ』の移行にあたっては専用の「設定ファイル」を用意しました。

設定ファイル内に保存される設定項目

設定ファイルは、サービス終了に伴い暗号化され、ストレージシステムに移されました。

設定ファイルはバイナリファイル形式でストレージシステムに保存されている。暗号化前はJSONのような形式で記述されていた

設定ファイルの役割

プレイヤーがエンディングを迎えた直後に『ナニカ』で自身のデータを確認する体験や、『ナニカ』で他のプレイヤーがエンディングを迎える様子を見る体験ができるよう、サービス期間中は『ナニカ』になっても通常通りAPI通信を行い、データをアプリサーバーから取得する必要がありました。

一方で、サービス終了後はサーバーとの通信を行わず、オフラインアプリ用の仕組みを使ってデータを表示しなければなりません。

そこで、『シノアリス』と『ナニカ』の混在状態に応じた3つの期間を設定ファイルで判別できるよう、それぞれの期間を以下に示す「アプリのタイプ」として分類しました。

各タイプに対するQAは同時に進行していたため、3タイプそれぞれに異なるサーバー環境を用意しました。これにより、QAテスターは「サーバー環境によってアプリの状態が異なる」という認識の下でチェックができ、QAのスピードや情報伝達、判断が早まるなどの業務効率向上を開発側・QA側の双方で体感できたそうです。

なお、手厚い準備を行ったうえでも、サービス終了後のオフライン化対応時にはメンテナンスによる運営のみが『ナニカ』に触れる時間を確保し、リリース前に動作の確認が必要でした。

アプリサーバー抜きでメンテナンスに対応するためのアイデア

『シノアリス』のメンテナンスはログイン時にアプリサーバーと通信を行ない、毎回メンテナンスモードかどうかをサーバー側に問い合わせてログイン可否を判断していました。『シノアリス』運用時に使用していたメンテナンスに関する仕組みは、アプリサーバーで制御していたためサービス終了後は使用できません。

そこで、サービス終了後は、ストレージシステムにある設定ファイルからアプリ表示の可否を判断することでメンテナンス状態を実現しました。

設定ファイルには「isMaintenance」というフラグを保持し、フラグがtrueであれば、クライアントはメンテナンス中だと判断。メンテナンス用の処理を実行します。

同時に、『シノアリス』も「isMaintenance」によるメンテナンスに対応させています。これは、サービス終了に伴うオフライン化の対応に『ナニカ』になっていないプレイヤーがアプリサーバーに接続すると、復旧できない不具合が発生する懸念があったためです。

メンテナンス端末からメンテナンス中に『ナニカ』の表示を確認

クライアントアプリ側でメンテナンスの判断を行うようにしたことで、特定の端末であればメンテナンス中でもログインできる仕組みも実装可能となりました。

メンテナンス端末には専用のバイナリを実装し、メンテナンス中に『ナニカ』に入って表示の確認が行えます。このメンテナンス端末専用のバイナリは、セキュリティ面でもメリットがあり、メンテナンス機能の他、本番環境の設定ファイルの内容を確認するのにも役立ったそうです。

『ナニカ』で見られるギルド情報や称号データなどの動的情報は、サービス終了後はサーバーを介してデータをクライアントに送信できないため、サービス終了前にクライアント側に送っておく必要がありました。また、静的な情報にも特殊演出、動画を含むメインストーリーや、ジョブの立ち絵など、サイズが大きいものがありました。

そこで『ナニカ』で見られる情報を「マスター系」・「静的リソース」・「動的データ」の3つに分類しました。

「マスター系」はジョブデータや、メインストーリーのテキストデータ、「静的リソース」は画像ムービーや立ち絵データ、「動的データ」はプレイヤーごとに異なるプロフィール情報や自身の資産データ

アプリをオフライン化する際は、静的リソースをアプリの中に含めるのが一番シンプルな解決法です。しかし、最低でも約11GBとなるデータサイズは、『シノアリス』の最低動作保障端末や、App Store・Google Playで配信できるアプリサイズ上限を考慮すると、内包が難しいものでした。仮に行うとしても表示するデータを制限するような手法が必要です。

高田氏のアカウントの場合、659体分のジョブの立ち絵を保存する必要があったそう

クライアント側が保有するデータの分別を抜け漏れなく行い、アセットバンドル（※）化して表示していたデータも含めて表示チェックするためには、最低でも2人/月程の工数がかかる見込みとなり、その捻出も問題となったそうです。その上、『ナニカ』で表示できるコンテンツも制限されるため、費用対効果が薄いのではないか、という声が上がりました。
※ リソースを読み込む際に使用できるアーカイブファイル。この情報を使用してモデルやテクスチャなどのデータを読み込むため、インストール時のデータサイズを抑えることができる

そこで、リソース環境だけをサービス終了後も落とさずにそのまま運用するというような方針にシフトチェンジ。『ナニカ』で表示できるコンテンツに制限をかける必要もなくなり、全体的なコストパフォーマンス向上に成功したとのことでした。

リソース環境を残し、アセットバンドルはサービス終了後も利用できるように仕様変更

当初はジョブデータのみ表示し、ナイトメア（召喚獣のようなもの）は表示できない仕様だったが、リソース環境を残すことで表示が可能に

コスト面では、『シノアリス』のシステムを流用するため、リソースの整理や内包化のパッケージ作業などを行う工数を削減できました。リソース周りのオフライン化ついては、技術的な負担、エンジニアの対応工数をゼロに抑えられたそうです。

金銭面だけで見ると、アプリに全て内包する場合のコスト（人件費やストレージ利用費）が、ストレージシステムのみ運用を続けた場合のコスト累積額と同額になるのは2073年となり、コストの負担が大きく軽減されたことが分かります。

リソースを内包すると、費用がかかるのは2023年のみ。しかし、『シノアリス』のケースでは、ストレージシステムの維持費を毎年払い続けても約50年はリソースを内包しないほうが得という試算に

『シノアリス』を戦った人達のデータを、どうやってサービス終了後も表示できるようにしているか

「シノアリスを戦った人たち」（通称“お墓”）とは『シノアリス』をエンディングまで遊んだプレイヤーが自身の情報をアプリに登録することで、サービス終了後も自身のデータのみならず、他のプレイヤーのお墓も見られる仕組みです。

クリアナンバー（自分が何番目に『シノアリス』のエンディングをクリアしたか）、ギルド名、アカウント名とコメントなどを見ることができます。

SNSでプレイヤー自身のお墓を投稿したり、定期的にお墓参りしたり、さまざまな楽しみ方がなされている「シノアリスを戦った人たち」。お墓には墓標No.などとともにプレイヤーのコメントが記される

リアルタイムでお墓の情報を出すのは、「シノアリスを戦った人たち」で必ず達成したいことだったと高田氏。『シノアリス』エンディングをクリアして『ナニカ』に変化した際に、プレイヤーがすぐに自分の情報を確かめられるようにするとともに、サービス終了後に興味を持ったプレイヤーがダウンロードした場合もお墓の情報は等しく見られる必要がありました。

しかし、アプリ側にお墓の情報を内包すると、ストアからアプリに反映されるまで最低でも3日程時間がかかり、リアルタイム性が失われてしまいます。サービス終了時に駆け込みでエンディングをクリアしたプレイヤーがお墓を見るのにストア反映を待つ、ということは避けたかったため、お墓のデータは常に最新のものを取得することが求められました。

『ナニカ』のデータは、サービス期間中はアプリサーバーからリアルタイムにデータを取得します。サービス運用中かサービス終了後であるかのステータス切り替えは、『ナニカ』の設定ファイルで随時行えたため、クライアントアプリの更新はせず、サービス終了後のメンテナンスで設定を切り替える対応としました。

青い円柱はお墓データ。1月15日のサービス終了で確定したお墓データをメンテナンス中にアプリサーバーから抜き出して、JSON化。暗号化した後に、ストレージシステムへ保管した

ユーザーコメントなどを含む「お墓」のデータ登録・閲覧方法

アプリサーバー稼働時の動作

お墓の情報登録時はアプリサーバーが稼働しています。クライアント側からアプリサーバーにデータを送り、データベースに保存します。サーバー側ではクリアデータ・クリアナンバーなどを発行。その後、プレイヤーがお墓に表示するコメントをクライアント側で記入などした後に再度アプリサーバーにデータを送信し、データベースに登録します。

アプリサーバー稼働時は閲覧時もアプリサーバーから情報を取得し、クライアント側で表示します。

サービス終了後の動作

サービス終了後は、クライアント側で『ナニカ』の設定ファイルを参照し、サーバーとのAPI通信ができるか否かによってデータの取得先を設定します。

サーバーとのAPI通信ができないサービス終了後は、アプリ起動時にお墓の表示に必要なデータをダウンロードします。

お墓のデータ取得時には、暗号化されているファイルの内容や破損もチェック。仮にデータの破損などが認められた場合は、アプリ側は正しいデータを取得できるまで、お墓のデータをストレージシステムから取得し直す

フルパッケージ版での動作

『ナニカ』では静的なデータのほか、動的なデータも存在します。ここでいう動的なデータとは、プレイヤーの行動や入力内容で、表示の内容が変わるデータのことで「ユーザー固有情報」「ユーザープロフィール」「ギルド情報」「フォローリスト」などがあります。

『ナニカ』で見られる主な動的データ。個人のゲーム開始日や資産情報、プレイ記録などの「ユーザー固有情報」、『シノアリス』でユーザーが自身で設定し、他のユーザーにも表示されていた「ユーザープロフィール」、自身の所属していた「ギルド情報」、『シノアリス』でフォローしていたプレイヤーの一覧データ「フォローリスト」

サービス運用中、サーバーと通信しAPI経由で表示していたこれらのデータは、アプリサーバー側で管理していたため、サービス終了後はストレージシステムの中に入れる必要があります。しかし、プレイヤー情報はPrivateな情報です。URLを知っていれば不特定多数の人がアクセスできるストレージシステムに、データを置くのは憚られます。

また、プレイヤーとデータが1対1のデータをストレージシステムに置いてしまうと、プレイヤーがストレージシステムからデータを取得する度にコストが掛かってしまう点も問題でした。

これらの理由から、動的データはリソースとは別の保管先を検討しました。まずはデータを、閲覧プレイヤーとデータが多対1のものと、1対1の関係のものに分類。多対1の情報はリソースと同じくストレージサービスの中に格納し、1対1のPrivateなデータについては、DummyResponseという仕組みを導入して表示することにしました。

多対1のデータは、全てのプレイヤーが見られるPublicな情報、1対1のデータはそのアカウントの保持者ただ一人が見られればいいPrivateな情報と言える

DummyResponseは、サーバー停止後も事前に端末のローカルで保存しておいたAPIのレスポンス値から、あたかもサーバーがある時と同じようにクライアント側でAPIを使えるようにする機能です。

『ナニカ』では、プレイヤー固有のデータをクライアント側に保存し、サーバーを介さずにサービス終了後もプレイヤーデータを表示する機能を独自に開発し、使用しています。

サービス運用中は以下の流れでAPIが動作します。

サービス終了すると、アプリサーバーが機能しなくなるためタイムアウトやエラーになります。

DummyResponseが機能している場合は、以下のようにフローが変わります。

サービス期間中

サービス終了後

クライアント側APIベースクラスに処理を渡す前にアプリサーバーの稼働状況を判断

DummyResponseの作成では、各画面のクライアント側の処理の対応工数を減らすことを心がけたそうです。

API統括をしているクライアント側APIベースクラスに処理を渡す前に、DummyResponseがサービス運用中/終了後を判断する分岐を作ることで、クライアント側APIベースクラスがアプリサーバーの状態を意識することなくAPIを呼び出せます。

これにより、実装するエンジニアはAPIの処理を実施すれば、特別な対応をせずにサービス運用中も終了後もアプリの表示を担保できました。

また、設定ファイルでアプリの状態の切り分けが可能なため、開発中にサーバー稼働中/非稼働中を再現して確認できたのもメリットだったそうです。

必要なAPIレスポンスの洗い出しとリクエスト間隔の制御

DummyResponseは端末に保存すべきAPIのレスポンスを洗い出してから使う必要があると高田氏。運用中に作成したAPIの数は約1,000個あり、使用する物のみを選択しないと、それぞれのデータサイズは大きくないものの合算するとプレイヤーの端末を圧迫するデータサイズになってしまいます。

APIのレスポンスをDummyResponse用に保存するタイミングにも注意が必要です。一度サーバーにアクセスしてレスポンスのデータを保存するため、タイミングによってはサーバー側がアクセス過多となり、負荷が急激に高まることが予想されます。

APIレスポンスが数多く要求されるタイミングは、アプリが『ナニカ』に切り替わり、プレイヤーのお墓に名前が刻まれるときでした。この問題は、クライアント側でAPIにリクエストを送る間隔を約0.1秒ずつ意図的にディレイさせることで、プレイヤーの体験を損ねることなく、サーバーの負荷を避けました。

プレイヤーの情報を表示するために、データの保存先を2つに分ける

データはPublicとPrivateの2つに分けて保存しました。

ストレージシステムに保存して誰でも随時アクセスできるようにしたPublic属性のデータは、必要になった時にダウンロードされていないデータをダウンロードする運用としました。一方、Private属性のデータは、必要なAPIのレスポンスをサービス期間中に予め端末に保存しました。

このように保存先と閲覧先を別にすることで、柔軟にデータを扱えるようになり、サービス中からサービス終了後もプレイヤーに大きな違和感を抱かせずに『ナニカ』に遷移ができたそうです。

講演の最後に、サービス終了後のアプリにはプレイヤーのアプリの状態を最低限マネジメントできる機構が必須だと高田氏は考えを述べました。『ナニカ』では、設定ファイルを使ってアプリの状態を「Normal」「Mixed」「Nanika」に定義可能にし、サービス終了後にメンテナンスを入れることで、事前にその表示確認も可能となりました。

アセット保持について、本プロジェクトでは工数とコストを鑑みて、従来のストレージシステムをそのまま流用しましたが、それぞれのプロダクトに合った方法を検討するのが良いと高田氏。『ナニカ』での表現の幅を広げることにつながった、と締めくくりました。

HATA

5歳の頃、実家喫茶店のテーブル筐体に触れてゲームライフが始まる。2000年代にノベルゲーム開発を行い、異業種からゲーム業界に。ゲームメディアで記事執筆を行いながらゲーム開発にも従事する。