DeepSeek V4：低コストでAIゲーム生成を最適化する

手頃なモデルで、実際に遊びたくなるブラウザーゲームを作れるでしょうか。ここ1週間、OpenGame Studioでこの問いをテストしてきました。最新の試みは、DeepSeek-V4.1-Flash-1017です。DeepSeek V4ファミリーから10月17日にリリースされました。

また、Grok 4.6、Xiaomi MiMo V2.6 Flash、MiMo V2.6 Pro、GLM 5.3 Flash、Claude Haiku 5.5もテストしました。生成コスト、待ち時間、遊べる挙動、見た目の品質のバランスを改善することが目的でした。ゲームが正常に開いても、左を押すと右に動いたり、接触前にコインが加算されたり、一時停止中も落下し続けたりする場合があります。

最新のDeepSeekランナーは、実施したゲームプレイの基本チェックに合格しました。アートは控えめでした。これまでの実験では、私たち自身の配信検証の不具合を含め、異なる問題が明らかになりました。説明のないモデルランキングより、こうした詳細のほうが制作者に役立ちます。

DeepSeek-V4.1-Flash-1017で最初に生成したランナー。キャラクター、レーン、コインは見分けられますが、環境は基本的な試作のままです。

手頃なゲーム生成を最適化する

小規模にゲームを作る場合、何度も試すことが大切です。初版ではカメラ、操作、衝突ルール、アートの方向性を再検討する必要があるかもしれません。実用上の問いは、その過程からどれほど役に立つ、テスト可能なゲームを得られるかです。

Claude Opus 5.5のような高性能なフラッグシップモデルは、難しいコーディング作業で有力な選択肢です。公式説明ではサブエージェントとの作業についても紹介されています。より大規模なワークフローを選ぶ前に、比較的手頃な候補を試したいと考えました。モデル名だけで良いゲームが保証されるわけではなく、複数エージェントを使うかどうかは作業量や利用量を増やし得るワークフロー上の選択です。

候補モデルにはそれぞれ異なる役割がありました。

• Grok 4.6は汎用モデルの比較基準として使いました。私たちにとっては予算重視の選択肢ではありませんでしたが、サブスクリプションで利用できることが魅力の一つでした。公式リリースページでは、Grok Buildなどのツールを通じたコーディング利用が説明されています。
• Xiaomi MiMo V2.6 FlashとProでは、同じファミリーの2つの選択肢を比べられます。XiaomiはFlashを効率的で頻繁な利用向け、Proをより高度な推論やプロジェクト作業向けに位置付けています。Proは同ファミリーのフラッグシップですが、私たちの予算を考慮した検討候補の一つでした。
• GLM 5.3 Flashは、効率を重視した別の選択肢でした。公式紹介でその位置付けが説明されています。ゲーム依頼全体をどう処理するか確認したいと考えました。
• Claude Haiku 5.5は、海外モデルのコスト重視の選択肢として加えました。AnthropicはHaikuを、高速かつ大量の処理向けと説明しています。後述の限定的な確認を行い、ゲームビルダーとしてテストしました。
• DeepSeek-V4.1-Flash-1017は最新の実験です。リリース告知にはプロジェクトのデモが含まれています。OpenGame Studioでどこまで活用できるか、独自のランナー依頼で試しました。

候補に中国発のモデルファミリーが多いのは、価格を重視して複数を候補に入れたためです。これは選定過程を反映したもので、国別のモデル品質についての結論ではありません。

一つのランナーで6つのモデル実験

共通のゲームとして、オリジナルの三人称視点・3レーン型エンドレスランナーColossal Runnerを用意しました。キャラクターは自動で前進します。プレイヤーはレーン変更、障害物のジャンプ越え、頭上の障害物の下をスライディング、コインの収集、衝突後のリスタートを行います。キーボードとタッチ操作で同じ画面上の結果になることも必要でした。

元の依頼には、一時停止、獲得コインを使った復活、2レーンを塞いで安全なルートを一つ残す巨大障害物も含まれていました。こうした連動するルールにより、スコア表示付きの動く場面だけを作る依頼より多くのことを確認できます。

2026年10月11日から17日に、同じオリジナル依頼を使って以下の実験を行いました。

いずれも開発者が個別に行った実験です。実用的な比較材料にはなりますが、限界があります。各モデルは異なる簡易案と実装を生成し、見た目もそれぞれ違いました。テスト日は異なり、ウェブサイトの環境も固定していませんでした。MiMo Flashではビルド前に追加のやり取りが必要でした。時間には相談、仕様作成、プレイテストを含まず、GLMの数値は拒否されるまでの時間です。

DeepSeekランナーでは、既存の生成制約とMiMo実験で使った同じ3Dビルダー指示を維持しました。受け入れチェック前にソースを手動で修正していません。この一連の実験から、統計的に信頼できる速度や品質のランキングが得られるわけではありません。

MiMo、GLM、Haikuから分かったこと

