はじめに
UE6（ue6-main）で FirstPersonTemplate を Verse だけで再実装できるか を調べた記事の続きです。
結論は「カメラ・入力・移動・フレームワーク層の Verse API が無いので現状は無理」だったのですが、その調査の過程で アニメーション周りが AnimBP から大きく作り替えられている ことに気づきました。具体的には、AnimBP が担っていた役割が Verse と UAF（Unreal Animation Framework）の2つに分割 されています。
ここは FirstPerson の移植可否（＝結局カメラ・入力が無い時点で詰む）にはあまり影響しないのですが、UE6 のアーキテクチャの話として面白かったので、前回の記事から切り出して まとめることにしました。本記事は アニメーション層と、その土台になっている RigVM の位置づけ が中心です。
調査環境について：
ue6-main/ コミット:ef011d7aa002、調査日: 2026-06-21
本記事で触れる UAF / UAFChooser 系プラグインは すべてEnabledByDefault: falseの Experimental、SceneGraph（EntityFramework）は Beta、Verse コアは安定版（IsBetaVersion: false）だが未有効、という状態です。API は今後ガラッと変わる前提で読んでいただければと思います。
プラグインやファイルのリストアップには Claude Code / Codex も併用しています。確認はしていますが、最終的にはご自身の環境でも確認するのを推奨します。
また、本記事は 「ソースから確認できた事実」と「推測」を区別して書く よう心がけています。推測の箇所はその旨を明示します。
結論：Verse → UAF は通る、UAF → Verse はまだ
先に要点だけ。Verse と UAF の間の連携は 片方向だけ整っていて、逆方向はまだほぼ無い 状態です。
| 方向 | 状況 |
|---|---|
| Verse → UAF（再生指示） | ◯ PlaySkeletalAnimation でアニメを再生できる |
| Verse → UAF（途中制御） | ◯ Easeable でブレンドを後から操作できる |
| UAF → Verse（AnimNotify 相当） | ✕ Verse 側に通知 API なし |
| UAF → Verse（ステート遷移通知） | ✕ |
| UAF → Verse（ルートモーション値の取得） | ✕ |
「Verse から再生を指示する」ことはできるけれど、「アニメ側で起きたこと（攻撃判定のタイミング、ステート遷移、ルートモーション）を Verse 側で受け取る」仕組みが、現時点ではまだ用意されていません。AnimBP 時代には当たり前にあった AnimNotify がごっそり無い、という状態です。詳細は後半で見ていきます。
AnimBP の何が変わったのか
まずは大局観から。UE5 までと UE6 で、構造がどう変わったかを整理します。
UE5 まで：
AnimBP は「Blueprint の一種」でした。ゲームロジックを書く Gameplay BP と、アニメーションを書く AnimBP が、同じ VM・同じグラフ基盤の上に乗った兄弟 だったわけです。
UE6：
UE6 では、ゲームロジックを担う Verse（VerseVM 上で動く） と、アニメーションを担う UAF（RigVM 上で動く） が、そもそも別の仮想マシンの上に分かれて います。AnimBP のように「同じ基盤の派生」ではなく、言語・VM レベルで分離 されたのが UE6 の構図です。
イメージとしてはこんな感じです。
- Verse = 「監督」（このシーンでこの曲を流せ、と指示する）
- UAF = 「音響エンジニア」（その曲をどうフェードイン・ミックス・カットするか組む）
- 境界 = 曲のリスト（AnimSequence）の受け渡しだけ
AnimBP 時代は監督と音響エンジニアが同じ Blueprint の中に同居していましたが、UE6 では役割がはっきり分かれた、というのが私の理解です。
UAF（Unreal Animation Framework）とは
Engine/Plugins/Experimental/UAF/ 配下に、AnimBP の後継となるプラグイン群が 14 個 あります。
| プラグイン | 役割 |
|---|---|
UAF |
コア（IsExperimentalVersion: true） |
UAFAnimGraph |
AnimGraph 本体（AnimBP の Anim Graph 後継） |
UAFAnimNode |
アニメノード |
UAFStateTree |
AnimBP のステートマシン相当を StateTree で記述 |
UAFChooser |
アニメ選択（条件分岐） |
UAFLayering / UAFMirroring / UAFPoseSearch / UAFWarping
|
各種アニメ機能 |
UAFControlRig |
ControlRig 統合 |
UAFMass / UAFAnimGen / UAFSharedAssets / UAFTestSuites
|
周辺 |
ポイントは2つです。これらはすべて RigVM ベース（後述）で、Verse で書くものではありません。そして、AnimBP のステートマシンに相当するのは UAFStateTree が担当します。AnimGraph 内のステートマシンが、独立した StateTree として切り出された形ですね。
Verse 側の modifier(skeleton) モデル
では Verse 側はアニメーションに対して何ができるのか。鍵になるのが modifier(skeleton) という考え方です。
Engine/Plugins/EntityFramework/Source/EntitySkeletalAnimation/Verse/SkeletalAnimation.native.verse：
@experimental
@available{MinUploadedAtFNVersion := 4100}
skeletal_animation<public><native> := class(skeletal_animation_base, modifier(skeleton)):
Evaluate<native><override>(InValue:skeleton)<reads>:skeleton
SetProperty<epic_internal><native>(PropertyName: string, NewValue: any, MarkDirty: logic)<transacts>:void
InternalAsset<epic_internal><native>:animation_asset = animation_sequence{}
HasSkeletalAnimation.native.verse：
has_skeletal_animation<epic_internal><native> := interface:
@editable
@category("Animation")
SkeletalAnimation<epic_internal>:modifier_stack(skeleton)
ざっくり言うと、Verse 側からは AnimationSequence をエンティティに割り当て、modifier として skeleton に積む ことができます。skeletal_animation が modifier(skeleton) を実装していて、Evaluate で skeleton を受け取って skeleton を返す——つまり 「ポーズを加工する処理」を Verse 側のオブジェクトとして表現 している、という構造です。
Verse ↔ UAF のブリッジ
では、Verse 側で作った modifier(skeleton) が、どうやって UAF（RigVM 側）のアニメーション評価につながるのか。その接続点がこのヘッダにありました。
Engine/Plugins/EntityFramework/Source/EntitySkeletalAnimation/Private/UAFGraphFactoryAsset_SkeletonModifier.h：
namespace verse { class modifier; }
USTRUCT(DisplayName="modifier(skeleton)", meta=(Hidden))
struct FUAFGraphFactoryAsset_SkeletonModifier : public FUAFGraphFactoryAsset
{
explicit FUAFGraphFactoryAsset_SkeletonModifier(TInterfaceInstance<verse::modifier> InModifier)
: ModifierObject(InModifier.GetObject()) {}
UPROPERTY()
TWeakObjectPtr<UObject> ModifierObject;
};
FUAFGraphFactoryAsset を継承した構造体が、コンストラクタで verse::modifier を受け取って保持しています。つまり Verse の modifier(skeleton) が、そのまま UAF AnimGraph のソース（入力アセット）として取り込まれる 設計になっている、ということです。
ここまでを図にすると、こうなります。
Verse は「どのアニメを使うか」を供給し、UAF が「それをどう評価・ブレンドして最終ポーズを作るか」を担う。境界は modifier(skeleton) の受け渡し、という分担です。
双方向 API の現状
ここからが本題です。Verse と UAF の間の通信が、方向によってどれくらい整っているかを見ていきます。
Verse → UAF 方向（再生指示）
SkeletalAnimationPlay.native.verse に、再生を指示する API があります。
@experimental
@available{MinUploadedAtFNVersion := 4100}
(Entity:entity).PlaySkeletalAnimation<public>(
Animation:skeletal_animation,
?EaseInWindow:easing_window = easing_window{},
?EaseOutWindow:easing_window = easing_window{})
<decides><transacts> : play_skeletal_animation_result
エンティティに対して PlaySkeletalAnimation を呼ぶとアニメが再生され、戻り値の play_skeletal_animation_result が持つ Easeable を使うと、再生中アニメのブレンドを後から操作 できます。つまり 「再生しろ」「ブレンドをこう変えろ」という Verse → UAF の指示はできる ということです。
UAF → Verse 方向（通知）
問題は逆方向です。EntitySkeletalAnimation/Verse/ 配下の全 .verse を、listenable / subscribable_event / notify で検索したところ、ヒット 0 件 でした。
AnimBP 時代に当たり前にあった、以下のような「アニメ側からゲームロジック側への通知」が、現状の Verse API には 存在しません。
| AnimBP 時代の機能 | UE6 Verse API |
|---|---|
| AnimNotify（攻撃ヒット・足音・エフェクト発火） | ✕ |
| ステート遷移イベント（"Idle → Walk" など） | ✕ |
| アニメ末端到達通知 | ✕ |
| ルートモーション値の取得 | ✕ |
UAF 側には EvaluationNotifies プラグイン（AnimNotify の UAF 版にあたるもの）が存在しますが、これは すべて C++ 実装で Verse バインディングがありません。UAF AnimGraph の中で完結する仕組みで、Verse からは触れない、ということです。
整理すると、双方向はこうなります。
なぜそう言えるのか（イベント基盤自体は機能している）
「単にまだ Verse のイベント基盤が無いだけでは？」とも思ったのですが、そうではなさそうです。SceneGraph のコンポーネントレベル（たとえば KeyframedMovementComponent）には、Stopped / Played / Paused / Finished / KeyframeReached といった listenable イベントが豊富に揃っています。
つまり Verse 側のイベント／購読の仕組みそのものは機能している わけで、Skeletal Animation 側にだけ、その通知がまだ実装されていない という状態です。
推測： Skeletal Animation が
@experimentalであることを踏まえると、UAF → Verse の通知系は「設計上できない」のではなく「Experimental 段階でまだ整備されていない」だけ、と考えるのが自然だと思います。ただし Epic 内部の意図までは分からないので、ここは推測です。
RigVM の位置づけ
UAF が「RigVM ベース」と何度か書いてきましたが、その RigVM 自体についても整理しておきます。
RigVM とは
Engine/Plugins/Runtime/RigVM/RigVM.uplugin：
Description: "Provides frontend and backend for the RigVM visual programming language and runtime"EnabledByDefault: true
RigVM は 汎用のビジュアルプログラミング言語 ＋ 仮想マシン です。Blueprint より低レベルで高速、かつ ドメイン特化エディタの共通基盤 として使われています。
Control Rig との関係
Control Rig は、この RigVM の上に乗っているドメイン特化アプリの1つです。ControlRig.h で、
UControlRig : public URigVMHost
と明示されていて、ControlRig.uplugin も RigVM を必須プラグインとして宣言しています。
補足（推測）： 業界的には「Control Rig が先に生まれ、その汎用グラフ／VM 部分が RigVM として切り出された」と知られていますが、その経緯を示す公式記述は UE6 リポジトリ内では確認できませんでした。確実に言えるのは、現在の継承関係（
UControlRig : public URigVMHost）が事実だ、という点までです。
RigVM を使っている主要システム
| システム | 用途 |
|---|---|
| ControlRig | プロシージャルリギング、IK、ボーン制御 |
| UAF | AnimBP 後継、AnimGraph 全体 |
| UAFAnimGraph / UAFAnimNode | UAF の AnimGraph 本体 |
| UAFChooser |
RigUnit_EvaluateChooser で Chooser を RigVM から呼ぶ |
| UAFControlRig | UAF と ControlRig のブリッジ |
Verse / Blueprint との階層分担
ここまでを階層で並べるとこうなります。
注： Actor / Blueprint の段階的な非推奨化（Verse への移行）は、State of Unreal 2026（2026/6/17）で公式に発表 されています。ロードマップ上、Actor / BP は UE6 の Early Access〜初期リリースには残り、新フレームワークが成熟した段階で非推奨化され、Verse への移行ツールが用意される、とされています。つまり「いずれ無くす」方向は公式ですが、
ue6-main時点ではまだ BP / C++ のテンプレートが現役で、本記事もその前提で書いています。BP 廃止と Verse の現状については別記事にまとめました → BP 廃止の UE6 で、Verse の「BP 風グラフビューワ」は自作できるのか
UAFChooser と Chooser の関係
最後に、UAFChooser が UE5 からある Chooser と何が違うのかを整理しておきます（名前が紛らわしいので）。
Chooser プラグイン（Engine/Plugins/Chooser/）
- UE5 から存在する 汎用基盤
Description: "Use Chooser and Proxy Tables to build dynamic asset selection logic."- 条件に基づいてアセットを選ぶロジックを組むためのもの
Chooser 自体の機能やコンセプト（データドリブンなアセット選択、ABP のステートマシンを Chooser ＋ 1 ノードに寄せる例など）は、おかずさん（@pafuhana1213）の解説記事がとても分かりやすいです。
UAFChooser プラグイン（Engine/Plugins/Experimental/UAF/UAFChooser/）
-
Description: "Chooser integration for UAF."← Chooser を UAF に統合するアダプタ IsExperimentalVersion: true-
Build.csのPublicDependencyModuleNamesに"UAF"と"Chooser"の 両方 を宣言
統合の証拠
// UAFAnimChooser.h
#include "Chooser.h"
UCLASS()
class UUAFAnimChooserTable : public UChooserTable // Chooser のサブクラス
{
...
};
UUAFAnimChooserTable が UChooserTable（Chooser 側のクラス）を継承しています。さらに UAFChooser 固有の要素として、
-
UAFChooserPlayerNode— UAF AnimGraph 上で Chooser を評価するアニメノード -
RigUnit_EvaluateChooser— Chooser を RigVM から呼ぶための Unit -
UAFGraphFactoryAsset_Chooser— Chooser Table を UAF AnimGraph ソースとして扱う
があります。
まとめると
| 質問 | 答え |
|---|---|
| UE5 の Chooser と別機能か | いいえ（基盤は同じ） |
| UE5 の Chooser と同じものか | いいえ（UAFChooser は別プラグイン） |
| Chooser の UAF 拡張か | YES（公式説明・継承関係から明確） |
つまり UAFChooser は、汎用の Chooser を UAF（RigVM の AnimGraph）から使えるようにするための統合レイヤー、という位置づけです。
おわりに
UE6 のアニメーションは、AnimBP のように1つの Blueprint の中で完結していたものが、ゲームロジック（Verse / VerseVM）とアニメーション（UAF / RigVM）に、言語・VM レベルで分割 されました。両者の境界は modifier(skeleton) の受け渡しで、Verse は「どのアニメを使うか」を供給し、UAF が「それをどう評価・ブレンドするか」を担います。
ただ、現時点で整っているのは Verse → UAF（再生指示・ブレンド制御）の片方向だけ で、UAF → Verse の通知（AnimNotify・ステート遷移・ルートモーション）はまだ Verse からは触れません。SceneGraph のコンポーネント側には listenable イベントが揃っているので、イベント基盤そのものは機能しています。Skeletal Animation 側にその仕組みが乗ってくれば、攻撃判定や足音のタイミングを Verse 側で受けられるようになるはずで、ここは今後に期待したいところです。
土台の RigVM は ControlRig も UAF も Chooser も載る共通グラフ基盤で、UE6 のアニメーション系がここに集約されつつあるのも見えてきました。
繰り返しになりますが、本記事で触れた UAF / UAFChooser はすべて Experimental 段階のスナップショット（ue6-main / ef011d7aa002）です。バージョンが上がれば、特に UAF → Verse の通知まわりは状況が変わる可能性が高いので、その前提で読んでいただけるとうれしいです。
前回の FirstPerson 移植可否の記事と合わせて、UE6 の Verse / SceneGraph まわりを触る方の入り口になればうれしいです。