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

by COLOPL Inc.

Embed

Start on current slide

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

● 株式会社コロプラ ○ 技術基盤本部第2バックエンドエンジニア部 ○ バックエンドエンジニア ● 経歴 ○ 2020年新卒入社 ○ 『ユージェネライブ』 ○ 『白猫プロジェクト NEW WORLD'S』 ○ 『Brilliantcrypto』 ○ 『神魔狩りのツクヨミ』 ○ 『FANPARK』 ○ ● その他 ○ 週末バンドが趣味 🎸🥁🤘 ○ AIAgentを極めて自分の仕事を無くしたい岡村ごう

Slide 3

Slide 3 text

● 株式会社コロプラ ○ 技術基盤本部第2バックエンドエンジニア部部長 ○ 開発ディレクター / バックエンドエンジニア ● 経歴 ○ 2016年新卒入社 ○ 『白猫プロジェクト NEW WORLD'S』 ○ 『ユージェネライブ』 ○ 『モンスターユニバース』 ○ 『神魔狩りのツクヨミ』開発プロデューサー齋藤 Kevin 雄輔 3

Slide 4

Slide 4 text

コロプラについて

Slide 5

Slide 5 text

コロプラについて Vision 行動指針エンターテインメントで日常をより楽しく、より素晴らしく Mission

Slide 6

Slide 6 text

コロプラについて @COLOPL, Inc.

Slide 7

Slide 7 text

CONFIDENTIAL

Slide 8

Slide 8 text

金子一馬、コロプラ移籍後初タイトル金子一馬 1988年、株式会社アトラスに入社。『真・女神転生』シリーズや『ペルソナ』シリーズに携わり、コンセプトづくりから世界観の設計、キャラクターデザインなどを行う。多数のゲーム制作に携わった後、2023年コロプラに入社。本作『神魔狩りのツクヨミ』ではコンセプトプランナーとして、世界設定・シナリオ制作・アート・キャラクターデザインを担当。　コンセプトプランナー

Slide 9

Slide 9 text

ジャンル「ローグライクカードゲーム」金子一馬の創る世界 × タワマンローグライク戦闘はターン制カードバトル。探索中にランダムで手に入るカードやアイテムの取捨選択が重要。臨機応変に立ち回る柔軟な戦略が求められる。 ※本資料内の画像およびデータは開発段階のものです。実際の製品版とは一部異なる場合があります。東京、湾岸エリアにそびえ立つ最新鋭タワーマンション「THE HASHIRA」。異形の存在「神魔」が蔓延る閉鎖空間と化したこの地の調査が目的。 @COLOPL, Inc.

Slide 10

Slide 10 text

　〈AIカネコ〉と「オオカミ」ＡＩカネコ奇才・金子一馬のクリエイティビティを独自に学習させた、生まれたてのAI〈カネコ〉ゲーム作中に登場する偽神「オオカミ」に、〈AIカネコ〉を搭載 @COLOPL, Inc.

Slide 11

Slide 11 text

　「オオカミ」による“オリジナルカード”の生成プレイヤーの行動ログを参照して、新カードの制作が行われる AIが“カードの性能”を選択し、 “絵柄”も描き出す生み出された新カードは、世界に1枚の自分だけのユニークなカード ※本資料内の画像およびデータは開発段階のものです。実際の製品版とは一部異なる場合があります。 @COLOPL, Inc.

Slide 12

Slide 12 text

　ＡＩ調伏プログラム「盈月奉納の儀」〈AIカネコ〉の創造性は、まだまだ “創造主”たる金子一馬には及ばないプレイヤーからの支持が高いオリジナルカードを金子一馬自身の手によって選定・リファインするリファインされたカードは “新オフィシャルカード”としてゲーム内に実装 NEW CARD ？ちょうぶくえいげつＡＩカネコ ※本資料内の画像およびデータは開発段階のものです。実際の製品版とは一部異なる場合があります。 @COLOPL, Inc.

Slide 13

Slide 13 text

「神魔狩りのツクヨミ」とは新テクノロジーを“玩具”にし、プレイヤーと金子一馬とでAIを使役して遊ぶ ≪新たなゲーム体験創造≫への挑戦じんまがオモチャ

Slide 14

Slide 14 text

CONFIDENTIAL @COLOPL, Inc.

Slide 15

Slide 15 text

本題

Slide 16

Slide 16 text

