ローカルLLMをゲームNPCへ導入する現実的な手順と設計

概要

ゲームNPCへLLMを導入すると、固定台詞だけでは表現しにくい会話、人格、記憶、状況に応じた意図の提案が可能になります。一方、LLMへ移動、戦闘、所持品、クエスト進行まで任せると、応答の遅延や誤りがゲーム状態を直接壊す構成になります。

この記事では、ローカルLLMを特定のゲームへ採用するとは決めず、導入前に分けるべき責務、実装順序、評価基準を整理します。モデル名やパラメータ数から先に選ぶのではなく、従来型ゲームAIとLLMの境界、ローカル推論とクラウドAPIの交換可能性、一つのCognitive Actorから始める現実案を扱います。

2026年時点のモデル自体の特徴は、2026年時点の主要なローカルLLMで整理しています。この記事では候補モデルが存在することを前提に、それをゲームへ安全に接続し、実測で採否を決める方法へ集中します。

2026年9月18日にAdaptive Neural CompanionとSpark-X2.5の開発元資料を確認し、初回起動の推論準備と比較候補を追加しました。既存事例は各情報日を維持し、今回の更新は当方の実測や全製品の再検証を意味しません。

結論

• 10月13日の確認では、Ollama RCの判断GGUF移行、Decision 2.0／3.0、EmbeddingGemma 2のCUDA修正を追加しました。実行版と配布物の互換性、入力制約、拒否時Fallbackを確認し、GameState・権限・期限の検証を維持します。
• 10月12日の確認では、WebLLM v0.2.86のtext／audio対応と中断修正をブラウザ向け比較経路へ追加しました。生成の永続化・再開と、現在のGameStateの検証・行動の再実行許可は分けます。
• 10月11日の確認では、LM Studio判断API、d1、UnityのBehaviorLLMを比較経路へ追加しました。数値出力、入力超過、保存slotの復元、並行要求、SDKのcache整合性を別々に検証し、ゲーム側の状態検証と実測による採否判断を維持します。
• 10月7日の追加確認では、ブラウザ内のwllamaとクラウドのOpenAI Decisions APIを、許可済み候補を評価する別々の経路として加えました。EmbeddingGemma 2はMemory検索の候補です。いずれもゲーム側の状態・権限確認と、用途別の実測が必要です。
• 9月29日に確認したÁmbar Reflexは、文章を生成しない判断方式の小規模な作者実験です。判断精度、応答時間、ゲーム成績を分けて測る材料として扱い、既存事例すべての再検証とは区別します。
• AI Follower Jessicaは、従来のコンパニオン機能にローカル会話・記憶・行動を重ねる公開Modです。作者の設定資料はゲームとLLMのVRAM競合を具体化しますが、独立した実測ではありません。
• HP、所持品、位置などのGameStateは、ゲーム側だけを正本にします。
• LLMは会話や高レベルの意図を提案し、ゲーム側のValidationを通過した要求だけを実行します。
• Structured Outputは形式を安定させますが、出力内容が現在のゲーム状態で正しいことまでは保証しません。
• 移動、照準、衝突、即時戦闘などは従来型AIで処理し、LLMはイベント駆動で呼び出します。
• ScriptedまたはFake、クラウドAPI、ローカルモデルを同じ境界の背後で差し替えられるようにします。
• 採用判断はモデルサイズではなく、日本語品質、Intent成功率、応答時間、VRAM、フレーム時間への影響から行います。
• 多数のEntityが存在しても、すべてを個別のLLM Actorにする必要はありません。
• 実装例が設計原則と一致していても、ゲームと同時実行した性能は対象環境で別途測定します。
• Epoch Forge Demoは、NPC会話にローカルLLMを使い、Gemmaとllama.cppを含むと公式Steamページで明記された、ダウンロード可能なGodot製Demoです。ただし、正確なCheckpoint、量子化形式、配布構成は公開情報から確認できません。
• ScapegoatとCometforge NPCは、一つの小型モデルを複数NPCで共有し、Memoryをシステム側で分離する構成がEarly Accessゲームまで進んだ例です。Scapegoatは2026年9月29日に無料公開されましたが、公開は独立した性能検証を意味しません。

現時点では、条件を絞った公開DemoやEarly Accessゲームで、小型モデルをオンデバイス実行する構成を確認できます。任意のゲーム、既製モデル、多数NPCで同じ結果を得られることではありません。

ゲーム側を唯一のAuthorityにする

LLMのMemoryとゲームのGameStateは分けます。LLMが「このNPCは剣を持っている」と出力しても、それを所持品の事実として扱いません。現在の所持品、位置、HP、関係値、クエスト状態は、ゲームシステムから読み取ります。

LLMへ許可するのは、状態の変更ではなく意図の提案です。

Game Event / Player Input
  → Context Builder
  → Cognitive Provider
      ├─ Scripted / Fake
      ├─ Cloud API
      └─ Local Model
  → Structured Response
  → Schema Validation
  → Semantic Validation / Authorization
  → BT・GOAP・Utility AIなど
  → Game Systems

例えば、LLMから次の応答を受け取ったとします。

{
  "speech": "この武器を使ってください。",
  "intent": "GiveItem",
  "target": "Player",
  "itemId": "sword-001"
}

JSONとして正しく、intentが許可された列挙値でも、次の確認はゲーム側に残ります。

• NPCがそのアイテムを所有しているか
• 譲渡可能な状態か
• 対象が存在し、受け取り可能か
• クエストやゲームルールへ違反しないか
• 同じ要求をすでに処理していないか

条件を満たさなければ拒否し、再試行回数を超えた場合は安全な行動へFallbackします。LLMの応答を直接ECSコンポーネントや所持品へ書き込ませません。

Structured Outputは意味の正しさを保証しない

OpenAIのStructured Outputsは、応答を指定したJSON Schemaへ準拠させ、必須キーの欠落や定義外の列挙値を防ぐための機能です。これは、パース失敗を減らし、形式上の契約を強くするために有効です。

一方、Schemaへ準拠したGiveItemが、現在のゲーム状態で実行可能とは限りません。次の3段階を分けます。

Function Callingも同様に、モデルが呼び出し候補と引数を提示する仕組みとして扱います。ゲーム側が実際の処理を所有し、引数と権限を再確認します。

2026年10月4日確認。形式制約そのものが有効になったかも検証します。9月29日公開のプレリリースllama.cpp b11246は、Muse Glimmerで--jinja使用時にresponse_format.json_schemaが無視される問題を修正しました。別製品のLlama-Unreal v1.4.0文書は、不正なGrammarをOnError code 12で通知した後も制約なしで生成を続けると説明しています。本記事の導入要件として、制約設定に失敗した応答を状態変更へ渡さずFallbackします。正常なJSONだけでなく不正な制約や再ロードも回帰確認し、GameStateと権限の検証を維持します。これは検証案であり、当方で実行した結果ではありません。

反射的な処理と認知的な処理を分ける

移動、照準、回避、衝突、アニメーション、ダメージ適用など、フレームや固定tickへ追従する処理はLLMの応答を待てません。これらはState Machine、Behavior Tree、GOAP、Utility AI、ECSなど、予測可能なゲーム側の仕組みで処理します。

LLMの対象は、遅れてもシミュレーションを止めない高レベルの判断に限定します。

• プレイヤーの発言意図を解釈する
• 会話文を生成する
• 複数の許可済みGoalから候補を選ぶ
• 重要な出来事をMemory候補として要約する
• 状況に応じて追加のObservationを要求する

