ローカルLLMでゲームやコードは自作できるか｜完全オフライン・反復前提で27〜30B級モデルが到達できる範囲

ローカルLLMの自作とは、反復と分解を前提にオフラインでコードを組み上げる手法。

単発のゼロショット生成なら、動くだけの試作で止まりがちです。けれど無限に試行を重ね、作るものを小さな単位に割って一つずつ繋いでいく前提に立つと、到達点はまるで変わってきます。海外のRedditコミュニティ（r/LocalLLaMA）では、「完全オフラインのローカルLLMに、何度でも書き直させながら1か月ほどかければ、どれくらいのゲームが作れるのか」という問いが話題になっていました。本記事では、その議論を起点に、27〜30B級のローカルLLMがゲームやコードをどこまで形にできるのか、到達範囲と限界の見極め方を整理します。

ゼロショット単発と「反復＋タスク分解」はまったく別の問い

ローカルLLMにゲームを作らせる話は、YouTubeなどで見かける「ゼロショットテスト」のイメージで語られがちです。これはモデルに一回だけチャンスを与え、有名ゲームの簡易版を一気に書かせて、どこまで動くかを見る試み。結果は往々にして、バグだらけの薄い再現に終わります。

ただ、r/LocalLLaMAで投げかけられていた問いは、その逆でした。試行回数を無制限にし、プロジェクトをいくつものパートに分解し、一つずつ動く状態にしてから接続していく。そうやって1か月かけたら、どこまで「ちゃんと動くゲーム」に近づけるのか、という問いです。同じ「ローカルLLMでゲームを作る」でも、出発点がまるで違います。

なぜ単発生成は試作どまりになりやすいのか

一発で全部書かせる方式が崩れやすいのは、モデルが長い出力の途中で前提を見失うため、と考えられます。ゲーム1本ぶんのコードを最初から最後まで一続きに書かせると、後半で前半の変数名やロジックとの整合が取れなくなり、実行すると壊れる。これはコミュニティでもよく指摘される現象で、「一発勝負はモデルの実力を測るには向くが、実用物を作る方法ではない」という見方が出ています。

加えて、ゼロショットは一度きりなので、エラーが出てもその場で直せません。人間の開発でも一発でバグゼロのコードは書けないのに、モデルにそれを求めるのは前提が厳しすぎる、とも言えます。

分解して接続するとどこまで変わるか

反復前提の議論で繰り返し挙がるのが、「自己完結し、テスト可能な単位に割る」という進め方です。プレイヤーの移動だけ、当たり判定だけ、スコア表示だけ、というように機能を小さく切り出し、それぞれを単体で動く状態まで詰めてから全体に組み込む。この構造化されたアプローチを取ると、モデルが一度に扱う文脈が小さくなり、整合を保ちやすくなる、という質的合意がコミュニティにはあります。

これはあくまで実践者の感触であって、ラボでベンチマークされた事実ではありません。ただ、人間がソフトウェアを設計するときの常道とも重なるため、説得力のある見方と言えます。試行回数という武器は、分解とセットで初めて効いてくる、と考えられます。

大きなプロジェクトほど、最初から全体を一気に書かせるのではなく、機能のまとまりごとに小さく分解し、セクション単位で「動いて検証できるシステム」に仕上げていくのが要点です。各セクションの精度を上げてから、最後にそれらを繋いで全体を組み上げる——この順序こそが、出力の精度を底上げする核心になります。

この「分解して文脈を整理する」という考え方は、ローカルLLMだけに限ったものではありません。クラウドの大規模モデルでも、巨大な仕様を一度に投げるより、機能ごとに分解し、入出力や接続条件を明確にしながら組み上げる方が安定します。違いは、クラウドの上位モデルほど扱えるコンテキスト量や推論力に余裕があるぶん、ローカルほど細かい粒度まで意識しなくても結果が出やすい場合がある点です。逆にローカルLLMでは、コンテキスト量・VRAM・生成速度の制約が強く出るため、分解の粒度をより小さくし、各部品を個別に検証してから接続する意識がより重要になります。つまり、分解して文脈を整理するという原則自体はローカルでもクラウドでも共通で、ローカルではそれをより厳密に運用する必要がある、という整理が現実的です。

モデルに「何を・どの順で・どこまで渡すか」を設計するこの考え方は、コンテキストエンジニアリングとして体系化されています。接続部で破綻させないための土台になる考え方なので、本格的に作り込むなら合わせて押さえておくと役立ちます。

