 |
このセッションでは，PS5のシステムソフトウェアのQA（品質保証）における一部の機能テストで活用しているという，ゲームプレイ自動化を実現するAI技術が紹介された。スピーカーは，以下の3名である。
 |
システムソフトウェアQAの取り組み
PS5は，ホームやコントロールセンターなどのシステム機能を有しているが，それらシステムソフトウェアの表示内容や画面遷移といった内容に関する品質を担保するため，システムソフトウェアQAチーム（以下，QAチーム）ではテストの自動化を積極的に採り入れているという。
 |
テスト自動化のメリットはいくつかあるそうだが，例として，ソフトウェアがリリースされるまでの間に継続してテストを行えることが挙げられた。これが手動テストだと，ケース・バイ・ケースではあるが，多くの場合は1プロジェクトの間で数回に留まるとのこと。
そうなると以下のスライドのように赤い矢印のタイミングでバグが混入したとなった場合，その検出は青い矢印で示されたプロジェクト終盤のテスト時となり，リリースに影響するリスクが出てしまう。
 |
一方，自動テストであれば毎日でも実施可能であり，緑色の矢印のタイミングですぐにバグを検出できるため，「バグの早期発見」というメリットが生じる。また，開発コードのコミット前に自動テストを実施できれば，バグの混入も防止できるとのこと。
そのような観点から，QAチームではテスト自動化を推進しているわけだが，ゲームプレイに連動したシステム機能に関しては，少し考慮する必要があるという。
その1つが現在プレイ中のゲームにおける進行状況などをカードとして表示する「アクティビティ」で，カードに進行度や推定プレイ時間などが正しく表示されるかどうかもQAの対象となる。また，カードの内容がゲームプレイに応じて変化することもあり，その変化に関する部分が正しく動いているかなどもQAの対象であることが示された。
 |
さらにシステムソフトウェアの機能テストには，アクティビティの更新内容を確認するときなど，ある程度のゲームプレイが必要なケースもある。そのため，効率化や不具合の早期発見などの観点からは，このゲームプレイも自動化することが望ましい。
 |
ゲームプレイに連動したシステムソフトウェアの機能はアクティビティ以外にもあり，タイトルによって使われているものとそうでないものとがある。そのため，ゲームプレイに連動した機能のテストを自動化する際には，タイトル依存のない汎用的な形での自動化が求められる。
加えて，その自動テストは人間のプレイヤーと同じ条件，つまり画面情報と音声情報のみを使ったものであることが求められる。そうした制約のため，ゲームプレイに連動した機能の自動テストは極めてハードルが高かったそうだ。
 |
自動プレイシステムの概要
上記のとおり，PS5のシステムソフトウェアの機能テストには，利用可能な情報がゲームの画面情報と音声情報のみであること，また特定のゲームタイトルに依存しない汎用的な技術であることが求められる。また，QAの現場に持ち込むためには，現実的なコストで自動化を実現できることも必要だ。
そうした制約を踏まえ，QAチームでは人間のプレイを学習して再現する技術である「模倣学習」をベースに，複数の技術を組み合わせて自動プレイシステムを開発したという。
本セッションでは，PS5にプリインストールされている「ASTRO's PLAYROOM」の事例を使って，この自動プレイシステムの概要などが紹介された。このシステムはPC上で動作し，PS5からゲーム情報として画面情報のみを取得している。そのうえで，システムがコントローラの操作内容を決定し，それをPS5に送信することにより，ゲームを自動で操作している。
 |
また，このシステムでは2種類のエージェントを使ってゲームを自動操作する。1つは「リプレイエージェント」と呼ばれるもので，事前に記録した手動のゲームプレイを再生することで，その手動プレイと同じ操作内容を再現する。
もう1つの「模倣エージェント」は，機械学習の1つである模倣学習によって人間のゲームプレイを学習したAIモデルが，人間のゲームを再現する。
 |