呼び出しは毎フレームではなく、会話開始、Goal完了、重要イベント、関係値の変化などを契機にします。応答待ちの間も従来型AIを動かし、Timeout、キャンセル、古くなった応答の破棄、Fallbackを設計します。

2026年10月6日確認。NobodyWho Godot v12.0.0は10月5日18:21 UTC（10月6日03:21 JST）公開のSDKです。版固定ChangelogはGodot APIの全面再実装、Main thread上のTool呼び出し、非同期Tool対応を記載します。ただし、Tool文書ではToolにTimeoutがなく、stop_generation()でも実行中Toolは中断されません。Toolが戻らなければ、そのChatと応答Streamは完了しません。

このSDKを評価する場合は、生成停止とゲーム操作のキャンセルを分けます。本記事の設計案として、Tool自身に完了までの期限とキャンセル処理を持たせ、停止後の遅延完了でも状態変更の直前に、現在のGameState、対象の存在、期限、キャンセル状態、権限、重複処理を再確認します。一つのActorで、戻らないTool、停止後の完了、対象消滅、重複要求とFallbackを検証します。v12のManifestはGodot 4.6以降で、READMEの4.5表記とは区別します。SDKのEUPL-1.2と、使用するGGUFの配布条件も別々に確認します。Main thread対応は行動の正当性やフレーム時間を保証せず、当方ではSDKを実行していません。

Ámbar Reflexは文章を生成しない判断方式の小規模実験

2026年9月29日確認。Ámbar Reflex / Sistema 1は、Qwen3.5-4B Q8_0とRTX 3060を使い、ゲーム状態から移動、ジャンプ、しゃがみ、照準、射撃、危険の6項目を評価する公開実験です。SemIf由来のlogit読み取り方式を使い、確率をローカルAPIで返してゲーム側が操作へ変換します。商用NPC導入の実績ではありません。

比較用の生成AgentはOllama経由で動くため、モデルの規模が同じでも実行経路まで揃えた比較ではありません。少数試行と質問設計に依存する結果であり、一般的なNPC性能やモデル順位へ広げません。静的な判断精度とリアルタイムのゲーム成績は別の評価軸です。正しい判断でも、到着までに状態が変われば役に立たない場合があります。

NPCへ応用するなら、次の構成を検証候補にできます。これは本記事の設計案です。

Game Stateと許可済み候補
  → 判断モデル / Logit Scorer
  → 候補の評価
  → ゲーム側で現在の状態・権限・有効期限を再確認
  → BT / Utility AIなどが実行

文章生成を省いても、入力の読み込み、Queue待ち、GPU競合は残ります。確率だけで行動を許可せず、古い応答の破棄とFallbackを維持します。会話は別の生成モデルに分担できますが、複数モデルの常駐メモリも測定対象です。各判断方式と実行経路の違いはAgent Harness記事で整理しています。

判断APIは実行版を固定して比較する

2026年10月4日確認。Ollama v0.35.0はNimbleとTev1向けに/v1/systemoneを追加しました。llama.cpp本流では10月2日UTC公開のb11361がLaya、Julia-1、Lev、OpenJev、Kev向けに同APIを追加し、10月3日のb11364でNimble、b11371でClef／Clef Flashへ対応しました。これらのllama.cpp配布版はプレリリースです。モデルの新規発表や、ÁmbarがこのAPIを使用している証拠ではありません。

Clef対応PR #29831によるb11371時点のGGUF実行は、文章入力限定で、1 batchあたり単一sequenceでした。2026年10月6日の追加確認では、10月5日公開のプレリリースb11418に画像対応PR #29969が入りました。同日の非プレリリースv0.6.0にも含まれます。これは実行経路の画像対応であり、モデルの新規発表ではありません。

b11418のAPI文書では、対応Projectorを--mmprojでロードし、画像をdata URLで渡します。Streaming非対応、自由文生成なし、確率の用途別の較正を保証しないという境界は残ります。Clefは複数の質問をまとめて評価し、ClefとLayaは入力全体を--ubatch-sizeへ収める必要があります。同版のClef実装も単一sequenceを前提とします。10月3日のプレリリースb11379が、n_batchをn_ubatchへ制限してLayaのServer abortを修正した記録も維持します。

対応版llama-serverだけでなく、更新Templateを含むGGUFと対応Projectorを揃えます。PRのレビューは旧GGUFの再変換が必要と指摘し、Clef Flashの配布差分でも本体更新とProjector追加を確認できます。配布一覧のQ4_K_M本体6.49GBとQ8_0 Projector 624MBは別ファイルの容量で、必要総RAM／VRAMではありません。モデルカードのApache-2.0表記とランタイムのMITを分け、製品同梱前にモデルのLICENSE原文と配布条件を確認します。

まず文章だけの一種類の許可済みIntentから、日本語、該当なし、古いGameState、Timeout、Fallbackを比較します。画像を加える場合は、同じ画像と文章で比較し、画像とGameStateの不一致、古い画像、入力超過、Projector未ロード時も拒否とFallbackを確認します。これは検証案であり、当方の実測ではありません。実行対応は再配布許可を意味せず、この本流版の個別機能のLM Studioへの取り込み、速度、総メモリ、ゲーム同居性能は未検証です。確信度の高い選択でも、ゲーム側のAuthorityを維持します。

2026年10月11日確認。v0.40.0の経路へ入ったOllama PR #18776は、Clef MLXで画像展開tokensを含めた入力超過をHTTP 400で拒否し、質問の部分的な準備結果を残しません。Layaはstate、質問、選択肢、予約tokensを含めて数え、超過時に切り詰めず拒否します。この個別実装を全Backendの保証へ一般化せず、上限直前／超過、画像展開、後続質問だけの不正を回帰確認します。ゲーム側でも重要な状態の欠落を拒否し、Fallbackします。公開テストは当方では未実行です。

2026年10月11日確認。正常な応答形式だけでなく数値も比較します。10月7日公開のプレリリースllama.cpp b11475は、PR #30100のMetal行列積・加算の結合処理修正を含みます。作者のM1 Max／Clef Flash Q8_0の特定質問では確率が0.284→0.977となり、CPUと対応しました。10月7日23:22 UTC（10月8日08:22 JST）公開の非プレリリースOllama v0.40.1は、PR #18777の64bit seekによって、Windowsで2GiBを超える位置のWeight読み取りとnon-finite logitの問題へ対応しました。作者の確認はWindows 11のCPU経路で、GPU Backendと別のcannot open modelエラーは未確認です。当方の再現や日本語の較正測定ではありません。同じ配布物・質問・候補・ContextでCPUと対象Backendの選択、確率、非有限値、エラーを比較します。両修正の相互取り込み、LM Studio／ゲームSDKへの取り込みは未確認で、ゲーム状態の検証も維持します。

2026年10月13日JST確認。10月12日19:00:12 UTC（10月13日04:00:12 JST）公開のプレリリースOllama v0.40.4-rc0は、PR #18917でGGUF判断要求をllama.cppの/v1/systemoneへ直接渡し、モデル別prompt構築も同経路へ移しました。旧形式の検査は必要な判断metadataのない旧GGUFと旧qwen35形式のClefを拒否し、共通検査はscoreを2〜10段階へ揃えます。更新モデル一式は別途提供予定とされ、全配布物の提供は未確認です。再取得すれば必ず直るとはせず、実行版とモデルdigestを固定し、互換形式の提供、拒否、Fallbackを確認します。

