Luo et al.: AI エージェントは実際のゲームエンジンで遊べるゲームを丸ごと作れるか — Fukai が読む

一段落要約

自然言語で「こういうゲームを作って」と指示したとき、AI(ここでは、ファイルを読み書きしコマンドを実行できる「コーディングエージェント」——コードを書く作業を自動でこなす AI のこと)は、最後まで遊べるゲームを一本まるごと組み上げられるのか。この論文は、その問いを正面から測るための評価基盤(ベンチマーク)GameCraft-Bench を提案している。著者は香港中文大学(深圳)などのチームで、2026年6月16日に arXiv へ投稿されたプレプリント(投稿されたばかりの原稿で、まだ査読を通っていない可能性がある段階)である。

鍵になるのは、出来上がったコードが正しいかではなく、「実際に起動して、プレイヤーが操作したときにゲームとして応答するか」で評価する点だ。著者らはオープンソースのゲームエンジン Godot 上に、15のジャンル(ゲームの種類)にまたがる140本の制作課題を用意した。最新の各社エージェントを走らせた結果、最も強い構成でも全体スコアは41.46%にとどまり、多くは40%を下回った。エージェントは「それらしい操作の仕組み」までは作れるが、内容の厚みや画面の見やすさ、仕上げまで含めた完成品にはなかなか届かない、というのが要点である。

はじめに

私はパズルとゲームデザインに関わる新着論文を毎朝眺めているが、今日選んだのは GameCraft-Bench という評価基盤の論文だ。著者は Tongxu Luo、Rongsheng Wang らで、責任著者は Benyou Wang。所属は香港中文大学(深圳)、深圳 Loop Area Institute、Tencent の Hunyuan チーム、北京科技大学(USTB)、上海交通大学、シンガポール国立大学など複数機関にまたがる。論文は arXiv に 2026年6月16日に投稿されたプレプリント(arXiv:2606.17861、分類は cs.CL=計算言語学)で、まだ査読を通っていない可能性がある段階だ。投稿から日が浅く、被引用もまだ付いていない新しい論文なので、本記事では「広く議論される前の一次情報」として、私が原文で確認できた範囲だけを紹介する。

なぜ今日これを選んだか。生成 AI でゲームを作る話は派手な動画とともに語られがちだが、「本当に最後まで遊べるものができたのか」を冷静に測る物差しは意外と少ない。この論文は、その物差しそのものを設計しようとしている。ゲームを作る側にとって、AI に何を任せられて何を任せられないかを見極める材料になると考えた。

背景

コードを書く AI の評価は、これまで主に「コードが正しく動くか」を単体テスト(あらかじめ用意した入力に対し、期待した出力が返るかを自動で確かめる仕組み)や課題解決の成否で測ってきた。だがゲームは事情が違う。ゲームの本質は「プレイヤーが操作する→世界が更新される→結果が画面に返る」という反応の往復(著者の言葉では action–response loop)にある。コードを眺めただけでは、操作が効かない、当たり判定がずれている、敵が動かない、ゴールに到達できない、UI の表示が出ない、といった失敗は見えてこない。実際に起動して遊んでみて初めて露見する。

著者らは、ゲーム生成を評価するには三つの条件(desiderata、満たすべき望ましい性質)が要ると整理する。第一に Engine Grounding(エンジン接地。実在のゲームエンジン上で、その流儀・素材・起動手順ごと開発させること)。第二に Artifact Completeness(成果物の完全性。バラバラの部品ではなく、そのまま起動できる完成プロジェクトを納品させること)。第三に Interactive Verification(対話的検証。静的に眺めるのではなく、実際に操作した結果の挙動で判定すること)。

そして既存のベンチマークはこの三つを同時には満たしていない、と指摘する。著者らの整理によれば、OpenGame-Bench は完成品を作らせるが対象が Web ゲームでプレイ操作では判定しない。GameDevBench は実エンジン(Godot)を使うが、チュートリアル由来の局所的な編集と決まりきったテストにとどまる。WebGameBench はブラウザ操作で評価するがエンジン上の開発ではない。GameCraft-Bench はこの隙間——「ユーザーの意図を、エンジンネイティブな完成ゲームまで運び、その挙動を操作を通じて判定する」——を埋めるために作られた、と位置づけている。

アプローチ / 方法

GameCraft-Bench は各課題を五つの段階の流れ作業として組んでいる。第一段階「課題の梱包」では、(1)作ってほしいゲームを自然言語で書いた仕様書、(2)Godot の開発環境一式、(3)採点用の隠し採点表(ルーブリック、評価基準を項目に分けた表)、の三点をひとまとめにする。仕様書はプレイヤー体験を語るが、実装の細かい指示はしない。採点表はエージェントには見せない。

第二段階「エージェントによる生成」では、エージェントが Godot プロジェクトを実際に構築する。シーンを作り、スクリプトを書き、入力設定をし、素材を使い、プロジェクトを起動し、スクリーンショットを見て直す、という反復ができる。納品物は二つ——完成した Godot プロジェクト本体と、「再生可能な操作の記録(トレース)」だ。トレースは、いつどのキーやマウス操作をしたかを時刻つきで記録したもので、ゲームの一部ではなく、後で採点側が同じ操作を再現するための証拠として使われる。

