はじめに

前回、ue6-main のソースを読んで Verse の「BP 風グラフビューワ」が自作できるのかを調べました。
今回はその続きで、もう少し足元の話です。

Verse でゲームプレイを書く時代が来るとして、素朴に気になったのが次の3点でした。

Verse のコードはパッケージ（出荷ビルド）に乗るの？ ソースがそのまま入るの？
Entity Prefab はアセットだけど、それ以外の Verse コードはどういう存在形態なの？
最終的には VM で動くコンパイル済みデータになるの？ なるとしたらどの VM？

そして調べていくうちに、話は自然と 「Actor / Blueprint 廃止方針とどう整合しているのか」 まで広がりました。Verse の現行実装が、実は Blueprint の基盤にどっぷり乗っているからです。

Entity Prefab が UBlueprint 派生なのは一時的な判断？
Verse → Blueprint（バイトコード）の変換って、もう存在するの？
それは「BP 完全廃止」の姿勢と矛盾しないの？
実行 VM が BPVM なのも一時的で、あとから VerseVM がメインになるの？
結局、どの層が長期的に「内部資産」として残るの？

本記事はこの計8つの疑問に、ソースを根拠にして答えていきます。

調査環境について：
本記事は、Epic の GitHub ミラーの ue6-main ブランチ（HEAD 21f152757186、2026-08-05 時点の最新。Build.version は MajorVersion 6）を対象に、2026-08-06 時点でエンジンソースを静的に読んで調べたものです。あわせて Epic の公式声明（"The Road to UE6" / 公式 X / REBASE 2025 講演）も一次ソースで確認しています。
実ビルド・実クックによる検証は行っていません。また UE6 はまだ研究/開発ブランチなので、ここで挙げるモジュール・API・デフォルト値はすべて変わる前提で読んでください。確証が取れなかった点は「未確認」として明示します。

例によって記事が長くなったので、要点だけ知りたい方は直下の「結論先出し」と末尾の「おわりに」だけでも。

結論先出し

最初の3つの疑問

疑問	回答
Verse はパッケージに乗るの？	生の `.verse` ソースはクライアントパッケージには乗りません。乗るのはコンパイル済み成果物（`/<Plugin>/_Verse` 系の `.uasset`）です。例外は専用サーバ + ini で明示した場合のみ
Entity Prefab 以外の Verse はどういう存在？	Entity Prefab は `UBlueprint` 派生の通常 `.uasset`。素の `.verse` はアセットではなく loose なソースファイルで、クック時にプラグイン単位の `_Verse` パッケージへ統合されます
VM で動くコンパイル済みデータになる？	なります。デフォルトは Blueprint VM のバイトコード（`UFunction::Script`）、`WITH_VERSE_VM=1` 時は専用 VerseVM のバイトコード（セルエクスポート）です

調べているうちに増えた5つの疑問

疑問	回答
Entity Prefab の `UBlueprint` 派生は一時的？	コード上に「一時的」と明記された箇所はないものの、状況証拠は「移行期の実装」を強く示唆します。周辺の UObject 基盤には「Verse で書けるようになるまでの Temporary」と明記があり、クラス名からも「Blueprint」を外すリネームが済んでいます
Verse→Blueprint（バイトコード）変換は既にある？	あります。それが現行のデフォルト実行方式そのものです。ただし「BP グラフへの変換」ではなく「BP の実行エンジン（VM）をターゲットにしたコンパイラバックエンド」。逆方向（BP→Verse）の変換ツールはこのツリーには存在しません
BP 完全廃止の姿勢と矛盾しない？	矛盾ではなく、公式方針どおりの「移行期」の姿です。公式声明は「即時廃止」ではなく「共存 → deprecated（改善停止）→ 最終的に削除」という段階的プロセスを明言しています
BPVM なのも一時的？VerseVM がメインになる？	ソース内の証拠は明確に Yes。「VerseVM が完全に立ち上がったら削除」というマーカーがリポジトリ全体で6箇所、削除前提の TODO も多数あります。ただし現時点のデフォルトは依然 BPVM で、VerseVM のクック済み運用は未完成です
どの層が長期的に残る？	UX としての Blueprint は廃止予定、BPVM は削除予定、Actor は「Temporary」なプロキシとして流用中。長期資産として残るのは Kismet のアセット/コンパイラ基盤（中期）と CoreUObject 層（長期）です

