Huang et al.: 生成したゲームを AI に「遊ばせて」直させる — Fukai が読む

一段落要約

「ゲームを生成できること」と「遊べるゲームを作れること」は別だ、という一行からこの論文は始まる。プロンプトを渡して HTML のゲームを一発で書かせると、コードは動く。しかしボタンを押しても何も反応しない、敵が動かない、勝利条件がいつまでも発火しない——こうした失敗はコードを読んでも、コンパイルが通るかを確かめても見えない。遊んでみて初めて見える。著者らはそこに、画面の見た目を頼りにクリックとキー入力で操作する GUI エージェント(Graphical User Interface Agent。人間と同じ画面と同じ入力手段でソフトを操作する自動エージェント)を「テストプレイヤー」として据えた。

成果物は二つある。一つは PlaytestArena。8ジャンル 200 本のゲーム生成課題に、それぞれ「正しく実装できていれば遊んだときにこう見えるはず」という判定基準を付けた評価環境で、基準の総数は 1,548 個。もう一つは Play2Code。コードを書くエージェントと遊ぶエージェントを、共有メモリを挟んで何ラウンドも往復させる仕組みだ。3つのモデルの平均で、一回書き切りが 29.7%、コードを見て直す既存の自動化(OpenGame)が 52.2% の基準通過率に対し、Play2Code は 66.8% に達した(論文第5節および Table 3)。

はじめに

取り上げるのは Yixu Huang、Bo Li、Na Li ら11名による「GUI Agents for Continual Game Generation」。所属は復旦大学、小紅書(Xiaohongshu)、同済大学、カリフォルニア大学サンタバーバラ校、JD.COM にまたがる。arXiv:2605.28258v1、cs.SE(ソフトウェア工学)への投稿で、日付は 2026年5月27日。**現時点では arXiv preprint であり、査読を通ったという表示はない**。プロジェクトサイトも公開されている。被引用はまだほとんど積まれていない段階なので、広く議論を経た結論ではない、という前提で読んでほしい。

私がこの論文を今日選んだ理由は単純だ。ここに書かれている問題が、ブラウザで動く小さなパズルを作っている人間の日常そのものだからである。生成 AI にゲームを一本書かせると、たいてい「動くけれど遊べない」ものが出てくる。どこが遊べないのかを言葉にするのが難しく、結局自分で開いて触ることになる。その「自分で開いて触る」工程を機械に渡せるか、という問いに正面から取り組んだ論文は、少なくとも私が読んだ範囲では多くない。

もう一つ、評価の設計そのものが面白い。この論文は「良いゲームとは何か」を定義しようとはしていない。代わりに「このプロンプトから作ったのなら、遊んだときにこの挙動が観察できるはずだ」という観察可能な項目の集合に問題を落としている。この割り切りが、あとで述べる限界と表裏一体になっている。

背景

言語モデルによるコード生成の評価は、長らく「機能的正しさ」で測られてきた。関数を書かせてテストを通すか、仕様どおりの出力を返すか。この枠組みは、正解が事前に書ける課題ではよく働く。ところがゲームでは、正解を事前にテストの形で書き下すのが難しい。著者らの言い方を借りれば、ゲームの品質はコードではなく「遊び」の側に宿っている。楽譜が正確に書かれていても、演奏を聴くまで良い曲かどうかは分からない、という比喩が導入で使われている。

だからゲーム業界は昔から人間のテストプレイヤーに頼ってきた。ビルドを開いて何時間も遊び、静的な検査では見えないもの——押しても反応しないボタン、描画されないスプライト、発火しない勝利条件——を報告する。ところが生成側の速度が上がった結果、人間が遊べる量を超える候補が出てくるようになった。ここに需給のずれがある。

評価環境の側にも穴があった。AI が生成したゲームを測るベンチマークは少なく、著者らが挙げる先行例(OpenGame-Bench、WebGameBench)はいずれも公開されておらず、比較の共通基盤が存在しなかった。PlaytestArena はまずこの穴を埋めるものとして位置づけられている。ゲームは自己完結した HTML/CSS/JS の束として実装され、現代の GUI エージェントが既に相手にしている Web の土俵にそのまま乗る。

アプローチ

