株式会社コロプラと『神魔狩りのツクヨミ』

齋藤：コロプラは、「Entertainment in Real Life」、エンターテインメントで日常をより楽しく、より素晴らしくというミッションで事業を展開しております。最新のテクノロジーと、独創的なアイデアで”新しい体験"を届けるというビジョンを掲げ、主にモバイルゲームを開発しています。

『神魔狩りのツクヨミ』（以下、神ツク）は、数々のタイトルを手がけてきた金子 一馬がコンセプトプランナーとして関わっている新作ゲームタイトルです。ジャンルはローグライクカードゲームで、プレイしながらダンジョンを探索し、キャラクターのHPがゼロになるとと最初からやり直すというジャンルになります。

齋藤：今回、AIというキーワードがあるので触れておきたいのですが、一番大きい特徴として、AIがサービス内に組み込まれています。金子 一馬のクリエイティブを学習させたAIが、ゲームの作中に「AIカネコ」として登場するのです。

実際にプレイヤーが遊んだログを参照して、AIがカードの性能や絵柄を描き出し、オリジナルなカードを作っていきます。そのカードを使って遊んでいくという形のゲームになっています。

さらに、ユーザーがそれぞれ作ったカードをユーザー同士が投票し、最終的に良かったものの中から金子 一馬が選定してリファインし、オフィシャルなカードにするというイベントも実施しています。

まとめますと、神ツクは新しいテクノロジーをおもちゃにし、プレイヤーと金子 一馬がAIを使って遊ぶというゲーム体験創造に挑戦したタイトルとなっています。iOS、Android、STEAMで配信していますので、もしよければ触ってみてください。

今回は、スマートフォンゲームの裏側がどうなっているのかという前提の紹介と、コロプラでのアーキテクチャ変遷のサマリー、そして後半は岡村から神ツクのアーキテクチャと画像生成AIの組み込みについてお話しします。

スマートフォンゲームの構成について

齋藤：そもそもスマートフォンゲームとは何かというと、モバイル端末上で動作するゲームです。特徴として、高い携帯性といつでもどこでもプレイできる点があります。また、地下鉄の中や外出時に通信が一瞬途切れるようなケースでも動作することが前提条件だったりします。さらに、ソーシャル要素が入っているので、他プレイヤーとの協力や対戦交流が必須になっていたり、継続的なコンテンツ配信が必要だったりします。

そんなスマートフォンゲームの裏側ですが、基本的な作りは実はWebアプリケーションとそれほど変わりません。いわゆるクライアントサーバーモデルで、クライアントとサーバーがネットワークを通じて繋がっています。我々はPHP、MySQL、Redis、あとSpannerも使っています。Web開発でも馴染みのある技術スタックだと思います。

齋藤：大きな違いを挙げるとしたら、クライアントがブラウザではなく、コロプラではUnityで作られたアプリケーションになっているというところです。

もう一つの特徴として、リアルタイムというキーワードがあります。対戦や協力をする中で、どうしてもAPIサーバーだけでは実現できない部分があるので、オンラインでのリアルタイムマルチプレイを実現するために専用サーバーを立てています。WebSocketなどの常時接続双方向通信が可能なプロトコルを利用して実装されているのが、通常のAPIサーバーとは異なるところです。

齋藤：例えば4人でプレイしている場合を想像してもらうと、誰か1人が移動したとか敵を倒したというメッセージが送られた時に、リアルタイムサーバーを介して他の3人にメッセージを送るという形です。英語ではDedicated Game Server、略してDGSと呼んだりします。

神ツクのアーキテクチャ概要

齋藤：では実際のコロプラでのアーキテクチャの話に入っていきます。最初に、神ツクでのアーキテクチャが最終的にどのような形になったかというところから紹介させていただきます。

齋藤：ここからは実際のコロプラでのアーキテクチャについてお話しします。まず、神ツクの最終的なアーキテクチャをご覧ください。さまざまなコンポーネントが並んでいますが、この時点では「こういった技術を使っているのだな」という全体感を掴んでいただければ十分です。

今回のリアーキテクチャでは、Cloud Runを採用して構成を変更しました。従来のGKEベースのタイトルと比較すると、全体構造がどのように変わったかがおわかりいただけると思います。具体的な変更点については後ほど詳しくご紹介しますが、まずは全体像の違いを押さえておいてください。