Verse コンパイル〜クックのパイプライン

全体像

.verse ソースが出荷ビルドに届くまでの流れは、次のようになっています。

ポイントは、Verse が独自のバイナリフォーマットを発明していないことです。コンパイル結果は UVerseClass などの 通常の UObject になり、通常の .uasset として出荷されます。

コンパイル済みパッケージの命名規則（VVMNames.cpp）は次のとおりです。

種類	UPackage パス
Content Verse（ユーザーコード）	`/<MountPoint>/_Verse`
VNI（C++ ネイティブバインディング）	`/<MountPoint>/_Verse/VNI/<CppModuleName>`
アセットリフレクション（Prefab 等の Verse 側投影）	`/<MountPoint>/_Verse/Assets`

ちなみに FPackageName::IsVersePackage() は /_Verse の部分文字列判定（プレフィックス判定ではない）なので、パス中の任意の深さでマッチします。

クッカーには Verse 専用の処理がある

_Verse パッケージはエディタ中ディスクファイルを持たないインメモリパッケージですが、クッカーが専用コードパスでファイル名を合成し .uasset として出力します。CookPackageData.cpp のコメントにも、Verse パッケージはエディタ生成のインメモリパッケージで対応するアセットファイルを（まだ）持たないが、パッケージ済みプロジェクト向けにクックしてアセットファイルを生成したい、という趣旨が明記されていました。

`.verse` ソースは原則ステージングされない

CopyBuildToStagingDirectory.Automation.cs を見ると、bStageVerseSourceFiles の初期値は false で、SC.DedicatedServer の場合のみ ini（bIncludeVerseSourceFilesForServer）で有効化できます。有効時も pak 外の NonUFS 扱いです。

UAT 全体で .verse を扱う箇所はこの1箇所だけで、クライアントに .verse が乗る経路は存在しません。「ソースが丸ごと出荷物に入って中身が読まれる」心配は、少なくとも現状の作りではしなくてよさそうです。なおサーバ向けステージング有効時、Source/**/Verse 配下は .verse / .vmodule に限らず全ファイルが対象になる（拡張子で絞るのは Content 側だけ）という細かい癖もありました。

クライアントには Verse コンパイラの実装が存在しない

WITH_VERSE_COMPILER=1 になるのはエディタと Server ターゲットのみです（Solaris.Build.cs / CoreUObject.Build.cs / VerseNative.Build.cs / VerseVMCodeGen.Build.cs の4箇所で同一ロジック）。

クライアントでは SolarisLoadCompilerModule がスタブ実装（約160行、全 API が no-op）に置き換わり、クック済みパッケージが見つからない場合は警告ログを出すだけでリカバリできません。つまり クライアントは _Verse.uasset をロードするだけの存在で、実行時に Verse を再コンパイルする能力を持ちません。

細かい点として、コンパイラ「モジュール」（VerseCompiler / uLangCore / VerseVMCodeGen）自体はクライアントでもリンクはされます（SolarisLoadCompiler.Build.cs が無条件依存）。実装が WITH_VERSE_COMPILER=0 で全部スタブ化される、という構図です。

Entity Prefab とそれ以外の Verse コードの存在形態

Entity Prefab は `UBlueprint` 派生の通常アセット

EntityPrefab.h を見ると、ど直球でこう書いてあります。

/**
 * A prefab is essentially a specialized Blueprint class for verse::entity
 */
UCLASS(MinimalAPI, BlueprintType)
class UEntityPrefab : public UBlueprint

