Unreal Engine 5.8のMCPを試す前に。Sandboxを過信しない小規模チーム運用

Unreal Engine 5.8のUnreal MCPは、AIエージェントからエディタを操作できる公式の入口になった。ただし、日本の個人・小規模チームが既存の本番プロジェクトへすぐ常設する段階ではない。2026年7月18日時点でMCPもSandboxesもExperimentalであり、EpicはMCPについて未完成・未提供の機能が多く、APIやデータ形式が変わり得ると明記している。

採用するなら、最初の結論は「廃棄できる複製プロジェクトで、ローカル接続を必要時だけ起動し、1回の変更を人が確認してから残す」である。特に、5.8のSandboxesをAIエージェント全体のセキュリティ境界と読み替えてはいけない。公式APIが説明する隔離対象は、主にUnrealのマウントポイント内で発生するファイルI/Oであり、OS権限、外部コマンド、ネットワーク、秘密情報まで隔離するとは書かれていない。

この記事で判断すること

• Unreal MCPを既存制作へ常設せず、小さな検証から始める理由。
• ローカル接続、認証、Toolsets、直列実行という公式の制約。
• Sandboxesが戻しやすくする変更と、守ると確認できない範囲。
• 小規模チームが90分以内で中止・継続を決める試験手順。

5.8で提供されたものと、まだ保証されていないもの

Epicは2026年6月17日にUnreal Engine 5.8の提供開始を発表した。Unreal MCPはエディタープロセス内にMCPサーバーを組み込み、互換クライアントからローカルHTTP経由で接続するExperimentalプラグインである。Actorの生成、照明設定、Material Instance作成、Slateウィジェットの調査、Automation Testの実行などをToolとして呼べる。標準ToolはUnreal MCP本体には含まれず、利用には別のAllToolsetsプラグインも必要になる。Epicの現行文書には、Claude Code、Cursor、VS Code、Gemini、Codex向けの設定生成も記載されている。

一方で、接続できることと、制作へ任せられることは別である。Unreal MCP公式文書によれば、既定の接続先は127.0.0.1:8000/mcpで、Auto Start Serverは既定で無効である。サーバーには認証層がなく、Epicはローカルマシン外へ公開する設計ではないとしている。ループバック限定はネットワーク上の公開範囲を狭める設定であり、接続者ごとの認可機能ではない。Tool呼び出しはゲームスレッド上で直列に実行され、クライアント側も重複する呼び出しを送るべきではない。

既定のTool Searchは、list_toolsets、describe_toolset、call_toolという3つの入口から必要なToolを探す仕組みで、最初から大量のスキーマをクライアントへ送らずに済む。しかし、これは権限制御の説明ではない。call_toolから変更系Toolを呼べるため、「一覧が小さいから権限も小さい」とは判断できない。

Sandboxesは変更選別の仕組みで、AI全体の隔離箱ではない

ISandboxManagerの公式API説明では、アクティブにできるSandboxは同時に1つで、/Game/、/Engine/、/MyPlugin/などのマウントポイント内にあるファイルの追加・変更・削除を、プロジェクトのIntermediate/Sandboxes以下へリダイレクトする。後から変更一覧を見て、元のファイルへ永続化できる。Assetを試作して採否を分ける用途には合っている。

ただし、公式の技術文書で具体的に確認できる隔離範囲はそのファイル層である。AIクライアントが別のシェルから行う操作、マウントポイント外のソースや設定、外部サービスへの通信、エディターが参照できる認証情報まで遮断するという説明はない。また、EpicのMCP文書とSandbox文書は別機能として説明され、すべてのMCP Tool呼び出しが必ずSandboxへ収まるとは明記されていない。

「Sandbox」の読み違いを避ける

ここでのSandboxは、Unrealの編集ファイルを分離し、残す変更を選ぶための機能である。悪意あるコードや誤操作をOSレベルで封じる実行環境としては確認できない。したがって、Sandboxを開いた後も、廃棄できるプロジェクト複製、バージョン管理、ローカル限定接続、人による永続化承認が必要になる。

90分のパイロットで採用可否を決める

試験の目的を「AIでゲームを作れるか」にすると、範囲が広すぎて失敗理由が分からない。1つの既知作業を、人が行った場合と比較できる形にする。たとえば、テスト用Level内のActor配置、既存Material Instanceの複製と値変更、Automation Testの実行など、結果を目視またはログで判定できる作業が向く。

1. 複製を作る：最新コミットから廃棄可能な別cloneまたはプロジェクト複製を作り、その中で検証ブランチを切る。元の作業ツリーは開かず、未コミット変更と秘密情報を複製先へ置かない。
2. 常設しない：Unreal MCPと、標準Toolを使う場合はAllToolsetsを有効にする。Auto Start Serverは無効のままにし、使う時間だけModelContextProtocol.StartServerで起動する。接続先がループバックであることをOutput Logで見る。
3. Toolを列挙する：最初にlist_toolsetsとdescribe_toolsetで、今回必要なToolと変更対象を人が読む。目的外のプラグインや自作Toolsetを同時に試さない。
4. 読む作業から始める：選択中Actorの確認、利用可能なToolの説明、Automation Testの実行など、状態変更の小さい要求で接続と出力を確かめる。
5. 変更を1件だけ行う：UnrealのSandboxを使う場合も、最初は1つのAssetまたはLevelへ限定する。複数クライアントや重複呼び出しを避け、完了するまで次を送らない。
6. 3種類の差分を見る：Sandboxの変更一覧、バージョン管理の差分、Output Logを照合する。要求外のAsset、設定、生成ファイルが増えていないかを確認し、必要な変更だけを人が永続化する。
7. 終了する：ModelContextProtocol.StopServerでセッションを閉じる。変更を説明できない、再現しない、要求外の書き換えがある場合は、その検証成果を本線へ入れない。

継続する条件と、待つ条件

継続する場合も、最初の運用単位は「1人、1クライアント、1Sandbox、1作業」にする。自作Toolは一つの責任へ絞り、公開する引数と返り値を人が読める形にする。採用の指標は生成物の派手さではなく、要求外変更の件数、差分確認に要した時間、同じ手順の再現率、破棄した試行の割合で置くと判断しやすい。