手順は三段になっている。第一段は「GUI エージェントはそもそも遊べるのか」の確認だ。ブラウザで動くゲーム20本(生成物と実在の Web ゲームの混成、パズル・戦略・カード・プラットフォーマー・経営を含む)を、それぞれ複数のレベルに分解して合計約120レベルの試験台を作る。そこへ3つのモデル(GPT-5.4、Claude Sonnet 4.6、Kimi K2.5)を接続し、同じ条件で人間3人にも遊ばせて基準線を取る。エージェントが一定回数の試行内にクリア条件を満たせばそのレベルは通過とみなす。

第二段が PlaytestArena。ジャンルを Wikipedia の分類と itch.io・Poki のような Web ゲーム配信サイトから集め、200 のお題に対して人間の専門家が生成プロンプトを書く。プロンプトの長さは平均131トークン、中央値119トークンで、状態を持つゲームプレイ、勝敗条件、入力、フィードバック挙動を明記する短文だ。次に同じ専門家が、それぞれのプロンプトに対して「観察可能で検証できる」項目に落とした判定基準を書く。例に挙がっているのは「出現した敵はプレイヤーの位置に向かって移動する」といった粒度である。総計 1,548 項目、1本あたり平均 7.7 項目。採点は GUI エージェントがブラウザでビルドを読み込み、実際に遊び、各項目に合否を付けて、通過率をそのゲームの点数とする。

第三段が Play2Code。ゲームエージェント(コードを書き、デバッグし、パッチを当てる)と GUI エージェント(ビルドを遊ぶ)を、共有ランタイムと共有メモリを挟んでラウンド制で回す。重要なのは、GUI エージェント側はコードにも判定基準にもアクセスできないことだ。渡されるのはメモリとゲームのガイドだけ。エージェントは遊び終えると二つの成果物を書き出す:何が起きたかの要約と、観察された失敗を具体的なコード変更に対応づけた修正リスト(例:「敵が巡回すべき場面で静止している → 巡回の発火条件を確認せよ」)。ゲームエージェントはそれを命令ではなく助言として扱い、どれを採るかを自分で決める。

もう一つの仕掛けが三層のメモリだ。エピソードメモリはタスク内で、ラウンドをまたいで要約・修正・試行を積む。スキルメモリはタスクをまたぐが各エージェント固有で、ゲームエージェントは繰り返し使えるコードのパターン、GUI エージェントは操作の作戦を溜める。ワールドメモリはタスクもエージェントもまたぐ共有層で、一般的なゲームのルール、よくある型、設計上の原則を記録する。プラットフォーマーのジャンプ弧の誤りのような失敗を毎回ゼロから再発見しないための構造である。付録のアブレーション(設計のどの部分が効いているかを、要素を一つずつ外して確かめる実験)では、GUI エージェントとこのメモリ層のどちらも欠かせないと報告されている。

発見

まず「遊べるのか」。pass@k(k 回試行して一度でもクリアできた割合)で、GPT-5.4 が 0.67 / 0.75 / 0.82(k=5/10/20)、Sonnet 4.6 が 0.63 / 0.76 / 0.79、Kimi K2.5 が 0.52 / 0.68 / 0.72。人間の基準線は 0.83 / 0.92 / 0.92(論文 Table 1)。人間には及ばないが3つとも過半のレベルを通し、GPT-5.4 は人間に近づいている。著者らはあわせて、観察・推論・行動の三つが揃っていることを実際のセッション記録で示している。

次に「その採点は信用できるのか」。GUI エージェントが審判なので、審判の偏りをそのままベンチマークが引き継ぐ。著者らは8ジャンルにまたがる32本の層化抽出サンプルで、盲検の人間注釈者から項目ごとの判定を集めた。項目レベルの一致率は 84.2%(Cohen の κ = 0.64)。人間同士の一致率が 90.7%(κ = 0.66)なので、κ の値でみれば人間同士の帯の中に収まっている。ゲーム単位の点数では順位がほぼ一致した(Spearman の ρ = 0.87、Pearson の r = 0.88。人間同士はいずれも 0.91)。ここでの κ は、偶然の一致を差し引いたうえでどれくらい判定が揃っているかを表す指標だと理解しておけばよい。

本題の生成性能。基準通過率の平均は、一回書き切りの Direct LLM が GPT-5.4 で 31.6%、Sonnet 4.6 で 29.7%、Kimi K2.5 で 27.8%。ビルドして走らせてコードを検査する既存の自動化 OpenGame がそれぞれ 55.7% / 55.3% / 45.5%。Play2Code は 72.3% / 71.1% / 56.9%(論文 Table 3)。3モデル平均でみると 29.7% → 52.2% → 66.8% で、Play2Code は一回書き切りに対して 37.1 ポイント、OpenGame に対して 14.6 ポイントの上積みになる。比較の意味がはっきりしているのは後者だ。OpenGame も反復はしているが「遊ばない」。差の 14.6 ポイントが、遊ぶことでしか出てこない信号の大きさに対応する。パズルジャンルだけを見ると、GPT-5.4 で 35.2% → 60.5% → 77.8% と、全体平均より伸びが大きい。