Decision 2.0／3.0を小型の判断経路へ加える

2026年10月13日JST確認。Decision-2.0-Kai-0.6Bは文章／JSONから候補選択・Yes/No・評点を返す0.60B・8,192 Contextのモデルで、公式GGUFのQ4_K_Mは401MBです。Decision 3.0のd3-edgeはVision Encoder込み総0.59Bで、BF16本体は1.19GBです。いずれもファイル容量は総RAM／VRAMではなく、初回モデル公開日時は未確定です。カードのApache-2.0表記とRuntimeの条件を分け、d3の個別LICENSEは今回原文を取得できていないため、同梱前に確認します。

Runtime対応は10月12日JST公開のプレリリースllama.cpp b11571（Decision 2）／b11572（d3）で、d3の複数sequence修正は10月13日07:55 JST公開のプレリリースb11577です。b11577 API文書ではd3のprompt全体を1 ubatchへ収め、画像には対応Projectorを揃えます。Decision 2は質問の選択肢とprompt末尾を1 batchへ収める制約があります。d3カードの動画対応をこのRuntimeの動画対応へ一般化しません。短い日本語の許可済みIntentで、選択肢順、古いGameState、入力超過、Projector欠落、複数sequence、Timeout後の結果破棄を比較し、状態・権限・期限の検証を維持します。モデル・Runtimeは未実行で、精度、較正、総メモリ、遅延、ゲーム同居性能は未測定です。

LM Studioのローカル判断Endpointも比較する

2026年10月11日確認。LM Studio 0.4.26 Build 4の10月8日付けノートは、Jev互換/v1/systemoneとOpenAI互換/v1/decisionsを追加し、通常配布ページも0.4.26を案内しています。ローカルServerの比較経路が増えた変更であり、OpenAIのクラウドモデルのWeight公開や同等の品質・速度を意味しません。一般要件はApple Silicon／macOS 14以降、Windows x64（AVX2）／ARM、Linux x64／ARM64とUbuntu 20.04以降です。アプリ・Engine・判断モデルを揃えますが、正確な対応組み合わせ、画像／音声、拒否、Streaming、並列処理は未確認です。Build 2のEngine 2.50.0／upstream b11337をBuild 4の構成へそのまま当てはめません。

一種類の許可済みIntentで、アプリ・Engine・モデル・入力を固定し、拒否、入力超過、Timeout、古い結果の破棄を比較します。バイナリは未実行で、日本語精度、総RAM／VRAM、p95／p99、描画同居性能は未測定です。上記のllama.cpp版固定記録は維持し、Endpointの提供だけで最新の本流修正・機能すべての取り込みを推定しません。アプリ利用条件とモデルの配布条件を分け、APIを使う試作をゲームへの同梱再配布許可とは扱いません。

d1-3Bを小型の画像付き判断モデルとして評価する

2026年10月11日確認。Liquid AIの10月7日公式発表はd1-3Bとd1-omni-600MのWeight公開を説明します。d1-3Bカードは総3.12B、文章・画像、32,768 Contextで、会話生成ではなく候補選択・Yes/No・評点を返すモデルです。公式GGUFのQ4_K_M本体1.67GB、Q8_0本体2.87GB、別の画像用Q8_0 Projector 583MBはファイル容量で、必要総RAM／VRAMではありません。

3B対応のプレリリースllama.cpp b11483は10月8日02:45 UTC（11:45 JST）、omni対応のb11488は同日04:16 UTC（13:16 JST）公開です。モデルの公開日と分けます。GGUF利用例に沿って、対応llama-server・指定GGUF・画像用Projectorを揃え、/v1/systemoneを使います。カードの公称8msはRTX 4090、BF16、Warm、CUDA graph使用、20回中央値の開発元測定で、GGUF、p95／p99、ゲーム同居性能へ転用しません。

b11488 API文書はStreaming非対応で、d1の質問を独立処理します。Python経路の複数質問一括処理の速度を引き継ぎません。入力全体を--ubatch-sizeへ収める制約はomniに適用され、omniは入力を16,384 tokensへ切り詰めます。他Runtimeの超過時明示エラーを一般化せず、重要な状態が落ちる前にゲーム側で入力上限を検査します。d1-omni-600Mは587Mの実験的Checkpointで、文章＋画像または文章＋音声を扱い、両方の媒体を同じ要求に混ぜません。画像時の状態・質問文章は896 tokens、音声は30秒へ切られ、音声学習は英語です。omniの全配布物容量と個別LICENSE原文は今回確認できておらず、日本語音声への採用は保留します。

両カードはLFM Open License v1.0を記載します。3B配布LICENSEと公式全文の年間売上に基づく商用条件、通知・帰属・再配布条件をRuntimeのMITとは別に確認します。短い日本語と英語対照、該当なし、候補順序、古いGameState、画像との矛盾、入力超過、Timeout後の遅延結果で比較する候補です。日本語精度、量子化後の較正、Cold／Warm応答、総メモリ、p95／p99、フレーム時間は未測定で、両モデルとも採用判断は保留です。

ブラウザ内のwllamaも判断経路として比較する

2026年10月7日確認。wllama 3.8.1は10月2日14:20 UTC（23:20 JST）公開の非プレリリースで、別のローカルServerを立てずにブラウザ内で判断モデルを実行する経路を加えました。版固定APIのcreateSystemOneはStateと型付き質問から結果を返します。画像入力は未対応で、引数の定義にStreamingやAbortSignalはありません。会話APIの機能や、後続llama.cppのClef画像対応をこの経路へ引き継いだとは扱いません。

同版READMEはWasm SIMDのCPU経路、WebGPU、Worker内推論を案内します。マルチスレッドにはCOOP／COEPが必要で、単一ファイル2GBの制限に対し512MB以下への分割が推奨されています。判断サンプルではKev-4BとLevにWebGPU必須の注意があります。サンプルに含まれるLayaの元モデルは英語版で、多言語版の能力や日本語品質をそのまま当てはめません。SDKのMITと、使用モデルの再配布条件も個別に確認します。

Web向けの設計案として、一種類のIntentから始め、英語対照と日本語、初回のJS／Wasm／GGUF取得、Cache再利用、取得中断・Cache削除・Offline再起動を分けて確認します。Timeout時はゲーム側でFallbackし、後から返る古い結果を破棄します。ブラウザ内で動くことだけでは、取得後のOffline動作、処理中断、描画とのCPU／GPU共存を保証しません。日本語精度、総メモリ、p95／p99、フレーム時間は当方では未測定です。

WebLLMの生成再開とゲーム状態の復元を分ける

2026年10月12日JST確認。10月11日UTC公開のWebLLM v0.2.86は、Gemma 4 E2Bのtext／audio入力と、会話のinterrupt、stream cancel、model lockの修正を含みます。再開機能の実装はPR #859で9月13日にmainへマージされ、10月11日公開のv0.2.86へ収録されました。前の公開版v0.2.85は9月8日公開で、この実装の統合前です。mainへの統合日と公開版での提供開始を分け、再開機能はv0.2.86の新規リリース項目として扱います。