「Prefab は本質的に verse::entity 向けに特殊化した Blueprint クラス」。実装もコメントどおりで、Kismet の基盤をフル活用しています。

生成は FKismetEditorUtilities::CreateBlueprint(verse::entity::StaticClass(), ...)（生成サイトは EntityPrefabFactory / SimulationPrefabFactory / EntityPrefabWithTransformComponentFactory / SceneGraphUtil の4箇所）
保存時には FKismetEditorUtilities::CompileBlueprint が無条件に走る
Prefab エディタは SSubobjectBlueprintEditor（BP エディタウィジェット）を直接利用

ただしイベントグラフは作らず、汎用の BP ファクトリからの生成も拒否する、「機能を絞った Blueprint」 という位置づけです。グラフは見せずに、BP のアセット管理・コンパイル・再インスタンス化のパイプラインだけを借りている格好ですね。

素の `.verse` は「アセットではない」

一方、素の .verse ファイルはアセットではありません。

AssetRegistry は通常のアセット DB（FAssetRegistryState）とは別体の CachedVerseFiles / CachedVerseFilesByPath で Verse ファイルを管理しています（コメントも "Database of known Verse files"）
Content Browser への表示はファイルデータソース（"VerseData"）経由で、型名の定義箇所には // Not a real type とコメントされています。つまり Content Browser に見えていても、それはアセットの顔をした loose ファイルです
また Verse コードはプラグイン必須で、プロジェクト直下には置けない規約です（VProjectFileGenerator.cs に "UE projects must not contain verse code per current convention" と明記）

この loose なソース群が、前述のとおりクック時にプラグイン単位で _Verse パッケージへ統合される、という関係になっています。

Prefab ⇔ Verse の双方向連携

Prefab → Verse: AssetRegistry タグ（FEntityPrefabMetaData）から digest テキストを生成し、_Verse/Assets パッケージとしてコンパイルします。出力書式は MyPrefab<ReadAccess> := class<ConstructAccess><final><concrete>(entity){} + @import_as(".../<Prefab>_C") の形（アクセス指定子が揃わない場合はフォールバック書式）。つまり Verse コードから Prefab をクラスとして参照できます
Verse → Prefab: <Prefab>_C クラスへの通常の UObject ハード参照です

ランタイム実行形態：BPVM と VerseVM の2系統

バックエンドは排他選択、デフォルトは BPVM

実行バックエンドは2系統あり、ビルド時に排他で選択されます。

bUseVerseBPVM = true（デフォルト）→ WITH_VERSE_BPVM=1 / WITH_VERSE_VM=0
false にしているのはテストプログラム5個のみ。エンジン / ゲーム / エディタ / サーバのストックターゲットは一切切り替えていません

なお bUseVerseBPVM はハード定数ではなくデフォルト値で、-NoUseVerseBPVM / -UseVerseBPVM のコマンドラインや BuildConfiguration.xml で上書きできます。両 VM を共存させる正規のエスケープハッチ（WITH_VERSE_VM=WITH_COREUOBJECT）も定義だけは存在しますが、これを使うターゲットはリポジトリ内にゼロでした（Epic 社内 / Fortnite 用と推定します）。

現在のデフォルト：BP バイトコードを直接吐く

デフォルトの BPVM 経路では、SolarisCodeGenerator.cpp が uLang の IR から BP の EX_JumpIfNot / EX_CallMath / EX_ComputedJump といった EX_* トークンを直接 UFunction::Script に書き込みます（7905行のファイルに EX_ の出現が387行）。実行は ProcessEvent / FFrame、つまり Blueprint とまったく同じ VM です。

新しい経路：VerseVM

WITH_VERSE_VM=1 の新しい経路は、だいぶ雰囲気が違います。

