チュートリアルどおりにLevel Blueprintへ処理を書いていたら、いつの間にかゲームの中身がほとんどLevel Blueprintに詰まっていた。そして新しいレベルを作った瞬間、全部動かなくなった。UE初心者が一度は通る道です。
UEには、ロジックを書ける場所が大きく2つあります。 Level Blueprint は「そのレベル専用の台本」、 Blueprint Class は「どこでも使い回せる部品の設計図」です。この違いを知らずに書く場所を間違えると、コピペ地獄が待っています。この記事では、2つの違いと黄金律 「モノは部品に、演出はレベルに」 を図解し、最後に「トリガーを踏むと扉が開く」仕掛けを正しい分担で組む方法を解説します。
この記事でわかること
- Level Blueprint＝そのレベル専用の台本 、 Blueprint Class＝使い回せる部品
- 黄金律 「モノは部品に、演出はレベルに」
- Level Blueprintに コアロジックを書いてはいけない 理由
- 実践：トリガーで扉が開く仕掛けを、 Interface も使 って正しく分担する
Level Blueprintとは：そのレベル専用の台本
Level Blueprint は、 特定のレベル（マップ）に1冊だけ紐づく Blueprintです。メインツールバーのBlueprintメニュー →「Open Level Blueprint」で開けます。
- レベルに紐づく: 他のレベルへ持ち出せません。レベルを削除すれば台本ごと消えます
- レベル内のアクターを直接参照でき る: 配置済みのアクターを選択した状態でグラフを右クリックすると、そのアクターへの参照ノードを直接置けます。これは他のBlueprintにはない、Level Blueprintだけの特権です
- 各レベルに1つだけ: 「このレベルの進行台本」として、常に1冊です
得意分野は そのレベル固有の、一度きりの演出や流れ です。レベル開始時のカメラワーク、この部屋のこの扉とこのスイッチの対応付け、レベルクリアの判定——「このマップでしか起きないこと」の台本として使います。
Blueprint Classとは：使い回せる部品の設計図
Blueprint Class は、爆発する樽・拾えるアイテム・動く床のような、 ゲームに何度も登場する「モノ」の設計図 です（→ UE5の基本概念）。
- 再利用できる: どのレベルにも、何個でもインスタンスを配置できます
- カプセル化されている: データ（変数）と振る舞い（イベント・関数）が設計図の中に完結します
- 継承できる:
BP_Barrelを親に「毒ガス樽」の子クラスを作る、といった拡張が可能です
たとえば「攻撃されると爆発する樽」は、樽自身のBlueprint Classにこう書きます。
BP_ExplosiveBarrel（Blueprint Class）
Event AnyDamage
→ Health から Damage を引いて Set
→ Health <= 0 なら → カスタムイベント Explode を呼ぶ
この樽はどのレベルの、どの場所に置いても同じように爆発します。 1回作れば全レベルで使える 。これがBlueprint Classの本質です。
比較と黄金律：モノは部品に、演出はレベルに
| 項目 | Level Blueprint | Blueprint Class |
|---|---|---|
| 役割 | そのレベルの演出・進行の台本 | 再利用可能な「モノ」の設計図 |
| 再利用 | 不可（レベル専用） | 可能（どこでも・何個でも） |
| カプセル化 | 低い（レベル内のアクターに依存） | 高い（設計図内で完結） |
| 継承 | 不可 | 可能 |
| アクター参照 | 配置済みアクターを直接参照できる | 間接的な手段（Overlap・Get All Actors Of Class 等）が必要 |
迷ったら、この黄金律で仕分けてください。
- ゲーム内の「モノ」（樽・扉・敵・アイテム）→ Blueprint Class
- そのレベルの「演出・流れ」（開幕カメラ・クリア判定・一度きりのイベント）→ Level Blueprint
最悪の間違い：コアロジックをLevel Blueprintに書く
初心者が最も踏みやすい地雷が、プレイヤーの体力管理やスコアシステムといった ゲームのコアロジックをLevel Blueprintに書いてしまう ことです。
レベル2を作った瞬間、レベル1の台本から全ロジックをコピペする羽目になり、以後は修正のたびに全レベルの台本を直して回ることになります。ダメージ処理はプレイヤーのBlueprint Classへ、ゲーム進行のルールはGameModeへ。コアロジックには、それぞれふさわしい家があります。
実践：トリガーで扉が開く仕掛けを、正しい分担で組む
黄金律を1つの仕掛けで体験しましょう。題材は「トリガーゾーンを踏むと扉が開く」。ダンジョンの隠し扉、ホラーの自動ドア、パズルの正解ギミック。どのジャンルにもある定番です。分担はこうなります： 扉というモノはBlueprint Class、この部屋のこのトリガーとこの扉の対応付けはLevel Blueprint 。
動かすとこうなります。プレイヤーがトリガーゾーンに入った瞬間、扉が1.5秒かけてせり上がって開く。ゾーンを出てまた入り直しても、扉はもう反応しない。「開き方」は扉が持ち、「いつ開くか」だけをレベルが決めている状態です。
再現条件
手元に何もなくても、この表のとおり作れば試せます。
| 項目 | 設定 |
|---|---|
Trigger Box（レベルに配置） | Box Extent = (100, 100, 100)、Collision Presets = OverlapAllDynamic |
BP_Door のメッシュ | Static Mesh に Cube を割り当て、Scale = (0.2, 1.5, 2.2) で薄い扉型に |
BP_Door の変数 | OpenHeight（Float）= 300.0 |
BP_Door のTimeline | TL_Open、Floatトラック1本、長さ 1.5秒、キーは 0秒=0.0 / 1.5秒=1.0 |
ステップ1：扉を部品として作る（開き方を扉に持たせる）
BP_Door（Blueprint Class・親は Actor）を作り、Static Meshコンポーネント（DoorMesh）で扉の見た目を用意します。そして 開く処理を扉自身のイベント として組みます。
BP_Door（Blueprint Class）
変数: OpenHeight（Float）= 300.0
OpenDoor（Custom Event）
→ TL_Open（Play from Start）
TL_Open（Update） // Alpha は 0 → 1 へ変化
→ Set Relative Location（Target: DoorMesh）
New Location = (0, 0, Lerp(0.0, OpenHeight, Alpha))
OpenDoor を呼ばれると、Timelineが1.5秒かけてAlphaを0から1へ動かし、そのAlphaで扉の高さを0cmから300cmまで補間します。 扉は「開け」と言われたら、自分の開き方でせり上がる 。この部品は、どのレベルに置いても同じように開きます。Timelineノードの詳しい作り方は Timelineノードで滑らかに動かす にあります。
ステップ2：レベルに配置する
BP_Door と Trigger Box をレベルに置きます。トリガーは扉の少し手前に、プレイヤーが通る位置へ。
ステップ3：Level Blueprintで「いつ開くか」だけを配線する
Trigger Boxを選択した状態でLevel Blueprintを開き（メインツールバーのBlueprintメニュー → Open Level Blueprint）、グラフを右クリックして On Actor Begin Overlap イベントを追加します。同じように、配置済みの BP_Door を選んでその参照ノードを置き、繋ぎます。
Level Blueprint（このレベルの台本）
On Actor Begin Overlap（TriggerBox）
→ Cast To ThirdPersonCharacter（Other Actor） // プレイヤーだけに反応させる
→ （成功）DoOnce
→ OpenDoor を呼ぶ（Target: 配置した BP_Door の参照）
Cast To ThirdPersonCharacter を挟むのは、飛んできた小物 や他のアクターでは開かないようにするためです。DoOnce は、ゾーンに入り直すたびに開閉が再発火しないための蓋です（→ FunctionとMacroの違い で作ったCooldownの親戚ですね）。
確かめる
Playしてトリガーゾーンに入ると、扉が 1.5秒かけて300cm（3m）せり上がって 開きます。ゾーンを出てもう一度入っても、DoOnce が働くので 今度は動きません 。うまくいかないときは、扉がまったく動かないなら BP_Door の参照が正しく繋がっているか、誰が触っても開くなら Cast To ThirdPersonCharacter が入っているかを見てください。
ここで注目してほしいのは 役割の線引き です。「どう開くか」（Timelineで300cm上昇）は扉が知っていて、「いつ・どのトリガーで開くか」だけをレベルの台本が知っている。だから同じ BP_Door を別のレベルに置けば、そのレベルの台本で別のトリガー、別のタイミングに配線し直せます。
発展：Interfaceでさらに疎結合に
この配線をもう一段美しくするのが Blueprint Interface です。BPI_Interactable というInterfaceに Interact 関数を定義し、BP_Door に実装させると、Level Blueprint側は 相手の型を知らずに「Interactして」というメッセージを送るだけ で済みます。
扉・宝箱・跳ね橋——「開けられるモノ」が増えても、台本側は同じメッセージを送るだけ。この考え方はアクター間通信の3つの方法とBlueprint Interfaceの記事で本格的に扱います。
ポイントは2つです。
- 「モノの振る舞い」と「レベルの配線」を分ける: 扉が自分の開き方を知っていれば、レベル側の台本は数ノードの配線だけで済みます
- Level Blueprintの直接参照は、便利だが依存: 配置済みアクターを直接参照できるのはLevel Blueprintの特権ですが、その参照はこのレベル限定です。「この便利さはレベルの外へ持ち出せない」と意識して使いましょう
おまけ：先に知っておくと良いこと
- わざと逆をやって、痛みを体感する: 実践の逆版を作ってみてください。扉の開閉ロジックを丸ごとLevel Blueprintに書き（Timelineもレベル側に置く）、そのレベルを複製して、片方の扉の上昇量だけ400cmに変えたくなったとします。修正が2つのレベルに散る瞬間、黄金律が理屈でなく皮膚感覚になります。5分の遠回りが、いちばん確実な理解です
Get All Actors Of Classの誘惑に注意: Blueprint Classから他のアクターを探すときに便利ですが、レベル内の全アクターを走査するため、毎フレーム呼ぶと重くなります。BeginPlayで1回だけ呼んで結果をキャッシュするのが基本です- Level Blueprintのもう1つの出番: レベル間の橋渡しをしない一度きりのカットシーン起動（→ Sequencerでカットシーンを作る）や、Level Streaming のロード指示など、「このマップの進行管理」には今でも現役です
- 迷ったらBlueprint Classに寄せる: 「後でこれ、他のレベルでも使うかも」と一瞬でも思ったら、部品側に作るのが安全です。部品をレベル専用に使うのは簡単ですが、台本を部品化するのは書き直しです
まとめ
| Blueprint | 役割 | 選択の基準 |
|---|---|---|
| Blueprint Class | ゲームの 部品（モノ） | 再利用したい・カプセル化したい振る舞い |
| Level Blueprint | レベルの 台本（演出・配線） | そのレベルでしか起きない流れ・対応付け |
黄金律は 「モノは部品に、演出はレベルに」 。そしてコアロジックは、Level BlueprintでもなくキャラクターのBlueprint ClassやGameModeへ。この仕分けができれば、レベルが10個に増えてもプロジェクトは破綻しません。
部品同士の連携が増えてきたら、次はアクター間通信の3つの方法へ進みましょう。
いまのあなたのLevel Blueprint、開いてみてください。そこに「他のレベルでも使いたくなりそうな処理」は眠っていませんか？