齋藤：この構成に至るまでには、コロプラでもさまざまなアーキテクチャの変遷がありました。その過程で採用してきた技術や直面した課題について、先にお話しさせてください。

アーキテクチャ変遷のサマリー

齋藤：10年前のアーキテクチャでは、インフラ基盤にAWSを利用していました。クライアントの通信、APIサーバー、リアルタイムサーバーがあり、PHPとNode.jsで実装されていました。MySQLを使っていたり、キャッシュとしてRedisを使っていたりと、大きなところは今と変わっていないかと思います。

齋藤：この当時の問題として、サーバー負荷のためにゲームに繋がりにくい、遊べないという状況が定期的に発生していました。

これがなぜ起きるのかというと、スマートフォンゲームのアクセスパターンの特殊性があります。ゲームが新しく出たタイミングや、周年イベント、年末年始、クリスマスなど大きなイベントのタイミングで、決まった時間に一気にユーザーが戻ってきたり遊んでいただいたりするのです。そのタイミングでどうしてもアクセスの壁ができてしまい、システムが動かなくなってしまうことがありました。

齋藤：急激に増えるユーザー数に対して、データ量およびクエリの増加でデータベースの負荷が上がり、詰まって接続が不安定になるということがよく起きていました。事前にシャーディングを行ったり負荷分散を行ったりと対策はしていたのですが、事前の試算が難しかったり、それでも予想以上にアクセスが来るということがありました。またシャーディングを考慮したコーディングをするとコードが複雑化してしまうという問題もありました。

当時の問題は、データベースをなんとかして運用コストを下げたい、安定化させたいということでした。

5年前、ちょうど『位置情報を活用した大型IPタイトル』が出た時期には、先ほどの問題を解決するためにSpannerを導入しました。この頃からAWSではなくGoogle Cloudに移行し、実行基盤としてKubernetesを採用し、GKE上にアプリケーションをデプロイして動かすような構成に変更しています。

齋藤：特に大きくインパクトがあったのがSpannerの部分です。ユーザーのデータベースとして分散型データベースのSpannerを採用し、カタログ上では実質的に無制限のスケーリングができると記載されているので、うってつけでした。

特にコロプラは、ユーザーが遊べない状況を作らないようにしようという考え方で、社内では「ノーメンテ」という言い方をしています。もちろん裏でメンテナンスは行っているのですが、止めないことを基本的に大事にしています。そういった中で、ダウンタイムがないという点はSpannerの非常に大きなメリットでした。

齋藤：ワークロードの実行基盤としてGKEを採用したのは、大きな課題感からというよりは、SpannerでGoogle Cloudに寄せていきたかったこと、また時代の流れとしてコンテナ型が台頭していたことから採用しました。コロプラ自体がインフラエンジニアをそれほど多く抱えていないこともあり、運用のオペレーションコストを下げたいという点でもマッチしました。

齋藤：これまで成功してきた実績もあり、Google Cloud＋GKE＋Spannerの組み合わせは、今後のタイトルにもどんどん使っていこうという形になりました。

その頃、別軸の話になりますが、『フェスバ+』や『白猫GOLF』といったマルチプレイの対戦型・協力型ゲームのタイトルが複数控えていました。社内では、対戦型のゲームを効率よく作っていきたいという機運が高まっていた時期がありました。

一方、リアルタイムサーバー周りを扱える人材が限られていたり、ゲームのジャンル・タイトルによってはそもそもリアルタイム要素がなかったりするので、ノウハウを繋ぎづらいという課題がありました。そこで組織的にもリアルタイム通信基盤を支えるチームを作って、いろいろと変えてきました。

齋藤：Agonesの導入前は、リアルタイムサーバー側を自前で管理していたのですが、そういった部分の実装が大変だったので、Agonesを使って管理を簡略化しました。また、ゲームではマッチング機能をよく実装するのですが、プロジェクトごとに都度実装していたので、OpenMatchを採用しました。

齋藤：こういった形で、DGSを使ったりOpenMatchを使ったりすることで、マッチング基盤作りから解放されてゲームロジックに注力できるようになりました。詳しくはアーキテクチャカンファレンス2024でお話ししていますので、よければそちらもご覧ください。

神ツクのアーキテクチャ