アジェンダ 1 スマートフォンゲームの構成について 2 アーキテクチャ変遷のサマリー 3 神ツクのアーキテクチャ 4 画像生成のアーキテクチャ @COLOPL, Inc.

Slide 17

Slide 17 text

スマートフォンゲームとはスマホやタブレットなどのモバイル端末上で動作するゲーム ▶ 特徴 ► 高い携帯性 ► いつでもどこでも手軽にプレイ可能 ► ソーシャル要素 ► 他のプレイヤーとの協力、対戦、交流が可能 ► 継続的なコンテンツ配信 ► インターネット接続を活かして新しいコンテンツを提供

Slide 18

Slide 18 text

Web アプリケーションとほとんど同じ構造スマートフォンゲームの主要コンポーネント API サーバー Request Response クライアント言語：C#

Slide 19

Slide 19 text

より楽しいゲーム体験を実現するためにリアルタイムな通信を実現するための専用のサーバーが存在する場合があるリアルタイムサーバークライアント言語：C#

Slide 20

Slide 20 text

より楽しいゲーム体験を実現するために・移動したよ！・敵を倒した！・ターンエンド！リアルタイムサーバー（DGS）各クライアントに情報を反映

Slide 21

Slide 21 text

スマートフォンゲームの主要コンポーネント API サーバー Request Response クライアント言語：C# リアルタイムサーバー（DGS）

Slide 22

Slide 22 text

神ツクのアーキテクチャ

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

神ツクのアーキテクチャ

Slide 25

Slide 25 text

これまでの変遷

Slide 26

Slide 26 text

年表 2014 2016 2018 2020 2022 2024 指一本で本格的なアクションゲーム！現実がドラゴンクエストの世界に！シンプル操作でリアルなゴルフ体験！ 5分でサクッとチームバトル！モバイルでのリアルタイム対戦！ @COLOPL, Inc.

Slide 27

Slide 27 text

約10年前のアーキテクチャ

Slide 28

Slide 28 text

スマートフォンゲームのアクセスパターン新作ローンチ時やイベントリリース時は急激にアクセスが増加 @COLOPL, Inc.

Slide 29

Slide 29 text

当時よく発生した問題急激に伸びるユーザー数データ量及びクエリの増加によるデータベースの負荷の急上昇データベースが詰まって接続が不安定に...

Slide 30

Slide 30 text

当時の課題データベースをなんとかして運用コストを下げたい！

Slide 31

Slide 31 text

年表 2018 2020 2014 2016 2022 2024 指一本で本格的なアクションゲーム！現実がドラゴンクエストの世界に！シンプル操作でリアルなゴルフ体験！ 5分でサクッとチームバトル！モバイルでのリアルタイム対戦！ @COLOPL, Inc.

Slide 32

Slide 32 text

Slide 33

Slide 33 text

実質的に無制限のスケーリング変更: ユーザーデータに Spanner を採用　※ Spanner については別のカンファレンスで詳しく話したものがあります Google Cloud の分散型データベース ▶ ボタンひとつでスケールイン・スケールアウト ► オペレーション、運用にかかるコストの削減 ▶ コード側でシャーディングを意識する必要性が少ない ► アプリケーションコードのメンテナンス性の向上 ▶ ゼロダウンタイム ► コロプラの運用ポリシーと相性良し

Slide 34

Slide 34 text

変更: ワークロードの実行基盤に GKE を採用コンテナ型仮想化の台頭 Kubernetes の仕組みに乗ることで ● ホストエラー発生時の対応 ● 自前のデプロイスクリプトの管理 ● 自前のサーバー台数管理システムなどから解放され、運用コストがおよそ半分に！また、 Infrastructure as Code を推進することでインフラ構成を文章化し、運用・管理・オンボーディングなどのコスト削減！

Slide 35

Slide 35 text

Slide 36

Slide 36 text

この頃の社内におけるアーキテクチャ選定の考え Google Cloud + GKE + Spanner は大成功！今後の新作もこの組み合わせでやっていく！

Slide 37

Slide 37 text

一方その頃に開発中の新作タイトルは... 指一本で本格的なアクションゲーム！現実がドラゴンクエストの世界に！シンプル操作でリアルなゴルフ体験！ 5分でサクッとチームバトル！ 2022 2024 2014 2016 2018 2020 モバイルでのリアルタイム対戦！対戦！対戦！ @COLOPL, Inc.

Slide 38

Slide 38 text