版固定のモデル一覧は、GGUFではなくMLC Weight・Manifest・コンパイル済みWebGPUライブラリの組み合わせです。q4f16_1はshader-f16を要求し、別のq4f32_1は要求しません。両方の一覧設定はContext 4,096です。リリースのBuild設定は音声16kHz・最大480,000 samplesで、30秒相当です。q4f32_1の設定も一致し、リリースが参照するCompilerのLoaderはVision Weightを除外します。元のGemmaのmodalityから画像対応を引き継ぎません。npm metadataではPackage版とApache-2.0表記を確認できましたが、モデル個別LICENSEとWeight総容量は取得できていません。実行対応から再配布許可や必要総RAM／VRAMを導きません。

v0.2.86の再開契約はopt-in、text-only、single choiceです。画像、grammar／JSON／structural tag制約、custom LogitProcessorは拒否され、上記audio対応も音声要求の再開対応を意味しません。同一originのOPFSへprompt、tokens、text patches、RNG stateを保存し、互換KV checkpointの復元、またはpromptの再prefillと保存tokensのreplayで再開します。model／tokenizer／weights／configのfingerprintは未実装で、同じmodel IDだけでは配布物の一致を保証できません。

WebLLMはこのjournalを暗号化せず、TTLによる自動削除もありません。session削除と、稼働中Runtimeのprefix cacheは別です。ブラウザの保存領域削除でデータを失う場合があり、relaxed durabilityでは未flush末尾が失われ、best-effort persistenceでは生成を継続しながら保存が止まる場合があります。開始済みstreamは明示的に閉じ、iteratorを放置しただけでlockが解放されるとは想定しません。

NPCでの検証案では配布物を固定し、一つのActorでinterrupt、tab crash、明示cancel、保存失敗、削除を別々に試します。復元したモデルの文章はGameStateの正本でも、行動を再実行する許可でもありません。Actor／要求の対応、現在状態、権限、期限、実行済みかを再確認し、古い提案は破棄またはゲーム側でFallbackします。これは設計上の接続境界であり、WebLLMを採用したゲームの実証ではありません。日本語、復旧Latency、総メモリ、描画競合は当方では未測定です。

OpenAI Decisions APIはクラウド側の比較経路にする

2026年10月7日確認。OpenAIは10月6日のChangelogでDecisions APIのBeta提供を発表しました。公式ガイドではPublic Betaで、対応モデルはgpt-6-lunaです。POST /v1/decisionsへ文章や画像と質問を渡し、文章生成ではなく型付きの判断を受け取ります。クラウドAPIとして比較し、ローカル実行やOpen Weightの配布とは区別します。

API仕様の判断には、真である確率を返すpredicate、提示した候補から選ぶchoice、順序付きの評価基準を採点するscoreがあります。scoreは0始まりの評価段階を確率で重み付けした平均で、小数にもなります。任意の数値やGameStateの事実を生成する契約ではありません。画像はInline Base64のdata URLを使い、外部画像URL、File ID、音声、Tool／Function CallはこのEndpointでは非対応です。質問ごとにrefusalが返り得るため、数値や選択が必ず得られる前提にしません。

公式ガイドはResponses APIより約10倍速いと説明しますが、測定条件や絶対時間、p95／p99は示していません。OpenAIの比較主張として扱い、通信・Queue待ち・検証を含むNPCの完了時間へ置き換えません。確認時点の基本料金は入力100万トークン当たりUS$0.10で、Cache読み書きと出力トークンの料金はありません。料金条件とモデル説明では、272Kを超える入力は要求全体の入力単価が2倍になり、対応するRegional Processingは10%加算です。通常のResponses API料金を流用せず、採用時に最新条件を再確認します。

NPCへの適用は本記事の設計案です。例えば、許可済みGoalをchoiceで選び、候補を評価する用途に限定し、会話生成や行動実行は別の処理へ分けます。必要なContextだけを送信し、APIのデータ保持条件を製品要件に含めます。クラウドへ送る文章・画像、認証、費用上限、通信不能時の扱いもローカル経路との比較項目です。拒否・Timeout・通信障害では規則ベースのFallbackへ戻し、応答が来た時点でもGameState、権限、有効期限を再確認します。同じ候補と入力で判断品質、p95／p99、1イベント当たりの費用を比較する案であり、当方はAPIによるNPC性能を測定していません。

PUBG Allyから確認できる範囲

KRAFTONのPUBG Allyは、ローカル推論と従来型ゲームAIの分離を確認できる有力な事例です。NVIDIAの2026年6月の記事では、次の構成が説明されています。

• 音声認識、2Bの小型言語モデル、音声合成をオンデバイスで実行する
• プレイヤーの発話またはゲームイベントから推論を開始する
• 移動、照準、即時戦闘などはBehavior Treeが処理する
• 言語モデルはプレイヤー意図の解釈、協調、発話を担当する
• 現在のゲーム状態はObservation Toolから取得する
• 一つのマップ、一つのモード、固定されたアイテム分類へ対象を絞る
• 大きなTeacher Modelから専用データを作り、2Bモデルへ蒸留する
• クライアント向けに量子化し、NVIDIAは合計8 GBのVRAMを持つGPUでも動作可能と報告している

これは「既製の2BモデルならNPCに十分」という証拠ではありません。閉じたゲーム世界、専用データ、蒸留、量子化、Behavior Tree、Observation Tool、実プレイヤーを使った評価までを組み合わせた結果です。8 GBも、あらゆるゲームやモデルの一般的な推奨スペックではなく、この事例についてベンダーが報告した条件です。

2026年10月4日確認。開発元のPUBG Ally論文の付録Cは、行動を待たずに処理を返し、完了・失敗・中断を後続イベントで通知する構成を説明しています。低レベル制御はゲーム側に残ります。RTX 4060級での測定では、言語別の4bit言語モデルのWeightと稼働用KV cacheが約1.6〜2.1GB（Table 9）で、ゲーム全体のメモリではありません。実行結果の明示とメモリの区分を補強する開発元資料として扱い、多数NPCの同時処理の証拠へ広げません。当方による再現、日本語品質、他ゲームでの性能は未確認です。

Local Multimodal LLMは設計原則を実装へ落とした例

Volley StudiosのLocal Multimodal LLMは、2026年8月25日に公開された、Unreal Engine 5.8.1 / Win64向けのベータ版C++プラグインです。プレイヤーの音声またはテキストから、ローカルLLMによる応答と音声合成までをオフラインで処理します。GGUF推論にはllama.cppを使い、CPUとVulkanの実行環境を同梱し、CUDA 12のAcceleratorは別配布です。実行時にクラウドAPIやPython Runtimeを必要としません。

このプラグインが設計上の参考になるのは、会話デモだけでなく、この記事で整理した境界をBlueprint / C++ APIとして具体化しているためです。

Player Speech / Text
  → STT（音声入力時）
  → Shared Local LLM
      └─ NPCごとのCharacter Sheet / Context / Memory Session
  → Text Response / 型付き・Allow-list済みTool Call
  → Game CodeによるValidation
  → Game Systems
  → TTS（音声出力時）

一つのロード済みモデルを複数のCharacter Sessionで共有し、NPCごとのContext、会話Memory、KV stateを分離します。Tool Callは型と許可リストで制限し、モデルがUnrealの任意の関数やConsole Commandを直接実行する構成ではありません。ゲーム状態を変更する要求はゲームコードが検証してから実行します。これは、Shared Model → NPC別Context / Memory → Structured Tool Call → Validation → Game Systemという構成の実装例です。

Starter Model Packは、音声入出力を含めて約3.25 GiBです。公式資料に記載された内訳は次のとおりです。

Plugin Coreは別に約80.5 MiB、任意のCUDA 12 Acceleratorは約922.1 MiBです。プラグイン本体のコードと文書はApache License 2.0ですが、モデル、音声、Native RuntimeはそれぞれのライセンスとNoticeに従います。