27〜30B級を完全オフラインで回す前提条件｜VRAMと量子化

ここがハード軸サイトとして外せない部分です。何度でも書き直させる運用は、モデルが手元で快適に回ることが前提になります。そこで関わってくるのが、VRAM（ビデオメモリ。GPUがモデルの重みや計算データを置くための専用メモリのこと）の容量と、量子化（モデルの重みを低い精度に圧縮し、サイズと必要メモリを減らす手法のこと）のグレードです。

コーディング志向のローカルモデルとして実在が確認できるのが、Qwen公式のQwen3-Coder-30B-A3B-Instructです。総パラメータ30.5B・アクティブ3.3BのMoE（Mixture of Experts。全パラメータのうち一部だけを推論ごとに使う構造のこと）で、48層、ネイティブで256Kのコンテキスト長（YaRNで最大1Mまで拡張）を持ちます。エージェント的なコーディングを主眼に置いたモデルです。

問題は、このクラスをどの量子化で持つかでVRAM要件が大きく動く点。Unsloth公式のGGUF（ローカル実行向けのモデルファイル形式のこと）サイズを並べると、収まり方がはっきり見えてきます。

Q8_0は載らない｜量子化グレード別の収まり方

RTX 5080は16GB GDDR7・256bitバス・10752 CUDAコアのBlackwell世代GPU。これが「16GBクラス」のローカルLLM運用の基準になります。表のとおり、Qwen3-Coder-30B-A3Bを16GBの1枚に載せようとすると、実用上はおおむねQ3_K_M〜IQ4_XSまで。Reddit投稿で言及されていた「Q8_0で27〜30B級」という前提は、16GBクラスのGPU単体には収まりません。

VRAMに収まらないときの現実的な落とし所

16GB単体に載らないグレードを使いたい場合、選択肢はいくつかあります。一つは量子化を落として収めること。もう一つは、一部の層をシステムRAMにオフロードして動かす方法です。MoE構造のモデルはアクティブパラメータが小さいため、フルにVRAMへ載せきれなくても、構成次第では実用速度を保てるケースがあります。ただしオフロードした層はシステムRAMとGPUの間で転送が挟まるぶん、生成速度は確実に落ちます。何度も試行する用途ではこの速度低下が反復のテンポにそのまま響くため、まずは量子化を一段落として1枚のVRAMに収めきる方を優先したい場面が多くなります。どうしても上のグレードを使いたいときだけ、オフロードを選択肢に入れるのが現実的です。

当サイトの検証環境（RTX 5080＋RTX 5060 Tiのデュアル構成・think=false統一・）では、qwen3-coder:30bが145.3 tok/sを記録し、VRAM使用量はGPU全体で10840MiB（約10.59GiB）でした。これはGPU全体の使用量（デスクトップ等のベースライン込み）であり、モデル単体の増分とは別物。2枚構成での値なので、16GB1枚の数値ではない点も添えておきます。1枚で収めたい場合はQ3_K_M〜IQ4_XSへ落とす前提になり、そのときの生成品質は別途確認が要ります。

なお、当サイトの検証はthink=falseで統一し、各モデルを複数回計測した中央値を採っています。実測値はOllamaやドライバ、モデルの版で変わるため、ここでは本記事執筆時点のスナップショットとして据え置きます。

反復前提で到達できる範囲と、人間の介入が不可欠になる境界

到達範囲の話に進みます。ここはRedditソースの考察が中心になるため、検証済みの事実・コミュニティの議論・推測を分けて書きます。

反復で詰めやすい領域（ループ・UI・小ロジック）

基礎的なゲームループ、シンプルなUI、単体でテストできる小さなロジック。この層は、反復前提なら現実的に形になりやすい、というのが実践者の感触です。プレイヤーが動いて、何かに触れて、スコアが増える――こうした自己完結した部品は、モデルが一度に扱う範囲が狭いため、何度か書き直せば動く状態に持っていける、という見方が出ています。

「小さく割って一つずつ接続する」進め方が効くのは、まさにこの領域だと考えられます。試行回数を武器にできるのは、各パートが単体で検証できるサイズに収まっているときです。

具体的には、ブロック崩しやスネーク、シンプルな落ち物パズル、ターン制の数当てのように、状態が少なく1画面で完結するゲームが、この「反復で届きやすい」層の典型です。1機能ずつ動かして確かめられるため、試行を重ねるほど少しずつ完成度が上がっていきます。まずはこの規模から始め、動いた部品を土台に範囲を広げていくのが、反復前提の自作では堅実な進め方になります。

