AI開発のトークンをローカルLLMで節約したい。コーディング担当は諦めて、前処理エージェントにした

はじめに

UnityやUnreal Engine、Rojo（Roblox）等をMCP経由でAIに操作させることで、誰でも簡単にゲーム開発をすることができるようになってきました。

以前、Unityをほぼ触ったことがない状態から、Unity MCPでレースゲームを作って公開するまでを記録しました。今回は、その続きとして「便利になったぶん増えるAIの作業量を、どう抑えるか」を試してみた話です。

前回: [Unity を触ったことがない素人が、Unity MCP でレースゲームを作って公開するまで]

AI開発ではAIに渡す情報は膨大になります。Consoleのエラー、ビルドログ、diff、関連スクリプトなどを読むため、クラウドAIだとトークンも相当に使い、コストも膨らみます。

そこで考えました。

軽いタスクだけでもローカルLLMに任せられれば、クラウドAIのトークン消費を抑えられるのでは？

手元のPCは RTX 5060 Laptop GPU、VRAMは8GBしかありません。大きなモデルをそのまま動かすのは厳しいため、4B前後の量子化モデルで試してみました。

結論から先に書くと、ローカルLLMにコーディングを任せる案はいったん見送り、ログを整理する担当にしました。 この記事は、そこに至るまでの備忘録です。

まずはコーディング担当としてやらせてみた

最初は、クラウドAIが計画とレビュー、ローカルLLMが小さな修正を担当する形を考えました。

ただ、コーディングは「コードを書ける」だけでは足りません。

• 指定されたファイルだけを直す
• JSONなどの返答形式を守る
• テストが失敗したら、原因に合わせて直す
• 触ってはいけない場所を触らない

このあたりを毎回守れるかを確認するため、Pythonの小さなTODOアプリを使ってテストしました。課題は追加、完了、JSONでの永続化、名前変更、検索、並び替えの6種類です。公開テストだけでなく、AIに見せない追加テスト、指定外ファイルの変更検出も通ったものだけを成功にしています。

モデル	成功数	試行数
Qwen3.5 4B	9	12
Qwen2.5-Coder 7B	4	12
GLM4 9B	3	12

Qwen3.5 4Bは意外と健闘しました。ただし、これは小さく固定したPython課題での結果です。ゲーム開発などの案件では、コード以外にアセット、シーン、エディタ操作まで関わります。75%で「修正を任せて大丈夫」と言うには、まだ心配が残ります。

Qwen3.8も試してみた

次に、Hugging Faceに登録されていた Qwen3.8 Distill 4BのQ5量子化モデルを試しました。

モデル名について: ここでいうQwen3.8はAlibaba公式の「Qwen3.8」ではありません。ドイツを拠点に活動する独立系のAI研究ラボ EmperoがQwen3.5-4Bアーキテクチャをベースに蒸留したコミュニティモデル empero-ai/Qwen3.8-4B-Distill-GGUF です。モデルカードの説明と来歴を確認した上で使いました。

項目	結果
GPU	RTX 5060 Laptop GPU
実VRAM	8,151MiB
モデル常駐時のGPU使用量	3,871MiB
コーディング評価	6 / 12 合格

モデルはVRAMには問題なく収まりました。小さな関数を一回で書ける場面もありました。

ただし、修正を繰り返すとこれが崩れてしまいました。JSONが途中で切れたり、括弧が合わなかったり、指定した制約を忘れたりします。このような失敗もあり、開発で使う実用的なレベルには達せていないことが分かりました。

限界が見えてきたので、方針を変えることにしました。

コーディング担当ではなく、クラウドAIが読む前に情報を整理する担当ならどうだろう？

ローカルLLMには「参照・整理だけ」を任せる

Qwen3.8には、ログ、diff、ファイルの抜粋を渡します。返してもらうのは、短い要約と「どのログを根拠にしたか」だけです。

Qwen3.8には、ファイル編集、コマンド実行、Unity/UE/Rojoの操作をさせません。最終判断はCodexやClaudeに残します。

また、Qwenの返答がおかしい場合や、自信がない場合は、要約を使わずに元のログを全部クラウドAIへ渡します。ここでは、これを fail_open と呼びます。

※セキュリティ分野の fail-open と同じ意味ではありません。この記事では、要約を採用せず、元データの全件確認へ戻すフォールバックを便宜上こう呼びます。

実際にQwenから受け取るのは、例えばこんな形です。

{
  "summary": "tasks.id のSQLite一意制約違反でPOST /tasksが500になっている",
  "source_refs": ["gateway-failure", "database-failure"],
  "candidate_files": [],
  "confidence": 0.92,
  "needs_full_context": false
}

コード側でも、以下なら fail_open にします。

• JSONやスキーマが壊れている
• 存在しない根拠IDが含まれる
• confidence が0.8未満
• 例外やタイムアウトが起きる

confidence はモデル自身の自己評価です。これだけを信用せず、JSON構造、根拠IDの存在、例外の有無と組み合わせて判断します。

このときは「要約を信じない」で終わりです。元データを捨てず、クラウドAIに全件を渡します。

「ローカルLLMが間違えない」ことを目指すのではなく、間違えても作業を危なくしない形にしました。

この役に向いている仕事には、共通点があります。