命令セットは UBT がビルド時生成（VerseVMBytecodeGenerator.cs → VVMBytecodeOps.gen.h）
テールコール連鎖型インタプリタ（[[clang::musttail]] + preserve_none）。MSVC フォールバックがないため Clang 必須です。なお UBT レベルでは検証されず、非対応環境ではコンパイルエラーとして顕在化します
AutoRTFM 必須（static_assert(UE_AUTORTFM, "New VM depends on AutoRTFM.")）+ libpas（専用ヒープ）
JIT はなし（VerseVM ディレクトリに "jit" の出現ゼロ）
コンパイル済み関数（VProcedure セル）は、パッケージフォーマット拡張のセルエクスポートテーブル（FCellExport、PackageFileSummary の CellExportOffset 等）として uasset 内に直接シリアライズされます
セルのロードは AsyncLoading2（Zen/IoStore）のみ実装。FLinkerLoad はサマリのフィールドを読むだけで一切処理しません。つまり VerseVM タイトルは実質 IoStore 必須です

面白いのは、VerseVM のバイトコードすら「通常の UPackage シリアライズ機構の拡張」として実装されている点です。ここでも独自コンテナは発明されていません。

ただし移行途上のシグナルも濃く、verse.ForceCompileFramework のデフォルトが VM 有効時 true（フレームワークを起動時にソースコンパイルする）、ソース中にも "VerseVM servers do not yet have matching cooked packages" とあり、VerseVM のクック済み運用はまだ完成していません。

Blueprint 廃止方針と矛盾しないのか

ここからが後半戦です。「Verse の実行基盤が Blueprint に乗っている」という前段の事実は、Actor / Blueprint 廃止方針とどう整合するのか。まず公式声明を事実確認してから、疑問に順に答えます。

前提：Epic 公式声明の整理

一次ソース（公式ブログ "The Road to UE6"、@UnrealEngine 公式 X の全文、REBASE 2025 講演）を確認した範囲では、Epic の公式方針は次のとおりです。

Actor と Blueprint は UE6 の初期バージョンには残り、新フレームワークが十分成熟した段階で eventually deprecated となる。移行用の変換ツールが提供される
移行方針は「既存プロジェクトを一緒に連れて行く。ハードブレイクは強制しない」
deprecation の公式定義：機能は改善されないまま利用可能であり続け、最終的には削除される。そのタイムラインは Verse への移行手段とともに明確に告知される
UE6 Early Access は 2027年末目標、正式版はその 12〜18 ヶ月後（2029年頃）の見込み
REBASE 2025（2025-10）では、Verse 専用 VM（ランタイム・オブジェクトモデル・バイトコードインタプリタをスクラッチ設計、AutoRTFM と組み合わせ）を「旧 VM 比で Verse コードが5倍高速」と発表

重要なのは、公式が言っているのが「UE6 で Blueprint 即時完全廃止」ではなく、「共存 → deprecation（改善停止）→ 最終的な削除 + 移行手段の提供」という段階的プロセスだという点です。削除自体は公式に明言されていますが、その日付・タイムラインは未発表です。なお「旧 VM = BPVM」である点は Epic の明文こそ未発見ですが、講演の文脈とコミュニティ技術情報から強く裏付けられる、準公式レベルの理解だと思います。

疑問①：Entity Prefab の `UBlueprint` 派生は一時的な判断か

コード上の事実から。

UEntityPrefab の UBlueprint 派生そのものに「temporary / transitional / deprecated」といったマーカーは一切ありません。EntityFramework 内の JIRA 風チケット参照（SOL- / UE- / FORT-）を走査しても、Blueprint / Kismet 脱却に関するものはゼロでした
一方、周辺の UObject 基盤には「一時的」と明記があります
- UBaseEntity / UBaseComponent：「Verse ではまだ宣言できないシリアライズ可能メンバ変数やネイティブ UObject インターフェースを実装するための Temporary な基底クラス」
- Entity.h：「プロキシアクターを使っている間だけエディタで必要な Temporary ヘルパ」「Temporary until the World handles the Entities」
命名からの状況証拠もあります。DefaultEntityFramework.ini に CoreEntityPrefabBlueprint → EntityPrefab の ClassRedirect が残っていて、クラス名から意図的に「Blueprint」を外したリネームの痕跡が見えます
EntityFramework.uplugin は "IsBetaVersion": true、公式ドキュメントも "Beta: Use with Caution" です