リプレイエージェントは，事前の手動プレイとまったく同じコントローラの操作を再現するという性質上，ランダムな要素が一切存在せず，常に同じ操作で進行可能なシーンのみで利用することとなる。
具体的には，タイトル画面でゲームをスタートさせるなどの一部のUI操作や，スタート地点とゴール地点が常に変わらない固定ルートの移動などである。加えて，QAにおける機能テストに必要なPS5本体側の操作なども，リプレイエージェントで行っているとのこと。
 |
模倣エージェントに人間のゲームプレイを学習させる模倣学習とは，手本となる行動データから，その行動パターンを再現するモデルを作成する機械学習の一種。具体的な模倣エージェントの作成手順は，事前にゲームを手動で複数回プレイし，そのデータを用いて模倣学習を行い，その手動プレイの操作内容を再現できるモデルを構築する。
 |
この模倣エージェントのモデルは，入力としてゲームの画面情報のみを必要とする。ゲームの画面情報を入力すると，次のフレームにおけるコントローラの状態を出力する設定となっており，毎秒10フレームで動作させることによってリアルタイムに操作を決定できるという。この模倣エージェントが対象とするのは，リプレイエージェントが適用できないシーンすべて，つまりわずかでもランダムな要素があるシーン全般となる。
 |
今回の「ASTRO's PLAYROOM」の事例では，模倣エージェント用にステージ別のモデルを用意したとのこと。その理由は，1つのモデルが担当するシーンを少なくするほど，モデルそれぞれの性能が安定するからだ。
 |
また，2つのエージェントを切り替えるタイミングを判定する機能として，「シーン認識」も用意した。この機能は，画面情報からゲームが特定のシーンに到達したことを判定するもので，大きく2つの技術を用いている。その1つが「テンプレートマッチング」で，あらかじめ準備したテンプレート画像と同じオブジェクトがゲームの画面内に存在しているかを判定する。
例えば，クエスト攻略時に出てくるアイコンやポップアップなどを認識する場合に利用しているそうだ。
 |
もう1つが「特徴点マッチング」で，あらかじめ準備したターゲット画像と，ゲーム画面の類似度を常にチェックしているという。類似度が閾値を超えると，ゲームがターゲット画像と同じシーンに到達したと判定してエージェントを切り替えるとのこと。
 |
また特徴点マッチングをシーン認識に活用する上では，「見た目のブレに対するロバスト性」が重要になることにも言及された。例えば，同じエリアに到達したとしても，カメラの向きが異なることによって，画面の見え方が変わってしまうことは珍しくない。同様に，ゲーム内の時刻によってライティングが変わってしまうこともある。そういった見た目の変化に対して，QAチームでは機械学習ベースの画像マッチング手法である「LoFTR」を活用したことも明かされた。
 |
 |
ゲームプレイ自動化の手順
ゲームプレイの自動化にあたっては，まず，ゲームプレイを含む自動化したいテストの内容を決定する必要がある。そして，そのテストの内容をエージェントの単位に分割する。
次にゲームを実際に手動プレイして，リプレイエージェントの場合は1回，模倣エージェントの場合は10回以上のプレイデータを取得する。ここで模倣エージェントの場合は，取得したデータを用いて模倣学習を行う。
 |
模倣学習が完了したら，2つのエージェントを実際に動かして，自動プレイできるかどうかの確認を行う。自動プレイが失敗した場合には，データの取得フェーズに戻り，データ取得→模倣学習→動作確認→……というフローを自動プレイが成功するまで繰り返すこととなる。
自動プレイに成功したら，Jenkinsなどの定期実行パイプラインを使ってプロセスを整える。これがゲームプレイ自動化の一連の流れである。
 |
 |
 |
QAチームでは，この自動プレイシステムを用いて，ゲームプレイを含む機能テストを実際に自動化して定期実行しているとのこと。その結果，システム上のバグを3件自動検出しており，それらのバグが混入した直後の機能テストで検出できたことも判明しているという。なおバグの検出数が少ないのは，今のところ機能テストの自動化が限定的な範囲でのトライアルという位置付けだからであるそうだ。
 |
 |