ただし、約3.25 GiBは配布するモデルデータの容量であり、最低VRAM、推論中の最大メモリ、実ゲームと同時実行したfps、Time to First Tokenを示す値ではありません。公開資料には、描画を含むゲームとの同居性能を一般化できる実測値がありません。小型の音声対話一式を配布できる具体例としては有力ですが、製品採用前にCPU / Vulkan / CUDAを分けて、VRAM、CPU Main、GPU Frame、応答時間を測る必要があります。

現在のStarter構成にも境界があります。既定のGemma ManifestではVisionとモデルへのNative Audio入力が無効で、音声は独立したSTT / TTSとして処理します。画像入力は、対応するProjectorとManifestを開発者が用意する開発機能です。MTPによるSpeculative Decodingもランタイムへ未実装です。対応バイナリはWin64が中心で、他のOSやUnityへそのまま移植できる汎用解ではありません。

Unity向けにはBehaviorLLMの行動引数を比較する

2026年10月11日確認。Unity向けの非プレリリースBehaviorLLM v0.6.0は9月22日00:07 UTC（09:07 JST）公開で、名前付き行動引数、実行時の許可済み行動subset、引数検証を追加しました。PackageはUnity 6000.0以降、ローカルllama-serverと互換GGUFを前提とし、サンプルにはAI Navigation／Input Systemも必要です。既存のstring HandlerはActionArgumentsへの破壊的変更を確認します。これは統合候補で、現在のGameStateで行動が正しい証拠ではありません。一つのActorで不正引数、古い状態、Timeout、Fallbackを検証し、PackageのMITとモデル・素材の条件を分けます。製品Build、日本語、長時間安定性、総メモリ、描画同居性能は当方では未検証です。

Epoch Forge DemoはローカルLLMを公開Demoの要件へ含めた例

Epoch Forge Demoは、2026年8月31日にSteamで公開された無料Demoです。Steam上の開発元説明では、NPCのチャット応答をゲームと同時に動くローカルLLMで生成し、固定の台詞も併用します。応答には人格、過去のPlayerとのやり取り、職業、現在地などを使い、誰が出来事を見たか、情報が他のNPCへ伝わることも製品仕様として説明されています。

同じSteam公式ページは、Godot Engineで制作され、GemmaをGemma Termsの下で、llama.cppをMIT Licenseの下で含むと明記しています。これにより、ダウンロード可能なDemoがローカルLLMによるNPC会話を製品要件とし、Gemmaとllama.cppを利用していることまでは一次資料で確認できます。一方、正確なCheckpoint名、量子化形式、ファイル容量、実行環境の同梱方法、内部の呼び出し順、Context管理、NPC間のQueue、GameStateのValidation方法は断定しません。

開発元が示す最低環境は8 GB RAMと2 GB VRAM、推奨環境は16 GB RAMと4 GB以上のVRAMです。対応GPUがない場合はCPUで会話を生成し、その間に一時的なフレームレート低下が起こると説明されています。これは、一般的なゲーミングPCを対象にローカルLLM込みのゲームを配布した具体例ですが、LLM単体の必要VRAMや安定したフレーム時間を測定した独立Benchmarkではありません。

また、完成版のEpoch Forgeでは、世界経済、Event、NPCの会話と行動、Storytellerの選択にもローカルLLMを使うと説明されています。ただし、完成版は未発売です。公開Demoについて確実に言える範囲は、ローカルLLMによるNPCチャットを固定台詞と併用し、Gemmaとllama.cppを利用していると公式に表示していることまでです。

公開資料だけでは、モデルのパラメータ数や容量、Time to First Token、生成速度、推論時の最大VRAM、複数NPCの同時要求、長期Memoryの整合性を評価できません。Epoch Forge Demoの価値は、それらを解決済みだと示したことではなく、ローカルLLMによるNPC会話を一般的なPC向けDemoの公開要件へ含めたことにあります。

AI Follower Jessicaは既存ゲームへローカル認知層を追加したMod

2026年9月6日確認。AI Follower Jessicaは、8月22日に公開され、9月3日にv0.1.12へ更新されたFallout 4の公開Modです。作者はローカル会話、音声、永続記憶、物体への自律的な働きかけを説明し、標準構成にQwen3-4B-Instruct-2507 Q6_K GGUFとVulkan版llama.cppを使います。従来のコンパニオン機能も残ります。認知層を追加する設計として参考になりますが、この記事が求める意味検証、権限確認、Timeout、Fallbackのすべてを実装済みと確認できたわけではありません。

作者の8GB VRAM向け資料は、Contextやテクスチャの縮小、一部レイヤーのRAMへの移動を案内します。これらは設定上の助言であり、本記事が安定したゲーム性能を実測したものではありません。差し替え用Qwen3.5／3.6には、遅延とthink blockの会話・音声・Actionへの混入を避けるため、非Thinkingモードを推奨しています。流暢さに加え、出力が後段の処理へ適合するかも評価します。

商用ゲームへの採用事例とは区別します。Mod資産の許諾は販売されるMod・ファイルへの利用を禁止しており、モデルのライセンスとは別に原文を確認します。既存の事例は各記述の情報日を維持し、今回すべてを再検証したものではありません。

Adaptive Neural Companionは推論準備の確認まで配布手順に含める

Adaptive Neural Companionの9月15日の開発者更新は、Windows向け3Dコンパニオンの配布手順を説明しています。Ollamaを準備し、未取得ならqwen2.5:7b-instructをダウンロードし、実際の推論テストでQWEN_READYを確認してから3D環境を起動します。不正・欠落したモデル応答を拒否し、推論不能時はQWEN_UNAVAILABLEと明示します。初回準備にはダウンロードが必要であり、ローカル推論と初回起動のオフライン完結は別です。

開発者はMemoryや会話をQwenの処理へ渡しつつ、Game Authority、Battle State、Slash Commandの決定的な制御をHost側へ残すと説明しています。配布・起動設計の参考ですが、当方による再現実験や実装監査ではありません。この更新資料から最低VRAM、フレーム時間、言語品質は確定できず、Weight容量からゲーミングGPUの推奨値を導きません。

定型文をモデル応答に見せかけないことと、Fallbackでゲームを継続することは分けます。本記事の設計では、推論不能を明示しながら従来型AIを継続し、ダウンロード中断、推論Timeout、復旧も検証します。これは導入時の設計要件であり、同製品がすべて実装済みという主張ではありません。

ScapegoatとCometforge NPCはEarly Accessまで進んだ例

2026年10月4日確認。Scapegoatは、2026年9月29日に無料のEarly Access版を公開したUnreal Engine製の推理ゲームです。Steam上の開発元説明では、シングルプレイに6人の容疑者NPCが登場し、人格、事件、証拠、物語は人間が設計したうえで、会話をLLMが実行時に生成します。既定では同梱したオンデバイスモデルを使い、プレイヤー自身のローカルモデルまたは任意のクラウドモデルへ切り替えられます。音声認識も端末内で処理します。

この構成は、LLMへ事件やゲームルールそのものを生成させるものではありません。人間が作った殺人事件、証拠、人格、秘密の範囲内で会話を即興生成し、決定的なゲーム構造と生成内容を分けています。公開されたEarly Accessビルドを評価できる段階ですが、当方ではインストールや動作確認を行っていません。SteamはマルチプレイではAIを使わないと明記しています。