• 副作用がない
• 結果を捨てられる
• 元データが残る
• 上位モデルが再確認できる
• 失敗時にそのままクラウドへ戻せる

ログの仕分けはこの条件に合います。逆に、コード編集やUnityのシーン変更は元に戻せても影響範囲が広いため、現時点では任せません。

長いログでは効果があった

42件のログから500エラーの原因を探す同じ問題で比べました。これは実案件のログではなく、評価用に作ったデータです。正常な GET /health 200 のログ40件に、POST /tasks の500ログと、それに対応するSQLite一意制約違反ログを1件ずつ混ぜました。

渡し方	クラウドAPIの合計トークン（入力＋出力）
ローカルLLMを使わない	2,246
Qwen3.8でログを整理してから送る	264

このケースでは、クラウドAPIで消費した合計トークンを 88.2%減らせました。どちらの方法でも、原因をSQLiteの一意制約違反と判断できました。

トークン数は、同じクラウドAPI呼び出しが返した usage の入力・出力トークンを記録した値です。ローカルQwenのトークンはクラウド利用量には含めていません。

ただし、これは「コストが88.2%安くなる」という意味ではありません。クラウドAIにはキャッシュがあり、入力と出力で価格も違います。短いログでは、Qwenを呼ぶ分だけ余計になることもありました。

なので、今は「ログやdiffが多いときだけQwenを呼ぶ」運用にしています。

grepで十分では？ ローカルLLMの優位性はどこにある？

その通りです。ERROR、Exception、Build failed のように定型で拾えるログなら、grepや正規表現で絞るほうが速く、安全で、LLMも不要です。

今回の42ログの実験は、Qwenによる前処理が成立するかを見るためのものです。grepとの同一条件のトークン・精度比較はまだしていません。数字を作らないため、ここでは未計測とします。

ローカルLLMを使いたいのは、次のようなgrepだけでは扱いにくい場面です。

• 複数ツールのログをまたいで、同じリクエストIDやエラーの流れを結び付ける
• 自然言語の警告、diff、ファイルの説明が混ざる
• 「この症状に関係するものだけ」という曖昧な絞り込みをする

まず機械的に絞れるものはgrepで落とし、その後にまだ量が多いときだけQwenへ渡す、という順番がよさそうだったので、この3方式を同じログで比べることにしました。

前処理	速さ・安全性	今後測るもの
なし	基準	クラウド入力と正答
grep / 正規表現	最も速く、挙動が一定	重要行の取りこぼし
Qwen3.8	文脈をまたいだ整理ができる可能性	トークン、待ち時間、根拠の正確さ

現在の担当分け

担当	使うもの
設計、実装、レビュー、テスト判断	Codex / Claude
Unity、UE、Rojoの操作	各ゲームエディタのMCP
長いログやdiffの整理	ローカルQwen3.8 + Ollama

Ollamaは、Qwenが必要になったときだけローカルで起動させます。普段から大きなモデルを常駐させないようにしています。

調べてみると、似た考え方はすでにあった

この記事を書いた後で少し調べると、ローカル小型モデルをクラウドモデルの前段に置く考え方は、すでに研究対象になっていました。Local-Splitterは、ローカルでの振り分け、プロンプト圧縮、意味的キャッシュなど複数の方法を測定しています。結果はワークロード依存で、万能の節約方法はないという結論です。

また、Anthropicもエージェントでは「何をコンテキストに入れるか」を設計する context engineering が重要だと説明しています。Effective context engineering for AI agents

今回の記事には特に新しい要素はありません。個人ノートPC、8GB VRAM、ゲーム開発MCPという条件で試してみたら、「小型モデルにコードを書かせる」より「ログを整理させる」ほうが、失敗時の影響を限定しやすかった、ということが改めてわかったという備忘録です。

これから確認したいこと

ここまでは開発に入る前のテストです。次は実際のUnity/UE/RojoのAI開発で、次のようなものを記録しようと考えています。

• Qwenを呼んだ回数
• fail_open になった回数
• クラウドの入力・キャッシュ入力・出力トークン
• 作業時間が本当に短くなるか
• ログの重要な行を見落とさないか

呼び出す量の目安も、実測で決めます。例えば「クラウドに渡す候補が500トークン以下ならそのまま」「2,000トークンを超えたら前処理を検討」といった境界は考えられますが、まだ仮説です。クラウドのキャッシュ、Qwenの待ち時間、取りこぼし率も一緒に見て決めます。

小さなローカルLLMを、いきなり「ゲームを作るAI」にするのは難しそうでした。でも、ログ整理のような小さな役なら、8GBのVRAMでも役に立つかもしれません。

今回の一番大きな学びは、小型モデルを賢くしようとする前に、間違えても困らない仕事を渡すことでした。

実際の開発での結果は、次の記事で追記しようと思います。

検証メモ

• 実行環境: Windows11、Ollama 0.34.4、RTX 5060 Laptop GPU（VRAM 8,151MiB）
• 数値はこのPCと小さな評価課題での結果です。他のPCや開発で同じ結果になるとは限りません。
• Qwen3.8のモデルは hf.co/empero-ai/Qwen3.8-4B-Distill-GGUF:Q5_K_M を使用しました。