ゲーム・エンタメ最新情報のファミ通.com
取材・リポート
- モバイル・アプリ
『学マス』AIによってリリース前にレッスンを10億回、人力なら1900年分の検証を実現。バランスブレイカーを効率的に見つけ出すAI学習とデッキ探索【CEDEC2024】

『学マス』AIによってリリース前にレッスンを10億回、人力なら1900年分の検証を実現。バランスブレイカーを効率的に見つけ出すAI学習とデッキ探索【CEDEC2024】

2024.08.21 19:50

更新

　2024年8月21日（水）から23日（金）にかけて開催されている、日本最大のコンピュータエンターテインメント開発者向けカンファレンス“CEDEC2024（Computer Entertainment Developers Conference 2024）”。その初日に実施されたセッション、“『学園アイドルマスター』における適応的ゲームAIとグレーボックス最適化を用いたバランス調整支援システムの実現”の内容をお伝えする。

　講演者は株式会社サイバーエージェント所属のリサーチエンジニア・伊原滉也氏と、株式会社 QualiArts所属、『学園アイドルマスター』（以下、学マス）リードサーバーサイドエンジニア・那須勇弥氏のおふたり。

　本講演では、『学マス』のカードゲームパートにおけるバランス調整の支援についてAIを活用して実現した方法と、変化が激しい最新のゲーム環境にも適応できる“デッキ探索AI”の開発手法が解説された。

『学園アイドルマスター』関連商品を検索(Amazon)

『学園アイドルマスター』関連商品を検索(楽天)

膨大なパターンと追加要素への対応を目指したAI開発

　まずはプロジェクトの全体概要について。『学マス』は2024年5月16日にリリースされた、プロデュースをくり返すことでアイドルの歌やダンスが変化する育成シミュレーションゲームだ。本作でいう“プロデュース”とは、レッスンや試験と呼ばれるターン制カードゲームをこなし、目標を達成していくものとなっている。

本講演では、カードゲームパートであるレッスンのバランス調整を支援する仕組みに焦点を当てている。

　レッスンのバランス調整では、おもにレッスン中に使用する個々のカードやアイテムの性能の調整を行う。このバランス調整には、大きくふたつの課題が生じた。

　課題のひとつは、膨大な組み合わせのシチュエーションが存在すること。カードゲームはどんなに強いカードでもデッキの内容、手札の回りかた、プレイングによって発揮できる性能が左右される。たとえば、本作ではリリース時点のカードプールでもカードデッキの構築パターン数は10の20乗以上になった。

　また、ひとつのデッキによるレッスンのプレイパターンも、10の20乗から40乗以上の組み合わせが存在した。バランスブレイカーとなるカードやアイテムがあったとしても、この中から人力で見つけるのはあまりに困難。そこで開発陣は、“デッキ探索AI”と“レッスンAI”のふたつのAIを開発した。

　デッキ探索AIは、“グレーボックス最適化”（詳細は後述）を用いて膨大な組み合わせの中から強いデッキを探すAIだ。もうひとつのレッスンAIは、深層強化学習によって自動で人間と同じようなプレイを行うAIとなっている。これらを連携させて、より高得点を出せるカードやデッキを効率的に探索できるようにしたという。ただ、これらを現実的に運用するには大きな課題があった。

　その課題とは、比較的短い期間で新カードが追加されること。本作ではカードゲームに影響を与えるスキルカードやP（プロデュース）アイテムが、月に数回追加される。この運用スパンに対して、実用的な強さを発揮するレッスンAIの学習には、少なくとも10日以上の時間が必要となった。

　バランス調整の過程では、シミュレーションの実行結果を見て性能の調整を行い、再度シミュレーションを実行する必要があり、学習時間の長さからバランス調整のイテレーションを回しづらい状態だったとのこと。この課題に対しては、“転移学習”を用いたアプローチで学習時間の短縮を行ったという。

　具体的には、すべてのスキルカードやPアイテムの学習を行ったスクラッチ学習モデルをベースに、マスターデータの追加差分を転移学習で効率的に学習。都度スクラッチ学習をくり返すよりも高速に学習を完了できるようになり、学習にかかる時間を10時間程度まで短縮できた。これらのアプローチにより、プランナー完結で実行可能なバランス調整支援システムが実現するにいたったという。

