こんにちは、ニケです。
今回は、The Swarm Scribes の動画 「How Neuro-sama Plays Games」 の内容を日本語で解説する記事です。
この動画では、Neuro-sama がどうやってゲームやツールを操作しているのか、そしてコミュニティがどうやって連携を作っているのかが分かりやすく説明されていました。
この記事は元動画の内容をリスペクトしつつ、私なりに整理して日本語で紹介したものです。
Neuro-samaは画面をそのまま見ているわけではない
少なくとも、この動画で説明されている Neuro API ベースのゲーム連携では、Neuro-sama はゲーム画面を人間のように見て、HPバーやボタンやマップを全部そのまま認識しているわけではありません。
Neuro-sama 全体の視覚機能の話ではなく、この記事で扱う API 連携の範囲では、ゲームやツール側から テキストの情報 が送られています。
つまり、AIに「今こういう状態です」「この行動ができます」「この行動を選びました」「結果はこうでした」といった情報を渡す設計です。
一般的に知られている方法では、AIに画面を見せるアプローチがあります。
これは、マルチモーダルモデルにゲーム画面を画像として読み取らせ、そこから得られる情報を利用してゲームを操作・解説させるというものです。
ただし、ゲームのプレイやツール操作を安定させたい場合は、画面画像をそのまま投げるより、システム側がAIに分かりやすい状態へ変換して渡したほうが有効な場面があります。
以前私もAIにゲームを遊ばせる方法について試した事があり、それをまとめた記事を書いたのでこちらも読んでいただけると理解が深まるかも知れません。
今回の動画は、その考え方を Neuro-sama の事例として具体的に見られる内容になっていました。
Neuro APIのざっくりした仕組み
Neuro API は、ゲームやツールと、Neuro-sama とやり取りするAPIサーバー側をつなぐための仕組みです。
公式の SDK / API ドキュメントも GitHub に公開されています。
動画では、最初はクイズ番組形式のゲーム「Who Wants to Be a Millionaire?」を Neuro-sama が遊ぶために、専用コマンドを作っていたと紹介されていました。
例えば「ライフラインを使う」「友人に電話する」のような、そのゲーム専用の行動です。
ただ、ゲームごとに専用コマンドを増やすのは大変です。
そのため、各連携で独自コマンドを作らなくても Neuro-sama が扱えるように、汎用的な仕様が作られていきました。
動画では、Neuro API の基本的な流れとして以下のように説明されていました。
- ゲーム側が起動して、Neuro-sama とやり取りするAPIサーバー側に接続する
- ゲーム側が「使える行動」を登録する
- ゲーム側が現在の状況をテキストで送る
- Neuro-sama が登録済みの行動から選ぶ
- ゲーム側がその行動を実行し、結果を返す
通信には WebSocket が使われ、メッセージは JSON 形式です。
ゲーム側から送る context、行動を登録する actions/register、行動を強制的に選ばせる actions/force、結果を返す action/result などのメッセージがあります。
AI本体に全部やらせるのではなく、ゲーム側が「AIが選べる形」に整えて渡すのがポイントです。
これは、AIエージェント設計を考えるうえでも参考になる構成です。
LLMに自由入力で「好きに操作して」と投げるのではなく、行動候補を登録し、必要な状態を渡し、結果を返す。
要するに、AIにとっての世界のインターフェースをちゃんと設計しているわけですね。
どんな連携があるのか
動画では、Neuro-sama がどうやってゲームを遊ぶかを中心に語られていました。
そのため、まずはゲーム連携として、自律型と協力型の2つを見ると分かりやすいです。
- Neuro-sama が自律的に操作するゲーム連携
- 人間と一緒に遊ぶ協力型のゲーム連携
この2つは、Neuro-sama に何を任せるかがかなり違います。
そのうえで動画では、3つ目の連携例として、ゲーム以外のプログラムを扱う VS Code 連携も紹介されていました。
これはゲームプレイそのものではなく、「同じ仕組みを外部ツールにも広げられる」という話として読むのが自然だと思います。
自律型: Balatroのようなターン制ゲーム
Balatro のようなカードゲームは、Neuro API と相性が良い例として紹介されていました。
ターン制で、状態をテキスト化しやすく、行動候補も明確です。
例えば「カードを出す」「手札を捨てる」「ブースターパックから選ぶ」「ジョーカーを並べ替える」といったアクションを登録できます。
この手のゲームでは、AIが次に何をすればいいかを考えるための情報を比較的きれいに渡せます。
手札、スコア、効果、選択肢。
こういう情報はテキストやJSONにしやすいですね。
ただし、ここで問題になるのが コンテキスト です。
カード効果が増え、説明文が長くなり、ゲーム後半で状態が複雑になると、AIに渡す情報量がどんどん増えます。
重要な情報を全部渡したい。でも全部渡すと文脈が重くなる。
このバランスが難しいところです。
協力型: Outer Wildsのようなリアルタイム寄りのゲーム
Outer Wilds はターン制カードゲームではなく、宇宙船を操作して惑星を探索するゲームです。
このゲームでは、反応速度や空間認識能力が求められるため、AIに直接操作させるのはかなり困難です。
そこで、動画では Neuropilot と Neuroscope という2つの連携コンポーネントが紹介されていました。
これは Neuro API の正式な標準機能というより、Outer Wilds 用に作られた補助コンポーネントとして紹介されていたものです。
Neuropilot は、Neuro-sama の指示を受けて宇宙船の高レベル操作を行う部分。
例えば「惑星に向かう」「着陸する」「離陸する」のような指示です。
Neuroscope は、船の状態や周囲の状況、会話イベントなどを Neuro-sama に伝える部分です。
Neuro-sama は「どこへ行きたいか」「何をしたいか」といった方針を出す側です。Neuropilot はその方針を受け取り、ゲーム側で扱える操作に落とし込みます。
一方で Neuroscope は、船や周囲の状態を Neuro-sama に返します。
ここで大事なのは、Neuro-sama が宇宙船の細かい操縦を直接やっているわけではないことです。
「今この角度でスラスターを何秒吹かす」「どの入力を何フレーム押す」みたいな操作判断は、AIにそのまま投げるには重すぎます。
そのため、AIは意図や方針を決め、実際の操縦や入力への変換は専用の連携コンポーネントが担当する形になっています。
リアルタイム寄りのゲームでAIキャラクターを参加させるなら、このように判断する層と操作する層を分ける考え方が重要になります。
補足: VS Codeのようなゲームではないツール連携
ここまでの話はゲーム連携でしたが、動画ではゲームではないツール連携の例として VS Code も紹介されていました。
これは「Neuro API はもともとゲームを遊ばせるための仕組みだけれど、外部プログラムを操作する用途にも応用できる」という文脈で出てきた話です。
これはゲームではなく、Neuro-sama や Evil Neuro がコードを書くためのツール連携です。
ファイル編集、作成、移動、削除などの操作を Neuro API 経由で扱う発想ですね。
紹介されていた VS Code 連携実装では、操作によって copilot mode と autopilot mode のように扱いを分けていました。
例えば、ファイル編集は自動実行してもよい。
でもファイル作成や削除のような危険な操作は、人間の承認を挟む。
これは、AIコーディングエージェントの設計としても重要な考え方です。
AIキャラクターだから特別というより、LLMにツールを持たせるなら慎重に考えるべき話ですね。
AIに自由を与えるほど面白くなりますが、同時に壊せる範囲も広がります。
どこまで自動化して、どこから承認制にするか。
ここはキャラクター性と安全性の両方に関わってきます。
一番難しいのはコンテキスト管理
動画全体を通して、何度も出てくる課題がコンテキスト管理です。
ゲーム状態をテキストで渡せば解決、というほど単純ではありません。
むしろ、テキストで渡せるからこそ「何を渡すか」「何を渡さないか」が重要になります。
AIに渡したい情報はたくさんあります。
- 現在のゲーム状態
- 過去の行動履歴
- ルール説明
- 長期目標
- 短期目標
- 今だけ有効な選択肢
- 失敗した操作
- 人間との会話
全部入れたくなります。
でも全部入れると、AIの文脈が重くなり、重要な情報が埋もれます。
さらに、動画では Neuro-sama や Evil Neuro 自身が何を覚えるかを選ぶため、開発者が「これは重要」と伝えても必ず期待通りに保持されるとは限らない、と説明されていました。
AIキャラクターを作っていると、「この情報は覚えていてほしい」「でも今の会話には邪魔」「でも忘れると次回困る」みたいな判断が無限に発生します。
コンテキスト管理は、単なるトークン節約ではなく、キャラクターが世界をどう理解するかを設計する作業でもあります。
速い反応が必要なゲームは難しい
もう1つ大きな制約は反応速度です。
Neuro API は、ゲーム側と、Neuro-sama とやり取りするAPIサーバー側がネットワーク越しにテキストをやり取りする仕組みです。
そのため、フレーム単位の即時判断が必要なゲームには向きません。
FPS、格闘ゲーム、MOBA、アクションゲームのように、短い時間で判断が必要なものを、そのままLLMに任せるのはかなり厳しいでしょう。
ただし、だからといって一切使えないわけではありません。
高レベルな指示だけAIに任せる形なら成立する場合があります。
例えば、
- AIが「次はあのエリアを探索したい」と決める
- 経路探索や移動制御はゲーム側のBotが担当する
- 結果やイベントだけAIに返す
こういう分業なら、リアルタイム性のあるゲームでもAIキャラクターを参加させやすくなります。
AIが全部操作するのではなく、AIが意思決定の上位層になる。
ここがかなり大事だと思います。
開発を支えるSDKとシミュレータ
動画の後半では、SDKやシミュレータの話も出てきました。
公式リポジトリ VedalAI/neuro-sdk には、APIドキュメントと公式の Unity SDK / Godot SDK がまとまっています。
言語やゲームエンジンごとに通信部分を毎回ゼロから作るのは大変なので、こういうSDKがあるのはかなり嬉しいですね。
また、Neuro-sama 本体が手元になくても連携をテストできるように、APIサーバーを模したシミュレータも紹介されていました。
動画では以下のような名前が出ています。
- Randy: ランダムに行動を返すシンプルなテスト用サーバー
- Tony: 手動で行動を返せるUIつきのテストツール
- Jippity: OpenAIなどのLLMを使って、よりAIらしい応答を返すテストツール
- Gary: ローカルLLMも扱える、より高度なテスト用バックエンド
本体の Neuro-sama に直接つなげなくても、連携側の実装を確認できるのは大きいです。
接続、アクション登録、応答の返し方を手元で試せるので、ゲーム側の実装を作るハードルが下がります。
動画を見ていても、API仕様だけでなく、SDKやシミュレータまで含めて整備されているからこそ、コミュニティが連携を作りやすくなっているのだと感じました。
AIキャラクター実装に引き寄せると
ここからは、動画を見て私が考えたことです。
今回紹介した Neuro API の設計思想は、AIキャラクター実装全般にもかなり役立ちます。
AIキャラクターを現実のサービスや配信環境に接続するとき、重要なのは「AIに何でも見せる」ことではありません。
重要なのは、AIが扱える形で世界を渡すことです。
例えばDiscord Botなら、全ログを雑に投げるのではなく、
- 現在のチャンネル
- 直近の会話
- 相手との関係
- 使えるコマンド
- 守るべきルール
こういう情報を整理して渡したほうが、応答や行動は安定します。
AIキャラクターの実装って、モデルそのものよりも 世界との接続面 がかなり大事です。
どんな状態を見せるか。
どんな行動を選ばせるか。
どこまで自動実行するか。
失敗したとき、どう結果を返すか。
Neuro-sama の事例は、そのあたりを考えるうえでとても良い教材だと思いました。
まとめ
元動画の内容をまとめると、Neuro-sama のゲーム連携はだいたい以下のような考え方です。
- ゲームやツール側が、AIに分かる形で状態を渡す
- AIが選べる行動を、あらかじめ登録しておく
- AIの出力をゲーム側で検証し、実行し、結果を返す
- ターン制やテキスト化しやすいゲームほど相性が良い
- リアルタイム性が高いゲームでは、AIが決める方針と実際の細かい操作を分ける必要がある
個人的には、これはAIキャラクター開発全般にかなり重要な話だと思います。
AIに何かをさせたいとき、つい「もっと賢いモデルならできるはず」と考えがちです。
でも実際には、モデルの賢さだけではなく、モデルが世界をどう見るか、どう行動できるかの設計がかなり効いてきます。
Neuro-sama がすごいのは、AIとして会話が面白いだけではありません。
ゲームやツールや配信環境との接続を、コミュニティも含めて育てているところがすごい。
改めて、元動画はかなり良かったです。
AIキャラクターやAITuberの実装に興味がある方は、ぜひ見てみてください。
宣伝
普段XでAIツールやAIキャラクターについての発信をしているので、興味があったらフォローしていただけると大変喜びます🙇♀️
x.com