開発元の最低要件はWindows 10／11 64-bit、RAM 8GB、DX12対応GPU・VRAM 4GB、空き5GBです。推奨VRAMは6GBで、オンデバイスNPCには6GB以上が適すると記載されています。推奨GPUの例はRTX 2060またはRX 5700です。ただし、これはSteam上の製品要件であり、LLM単体のVRAM測定、フレーム時間、Time to First Token、長時間プレイ時の安定性を公開したBenchmarkではありません。

Scapegoatの基盤として案内されているCometforge NPCは、Unreal Engine 5.7 / Win64向けのプラグインです。On-Deviceモードでは、Ministral 3 3B InstructのQ4_K_Mを約2GBのGGUFとして同梱し、組み込みのllama.cppとVulkanでゲーム内から推論します。任意のllama.cpp互換GGUFへ交換でき、BYOMモードではLM Studioやllama-serverなどのOpenAI互換Local Serverへ接続できます。

設計上の要点は、一つのモデルをCast全体で共有し、NPCごとにMemoryを分けることです。Cometforgeは、working、episodic、semantic、proceduralの4階層、重要度、時間経過による減衰、統合、ディスクへの永続化を説明しています。公開ドキュメントでは、Memoryの保存・取得・各Turnへの注入を決定的な処理として実装し、小型モデルが自律的にToolを選ぶ能力は保証しないと明記しています。

これは、Shared Local LLM → NPC別Context / Memory → Deterministic Game Logicという境界を具体化した例です。一方、公開資料からはScapegoatの現行ビルドがCometforge標準のMinistral 3 3B Q4_K_Mをそのまま使っているかまでは確認できません。CometforgeがScapegoatを実ゲーム例として紹介していることと、プラグインの標準On-Device構成がMinistral 3 3Bであることは確認できますが、両者を同一Checkpointだと断定しません。

gamescom 2026で具体化したHybrid構成

gamescom dev 2026でTencentは、FPS向けAgentとしてLLMと強化学習を組み合わせるDual-Brain構成を紹介しました。LLMは状況の意味理解、戦術、高レベルのPlayer命令を扱い、RLはリアルタイムの意思決定と操作を担当します。これは、この記事で整理しているCognitive Layerと反射的な実行系の分離に近い構成です。

またNVIDIAは、『Aniimo』が2027年初頭にNVIDIA ACEへ対応し、PlayerのGPU上でFine-tuning済みNemotron SLMを動かす予定だと発表しました。SLMは自然言語や音声から意図を解釈し、Game側のBehavior APIを呼び出します。

二つの事例は、次の境界を補強します。

ただし、TencentのFPS Agentは会場Demoであり、Aniimoは搭載予定です。製品版でのLatency、誤操作率、同時Actor数、GPU共有時の負荷を実証した事例としては扱いません。発表の成熟度と他のAI用途は、gamescom 2026で見えたゲームAIの現在地で分けて整理しています。

モデルサイズより先に評価項目を決める

小型モデルはVRAMや応答時間の面で有力ですが、パラメータ数だけでは採用を決められません。GoogleのFunctionGemmaは270MのFunction Calling特化モデルですが、定義済みAPIを持ち、用途固有の追加学習を行う利用者向けと説明されています。小さいことと、追加学習なしで日本語NPC会話へ使えることは別です。

LFM2.5-2.6Bは検証候補であり、採用の証拠ではない

Liquid AIのLFM2.5-2.6Bは、Tool Useと複数段階の作業を対象とし、公式のQAD Q4_0が約1.59GBであるため、Local Model Providerの具体的な小型候補になります。IntentまたはTool Callを提案し、Validatorを通してからBTやGOAPへ渡す、この記事の境界とも一致します。

ただし、QADは4bit量子化による品質低下を抑える方法、DSparkは補助モデルを使って生成を速める方法です。どちらも、提案したIntentが現在のGameStateで正しいことや、NPCの日本語、人格、長期Memoryの品質を保証しません。公式のDSpark速度はM4 Max上のFP16 GGUFを使った条件であり、QAD Q4_0、Windows、ゲーム描画との同居性能を示すものでもありません。

LM Studio 0.4.22は、llama.cpp engine 2.29.1以降でDSpark、DFlash、MTPのAssistant Drafterへ対応しました。これにより、LM StudioのGUIまたはLocal ServerからLFM2.5-2.6BとDSparkを組み合わせた試作を行いやすくなりました。ただし、LM Studioをゲームへ同梱するという意味ではなく、公開された2.27倍という平均速度もM4 Max上の別条件です。補助モデルの採用率やハードウェアによっては遅くなる可能性があります。

検証するときは、QAD Q4_0のIntent成功率を通常のQ4_0と比較します。Q4_K_Mとの実用上の品質・速度比較は別の実験に分け、DSparkの有無でp95・p99応答時間を比較します。Weight容量だけで同居可能と判断せず、ゲーム実行中のVRAM、CPU Main、GPU Frame、Queue待ちも測ります。LFM Open License v1.0には年間売上に応じた商用利用条件があるため、製品化時は公式ライセンス説明も確認します。

K2 Horizonを追加の検証候補にする

2026年9月6日確認のK2 Horizon 3.7Bと7Bも比較候補です。Agent BenchmarkからNPC適性を直接判断せず、日本語、人格の維持、Intentの正確さ、Reasoning量、応答完了時間、ゲーム同居時の負荷を既存候補と比較します。モデルとランタイムの詳細はローカルLLM記事で扱います。

Spark-X2.5と省メモリ方式もNPC用に別途評価する

Spark-X2.5 4B / 1.7Bも2026年9月18日時点の小型Agent比較候補です。開発元評価はThinking有効時であり、Tool Callingのスコアだけでは日本語会話、人格維持、Intentの正確さ、低遅延を判断できません。同じゲーム状態、Schema、Context、出力予算で既存候補と比較し、Reasoning設定と応答完了時間を記録します。

Bonsai 2の低ビットWeightとEdge0のSSD Expert StreamingはローカルLLM記事で整理しています。Weight容量やactive memoryが減っても、描画との同居可能性は確定しません。NPC同時要求のQueue待ちとフレーム時間への影響を測り、Streamingではストレージ競合とCold／Warm時のキャッシュ状態も含めます。ゲームへの採用実績ではなく、検証する方向性として扱います。

共通の評価項目

候補を比較するときは、同じシナリオ、同じSchema、同じゲーム状態を使い、少なくとも次を記録します。

クラウドAPIにはネットワーク遅延、利用料金、接続障害、送信データの扱いがあります。ローカル推論にはVRAM競合、モデル配布、初回ロード、ハードウェア差、更新方法があります。比較対象はChatGPTというアプリではなく、OpenAI APIのモデルなどのクラウドAPIと、ゲームへ同梱またはローカルプロセスで動かすモデルです。

Shared ModelでもNPCごとのコストは残る

NPCごとにモデル本体をロードする必要はありません。一つのモデルを共有し、要求をQueueへ積む構成にできます。ただし、共有によって次のコストが消えるわけではありません。

• NPCまたはActorごとのContext構築
• 会話履歴やMemoryの読み込み
• KV cacheの保持または再計算
• Queue待ち
• 入力トークンと出力トークンの推論時間
• 応答が古くなった場合の破棄と再要求

「1モデルを共有できる」ことと「多数NPCを同時に低コストで考えさせられる」ことは分けて評価します。最大同時要求数、優先度、キャンセル条件、Actorごとの頻度上限を決め、Queue待ちも応答時間へ含めます。

