はじめに

個人で UE 向けの AI エージェント統合プラットフォームプラグイン を、ここ最近開発しています。
Claude Code や Codex などの AI エージェントが、UE の Editor と Runtime を「操作・観測・実行・検証」できる共通基盤を提供するものです。

その最中、おかずさん（@pafuhana1213）が UE5.8 で増えたプラグインを丁寧に棚卸しされたこちらの記事を拝見しました。

【UE5】UE5.7 → UE5.8 で同梱プラグインが 100 個増えていた話

AI からAnimation、Media、GDK まで全カテゴリを網羅されていて、まずこれを読めば UE5.8 の全体像が一望できます。
私もこの記事で UE5.8 の AI 対応を知りました。

中でも目を引いたのが AI Toolsets カテゴリです。
自分が作っている領域が公式で降ってくるのか…と思い、せめて棲み分けできないかと、AI 向けプラグインに絞って調べてみることにしました。

おかずさんの記事が 106 個すべてを俯瞰する「棚卸し」なのに対して、本記事は AI 連携まわりの仕組みを掘り下げる 方向でまとめています。
アーキテクチャの全体像と、各プラグインの役割・実装状況・注意点が中心です。
AI 以外も含めた全プラグインの増減を知りたい方は、まずはおかずさんの記事を確認してみてください。

調査環境について： UE5.8 はまだ正式リリース前で、正式リリースは6月中旬予定です。
本記事は、プレビューリリース前の GitHub リポジトリと、公開された Preview 版の両方で調査しました。
紹介するプラグインは すべて Experimental ステータス なので、API は今後ガラッと変わる可能性が高い前提で読んでいただければと思います。

記事が少し長くなったので、要点だけ知りたい方は直下の「できること / できないこと」と、末尾の「おわりに」をご参照ください。

UE5.8 時点でできること / できないこと

できること ✅

カテゴリ	具体的にできること
エディタ UI 操作	ウィジェットのクリック・入力・ドラッグ・スクリーンショット取得（SlateInspectorToolset）
自動テスト実行	Automation Test の検索・実行・結果取得・中断（AutomationTestToolset）
GAS 操作・観測	アトリビュート値取得、アクティブエフェクト一覧、アビリティ確認（GASToolsets）
Gameplay タグ管理	タグ一覧・追加・削除・リネーム・参照元検索（GameplayTagsToolset）
アセット意味検索	自然言語クエリでアセットを検索（SemanticSearch プラグイン、UE5.8+）
独自ツール公開	`UFUNCTION(meta=(AICallable))` を付けるだけで MCP 経由に公開（ToolsetRegistry）
外部 MCP 接続	外部 MCP サーバのツールを UE 内に取り込む（MCPClientToolset、OAuth 2.0 対応）
エディタ内 AI チャット	Epic Developer Assistant をエディタパネルに表示し UE 操作と連携（AIAssistant）

できないこと ❌

カテゴリ	制約の内容
Runtime / PIE 制御	PIE の開始・停止・Runtime 中のアクター観測は未対応。Editor 専用
Artifact 管理	スクリーンショットや JSON ダンプを体系的に保存・バンドルする仕組みがない
複数コマンドの連鎖実行	ステップ間の条件分岐・リトライ・タイムアウト管理などのオーケストレーションは未対応
認証・権限制御	Bearer Token 認証や実行できる機能別の権限制御がない（Origin ヘッダーのみ）
WebSocket / stdio	MCP サーバは HTTP のみ。WebSocket・stdio transport は未実装
UE5.7 以前の環境	全プラグインが UE5.8 以降専用（Experimental）

補足： 余談ですが、ここで挙げた「できないこと」── 特に Runtime / PIE 制御や Artifact 管理、複数コマンドの連鎖実行あたりは、私が個人開発中のプラグインで重点的にカバーしている領域とほぼ重なっていました。
裏を返すと、現時点の公式プラグインは「Editor を触る」ところまでで、Runtime まで踏み込んで動かし結果を検証するのはこれから、という温度感のようです。
自作プラグインの存在意義は当面ありそうでちょっとホッとしました…。

全体アーキテクチャ

まず大局観として、UE5.8 の AI 統合は 3層構造 になっています。