評価（事実と推論を区別します）。

事実：「一時的」というコード上の宣言はなく、Kismet コンパイラ・BP エディタ基盤にどっぷり依存した、現時点で本気の実装です
推論：Epic 公式の「eventually deprecated」方針、周辺基盤の「Verse で書けるようになるまで」という Temporary マーカー群、Blueprint を外したリネームを合わせると、「成熟した BP アセット/コンパイラ基盤を移行期の足場として再利用している」という解釈が最も整合的だと考えます。ただし「UBlueprint 派生をやめる」という計画そのものは、公式にもこのミラーからも確認できませんでした

疑問②：Verse→Blueprint（バイトコード）の変換は既にあるのか

あります。ただし「変換ツール」ではなく「コンパイラバックエンド」としてです。

前述のとおり、現行デフォルトの Verse 実行方式そのものが「Verse ソース → BP バイトコード」変換です。ただしこれは BP アセット（グラフ）を生成するわけではありません。ノードグラフは作られず、UVerseClass の UFunction にバイトコードだけが入ります。「Verse → Blueprint グラフ」ではなく「Verse → BPVM（実行エンジン）」ターゲティング、と言い分けるのが正確です。

では逆方向、Blueprint → Verse の変換ツールはどうか。こちらはこのツリーには存在しません。ファイル名走査（toverse / bp2verse / versemigrat 等）・コンテンツ検索・約39万コミットのコミットメッセージ検索、すべてゼロ件でした。ツリー内に存在する「Verse コードを生成する機構」はアセットリフレクション（StaticMesh / Material / ControlRig 等 → Verse API digest）のみで、BP グラフは読みません。

公式が約束している "conversion tools" / "ways to migrate projects to Verse" も、表現としてはプロジェクト / フレームワークの移行手段であって、「BP グラフ → Verse コード」のトランスパイラを明言した公式引用は見つかりませんでした。ここは今後の発表待ちだと思います。

疑問③：これらは「BP 完全廃止」の姿勢と矛盾しないのか

矛盾しない、というのが調査結果です。理由は3層あります。

公式方針自体が「即時完全廃止」ではない。前述のとおり公式の説明は「初期 UE6 では共存 → 成熟後に deprecated（改善停止）→ 最終的に削除」です。ue6-main が BP 基盤の上に Verse / SceneGraph を構築している現状は、公式が説明した移行戦略の第1段階（共存期）そのものです
「Blueprint」と「BPVM」は別物。ユーザーが触る Blueprint（アセット・グラフ・エディタ）と、その実行エンジンである BPVM（UFunction::Script のバイトコードインタプリタ）は独立に廃止できます。Verse が BPVM に乗っているのは「実績ある VM を踏み台に言語を先に出荷する」ブートストラップで（UEFN が実際にこの方式で出荷済み）、BP 廃止方針とは軸が異なります
Entity Prefab の UBlueprint 派生も同じ構図。BP のアセット管理・コンパイラ・エディタ・再インスタンス化という成熟インフラを、SceneGraph が自前で持つまで借りている、という読みです

疑問④：BPVM なのは一時的か。VerseVM がメインになるのか

ソース内の証拠は、明確に「一時的であり、VerseVM への移行が進行中」を示しています。個人的に今回一番面白かったのがここです。

削除前提のマーカーを抜粋します。

// VerseCompiler/Public/uLang/CompilerPasses/CompilerTypes.h
// HACK_VMSWITCH - remove this once VerseVM is fully brought up
enum class EWhichVM { VerseVM, BPVM };

この HACK_VMSWITCH（"remove this once VerseVM is fully brought up"）マーカーは、リポジトリ全体で計6箇所あります（CompilerTypes.h ×1、Toolchain.cpp ×4、VerseCompilerCmd.cpp ×1。）。ほかにも、