岡村：コロプラではゲームタイトルごとにGoogle Cloudプロジェクトを分離しています。また各プロジェクトには開発環境、ステージング環境、本番環境、それとリアルタイム通信する場合はリアルタイムのゲームサーバーなど、複数のクラスタが存在しています。

このような状況ですと、GKEアップグレードに関する運用負荷が高いという問題が発生してきます。GKEでは数か月に一度という頻度でコントロールプレーンとノードバージョンの更新が求められます。この更新作業は、大きなイベントをリリースする時期と重なってしまうととても大変なことになるので、アップデートのタイミングや進行を慎重に見極める必要があります。

また、GKE環境のゲームタイトルが増えていくにしたがって、アップグレードの対象となるプロジェクト数・環境数が増えていきます。そのため、作業自体の重さに加えて、プロジェクト数と環境数が掛け合わされた結果、大きな負荷となっていました。

実際のアップデート作業も少人数のインフラエンジニアが他の業務と並行して担当しているという状況でしたので、工数削減が求められていました。

岡村：アップグレードを自動化できるのではという疑問を持たれる方もいるかもしれませんが、いくつかのハードルがありました。最大の懸念は、アップグレード時に問題が発生する確率が高いという点です。注意深く操作しないとシステム停止や予期しないトラブルが発生するリスクが伴います。

実際のケースでは、ノードOSのディスクドライバの更新影響や、カーネルパラメータの変更によってサーバーが不安定になったという事例もあります。どれもアップグレード内容を確認しただけでは予測することが困難で、実際に動かして検証・調査・対応が必要でした。また、弊社が利用しているカスタムリソースの一部はGKEなどしかサポートされないという理由もあり、AutoPilotの導入はできませんでした。

別軸になりますが、サービスがシュリンクしていくような状況においては、GKEのアーキテクチャだと運用コストが相対的に高くなってしまい、それがサービス継続にとっての大きな障害となることも否定できません。結果として、アーキテクチャ自体がサービス継続の足かせとなるリスクを抱えていました。

岡村：このような問題を抱えていた中、GKEの必然性についていくつか疑問点が浮かんできました。リアルタイム要素を持たないゲームにおいては、AgonesやDGSを使いませんので、必ずしもGKEである必要はないのではないか。また、GKE上で運用しているその他のコンポーネントも、最近マネージドサービスがたくさん出ていますので、それと代替することによって運用負荷とコストの最適化を実現できるのではないか。

ということで、Cloud Runを含めたフルマネージドサービスを中心としたアーキテクチャを検討したという流れになっています。

ここからは、Cloud Runで構築した神ツクのアーキテクチャについて解説していきます。

岡村：まず、アプリケーションサーバーにCloud Runを使っています。大きなメリットとしてはゼロスケールができるという点です。特に開発環境においてメリットがあります。縮退スケジュールを組まなくても、人がアクセスしている時だけインスタンスが起動するという特徴があるため、就業時間以外のコストをゼロにできます。

これはゲーム開発特有かもしれませんが、数か月先までの試作ラインが同時並行で動いており、開発環境数がとても多くなりがちです。そのため、開発環境のコストを圧縮できるというのはとても助かる性質となっています。

ゼロスケール状態でアクセスするとコールドスタートになるため、初回アクセスがもたつくこともありますが、ほとんどの環境では許容できます。QA環境や本番ではコールドスタートの影響を抑えたいので、最低1台起動しておくような調整をしています。

岡村：Cloud Runサービス内部に注目してみると、GKE時代には使っていなかったコンポーネントがいくつかあります。アクションログをBigQueryに転送するためにFluentbitを使ったり、トレースやメトリクスをDatadogに転送するためのOpenTelemetry Collectorを使ったりしています。

モニタリングには、Cloud MonitoringとDatadogを使っています。インフラメトリクスはCloud Monitoringで収集して、アプリケーション固有のメトリクス、例えばゲーム内のイベント処理数などはDatadogで収集するという使い分けになっています。Datadogではダッシュボードや監視設定を柔軟に設定できるので、早期にサービス異常に気づけるような活用もしています。具体的には、前日のアクセス数のダッシュボードをPDFにしてSlackに送るといったこともしています。