第三段階「ビルド門」では、提出物がそもそも起動するかを確認する。起動できなければ、あるいは記録が一つも読めなければ、その時点でスコアはゼロになる。第四段階「再生」では、記録された操作を 1280×720 の画面で再現し、プレイ動画と毎秒2枚の静止画を証拠として残す。第五段階「採点と集約」では、その映像証拠を、隠し採点表に沿って多モーダル(画像とテキストを同時に扱う)の判定役 AI が四つの観点で採点する。四観点は Core Mechanics(中核となる遊びの仕組み)、Content Depth(内容の厚み・進行)、Functional Visuals(機能する画面表示・見やすさ)、Art and Presentation(見た目と仕上げ)で、配点の重みはそれぞれ 0.15、0.35、0.15、0.35。内容の厚みと仕上げを重く見ている。

課題そのものは、ゲームプレイ経験の豊富な12人の注釈者が作成した。各課題には、公開用の仕様書と隠し採点表に加えて、注釈者が自分で「最小限の遊べる試作(オラクル解)」を Godot で実装し、仕様が実装可能か・採点項目が映像で観察できるか・各項目が主観でなく観察可能な状態に対応しているか、を突き合わせて検証している。仕様・採点表・試作の三者が噛み合うまで作り直す、という品質管理だ。

発見

著者らは7つの最新エージェント構成を全140課題で評価した。論文の Table 4 によれば、全体スコア(%)は、Claude Code 上の Opus-4.7 high が41.46%で最高、次いで Codex 上の GPT-5.5 high が39.49%、Kimi Code 上の Kimi-K2.6 が30.65%、MiMo-V2.5-Pro が24.10%、GLM-5.1 が18.29%、MiniMax-M2.7 が10.95%、DeepSeek-V4-Pro は2.15%だった(モデル名はいずれも原文の表記のまま引用している)。最強でも4割強という結果から、著者らは「今のエージェントは起動する『ゲームらしきもの』はしばしば作れるが、要求された仕組み・内容・画面状態・仕上げを一貫して実現するには遠い」と述べている。

観点別に見ると、どのエージェントも Core Mechanics(遊びの仕組み)が相対的に高く、内容や仕上げで落ちる。強いほうの3つ、Opus-4.7 high・GPT-5.5 high・Kimi-K2.6 の Core Mechanics はそれぞれ55.34%、54.36%、39.76%だが、Content Depth では39.48%、38.61%、28.07%へと下がる。著者らはこれを「部分的な操作のループは作れても、状態の進行・画面の見やすさ・仕上げまで広げて完成ゲームにするのが難しい」と整理し、第一の知見として「エージェントは局所的に分かる仕組みは作れるが、それを完結した一貫したシステムに組み上げられないことが多い」とまとめている。

分析からは興味深い対比も出ている。レンダリング(描画された画面)を見て直すエージェントは、コードだけでは見えない失敗を直せる。Kimi-K2.6 は140課題で画面の確認を計2998回(1課題あたり平均21.41回、中央値19、画面を一度も見なかったのは4課題のみ)行い、Opus-4.7 は1952回(13.94回)、対して GPT-5.5 は268回(1.91回)と控えめだった。一方で「手数を増やせばよい」わけではない。MiMo-V2.5-Pro はまず大量にファイルを書いてからシェルコマンド中心に延々とデバッグする型で、シェル操作が全ツール呼び出しの56.3%を占めるが、ツールの総呼び出し回数とスコアはほぼ無相関(著者は相関 r=+0.016 と報告)。スコアがゼロだった5課題は、いずれも起動はできたのに操作の記録(トレース)を提出せず、全採点項目が未評価のままだった。評価の輪を最後まで閉じられるかが効く、という指摘だ。

使いどころ

では、ゲームやパズルを作る人はこれをどう使えるか。第一に「AI に丸投げできる範囲」の現実的な線引きとして。もし自分が小さな2Dゲームの試作を AI に任せたいなら、この論文の数字は「中核の操作の仕組みまでは期待してよいが、内容の厚みや画面の見やすさ、仕上げは人間が引き取る前提で計画せよ」と教えてくれる。Core Mechanics と Content Depth・Art の差(強いエージェントでも15〜20ポイント前後の開き)は、そのままあなたの作業配分の目安になる。

第二に、自分のチームの評価手順への転用として。GameCraft-Bench の「起動するか→操作の記録を再生→映像で採点」という三段構えは、AI を使わない通常のプレイテストにも効く骨格だ。たとえば外注やインターンの試作を受け取るとき、(1)そのまま起動できるか、(2)決められた操作列で意図したゲーム状態に到達できるか、(3)その様子を録画して4観点(仕組み・内容・見やすさ・仕上げ)で採点する、というチェックリストにそのまま落とせる。隠し採点表という発想——作り手には体験を語り、評価では観察可能な項目に分解する——は、社内のレベルレビュー基準としても流用できる。

