A2Z GameSpec-Bench、コーディングエージェントのゲーム設計忠実度を検証

導入

コーディングエージェントにゲームを生成させる場合、起動できる成果物を得ることと、ゲームデザインを忠実に実装することは同じではない。長文のGame Design Document（GDD）には、ゲームルール、状態、見た目、プレイヤー操作が相互に結び付いて記述される。個別の機能が動いていても、別の状態や操作と組み合わせたときに設計上の関係が崩れる可能性がある。A2Z GameSpec-Benchは、この差を測るための評価基盤である。

主な仕組み

• 100件の長文GDD：短いプロンプトで単一機能を作らせるのではなく、実際の開発に近い複数要件を含む長文仕様を対象にする。
• 依存関係対応コントラクト：各GDDを、実装すべきルール、制約、前提条件の関係を含む固定的な契約へ整理する。これにより、ある動作が成立するために何が必要かを明示できる。
• コードとプレイの両面を検証：ソースコードの確認だけでなく、エージェントが作成したテスト方針を使い、シナリオ再生と適応的プレイテストを行う。実装、実行時の表示や挙動、プレイヤーの操作を同じ要件に結び付けて評価する。
• 比較可能な評価軸：エージェントや修正ラウンドが変わってもコントラクトは固定される。要件ごとに判断と証拠を記録するため、どの設計違反が繰り返されるかを追跡しやすい。

分かったこと

評価結果では、現在のコーディングエージェントが、コード実装と実際のプレイの双方で相互依存する要件を満たすことに苦戦している。コンパイルや起動に成功しても、特定の状態遷移や操作手順で初めて現れる不整合が残る場合がある。したがって、ソースコードだけを調べる方法では、設計への忠実度を十分に判断できない。

修正方法の比較も示唆的だ。2回の修正後、具体的な要件に結び付いたフィードバックを与えた場合、エージェントに自己修正だけをさせるよりGDD Fidelityが10.9%向上した。改善すべき箇所を要件単位の証拠として示すことが、一般的な再確認の指示より有効だったと解釈できる。

意義と影響

このベンチマークは、評価の焦点を「実行可能なコードを書けるか」から「複雑な仕様を実装後の体験まで維持できるか」へ移す。ゲームは、ロジック、表示、状態、操作が密接に関係するため、仕様追従能力を検証する厳しいテストケースになる。同じ考え方は、エージェントが生成する他の複雑なアプリケーションにも適用できる。

開発者にとっては、依存関係対応コントラクトが設計違反と原因を結び付ける手掛かりになる。研究者にとっては、固定された契約と要件単位の証拠が、エージェントや修正戦略を比較するための一貫した基盤を提供する。プロジェクトのコードとデータセットは公開されており、仕様に忠実なエンドツーエンド生成の研究を後押しする。

出典：Hugging Face Daily Papers