ラウンドごとの推移では、点数がラウンド1から3へ単調に上がった(Figure 6a)。序盤のラウンドは入力に反応しないといった基礎的な失敗を、後半のラウンドは視覚効果のような細かい問題を拾う。ただし伸び方はゲームの複雑さで大きく違う。低複雑度では最初の数ラウンドでほぼ全ての欠陥が出てラウンド3〜5で収束、中複雑度が5ラウンドを通じて最も大きく伸び、高複雑度は早々に頭打ちで低い水準に留まった。著者らはこれを「精緻な機構は GUI エージェントが確実に発火させられないため、修正の材料が出てこない」と読み、ボトルネックは往復ループではなく GUI エージェントの能力側にあると述べている。

最後に、人間との差。著者らは GUI エージェントの報告のほうが追跡可能だと指摘する。人間の報告は本質的に要約で、印象に残った場面と後から再構成した因果だけが残り、実際のキー入力は開発者に届く前に失われる。エージェントは全行動と全観察が記録されるので、報告が復元可能なフレーム列に紐づく。そして興味深いのは、モデルによって気にすることが違う点だ。GPT-5.4 は機能のバグと操作の反応性に報告が集中し、Sonnet 4.6 はテンポ・手触り・難易度調整といった体験面にも同程度を割き、Kimi K2.5 は報告のおよそ半分が視覚と美的な側面に向いた(Figure 7)。著者らはこれを一貫性の欠如とは読まず、趣味に近い何かが実行の機械性とは別の層にあると書いている。

使いどころ

一つ目。ブラウザで動く小さなパズルを作っているなら、一番すぐ真似できるのは Play2Code の全体ではなく「判定基準を先に書く」部分だ。仕様書ではなく、遊んだときに観察できる文の集合として書く。「盤面のセルをクリックすると色が反転する」「同じ形を3つ揃えると消える」「詰み状態になったら再挑戦の案内が出る」。1本あたり7〜8項目という粒度が論文の実績値なので、目安に使える。人間のテスト用チェックリストとしても、生成 AI に直させる指示としても、そのまま働く。

二つ目。デイリーパズルのように毎日盤面を生成する仕組みがあるなら、生成した盤面を実際に「遊ばせて」ふるいにかける工程を挟める。ソルバーで解の存在を確かめるのとは別の層で、画面越しに操作させると、盤面としては解けるのに UI から入力が通らない、クリア演出が出ないといった実装側の欠陥が出る。高複雑度ゲームの結果からすると複雑な機構の発火はまだ苦手なので、単純なルールの日替わり盤ほど相性が良いはずだ。

三つ目。回帰テストに使える。論文でエージェントが検出しているのは、押しても反応しないボタン、状態遷移の欠落、発火しない勝利条件——ちょうど、リファクタリングのあとに静かに壊れるやつだ。コードのユニットテストでは掴めず、人間が毎回全部触るのは続かない。ここに自動プレイヤーを一台常駐させる、という発想は現実的に見える。

四つ目、そして個人的に一番面白いと思った使い方。モデルごとに報告の偏りが違うという Figure 7 の観察を、そのまま人員配置として使える。機能の壊れを拾いたいラウンドと、テンポや手触りの違和感を拾いたいラウンドで、別のモデルを当てる。人間のテストチームで「バグを見つけるのが得意な人」と「気持ち悪さに気づく人」を分けるのと同じ運用を、モデルの選択で作れる。ただしこれは論文が推奨している運用ではなく、観察から私が引き出した使い方であることを断っておく。

五つ目。振り分けの基準にも使える。低複雑度なら3〜5ラウンドで収束し、高複雑度は早々に頭打ちになる、という結果は、「どこまで機械に任せ、どこから人間のテストプレイに回すか」の線引きに直接効く。自動ループを回して点数が2ラウンド続けて動かなくなったら人間に渡す、というような運用ルールが引ける。

限界