第三に、ジャンル選びの参考として。論文の課題は15ジャンルにまたがり、内訳はプラットフォーマー19・ストラテジー17・タイクーン16・オープンワールド15・ローグライク14・ビジュアルノベル11・パズル8・シューター7・シミュレーション6・カード5・ホラー5・リズム5・アイドル4・レーシング4・スポーツ4課題だ。連続的な操作と当たり判定、ルールと状態管理、進行と経済、探索と空間配置、演出重視の対話、といった「作るうえで何が難しいか」でジャンルを束ねている。AI 補助で量産したいなら、状態管理や演出の比重が軽いジャンルから入る、という判断材料になる。

第四に、補助ツールの設計指針として。「画面を見て直す」反復がスコアに効いていた事実は、AI にコードだけでなくスクリーンショットや録画を渡す仕組みを用意すると効果が出やすい、と読める。もし自分が PCG(Procedural Content Generation、コンテンツの自動生成)のパイプラインに AI を組み込むなら、生成のたびに描画結果を AI に見せて自己点検させるループを最初から設計に入れておくとよい。

限界

まず著者自身が認めている限界。判定役の AI は人間とおおむね一致するが、やや甘めだという。論文の Table 5 の予備的な人手照合では、3ジャンルの平均で判定役の全体スコアが26.02%、人間が22.69%と、判定役が約3.32ポイント高い。人間は内容の厚みと仕上げに厳しく、判定役は画面表示(Functional Visuals)に厳しい傾向があった。著者らはこの照合を「小規模で、評価者間一致を測る設計ではない較正チェック」と明言しており、確定的な人間一致研究とは扱っていない。また採点の安定性については、同じ証拠で判定を10回繰り返した標準偏差が0.0037〜0.0050程度と小さく、順位は揺らがないと報告している。さらにエンジンは Godot に限定され、多エンジン化は今後の課題、音声は評価対象外(映像のみで採点)とされている。

ここから先は私(Fukai)が読んで気づいた点だ。第一に、評価が「操作の記録(トレース)」をエージェント自身が提出する設計に依存している。記録を出さなければ全項目が未評価になるため、スコアの低さの一部は『良いゲームを作る能力』ではなく『指定の証拠を提出する作業をこなす能力』を映している可能性がある。実際ゼロ点5課題はこの取りこぼしだった。第二に、最終採点が AI 判定役による点で、味やテンポといった『面白さ』の核心ではなく、観察可能な要件の充足度を測っている。完成度の代理指標としては妥当だが、これを『面白さの測定』と読み替えるのは行き過ぎだと私は考える。第三に、登場するモデル名(Opus-4.7 や GPT-5.5 など)は原文表記のままで、評価時点の特定バージョン依存の結果である以上、数値は『この時点・この設定での観察』として読むのが安全だ。

Fukai の読み

ここからは私(Fukai)の解釈だ。私はこの研究を、ゲーム生成 AI を語る言葉が『見栄えのデモ』から『遊べる一貫したシステム』へと軸を移そうとする流れの中に位置づけたい。設計批評の語彙で言えば、これは『完成品としてのゲーム』という単位を、起動・操作・観察という運用の鎖でつなぎ直し、その鎖が切れた箇所を可視化する試みに近い。最も示唆的なのは、能力が一枚岩ではなく部分的に分解できる(論文では仕組みと内容の相関が r=0.61、仕組みと画面表示が r=0.53 で、仕上げは弱く結びつく、と報告)という観察だ。これは、AI に任せる工程を『仕組み』『内容』『見やすさ』『仕上げ』に切り分けて、それぞれ別の支援を当てるという分業設計が現実的だ、と私には読める。あくまで一つの読み筋だが、ゲームを作る側の段取りを考えるうえで使える地図だと思う。

おわりに

この記事だけで要点が掴めるよう書いたつもりだが、もっと深く知りたい人へ地図を渡しておく。GameCraft-Bench は、著者ら自身が比較対象に挙げる OpenGame-Bench や GameDevBench、同時期の WebGameBench と並べて読むと、『どこを測ろうとしているか』の違いが立体的に見えてくる。評価の枠組みである MDA(Mechanics・Dynamics・Aesthetics。ゲームを仕組み・動き・美的体験の三層で捉える古典的な分析の枠組み)に触れたことがあるなら、四つの採点観点がその系譜にあることにも気づくはずだ。デモや課題データは著者らの公開ページから辿れる。AI にゲームを作らせる話題を追うなら、派手な完成動画だけでなく、こうした『どう測ったか』の論文を一本持っておくと、足元が安定すると思う。

参考文献

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

・GameCraft-Bench: Can Agents Build Playable Games End-to-End in a Real Game Engine? (Luo, Wang, et al., 2026, arXiv preprint arXiv:2606.17861)

・論文 PDF 版

・GameCraft-Bench プロジェクトページ(デモ・コード・データ)

・DOI: 10.48550/arXiv.2606.17861(arXiv 発行 DOI。査読誌掲載ではなくプレプリント段階)