モデル単体では崩れやすい領域（状態整合・衝突判定）

一方で、複雑なゲーム状態の整合や、込み入った衝突判定の維持には、人間の継続的な介入が要るというのがコミュニティの大方の感触です。パーツが増え、相互に影響し合うようになると、モデルは全体の整合を見失いやすくなる。あるパートを直すと別のパートが壊れる、という揺り戻しが起きやすくなります。

SOTA級と目されるGLM-4.6（200Kコンテキストを持つ実在モデルで、エージェント的コーディングで実運用される）のようなモデルを使っても、複雑な「バイブコーディング」（仕様を細かく書かず、対話だけで作らせる進め方のこと）は依然として難しく、基本的なゲームループやUIの生成に留まりやすい、という見方があります。これも査読された結論ではなく、実践者の議論として帰属しておきます。

もう一段踏み込むと、クラウドの大規模モデルを本格的に使う段階では、モジュール内部を正確に書けること自体はほぼ前提になります。精度の差が出るのは、むしろモジュール同士が連動する継ぎ目の方です。モジュールが増えるほど、相互作用の組み合わせ——どのモジュールがどの状態でどう影響し合うか——は急速に膨らみ、モデルはその分岐をすべて整合させながら推論しなければならない。大規模モデルの失敗の多くが、個々の部品ではなく接続部で起きるのはこのためです。だからこそ上級者ほど、モジュールを増やすこと自体より、継ぎ目を狭く・疎結合に設計して、追うべき分岐の数を抑えることに注力します。分解は「細かく割る」だけでなく、「つなぎ目をいかに単純に保つか」まで含めて、初めて精度に効いてきます。

ここで一つ、見落とされがちな壁があります。ゲーム設計やシステム設計の知識そのものが、指示の精度と成果物の質を左右する点です。何を作るか、どう分割するか、どこがバグの温床かを判断できる人ほど、モデルから良い出力を引き出せる。逆に、まったくコードを書けない人がモデルだけで複雑なゲームを完成まで持っていくのは難しい、と考えられます。モデルは「指示された範囲を埋める」道具であって、設計の意思決定まで肩代わりしてくれるわけではありません。

つまり到達範囲は、モデルの実力だけでなく、使う人がどれだけプロジェクトを分解・検証できるかに大きく依存します。本記事で測れているのは収容条件と速度の次元であって、生成されるゲームの品質や面白さは別物。ご自身のタスクで実際に確認する前提で読んでください。

なぜ完全オフラインで自作するのか｜従量課金との対比

なお、ここでいう完全オフラインは、モデル推論とコード生成を外部APIなしで手元のGPUで行うという意味です。ライブラリの取得や公式ドキュメントの確認まで一切不要になるという意味ではありません。

「無限に試行する」という前提は、コストの面でローカル運用と相性が良い、と考えられます。

クラウド型のAIコーディング支援は、近年トークンや使用量に応じた従量課金へと移行が進んでいます。複数ファイルを参照し、内部で何度もモデルを呼び出すエージェント型の機能ほど、一回の依頼で消費する量は読みにくく、試行を重ねるほど費用がかさみやすい。何度も書き直させる進め方は、メータ課金のクラウドとは構造的に相性が悪い側面があります。

クラウド側の料金やデータ取り扱いをモデル別に比較した話は、姉妹サイトのDeepSeek V4はクラウドで使うべきか｜料金・コーディング精度・データ取扱いをClaude・GLM-5.2と比較でも整理しています。

その点、完全オフラインのローカルLLMは、何回試行しても課金が増えません。電気代と時間はかかりますが、「クレジット残量を気にせず無限に書き直す」という運用がしやすい。Redditで「offline・unlimited attempts」が前提に置かれていたのは、この自由度を見込んでのことだと考えられます。

反復回数がコストに跳ねないオフラインの利点

ただし、ローカルが無条件に安いわけではない点も正直に書いておきます。前提となるGPU（RTX 5080なら参考価格20万円〜）の初期費用、推論時の電力、待ち時間といったコストは確実に発生します。RTX 5080のTDPは360W。長時間回せば電気代も積み上がります。「従量課金から自由」という利点は、こうした固定的なコストと引き換えに得られるもの、と捉えるのが正確です。