VVMVerseClass.h：「once BPVM is removed なら復元機能は不要になるだろう」
VVMJson.cpp：「新 VM が書いた永続化データを BPVM で読む必要がある間は…… TODO: Delete when new VM is on 100%」
RulesAssembly.cs：「VNI が新 VM を完全サポートするまで、稀なケースで新旧両方を使えるようにする必要がある」（両 VM 共存サポートの存在理由そのものが「移行完了まで」）
AsyncLoading2.cpp は BPVM 世代の Verse クラスを "old VerseVM classes" と呼んでいる

と、削除前提の記述だらけです。互換目的で残しているコードにすら削除 TODO が付いているあたり、温度感がよく伝わってきます。機能面でも BPVM 側は劣後と明記されていて、named arguments 非対応、byte を超える enum 値非対応、パラメータデフォルト式での <decides> / <suspends> 非対応、タスクキャンセル未実装、といった制約が並びます。

さらに Epic 自身が REBASE 2025 で VerseVM を「旧 VM 比5倍高速」と講演済みで、テスト構成には「vvm server + bpvm client」というクロス VM 相互運用テストまで存在します。サーバ先行などの段階的ロールアウトを想定した作りに見えます。

ただし現在地はこうです。

ue6-main のデフォルトは依然 bUseVerseBPVM = true。ストックターゲットで VerseVM を有効にしているものはゼロ
VerseVM のクック済みフレームワーク運用は未完成（起動時ソースコンパイルがデフォルト）
VerseVM は Clang + AutoRTFM + libpas + IoStore を要求し、ツールチェーン面のハードルも高い
移行完了時期を示すバージョン・マイルストーン・日付は、コード上のどこにも書かれていません

まとめると、「BPVM は Blueprint 存続期間向けの過渡的実装で、あとから VerseVM がメインになる」という見立ては、ソースコードの証拠と Epic の公式発言の両方に整合します。切替時期だけが不明、という状況です。

補足：「Visual Verse」のその後

前回記事で触れた Visual Verse（ProtoLem / VersaTiles）は、この HEAD でも健在です。ただし、その VersaTiles ベースの UI 自体が既に "legacy" 扱いで（sol.UseVerseExplorer2 デフォルト true）、VerseExplorer v2 への置き換えが進みつつありました。これは BP コンバータではなく Verse のオーサリング UI であり、視覚的スクリプティングの公式提供については、報道レベルで「計画あり」と「no plans」が混在していて未確定のままです。

結局、どの層が「内部資産」として残るのか

「UX としての Blueprint は廃止されるが、バックエンドは内部資産として使い続けるのでは」という観点で、Blueprint / Actor を構成するレイヤーごとに整理します。レイヤーによって運命が分かれるのがポイントです。

レイヤー	現状の内部利用	将来	根拠
UX としての Blueprint（グラフエディタ・ノード・アセット作成 UI）	ユーザー向け機能として健在	eventually deprecated（公式声明）	"The Road to UE6"。削除日付は未発表
Kismet（アセット/コンパイラ/エディタ基盤）	`UEntityPrefab` がフル活用	中期的に存続の可能性が高い。この依存関係には削除予定マーカーが一切ない	「グラフを見せない Blueprint」としてアセット管理・コンパイルパイプラインだけを借りる構図
BPVM（実行エンジン）	Verse のデフォルト実行基盤	最終的に削除予定。長期資産にはならない	`HACK_VMSWITCH` ×6、"once BPVM is removed"、"TODO: Delete when new VM is on 100%"
Actor	SceneGraph がエディタ内でエンティティをプロキシアクター（`ALevelEntity`）経由でホスト	流用は現実だが「Temporary」と明記	"Temporary until the World handles the Entities"。公式ドキュメントも Actor と Entity を「互換ではなく連携する別システム」と説明
CoreUObject 層（UObject / UClass / リフレクション / シリアライズ / GC）	Verse・SceneGraph の土台そのもの	最も長期に残る本当の内部資産	`UVerseClass` は `UClass` 派生。VerseVM のバイトコードセルすら通常 UPackage のシリアライズ機構に相乗り