社内で高まる気運社内のニーズ対戦型のゲームをうまく効率よく作っていきたい！対戦型ゲームの要件プレイヤーの操作をリアルタイムにゲーム内に反映帰結リアルタイムサーバーの活用が重要！

Slide 39

Slide 39 text

当時リアルタイムサーバーで抱えていた課題 ▶ 属人化 ► 高度な専門性を必要とするので、対応者が偏りがち ► チーム内の有識者が都度対応 ▶ 組織としての柔軟性が欠如 ► 個人に知識が集中 ► 進捗が個人の課題解決能力に依存 ▶ リアルタイム通信基盤を支える中心となるチームの誕生

Slide 40

Slide 40 text

リアルタイムのアーキテクチャ

Slide 41

Slide 41 text

DGS の管理についてクライアント API サーバーリアルタイムサーバー (DGS) A B C 従来までの動き・稼働中の DGS がある？・ルールに適している？・キャパ的に大丈夫？・etc… ふたりで遊びたい！ C を使って！

Slide 42

Slide 42 text

変更: DGS の管理に Agones を採用クライアント API サーバーリアルタイムサーバー (DGS) A B C 従来まで・稼働中の DGS がある？・ルールに適している？・キャパ的に大丈夫？・etc… 実装が大変！

Slide 43

Slide 43 text

変更: DGS の管理に Agones を採用クライアント API サーバーリアルタイムサーバー (DGS) A B C ふたりで遊びたい！ Agones 導入後 DGS ください C を割り当てました C を使って！

Slide 44

Slide 44 text

マッチメイキングについて 1.試合したい 2.チケット作成 3.マッチング対象チケット登録従来まで

Slide 45

Slide 45 text

マッチメイキングについて 8. チケット返却 10.マッチ候補リストアップ 9. マッチ候補返却 7. チケット取得 4.定期的にマッチ要求 5.トリガー 6.チケット要求従来まで

Slide 46

Slide 46 text

マッチメイキングについて 11. マッチ候補提出 12.評価依頼 13.評価結果 14. マッチ結果返却 15. マッチ結果返却従来まで

Slide 47

Slide 47 text

マッチメイキングについて 16.DGS 割り当て 17.チケット更新 18.チケット更新 19.次のリクエストでマッチしたチケットを返却従来まで

Slide 48

Slide 48 text

マッチメイキングについてコンポーネントの連携・実装が大変！従来まで Application (PHP)

Slide 49

Slide 49 text

変更: マッチメイキングに Open Match を採用 2. Match Proﬁle の定義 1. マッチングロジック仕組み作りから始める必要がなくなり、ゲームロジックの調整に集中できるように！ Open Match 導入後

Slide 50

Slide 50 text

効果 DGS / マッチングの基盤作りから解放！ API サーバー DGS DGS 対戦リクエストなどマッチ依頼 DGS 要求 DGS 割り当てゲームロジックに注力できるように！

Slide 51

Slide 51 text

と、ここまでが去年発表した内容 (詳細はアーカイブにて)

Slide 52

Slide 52 text

神ツクのアーキテクチャ

Slide 53

Slide 53 text

ここまでのアーキテクチャの課題 ▶ GKEの利用状況 ► ゲームタイトルごとにGoogleCloudプロジェクトを分離 ► 各プロジェクト内にも複数の環境（クラスタ）が存在 ▶ GKEアップグレードの運用負荷 ► 数ヶ月に一度コントロールプレーンとノードのバージョン更新が必要 ► 各プロジェクトの施策の合間を縫った形でのアップデートが必要 ► GKE導入タイトルが増えるほどアップグレード対象が増えていく ► 作業自体の重さ ✖ (プロジェクト数 ➕ 環境数) 🟰 🔥 ▶ GKE運用の組織課題 ► インフラとして幅広い業務があるメンバーが片手間で運用している

Slide 54

Slide 54 text

ここまでのアーキテクチャの課題 ▶ 自動化/Autopilot採用の難しさ ► アップグレード時に問題発生する確率が高い ► ノードOSのディスクドライバ周りでの不安定になった事例 ► カーネルパラメータの変更によって不安定になった事例 ► どれも動かしてみないとわからない ► GKE Standardでしかサポートされていないカスタムリソースを利用 ▶ 規模がシュリンクしていくと運用コストが目立ってきてサービス継続の妨げになる ► アーキテクチャがサービス継続の足枷になってしまう ► あってはならないこと

Slide 55

Slide 55 text

