この記事の要点

Cast To ノードは「オブジェクトが特定クラス（か派生）かどうか」を判定して、そのクラスとして扱うためのノード 1 回のキャストで判定できるのは 1 クラスのみ。複数クラスを扱うには 3 つのアプローチがある 方法 1: 連続キャスト — シンプルだがクラスが増えると失敗側のラインが伸びる 方法 2: 共通親クラス — もっとも素直。ダメージ可能 / 拾える 等の軸に親を作る 方法 3: Blueprint Interface — 継承の縛りなしに「契約」だけ共有。多軸の能力を持たせたいときに最強

Cast To とは

Cast To は Blueprint で「このオブジェクトは X クラス（およびその派生）として扱えるか」をチェックし、扱えるならその型として参照を返してくれるノードです。よくある使い方は次の流れです。

1. Hit Result や Overlap イベントから Other Actor を取得
2. Cast To MyCharacter に流す
3. 成功側ピンで MyCharacter の関数（TakeDamage 等）を呼ぶ
4. 失敗側ピンは何もしない（または別処理）

制約：Cast To は 1 クラス専用

1 つの Cast To ノードで判定できるクラスは 1 つだけです。たとえば「敵キャラ MyEnemy でも、味方 NPC MyAlly でも、それぞれ別処理をしたい」となると、Cast To だけでは表現に無理が出てきます。

本記事ではこのケースに対する 3 つの方法を比較します。

方法 1：連続キャストで分岐

もっとも直接的な方法は、Cast To を縦に並べることです。

Event Actor Begin Overlap
  ↓
Cast To MyCharacter
  ├─ Success → MyCharacter の処理
  └─ Failed  → Cast To MyEnemy
                ├─ Success → MyEnemy の処理
                └─ Failed  → Cast To MyItem
                              ├─ Success → MyItem の処理
                              └─ Failed  → 何もしない

長所

• 追加クラスが 1〜2 個なら一番手早い
• クラスごとに独自処理を書ける

短所

• クラスが増えるとノードグラフが下に長くなる
• 判定順に依存（先に書いたクラスが優先される）
• クラスを増やすたびにグラフを書き換える必要があり保守性が悪い

方法 2：共通親クラス（Base Class）を作る

UE5 のオブジェクト指向設計を活かす方法です。複数クラスに共通する「軸」（ダメージを受ける、拾える、調べられる…）ごとに 親クラスを作り、子クラスがそれを継承します。

親クラス例	共通処理	子クラス例
BaseDamageable	TakeDamage, OnDeath	MyCharacter, MyEnemy, BreakableObject
BasePickup	OnPickedUp	HealthPotion, AmmoBox, Coin
BaseInteractable	OnInteract	Door, Lever, NPC

Event Actor Begin Overlap
  ↓
Cast To BaseDamageable
  ├─ Success → ApplyDamage(50)   (子クラスでオーバーライド可)
  └─ Failed  → 何もしない

長所

• Cast To は 1 個で済む
• 子クラスを増やしてもグラフは変えずに済む（OOP の継承）
• 関数オーバーライドで子ごとに挙動を変えられる

短所

• クラス階層を後から再設計するのが大変
• 「ダメージも受けるしアイテムでもある樽」のように多軸の能力には弱い（多重継承不可）

方法 3：Blueprint Interface を使う

もっとも柔軟なのが Blueprint Interface（BPI）です。インターフェースは「この関数を持っている」という契約だけを定義し、実装側は継承関係に関係なく好きに採用できます。

手順

1. コンテンツブラウザで「Blueprints → Blueprint Interface」を新規作成（例: BPI_Damageable）
2. インターフェース内で関数シグネチャを定義（例: TakeDamage(Damage : float)）
3. 採用したい各 Blueprint（MyCharacter, MyEnemy, BreakableObject）で「クラス設定 → インターフェース → 追加」
4. 各クラスで TakeDamage イベントを実装

呼び出し側

Event Hit
  ↓
Does Implement Interface (BPI_Damageable)
  ├─ True  → TakeDamage (Interface Call) を呼ぶ
  └─ False → 何もしない

または直接 TakeDamage (Message) を呼ぶことも可能で、対象がインターフェースを実装していなければ何も起きない安全な呼び出しになります。

長所

• 継承関係が不要。階層がフラットになる
• 1 クラスで複数のインターフェースを実装できる（多軸）
• Cast To よりパフォーマンスがやや有利（型解決が軽い）

短所

• インターフェース宣言と実装が分散するため、関数の所在を辿りづらい
• 戻り値が複雑な型の場合、デフォルト値の扱いに注意

3 方式の比較

観点	連続 Cast	共通親クラス	Blueprint Interface
実装の手軽さ	◎	○	△（事前準備が要る）
クラス追加時の改修	×（毎回修正）	○（子追加だけ）	◎（採用するだけ）
多軸の能力	○	×（多重継承不可）	◎
パフォーマンス	△（キャスト連鎖）	○	◎
可読性	○（局所的に見える）	◎（親に集約）	△（分散）
向く場面	クラスが 2〜3 個	明確な階層	横断的な能力

実務での選び方

• クラスが 2〜3 個で固定、追加予定なし → 連続 Cast で OK
• 「ダメージを受ける」「拾える」など軸が明確 → 共通親クラスから始める
• 「樽は壊せるしダメージも受ける」のように能力が交差する → Blueprint Interfaceに切り替え
• 大規模プロジェクトでは親クラス＋インターフェースの併用が定石

パフォーマンスの目安

Cast To は内部的に動的型チェック（IsA）を行うため、毎フレーム数千回呼ぶような状況では負荷になります。次の使い分けが目安です。

頻度	推奨
イベント駆動（オーバーラップ・ヒット）	Cast To で問題なし
毎フレーム数百回以上	インターフェース呼び出しに切替
BeginPlay などで 1 回だけ	Cast To で OK、参照を変数にキャッシュ

関連

• プロジェクトを多言語化する方法
• RInterp To
• ブループリントで現在日時を取得する方法
• Event ActorBeginOverlap と On Component Begin Overlap の違い