日本の横浜で最近開催された CEDEC イベントでの講演の中で、ソニー社内の開発責任者は、QA プロセスの効率と精度を向上させるために AI および機械学習モデルを実装する最近の取り組みについて説明しました。
講演は、同社のゲームサービス研究開発部門の機械学習研究者、矢部宏之氏と宮野田内祐太郎氏、およびソフトウェアQAエンジニアリングを専門とするソフトウェアエンジニアの中原裕樹氏が主導した。これは、同社が実際の PS5 ハードウェアを使用して AI を QA プロセスに統合し、人間による Q&A と同様の画面上の情報と音声情報のみを収集しながら、タイトルをより定期的に、より効果的にテストできるようにした方法について、仲間のクリエイターに理解してもらうことを目的としていました。効率。
この方法で定期的にテストを自律的に実行することで、チームはより定期的なテストのおかげで、より多くのバグを早期に排除することができました。これは、そうでなければ手動テストは開発サイクルごとに数回しか実施できず、開発が遅すぎるとバグが発見されるとリリースに影響を与える可能性があるためです。
この講演では、チームは PlayStation 5 のローンチ タイトルである Astro's Playroom で QA 業務を自動化するソフトウェアを使用した調査結果を共有しました。これは、広範な QA テストを必要とする重要な機能の 1 つが、プレイヤーがレベルを通過するにつれて特定の目標の進行状況を追跡できる PS5 のアクティビティ カードなどのハードウェア機能とゲームの進行状況を統合することであったため、注目に値しました。
リプレイエージェントとイミテーションエージェント
このテクノロジーをテスト プロセスに統合する方法を研究する際、チームには満たす必要のある条件がいくつかありました。どのテスト システムも、ゲーム固有のツールに依存してはなりません。その場合、他のゲームで使用するためにツールを作り直す必要があります。つまり、シューティング ゲームの AI テストは、プラットフォーマーや他のシューティング ゲームに適用できない照準支援に依存してはなりません。
また、そのような自動化を価値あるものにする現実的なコストで実現可能である必要があり、技術的な経験のない人でも模倣エージェントを作成してテスト シミュレーションを実行できるほど単純である必要もあります。
その結果、Astro's Playroom では、リプレイ エージェントとイミテーション エージェントという 2 つの別個の自動プレイ システムを使用して QA を自動化することになりました。前者のシステムは、一貫性を確保するために正確なボタンの組み合わせを複製することで機能し、ゲーム内 UI や PS5 ハードウェア メニューをナビゲートする場合や、スポーン ポイントから変数のないレベル移行時などの特定の状況で使用されていました。動きに影響を与える可能性があります。
一方、模倣エージェントは人間の遊びを変化させて再現します。どちらのシステムも PS5 を PC に接続することで実現され、コントローラーの入力がハードウェアに送り返される前に、画面上の情報が学習モジュールに送信されます。
これらのツールは順番に使用することもできます。ビデオの例では、模倣エージェントがレベルの再生を引き継ぐ前に、リプレイ エージェントを使用して Astro のプレイルームの UI をナビゲートしたり、ハブ ワールドからレベルに移動したりすることができます。通常、レベルに入るときにアクティビティ カード メニューを開き、2 つのシステム間の遷移を再現可能な方法で示すなど、この変更を示すためにシーン遷移が使用されます。
矢部氏の説明によると、「模倣エージェントのために、人間のゲームプレイを再現できる機械学習モデルを作成し、それを使用して正確に再現できないプレイのセクションをテストしました。そのためには、人間のテスターに多数のセクションをプレイしてもらいますAstro のプレイルームの場合、代表的なサンプルを取得するために、テスターに各セクションをおよそ 10 ～ 20 回プレイしてもらい、そこから機械学習システムにデータを入力しました。それを複製するためのものです人間のゲームプレイはさらなるテストのために。」
「私たちは人間のゲームプレイを再現できる機械学習モデルを作成し、それを使用して正確に再現できないプレイのセクションをテストしました。」矢部浩之
これにより、チームはこれらのセクションを繰り返しテストして、バグが見落とされていないことを確認できるようになります。この種の機械学習は、プレイヤーがカメラや視点を自由に操作できるエリアや、敵の AI がプレイヤーのアクションに反応してプレイヤーを攻撃するシーンなど、入力を正確に再現することが不可能なエリアをテストするために必要でした。 -セットパターン。このようなシナリオでは、これらの要素はセッションを繰り返すと安定しないため、入力を正確に再現しても有益な結果が得られず、マシンがレベルを完了することもできません。
機械学習モデルを支援するために、LoFTR (検出器不要の局所特徴マッチング) などの他の AI システムが使用され、カメラの角度やプレイヤーの位置などが異なる場合でも、システムがシーンをモデル内のシーンと同一であると認識できるようになります。システムに提供された入力と異なっていました。自動テスト モデルがリプレイ エージェントとイミテーション エージェントの間で戻るテストでは、このような知識は、有用なエージェントを切り替える移行シーンに到達したときのゲームを理解する上で非常に重要です。
矢部氏が指摘したように、「模倣エージェントのモデルは、入力としてゲーム画面情報のみを必要とします。ゲーム画面情報が入力されると、次のフレームでコントローラーの状態を出力するように設定されており、[記録モデル] を実行することで、 ] 1 秒あたり 10 フレームで、イミテーション エージェントはリプレイ エージェントが適用できないすべてのシーンを対象に操作を決定できます。
そうは言っても、提供されたプレイ データを使用してゲームが環境を実際に学習できるようにするには、ある程度の簡素化とガイダンスが必要でした。たとえば、生のアナログ入力を処理するのではなく、これを 9 つの動きの象限に単純化し、システムによってより効果的に管理できるようになります。人間の遊びを再現する場合、モデルは確率を使用して、提供されたデータから特定の瞬間にボタンが押されたかどうかを判断します。
人間の遊びを反映する
もう 1 つの注意点は、特にそのような場合に予想される小規模な学習サンプルを扱う場合、成功の可能性を高めるためにクラス バランスをトレーニング データに統合する必要があるということでした。一般的なデータセットに基づいて無差別にトレーニングされたモデルは、クリア成功につながる結果に偏る可能性がありますが、人間のプレイは反映されていません。一方で、敵を倒した際にランダムで落ちてくる進行に必須のアイテムを拾うなど、頻度が少なく影響力の大きいタスクは機械学習が導入しにくい。このようなタスクに優先順位を付けて、たとえ実行可能としても利用できるようにするためにBalanceが導入された。そのような状況では。
宮内祐太郎氏の説明によると、「ゲームでは、ランダムな場所に落ちているアイテムを拾うためにボタンを押す必要があるが、進行には不可欠である瞬間があることは珍しくありません。しかし、そのようなアクションは頻繁には現れませんが、レベルをクリアする能力に大きな影響を与えるものは機械学習にとって困難であり、これに対応するモデルを作成するのは困難です。クラス バランスを使用して、モデル内で学習が及ぼす影響の程度を調整することで、重要な要素をより重視しました。操作の出現頻度が低いため反映されるモデルではより強力になります。」
モデルはまた、人間の遊びをよりよく反映し、不自然な遊び方をしないようにするために、失敗した状態（壁にぶつかるなど）から抜け出して標準的な遊びに戻る方法を学習するのに役立つデータに基づいて訓練します。効果的なテストには役立たない。
講演中に示された一例では、ボタンの押下とアナログ動作の確率が、学習成果のバランスの有無にかかわらず示され、結果には明らかな違いが示されました。バランスの取れたモデルでは、レベル内での Astro Bot の動きは人間が世界を移動する方法を反映しており、ジャンプや段差を効果的に乗り越えることができますが、アンバランスなシステムでは常に壁にぶつかったり、途中で障害物にぶつかったりします。たとえそれが最終的には目標を達成するかもしれないとしても（あるいは、多くの場合、達成できなかったとしても）。
データにバランスを入力することで、より少ないデータセットを使用してモデルを効果的にトレーニングできるだけでなく、選択したジャンルのベースモデルを作成することで、1 つのゲームの世界によりよく適応し、同じジャンルの新しいゲームにも迅速に適応できるようになりました。それはタイトル全体に適用できるかもしれません。
システムは改良され続けていますが、研究者らは、このタイトルや他のタイトルの開発プロセス全体で自動 QA をテストした経験の中で、このモデルの多くの利点と欠点に気づきました。例として、ゲーム A とゲーム B の 2 つのゲームを使用して、ゲーム A では、ゲームの特定領域における人間のプレイに関する広範な訓練済みデータがあっても、提供されたデータを使用してエージェントがゲームをクリアできるとは限らないことを指摘しました。 。その場合、新しいデータまたは追加のデータを取得する必要があり、手動による人間によるテストで達成できる時間を超えてテストに必要な時間を延長する可能性があります。
ただし、ゲーム B の場合、自動化システムの人的データ収集には、50 時間に相当する人的テストを行うのに 1 時間かかる可能性があり、QA が大幅に高速化され、自動化を促進するために必要な工数が全体的に削減されます。人間によるテストで同じ結果を達成するために必要な数値よりも低い。
さらに、システムは現時点では完全に自立しておらず、QA において完全な自律性を持って動作できないため、効果的な結果を得るには依然としてある程度人間の入力が必要です。講演後の聴衆の質問に答えた際、矢部氏は、敵やプラットフォームの配置などのレベル内でパラメータが変更されると、以前の機械学習データは効果がなくなることを認めました。この時点で、新しい機械学習モデルを作成するか、その領域を手動でテストして、モデルをゲームプレイのより機能が充実したセクションに限定する必要があります。
システムは完全に自己完結的ではなく、QA において完全な自律性を持って動作できないため、効果的な結果を得るには依然としてある程度人間の入力が必要です。
ただし、全体としては、自動テストを使用することで、完全に人間主導のアプローチと比較して、チームは QA プロセスの効率を向上させることができました。この機械学習モデルは人間のテスターの必要性を完全に排除したわけではありませんが、代わりに開発全体を通じてより頻繁にテストを行うことができるようになり、バグを早期に検出できるようになりました。さらに、より多くのタイトルでのさらなるテストにより、モデルが時間の経過とともに改善され続けることが期待されるため、システムが改良され続けていることがわかりました。
大規模な言語モデルや生成 AI での機械学習の使用は軽蔑され、開発サークルの内外からの反発に直面していますが、他のシナリオで使用されるこれらのモデルは、ゲーム作成者に目に見えるメリットをもたらします。これらの AI モデルの使用は、QA スペシャリストの必要性に取って代わられたわけではありません。すべてのテストが人間主導の QA よりも機械を使用した方が速いわけではありませんが、代わりに QA のプロセスが開発プロセスにさらに統合されました。
このようなバグ修正と QA を開発の終了まで放置するのではなく、その時点で、早期発見の欠如により一部の複雑な問題がゲーム プログラミングの構造により深く統合される可能性があるため、新しい問題が発生するたびに開発プロセス全体で QA を繰り返すことができます。機能とレベルが完成しました。
QA プロセスにおける機械学習システムの開発により、他の開発者が求めるツールを使用しながら、このような早期発見とバグ修正がより合理化され、開発者が実行できる効果的なものとなり、品質が向上し、一般に出荷されるタイトルのバグの数が減少します。独自の機械学習モジュールを開発して実行することでエミュレートします。