それでも、設計と検証を自分で回せる人にとって、試行回数が費用に直結しない環境は大きな武器になります。失敗を恐れず何度でも作り直せること自体が、反復前提の自作では効いてきます。

スペック別の到達範囲ガイドライン

ここまでの内容を、VRAM容量ごとの現実的な到達範囲として整理します。あくまで27〜30B級コーディングモデルを反復前提で回す場合の目安です。

この表は容量と量子化の対応を示すもので、生成されるゲームやコードの品質を保証するものではありません。同じ16GBでも、作る人がプロジェクトをどれだけ分解・検証できるかで成果は変わります。VRAMはあくまで「どのグレードのモデルを手元で回せるか」という入口の条件、と捉えてください。

もう一つ、反復前提では容量と並んで「推論速度」が効いてきます。コードを何十回と書き直させる使い方では、1回あたりの生成が数秒違うだけでも、回数を重ねるほど待ち時間が積み上がる。同じ16GBに収まるモデルでも、生成が速いGPUほど試行のテンポが上がり、反復のサイクルを多く回せます。VRAMが「そのモデルを動かせるか」という入口の条件だとすれば、推論速度は「どれだけ速く反復できるか」を左右する軸です。容量に余裕があるなら、その上で生成の速いGPUを選ぶと、コードの反復作業では体感が大きく変わります。用途ごとのGPUの選び分けはVRAM 16GB GPUの選び方でも整理しています。

まとめ

到達範囲を改めて整理します。基礎的なゲームループやUI、小さなテスト可能ロジックは、反復＋タスク分解を前提にすれば27〜30B級モデルでも形にできる見込みがあります。一方、複雑な状態整合や衝突判定の維持には、人間の継続的な介入が前提になります。27〜30B級コーディングモデルのQ8_0（約32.5GB）は16GBクラスに収まらず、16GBではQ3_K_M〜IQ4_XSで載せる運用が現実的。そして完全オフラインは、試行回数が課金に跳ねないという点で「無限の修正」と相性が良い、というのが本記事の見立てです。

次の一歩としては、まずご自身が作りたいものの規模を見極めることから始めてみてください。小さなツールや単純なゲームなら反復で届きやすく、複雑な作品ほど設計知識と人間の手が要る。そのうえで、手元のGPUがどの量子化まで回せるかを上のガイドライン表で照合すれば、現実的な期待値が見えてきます。ご自身なら、どこまでをモデルに任せ、どこから自分で手を入れますか。その線引きこそが、完成度を左右する分かれ目になります。

よくある質問

Q. 16GBのVRAMで27〜30B級モデルは動く？

量子化を落とせば動きます。Qwen3-Coder-30B-A3BならQ3_K_M（14.7GB）やIQ4_XS（16.4GB）が16GBクラスの実用ライン。Q4_K_M（18.6GB）以上やQ8_0（32.5GB）は16GB単体には収まりません。コンテキストを伸ばすと追加でメモリを使う点も見込んでおくと安心です。

Q. Q3まで落とすとコード生成の質は落ちる？

量子化を下げるほど精度面の影響は出やすくなります。ただし、どの程度落ちるかはモデルやタスクに依存し、本記事では品質の定量評価はしていません。速度やVRAMは測れても、生成コードの正しさは別の次元。ご自身が作りたいコードで実際に試して判断するのが確実です。 量子化グレード別のVRAMと速度の実測比較は、ローカルLLMの量子化はどれを選ぶかでも扱っています。

Q. 非エンジニアでもゲームは完成させられる？

小規模なものなら可能性はありますが、複雑な作品ほど難しくなる、というのが実践者の感触です。ゲーム設計の知識自体が指示の精度を左右するため、まったくコードを書けない状態でモデルだけに任せて完成まで届くケースは限られると考えられます。分解と検証を自分で回せるかが鍵になります。

Q. ローカルとクラウド、どちらが安い？

試行回数が多いほどローカルが有利になりやすい、と考えられます。クラウドのAIコーディング支援は使用量に応じた従量課金が主流で、試行を重ねるほど費用が積み上がります。ローカルは初期のGPU費用と電力・時間がかかる代わり、何回書き直しても課金は増えません。無限に試行する前提ならローカルと相性が良い、というのが見方の一つです。

参考資料

• Qwen 公式: Qwen3-Coder-30B-A3B-Instruct モデルカード（Hugging Face）
• zai-org 公式: GLM-4.6 モデルカード（Hugging Face）
• NVIDIA 公式: GeForce RTX 5080 製品ページ