2026年10月6日確認。KV／Sessionをファイルへ保存して再利用する構成では、実行版を変える際の復元互換性も検証します。10月5日にマージされたllama.cpp PR #28498は、同日公開のプレリリースb11411と非プレリリースv0.6.0に含まれます。KV cacheの回転設定を保存し、不一致時に復元を拒否する変更で、作者は旧保存cacheとの非互換を説明しています。保存形式もSession 10→11、Sequence 3→4へ変わりました。

この保存方式を使う場合に限り、対象GGUF、KV型、回転設定、実行版を固定し、旧cacheや設定不一致の復元が拒否されたとき、正本の会話履歴から再構築して継続できるかを確認します。旧cacheを唯一の永続データにしません。自然言語の長期Memoryやゲームのセーブデータ全般とは別の互換性です。既存SDKへの取り込み、復元時間、ゲーム同居性能は当方では未確認です。

保存slotの復元後もcheckpoint再利用と障害回復を確認する

2026年10月11日確認。10月8日に統合されたllama.cpp PR #26004を追記します。SWA／Hybridモデルでslot保存・復元後にContext checkpointが失われ、共通prefixまで全量再処理される問題へ対応しました。10月8日15:27 UTC（10月9日00:27 JST）公開のプレリリースb11507で実行用配布物を確認し、b11506はTag／ソース確認にとどめます。版固定実装はcheckpoint payloadの追加、破損領域のサイズ検査、checkpoint復元失敗時の全量再処理、Draft KV型不一致時のDraft cache破棄、不完全な保存のエラー通知を扱います。上記の保存形式変更をまたぐ互換保証にはしません。

対応Server、checkpointを使うモデル、slot保存設定とdisk容量を揃える場合に限り、保存→別会話→再起動→復元→共通prefixからの分岐、破損ファイル、Draft KV型変更を比較します。再処理tokens、復元時間、応答、Fallbackを確認し、正本の会話履歴から再構築できる設計とGameState・権限確認を維持します。作者・利用者の時間短縮報告は当方の実測ではありません。永続Memoryの正確さ、日本語、総メモリ、ゲーム同居性能、SDK／Ollama／LM Studioへの取り込みは未検証です。

使用中slotのContextを保護する

2026年10月11日確認。10月10日19:52 UTC（10月11日04:52 JST）公開のプレリリースllama.cpp b11552はPR #30295を含みます。使用中のid_slotを指定した後続要求が待機前に別のRAM prompt cacheを読み込み、先行する生成のContextを置き換える問題を修正しました。修正後は使用中slotに触れず待機します。明示的slot指定とRAM prompt cacheを使う並行要求の問題であり、保存slotの復元とは区別します。

実行版と互換GGUFを固定し、Actor／要求ごとに異なる識別子を入れ、長い生成中に同じslotへ別要求を送って、応答の混線、Queue待ち、Timeout後の遅延結果破棄を確認します。正常な構造化出力だけでは、正しい要求のContextから生成されたことを保証しません。Actor対応、現在のGameState、権限、期限を再確認します。公開された回帰テストと利用者の限定試験は当方の実測や全モデルの保証へ読み替えず、日本語品質、p95／p99、総メモリ、ゲーム同居性能、Ollama／LM Studio／ゲームSDKへの取り込みは未検証です。RuntimeのMITとモデルの再配布条件も分けます。

NobodyWho v12.1では履歴と推論cacheの整合性を確認する

2026年10月11日確認。10月9日11:57 UTC（20:57 JST）公開の非プレリリースNobodyWho Godot v12.1.0にはSDK ZIPがあります。PR #796はKV cacheと内部記録の更新を一致させ、応答末尾や画像後の古い文章残留を修正し、M-RoPEのtokens数とpositions数を区別します。PR #803はRecurrent／Hybridモデルのユーザー発話末尾checkpointを再利用し、MTP棄却時のrollbackにも対応します。同一Chatのメモリ内管理であり、Actor間分離、disk保存slot、永続Memoryの正確さを保証する更新ではありません。

版固定ManifestはGodot 4.6以降、Windows x86_64／Linux／macOS／Android arm64を記載しています。互換GGUFに加え、画像にはProjector、MTPには対応モデル構成が必要です。ChangelogのAndroid OpenCL／Vulkan追加はGPU経路の拡大で、Web／Godot iOS対応の発表ではありません。同じモデル・Templateでv12.0／12.1の画像→文章、Thinking履歴、Tool結果→次Turn、MTP有無を比較し、cache位置、再処理tokens、応答の一致を確認します。SDKと回帰テストは未実行で、日本語品質、遅い要求の応答時間、総メモリ、発熱・消費電力、描画同居性能、実端末のAndroid Backend選択は未検証です。GameStateの検証を維持し、EUPL-1.2とモデルの条件を個別に確認します。

Entity数とCognitive Actor数を分ける

数千のEntityを描画・更新するゲームでも、数千体へ個別の人格と会話を持たせる必要があるとは限りません。LLMを使う単位を、シミュレーション上の個体とは別のCognitive Actorとして設計できます。

例えば、次の単位が候補になります。

• プレイヤーと直接会話する少数のNPC
• 部隊を代表する指揮官
• 陣営全体の方針を提案するActor
• 集合意識や群れの人格
• 物語上重要なイベントだけを解釈するNarrator

これは、どのゲームにも集合意識を採用すべきという結論ではありません。個体ごとの会話がゲーム価値にならない場合に、Entity数と推論Actor数を切り離す未検証の設計候補です。

Memoryは保存前と参照時の両方で検証する

自然言語のMemoryは、GameStateの代わりにしません。会話の継続性には役立ちますが、誤った要約、矛盾、古い情報、過剰な個人情報を長期間残す可能性があります。

Memoryには、本文だけでなく次の情報を持たせます。

• 元になったイベントまたは発話
• 対象Actor
• 記録日時と有効期限
• 重要度と参照範囲
• 確定事実か、NPCの信念・推測か
• 訂正元と訂正先
• 削除条件

LLMが生成したMemory候補をそのまま永続化せず、保存可能な種類、長さ、出典を検証します。参照時も、GameStateと矛盾する内容を事実として使わないようにします。

2026年10月6日確認。NobodyWho Godot v12のChat文書では、Context shiftingで残す冒頭・末尾Turnと削減先サイズを指定でき、context_shift: falseならContext満杯をエラーにできます。Changelogには、Tool直前に生成した文章が履歴へ残らなかった問題の修正もあります。これは入力履歴の管理であり、永続Memoryの正確さやGameStateの正本を保証しません。

検証時は、長い会話で残るTurn、Context超過時のエラーとFallback、Tool前後の文章・呼び出し・結果を含む履歴の保存と復元を確認します。省略された履歴を確定事実として補わず、復元後も現在のGameStateと照合します。日本語品質、総メモリ、遅延、多数NPCでの動作は当方では未測定です。

EmbeddingGemma 2はMemory検索を担う候補

2026年10月7日確認。Googleが10月6日に発表したEmbeddingGemma 2は、文章・画像・音声・動画をEmbeddingへ変換して検索するモデルです。NPCの発話生成や自律行動ではなく、参照するMemory候補の検索に使う設計を評価します。総740Mのうち文章だけなら270MのText Encoderを使い、不要なVision／Audio Encoderをロードしない構成を取れます。MoEのActive Parametersや、別の270M版Checkpointの配布を意味しません。