ポイントは各レイヤーが完全に分離されていることです。
後述しますが、Toolset を1つ追加するだけで自動的に MCP 経由でも呼び出せるようになる、という気持ちのいい設計になっています。

ToolsetRegistry ── ツール管理の心臓部

仕組み

ToolsetRegistry は「どんなツールが存在するか」を一元管理するレジストリです。
個人的に一番感心したのは、meta=(AICallable) を付けるだけ でツールが公開される点でした。

UCLASS()
class UMyToolset : public UToolsetDefinition
{
    /** アクターを選択する */
    UFUNCTION(meta=(AICallable))
    FString SelectActor(const FString& ActorName);
};

この1行で次のことが自動的に行われます。

自動処理	内容
JSON スキーマ生成	UHT リフレクションから引数・戻り値のスキーマを自動生成
ルーティング登録	`MyToolset.SelectActor` という名前でルーティング
MCP への公開	ModelContextProtocol プラグイン経由で外部 AI に公開

スキーマ生成には UHT（Unreal Header Tool。UCLASS / UFUNCTION を解析してリフレクション情報を生成する UE のツール）が使われています。
AI に見せるツールの説明文も、Description= のような専用メタ指定子ではなく UFUNCTION 直上の /** ... */ ツールチップコメントがそのまま採用される 作りでした。
つまり C++ の型情報とコメントが、そのまま AI 向けの API 仕様になる わけです。UnrealC++ ではお馴染みのメタ指定子とドキュメントコメントが、ここでは「AI 向け API の公開」として効いてきます。

ここからは予想ですが、今後は AI 向けの情報を渡すためのメタ指定子がもっと増えていくのではと思っています。
AICallable は「AI に公開するか」のフラグですが、たとえば「この引数の取りうる値の例」「副作用の有無」「破壊的操作かどうか（実行前に確認を取らせる）」といったヒントをメタ指定子で添えられるようになれば、AI 側はより安全かつ的確にツールを使えるようになるはずです。
リフレクション情報をそのまま AI の文脈に流し込むこの仕組みとは相性が良いので、UnrealC++ の指定子が「人間向け」だけでなく「AI 向け」にも拡張されていく未来は十分ありそうだなと感じました。

ExecuteTool の流れ

FToolsetRegistry::ExecuteTool("Toolset.ToolName", JsonInput)
  → "." で Toolset 名と Tool 名に分割
  → UFUNCTION をリフレクション経由で呼び出し
  → TFuture<TValueOrError<FString, FString>> で非同期返却

戻り値は必ず JSON 文字列 形式です。

ModelContextProtocol ── UE を MCP サーバにする

概要

このプラグインは UE エディタそのものを MCP（Model Context Protocol。Anthropic 策定の、AI と外部ツールをつなぐ標準プロトコル）サーバとして外部に公開 します。
Claude Code などの AI エージェントから直接接続できるようになります。

項目	仕様
Transport	HTTP のみ（WebSocket / stdio は未対応）
エンドポイント	`POST /mcp`（RPC 受付）、`DELETE /mcp`（セッション削除）
デフォルトポート	8000
プロトコルバージョン	2025-11-25 / 2025-06-18 / 2024-11-05 に対応
認証	なし（Origin ヘッダーによる DNS rebinding 対策のみ）
ストリーミング	`tools/call` のレスポンスを SSE（Server-Sent Events。サーバ→クライアントの一方向 push）で返す

Deferred Loading モード

ツールが大量になると今度は AI 側のコンテキスト枠を圧迫 します。
bDeferredToolLoading=true にすると最初は3つのメタツールだけを公開する遅延モードになります。

初期公開ツール（3種類）
  ├─ list_toolsets    ── どんな Toolset があるか確認
  ├─ describe_toolset ── Toolset の詳細を確認
  └─ load_toolset     ── 必要な Toolset だけ明示的にロード
        ↓ AI が load_toolset を呼んで初めて個別ツールが露出

全部いきなり公開するのではなく、AI が必要なものを自分で探してロードする形です。
コンテキスト効率を考えた実用的な設計になっていました。

各 Toolset の実装状況

UE5.8 時点（Experimental）での各 Toolset の状況です。
なお、 Toolset は他にも Conversation / Niagara / Physics / UMG / StateTree / GameFeatures / LiveCoding など多数あります。
ここでは私が中身まで確認した主要なものに絞るので、全リストは前掲のおかずさんの記事を確認してください。