バランス調整システムの構成と課題の解決

　講演では引き続き詳細の解説に入るにあたり、まずはバランス調整支援システムについて紹介された。

調整支援システムはQualiArtsの『学マス』開発チームと、サイバーエージェントのゲーム事業部AI戦略本部が連携して開発した。

　バランス調整支援システムのワークフローは、まず新しいスキルカードやPアイテムの効果を設計し、マスターデータを追加するところからスタート。つぎにレッスンAIの学習を行うが、ここではベースとなるモデルが存在しない場合、初回のみスクラッチ学習を行ない、モデルが存在する場合はベースモデルを選択して転移学習を実行する。

　さらに学習終了後、性能検証したいスキルカードやPアイテムを中心にデッキ探索を実行し、レッスンAIにカードゲームをプレイさせてシミュレーションを行う。そのシミュレーションログをGoogle CloudのBigQueryに蓄積し、スプレッドシートと連携させてデータの可視化を行い、結果を確認する。

結果に問題がある場合は再度効果パラメーター調整に戻り、問題がなければデバッグ検証してリリース作業に移行する。

　講演では、以降ワークフロー内の各詳細について解説された。

スクラッチ学習と転移学習

　この機能では深層強化学習によって学習したモデルの管理や、学習を実行する機能を提供。これらはレッスンのプレイスタイルが大きく変わる、“センス”と“ロジック”と呼ばれるプラン別に学習していく。

　管理コンソールではメタデータのみを管理し、モデルの実体はMLワークフローに特化した、W＆B（Weights＆Biases）プラットフォームに保持。学習の開始もこの画面から行い、たとえば転移学習を実行する際はベースにするモデルを選択し、学習を実行する。

エンジニアでなくとも扱いやすい作りを意識し、機械学習特有のハイパーパラメーターは一切入力しなくても実行できる構成になっている。

　本作のレッスンのコアとなるカードゲームロジックは、Unityリポジトリで開発されている。このコアロジックは“.NETランタイム”でも動かせるように、Unityに依存しないC#言語のみで実装されており、独立した.NETアプリケーション用のリポジトリに同期して処理を呼び出せる。

AIに関する処理はpythonで実装されており、pythonのレッスンAIプレイヤーと.NETアプリケーションがソケット通信で連携し、AIによるレッスンプレイを実行する。

　ただ、ここまで解説された機能だけでは、管理コンソールから確認できるモデルの情報が少なく、扱いやすい状態とは言えなかった。

　まず、モデルが何を学習したのかわかりづらい。この機能では、学習実行時のマスターデータ情報から学習させたスキルカードやPアイテムの状態を正確に把握するのに手間がかかる。この課題に対して、学習済みのモデル一覧画面や学習実行前にベースにしたモデルと学習内容の差分を視覚的にわかりやすく表示する機能を実装した。

　本作のスキルカードやPアイテムのマスターデータは数十個のテーブルから構成されており、効果内容に関係のない情報も多く含まれるため、そのまま比較するのは現実的ではない。そこで注目したのは“効果説明文”だ。本作のすべての効果説明文は、関連するマスターデータの設定から自動生成される仕組みになっている。つまり、効果内容に関する調整を行うと確実に効果説明文にも差分が現れるようになっており、単一の文字列化することができるため、規格処理を容易に実装することができた。

　扱いにくいポイントのふたつめは、モデルの強さがわかりづらい点。バランス調整のフローでモデルがうまくレッスンをプレイできない状態になっていた場合、デッキ探索のシミュレーション結果を信用することができなくなってしまう。この課題に対しては、モデルの強さを評価して可視化する機能を実装して解決したという。

　この機能では転移学習モデルによるレッスンプレイと、モンテカルロ木探索（※）によるレッスンプレイのスコアを比較し、可視化する。モンテカルロ木探索はレッスンプレイに時間がかかる代わりに学習を必要とせず、比較的精度の高いスコアを出せる手法として採用したとのこと。

※モンテカルロ木探索：ランダム性を用いることで途中不要な探索をやめ、ある程度の高確率でいい手を導くという探索アルゴリズム。囲碁やチェスのつぎの手の決定や、相手の手の内がすべててわかるわけではない対戦ゲームなどに用いられる。

