OpenGame解説｜汎用LLM直書き・OSS・Rosebud AIの3軸比較、Build Health 72.4でDX担当が選ぶゲーム生成基盤

この記事の要点

OpenGameは2026年4月21日に香港中文大学MMLabが公開したOSS。「汎用LLMにプロンプトで頼む」方式ではなくゲーム特化LLM（GameCoder-27B）＋エージェント構成でWebゲームを丸ごと生成する
論文Table 1では、OpenGame+Claude Sonnet 4.6がBuild Health 72.4を記録。Cursor(66.8)・Claude単体(58.5)・GPT-5.1単体(57.4)を上回る
非エンジニア事業者の選択肢は「ChatGPT/Claude直書き」「OpenGame（OSS）」「Rosebud等のSaaS」の3択。用途・予算・商用利用条件で分岐する

「ChatGPTにSnakeゲーム作ってと頼んだら、
動くけど当たり判定がガタガタだった」。
こういう経験、
教材担当や社内DX担当の間で積み重なっていると思います。
その構造的な原因と、
代替手段が4月21日に中国・香港の研究室から出ました。

OpenGameは汎用LLMにプロンプトを渡す方式ではなく、
ゲーム開発に特化して訓練されたLLMとエージェントの連携でWebゲームを丸ごと生成するOSSです。
私は注目してます。
論文ベンチマークでCursorすら上回る数字が出ている点、
そしてApache-2.0で商用利用可な点が効くからです。

この記事では、
汎用LLM直書き・OpenGame・Rosebud等のSaaSを並べて、
非エンジニアの実務応用層がどこで何を選ぶべきかを整理します。

OpenGameとは何なのか（公式情報の要点）

OpenGameは香港中文大学のMultimedia Laboratory（MMLab）が開発したOSSで、
2026年4月21日にGitHubとarXivで公開されました。
CUHK MMLabは過去にMMDetection、
MMPose等を公開している研究機関です。
突然現れた個人プロジェクトではありません。

論文冒頭にこう書かれています。

Game development sits at the intersection of creative design and intricate software engineering, demanding the joint orchestration of game engines, real-time loops, and tightly coupled state across many files. While Large Language Models (LLMs) and code agents now solve isolated programming tasks with ease, they consistently stumble when asked to produce a fully playable game from a high-level design, collapsing under cross-file inconsistencies, broken scene wiring, and logical incoherence.

（出典: arXiv 2604.18394）

要するに、
汎用LLMはコードの1ファイル単位は解けるのに、
ゲームという「複数ファイルが整合を保って動き続ける」対象ではガタつく、
という問題提起です。
ここに共感がある方、
多いはず。
OpenGameはそこに真正面からぶつかりに来た最初のオープンソース・エージェンティックフレームワークだと論文は主張しています。
私はこの問題提起の仕方に説得力を感じました。

公式スペック要点

GitHub: leigest519/OpenGame（2026年4月23日時点でスター336、フォーク28）
プロジェクトページ: opengame-project-page.com
ライセンス: Apache-2.0（商用利用可・改変可）
提供形態: npm経由のCLIツール
Node.js 20以上必須（Windows/Mac/Linux対応）
Primary LLM: OpenAI互換API（OPENAI_API_KEY、OPENAI_BASE_URL、OPENAI_MODEL環境変数で設定）
素材生成用API: DashScope、Doubao、fal.ai、OpenRouter等を別途設定
生成コマンド: opengame -p "ゲーム説明" --yolo

対応ジャンルは公式READMEによればプラットフォーマー、
サイドスクロール、
ターン制カードバトル、
タワーディフェンス、
トップダウンアクションRPG、
ツインスティックシューター、
クイズ、
サバイバル反射系まで。
デモではMarvel Avengers風、
Squid Game風、
Star Wars風などが置かれています。

汎用LLM直書き vs OpenGame vs SaaS（比較マトリクス）

非エンジニアがWebゲームを業務に組み込む場合、
現時点で現実的な選択肢は3系統です。
最初に数字で並べます。

ベンチマーク比較（論文Table 1）

OpenGame-Benchは150種のゲームプロンプトをヘッドレスブラウザで実行し、
VLMが判定する評価系です。
評価軸は3つ。
Build Health（ビルド正常性）、
Visual Usability（視覚的使いやすさ）、
Intent Alignment（意図整合性）。

モデル/ツール	Build Health	Visual Usability	Intent Alignment
OpenGame + Claude Sonnet 4.6	72.4	67.2	65.1
Cursor + Claude Sonnet 4.6	66.8	61.4	58.9
OpenGame + GameCoder-27B（自前モデル）	63.9	57.0	54.1
Claude Sonnet 4.6 直書き	58.5	50.8	50.3
GPT-5.1 直書き	57.4	52.9	49.4
Gemini 3.1 Pro 直書き	53.6	60.2	42.1

出典: arXiv 2604.18394 Table 1。

