ローカルLLMでゲームを作るときの選び方と進め方

ローカルLLMの「できること」と「限界」を先に知る

ローカルLLMが得意なのは、比較的短いコード片の生成と修正です。「キャラクターをキー入力で動かすJavaScriptを書いて」「衝突判定のロジックを直して」といった、一度に扱う文脈が短いタスクであれば、中規模のモデルでも実用的な出力が得られます。

苦手なのは、長いコードベース全体を把握して矛盾なく修正する作業です。クラウドAPIのモデルが数万〜数十万トークンのコンテキストウィンドウを持つのに対し、ローカルで現実的に動かせる小〜中規模モデルは数千〜数万トークン程度に収まることが多く、ファイルをまたぐ設計の相談や大きなリファクタリングは精度が落ちやすくなります。また、最新のライブラリ仕様や最近登場したゲームエンジンの知識は、学習データのカットオフ以降は反映されません。

「ローカルで完結させたい理由」を最初に明確にしておくことが重要です。理由がセキュリティなら完全オフラインが必須ですが、単にAPIのコストを減らしたいだけなら、無料枠のあるクラウドサービスと使い分ける方が現実的な場合もあります。

PCスペックとモデル選びの判断基準

ローカルLLMを動かすのに最低限必要なスペックの目安は、一般に公開されているモデルの動作要件を参照するのが確実です。ここでは概念的な基準を示します。

GPU搭載の有無で選択肢が変わる

GPU（VRAM）が十分にあるPCでは、モデルの推論がCPUだけで動かす場合より大幅に速くなります。コード生成で実用的な速度を得るには、モデルのサイズに見合ったVRAMが必要です。GPUがない、またはVRAMが少ない場合はCPUとRAMだけで動かす構成になりますが、応答までの待ち時間が長くなります。開発中の「すぐ直したい」という場面で待ち時間が長いと、作業リズムが崩れやすくなります。

モデルのパラメータ規模と量子化

ローカルで使われるモデルは、配布サイズを小さくするために「量子化」（数値の精度を落として圧縮する処理）が施されていることがほとんどです。同じパラメータ数でも量子化の段階が違うと、ファイルサイズと生成精度のバランスが変わります。ゲームのロジックコードを生成する用途では、パラメータ数が大きく量子化が浅いモデルほど精度が高い傾向がありますが、その分PCへの要求も上がります。

実際に使うモデルを選ぶ際は、コード生成ベンチマーク（HumanEvalなど）のスコアと、自分のPCで動かせるサイズのバランスを見て選ぶのが基本的な方法です。

実際にローカルLLMをセットアップする流れ

ローカルLLMをゲーム開発に使い始めるまでの大まかな手順を示します。

1. ランタイムを選ぶ

モデルをローカルで動かすには、推論を実行するランタイムが必要です。現在よく使われているのはOllamaとllama.cppです。OllamaはCLIとAPIサーバーをまとめて提供していてセットアップが比較的簡単です。llama.cppは細かいオプションを調整したい上級者向けですが、対応形式が幅広く動作環境の柔軟性があります。公式ドキュメントでOS・GPU環境ごとの導入手順を確認してから始めてください。

2. コード生成向けのモデルをダウンロードする

Hugging FaceやOllamaのライブラリには、コード生成に特化したモデルが複数公開されています。DeepSeek CoderやCodeLlamaなど、コードを主な学習データに含むモデルはHTML・JavaScript・Pythonの出力品質が汎用モデルより高い傾向があります。初めて使う場合は、自分のPCで許容できる最大サイズのモデルを一つ選んで試し、応答速度と精度を確かめてから他を比較する進め方が効率的です。

3. エディタと連携させる

VS CodeにはローカルLLMのAPIに接続できる拡張機能がいくつかあります（Continue、Tabby、などが知られています）。これらを使うと、エディタ上でコード補完や質問ができるようになり、ブラウザゲーム開発に使うHTML・JavaScript・CSSのファイルをその場で修正できます。ランタイムのAPIエンドポイント（通常はlocalhost上のポート）を拡張機能の設定に入力するだけで接続できます。

4. プロンプトの粒度を調整する

ローカルモデルは一度に処理できるコンテキストが短いため、「ゲーム全体を作って」ではなく「このHTML内のジャンプ処理だけを書き直して」と部品単位で指示する方が精度が出ます。生成されたコードは必ずブラウザで動作確認してから次の指示を出す、という小さなサイクルを繰り返すのが失敗しにくい進め方です。

失敗しやすい点と回避の考え方

モデルへの期待値が高すぎる：ローカルモデルの多くは、最新のクラウドAPIと比べると複雑な設計の提案や長いコードの一貫性維持で劣ります。「補助ツール」として位置づけ、最終的な動作確認と設計判断は自分で行う前提で使うとストレスが少なくなります。

RAMとVRAMを使い切る：ゲームをブラウザでテストしながらLLMを動かすと、ブラウザとモデルが同時にメモリを消費します。メモリが不足するとOSのスワップが頻発して全体が遅くなるため、モデルのサイズはシステムRAM・VRAMの半分以下を目安に選ぶと動作が安定します。

オフライン環境でのモデル更新が手間になる：モデルファイルはサイズが大きく、更新のたびに再ダウンロードが必要です。インターネット接続が制限されている環境では、更新のタイミングと手順を事前に決めておく方が運用しやすいです。

ライセンスの確認を忘れる：公開されているモデルにはそれぞれライセンスがあり、商用利用の可否が異なります。ゲームを公開・販売する場合は、使用したモデルのライセンスを必ず確認してください。個別の判断は公式ドキュメントや必要に応じて専門家に相談することをお勧めします。

クラウドAPIとの使い分けを決める基準

ローカルLLMとクラウドAPIはどちらかを選ぶというよりも、場面で使い分けることが現実的です。

• 通信できない環境での作業、ローカルLLMが向く：◯、クラウドAPIが向く：✕
• APIキーを持ちたくない場面、ローカルLLMが向く：◯、クラウドAPIが向く：✕
• 長いコードの設計相談、ローカルLLMが向く：△、クラウドAPIが向く：◯
• 素早い応答が必要なとき、ローカルLLMが向く：△（スペック依存）、クラウドAPIが向く：◯
• 繰り返し使うコスト削減、ローカルLLMが向く：◯（初期投資後）、クラウドAPIが向く：△（従量課金）

ゲームのプロトタイプを短期間で作りたい場面ではクラウドAPIの応答精度と速度が有利で、継続的にAIを使いながらコストを抑えたい場面ではローカルLLMが候補になります。

次の行動

まずOllamaの公式ドキュメントを参照してセットアップ手順を確認し、自分のPCスペックに合うコード生成向けモデルを一つ選んでみてください。動かせたら、ブラウザゲームの部品（当たり判定・スコア計算など）を一つだけ生成させて精度と速度を確かめるところから始めると判断しやすくなります。作れたゲームはアソバースにHTMLファイルやZIPとして投稿して公開できます。

参考資料

• Ollama 公式ドキュメント
• llama.cpp GitHub リポジトリ
• Hugging Face モデルカード（各モデルのライセンス・動作要件）
• Continue 拡張機能 公式ドキュメント
• HumanEval ベンチマーク（OpenAI、コード生成評価指標の説明）