「巨大なアセットを、AIと一緒に解読した話」

AI

壁にぶつかった

UE5 で使っているアセット「Flexible Combat System（FCS）」は、非常によくできた戦闘フレームワークです。 でも、Blueprint でできているのでソースコードが読めません。

「このコンポーネントの中で何が起きているのか」を調べたいとき、エディタで一つ一つノードを追いかけるしかない。 しかも複数のコンポーネントをまたぐ処理を把握するとなると、頭の中で接続を組み立てながら読み進める必要があります。

ガード（Block）のラグ対策を設計しようとしたとき、この壁にぶつかりました。 TakingDamage コンポーネントの内部フローを正確に把握しないと、どこに割り込めばいいかわからない。 エディタでポチポチ追うのは時間がかかるし、見落としも怖い。

もっと効率のいい方法はないかと考えて、Blueprint を一括でテキスト化することにしました。

v1：失敗した方法

まず UE5 の Editor Python を使って、Blueprint の変数・ノード・グラフ情報を get_editor_property で取り出すスクリプトを書きました。

実行してみると、528 個の Blueprint が出力されました。 でも全部こんな感じでした。

=== Variables ===
  (variables block error: Blueprint: Failed to find property 'new_variables' for attribute...)

=== Event Graphs ===
  (error: Blueprint: Failed to find property 'ubergraph_pages'...)
Code language: JavaScript (javascript)

UE5.5 では get_editor_property でこれらのプロパティに直接アクセスできなくなっていたようです。

v2：T3D 形式で解決

調べてみると、UE には AssetExportTask という仕組みがあり、アセットを「T3D 形式」と呼ばれるテキスト形式でエクスポートできることがわかりました。

T3D は UE のネイティブシリアライズ形式で、Blueprint のノード・ピン接続・変数がすべてテキストで出力されます。

task = unreal.AssetExportTask()
task.object = asset
task.filename = output_path
task.selected = False
task.replace_identical = True
task.prompt = False
task.automated = True

result = unreal.Exporter.run_asset_export_task(task)
Code language: PHP (php)

これで全 Blueprint が .t3d ファイルとして出力されました。

ただし、出力されたファイルは UTF-16LE エンコードでした。 grep がそのままでは使えないので、解析前に変換が必要です。

iconv -f UTF-16LE -t UTF-8 DefensiveComponent.t3d > defensive_utf8.txt
grep -n "SR_BeginBlock\|BlockUp\|ChangeMovementSpeed" defensive_utf8.txt
Code language: JavaScript (javascript)

要約 Markdown も自動生成

T3D ファイルは巨大です（DefensiveComponent で17,000行超）。 全部読むのは非効率なので、Python スクリプトで Markdown 要約に変換することにしました。

[要約 Markdown の内容]
## Graphs (Functions / Events)
  - SendBlock
  - ReleaseBlock
  - SR_BeginBlock
  - SR_StartGuard
  ...

## Function Calls
  - OnActionBegin
  - SR_ChangeMovementSpeed
  - CanAnimationPlay
  ...

## Variables
  - BlockUp
  - ParryUp
  ...
Code language: PHP (php)

関数名・変数名の一覧が一瞬で把握できるようになりました。 「この関数あるのかな？」をエディタを開かずに確認できます。

AI との連携で真価を発揮した

ここからが本題です。

T3D ファイルを AI（Claude）に渡すと、「この関数の中で何が呼ばれているか」を正確に答えられるようになりました。

たとえば「SR_BeginBlock の中身を教えて」と聞くと：

SR_BeginBlock（サーバー）の実装：
1. InputBufferComponent → OnActionBegin
2. MovementComponent → SR_ChangeMovementSpeed(Block)  ← Server RPC 版
3. Set BlockUp (True)  ← 速度変更の後にセット
Code language: JavaScript (javascript)

これはエディタでノードを一つ一つ追って確認したのと同じ情報です。 でも T3D 経由なら一瞬で出てくる。

実装ガイドを作るときに「SR_StartGuard に移植すべき処理」を正確に特定できたのは、T3D 解析があったからです。

副産物：バグの発見

T3D を解析していて、予期しない発見がありました。

CustomFunctionName=" SR_EndGuard"  ← 先頭にスペースが入っている
Code language: JavaScript (javascript)

自分で作成した SR_EndGuard という関数の名前に、先頭スペースが混入していました。 エディタ上では気づきにくいバグです。テキストにしたからこそ発見できました。

まとめ

Blueprint アセットの解析ワークフローをまとめると：

UE5 Editor Python
  → AssetExportTask で T3D 出力（bp_export_v2/）

通常 Python（UE不要）
  → T3D を Markdown 要約に変換（bp_summary/）
  → iconv で UTF-8 変換 → grep で詳細調査

Claude
  → T3D の内容を渡して「この関数の中身は？」と質問
  → 実装手順書の精度検証

「実装したいが既存の挙動が不明」という場面で、このワークフローが役立っています。 FCS のような Blueprint アセットを使っている方にはおすすめです。

タイトルとURLをコピーしました