岡村：QueueバックエンドとしてはCloud Taskを利用しています。こちらはLaravel用のカスタムドライバーライブラリを弊社で作成して使っています。Cloud TaskはCloud Runに対してHTTPリクエストを送ることでジョブの処理を行いますので、Cloud Runがリクエスト時だけ動くという特性にとても合っていて、相性の良い形となっています。

岡村：デプロイにはCloud DeployとCloud Runの標準機能を最大限活用しています。カナリアデプロイでは、Cloud Runのリビジョン切り替え機能を使って、段階的に新しいバージョンをリリースしていくこともやっています。また、デプロイの進行をSlackと連携して可視化することも標準機能で行えます。各デプロイがどの段階にあるかを、チーム全体でリアルタイムに監視できる体制で運用を行っています。

また、Cloud Runのマニフェストはカスタマイズをシークレットマネージャーで管理しています。これによって異なる環境や設定に対しても、共通のベースを活用しながら柔軟にマニフェストを調整することが可能になっています。また、このような管理をすることによって、アプリケーションリポジトリ内でマニフェストを管理できるようになりましたので、インフラチームに依存せず、必要な変更を必要だと思った人がすぐに反映できるという迅速な開発体制も担うことができました。

このようなフルマネージドサービスの利用で、GKE時代のつらさを解消できました。その結果、最小構成のコスト比較では3割ほどの費用の削減ができました。また副次的な効果として、プロジェクトのエンジニアへの権限の委譲なども進められたという結果になります。

今後の展望をお話しします。柔軟にコスト最適化できるような構成にした結果、固定費のように料金がかかってくるようなサービスが割高に見えてきました。損益分岐点やプロジェクトに本当に必要なのかまで考慮しながら、よりスケーラブルな選択肢を検討中です。

岡村：具体的には、データベースでマスターデータの保存先としてCloud SQLを使っているのですが、Spannerに一本化してもいいのではないかという話があったり、検索エンジンとしてOpenSearch Serviceを使っているのですが、最近SpannerがFulltext Searchをサポートし始めましたので、これに寄せられるのではないかという話があったりします。また、弊社はGitLabのCIを自前で立てて運用しているのですが、GitHub/GitHub Actionsへ移行することなども視野に入れています。

画像生成のアーキテクチャ

岡村：画像生成サーバーとは、Stable Diffusion WebUIをホスティングしているサーバーのことを呼びます。やっていることはプロンプトをText to Image APIに投げて画像を生成しているだけなので、原理的には簡単なことをやっています。

岡村：ただ、実際に神ツクで生成している画像を見てみてください。コンセプトプランナーの金子 一馬らしさを一定反映した画像になっていることがわかると思います。このように、特定のクリエイティビティを過不足なく実現しつつ、安定して生成を行うためのアーキテクチャについて、詳しくご紹介していきます。

全体像としては、Pub/Subによって画像を生成してくださいという命令をリレーしており、最終的にCloud Tasks経由でデータベースやCloud Storageに永続化を行うという感じになっています。画像生成自体はRunPodというクラウドサービス上で構築しています。

岡村：ここで簡単に用語の解説をさせてください。初期生成とは、キャラの造形やポーズの大まかな方向性の生成、言うならばラフ画のようなものを生成していることを言います。そして画風変換とは、そのラフ画をもとに金子一馬のクリエイティビティに近づけつつ、再度生成し直すことを言います。

初期生成にはフルファインチューニングモデルを、画風変換にはSDXLベースモデルに加えてモデルの拡張モジュールであるLoRAを使用しています。フルファインチューニングモデルとLoRAについては、どちらもコロプラが独自に学習を行ったものを利用しています。

岡村：続いて、このような構成になるまでの変遷についてお話しします。最初期はSDXLベースモデルとLoRAのみを用いた生成方法を検証していました。この構成だとバリエーションがあまり出ないという問題がありました。学習データの特徴が強く反映してしまい、多彩な造形と画風の両立ができなかったのです。例えば、ゲームの主人公が被る特徴的な仮面が頻繁に生成されてしまうような状態でした。

岡村：そこで、フルファインチューニングモデルを利用してバリエーションを担保しようという構成にしました。

次に、フルファインチューニングモデルとLoRAを併用した検証では、バリエーションの問題を解決できたのですが、破綻する画像が出力されるケースが増えてしまうという問題がありました。髪なのかドレスなのかよくわからないものが生成されてしまうような事例です。異なる方向性・特性を持つモデルとLoRAを強引に適用すると、破綻する画像になってしまう確率が上がってしまうという結果でした。