MiMo Flashは、確認可能なゲームを生成し、有用な操作テストもできました。 範囲を限定したキーボード、タッチ、一時停止のチェックも行えました。問題はコインのルールでした。ランナーがコインに届く前に報酬が入る場合がありました。取得判定で誤った位置フィールドを読み取っていました。見栄えのする画面と増えていくカウンターが、壊れた操作を隠していました。

後で選択的な修正を加える前のMiMo Flash初期出力。取得タイミングの不具合はゲームプレイとソースの確認で判明しました。この画像だけでは証明できません。

MiMo Proもプレイ可能な試作版を生成しました。 方向操作とコイン接触のチェックは良好でしたが、空中で一時停止すると別の問題が見つかりました。距離とコインの加算は止まる一方、キャラクターは落下し続けました。完全な一時停止では、縦方向の移動を含む関連シミュレーションを止める必要があります。

MiMo Proで最初に生成した街の画面。一時停止の不具合を見つけるにはジャンプ中の確認が必要で、見栄えのよい静止画像では分かりません。

GLMについては、別々の2つの結果を記録する必要があります。 Studioの実行では、検証機能がインラインのゲームコードを禁止対象のリソース記法と誤認し、配信に失敗しました。これはプラットフォームの問題です。GLMにゲームを生成できなかった証拠として数えるのは誤りです。

変更されていないオリジナルを復旧し、別途確認しました。そこで範囲を限定した方向、タッチ、一時停止のチェックは動作しましたが、リスタート後に古いコイン表示が残る場合がありました。この確認から成果物の挙動は分かりますが、失敗したStudioの流れを成功した配信として扱うことはできません。

別途確認したGLMの復旧オリジナル。Studio経由の配信が成功した証拠ではありません。

Haiku 5.5は、このサンプルでは比較的短時間でプレビューを配信しました。 スタート画面を確認した後、初回の見た目の確認を終えてテストを終了しました。キーボード、タッチ、衝突、復活、リスタートの受け入れテストは完了していません。初見の印象だけではMiMo実験への好みは変わりませんでしたが、Haikuの品質を確定するゲームプレイの証拠はありません。

テスト記録を続けるうえで、この区別は重要です。「配信された」「見た目を確認した」「挙動を検証した」は、それぞれ異なる段階です。

左操作が右に動くのはなぜ？

Grokランナーでは、最も分かりやすい操作の問題が見つかりました。中央レーンからArrowLeftを押すと、キャラクターが画面右側へ移動しました。左スワイプでも同じ動きになりました。

入力前：ランナーは中央にいる。

ArrowLeft入力後：ランナーは明らかに右側へ移動している。どちらの画像も未変更の生成ビルドを撮影したものです。

ソースを確認すると原因が分かりました。ハンドラーは「左」に向かってワールド座標のXを減らしていましたが、カメラの向きによって、その移動が画面上では右に見えました。キーボードとタッチが同じレーン制御を使っていたため、両方で誤りが起きていました。

プレイヤーの基準は画面上に見えるコースです。座標が減少したからといって、画面上でも左へ動いたとは限りません。追従カメラでは、コースが移動して画面中央にキャラクターがとどまる場合があるため、レーンに対するキャラクターの位置も確認する必要があります。

別のレース実験では、評価方法にも弱点があると分かりました。自動操作プログラムは逆になったハンドル操作を補正してラップを完走できました。現在は各方向を新たに開始した状態から個別に確認します。コースを完走しただけでは、操作のラベルが正しいことを検証できていませんでした。

DeepSeek V4のランナーテストで確認したこと

仕様の確認後、最新のランナーはおよそ7分で生成されました。ウェブサイトのプレビューでオリジナルの結果をテストしました。

• 方向操作： ArrowLeft、ArrowRight、A、Dは画面上で正しいレーンへ移動しました。連続入力でも外側のレーンを越えませんでした。
• タッチ操作： 縦長・横長の表示をエミュレートした状態で左右スワイプが動きました。上スワイプでジャンプし、下スワイプで着地してスライディングしました。
• 障害物： キーボード操作で地上の障害物を飛び越え、頭上のバーの下を滑り、巨大な障害物を安全なレーンで避けました。
• コインと復活： コインに到達してから収集が始まりました。獲得コインを使って復活すると、安全にプレイを再開しました。購入できない復活では、コインも使用回数も消費されませんでした。
• 一時停止とリスタート： ジャンプ中の一時停止では、高さと距離が維持され、コース操作は無効になりました。リスタートすると中央レーン、距離、表示コインがリセットされました。

障害物コースの一度の走行では、216メートルを超え、51枚のコインを獲得しました。ブラウザー自動化では通常のゲーム操作を行いました。結果を得るために座標、スコア、衝突状態を改変していません。

ブラウザーの縦長画面エミュレーションでは、左スワイプで画面上の左レーンへ移動します。実機スマートフォンの互換性は未テストです。

