ローカルPC環境で動作するオープンなLLMモデルへの注目が集まってきています。ファイルサイズの異なるさまざまなモデルが登場しているのですが、実際のところ、どれぐらいの性能差があるのでしょうか。日本語への対応能力の高い「Gemma 4」が現在のゲーム開発で、どの程度応用できるのかを、筆者の2本のアプリ開発を通じて探ってみました。【※記事配信先の設定によって図版や動画等が正しく表示されないことがあります。その場合はこちらからご覧ください】
AIチャットアプリをゲームに応用
この連載で公開したAIチャットアプリの「Rinon Voice Lab」の評判がよく、触っていただいた方の中には、改造して独自のアプリへ発展させる方もいました（参考：寝不足になるほど面白い ローカルAIと音声合成をつないだら、キャラが普通にしゃべり始めた）。
NKネクロシスさんは、元々は2人のキャラクターの掛け合いだったシステムを、4人のキャラクターが会議を進める仕組みに発展させました。
はじめまして、突然失礼いたします。
素晴らしいものを公開してくださって本当にありがとうございます…！
実はAI同士の4名による会議システムのバックエンドを作ったのですが、フロントエンドをどうするかで悩んでおりましたところ、こちらをお借りいたしました！
まだまだですが、形にできました pic.twitter.com/lR6kvAmhIJ
— NKネクロシス (@NKnecrosis) June 14, 2026
Teteさんは、AI PNGTuberの仕組みと組み合わせ、簡易アニメーションを再生し、口パクをしながらAIが対話をするアプリに発展させました。
@kiyoshi_shin
はじめまして！いつも楽しく見せてもらっています！
Rinon-Voice素晴らしいですね！自分も思わず弄りたくなって、LLM同士がMotionPNGTuberで口パク会話するアプリ作ってみました！ pic.twitter.com/howJX7flhh
— tete (@KimuraTete75045) June 15, 2026
AIキャラクターと音声を通じて話したい、様々なトピックを組み合わせて雑談したいと考えている方は多数いると感じました。また、複数人のキャラクターによる掛け合いという点が、目新しかったのかもしれません。
筆者がもともと「Rinon Voice Lab」でやりたかったのは、もっとゲーム的な展開を可能にすることでした。大まかなストーリーや世界観を生成しておき、二人のキャラクターの掛け合いが進行し、途中で物語の選択を通じてユーザーが介入できるという仕組みです。ゲームのセリフは毎回生成され、証拠集めをしながら進めていくアドベンチャーゲーム風の作品です。「Rinon Voice Lab」を、「Rinon Detective」として再設計していきました。今回は、Claude Codeを設計の中心役に据え、コーディング作業はCodexに接続してやらせるという体制で進めています。
△「Rinon Detective」のプレイデモ
グーグル「gemma 4」を使用
ゲームでは、登場キャラクターであるリノンとルヴィアは、AI捜査官という設定にしました。解決しなければならない事件を設定し、三幕のシナリオが展開され、最後の犯人逮捕までたどり着けるかという、ゲームとしての対立が明確に見える構成にしました。リノンは同情的で、ルヴィアは事件解決のための強行突破を目指しやすいという性格付けもしました。また、要所での決定が世界全体のパラメーターにも影響を与え、結末にも反映されるようにしました。
まずは、UIデザインを見直しました。CodexはUIデザインのセンスが高くないことは知られているとおりですが、これをClaude Codeを使って再デザインしました。UIデザインにはAnthropicによる「frontend-design」スキルが公開されており、それを取り込むだけで、利用しているAIエージェントが再設計したUIモックを作ってくれます。
状況説明役のサポートAI的な存在が必要だとも感じられたので、「ハチ」というサポートAIも登場させることにしました。
ところで、本格的に開発を進めるうえで、大きな懸念が出てきました。利用するLLMによってゲーム体験が変わる可能性がある点です。ベースの物語のアウトラインは、あらかじめOpusに作らせ、データを用意しておきますが、実際のゲームを進めるセリフは、LLMに任せる必要があるため、出力の品質が変わってしまうためです。
「Rinon Detective」では、日本語出力が美しく、処理速度も速いことから「Gemma ４」を使っていますが、Gemma ４には、31B、12B、E4B、E2B、26B A4Bの5種類の、サイズと使用目的が異なるバージョンが存在します。「B」はLLMが内部に持つパラメータ数を示しており、31Bは310億パラメータを意味します。「E」はEffective（実質的）という意味で、軽量に動かすことを目的としたモデルです。26B A4Bは、総パラメータは26Bですが、実質的にA4Bで動かせる軽量動作が可能なモデル、という意味です。もちろん、数値が大きいほど、ファイルサイズは基本的に大きくなり、求められるVRAM量も大きくなります。
31B、12B、E4B、E2Bを使って比較をしてみました。参考としてClaudeのOpus 5.8も追加しています。多くの方にゲームを遊んでもらうには、12B Q4_0（圧縮版）の6.7GBか、E4B Q4_0（4.5GB）がターゲットになるだろうと考えています。
ゲーム品質としては12Bモデルで十分
同じストーリー展開を提供し、それらがどの程度適切に出力されるのかを比較してみました。すべて自動で3回生成させました。プレイヤーの応答部分もAIに選択させて、ログデータを蓄積しました。そして、最終結果が揃ったところで、返答のない無音状態が起きていないか、会話でゲームを適切に進めることができているのかなどの観点から、Opusに評価させました。
やはり、品質的にはOpus 5.8のものが抜群によく、自然な文章でした。次点で31Bでした。ただ、結論としては、「Rinon Detective」に使うには、12Bがゲーム品質としては十分であるという結論に至りました。E4Bでは、そもそも、出力が出てこないことがあったり、キャラクターのセリフの人格を維持できなかったり、同じ内容を反復することがありました。進行不能を避けるための対策スクリプトを別途入れないと、ゲーム進行を成立させるのは難しい状態でした。さらに2Bになると、そのままではゲームを進行させるのが難しい、という結果になりました。
12Bは、6月5日にリリースされた比較的軽量でありながら、大きめのパラメーター数で動かすことを実現したモデルであるため、軽量モデルのE4Bを採用する意味はなくなってきています。そのため、今後の開発は12Bを基準として進めてよさそうだと考えています。
実は担当編集に見せたところ、すべての展開パターンを先に計算しておき、LLMがなくてもプレイできるパターンがあってもいいのではと提案してくれました。様々な分岐があり得るわけですが、それらもすべて事前に計算して作成しておき、音声ファイルだけIrodori-TTSでリアルタイムで作成することで計算時間を短くするアイデアです。これまでのアドベンチャーゲームに近い体験ですが、LLMなしにLLMを利用したかのような体験ができるというものです。
なるほどと思い、さっそく実装しました。会話部分は、最も品質の高いデータを出せるOpus 5.8で作成し、事前に選択式で読み込ませる形にしました。もちろん、スクリプトを用意すれば試せるので、他のLLMで作っても問題ありません。そうすることで、ゲーム体験がどの程度変わるのかを、より迅速に探ることができます。動画のデモ版はそれを採用しています。
「Rinon Detective」はまだ作りかけのゲームで、生成される会話を聞いているだけで、ゲームに没入できるのかを試している段階ですが、相変わらず、AIを使った開発は、技術検証まで含めて手早く進められると感じます。
小型モデルでテーマ討論ゲームも作ってみた
ところで、Googleが「26B A4B」を使って、10体のサブAIエージェントを動かして、分業によって、アプリケーションを高速に生成する動画を公開しました。このモデルはパラメータサイズのわりに、4B相当でしか動作しないのですが、小さなメモリ消費量で動作するというモデルです。
Teamwork makes the dream work. Now running locally.
Watch Gemma 4 26B orchestrate 10 parallel sub-agents to code an SVG art gallery in seconds. Hitting 100+ tokens/sec, imagine how you can scale this for complex tasks or local chatbots for entire teams!! pic.twitter.com/oIA9Rt2FwM
— Google Gemma (@googlegemma) June 17, 2026
この方法は、容易にまねできるため、26B A4Bを前提として、筆者も作ってみることにしました。作成したのはテーマ討論ゲーム「Gemma Concurrent Debate Wall」です。
ひとつの話題を提案すると、それに合わせて賛成・反対に分かれ、4体のエージェントが議論し、専門性を持った3つのジャッジが勝ち負けを判定して、それを10回繰り返して、合計点でその話題での勝ち負けを判定するというアプリです。話題が抽象論で退屈にならないように、リサーチャーという、話題に合わせて最新のトピックスを拾ってくるAIも設定しています。そのため、都合8体のエージェントが走って、議論を続けていくという仕組みにしています。
△「Gemma Concurrent Debate Wall」のデモ動画
動画では、「シンギュラリティに賛成か反対か」を問うていますが、序盤では賛成派が優勢だったのですが、後半に巻き返されて、負けてしまいました。最終総括では次のように書かれています。
FINAL SUMMARY / 最終総括 今回の討論の勝者は慎重派です。
慎重派が勝利した決定的な理由は、技術進化がもたらす「不可逆的なリスク」に対する論理的な防衛力の高さにあります。賛成派は、環境破壊などの現状の破滅を回避するために技術加速を「唯一の救済策」として提示しましたが、慎重派は存亡リスク（Existential risk）を根拠に、その加速こそが制御不能な破滅を招く最短経路であると反論しました。賛成派の主張が、技術によるパラダイムシフトという理想論に依存しすぎたのに対し、慎重派は社会の受容能力や人間性の喪失といった、技術が既存の社会基盤を破壊する具体的なプロセスを的確に突きました。
テーマに合わせて次々に生成される議論や、SF的なUIの変化はなかなか眺めていても楽しいものです。4Bサイズでは、ゲームシナリオのようなもので、設定を維持しながら展開するのは得意ではないようです。しかし、こうした高速な環境で議論させるような用途でも、十分な日本語品質を生み出せているように思えます。
筆者のNVIDIA RTX 4090を搭載したPCでは16.5GBのVRAM消費量でまだ余裕があり、さらにエージェントを増やしても余裕がありそうです。アプリでは、VRAMが少なめのPC用に、エージェント3体と5体のモードも用意しました。
こちらは、GitHubに公開していますので、試してみてください。
現在、ユーザーができるのは、最初のお題設定までです。今後、読み上げ機能や、ユーザーが介入して議論を変化させる仕組みを組み込んだりすれば、また新しいゲーム性を生み出せそうだと感じています。
ローカルAIの使われ方は緩やかに変わっていく
LLMが本格的に広がり始めてから、ゲーム中に登場するキャラクターに自動応答させるという可能性は常に議論されてきましたが、なかなか普及には至っていません。ローカルLLMがまだ小型のモデルだと使いにくいのと、制御を完全にすることが難しいという課題を抱えていたためです。
しかし、新しいモデルの登場によって、状況はだんだん変わってきています。もちろん、ローカルPCに搭載されるVRAM量がネックではありますが、ゲームでのローカルLLMの使われ方も、緩やかに変わっていくのではないでしょうか。
筆者紹介：新清士（しんきよし）
1970年生まれ。株式会社バリーン・スタジオ Creative Tech Lab./デジタルハリウッド大学大学院教授。慶應義塾大学商学部及び環境情報学部卒。ゲームジャーナリストとして活躍後、VRマルチプレイ剣戟アクションゲーム「ソード・オブ・ガルガンチュア」の開発を主導。2026年3月に発売したクラフト系サバイバルゲーム「Exelio」のAIによるキャラクターデザイン、3Dプロップの作成を担当。著書に『メタバースビジネス覇権戦争』（NHK出版新書）がある。