GKEの必然性について ... 🤔 ▶ リアルタイム要素がないゲームではAgonesやDGSを使わない ► 必ずしも、GKEである必要はない ▶ GKE上で運用しているコンポーネントはマネージドサービスで代替して、運用負荷とコストの最適化ができるのでは？ Cloud Runを含めたフルマネージドサービスを中心としたアーキテクチャを検討

Slide 56

Slide 56 text

年表現実がドラゴンクエストの世界に！シンプル操作でリアルなゴルフ体験！ 5分でサクッとチームバトル！ 2022 2024 2016 2018 2020 モバイルでのリアルタイム対戦！ 2025 生成AIを用いたローグライクカードバトル！ @COLOPL, Inc.

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

アーキテクチャ全体像

Slide 59

Slide 59 text

変更: Cloud Run ▶ コスト最適化がしやすい ► 利用したリソースの分だけ課金される ► 最低0台までスケールインできる ► リクエストがあった時だけ動く ► リクエストがなくなってから15分間ほどで停止 ► 夜間・休日稼働などを気にする必要なし ► 機能・施策毎に環境を作ることが多い弊社では特に助かる ► ノードリソースを意識しなくて良い ► 環境ごと柔軟に設定を変更しやすい ▶ オートスケーリング ► リクエスト数/CPUによる自動スケール

Slide 60

Slide 60 text

変更: ログ収集・集約 ▶ FluentBit => BigQuery ▶ OpenTelemetry Collector => Datadog Agent ► 「Google Cloud RunでのDatadog APM活用事例」(Findy Toolsに寄稿) ▶ Prometheus & Grafana => Cloud Monitoring & Datadog

Slide 61

Slide 61 text

変更: Cloud Task (Queue) ▶ スケールしやすいQueueシステム ► HTTPジョブハンドラがCloud Run上の普通のAPIリクエスト ► Laravel用のカスタムドライバライブラリを作成 ► 専用のCloud Runサービスに対してリクエストすることでジョブを処理 ► スケールイン/アウトはCloud Runに一定任せられる ▶ 自動でリトライ、指数バックオフ ▶ ※ at least one方式のためジョブ側で冪等性を担保する必要あり

Slide 62

Slide 62 text

変更: Cloud Deploy ▶ CloudDeploy + CloudRun の標準機能のみで実現 ► カナリアデプロイ ► CloudRunのリビジョン切り替え機能 ► デプロイの進行の可視化 ► CloudDeploy上でイベントが発生するとPub/Subに通知 ► サブスクライブしてSlack通知をする ▶ Kustomize と Secret Manager を併用してマニフェスト管理 ► アプリケーションのリポジトリで管理 ► 環境変数の変更をプロジェクトのエンジニアが可能に ► インフラチームへの依存が減った

Slide 63

Slide 63 text

▶ フルマネージドシステムの利用でGKE運用のつらみを解消 ▶ 最小構成のコストの比較で約3割減 ▶ 副次的な効果も ► プロジェクトのエンジニアへの権限移譲結果

Slide 64

Slide 64 text

▶ 固定費のかかるサービスが割高に見えてくる ► 損益分岐点や必要な機能を念頭に、より高スケーラブルな選択肢を検討 ► CloudSQL => Spanner, AlloyDB, Firestoreなど ► OpenSearch Service(検索エンジン) => Vertex AI Search, Spanner全文検索など ► GitLab + CI (self hosted) => GitHub + Actions ▶ コンテナの起動速度が遅い問題が顕在化 ► スパイクに対応しづらく、事前スケールアウトが必要 ► 無駄なコストがかかっている ► 起動プロセスの改善今後の展望

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

● Stable Diﬀusion Web UIをホスティングしているサーバー ● プロンプトをSDWebUI txt2img APIに投げて画像を生成 ○ 常駐のPythonプロセスから呼び出している画像生成サーバーとは 66

Slide 67

Slide 67 text

実際に生成した画像の例 67 @COLOPL, Inc.

Slide 68

Slide 68 text

画像生成サーバー全体像 68

Slide 69

Slide 69 text

画像生成サーバー詳細 69 画風 LoRA ControlNet 特徴を抽出 txt2img フルファインチューニングモデル txt2img SDXL V1.0 Baseモデル初期生成サーバー画風変換サーバー画像生成画像生成

Slide 70

Slide 70 text

画風LoRAだけではバリエーションがでない ▶ 学習データの一部である神ツクのキャラクターの特徴が強く反映 ▶ フルファインチューニングモデルを併用する方針へ ► バリエーションの問題は解決 ※AIモデルの検証過程で生成された画像 @COLOPL, Inc. 画風 LoRA txt2img SDXL V1.0 Baseモデル画像生成サーバー画像生成