実装済み（使える）

SlateInspectorToolset ── UI オートメーション

エディタの UI を AI から直接操作するためのツール群です。
スクリーンショットを撮り、ウィジェットツリーをダンプし、ボタンをクリックする。
人間がエディタを触る操作をひと通り肩代わりしてくれます。

ツール	概要
Screenshot	エディタのスクリーンショット取得
Snapshot	Slate ウィジェットツリーを JSON ダンプ
Click / Hover	ウィジェットのクリック・ホバー
Type / PressKey	テキスト入力・キー入力
Drag	ドラッグ操作
WaitFor	条件が満たされるまで待機
FillForm	フォームの一括入力
ほか計14種

AutomationTestToolset ── 自動テスト連携

ツール	概要
DiscoverTests	テストを検索・一覧取得
ListTests	テスト一覧を返す
RunTests	テストを実行
GetTestResults	テスト結果を取得
GetTestStatus	実行中テストのステータス確認
StopTests	テストの中断

AI がテストを実行 → 結果を受け取って判断 → 直す、というループが組めるのはいいですが、このループ自体は AutomationTest をコマンドラインからヘッドレス実行すれば以前から組めたもので、この Toolset は同じことを AI 前提で扱いやすくしてくれるもの、という位置づけです。

GASToolsets ── Gameplay Ability System

ツール	概要
GetAttributeValues	アトリビュート値の取得
GetActiveEffects	アクティブな Gameplay Effect 一覧
GetGrantedAbilities	付与済みアビリティ一覧
ExecuteCueOnSelectedActor	選択アクターに Gameplay Cue を実行

GASToolsets は実際には AbilitySystemInspector / AttributeSet / GameplayCue の3つの Toolset クラスに分かれていて、合計で14ツールほどあります（上表は代表的なものの抜粋。ExecuteCueOnSelectedActor は GameplayCue 側）。

GameplayTagsToolset ── Gameplay タグ管理

ListTags / AddTag / RemoveTag / RenameTag / FindReferencersByTag が使えます。
タグのリネームや参照元の一括検索など、手動だと地味に面倒な作業 を AI に委ねられるのは実用的だと思います。

C++ は空でも油断できない（Python 実装の Toolset）

ここは私が最初に読み違えたところなので、注意喚起として書いておきます。
AnimationAssistantToolset と AIModuleToolset は C++ モジュールがほぼ空（UFUNCTION ゼロ） で、ヘッダだけ見ると「スタブかな？」と早とちりしがちです。
ところが中身は Python 側で実装 されていました。

Toolset	C++	実体
AnimationAssistantToolset	ほぼ空（19行）	Python で実装（`sequencer.py` ほか、計 300 超の関数）
AIModuleToolset	ほぼ空（16行）	Python で実装（`behavior_tree.py` 等）
DataflowAgent	17 UFUNCTION を実装済み	C++ で完成（`ListNodeTypes` ＋ `UDataflowGraphEditingSkill` も実在）

ToolsetRegistry は C++ だけでなく Python で書いたツールも登録できる 設計になっていて、上記2つはそのルートで機能します。
つまり「C++ ヘッダが空＝未実装」ではない、というのが UE5.8 の Toolset を読むときの落とし穴です。
DataflowAgent も「実装中」どころか中身は一通り揃っていました。ヘッダの行数だけで判断せず、Python 側も合わせて見るのが正解です。

SemanticSearch ── 自然言語でアセットを検索する

Toolset という形式ではありませんが、UE5.8 で追加された SemanticSearch も AI 統合の文脈で面白い機能なので紹介します。

何ができるか

「キャラクターが走るモーション」「赤みがかった岩のマテリアル」のような 自然言語クエリ でプロジェクト内のアセットを検索できます。
従来のキーワード検索（ファイル名一致）と違い、意味的な近さ で候補を絞り込んでくれるのがポイントです。

内部の仕組み

① クエリテキスト（例: "running animation for character"）
        ↓ MLS バックエンド（Epic の ML サービス）に HTTPS 送信
② 埋め込みベクトルを生成（次元数はモデル依存。応答から動的に決まる）
        ↓
