Print Stringを1個、2個、3個と足していくうちに、グラフ中がログノードだらけになります。それでも画面を流れる文字は速すぎて、肝心の「その瞬間、値はいくつだったのか」が読み取れません。
ここで使うのが Blueprint Debugger です。ログを撒いて後から痕跡を読むのではなく、 処理をその場で止めて、値を直接のぞき込む 道具で、Print Stringのデバッグ手法の「3つの質問」で怪しい場所まで絞れた後に効きます。この記事では、ブレークポイントの打ち方、ステップ実行3種の使い分け、そして「同じ敵が10体いる中で、どの1体を見るか」を解説します。
この記事でわかること
- Print Stringとの使い分け。痕跡を追うか、その場で止めるか
- ブレークポイントの打ち方と、止まった後に見えるもの
- Step Into / Over / Out の3択の使い分け
- Debug Object で「10体のうちのこの1体」に絞る方法
- 実践：「ダメージが0になる」バグを、止めて・見つけて・直す
Print Stringとの使い分け
どちらもデバッグの道具ですが、性格がまるで違います。
| Print String | Blueprint Debugger | |
|---|---|---|
| やること | 通り道に足跡を残し、あとから読む | 処理を止めて、その時点の値を直接見る |
| 得意 | 「呼ばれたか」「大まかな値」の把握。 ゲームを動かしたまま 観察できる | 1ノードずつの追跡と、値の精査 |
| 苦手 | 大量に出ると読めない。1フレームの中身は追えない | 止まるのでゲームの流れは途切れる |
使い分けはシンプルで、 場所を絞るまではPrint String、絞れたらDebugger です。
そのうえで大事なのが、 デバッガは常に上位互換ではない ということ。連打やUIのフォーカス、タイミングに依存する不具合は、止めた瞬間に条件そのものが変わってしまい、再現しなくなることがあります。「止めると消えるバグ」に出会ったら、素直にログへ戻りましょう。
ブレークポイントを打って止める
デバッグの第一歩は、止めたいノードに ブレークポイント を置くことです。
- 打つ: 止めたいノードを選んで
F9（または右クリック →「ブレークポイントを切り替え」）。ノードの左上に赤い円が付けば設定完了です。 置けるのは実行ピンを持つノード（関数呼び出し、Set、Branchなど）だけで、足し算やGetのような純粋な計算ノードには置けません - 走らせる: そのままPIE（エディタ内プレイ）を開始します
- 止まる: 処理がそのノードに到達した瞬間、Blueprintの実行が一時停止し、Blueprintエディタが前面に出ます
止まったノードは光る枠で示され、 そこまで通ってきた実行の道筋（ワイヤー）にも色が付きます 。「思っていたのと違う分岐を通っていた」——それだけで解決するバグも珍しくありません。止まっている間は時間が凍っているので、慌てずに値を眺めましょう。
赤い丸が黄色くなっていたら: そのブレークポイントは無効な状態です。多くは Compile忘れ が原因なので、まずコンパイルを。アイコンにマウスを乗せると理由が表示されます。
Blueprint Debuggerウィンドウ:
Tools → Debug → Blueprint Debugger（Blueprintエディタ上部のDebugメニューからも可）で開くと、設定中のブレークポイント一覧・ウォッチ中の値・コールスタックが1画面にまとまります。ブレークポイント自体はこのウィンドウを開かなくても機能するので、必要になったときだけで大丈夫です。
ステップ実行：入る・またぐ・出る
止まったあとは、ノードを1つずつ進めながら観察します。 ステップ操作はブレーク中だけ有効 です。
| 操作 | 動き | 使いどころ |
|---|---|---|
Step Into（F11） | 次へ進む。関数やマクロなら 中に入る | その中身が怪しいとき |
Step Over（F10） | 次へ進む。関数は 中に入らず結果だけ 受け取る | その関数は信用していいとき |
| Step Out | いまいる関数を 最後まで実行して 、呼び出し元の続きへ戻る | 入ってみたけど無関係だったとき |
| Resume | 次のブレークポイントまで一気に進む | 観察が済んだとき |
Step OutとResumeはツールバーのボタンから実行できます（ショートカットは環境によって割り当てが異なるので、Editor Preferencesのキーボードショートカットで確認・設定してください）。
コツは 「疑わしい関数だけIntoして、それ以外はOver」 。すべてにIntoしていると、共通の関数やマクロ の中へ次々潜って迷子になります。
そして覚えておきたい性質が1つあります。 デバッガは巻き戻せません 。「いま通り過ぎたノードの値を見たかった」というときは、その手前にブレークポイントを追加して、 もう一度同じ操作をやり直します 。この「見逃したら置き直して再実行」のリズムが、デバッガを使う基本動作です。
値を見る：ピンのホバーとウォッチ
止まっている間、値を見る方法は2つあります。
- ピンにマウスを乗せる: いちばん手軽で、いちばん使います。ノードの入力ピン・出力ピンにカーソルを乗せると値がポップアップし、「渡した引数」と「返ってきた結果」を同時に確認できます。ただし表示されるのは そのノードが直近に実行されたときの値 です。まだ実行されていないノードの出力ピンには、今回の結果は入っていません。「値が出ない」ときは1ステップ進めてから見直してください
- ウォッチに登録する: 変数やピンを右クリック →「値をウォッチ」しておくと、Blueprint Debuggerウィンドウにその値が並びます。何度も止めて同じ変数を見る場面で効きます
Debug Object：どの1体を見るか
Blueprintエディタのツール バーには Debug Object（デバッグ対象）のドロップダウンがあります。ここの挙動を知らないと、あとで必ず混乱します。
- 未選択のまま（既定）: そのBlueprintの どのインスタンスでも ブレークポイントで止まります。敵が10体いれば、最初に処理が走った1体で止まります
- 1体を指名する: PIE中にドロップダウンを開くと、実行中のインスタンス一覧が並びます。ここで選ぶと その個体だけ が観察対象になります
おすすめの順番は 「まず未選択のまま止めてみる → 別の個体でも止まって混ざるようなら名指しする」 。最初から絞ろうとすると、「一覧が空っぽで選べない」（PIE開始前は候補が存在しません）や「選んだのと違う個体を動かしていて止まらない」といった、余計なつまずきを踏みがちです。
実践：「ダメージが0になる」バグを捕まえて直す
道具が揃ったので、1匹 捕まえましょう。題材はPrint Stringの記事と同じ「攻撃は当たっているのにHPが減らない」——あのとき3つの質問で「値がおかしい」ところまでは絞れました。今度は、値がどこで壊れるのかを特定して、直すところまでやります。アクションの斬撃でも、シューティングの弾でも、構図は同じです。
再現用の準備（手元に該当グラフがない方は、これだけ作れば試せます）。敵Blueprint BP_Enemy に、次の変数を用意します。
| 変数名 | 型 | 初期値 | 役割 |
|---|---|---|---|
Health | Float | 100.0 | 敵の体力 |
BaseDamage | Float | 20.0 | 攻撃1回の基礎ダメージ |
DamageMultiplier | Float | 0.0 | 倍率。 この0がわざと仕込んだ不具合 です |
そのうえで、関数1つとイベント1つをこう組みます。グラフはこの形です。
文字で追いたいときは、同じ内容がこう書けます。
Function: CalculateDamage（戻り値: Damage / Float）
→ Multiply（A: BaseDamage, B: DamageMultiplier）
→ Return Node（Damage ← Multiplyの結果）
Event: 攻撃が当たったとき（Event AnyDamage や Overlap など何でも可）
→ CalculateDamage を呼ぶ ← ★ここにブレークポイントを打つ
→ Subtract（A: Health, B: CalculateDamageの戻り値）
→ Set Health（Subtractの結果）
→ Print String（Health を Append して表示）
- 呼び出し側で止める:
CalculateDamageを 呼んでいるノード を選んでF9。関数の中ではなく、呼び出し側に置くのがポイントです - 攻撃して止める: PIEを開始して攻撃を当てると、そのノードで実行が止まります
- 中に入る:
F11（Step Into）でCalculateDamageの中へ。 関数の入口で、渡ってきた値を確認できる 位置に立ちます - 値を追う:
F10で1ステップずつ進めながら、実行済みになったピンをホバーします。BaseDamageは20で正しい値です。ところが乗算の結果は 0 になっています。相方のDamageMultiplierをホバーすると、こちらが0でした。ここが原因です - 直して、確かめる: PIEを止めて
DamageMultiplierを1に修正し、もう一度攻撃。HPが100→80に減れば完了です
Print Stringなら「怪しい箇所にログを挿しては再実行」を何度も繰り返すところが、 止めて、覗いて、直す の一巡で終わりました。
ポイントは2つです。
- ブレークポイントは「症状の1個手前」に置く: HPを減らすSetノードそのものより、その材料を作っている関数呼び出しに置く。原因は必ず症状の上流にあります
- 見逃したら、置き直して再実行: デバッガは巻き戻せません。「もう1つ手前が見たい」と思ったら、ブレークポイントを追加して同じ操作を繰り返します
おまけ：先に知っておくと良いこと
直したら、再発を防ぐテストを1つ足す。 原因を突き止めて直した直後が、そのバグを 再現するテストを書く いちばんのタイミングです。同じ条件を自動テストに落としておけば、二度と同じ場所で踏みません（→ UEの自動テスト入門）。
- PIE中にマウスが取られたら
Shift + F1: ゲームがマウスを掴んでいると、エディタ側のドロップダウンやアクターを操作できません。Shift + F1でカーソルをエディタへ戻せます - Accessed Noneで自動的に止められる: 空の参照を触ったときにデバッガを止める機能があります。
Editor Preferences → Experimental → Blueprintsの Blueprint Break on Exceptions を有効にすると、エラーの発生地点へ直行できます（実験的機能の扱いなので、常用するかはお好みで） - ブレークポ イントは片付ける: 用が済んだら削除するか無効化を。残っていると、後日まったく別の作業中に突然ゲームが止まって「なぜ？」となります。Blueprint Debuggerウィンドウの一覧から一括で見直せます
- Componentの中で止めたいとき: 自作Componentのイベントにもブレークポイントを打てます。その場合のDebug Objectは そのComponentのインスタンス で、所有アクター名を手がかりに選びます（→ Blueprint Componentの記事）
まとめ
- Print Stringは 痕跡を追う 道具、Blueprint Debuggerは その場で止める 道具。場所を絞るまではログ、絞れたらデバッガ。ただし 止めると消えるバグ はログの領分
- F9 で打ち、F11（Into）／F10（Over） で進む。疑わしい関数だけIntoする
- 値は ピンのホバー が最速。表示されないときは、そのノードがまだ実行されていない
- Debug Objectは 未選択なら全個体で止まる 。混ざって困るときだけ名指しする
- デバッガは 巻き戻せない ので、見逃したら置き直して再実行
グラフが複雑すぎてブレークポイントを打つ場所すら決められない、という段階なら、先にBlueprintグラフを整理する10のテクニックで見通しを良くするのが近道です。そもそも踏みやすい地雷を知りたい方はBlueprintでよくある10のミスへ。
いまあなたが「なぜか動かない」と思っている処理。次に開いたら、ログを1個足す前に、その処理を呼んでいるノードで F9 を押してみませんか？