Slide 71

Slide 71 text

1回で生成しようとすると破綻する ※AIモデルの検証過程で生成された画像 @COLOPL, Inc. 画風 LoRA フルファインチューニングモデル画像生成画像生成サーバー ▶ モデル, LoRA などで出力を強制するほど、絵として破綻しやすくなる ▶ 生成を2回に分ける方向性へ ► 破綻する確率が大きく下がった txt2img

Slide 72

Slide 72 text

1本のパイプラインだと速度が遅い ▶ モデル切り替えが都度発生 ► モデルファイルの実体は、大容量ファイル！(6.5GB) ► 初期生成と画風変換の度にモデルロードし直すのが非常に無駄 ► キャッシュするオプションはあるが、マシンスペック上できない ▶ 2系統のサーバーを用意し、常にキャッシュしてモデルを利用 ► 生成時間を約45%削減画風 LoRA ControlNet 特徴を抽出 txt2img フルファインチューニングモデル txt2img SDXL V1.0 Baseモデル画像生成サーバー画像生成画像生成

Slide 73

Slide 73 text

ランニングコストの問題 73 画風 LoRA ControlNet 特徴を抽出 txt2img フルファインチューニングモデル txt2img SDXL V1.0 Baseモデル初期生成サーバー画風変換サーバー画像生成画像生成 ▶ 当初 GCE 上で L4GPU を使用 ▶ 必要台数の見積もりの結果問題が判明 ► 多数のGPUサーバーが必要 ► これが、ほぼ24時間起動するのでコストは... 🔥

Slide 74

Slide 74 text

Runpodへの移行 ▶ AIや機械学習のワークロードに特化したクラウドGPUプラットフォーム ► 高性能なGPUを時間単位の従量課金で利用可能 ► 比較的在庫に余裕がある RTX4090 を使用 ► 生成時間を約70%削減 ► 1台あたりのコストを約20%削減 ▶ Google Cloudと同じ様に運用できることが選定の条件 ► チーム管理系(権限等)の機能がある ► コンシューマGPUをまとまった台数で安定してリリースできる ► 実質 Runpod か Vast.ai の2択 ► Runpodの方が柔軟にサーバー借りることができるので採用

Slide 75

Slide 75 text

画像生成サーバー詳細 (再掲) 75 画風 LoRA ControlNet 特徴を抽出 txt2img フルファインチューニングモデル txt2img SDXL V1.0 Baseモデル初期生成サーバー画風変換サーバー画像生成画像生成

Slide 76

Slide 76 text

まとめ画像生成をゲームに組み込むアーキテクチャの一つの形ができた！ @COLOPL, Inc.

Slide 77

Slide 77 text

今後の課題 ▶ マシンが若干不安定 ► まれに起動や生成に10倍以上の時間がかかったり、止まったりする ▶ デプロイが若干複雑 ► モデルファイルや環境は丸ごとネットワークディスクに配置 ► リージョン障害が起きた場合にはディスク構築をしててデプロイ ▶ ドキュメントの情報不足 ▶ 取得できるメトリクスが限られている ► 各種リソース使用率/割り当て数等は主要なエクスポータで取得可能 ► 詳細なディスクI/Oやネットワークメトリクスは未提供 ▶ よりよい選択肢も引き続き検討

Slide 78

Slide 78 text

まとめ 2014 2019 2024 データベースが詰まってしまう... Google Cloud + GKE + Spanner 構成へ対戦型ゲームの開発の盛り上がりを受けて... Agones + Open Match + DGS によるマルチ開発 2026 これからも挑戦は続く... 運用負荷削減とコスト効率最適化 & AIを使った新たな体験を目指して ... CloudRun 構成という選択肢 + 画像生成サーバーの構築

Slide 79

Slide 79 text

● 技術情報発信しているのでフォローしてもらえると嬉しいです！ ○ 「アーキテクチャ Conference 2024」登壇時の資料や ○ 「 PHP Conference Japan 2024」登壇時の記事など技術ブログで公開しています ○ 登壇者・執筆者のモチベーションにつながるので立ち寄ってもらえればと🙏🙇 最後に宣伝 COLOPL Tech Blog https://blog.colopl.dev/

Slide 80

Slide 80 text

ご清聴ありがとうございました！ @COLOPL, Inc.