③ FAISS（PQ 量子化のベクトル近似探索）で意味的に近いアセットを絞り込む
   ＋ BM25（全文検索）でキーワード一致も評価
        ↓
④ RRF スコアで統合ランキング → 結果を返す

意味検索と全文検索の 2種類を組み合わせたハイブリッド検索 です。
それぞれ簡単に補足します。

埋め込みベクトル（Embedding）：テキストの意味を数値の配列で表したもの。
意味が近いほどベクトルの距離も近くなり、次元数は固定ではなくバックエンドの応答から動的に決まります
FAISS：大量のベクトルから近いものを高速に探す Meta 製ライブラリ。
近似最近傍探索（ANN）で絞り込む。
UE5.8 では PQ（Product Quantization）でベクトルを圧縮して持ちます。
BM25：キーワードの一致頻度と文書長を考慮した古典的な全文検索スコアリング。
RRF（Reciprocal Rank Fusion）：複数のランキングを「順位情報だけ」で統合する手法。
スコアのスケール差を気にせず合成できる。

意味検索は固有名詞の完全一致が苦手なのでそこを BM25 で補い、最後に RRF で1本のランキングにまとめる、という構成になっています。

MLS バックエンドとは

埋め込みの生成はローカル推論ではなく、Epic の ML バックエンド（コード上のコメントでは "MLS backend services" と表記。Machine Learning Service の略と思われます）への HTTPS リクエストで行われます。
実装されている IEmbeddingProvider は FRemoteEmbeddingProvider の1種類だけで、FHttpModule 経由でリモートに投げる作りです（NNE などのオンデバイス推論版は、インターフェース上「将来両対応可」とコメントされているのみで未実装）。

ここで重要なのが、接続先 URL や認証情報が Engine/Restricted/NotForLicensees/... 配下の非公開 Config から読み込まれる という点です。
これは Epic 社員向けのファイルで公開ビルドには同梱されません。
つまりライセンシーが使う通常のエンジンでは URL が未設定のまま起動し、Remote Provider は実質的に動かない ことになります。
SemanticSearch を有効化しても、現状の公開ビルドではこの埋め込み生成が機能しない、という理解が正確です。

注意： 裏を返すと、接続先が設定された環境（Epic 社内など）で動かした場合は、クエリテキストとアセットのキャプション情報が HTTPS で外部に送信されます
（クエリは {"text": "..."} の POST、キャプション生成は task_preset = "UE_ASSET_TAG_AND_CAPTION_V1" の multipart）。
将来 URL が一般提供される際には、社外秘アセットを含むプロジェクトでの取り扱いに注意が要ります。

サードパーティが MLS を使えるのか問題

IEmbeddingProvider::GenerateEmbeddingAsync() は API としては呼び出せる状態になっています。
ただ前述のとおり、公開ビルドでは接続先 URL が同梱されていないため、呼んでも実際には機能しません。
「API はあるが、接続先はまだライセンシーに開かれていない」状態です。

仮に将来 URL が提供されたとしても、

MLS の利用は Epic 自社製品・公式プラグインのみを想定しているのか
サードパーティ製の商用プラグインから MLS を呼ぶことは EULA / 利用規約の範囲内か

といった点は依然として不明確です。
SemanticSearch 自体がまだ Experimental なこともあり、利用規約の整備は機能の安定化より後になる可能性が高い と思います。
当面は「公開ビルドでは事実上使えない」前提で捉えておき、MLS に依存した機能を商用配布したい場合は事前に Epic へ確認するのが無難でしょう。

MCPClientToolset ── 今度は UE を MCP クライアントにする

ここまでは「UE がサーバになる」話でしたが、逆方向の接続 もあります。
UE 側が外部の MCP サーバへ接続しにいくクライアント機能です。

外部 MCP サーバのツール群をローカルの ToolsetRegistry に取り込み、他の Toolset と同列で扱えるようになります。
認証方式は3段階に対応しています。

認証モード	説明
None	認証なし
Bearer Token	`Authorization: Bearer <ApiKey>`（固定の API キーを直接指定する簡易設定）
OAuth 2.0	Authorization Code + PKCE。RFC 8414 Discovery・RFC 7591 Dynamic Client Registration・トークン永続化まで実装済み

