「スイッチを踏んだら、ドアを開けたい」。やりたいことは単純ですが、スイッチはどうやってドアに「開け」と伝えればよいのでしょうか。アクターが2つ登場した瞬間、UE開発は「通信」の問題になります。
Blueprintの通信手段は主に3つ。 Direct Reference（直通電話） 、 Interface（宛名のいらない手紙） 、 Event Dispatcher（ラジオ放送） です。どれでも動きますが、選び方を間違えると、プロジェクトが育ったときの修正コストが桁違いになります。
この記事では、3方式の違いと使い分けを比喩と図で解説します。最後に「ボタンで橋が架かる仕掛け」を3方式で組む実践も紹介します。
この記事でわかること
- 3方式の本質は 「直通・手紙・放送」
- 結合度 で選ぶ考え方（相手が固定なら直通、相手が多様なら手紙、相手が不特定なら放送）
- よくある事故（ 全部Direct Reference ・ Unbind忘れ ）の防ぎ方
- 実践：1つの仕掛けで 3方式を適材適所 に使い分ける
全体像：直通・手紙・放送
| 方式 | 比喩 | 結合度 | 主な用途 |
|---|---|---|---|
| Direct Reference | 直通電話 | 高い（密結合） | 特定の1体との固定的なやり取り |
| Interface | 宛名のいらない手紙 | 低い（疎結合） | 「同じ頼みごと」を多様な相手へ |
| Event Dispatcher | ラジオ放送 | 最も低い | 不特定多数への一斉通知 |
覚え方はシンプルで、 相手が固定なら直通、相手が多様なら手紙、相手が不特定なら放送 です。それぞれ順に見ていきましょう。
Direct Reference：決まった相手との直通電話
最もシンプルな方法です。相手のアクターへの 参照（Reference）を変数に持ち、関数を直接呼びます 。「このドアの、OpenDoorを実行して」という名指しの通話にあたります。
BP_Player のイベントグラフ（変数 TargetDoor: BP_Door型）
Is Valid（TargetDoor） → True → TargetDoor の OpenDoor を呼ぶ
| メリット | デメリット |
|---|---|
| 実装が簡単・処理の流れが追いやすい | 密結合 ：参照先のクラスに縛られる |
| 確実で速い | 相手が変わる・増えると、参照元をすべて修正 |
使いどころは 相手が特定の1体で、構造が固定されている とき（親子関係、レベル内の1対1の対応付けなど）。なお、呼ぶ前の Is Valid チェックは習慣にしてください。相手が破壊済みだった場合のエラーを防げます。
Blueprint Interface：宛名のいらない手紙
Blueprint Interface は「このメッセージを受け取ったら、どう処理するかは受け取り側が決める」という 契約 です。送り手は相手の具体的なクラスを知る必要がありません（疎結合）。
代表例が「インタラクト」。プレイヤーはドア・宝箱・レバーの違いを知らず、目の前の相手にただ Interact の手紙を送ります。開くのか、フタが開くのか、倒れるのかは受け取った側の自由です。
使い方は4ステップです。
- 作る: コンテンツブラウザで Blueprint Interface
BPI_Interactableを作成し、Interact関数を定義 - 実装宣言:
BP_DoorやBP_ChestのClass SettingsでこのInterfaceを追加 - 中身を書く: 各アクターに現れる
Event Interactに、それぞれの反応を書く - 送る: プレイヤー側は相手（Actor型のままでOK）に Messageノード で
Interactを送るだけ
| メリット | デメリット |
|---|---|
| 疎結合 ：相手のクラスを知らずに頼める | Direct Referenceより手順が多い |
| 対応アクターを増やしても送り手は無修正 | 処理が実装先に分散し、追跡がやや複雑 |
補足: Interfaceの関数には戻り値も定義できます（例:
GetInteractionTextで「開ける」「調べる」の表示文字列を返す）。深掘りはBlueprint Interfaceの記事へ。
Event Dispatcher：聴きたい人が聴く放送
Event Dispatcher は「一対多」の通知です。発生源はイベントを 放送（Call） するだけで、誰が聴いているかを知りません。聴きたい側が事前に バインド（受信登録） しておきます。オブザーバーパターンと呼ばれる設計です。
受信側（BP_ScoreUI の BeginPlay）
Bind Event to OnGameOver（発生源の参照が必要） → カスタムイベントを接続
発信側（BP_GameMode）
ゲームオーバー時 → OnGameOver を Call
| メリット | デメリット |
|---|---|
| 1回の放送で 何人でも 受け取れる | バインド／アンバインドの管理が必要 |
| 発信側は受信者を 一切知らない（最も疎結合） | 「誰が聴いているか」が見えず、流れを追いにくいことがある |
「敵を倒した」を、スコアUI・ドロップ生成・実績システムが同時に聴く——このような ゲーム全体に波及するイベント が得意分野です。受信側が破棄されるときは Unbind Event を忘れずに。深掘りはEvent Dispatcherの記事へ。
使い分けのフローチャート
- 相手は特定の1体で、今後も変わらない？ → Yes: Direct Reference（将来増えそうならInterfaceへ）
- 「同じ頼みごと」を、種類の違う複数の相手に送りたい？ → Yes: Interface
- 起きたことを、興味のある全員に知らせたい？ → Yes: Event Dispatcher
よくある事故は3つ——①全部Direct Referenceで済ませて、後から修正コストが爆発する。②Interfaceを実装宣言したのに Event ◯◯ ノードを置き忘れて、手紙が無視される。③Dispatcherのアンバインド忘れで、破棄済みアクターへ放送が届き続ける。
実践：ボタンで橋が架かる仕掛けを3方式で組む
3方式は「どれか1つを選ぶ」ものではなく、 1つの仕掛けの中で共存 します。題材は「ボタンを踏むと橋が架かる」——アクションのギミック、パズルの正解演出、RPGのショートカット解放。この1つの流れに、3方式を適材適所で配置してみましょう。
再現用の準備: BP_FloorButton（床ボタン）、BP_Bridge（橋）、WBP_HUD（UI）の3つを用意し、次の変数とイベントを持たせます。
| 置き場所 | 名前 | 種類 | 設定 |
|---|---|---|---|
BP_FloorButton | TargetBridge | BP_Bridge型の変数 | Instance Editable にチェック（レベル上で相手を指定するため） |
BP_Bridge | Extend | カスタムイベント | 橋を架ける演出（Timelineでの移動など） |
BP_Bridge | OnBridgeExtended | Event Dispatcher | 架かったことを知らせる放送口 |
-
ボタン → 橋：Direct Reference: レベルに置いたボタンを選び、詳細パネルの
Target Bridgeで対応する橋を指定します。 このボタンとこの橋は1対1で固定 なので、直通電話の出番ですBP_FloorButton On Component Begin Overlap（踏み判定のBox） → Is Valid（TargetBridge） Valid → DoOnce → TargetBridge の Extend を呼ぶ ← 名指しの直通DoOnceを挟んでいるので、2回目に踏んでも何も起きません（橋は一度架かれば終わり、が仕様です）。何度も架け直すギミックにするなら、DoOnceの Reset ピンを叩いて再武装します。 -
プレイヤー → ボタン：Interface: 「踏む」だけでなく「調べて起動」もできるようにするなら、
BPI_Interactable（関数Interact）をBP_FloorButtonに実装します。プレイヤー側は相手の型を知らずに手紙を送るだけですBP_Player（Eキーを押したとき） → Line Trace で目の前のActorを取得 → Interact（Message）（Target: ヒットしたActor） ← 相手がボタンでもレバーでもOK BP_FloorButton Event Interact（BPI_Interactable の実装） → TargetBridge の Extend を呼ぶ ← 踏んだときと同じ処理を再利用 -
橋 → みんな：Event Dispatcher: 架かった瞬間に放送します。橋は誰が聴いているか知りません
BP_Bridge Event Extend → Timeline で橋を所定の位置へ移動 → Finished → OnBridgeExtended を Call ← 全方位への放送 WBP_HUD（聴く側） Event Construct → Bind Event to OnBridgeExtended（Target: 橋の参照） Event ピン ← Custom Event: ShowAreaUnlocked ShowAreaUnlocked → 「新エリア解放」テキストを表示
「橋の参照」はどこから来る？ ここが初心者最大のつまずきです。UIが特定の橋をBindするには参照が要りますが、
Get All Actors Of Classで拾い集めるのは避けたいところ。橋が1本だけなら生成時にUIへ渡し、橋が複数あるゲームなら GameStateにベルを1つ置いて、すべての橋がそこへ鳴らす 手が定石です（→ Event Dispatcherの記事 のおまけ「中央Dispatcher」）。
3つを並べると、形の違いがそのまま「つながりの強さ」の違いになっているのが見えます。
Playしてボタンを踏むと、まず橋がTimelineで動き始め、 動き終わった瞬間（Finished後） にUIへ「新エリア解放」が出ます。もし橋が動いている最中に通知が出たなら、OnBridgeExtended のCallをFinishedではなくEvent Extendの直後に繋いでいるサインです。注目してほしいのは 拡張のしやすさの違い です。「ファンファーレも鳴らしたい」と思ったら、オーディオ担当は OnBridgeExtended にBindするだけで済み、 橋のBlueprintには一切触りません 。もし全部をDirect Referenceで組んでいたら、橋がUI・音・実績を名指しで知る羽目になり、橋のBlueprintは触るたびに壊れ物になっていきます。
ポイントは2つです。
- 「知る必要があるか」で選ぶ: ボタンは橋を知るべき（1対1の仕掛け）。橋はUIを知る必要がない（結果の通知）。この線引きがそのまま方式の選択になります
- 迷ったら疎結合側へ: Direct Referenceで書き始めて相手が2種類に増えたら、それはInterfaceかDispatcherへ乗り換えるサインです
おまけ：先に知っておくと良いこと
- Component側の通信も同じ原則: 自作Componentから外への通知もEvent Dispatcherが定石です（→ Blueprint Componentの記事）
- 「全員が知っている場所」は通信不要: ゲーム全体のスコアや状態は、そもそもGameState / PlayerStateという公式の置き場があります。通信で配り回る前に、フレームワークに乗せられないか考えましょう
- Castの多用は第4の（危険な）通信:
Cast To BP_◯◯で相手を特定クラスに変換して呼ぶ方法もありますが、密結合＋メモリ面の欠点があります。詳しくはBlueprint InterfaceとCastingの記事で扱います
まとめ
- Direct Reference＝直通電話: 速くて確実。ただし相手が固定のときだけ
- Interface＝宛名のいらない手紙: 同じ頼みごとを、種類の違う相手へ。受け取り方は相手が決める
- Event Dispatcher＝ラジオ放送: 発信者は放送するだけ。聴きたい人が登録する
- 選択の軸は 「相手を知る必要があるか」 。迷ったら疎結合側へ
次は各論です。Event Dispatcherによるイベント駆動設計で放送の実践パターンを、Blueprint Interfaceで実現する疎結合設計で手紙とCastの使い分けを深掘りしましょう。
あなたのプロジェクトでいちばん最近書いた「アクターからアクターへの連絡」は、直通・手紙・放送のどれでしたか？