数ヶ月前の自分が組んだBlueprintを開くと、ノードが絡み合い、ワイヤーが画面を縦横無尽に走っていて、どこから読めばいいのか分からない。いわゆる スパゲッティコード です。
Blueprintは自由度が高いぶん、放っておくと必ず絡まります。原因は3つあります。①実行ピンをどこからでも繋げてしまう自由さ、②コピペによる重複、③機能追加のたびに1つのグラフへ詰め込む習慣です。この記事では、絡まりをほどく 10のテクニック を「分割・見た目・名前と値」の3系統に整理し、散らかったグラフを15分でリフォームする手順まで解説します。
この記事でわかること
- スパゲッティ化を防ぐ 10のテクニック（分割3・見た目4・名前と値3）
- Rerouteノード と整列ショートカットの実際の操作
- Epic公式が推奨する 命名規則 の本当のポイント
- 実践：散らかったグラフを 「区画→整列→箱詰め」 の順でリフォームする
なぜBlueprintは絡まるのか
整理の目的は美観ではありません。 数ヶ月後の自分は、実質他人 です。その他人が迷わず読める状態を保つことが、機能追加のスピードとバグの少なさに直結します。C++の世界で当たり前の「関数・命名規則・整形」の文化を、Blueprintにも持ち込みましょう。
10のテクニック：3つの系統
| 系統 | テクニック |
|---|---|
| 分割の技 | ①関数化 ②マクロ化 ③Componentへの分割 |
| 見た目の技 | ④コメントボックス ⑤ノード整列 ⑥Rerouteノード ⑦左から右の一方向 |
| 名前と値の技 | ⑧変数の命名規則 ⑨ローカル変数 ⑩マジックナンバーの定数化 |
分割の技（①〜③）
最も効果が大きいのが、ロジックを 適切な単位に切り出す ことです。
- ① 関数化: 「最終ダメージを計算する」「アイテムを検索する」のような 結果を返す処理 はFunctionへ。ローカル変数が使え、デバッグも容易です
- ② マクロ化:
DoOnceやBranchを含む 実行フローの制御パターン はMacroへ。①②の使い分けはFunctionとMacroの違いで扱ったとおり、基本はFunction、時間と分岐だけMacroです - ③ Componentへの分割: 体力・インベントリのような 1つの関心事のまとまり は、そもそも同じグラフに置かず自作Componentへ切り出します。イベントグラフ自体が短くなる、最も根本的な分割です
見た目の技（④〜⑦）
- ④ コメントボックス: ノード群を選択して
Cキーで囲み、 処理の目的 を書きます。「ダメージ処理」ではなく「防御力を考慮した最終ダメージ計算」——目的まで書くのがコツです - ⑤ ノード整列: ノードを複数選択 → 右クリック → Alignment、またはショートカット
Shift + W/S/A/D（上/下/左/右揃え）。これを癖にするだけで見た目は劇的に変わります - ⑥ Rerouteノード: ワイヤーをダブルクリック すると中継点が打てます。交差するワイヤーを直角に迂回させ、線を読める形に保ちます
- ⑦ 左から右の一方向: 実行もデータも、流れは常に 左から右・上から下 へ。逆流するワイヤーが現れたら、それは関数化かRerouteのサインです
名前と値の技（⑧〜⑩）
- ⑧ 変数の命名規則:
Temp1やNewVarは数ヶ月後の他人（＝自分）への嫌がらせです。型を接頭辞で示す流儀（bIsJumping・fMoveSpeedなど）もありますが、 Epic公式の規約で必須とされるのはBooleanのb接頭辞のみ 。どの流儀を選ぶかより、 プロジェクト内で統一する ことが本質です - ⑨ ローカル変数: 関数内でしか使わない中間値はローカル変数に。グラフのピンとワイヤーが減り、意図しない書き換えも防げます（→ Blueprint変数入門）
- ⑩ マジックナンバーの定数化: ノードに直接打ち込まれた
500.0は、3ヶ月後には誰にも意味が分かりません。タワーディフェンスの500.0が射程なのか価格なのか体力なのかは、数字を見ただけでは判別できません。名前付きの変数（MaxRangeなど）にして1箇所で管理すれば、意味も伝わり、調整も1箇所で済みます
実践：散らかったBeginPlayを15分でリフォームする
10の技は、覚えるより 順番に使う のが早道です。題材はどのプロジェクトにも1つはある「何でも詰め込まれたBeginPlay」。たとえば、次の12ノードが直列に繋がった1本を思い浮かべてください。
Event BeginPlay
→ Create Widget → Add to Viewport （UI）
→ Set Health(100) → Set Ammo(30) （ステータス）
→ Play Sound 2D(BGM) （音）
→ Set Timer by Event(自動回復) （ステータス）
→ Spawn System at Location(登場エフェクト) （演出）
→ Set Actor Location(初期位置) → …
リフォームに入る前に、 このBeginPlayが何をしているかを、声に出して30秒で説明 してみてください。言い切れずに詰まったら、それはもう他人のグラフです。リフォームは3手順、部屋の片付けと同じ要領で進めます。ゴールは、上の1 本道を下のような「3つの関数を呼ぶだけの目次」に変えることです。
- 区画する（④）: まずグラフを眺めて、意味のまとまりごとに コメントボックスで囲みます 。上の例なら 「UI」「ステータス」「音と演出」の3枚 に分かれるはずです。この時点ではノードを1つも動かさなくてOK。地図に区画線を引くだけで、全体像が見えてきます
- 整列させる（⑤⑥⑦）: 区画ごとに
Shift + W/A/S/Dで高さと端を揃え、交差したワイヤーにはRerouteの中継点を打ち、流れを左から右の一本道へ。ここまでで「読めるスパゲッティ」になります - 箱詰めする（①〜③）: 各区画を眺めて、「これは毎回使う手続きだ」と思えたら ノード群を選択 → 右クリック → Collapse to Function で関数へ箱詰めします。3枚の 区画はそれぞれ
InitializeUI・InitializeStats・PlayIntroのような動詞の名前の関数になり、BeginPlayは その3つを呼ぶだけ の、目次のようなグラフになります。関数に切り出しておくと、デバッグ時に Step Over でその関数を一気に飛ばせる利点もあります（→ Blueprint Debuggerの記事）
仕上げに一度Playして、リフォーム前と同じ挙動であることを確認しましょう。整理をしても動作は変わらないはずなので、もし変わったらCollapse時のピンの繋ぎ漏れを見直してください。翌日このグラフを開いたとき、目次を読むように全体が頭に入ってくれば、リフォーム成功です。
ポイントは2つです。
- 順番が効率を決める: いきなり関数化から始めると「何をまとめるべきか」で迷います。 区画（意味の発見）→ 整列（流れの確認）→ 箱詰め（分割の実行） の順なら、迷いなく進めます
- リフォームは機能追加の直前が最良のタイミング: 「この辺に新機能を足すぞ」という日こそ、まず15分の掃除を。散らかった場所への増築は、絡まりを加速させるだけです
おまけ：先に知っておくと良いこと
Qキー＝ワイヤーの直線化: ノードを複数選択してQ（Straighten Connections）を押すと、繋がったワイヤーがまっすぐになる位置へノードが微調整されます。⑤の整列とセットで覚えると強力です- Collapse Nodesは「見た目だけ」: 右クリックのCollapse Nodesは折り畳むだけで再利用できません。再利用するなら Collapse to Function / Macro を選びましょう（→ FunctionとMacroの違い）
- 巨大Tickは整理より前に見直す: Event Tickに何でも入っているグラフは、整理の前に「そもそもTickであるべきか」を疑うのが先です（→ Event Tickをやめる設計）
まとめ
10の技は、突き詰めれば3つの心がけです。
- 分割: 関数・マクロ・Componentで、ロジックを小さな単位に切り出す
- 視覚的整理: コメント・整列・Reroute・一方向で、流れを目で追える形に保つ
- 命名: 変数にも数字にも名前を付け、意味を1箇所に集める
そして合言葉は 「数ヶ月後の自分は、他人」 。その他人に優しいグラフは、今日のあなたの開発速度も上げてくれます。
つまずきの先回りにはBlueprintでよくある10のミスも併せてどうぞ。
あなたのプロジェクトでいちばん散らかっているグラフはどれですか？ 今日はそのグラフに、コメントボックスの区画線を3本引くところから始めてみましょう。