OAuth 2.0（パスワードを渡さずにアクセス権を第三者へ委任する仕組み）までしっかり実装されているあたり、本格的な外部サービス連携を想定しているのが伝わってきますね。
なお PKCE (ピクシーって読むらしいですね...) は、認可コードを横取りされても単体では使えないようにするための追加防御のようです。
ただし取得したトークンは GEditorPerProjectIni に 平文で保存 される実装で、暗号化やセキュアストレージは使われていない点には留意してください。

AIAssistant ── エディタ内に Epic Developer Assistant を表示する

これは Toolset / MCP サーバとは 別系統の独立したプラグイン です。

CEF（Chromium Embedded Framework）ベースの組み込みブラウザで、dev.epicgames.com/community/assistant/embedded にホストされた Epic Developer Assistant（EDA） を Editor パネルとして表示します。
EDA は Epic が独自に運用している AI アシスタントで、バックエンドの LLM が何なのかはソースからは判別できませんでした。

なおこのプラグインは NoRedist／デフォルト無効の Experimental なので、使うにはまず手動でプラグインを有効化する必要があります。

通信アーキテクチャ

HTTP REST ではなく JavaScript ブリッジ で UE と EDA が双方向通信しているのが特徴です。

EDA フロントエンド（ブラウザ内）
  ↕ window.eda.*（JS ブリッジ）
UE C++ 側（AIAssistant プラグイン）
  ↕ FToolsetRegistry::ExecuteTool()
各 Toolset（SlateInspector 等）

起動時に ToolsetRegistry へ登録済みの全ツールスキーマを EDA へ送信し、EDA は「どのツールが呼べるか」を把握します。
EDA がツール呼び出しを要求すると、C++ 側が受け取って ToolsetRegistry 経由で実行し結果を返します。
ブラウザ内の AI と UE 内部を window.eda でつないでいるわけですね。

注意点

接続先が dev.epicgames.com なので、オフライン環境では動作しない
Epic アカウントへのログインが必要になる可能性がある（認証フローは Web 側で処理）
AIAssistant.json の main_url を書き換えれば接続先の差し替え自体は可能だが、 window.eda 互換の JavaScript API を自前で実装する必要がある

差し替え口は一応あるものの、ブリッジ互換まで実装するのはそれなりに大変、という感じです。

セキュリティ面の注意

最後に地味だけど大事なところですが、公式 MCP サーバ（ModelContextProtocol）の認証は Origin ヘッダーによる DNS rebinding 対策のみ です。
これはローカルで動くサービスを悪意ある Web ページから勝手に叩く攻撃ですが、UE5.8 はリクエストの Origin が期待したドメインかをチェックして防いでいます。

逆に言うと、Bearer Token 認証や実行できる機能別の権限制御は現時点では存在しません。
「信頼できるローカル開発環境での利用」が大前提 ということです。
外部ネットワークに露出する運用をするなら別途しっかり対策を入れる必要があります。

おわりに

書きたいことを書いていたら長い記事になってしまいました。

冒頭で書いたとおり私自身ちょうど近い領域のプラグインを個人開発しているので、今回は開発中のプラグインがお蔵入りになるのではとドキドキしながら確認していました。
結論としては、公式プラグインは「Editor を触る」ところまで。
Runtime まで踏み込んだ操作・検証やコマンドの連鎖実行といった部分はまだこれから、という印象でした。
とはいえ、独自ツールを AICallable 1行で公開でき、MCP サーバ → ToolsetRegistry → 各 Toolset の綺麗な3層構造でそれが成り立っているのを見ると、これまで各社・各個人が独自に作り込んでいた領域がエンジン標準として降りてきたのだな...と実感しました。
Experimentalが外れた時は、個人利用の範囲なら Toolset の仕組みに乗せて個人用のライブラリを作れば良いかもしれません。

今回の調査は UE5.8 の Plugins/Experimental 以下（ModelContextProtocol / ToolsetRegistry / 各 Toolset / SemanticSearch）を確認して行いました。
このあたりの公式プラグインはまだ日本語の情報がほとんどないので、今後色んな情報が出てくるのが楽しみです！
この記事が UE5.8 の AI まわりを触る方の入り口になればうれしいです。