9月1日開催の「CEDEC2017」にて、ディライトワークスの瀧下祥氏（技術部、プログラマ）によるセッション「Fate/Grand Orderにおける自動リプレイを用いたQA改善への挑戦」が行われた。そのセッションの模様をお届けする。
▲瀧下祥氏。
▲本発表についての補足。
まず、自動リプレイを導入することになった背景について、「クエストやサーヴァント、スキル、演出、特別処理等、各要素の追加により、増大し続けるQA工数。そのQA工数を削減したい」という思いがあったと瀧下氏は明かす。
QA工数の一例を挙げつつ、作業を繰り返し行ったり、バグの再現を繰り返し試みることでかかる時間のロスをなくすため、繰り返しを自動化するためのリプレイ機能を検討したそうだ。
そして導入を検討した自動リプレイだが、その概要は何らかの方法でゲームをプレイして内容を記録し、記録したプレイを再現する機能。ゲーム中の“ある瞬間の再現”を重視するため、再現性の低いバグの発見に有効だという。
▲ユーザーの操作など必要な入力情報を記録して同じ状況を再現したり、乱数シードを記録して同じ値を使うことで毎回同じ結果にするなど、自動リプレイ実現方法の一例を紹介。
▲自動プレイの導入も検討したそうだが、再現性や既存コードによるゲーム部分への影響と既に運用しているタイトルでの実装リスクの高さから、自動リプレイを選んだという。
続いて、自動リプレイの導入で目指したことについて瀧下氏は、「“発生頻度の低いバグの再現性向上”と“QA工程の効率化（工数削減）”、“バトル再現手順の簡略化・半自動化”」とした。発生頻度の低いバグの再現性向上については、「端末での操作を自動記録して後から確認（再生）を可能にして、記録したものとは異なる端末でも再生可能、常に同じ状況でテストできるようにした」（瀧下氏） そしてQA工程の効率化によってQA時の再現性確認の手戻りを改善。
また、バトル再現手順の簡略化・半自動化では、発生した不具合の再現性を高め、再現コストの低減に繋げた。
そして自動リプレイを導入してみた結果については、「再生機能を使うことで検証に必要な工数を省けるので非常に楽」、「PC（Unity Editor）と実機で互換性があるので調査が容易に行える」といった実際に利用している人の感想を紹介。
瀧下氏は「非常に評判が良い」とした。
■リプレイ機能の実装方針
次に、リプレイ機能の実装方針について紹介した瀧下氏。実装方針は「入力記録方式と関数記録方式の2案を検討した」（瀧下氏）そうだ。
結果から言うと、採用されたのは関数記録方式だった。瀧下氏は、「ユーザーの入力の位置や時間を毎回記録し、再現する入力記録方式は、別途乱数シードなどを再現したり、端末の解像度や処理性能によって再現性が損なわれないよう注意が必要だった」とし、さらに
「ボタン位置のインターフェースの変更などの対応にも注意が必要となり、メンテナンスコストがかかってしまう」と、入力記録方式が採用に至らなかった理由を説明した。
逆に関数記録方式は、コールスタック上の主要な関数を実行フレーム単位で記録し、再現。乱数シードなどの再現も容易で、ボタン位置にかかわらず押下イベント（関数）を実行できる。また、実行端末の解像度や処理性能の差異を吸収できそう、などの要素が採用の決め手になったようだ。
▲リプレイ機能実装方針の関係図。
実装詳説では、既に運用しているタイトルに適用するということで、ゲーム部分に影響を与えず、ソースコードの埋め込みを最小限にするため、Unityのコンパイル時にソースコードを自動で置き換えた。そして、Unityビルド時にソースコードを自動置換。主要となる関数をWhitelistに記録して置換する関数を指定し、インスタンスの紐付けはヒエラルキーから推測（推測出来ない場合はコード上でUnique Keyを割り当て）したという。
また、通信面では、クライアント（ライブラリ）とサーバー間の通信はWebSocketを使用し、ログの送受信や再生命令送信をリアルタイムで行い、ゲーム用のHTTPリクエストとは別に、専用通信を非同期処理で実施。乱数で不定となるデータは全てサーバーへ記録しているとのことだ。
▲リプレイ記録時の処理フロー。
瀧下氏は、最後にリプレイ機能の実装について、良かった点と苦労した点を改めて紹介。また、画面キャプチャ保存機能の改善、自動リプレイを複数端末で同時再生、そして自動プレイへの要望が多いことから技術検証を進めていく、という今後の展望を語った。
▲自動プレイについては、自動リプレイとの併用でデバックの効率化向上を狙うようだ。