構造的に言うと、BPVM の寿命は「①ユーザー向け Blueprint が存在する限り必要」「②Verse の VerseVM 移行が完了するまで必要」の2要因に縛られていて、両方が終われば利用者がいなくなります。「UX は廃止、VM は温存」ではなく「UX の廃止完了と Verse の移行完了をもって VM も削除」がソースから読める設計意図です。

つまり「バックエンドを内部資産として使い続ける」という見立ては、BPVM ではなく Kismet 基盤（中期）と CoreUObject 層（長期）に対して成立します。UE6 の移行は「Actor / Blueprint / BPVM という上物を SceneGraph / Verse / VerseVM に置き換えつつ、CoreUObject という土台は新旧両方で使い続ける」という構図に見えます。

出荷物を実際に確認したい場合

手元でパッケージを覗くときの手がかりです。

ステージ済みビルドの <Plugin>/Content/_Verse.uasset（+ _Verse/Assets.uasset、VNI なら _Verse/VNI/<Module>.uasset）を探す。ランタイムの FindCookedVerseContent は FPackageName::DoesPackageExist("/<Plugin>/_Verse") で検索しています
クック済みビルドで Verse 型を列挙するなら UVerseClass オブジェクトや FPackageName::IsVersePackage() が使えます。エディタ内でのソース列挙は IAssetRegistry::GetVerseFilesByPath です

未確認事項

ソース読解の限界として、次の点は未確認のまま残っています。

クッカーがインメモリ _Verse パッケージをクック要求リストへ積極的に追加する箇所は未特定です（参照経由の推移的発見と推定）
bIncludeVerseSourceFilesForServer の宣言側 UPROPERTY はこのツリーに存在しません（Epic 内部側と推定）
Fortnite / UEFN の実ターゲットが bUseVerseBPVM をどう設定しているかはミラーに含まれず不明です
EntityFramework のこのリポジトリでの初出は単一コミット（2026-06-11 の "Moving EntityFramework plugin (SceneGraph) out of NFL"）で、それ以前の Epic 社内での履歴・設計議論は見えません（初出以降はリポジトリ内で203コミットの活発な変更があります）
公式ブログの「BP→Verse 変換ツール」が「グラフ→コード変換」なのか「プロジェクト構造の移行」なのか、公式表現は依然曖昧です
実ビルド・実クックによる検証は未実施です

おわりに

例によって長くなりました。

最初の疑問「Verse はパッケージに乗るの？」への答えは、「ソースは乗らない。通常の .uasset に化けて乗る。そして中身は（今のところ）Blueprint のバイトコード」 でした。Verse が独自フォーマットをほとんど発明せず、UPackage・UClass・BPVM といった既存資産の上に徹底して相乗りしている、というのが今回一番の発見です。

そしてその相乗りは、BP 廃止方針との矛盾ではなく、公式が説明した「共存 → 改善停止 → 最終削除」という移行戦略の第1段階の姿そのものでした。HACK_VMSWITCH のような削除前提マーカーを見ると、Epic 自身が「これは足場です」と言いながら組んでいるのがよく分かります。廃止の報道だけ見ると急進的に見えますが、ソースの中身はむしろ、既存基盤を最大限使い倒す堅実なブートストラップでした。

一方で、VerseVM のクック済み運用が未完成だったり、BP→Verse 変換ツールがまだ影も形もなかったりと、「移行の道具立て」はこれからです。UE6 Early Access（2027年末目標）までにこのあたりがどう埋まっていくのか、引き続き定点観測していこうと思います。

この記事が、UE6 の Verse まわりの「今どうなっているか」を掴む入り口になればうれしいです。