個人的にはここで目が止まりました。
汎用LLMのままClaude Sonnet 4.6に頼むと58.5。
同じClaude Sonnet 4.6をOpenGameのエージェントに載せ替えると72.4。
差は+13.9ポイント。
Cursorと比較しても+5.6ポイント上。
モデルが同じでも、
エージェント側の設計でここまで動く。
数字の重さが別物です。

実務3択マトリクス

観点	汎用LLM直書き (ChatGPT/Claude)	OpenGame (OSS)	Rosebud AI (SaaS)
セットアップ	ブラウザだけでOK	Node.js 20＋git clone＋API鍵	ブラウザ＋アカウント登録
技術スキル要件	プロンプトが書ければ可	CLI操作と環境変数設定が必要	プロンプトが書ければ可
月額	LLM料金のみ（ChatGPT Plus $20等）	ツール無料＋API従量課金	無料〜$50/月
商用利用	API規約に依存	Apache-2.0で可（著作権表示必要）	Indieプラン（$10〜13/月）から可
ゲームの完成度	Build Health 53〜59（ガタつく）	Build Health 63〜72（SOTA）	公式ベンチスコア非公開
生成後のコード改変	自由（手元にコードが来る）	自由（手元にコードが来る）	プラットフォーム内で編集
サポート体制	なし（自己解決）	GitHub Issuesのみ	公式サポートあり

Rosebud AIの料金は無料プランが週20プロンプト・商用不可、
Indieプランが$10〜13/月で300プロンプト・商用権利付き、
Proプランが$20〜50/月で無制限プロンプト（出典: flickonclick.com Rosebud AIレビュー）。
Rosebudは収益分配ゼロ（Stripe手数料のみ）を謳っていて、
ここは個人的に評価高い。

Makko AIも競合として存在し、
$20/月の有料プラン、
ベータ7ヶ月で4,500人超・4万件超のアセット生成という数字をローンチ記事で公開しています。

なぜ汎用LLM直書きはゲームでガタつくのか

ここは日本語の先行レビューが答えを出してくれている部分。
ai-torai.comが「ChatGPTにスイカゲーム風の宝石パズルを依頼した」事例でこう記録しています。

何度コードを生成し直してもバグやエラーが消えず、
特にオブジェクト同士の当たり判定のズレや表示崩れが発生しやすかった

（出典: AIチャレンジ日記）

AI Watch（インプレス）のゲーム実装記事ではこう書かれています。

初期のプロンプトでは、
勝敗を間違えたり、
終了条件を間違えてラウンドを継続したりするケースがあった

（出典: AI Watch）

同記事では「生成AIによるプロンプト生成→プレイ→バグ発見→生成AIによる修正という作業を数回繰り返す必要があった」と続きます。
これが汎用LLM直書きの実態。
何往復もする。

Qiitaの開発レポートでは、
クリア不能な木の位置が生成されないようにと明示指示しないとゲームバランスが壊れる、
と記録されています（Qiita記事）。
ゲームデザインの暗黙知を毎回プロンプトで注入する必要があるということです。
ここが個人的に一番しんどいと思う。

OpenGameの論文はこの問題の正体を「cross-file inconsistencies, broken scene wiring, and logical incoherence」（ファイル間の不整合、
シーン接続の破綻、
論理の非一貫性）と整理しています。
対処として導入されたのが次の3つ。

GameCoder-27B: Qwen-3.5-27Bベースのゲーム特化LLM。継続事前学習→SFT→実行ベース強化学習の3段階パイプラインで訓練
Template Skill: 経験から成長するプロジェクトスケルトンライブラリ（安定したアーキテクチャのスキャフォールド）
Debug Skill: 検証済みフィックスのリビングプロトコル（孤立した構文バグのパッチではなく統合エラーの体系的修復）

論文Table 3によれば、
hook-drivenな実装を外すだけでBuild Healthが最大10.1ポイント、
Intent Alignmentが11.6ポイント落ちる、
とのこと。
要するに「LLMを賢くする」だけでは届かない部分を、
エージェント側のアーキテクチャで埋めている。
これが面白いところ。

OpenGameは誰に向いていて、誰には向かないか

向いている層

私が各ソースを突き合わせた範囲で整理すると、次の層に刺さります。

教材制作・社内研修で「ブラウザだけで動く短いゲーム」を量産したい教材担当
Apache-2.0で商用利用可能な状態を確保した上で、自社プロダクト（LPのミニゲーム、展示会のインタラクティブ体験等）に組み込みたい事業者
生成物のソースコードを手元に置き、改変とホスティングを自社管理したい社内DX担当
すでにOpenAI互換APIの請求アカウント（OpenRouter、fal.ai、Doubao等）を持っていて、従量課金をコントロールできるチーム

向かない層