学習完了後にモンテカルロ木探索と同じデッキや乱数を使って転移学習モデルでレッスンプレイ。スコアを比較してモデルの強さを確認できる。

デッキ探索とシミュレーションの結果確認

　本作開発におけるデッキ探索実行機能では、学習済みのスクラッチ学習モデル、または転移学習モデルを選択し、デッキ探索を実行する。こちらは学習機能と同様に、.NETとpythonのアプリケーションを連携で処理していく。

　デッキ探索機能のインフラは、Google CloudのCloud RunとBatchを中心としたサーバーレスアーキテクチャで構成。管理コンソールはCloud Runで稼働しており、デッキ探索処理は、.NETとpythonパイソンのランタイムを搭載した単一のマルチプロセスコンテナをBatchに配置して動かしている。

サーバーレスアーキテクチャーで構成したことで、複数のデッキ探索シミュレーションが並列実行可能になり、柔軟にスケールし効率的なシミュレーションを実行できるようになった。

　シミュレーション結果の確認には、Googleスプレッドシートを利用している。BigQueryに蓄積したログは、スプレッドシートのデータコネクターを使って同期しており、プランナーが扱い慣れているスプレッドシート上でデータを任意に加工し、分析することができる。

BigQueryには探索したデッキの情報やAIの行動がすべて蓄積。このログを集約することで、デッキのランキングやカードの使用率などの指標を確認できる。

　上記のバランス調整支援システムを導入した効果についても、具体的に紹介された。このシステムはサービス開始前から運用されており、サービス開始の時点で1億パターン以上のデッキのシミュレーションを実施していたという。レッスンプレイ回数の合計は10億回以上になり、これは人間が1回1分でプレイした場合、1900年かかる計算になるという。

　シミュレーションをくり返す中で、たとえば上位にランクインするデッキが特定のスキルカードだらけになるパターンや、特定のスキルカードの組み合わせで擬似的に無限ループを発生させられてしまうパターンが検出されており、実際にシミュレーション結果を見たあとに効果調整が行なわれた。また、約200件のバグの検出にも役立ったという。

ふたつのAIに求められた特化仕様の要件

　講演では引き続き、レッスンAIとデッキ探索AIの技術的詳細について解説された。

　まず大前提として、本作のレッスンとはプロデュース中に現れるターン制のひとりプレイカードゲームであり、スキルカードを使用してアイドルのパラメーターを上昇させ、決められたターン数以内にレッスン目標を達成することでクリアーとなる。プレイヤーには手札や山札のカードの効果を考えながら、どのカードを選択するか適切なプレイが求められる。

　本作のレッスンAIは、デッキ探索においてデッキを評価し、期待スコアを計算するのに使用。したがって、探索の過程であらゆるレッスン設定、デッキ設定でうまくプレイできるかを検証する。また、探索システムではくり返し膨大な数のレッスンをプレイする必要があり、一回あたりのプレイ時間をできるだけ短く抑える目標があった。これらを踏まえて、レッスンAIには以下の三点の要件を設定したという。

あらゆる状況で任意のカードがプレイ可能

　まずレッスンAIは、マルコフ決定過程（MDP）としてモデル化が可能であるといえる。MDPはつぎの状態を、現在の状態と行動から確率的に決めるモデルだ。本作のレッスンはゲーム盤面を現在の状態として、カード選択を行動として考えることで、カード選択によりつぎのターンの状態が決定するというMDPになっている。

レッスンのすべての要素はMDPにおける状態と行動に、このように割り振って定義できる。

　MDP上の展開型ゲームで有効な探索方法が、モンテカルロ木探索だ。この探索方法は、より厳密な最適行動を近似可能な手法であるが、レッスンやデッキ探索ひとつひとつに探索が必要であり、膨大な時間を要するという問題が出てくる。

実験の結果、4ターンのプレイでも約5分かかったという。これでは時間がかかりすぎる。

レッスンのプレイ時間が0.1秒以下

　プレイ時間の短縮のために、本作のAIでは深層強化学習により、レッスン・デッキ設定に汎化して最適なプレイを近似するシステムを構築した。さまざまな状況を試行錯誤によって学習させることで、あらゆる状況のプレイに適用可能になったわけだ。ただ、副次的な問題として経験が必要な問題設定が多く、学習に時間がかかるというところは課題となっている。