ランダムな障害物のすべてのパターン、列車屋根ルート、復活回数の上限、終盤の状態を網羅したわけではありません。テストした範囲では、ルール処理に期待が持てる、動作する試作版でした。

ロジック、アート、読みやすさは分けて評価する

DeepSeekランナーでは、青緑色のキャラクター、明るいレーンの縁、金色のコイン、色の違う障害物を見分けられました。暗く簡素な環境とシンプルな建物には、見た目を改善する余地が多く残っていました。一つの結果だけでは、DeepSeekはロジックがアートより得意だという一般論にはなりません。

別のNeon Harbor Sprint実験では、ネオンのスタイルは魅力的でしたが、車の輪郭や道路は見分けにくくなりました。描画解像度を下げる性能改善で応答性は向上したものの、鮮明さは失われました。

別のDeepSeek製レース試作版。異なる依頼を使っており、共通ランナーの比較対象ではありません。

別のゲームでは比較が分かりにくくなるため、ランナーに戻りました。このレーサーからも有用な教訓が得られます。ゲームが動いている状態で、実際のプレイサイズにおけるキャラクター、障害物、レーン境界を評価しましょう。エフェクトや装飾があっても、読みやすさが損なわれていることがあります。

プロンプトやスキルの制約は厳しすぎる？

同じ依頼を再利用できるよう、ランナーの依頼は意図的に詳細にしました。通常の制作者は、もっと短いアイデアから始められるはずです。そのアイデアを役立つ依頼文に整えることも、製品の役割です。

短い依頼と詳細な依頼を、条件を統制して比較する実験は行っていません。そのため、プロンプトの長さだけで操作の逆転を説明することはできません。失敗したソースにはカメラと入力の直接的な原因があり、共通の依頼を使った別の出力では方向が正しく動きました。

一貫した操作、コインに触れたときの正しい反応、完全な一時停止、きれいなリスタートなど、ゲーム体験を守る制約もあります。一方で、テーマ、色づかい、カメラの見せ方、モデルが画面を構成する方法には自由を残せます。厳格な制作フローが、初版を確認して改善する余地を狭める可能性もあります。改訂の機会を増やす効果は今後検証する価値がありますが、現時点では仮説です。

これまでの試行から、ワークフローを考える重要性が分かりました。あるMiMoの試みでは、ゲームを配信する前に応答の利用上限に達しました。別の試みではコードを書きましたが、プロバイダーストリームの障害で最終配信に失敗しました。これらは原因が異なるため、ゲームプレイ上の欠陥とは別に記録する必要があります。また、過去の試行すべてをモデルのみのA/Bテストとして扱うこともできません。

制作者は、次のような短い依頼から始められます。

3レーンの簡単な3Dランナーを作ってください。キーボードかタッチで左右に移動し、障害物をジャンプで越え、梁の下をスライディングできるようにしてください。見やすいキャラクター、気持ちよいコイン取得、衝突後すぐにリスタートできる操作がほしいです。舞台とビジュアルスタイルは選んでください。

これは比較実験に使った元の依頼ではなく、開始案です。Studioでは不足しているルールを確認し、依頼内容を確定しながら創造的な選択の余地を残せます。その後、短いプレイテストで次に役立つ修正を見つけられます。

これらのテストを次の実験にどう活かすか

私たちにとって、最適化とは配信の信頼性、確認にかかる時間、遊べる結果に必要な修正量も含みます。通常の操作に耐え、扱いやすい改訂ループで改善できるなら、低コストの生成には意味があります。

今後はオリジナル出力を保存し、各試行がどの段階まで進んだか記録し、キーボードとタッチの動作を画面で見える結果と照らして確認します。将来の比較では、ゲームを同じに保ち、依頼の長さや改訂の機会といったワークフローの条件を一つだけ変えられます。今回の観察だけでは、その実験でどのモデルが優れるかは分かりません。

プレイ可能な例として、Colossal Runnerをお試しください。公開中の選択的改訂版には、後から加えた修正が含まれており、ここに示すオリジナル実験とは別です。ほかのブラウザーゲームも見て、作りたい体験のアイデアを探せます。

小さなゲームのアイデアがありますか？OpenGame Studioで依頼を始め、基本のゲームループを決めて、最初のバージョンを実際の操作でテストしましょう。

出典について

モデル名、リリース時期、各社の位置付けは、公式情報で確認しています。DeepSeekの10月17日リリース、Grok 4.6、MiMo V2.6 Flash、MiMo V2.6 Pro、GLM 5.3 Flash、Claude Haiku 5.5、参考として取り上げた未テストのフラッグシップモデルClaude Opus 5.5です。

ゲームプレイの観察と生成時間は、OpenGame Studioで行い、オリジナルを保存した私たち自身の実験に基づいています。8枚の画像は確認時に撮影した未変更の画面で、オリジナルのプロシージャルアートまたはCC0-1.0でライセンスされたOpenGame M0キャラクター素材を含みます。プロバイダーのデモ画像でも、加工して再構成した画像でもありません。