Node.jsもCLIも触れないタイプの担当者単独（誰か1人はターミナルを触れる前提が必要）
サポート窓口がないと不安な大規模導入（現状はGitHub Issuesのみ、4/21〜22にnightly buildが3件連続失敗している状況）
AAA級のカスタムレンダリングや複雑なマルチプレイヤーネットワーキングを要求する本格商用ゲーム（Makko AI公式も「Not suited for engine-level customization or large-scale production.」と、このレンジのAI生成ゲーム全般について明言している）
プロンプト画面1枚で完結させたい非エンジニア1人チーム（この層はRosebudやMakkoの方が実務導線が短い）

この切り分け、重要だと思う。「AIでゲーム作れる」の粒度がバラバラすぎるから。

商用利用まわりの注意点（Apache-2.0）

OpenGame本体はApache-2.0ライセンスです。
商用利用は可能で、
義務は2つ。

バイナリ配布時も含め、著作権表示とライセンス文書を同梱すること
コードを変更した場合は変更した旨を通知すること

コピーレフトではないので、
自社の改変コードをオープンソースにする義務はありません（出典: FOSSA Apache License 2.0 解説、
Apache License 2.0 原文）。

ただし注意点が1つ。
Apache-2.0は「ツール本体」のライセンスです。
「生成された出力ゲームコード」の著作権帰属は、
ユーザーが投げたプロンプトと、
裏で使ったAPIプロバイダ（OpenAI、
Anthropic、
Doubao等）の利用規約にも依存します。
ここはグレーゾーンとして、
商用配布前に法務確認を挟んだ方が安全だと私は見ています。

セキュリティと運用面の現実

中国発のOSSという点、
事業導入側は気にする方もいるはず。
GitHubのIssues欄を見ると、
2026年4月21〜22日にかけてnightly releaseが3件連続失敗（#2、
#4、
#6）しており、
エラー詳細は"N/A"のみ（OpenGame Issues）。
リリース直後の初期不安定期に入っています。
Issue #5ではGameCoder-27BとOpenGame-BenchのHuggingFace公開を求めるリクエストが出ていて、
4月23日時点でモデル本体はまだ未公開です。

運用観点としては次の3点を押さえておくのが無難。

社内導入前にClaude Code等でコードの静的スキャンを通す（npm依存ツリー含む）
APIキーは最初は検証用サブアカウントで切る（素材生成4プロバイダ分のキーが必要なため、権限の最小化を徹底）
本番機能組み込みは数バージョン様子を見る（4月末〜5月の安定化を待ってから）

ここを踏んだ上で試す分には、
Apache-2.0＋OSS＋論文ベンチSOTAという組み合わせは、
2026年前半のAIゲーム生成領域でかなり強いカードに見えます。
私は夏までにいくつか日本語デモが出てくると見ています。

FAQ

Q. OpenGameを使うのに必要な費用は月いくらですか

A. OpenGameツール本体は無料（OSS）です。
実費はバックエンドで使うOpenAI互換APIの従量課金のみ。
1ゲーム生成あたりの概算は公式から明示されていません。
Claude Sonnet 4.6を使えばベンチ数値（72.4）に届きますが、
その分APIコストは高め。
予算優先ならGameCoder-27B（BH 63.9）で運用する選択肢もあります（ただし4月23日時点でモデル本体はHuggingFace未公開）。

Q. Rosebud AIやMakko AIと比べてOpenGameの強みは何ですか

A. 生成されたゲームのソースコードを手元のファイルシステムに落とせる点、
Apache-2.0で改変・再配布が可能な点、
そして論文ベンチでCursorを上回るスコアを出している点。
SaaS系はプラットフォーム上で完結する代わりに、
コードのポータビリティやカスタマイズ深度で制約が出ます。
逆にブラウザだけで完結させたいならRosebudやMakkoの方が導線が短いです。

Q. 生成されたゲームを自社サイトに組み込んで商用配布できますか

A. OpenGame本体はApache-2.0なのでツール自体の商用利用は可能です。
ただし「生成されたゲームコード」の著作権帰属は、
裏で使ったAPIプロバイダの利用規約に依存する部分があります（OpenAI、
Anthropic、
Doubao等それぞれ規定が異なる）。
商用配布前にAPIプロバイダの利用規約を確認し、
法務レビューを挟むことを推奨します。

Q. プログラミング未経験でも使えますか

A. 正直、
単独では厳しい。
Node.js 20以上の環境構築、
gitコマンド、
環境変数の設定、
npm link等のCLI操作が前提です。
社内に1人ターミナルを触れる人がいれば成立します。
完全にブラウザ完結でやりたいならRosebud AI（無料プランで週20プロンプト）かMakko AIから試す方が現実的。

Q. ChatGPTやClaudeに直接お願いするのとどう違うんですか

A. 論文Table 1ではClaude Sonnet 4.6を同じ素材として使っても、
直書きではBuild Health 58.5、
OpenGameのエージェント経由では72.4と14ポイント近い差が出ています。
原因はファイル間整合性・シーン接続・論理一貫性を管理するエージェント側の設計（Template Skill / Debug Skill / hook-driven実装）。
同じLLMでも「周辺アーキテクチャの有無」でここまで変わる、
というのが論文の主張です。