AIでWebゲームを全自動生成する「OpenGame」とは

ここ最近、CursorなどのAIコーディングツールを使っていて、ある種の「もどかしさ」を感じることはないだろうか。単一の関数やアルゴリズム、独立したコンポーネントを書かせるなら、彼らはすでに人間と同等かそれ以上のスピードを誇る。しかし、「この要件でアプリケーションを一つ丸ごと作って」と投げた途端、状況は一変する。無数のファイル群が生成されるものの、モジュール間の依存関係は矛盾だらけで、データの受け渡しは破綻し、結果的に人間が手作業で辻褄を合わせる羽目になる。これが現在のLLMが抱える「アーキテクチャレベルの壁」だ。

とりわけ、その壁が最も高くそびえ立っている領域が「ゲーム開発」である。ゲームは、リアルタイムのメインループ、複雑に絡み合うステート管理、複数ファイルにまたがるアセットのロードとシーンの遷移など、ソフトウェアエンジニアリングにおける「密結合」の極みとも言える。単発のタスク解決に特化した現在のコードエージェントが、ゲームを作ろうとして見事に崩壊するのは、ある意味で当然の帰結だった。

「遊べるゲーム」を破綻させずに組み上げる技術

香港中文大学（CUHK）のMMLabから発表された「OpenGame」は、まさにこの壁を真正面から突破しようとする野心的なフレームワークだ。彼らが目指したのは、プロンプトひとつでエンドツーエンドのWebゲームを全自動生成すること。単なるスネークゲームやテトリスのクローンではなく、アクションゲームのような複雑なインタラクションを持つゲームの構築である。

このリポジトリの最大の発明は、LLMのプロンプトエンジニアリングを洗練させたことではなく、エージェントに「アーキテクトとしての経験」と「統合デバッガーとしての視点」を持たせた点にある。OpenGameのコアとなるGame Skillは、2つの能力で構成されている。

ひとつは、過去の生成経験からプロジェクトの骨組みをライブラリ化し、成長させていく「Template Skill」。ゼロから闇雲にコードを吐き出すのではなく、安定したプロジェクト構造のテンプレートを足場として使う。もうひとつは、構文エラーのような単純なバグではなく、システム全体の結合エラーを体系的に修復する「Debug Skill」だ。ファイル間の整合性が取れていない箇所を見つけ出し、検証済みの修正プロトコルに従ってロジックを修復していく。これにより、「ファイル単体では動くが、繋げると落ちる」というLLM特有のトラップを回避している。

静的コード解析から「プレイアビリティ」の評価へ

さらに興味深いのは、彼らが自前で鍛え上げたゲームエンジン特化のコードLLM「GameCoder-27B」の存在と、その評価パラダイムである。

通常のソフトウェアなら、テストコードを回してカバレッジや静的解析を見れば、ある程度の正当性は担保できる。しかし、ゲームにおける正解は「エラーが出ないこと」ではなく「遊べること」だ。キャラクターが壁をすり抜けないか、攻撃の当たり判定は正しいか、UIは意図した通りに描画されているか。これらはソースコードの文字列を眺めているだけでは絶対にわからない。

そこで彼らは、「OpenGame-Bench」という独自の評価パイプラインを構築した。生成されたゲームをヘッドレスブラウザ上で実際に走らせ、その描画結果や挙動をVLM（視覚言語モデル）にジャッジさせるのだ。「ビルドの健全性」「視覚的な使いやすさ」「意図との一致」という3つの軸で、AIが作ったゲームをAIがプレイして採点する。この実行ベースの強化学習ループ（Execution-grounded RL）を取り入れたことで、OpenGameは既存のコード生成モデルとは一線を画す「動的ソフトウェアの構築能力」を手に入れた。

ソフトウェアエンジニアリングの次の主戦場

OpenGameの登場は、「ゲーム開発を自動化するツールが出た」という局所的なニュースに留まらない。これは、AIエージェントが「関数」という点から「システム」という面へ、そして「インタラクティブなプロダクト」という立体へと、その介入領域を押し広げたマイルストーンだ。

リアルタイム性が求められ、状態管理が複雑極まりないゲームという領域でエージェントが実用レベルに達するのであれば、一般的な業務アプリケーションのエンドツーエンド生成が当たり前になる未来は、私たちが想像しているよりもずっと早く訪れるだろう。

参考リポジトリ: leigest519/OpenGame

Photo by Nubelson Fernandes on Unsplash