模倣エージェントの技術的説明
模倣エージェントの技術的説明では，まず模倣学習のアルゴリズムが紹介された。今回の取り組みでは，先に記した「どんなタイトルに対しても適用できる汎用性」に加え，エンジニアのスキルがなくとも模倣エージェントを作成できる「誰でも使える簡易性」を目指したという。
 |
それら2つの目標を踏まえて，QAチームではアルゴリズムとして「Behaviour Cloning」を採用したとのこと。このアルゴリズムは模倣学習の中ではもっともシンプルなもので，モデルの入力と出力を結びつける教師あり学習だ。今回のケースでは，入力をゲーム画面，出力をコントローラ操作として学習を進めていくこととなる。具体的な模倣エージェントの作成の流れは，上記のとおり事前に手動プレイでゲーム画面とコントローラの情報をデータとして記録し，そのプレイデータをモデルに学習させるというものである。
 |
モデルの構造は極めてシンプルになっており，入力された1枚のみの画像を画像特徴量抽出層とコントローラ状態出力層（全結合層）に通して，最終的にコントローラの状態を出力する。また，操作および記録の頻度を毎秒10フレームにしているのは，学習を簡単にするためとの説明もなされた。
 |
コントローラのアナログスティックの出力は，アナログ値ではなく上下左右斜めとニュートラルを合わせた全9クラスとして扱っている。これは学習の容易さを踏まえた結果だという。
また，モデルの出力に関しては，コントローラの各ボタンとスティックの状態を出力させるため，それぞれに最終層が分岐したようなネットワークを使用。最終層となる全結合層では，ボタンであればオン / オフそれぞれの誘導，スティックであれば各方向の誘導を出力している。これには，データセットに合わせて余分な操作のネットワークを作らないことにより，不要な学習の発生を防ぎ，モデルの性能を向上させる意味があるとのことだ。
 |
 |
画像特徴量抽出層には，事前学習済みのEfficientNetのエンコーダを利用。模倣学習時には，そのEfficientNetのエンコーダにはさらなる学習をさせず，全結合層にのみ学習させたという。これは，少ないゲーム画面でエンコーダに学習させるより，大量の実写画像で事前学習されたEfficientNetのエンコーダを使うことによって，モデルの性能が上がることがさまざまな事例で確認されているからとのことだ。加えて，全結合層のみの学習はネットワークが小さくなるため，学習にかかる時間が短いこともメリットとして示された。
 |
入力を画像1枚にしているのは，入力を増やすとモデルの性能が落ちるという，これまでの実験結果がベースになっていることも明かされた。この傾向は「ASTRO's PLAYROOM」に限らず，ほかのゲームのタスクにも見られるそうだ。
 |
今回の取り組みで，直面した課題にどう対応したかについても紹介された。例えば，「ランダム地点に落ちている，進行に必須なアイテムを拾うためにボタンを押す」といったような操作はゲームにおいて珍しくない。しかしそういった，出現数は少ないもののクリア率に大きく影響する操作は，深層学習において学習がなかなか進まず，期待どおりにボタンを押すモデルを作成するのは非常に困難だという。
 |
そこで今回の取り組みでは，学習がモデルに与える影響度を調整する「Class Balance」を用い，出現割合が少ない操作であるほど重みを付けて，その学習がより強くモデルに反映されるようにしたそうだ。
 |
 |
そのほか模倣学習の弱点として，操作に失敗して手本となるデータから乖離してしまうと復帰が困難になることも挙げられた。これに関しては，未知の状態から手本のある状態まで復帰する追加データを学習させることで解決したとのこと。
 |
 |
 |
セッションの最後には，今回紹介された自動プレイシステムの検証を通じて，今後のQAテストの品質向上が見込めることが確認できたとの見解が示された。
 |
鄭重声明：本文の著作権は原作者に帰属します。記事の転載は情報の伝達のみを目的としており、投資の助言を構成するものではありません。もし侵害行為があれば、すぐにご連絡ください。修正または削除いたします。ありがとうございます。
