指示したはずのワールドと別プロジェクトが書き換わったRoblox Studio、Unity×LLMのNPC実装でも刺さる宛先明示の設計

AIエージェントに指示したはずの変更が、気づかないうちに別のゲームプロジェクトへ書き込まれる——複数エージェント時代のRoblox Studioでは、そんな事故がいつ起きてもおかしくなかった。自分は10年以上ゲーム開発と業務システムの両方に関わってきたエンジニアで、副業でも AI エージェントを何本か並列で走らせている。この「どのインスタンスに話しかけているか」という問題は、Roblox に限らず、ゲームエンジンやクリエイティブツールに AI を差し込む全ての現場で必ず起きる。

Roblox は8月20日、Roblox Studio に AI エージェントを接続する仕組み「Studio MCP Server」の大きなアップデートを発表した。核心は、複数のエージェントが同じ Studio を触る時の指定方法を作り直したこと。この変更は Roblox 固有の話に見えて、実は Unity や Godot のような他のゲーム開発環境に AI を常駐させる時にも避けて通れない問題を先に潰した設計判断だと、自分は読んだ。

Roblox Studioに複数のAIエージェントを同時接続すると、なぜ破綻していたのか
set_active_studioの廃止が示す、AIエージェント時代の接続設計の作り直し
1. studio_idという「毎回呼びかけ先を指定する」発想への転換
Unity×LLMでNPC会話を実装する時にも起きる「どのインスタンスに話しかけているか」問題
AIエージェントをゲーム開発環境に常駐させる設計思想は、受託の現場でも武器になる
まとめ
参考
【PR】おすすめの書籍
1. あわせて読みたい

Roblox Studioに複数のAIエージェントを同時接続すると、なぜ破綻していたのか

まず前提を整理する。MCP は Model Context Protocol の略で、AI ツールと外部アプリケーションを繋ぐ規格。Anthropic が提案して、Claude Code や Codex のような AI クライアントが対応している。Studio MCP Server は、この MCP に対応した AI エージェントを Roblox Studio に接続して、開いているセッションへ直接オブジェクトや設定を書き込めるようにする仕組みだ。

アップデート前の設計はこうだった。MCP クライアントは、set_active_studio というツール呼び出しによって、単一の Studio インスタンスに結び付けられる。1回接続を確立したら、その MCP セッションは「アクティブな Studio」を1つ持つ状態になる。エージェントが何かツールを呼ぶと、その「アクティブな Studio」に対して操作が飛ぶ。

これ、シングルエージェントで使う限りは全く問題ない。ただし、1本の MCP 接続を複数のエージェントで共有した瞬間に破綻する。エージェント A が「ワールド A を編集中」だと思って書き込みリクエストを飛ばしている裏側で、エージェント B が同じ接続経由で set_active_studio を叩いてターゲットを「ワールド B」に切り替えることが可能になる。順序の悪いタイミングで A のリクエストが着弾すると、A は自分が指定したつもりのないワールド B に対して変更を加えてしまう。

エージェント B からしても、A が何をやっているかは分からない。共有された1個の状態変数『active_studio』を、複数の呼び手が非同期に書き換え合うわけで、これはマルチスレッドプログラミングで昔から言われている「共有可変状態は事故の温床」の教科書通りのパターンだ。しかも AI エージェントは並列に、しかも予測しづらいタイミングでツールを呼んでくる。この設計だと、複数エージェントで同じ Studio を運用したい人が増えるほど事故率が跳ね上がる。

Roblox がこの問題を「複数エージェント運用時の信頼性」として明示的に取り上げたのが、今回のアップデートの発端になっている。

set_active_studioの廃止が示す、AIエージェント時代の接続設計の作り直し

今回のアップデートで set_active_studio は削除された。代わりに、全てのツール呼び出しに対して、操作対象の Studio を示す studio_id を毎回渡す設計へ切り替わった。セッションの状態に頼らず、呼び出しごとに操作先を明示する形だ。

これは実装レベルの話に見えて、実は AI エージェント設計における1つの重要な思想転換だと感じる。「グローバルなアクティブ状態」を持たせず、「呼び出し1回ごとに宛先を毎回明示する」設計へ寄せる。ちょうど、UNIX のパス指定に近い。cd で作業ディレクトリを切り替えるスタイルではなく、常にフルパスで指定するスタイル。書く量は増えるが、誰が呼んでも同じ結果になる。

さらに、list_roblox_studios が返す情報も広がった。従来は Studio 名と Studio インスタンス ID だけを返していたが、今回のアップデートで Place ID も返るようになった。同じ名前で複数の Studio を開いている時、名前だけだとどっちがどっちか判別できない。Place ID があれば、どのゲームのどのバージョンを触りに行くかを、エージェント側が正確に決められる。ローカルプレイスのように Place ID を持たないケースは名前のみだが、通常の運用ケースは網羅されている。

