Cloud Runでコロプラが挑む 生成AI×ゲーム『神魔狩りのツクヨミ』の裏側

アーキテクチャConference 2025
https://architecture-con.findy-tools.io/2025

Cloud Runでコロプラが挑む生成AI×ゲーム『神魔狩りのツクヨミ』の裏側
岡村 ごう / 齋藤 Kevin 雄輔

Transcript

1. 株式会社コロプラ Cloud Runでコロプラが挑む 生成AI×ゲーム『神魔狩りのツクヨミ』の裏側 2025.11.21
2. • 株式会社コロプラ ◦ 技術基盤本部 第2バックエンドエンジニア部 ◦ バックエンドエンジニア • 経歴 ◦ 2020年新卒入社 ◦ 『ユージェネライブ』 ◦ 『白猫プロジェクト NEW WORLD'S』 ◦ 『Brilliantcrypto』 ◦ 『神魔狩りのツクヨミ』 ◦ 『FANPARK』 ◦ • その他 ◦ 週末バンドが趣味 🎸🥁🤘 ◦ AIAgentを極めて自分の仕事を無くしたい 岡村 ごう
3. • 株式会社コロプラ ◦ 技術基盤本部 第2バックエンドエンジニア部 部長 ◦ 開発ディレクター / バックエンドエンジニア • 経歴 ◦ 2016年新卒入社 ◦ 『白猫プロジェクト NEW WORLD'S』 ◦ 『ユージェネライブ』 ◦ 『モンスターユニバース』 ◦ 『神魔狩りのツクヨミ』 開発プロデューサー 齋藤 Kevin 雄輔 3
4. コロプラについて
5. コロプラについて Vision 行動指針 エンターテインメントで日常をより楽しく、より素晴らしく Mission
6. コロプラについて @COLOPL, Inc.
7. CONFIDENTIAL
8. 金子一馬、コロプラ移籍後 初タイトル 金子一馬 1988年、株式会社アトラスに入社。『真・女神転生』シリーズ や『ペルソナ』シリーズ に携わり、 コンセプトづくりから世界観の設計、キャラクターデザインなどを行う。 多数のゲーム制作に携わった後、2023年コロプラに入社。 本作『神魔狩りのツクヨミ』では コンセプトプランナー として、 世界設定・シナリオ制作・アート・キャラクターデザイン を担当。 　コンセプトプランナー
9. ジャンル「ローグライクカードゲーム」 金子一馬の創る世界 × タワマンローグライク 戦闘はターン制カードバトル。 探索中にランダムで手に入る カードやアイテムの取捨選択が重要。 臨機応変に立ち回る柔軟な戦略が求められる。 ※本資料内の画像およびデータは開発段階のものです。実際の製品版とは一部異なる場合があります。 東京、湾岸エリアにそびえ立つ 最新鋭タワーマンション「THE HASHIRA」。 異形の存在「神魔」が蔓延る 閉鎖空間と化したこの地の調査が目的。 @COLOPL, Inc.
10. 　 〈AIカネコ〉と「オオカミ」 ＡＩ カネコ 奇才・金子一馬のクリエイティビティを 独自に学習させた、生まれたてのAI〈カネ コ〉 ゲーム作中に登場する偽神「オオカミ」 に、 〈AIカネコ〉を搭載 @COLOPL, Inc.
11. 　「オオカミ」による“オリジナルカード”の生成 プレイヤーの行動ログを参照し て、 新カードの制作が行われる AIが“カードの性能”を選択し、 “絵柄”も描き出す 生み出された新カードは、 世界に1枚の自分だけのユニークなカード ※本資料内の画像およびデータは開発段階のものです。実際の製品版とは一部異なる場合があります。 @COLOPL, Inc.
12. 　 ＡＩ調伏プログラム「盈月奉納の儀」 〈AIカネコ〉の創造性は、まだまだ “創造主”たる金子一馬には及ばない プレイヤーからの支持が高いオリジナルカードを 金子一馬自身の手によって 選定・リファインする リファインされたカードは “新オフィシャルカード”として ゲーム内に実装 NEW CARD ？ ちょう ぶく えい げつ ＡＩ カネコ ※本資料内の画像およびデータは開発段階のものです。実際の製品版とは一部異なる場合があります。 @COLOPL, Inc.
13. 「神魔狩りのツクヨミ」とは 新テクノロジーを“玩具”にし、 プレイヤーと金子一馬とでAIを使役して遊ぶ ≪新たなゲーム体験創造≫への挑戦 じん ま が オモチャ
14. CONFIDENTIAL @COLOPL, Inc.
15. 本題
16. アジェンダ 1 スマートフォンゲームの構成について 2 アーキテクチャ変遷のサマリー 3 神ツクのアーキテクチャ 4 画像生成のアーキテクチャ @COLOPL, Inc.
17. スマートフォンゲームとは スマホやタブレットなどのモバイル端末上で動作するゲーム ▶ 特徴 ► 高い携帯性 ► いつでもどこでも手軽にプレイ可能 ► ソーシャル要素 ► 他のプレイヤーとの協力、対戦、交流が可能 ► 継続的なコンテンツ配信 ► インターネット接続を活かして新しいコンテンツを提供
18. Web アプリケーションとほとんど同じ構造 スマートフォンゲームの主要コンポーネント API サーバー Request Response クライアント 言語：C#
19. より楽しいゲーム体験を実現するために リアルタイムな通信を実現するための専用のサーバーが存在する場合がある リアルタイムサーバー クライアント 言語：C#
20. より楽しいゲーム体験を実現するために ・移動したよ！ ・敵を倒した！ ・ターンエンド！ リアルタイムサーバー（DGS） 各クライアントに 情報を反映
21. スマートフォンゲームの主要コンポーネント API サーバー Request Response クライアント 言語：C# リアルタイムサーバー（DGS）
22. 神ツクのアーキテクチャ
23. GKEタイトルのアーキテクチャ Google Cloud Kubernetes Cluster Monitoring Prometheus Queue Workers GKE Pods Queue RabbitMQ (VM) Master Data MySQL (VM) Multiple Replicas Cache Memory Store API Gateway Load Balancer KPI Analytics BigQuery Logs Cloud Logging LB Phone Google認証 Cloud IAP Admin Server GKE Pods Visualization Grafana User Search Elasticsearch API Servers GKE Pods Twemproxy LB 管理者 Admin Pubsub Redis User Data Cloud Spanner
24. 神ツクのアーキテクチャ
25. これまでの変遷
26. 年表 2014 2016 2018 2020 2022 2024 指一本で本格的な アクションゲーム！ 現実が ドラゴンクエストの世界に！ シンプル操作で リアルなゴルフ体験！ 5分でサクッと チームバトル！ モバイルでの リアルタイム対戦！ @COLOPL, Inc.
27. 約10年前のアーキテクチャ
28. スマートフォンゲームのアクセスパターン 新作ローンチ時やイベントリリース時は急激にアクセスが増加 @COLOPL, Inc.
29. 当時よく発生した問題 急激に伸びるユーザー数 データ量及びクエリの増加によるデータベースの負荷の急上昇 データベースが詰まって接続が不安定に...
30. 当時の課題 データベースをなんとかして 運用コストを下げたい！
31. 年表 2018 2020 2014 2016 2022 2024 指一本で本格的な アクションゲーム！ 現実が ドラゴンクエストの世界に！ シンプル操作で リアルなゴルフ体験！ 5分でサクッと チームバトル！ モバイルでの リアルタイム対戦！ @COLOPL, Inc.
32. GKEタイトルのアーキテクチャ Google Cloud Kubernetes Cluster Monitoring Prometheus Queue Workers GKE Pods Queue RabbitMQ (VM) Master Data MySQL (VM) Multiple Replicas Cache Memory Store API Gateway Load Balancer KPI Analytics BigQuery Logs Cloud Logging LB Phone Google認証 Cloud IAP Admin Server GKE Pods Visualization Grafana User Search Elasticsearch API Servers GKE Pods Twemproxy LB 管理者 Admin Pubsub Redis User Data Cloud Spanner
33. 実質的に無制限のスケーリング 変更: ユーザーデータに Spanner を採用 　※ Spanner については別のカンファレンスで詳しく話したものがあります Google Cloud の分散型データベース ▶ ボタンひとつでスケールイン・スケールアウト ► オペレーション、運用にかかるコストの削減 ▶ コード側でシャーディングを意識する必要性が少ない ► アプリケーションコードのメンテナンス性の向上 ▶ ゼロダウンタイム ► コロプラの運用ポリシーと相性良し
34. 変更: ワークロードの実行基盤に GKE を採用 コンテナ型仮想化の台頭 Kubernetes の仕組みに乗ることで • ホストエラー発生時の対応 • 自前のデプロイスクリプトの管理 • 自前のサーバー台数管理システム などから解放され、運用コストがおよそ半分に！ また、 Infrastructure as Code を推進することでインフラ構成を文章化し、 運用・管理・オンボーディングなどのコスト削減！
35. 効果 最大規模のタイトルの 安定運用に成功！ ここ6年間で大きな サービスダウンはなし！ © ARMOR PROJECT/BIRD STUDIO/SQUARE ENIX All Rights Reserved.
36. この頃の社内におけるアーキテクチャ選定の考え Google Cloud + GKE + Spanner は大成功！ 今後の新作もこの組み合わせでやっていく！
37. 一方その頃に開発中の新作タイトルは... 指一本で本格的な アクションゲーム！ 現実が ドラゴンクエストの世界に！ シンプル操作で リアルなゴルフ体験！ 5分でサクッと チームバトル！ 2022 2024 2014 2016 2018 2020 モバイルでの リアルタイム対戦！ 対戦！ 対戦！ @COLOPL, Inc.
38. 社内で高まる気運 社内のニーズ 対戦型のゲームをうまく効率よく作っていきたい！ 対戦型ゲームの要件 プレイヤーの操作をリアルタイムにゲーム内に反映 帰結 リアルタイムサーバーの活用が重要！
39. 当時リアルタイムサーバーで抱えていた課題 ▶ 属人化 ► 高度な専門性を必要とするので、対応者が偏りがち ► チーム内の有識者が都度対応 ▶ 組織としての柔軟性が欠如 ► 個人に知識が集中 ► 進捗が個人の課題解決能力に依存 ▶ リアルタイム通信基盤を支える中心となるチームの誕生
40. リアルタイムのアーキテクチャ
41. DGS の管理について クライアント API サーバー リアルタイムサーバー (DGS) A B C 従来までの動き ・稼働中の DGS がある？ ・ルールに適している？ ・キャパ的に大丈夫？ ・etc… ふたりで遊びたい！ C を使って！
42. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS) A B C 従来まで ・稼働中の DGS がある？ ・ルールに適している？ ・キャパ的に大丈夫？ ・etc… 実装が大変！
43. 変更: DGS の管理に Agones を採用 クライアント API サーバー リアルタイムサーバー (DGS) A B C ふたりで遊びたい！ Agones 導入後 DGS ください C を割り当てました C を使って！
44. マッチメイキングについて 1.試合したい 2.チケット作成 3.マッチング対象チケット登録 従来まで
45. マッチメイキングについて 8. チケット返却 10.マッチ候補リストアップ 9. マッチ候補返却 7. チケット取得 4.定期的にマッチ要求 5.トリガー 6.チケット要求 従来まで
46. マッチメイキングについて 11. マッチ候補提出 12.評価依頼 13.評価結果 14. マッチ結果返却 15. マッチ結果返却 従来まで
47. マッチメイキングについて 16.DGS 割り当て 17.チケット更新 18.チケット更新 19.次のリクエストで マッチしたチケットを返却 従来まで
48. マッチメイキングについて コンポーネントの 連携・実装が大変！ 従来まで Application (PHP)
49. 変更: マッチメイキングに Open Match を採用 2. Match Profile の定義 1. マッチングロジック 仕組み作りから始める必 要がなくなり、ゲームロ ジックの調整に集中でき るように！ Open Match 導入後
50. 効果 DGS / マッチング の基盤作りから解放！ API サーバー DGS DGS 対戦リクエストなど マッチ依頼 DGS 要求 DGS 割り当て ゲームロジックに 注力できるように！
51. と、ここまでが去年発表した内容 (詳細はアーカイブにて)
52. 神ツクのアーキテクチャ
53. ここまでのアーキテクチャの課題 ▶ GKEの利用状況 ► ゲームタイトルごとにGoogleCloudプロジェクトを分離 ► 各プロジェクト内にも複数の環境（クラスタ）が存在 ▶ GKEアップグレードの運用負荷 ► 数ヶ月に一度コントロールプレーンとノードのバージョン更新が必要 ► 各プロジェクトの施策の合間を縫った形でのアップデートが必要 ► GKE導入タイトルが増えるほどアップグレード対象が増えていく ► 作業自体の重さ ✖ (プロジェクト数 ➕ 環境数) 🟰 🔥 ▶ GKE運用の組織課題 ► インフラとして幅広い業務があるメンバーが片手間で運用している
54. ここまでのアーキテクチャの課題 ▶ 自動化/Autopilot採用の難しさ ► アップグレード時に問題発生する確率が高い ► ノードOSのディスクドライバ周りでの不安定になった事例 ► カーネルパラメータの変更によって不安定になった事例 ► どれも動かしてみないとわからない ► GKE Standardでしかサポートされていないカスタムリソースを利用 ▶ 規模がシュリンクしていくと運用コストが目立ってきてサービス継続の 妨げになる ► アーキテクチャがサービス継続の足枷になってしまう ► あってはならないこと
55. GKEの必然性について ... 🤔 ▶ リアルタイム要素がないゲームではAgonesやDGSを使わない ► 必ずしも、GKEである必要はない ▶ GKE上で運用しているコンポーネントはマネージドサービスで代替して、運 用負荷とコストの最適化ができるのでは？ Cloud Runを含めた フルマネージドサービスを中心としたアーキテクチャを検討
56. 年表 現実が ドラゴンクエストの世界に！ シンプル操作で リアルなゴルフ体験！ 5分でサクッと チームバトル！ 2022 2024 2016 2018 2020 モバイルでの リアルタイム対戦！ 2025 生成AIを用いた ローグライクカードバトル！ @COLOPL, Inc.
57. GKEタイトルのアーキテクチャ (再掲) Google Cloud Kubernetes Cluster Monitoring Prometheus Queue Workers GKE Pods Queue RabbitMQ (VM) Master Data MySQL (VM) Multiple Replicas Cache Memory Store API Gateway Load Balancer KPI Analytics BigQuery Logs Cloud Logging LB Phone Google認証 Cloud IAP Admin Server GKE Pods Visualization Grafana User Search Elasticsearch API Servers GKE Pods Twemproxy LB 管理者 Admin Pubsub Redis User Data Cloud Spanner
58. アーキテクチャ全体像
59. 変更: Cloud Run ▶ コスト最適化がしやすい ► 利用したリソースの分だけ課金される ► 最低0台までスケールインできる ► リクエストがあった時だけ動く ► リクエストがなくなってから15分間ほどで停止 ► 夜間・休日稼働などを気にする必要なし ► 機能・施策毎に環境を作ることが多い弊社では特に助かる ► ノードリソースを意識しなくて良い ► 環境ごと柔軟に設定を変更しやすい ▶ オートスケーリング ► リクエスト数/CPUによる自動スケール
60. 変更: ログ収集・集約 ▶ FluentBit => BigQuery ▶ OpenTelemetry Collector => Datadog Agent ► 「Google Cloud RunでのDatadog APM活用事例」(Findy Toolsに寄稿) ▶ Prometheus & Grafana => Cloud Monitoring & Datadog
61. 変更: Cloud Task (Queue) ▶ スケールしやすいQueueシステム ► HTTPジョブハンドラがCloud Run上の普通のAPIリクエスト ► Laravel用のカスタムドライバライブラリを作成 ► 専用のCloud Runサービスに対してリクエストすることでジョブを処理 ► スケールイン/アウトはCloud Runに一定任せられる ▶ 自動でリトライ、指数バックオフ ▶ ※ at least one方式のためジョブ側で冪等性を担保する必要あり
62. 変更: Cloud Deploy ▶ CloudDeploy + CloudRun の標準機能のみで実現 ► カナリアデプロイ ► CloudRunのリビジョン切り替え機能 ► デプロイの進行の可視化 ► CloudDeploy上でイベントが発生するとPub/Subに通知 ► サブスクライブしてSlack通知をする ▶ Kustomize と Secret Manager を併用してマニフェスト管理 ► アプリケーションのリポジトリで管理 ► 環境変数の変更をプロジェクトのエンジニアが可能に ► インフラチームへの依存が減った
63. ▶ フルマネージドシステムの利用でGKE運用のつらみを解消 ▶ 最小構成のコストの比較で約3割減 ▶ 副次的な効果も ► プロジェクトのエンジニアへの権限移譲 結果
64. ▶ 固定費のかかるサービスが割高に見えてくる ► 損益分岐点や必要な機能を念頭に、より高スケーラブルな選択肢を検討 ► CloudSQL => Spanner, AlloyDB, Firestoreなど ► OpenSearch Service(検索エンジン) => Vertex AI Search, Spanner全文 検索など ► GitLab + CI (self hosted) => GitHub + Actions ▶ コンテナの起動速度が遅い問題が顕在化 ► スパイクに対応しづらく、事前スケールアウトが必要 ► 無駄なコストがかかっている ► 起動プロセスの改善 今後の展望
65. 画像生成のアーキテクチャ
66. • Stable Diffusion Web UIをホスティングしているサーバー • プロンプトをSDWebUI txt2img APIに投げて画像を生成 ◦ 常駐のPythonプロセスから呼び出している 画像生成サーバーとは 66
67. 実際に生成した画像の例 67 @COLOPL, Inc.
68. 画像生成サーバー全体像 68
69. 画像生成サーバー詳細 69 画風 LoRA ControlNet 特徴を抽出 txt2img フルファイン チューニング モデル txt2img SDXL V1.0 Baseモデル 初期生成 サーバー 画風変換サーバー 画像生成 画像生成
70. 画風LoRAだけではバリエーションがでない ▶ 学習データの一部である 神ツクのキャラクターの特徴が強く反映 ▶ フルファインチューニングモデルを併用する方針へ ► バリエーションの問題は解決 ※AIモデルの検証過程で生成された画像 @COLOPL, Inc. 画風 LoRA txt2img SDXL V1.0 Baseモデル 画像生成サーバー 画像生成
71. 1回で生成しようとすると破綻する ※AIモデルの検証過程で生成された画像 @COLOPL, Inc. 画風 LoRA フルファイン チューニング モデル 画像生成 画像生成サーバー ▶ モデル, LoRA などで出力を強制するほど、 絵として破綻しやすくなる ▶ 生成を2回に分ける方向性へ ► 破綻する確率が大きく下がった txt2img
72. 1本のパイプラインだと速度が遅い ▶ モデル切り替えが都度発生 ► モデルファイルの実体は、大容量ファイル！(6.5GB) ► 初期生成と画風変換の度にモデルロードし直すのが非常に無駄 ► キャッシュするオプションはあるが、マシンスペック上できない ▶ 2系統のサーバーを用意し、常にキャッシュしてモデルを利用 ► 生成時間を約45%削減 画風 LoRA ControlNet 特徴を抽出 txt2img フルファイン チューニング モデル txt2img SDXL V1.0 Baseモデル 画像生成サーバー 画像生成 画像生成
73. ランニングコストの問題 73 画風 LoRA ControlNet 特徴を抽出 txt2img フルファイン チューニング モデル txt2img SDXL V1.0 Baseモデル 初期生成 サーバー 画風変換サーバー 画像生成 画像生成 ▶ 当初 GCE 上で L4GPU を使用 ▶ 必要台数の見積もりの結果問題が判明 ► 多数のGPUサーバーが必要 ► これが、ほぼ24時間起動するのでコストは... 🔥
74. Runpodへの移行 ▶ AIや機械学習のワークロードに特化したクラウドGPUプラットフォーム ► 高性能なGPUを時間単位の従量課金で利用可能 ► 比較的在庫に余裕がある RTX4090 を使用 ► 生成時間を約70%削減 ► 1台あたりのコストを約20%削減 ▶ Google Cloudと同じ様に運用できることが選定の条件 ► チーム管理系(権限等)の機能がある ► コンシューマGPUをまとまった台数で安定してリリースできる ► 実質 Runpod か Vast.ai の2択 ► Runpodの方が柔軟にサーバー借りることができるので採用
75. 画像生成サーバー詳細 (再掲) 75 画風 LoRA ControlNet 特徴を抽出 txt2img フルファイン チューニング モデル txt2img SDXL V1.0 Baseモデル 初期生成 サーバー 画風変換サーバー 画像生成 画像生成
76. まとめ 画像生成を ゲームに組み込む アーキテクチャの 一つの形ができた！ @COLOPL, Inc.
77. 今後の課題 ▶ マシンが若干不安定 ► まれに起動や生成に10倍以上の時間がかかったり、止まったりする ▶ デプロイが若干複雑 ► モデルファイルや環境は丸ごとネットワークディスクに配置 ► リージョン障害が起きた場合にはディスク構築をしててデプロイ ▶ ドキュメントの情報不足 ▶ 取得できるメトリクスが限られている ► 各種リソース使用率/割り当て数等は主要なエクスポータで取得可能 ► 詳細なディスクI/Oやネットワークメトリクスは未提供 ▶ よりよい選択肢も引き続き検討
78. まとめ 2014 2019 2024 データベースが詰まってしまう... Google Cloud + GKE + Spanner 構成へ 対戦型ゲームの開発の盛り上がりを受けて... Agones + Open Match + DGS によるマルチ開発 2026 これからも挑戦は続く... 運用負荷削減とコスト効率最適化 & AIを使った新たな体験を目指して ... CloudRun 構成という選択肢 + 画像生成サーバーの構築
79. • 技術情報発信しているのでフォローしてもらえると嬉しいです！ ◦ 「アーキテクチャ Conference 2024」登壇時の資料や ◦ 「 PHP Conference Japan 2024」登壇時の記事など技術ブログで公開しています ◦ 登壇者・執筆者のモチベーションにつながるので立ち寄ってもらえればと🙏🙇 最後に宣伝 COLOPL Tech Blog https://blog.colopl.dev/
80. ご清聴ありがとうございました！ @COLOPL, Inc.