岡村：このような問題があったので、初期生成と画風変換で段階を分けて生成しようという構成になりました。

初期生成と画風変換で2段階に分ける方向性になった最初期は、1つのサーバー上でリニアに生成を行っていました。その場合、1つの画像を生成するたびにSDXLベースモデルとフルファインチューニングモデルでモデルの切り替えを行う必要があり、ここでとても時間がかかっていました。期待するような生成速度が得られませんでした。

モデルファイルの実態は大容量ファイルですので、それぞれのステージで別のモデルをロードしようとするとオーバーヘッドが大きいです。また、1つのサーバーに2つのモデルをずっとキャッシュしておくことはマシンスペック上難しいので、サーバーごとに役割を分けて、常にキャッシュしたモデルを利用しようという形になりました。

岡村：その結果、生成速度が45%ほど短くなりました。モデルのロードがいかに遅いかということが感覚的におわかりいただけるかと思います。

ここまでの構成でクオリティの高い画像を安定して生成することが可能になりました。しかし次に、ランニングコストの問題が出てきました。

当初はGoogle Compute EngineのL4 GPUを使用してサーバーを構築していましたが、サービスインに必要なサーバー台数を見積もったところ、とてつもないランニングコストになることがわかりました。サービスの要求に耐えられるだけの数の画像を生成するには多数のGPUサーバーが必要で、それがほぼ24時間動くことを考えると、当然かなという感じです。

ということで、コスト圧縮を目的にRunPodへの移行を行いました。

岡村：RunPodについて軽く説明します。RunPodとは、AIや機械学習のワークロードに特化したクラウドGPUプラットフォームのことです。高性能なGPUを時間単位で従量課金で利用可能です。神ツクでは、在庫に比較的余裕のあるRTX4090を使用して構成しています。

RunPodで構成することに変えたことによって、生成時間が45%ほど短くなり、またサーバー1台あたりのコストも20%ほど安くすることが可能になりました。

RunPodの選定基準についてもう少し深く解説します。一番重要視していたことが、Google Cloudと同様の運用ができるという点です。つまり、チーム管理系の機能や権限管理などが充実していること、コンシューマーGPUをまとまった台数で安定して利用できること、ディスクイメージやカスタムコンテナイメージが使用可能であることなどです。

このような条件を満たすクラウドGPUプラットフォームは、実質的にはRunPodとVast.aiの二択でした。RunPodの方が柔軟にサーバーを借りられるという特徴がありましたので、今回は採用したという経緯となります。

このアーキテクチャで、リリース2か月で160万枚の画像を安定して生成することに成功しています。画像生成をゲームに組み込む際のアーキテクチャの1つの形ができました。

最後に、今後の課題感についてです。現状マシンが若干不安定です。具体的には起動や生成に通常よりも時間がかかってしまったり、時には完全に停止してしまう場合もあります。現在はアラートを起点に手動で再起動を行っているのですが、安定したマシンが望まれます。

また、デプロイの手順も若干複雑となっています。簡略化して誰でもメンテナンスできるような状況にしたいと思っています。

さらに、RunPod上では取得できるメトリクスが限られています。具体的には詳細なディスクI/Oやネットワークメトリクスが見られませんので、運用上の課題となっています。今後画像生成を組み込んだサービスを開発する際には、このような問題を解決できるサービスがあれば、その検討も行っていくというステータスです。

まとめ

岡村：前半ではコロプラの10年間を振り返って、当時の出来事やアーキテクチャの移り変わりを一緒に見ていただきました。最初期ではデータベースの問題がありましたので、Google Cloud＋GKE＋Spannerの構成になり、その後対戦ゲームが勃興しましたので、Agones＋OpenMatch＋DGSによる開発を行いました。

岡村：後半では新作の『神魔狩りのツクヨミ』における事例の紹介でした。運用負荷削減とコスト最適化を目指してCloud Runという構成を進めた話、またAIを使った新たな体験を目指して画像生成サーバーの構築を行った話をさせていただきました。

今日の発表でコロプラの日々の挑戦について身近に感じていただけたら幸いです。ご清聴ありがとうございました。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
アーキテクチャConference 2025

※動画の視聴にはFindyへのログインが必要です。