加えて、Assistant Settings の MCP Servers ページから、AI クライアントの接続状況を確認できるようになった。ツールチップにカーソルを合わせると、接続中のクライアントが一覧表示される。エージェントが反応しない時、まず「そもそも繋がっているのか」を目で見て確かめられる。デバッグの入口が整備された、と受け取っていいと思う。

このほか、有効な呼び出しに対して MCP Server が method not implemented を返す不具合や、MCP Server が自動で無効化される不具合も修正されている。細かい修正だが、複数エージェント運用の信頼性という文脈で見ると、どれも「エージェントが黙って失敗する」経路を塞ぐ変更だ。

studio_idという「毎回呼びかけ先を指定する」発想への転換

studio_id を毎回渡す方式は、書き手のコード量からするとちょっと冗長に見える。set_active_studio で一度セットしておいて、あとは同じターゲットに何十回もリクエストを飛ばす方が、DRY 的には気持ちいい。

ただ、AI エージェントは1つの物理接続を複数のエージェントで共有できる、という前提に立つと、話がひっくり返る。呼び出し側から見た短さより、呼ばれる側の Studio から見た「どのエージェントが何にリクエストしているかが一意に決まる」ことの方が、事故防止としては桁違いに強い。

これは AI エージェント時代のツール設計における1つの型として、他の環境にも波及してくると自分は見ている。エージェントの数が増えれば増えるほど、「アクティブな何か」を暗黙に共有する設計は必ず破綻する。宛先は毎回明示、状態は呼び出し側で持つ、という原則が普通になっていく可能性が高い。

Unity×LLMでNPC会話を実装する時にも起きる「どのインスタンスに話しかけているか」問題

この構造は、実は Unity で LLM を NPC 会話に組み込む時にも同じ形で登場する。

シーンに10体の NPC を配置して、それぞれの NPC に個別の LLM 対話セッションを持たせたいとする。プレイヤーが NPC A に話しかけて、途中で NPC B にも話しかけて、また A に戻ってくる。各 NPC は自分の会話履歴とキャラ設定を保持していて、混ざってはいけない。

安直に実装すると、「今アクティブな NPC」というグローバル変数を1つ持って、話しかけるたびに切り替える方式を取りがちだ。プロトタイプならこれで動く。ただし、非同期に別 NPC のバックグラウンド思考ルーチンを走らせたくなった瞬間に、Roblox の set_active_studio と全く同じ問題にぶつかる。プレイヤー会話と裏側の思考ジョブが同じ「アクティブ NPC」を奪い合うと、プレイヤーに向けた返答が別 NPC のキャラで返ってくる、みたいな事故が起きる。

対策は、Roblox が今回とった studio_id 方式と同じで、リクエストごとに npc_id なり session_id なりを明示的に渡す設計にすること。LLM 呼び出しのラッパーを書く時、「今どの NPC の話をしているか」を毎回引数で受け取る形にしておく。UI 側で NPC を切り替える時にも、内部のグローバル状態を切り替えるのではなく、呼び出しに渡すパラメータを差し替えるだけで済む。

AIVTuber の実装でも似た問題が出る。1人の AIVTuber に見えていても、内部で「配信中の会話コンテキスト」「Discord での日常会話コンテキスト」「動画台本を書く時のコンテキスト」を分けたい、というケースは普通にある。ここでもアクティブコンテキストをグローバルに1つ持たせると、非同期でぶつかった時に「配信中に日常会話用の記憶で応答した」みたいな事故が起きる。呼び出しごとにコンテキスト ID を渡す設計に寄せておくと、複数の会話の場を同時に走らせても平気になる。

Roblox が MCP レイヤーで下した設計判断は、AI をクリエイティブツールに差し込む全てのレイヤーで応用が効く。

AIエージェントをゲーム開発環境に常駐させる設計思想は、受託の現場でも武器になる

VRChat のワールド制作、Unity での AI NPC 実装、AIVTuber の開発支援——AI エージェントをクリエイティブツールに常駐させる案件は、少しずつ現場に出始めている。個人開発の延長でやっている人が多いが、企業側からの依頼もじわじわ増えている感触がある。

こういう領域の依頼で強いのは、実装ができることに加えて、「複数エージェント運用でどこが壊れやすいか」を先に指摘できるエンジニアだ。set_active_studio 方式でプロトタイプを組んで、後から複数エージェント対応で全面書き換え、という手戻りは、依頼側にとって痛い。最初から studio_id 方式相当の設計にしておく判断力があると、それだけで差別化になる可能性がある。

Unity × LLM の連携ノウハウや、複数エージェント環境での状態管理の設計は、個人開発でも受託でも評価される領域だ。今のうちに小さな NPC 実装やワールド内 AI コンパニオンを組んでおくと、案件が出てきた時に選ばれる側に立ちやすい。Roblox の今回の更新は、その練習台としてもちょうどいい題材だと思う。Claude Code や Codex を繋いで、複数エージェントで1つの Studio を触ってみると、共有状態の怖さと studio_id 方式のありがたみが体感で分かる。