UE5のBlueprintで出てくるCollapsed Graphは、FunctionやCustom Eventと何が違うのか、どんなときに使うのかを初心者向けに整理します。実際の初期化フローを例に、なぜCollapsed Graphが自然なのかもあわせて解説します。
UE5のBlueprintで出てくる「Collapsed Graph」とは何か
Unreal Engine 5のBlueprintを触っていると、Collapsed Graph というものを見かけることがあります。
最初に見たときは、「これ、FunctionやCustom Eventでよいのでは？」と思いやすいです。実際、その感覚はかなり正しいです。再利用するならFunction、イベントの入口にするならCustom Eventが基本だからです。
それでもCollapsed Graphにはちゃんと使いどころがあります。結論から言うと、Collapsed Graphは再利用のための機能ではなく、その場の処理を整理するための機能です。
まずは、長いノード列を読みやすく折りたたむための箱として理解すると分かりやすいです。
Collapsed GraphはFunctionやCustom Eventの代わりではありません
ここは最初に整理しておくと混乱しにくいです。
Functionの役割
- 同じ処理を何度も呼びたいときに向いています
- 戻り値を返したいときに向いています
- 処理を部品として再利用したいときに向いています
Custom Eventの役割
- イベントの入口を作りたいときに向いています
- Server / Client / Multicast などのRPCにしたいときに向いています
- タイマーや待機処理など、イベントフローの起点にしたいときに向いています
Collapsed Graphの役割
- その場の長い処理を見やすくまとめたいときに向いています
- 一回しか使わない流れを整理したいときに向いています
- Event Graph上の手順を、ひとかたまりとして見せたいときに向いています
つまり、Collapsed GraphはFunctionやCustom Eventそもそも役割が違うというのが正確です。
それでもCollapsed Graphを使う利点はあるのか
あります。ただし、その利点は「強い機能がある」ことではなく、既存のBlueprintを整理しやすいことにあります。
1. すでにあるノード群をそのまま畳みやすいです
Collapsed Graphは、作ってしまったノード列を選択して、そのまま折りたためるのが大きな利点です。
最初から完璧にFunctionへ切り出すのは、初心者ほど難しくなりやすいです。まず動くものを作ってから、流れの単位で整理したいときにCollapsed Graphは使いやすいです。
2. その場所専用の処理をまとめやすいです
Functionは再利用を前提にした部品化に向いていますが、Blueprintには「このイベントの中でしか使わない処理」も多くあります。
たとえば、BeginPlayの中でしか意味を持たない初期化チェックや、その場限りの分岐処理は、無理にFunction化しなくてもよいことがあります。そういう処理をしまう箱としてCollapsed Graphは自然です。
3. “計算の部品”ではなく“手順のかたまり”として見せやすいです
Blueprintでは、処理の中身だけでなく、流れがどうなっているかも非常に重要です。
Collapsed Graphは、何かを計算して返す部品というよりも、このイベントの中の一連の手順をまとめるのに向いています。
実例：BeginPlayで参照を初期化する流れ
Collapsed Graphの使いどころは、実例で見るとかなり分かりやすくなります。
たとえば、DefensiveComponentのBeginPlayで、Ownerから必要なコンポーネント参照を拾って保存する処理を考えます。流れとしては次のようなものです。
- BeginPlayで初期化を開始する
- Ownerを取得する
- OwnerがAIかどうかを判定する
- AIなら必要なセットアップが終わっているか確認する
- 未完了ならタイマーで再試行する
- 準備完了後に必要コンポーネントを保存する
このような流れは、ひとことで言えば「安全に参照を初期化する処理」です。
外から見たときは1つのまとまりとして読みたいですが、中身は分岐や再試行があって少し複雑です。こういうときにCollapsed Graphが向いています。
この例での役割分担
この実例では、役割を次のように分けると理解しやすいです。
Collapsed Graph：StoreComponentsWithCheck
こちらは保存前の安全確認をする流れです。
- Ownerを取得する
- AIかどうかを判定する
- AIならセットアップ完了を確認する
- 未完了ならタイマーを張って再試行する
- 準備できたら保存処理を呼ぶ
このCollapsed Graphの中では、Custom Eventが再試行用の入口として使われています。
具体的には、AIのセットアップがまだ終わっていない場合に Set Timer by Event でタイマーを設定し、その呼び出し先として ComponentsSetup というCustom Eventを使っています。
このCustom Eventは、一定間隔でもう一度セットアップ完了を確認するための再チェック処理です。条件を満たしたらタイマーを止めて、最後に StoreComponents を呼び出します。
Function：StoreComponents
こちらは実際に参照を保存する処理本体です。
- Ownerから各コンポーネントを取得する
- 取得した参照を変数に保存する
- Character参照やMesh参照も保存する
この分け方にすると、チェックと保存の責務が分かれます。Blueprintとしても読みやすい構成です。
なぜこの流れはFunctionだけでまとめにくいのか
ここが、Collapsed Graphを使う理由として一番大事な部分です。
この初期化フローには、次の3つが含まれています。
- Set Timer by Event
- Custom Event
- 再試行フロー
これらが入ると、処理がその場で最後まで終わる1本線ではなくなります。これがFunctionと相性が悪い理由です。
Functionは「呼ばれて、その場で最後まで終わる処理」に向いています
Functionは、呼ばれたら上から下へ実行され、その場で処理が終わって呼び出し元へ戻る、という形が得意です。
たとえば、Ownerからコンポーネントを取得して変数に保存するだけなら、これはFunction向きです。呼ばれた瞬間に最後まで処理できるからです。
Set Timer by Eventは「あとで別タイミングに呼ぶ予約」です
一方で、Set Timer by Eventは、その場で最後まで処理するためのノードではありません。未来のタイミングで別のイベントを呼ぶ予約です。
つまり、Functionの中でこれを使うと、そのFunctionはその場で完結しません。本当にやりたい続きは、あとで別の入口から動くことになります。
その結果、Functionの中に処理全体がきれいに収まりにくくなります。
Custom Eventは「別の入口」です
Custom Eventは、Blueprint内の別入口として使うノードです。タイマーから呼ばれる受け皿としてもよく使います。
今回のように、「未準備ならタイマーを張る → 0.01秒後にもう一回確認する」という流れでは、再確認の入口としてCustom Eventが自然です。
ただし、ここで重要なのは、Functionの中にはCustom Eventを置けないという点です。
そのため、再試行の入口を持つこの種の処理は、Functionグラフだけでは閉じにくく、Event GraphやCollapsed Graphに置いたほうが自然になります。
再試行フローは複数フレームにまたがる処理です
再試行フローは、1回呼んで終わる処理ではありません。
- 今チェックする
- だめなら待つ
- 次のタイミングでもう一度チェックする
- 条件が満たされるまで繰り返す
これは、即時実行の部品というより、イベント駆動の手順です。だから、Function1本に押し込むより、Collapsed Graphでひとかたまりとして見せるほうが理解しやすくなります。
この例でCollapsed Graphが自然な理由
今回の初期化フローでは、Collapsed Graphを使う理由がかなりはっきりしています。
- BeginPlayにぶら下がる、その場専用の流れであること
- AIかどうかの分岐があること
- タイマーによる再試行があること
- 再確認用のCustom Eventが必要なこと
- 最終的な保存処理は別のFunctionに分けられていること
つまり、流れの制御はCollapsed Graph、即時実行の保存処理はFunction、という役割分担になっています。これはBlueprintとしてかなり自然な切り方です。
では、どこまでFunctionに切り出せるのか
ここで大事なのは、「Collapsed Graphを使うならFunctionは不要」という話ではないことです。
今回のような再試行フロー全体はFunction1本にまとめにくいですが、その中に含まれる判定処理や保存処理の一部はFunctionへ切り出せます。
たとえば、次のような分け方なら整理しやすいです。
- Function：準備完了しているか判定する
- Function：実際に参照を保存する
- Custom Event：タイマーから呼ばれる再確認の入口にする
- Collapsed Graph：初回判定から再試行、成功時の保存呼び出しまでをまとめる
このように考えると、Function化できる部分はFunction化しつつ、イベント駆動の流れはイベント側に残すという整理がしやすくなります。
初心者向けの判断基準
迷ったときは、次の順番で考えると分かりやすいです。
1. これはRPCやイベントの入口ですか
はいなら、Custom Eventが向いています。
2. これは同じ処理を何度も使いますか
はいなら、Functionが向いています。
3. これはその場の長い流れを見やすくしたいだけですか
はいなら、Collapsed Graphが向いています。
この順番で考えると、役割をかなり整理しやすくなります。
ネットワーク処理とは別に考える必要があります
もうひとつ大事なのは、Collapsed Graph自体にはネットワーク機能がないということです。
Collapsed Graphはあくまで整理のための箱です。Server / Client / Multicast / RepNotify のような仕組みを持っているわけではありません。
そのため、マルチプレイ前提のプロジェクトでは、次のような重要処理は外から見える形で管理したほうが安全です。
- Authority判定
- Server RPCの入口
- RepNotifyで反映する変数
- アイテム付与やダメージ確定などの結果確定処理
Collapsed Graphの中に何でも隠してしまうと、どこでサーバー確定しているのか分かりにくくなります。整理のために使う機能ですが、重要な責務の境界まで隠しすぎないことが大切です。
まとめ
Collapsed Graphは、FunctionやCustom Eventの代わりになるものではありません。
- 再利用したいならFunction
- イベント入口やRPCにしたいならCustom Event
- その場の流れを読みやすくまとめたいならCollapsed Graph
特に、タイマー、Custom Event、再試行フローのように、その場で完結しないイベント駆動の処理が入ってくると、Functionだけではきれいに閉じにくくなります。
そのようなとき、Collapsed Graphは「再利用のための部品」ではなく、イベントフローを分かりやすく見せるための整理用の箱としてとても有効です。
Blueprintが長くなってきたときは、まずCollapsed Graphで流れを整える。そのうえで、再利用が見えてきた部分だけFunctionへ切り出す。この考え方で進めると、初心者でもかなり扱いやすくなります。