公式モデルカードは8,192トークンの共通Contextを案内します。配布設定の262,144という値を、そのまま利用保証へ読み替えません。公式Pythonガイドに従い、必要なEncoderと対応ライブラリを揃え、配布の依存条件にあるSentence Transformers 6.1.0以降とBF16またはFP32で評価します。FP16は非対応です。配布本体のmodel.safetensors 1.49GBはファイル容量で、Index、実行時領域、ゲームを含む必要総メモリではありません。モデルのApache 2.0原文と、実行ライブラリや製品の配布条件も確認します。

2026年10月13日JST確認。10月13日06:30:50 JST公開のプレリリースllama.cpp b11576は、PR #30416のno-cache Attention用K/V・maskの256単位paddingを含みます。EmbeddingGemma 2などhead size 512のCUDA経路で、入力長によってAttentionがCPUへ戻り、-fa autoも無効化される問題への対応です。新モデル発表ではありません。Ollama v0.40.4-rc0の同梱基準はb11521で、この修正の取り込み済みとは扱いません。版・モデル・入力長・Flash Attention設定を固定し、実際のBackend、Embeddingの一致、遅延、総メモリを比較します。当方のCUDA実測はありません。

本記事の検証案は、正解付きの小規模な日本語資料で文章・画像検索から始め、誤検索、該当なし、古い／削除済み記録、他Actorの非公開情報を確認することです。類似度の高さだけで事実や参照権限を認めず、検索前の参照範囲の制限と、検索後の出典・期限・GameState照合を維持します。Embeddingをローカル計算しても、Indexの保存・訂正・削除は別途実装が必要です。NPC採用の実例、日本語品質、総RAM／VRAM、遅延、ゲーム同居負荷は当方では未確認です。

現実案は一つのCognitive Actorから始める

最初から完全自律NPCや多数の同時会話を作るのではなく、一つのCognitive Actorと一種類のIntentに限定し、同じ要求契約を三つのProviderで比較します。

1. ScriptedまたはFake Providerで、ゲーム側の処理順、Validation、Timeout、Fallbackを検証する。
2. クラウドAPIで、対象シナリオにおける品質と要求・応答設計の比較基準を作る。
3. ローカルモデルで、同じ評価セットを実行し、品質、遅延、VRAM、ゲームフレームへの影響を測る。
4. 対象ハードウェアでゲームと同時に動かし、VRAM、CPU Main、GPU Frame、応答時間を測る。
5. 一つのCognitive Actorで成立してから、Actor数と同時要求数を一つずつ増やす。

最初の完了条件は、自由会話の豊かさではありません。許可したIntentを正しく提案し、不正な要求がValidationで拒否され、Timeout時も従来型AIへ戻り、ゲームのフレーム時間を許容範囲に保てることです。

この順序なら、ローカルモデルの性能不足と、ゲーム側の接続設計の不具合を分けて調べられます。クラウドAPIを本番採用するとは限らず、品質の比較基準としてだけ利用することもできます。

現時点の判断

9月18日の追加では、起動時の推論確認と推論不能の明示を具体化し、Spark-X2.5を比較候補へ加えました。開発元の説明やWeightの小ささだけで、Intentの正確さ、Queue待ち、ゲームのフレーム時間の検証を代替しません。

9月6日に追加したJessicaは、ローカル会話・記憶・行動を組み合わせる公開Modの事例です。実装資料を補強しますが、対象ゲームとハードウェアでの性能を確定するものではありません。

2026年9月3日時点では、LLMをゲームNPCの会話や高レベルの意図提案へ使う技術的な現実性はあります。LFM2.5-2.6BやMinistral 3 3Bのような小型モデル、Local Multimodal LLMやCometforge NPCのようなエンジン統合例に加え、Epoch Forge Demoでは、ローカルLLMによるNPC会話とGemma、llama.cppの利用を公式要件に含む公開Demoまで確認できました。10月4日の追加確認では、Scapegoatがオンデバイス会話を製品要件へ組み込んだEarly Access版を公開済みです。ただし、製品への採用可否はゲーム要件と対象ハードウェアでの実測なしには決められません。

安定しているのは、次の設計原則です。

• GameState Authorityをゲーム側に置く
• LLMをCognitive Layerへ限定する
• Structured Outputの後に意味検証と権限確認を置く
• Event Drivenで呼び出し、従来型AIを止めない
• TimeoutとFallbackを用意する
• Providerを差し替え可能にする

一方、最適なモデル、パラメータ数、ランタイム、同時Actor数、必要VRAMは時点とゲームごとに変わります。モデル一覧を固定的な推奨へせず、使用する時点でライセンス、対応環境、品質、性能を再評価します。

注意点

• この記事は公開資料から設計境界を整理したもので、ローカルモデルをゲームへ組み込んだ実測記事ではありません。
• PUBG Allyの構成と数値は、その製品と公開時点の条件に限られます。
• FunctionGemmaはFunction Calling特化モデルの例であり、NPC会話の品質を示す事例ではありません。
• Local Multimodal LLMはベータ版のUnreal Engine向け実装例であり、Unityを含む他のエンジンやプラットフォームで同じ結果を保証するものではありません。
• Epoch Forge Demoはダウンロード可能な公開Demoですが、公開資料から確認できるAI機能は主にNPCチャットです。完成版ページが説明する世界経済、Event、NPC行動、Storytellerへの利用を、Demoで実装済みとは扱っていません。
• Epoch Forge DemoのSteam公式ページはGemmaとllama.cppの利用を示しますが、正確なCheckpoint、量子化形式、ファイル容量、実行環境の配布構成は一次資料で確認できていません。Steamのシステム要件も、LLM単体またはゲーム同居時の推論性能を測定したBenchmarkではありません。
• Scapegoatは2026年10月4日時点でEarly Accessです。オンデバイス動作とシステム要件は開発元の公開情報であり、当方の動作検証や完成版の性能評価ではありません。
• Cometforge NPCの標準On-Deviceモデルと、Scapegoatの現行ビルドが使うCheckpointを同一とは断定していません。
• OpenAI APIのモデル、機能、価格、提供条件は変わるため、実装時は最新の公式資料を確認してください。
• Memoryへプレイヤーの発言や嗜好を保存する場合は、プライバシー、削除、利用目的、保存期間を製品要件として扱う必要があります。

関連資料

• 2026年時点の主要なローカルLLM
• How KRAFTON Built PUBG Ally
• KRAFTONによるPUBG Allyの発表
• FunctionGemma model overview
• LFM2.5-2.6B Model Card
• LFM2.5-2.6B公式GGUF
• LFM2.5 QAD Q4_0
• LFM2.5-DSpark
• LM Studio 0.4.22 release notes
• LM Studio Speculative Decoding
• LFM Open Licenseの説明
• Local Multimodal LLM GitHub repository
• Local Multimodal LLM Starter Models
• Local Multimodal LLMのEpic Developer Communityでの公開情報
• Epoch Forge Demo Steamページ
• Epoch Forge Steamページ
• Scapegoat Steamページ
• Cometforge NPC
• Cometforge NPC documentation
• Ministral 3 3B model overview
• OpenAI Structured Outputs
• OpenAI API model catalog
• TencentのFPS向けDual-Brain Agent
• NVIDIAのgamescom 2026発表
• gamescom 2026で見えたゲームAIの現在地
• AI Follower Jessica
• K2 Horizon 3.7B
• K2 Horizon 7B