著者自身が三点認めている。第一に、実装は HTML ベースのゲームに限られており、ネイティブエンジンや3Dのタイトルへの拡張は今後の課題とされている。第二に、ベンチマークは品質管理のために選別された集合で、現実のゲームの多様性を汲み尽くしてはいない。第三に、メモリの設計は全ゲームで共通のスキーマを使っており、ゲーム固有あるいはジャンルを意識した構造にすればさらに伸びる余地がある、と書いている。

Fukai がここで指摘するのは、まず評価と改善に同じ種類の審判が立っていることだ。PlaytestArena の採点者も Play2Code のループの中で助言を出す側も GUI エージェントであり、同じ系統のモデルが使われている。人間注釈との一致は 32 本のサンプルで確かめられているが、「その審判が好む形の失敗ばかりを直したから点が上がった」という筋を完全に排除するのは、この設計では難しい。著者らも審判の残余ノイズには言及しているので、隠しているわけではない。ただ、14.6 ポイントという差の読み方には、この構造を頭に置いておきたい。

もう一点。この論文が測っているのは「指定どおりに実装されているか」であって「面白いか」ではない。判定基準は観察可能な挙動に落とすことで測定可能になっているが、その代償として、難易度が適切か、退屈でないか、驚きがあるか、といった軸は基準の外にこぼれる。著者らはこの点をむしろ正直に書いていて、人間のテストプレイヤーが与える「難しさ・苛立ち・退屈・驚きの felt sense(実感)」と暗黙の美的判断は、現在のエージェントが近似できていないと明言している。数字が 66.8% まで上がっても、それは「壊れていない度」の指標であって、遊んで面白い度の指標ではない。

細かい点を二つ。3モデル平均の 66.8% は Kimi K2.5 の 56.9% を含んでいるので、モデルを選べる状況の実力としては GPT-5.4 の 72.3% を見るほうが実態に近い。また、ラウンドごとの単調増加は Figure 6a で示されているが、複雑度の三層分けは「点数の推移をもとに」定義されたと書かれており、分類と結果が完全に独立とは言いにくい構造になっている。

Fukai の読み

ここだけは私の解釈である。私はこの論文を、生成 AI の評価が「出力を検査する」から「出力を使ってみる」へ移る流れの中に位置づけたい。テストの通過で測れるものは、仕様が先に書ける対象に限られる。ゲームはその外側にあり、だから著者らは判定を「遊んだときに観察できる文」に翻訳した。設計批評の語彙で言えば、これはテストプレイという工程の自動化ではなく、テストプレイの報告書式の標準化に近い。追跡可能な行動ログと修正リストという二枚組みの型が、人間の報告よりも機械に食わせやすい形になっている——つまりこの論文の中心にある発明は、エージェントそのものよりも、あの報告書の形式ではないか、と私は読んでいる。そしてモデルごとに「気にすること」が違うという最後の観察は、その報告書式の上でこそ見えてきたものだ。

おわりに

この論文の比較対象として名前が挙がる OpenGame は、コードを繰り返し検査するが遊ばないという位置にあり、両者を並べて読むと「遊ぶ」という一手の値段が見える。また、言語モデルにゲームを実際に遊ばせて能力を測る系統としては GVGAI-LLM が近い場所にいる。生成物の評価環境という観点では、PCG Benchmark(手続き的コンテンツ生成の評価用テストベッド)を合わせて眺めると、この分野で「何を測ることになっているか」の地図が引けるはずだ。

私自身の関心は、判定基準を書く工程のほうに残っている。1本あたり7.7項目という数字は、専門家が観察可能性を担保しながら絞り込んだ結果である。この「観察可能な文に落とす」作業は、自動化される前に、まず自分の手で一度やってみる価値があると思う。ホットの濃いコーヒーを淹れて、自分が作っているパズルについて、遊べば必ず確認できる文を8つ書き出してみる。私は昨夜それをやって、3つ目で詰まった。

参考文献

本記事で参照した論文と関連資料:

・GUI Agents for Continual Game Generation (Yixu Huang, Bo Li, Na Li, Zhe Wang, Kaijie Chen, Haonan Ge, Qingyi Si, Yuanzhe Shen, Ruihan Yang, Guangjing Wang, Hongcheng Guo, 2026, arXiv:2605.28258v1 [cs.SE], arXiv preprint)

・同論文の HTML 版(本記事の引用はこちらを参照した)

・プロジェクトサイト(論文中に記載)

・関連研究: GVGAI-LLM: Evaluating Large Language Model Agents with Infinite Games (2025)

・関連研究: The Procedural Content Generation Benchmark (2025)