Unityのデバッグ可視化 完全ガイド｜Gizmos・Debug.DrawLine・OnGUIの使い分け実践テク

Unityで開発していると、必ずぶつかるのが「デバッグ、どうやって効率よくやる？」という悩みです。
とりあえず Debug.Log() を仕込んでみたものの、ログが流れすぎて何が起きているのか分からなくなったり、Inspectorを眺めてもピンとこなかったり……心当たり、ありませんか？😅

実はそのモヤモヤ、「デバッグ情報が見えていない」ことが原因かもしれません。
位置・方向・範囲・衝突判定・数値の変化といった情報は、文字で追うよりも視覚的に確認できた方が圧倒的に理解が早いんです。

Unityには、そのための強力な仕組みとして Gizmos、Debug.DrawLine / Debug.DrawRay、OnGUI（IMGUI） といった「デバッグ可視化」の手段が標準で用意されています。

ただし、この3つは何でも同じように使えばいいわけではありません。
Sceneビュー向きなのか、実行中の挙動確認なのか、数値や操作を見たいのか——目的に合わない使い方をすると、逆に分かりづらくなってしまいます。

この記事では、

• Gizmos・Debug.DrawLine・OnGUIそれぞれの役割
• どんな場面で、どれを使うのがベストか
• Debug.Logに頼らない、実践的なデバッグの考え方

を、実例ベースでやさしく整理していきます。

「デバッグがつらい…」から
「あ、今こうなってるんだ！」に変わる感覚、ぜひ体験してみてください。
それでは、まずはデバッグ可視化がなぜ重要なのかから見ていきましょう✨

---

なぜ「デバッグの可視化」が重要なのか

Unity開発に慣れてくるほど、デバッグのやり方がそのまま開発スピードと品質に直結していることに気づきます。
まずは、従来よく使われがちなデバッグ手法が、なぜ限界に来やすいのか整理してみましょう。

Debug.Logに頼りすぎると起きる問題

一番手軽なのは Debug.Log() を使ったデバッグですよね。
変数の値を出したり、処理が通ったか確認したり……最初はとても便利です。

でも、処理が複雑になってくると状況は一変します。

• 毎フレームログが流れて、必要な情報を見失う
• どのオブジェクトのログなのか、区別がつきにくい
• ログ出力自体が増え、パフォーマンスに影響することもある

特に移動処理・物理挙動・AIなどでは、「数値は合っているのに挙動がおかしい」というケースがよくあります。
この状態をログだけで追うのは、正直かなりしんどいです…。

Inspector確認だけでは直感的に理解できない

Inspectorで変数を表示して監視する方法もあります。
[SerializeField] を付けておけば、実行中でも値の変化は確認できますよね。

ただし、この方法にも弱点があります。

• 方向・範囲・距離といった空間的な情報が分かりにくい
• 複数オブジェクトの状態を同時に比較しづらい
• 「今、画面のどこで何が起きているか」が直感的に掴めない

数値は見えているのに、頭の中で状況を再構築しないといけない。
これが、地味に時間を奪うポイントです。

「見える」だけでデバッグは一気に楽になる

そこで効いてくるのがデバッグの可視化です。

例えば、

• Raycastの向きや当たっている位置が線で見える
• 当たり判定や探索範囲がその場で確認できる
• 数値や状態が画面上に常に表示される

こうした情報がリアルタイムで目に入るだけで、

「なるほど、ここが原因か！」

と一瞬で理解できることが増えてきます。
ログを追いかける時間が減り、試行錯誤のテンポも一気に良くなります。

---

Gizmos｜Sceneビューで使う「構造を理解するための可視化」

まず最初に紹介するのが Gizmos です。
Gizmosは、Sceneビュー上に線や図形を描画して、オブジェクトの構造や設定状態を直感的に確認するためのデバッグ可視化手法です。

「このオブジェクト、どの方向を向いているんだっけ？」
「当たり判定のサイズ、本当にこれで合ってる？」
そんな疑問に、ひと目で答えてくれるのがGizmosなんです。

Gizmosの特徴と得意なこと

Gizmosには、次のような特徴があります。

• Sceneビュー向けのデバッグ表示
• エディター専用で、ビルドには含まれない
• 位置・方向・範囲など幾何学的な情報の確認に強い
• オブジェクト単位で表示ON/OFFを切り替えられる

つまりGizmosは、
「今このオブジェクトが、どういう設定・構造になっているか」
を確認するための道具だと考えると分かりやすいです。

Gizmosが特に活躍するシーン

実際の開発では、こんな場面でよく使われます。

• Raycastや視線方向の確認
• 索敵・探索範囲の可視化
• 当たり判定（Collider）のサイズ確認
• 移動ルートや目標地点の把握

これらをログや数値だけで把握しようとすると、かなり大変です。
Gizmosで線やワイヤーフレームを描くだけで、理解スピードが一気に上がります。

Gizmosの基本的な描画方法

Gizmosは、MonoBehaviour内の特定のメソッドで描画します。

• OnDrawGizmos()：常に描画される
• OnDrawGizmosSelected()：オブジェクト選択時のみ描画

例えば、「普段は邪魔だけど、選択中だけ見たい」という情報は OnDrawGizmosSelected() に書くのが定番です。

描画前に Gizmos.color を設定しておくと、
「赤は危険」「緑はOK」といった意味を持たせた可視化もできます。

Gizmosは「設計を理解する」ためのデバッグ

ここで一度、Gizmosの立ち位置を整理しておきましょう。

Gizmosは、

• 実行中の一瞬の挙動を見るものではない
• リアルタイム数値を操作するものでもない

代わりに、

「このオブジェクトは、こういう前提で作られている」

という設計・構造の確認にとても向いています。
だからこそ、デバッグ可視化の最初の一歩として最適なんです。

基礎を体系的に理解したい人へ

Gizmosを使い始めると、
「Unityって、こういうデバッグの仕組みが用意されてるんだ」
と気づく場面が増えてきます。

もし、

• Gizmosを含めたUnityの基本機能を整理して学びたい
• 独学で抜けがないか確認したい

という場合は、基礎から体系的にまとめられている資料を一度通しておくのもおすすめです。

Unityの教科書 Unity 6完全対応版
✅ Amazonでチェックする ｜ ✅ 楽天でチェックする

---

Debug.DrawLine / Debug.DrawRay｜実行中の挙動をその場で確認する

Gizmosが「構造や設定を理解するための可視化」だとしたら、
Debug.DrawLine / Debug.DrawRay は実行中の挙動そのものを確認するためのデバッグ手法です。

「ちゃんとRaycastが飛んでる？」「どこで当たってる？」
そんな疑問に、プレイしながら即答してくれるのがこの方法です。

Debug.DrawLineとGizmosの決定的な違い

まず混乱しやすいポイントを整理しておきましょう。

• Gizmos： Sceneビュー中心・エディター向け
• Debug.DrawLine： Play Mode専用・実行時向け

Debug.DrawLine / DrawRayは、
ゲームを再生している間だけ表示されるというのが最大の特徴です。

動的に変化する情報を見るなら、Gizmosではなくこちらが主役になります。

よく使われるデバッグ例

Debug.DrawLine / DrawRayは、次のような場面で特に活躍します。

• RaycastやSphereCastの方向・距離確認
• 当たり判定の検証
• AIの視線・索敵チェック
• 移動処理や補間の軌跡確認

ログだけだと「当たった／当たってない」しか分からない処理も、
線が見えるだけで理解度が段違いになります。

Debug.DrawLineの基本的な使い方

Debug.DrawLineは、次のような形で使用します。

Debug.DrawLine(startPosition, endPosition, Color.red, 0.0f, true);

• startPosition：開始位置（ワールド座標）
• endPosition：終了位置（ワールド座標）
• Color：ラインの色
• duration：表示時間（0なら1フレーム）
• depthTest：奥のオブジェクトに隠れるかどうか

たとえば、duration を少し長めにすると、
「どういう軌跡で動いているか」を残像のように確認できます。

DrawRayを使うと、さらに分かりやすい

Raycastのデバッグでは、Debug.DrawRay() が定番です。

開始位置と方向ベクトルを渡すだけなので、
「どっちに飛ばしているか」が一瞬で分かります。

Debug.DrawLineは「挙動チェック専用」と割り切る

ここも重要な考え方です。

• 常に表示したい情報 → Gizmos
• 実行中だけ確認したい挙動 → Debug.DrawLine

この切り分けを意識するだけで、
デバッグコードがぐっと整理されます。

DrawLineが増えすぎたときの悩み

便利だからといってDrawLineを増やしていくと、

• どの線が何を意味しているか分からない
• ON/OFFの管理が面倒
• 実験用コードが散らかる

といった別の悩みが出てきます。

---

OnGUI（IMGUI）｜数値・状態・操作をまとめて可視化する

Debug.DrawLineが「挙動を見る」ためのデバッグだとしたら、
OnGUI（IMGUI）は数値や状態を“管理する”ためのデバッグです。

位置や線だけでは分からない、
「今のHPはいくつ？」「このフラグ、ON？OFF？」といった情報を、
画面上に常に表示しながら確認できるのが大きな強みです。

OnGUIが活躍するデバッグシーン

OnGUIは、次のような場面で特に力を発揮します。

• 変数のリアルタイム監視（HP、速度、状態IDなど）
• フラグやモードの切り替え
• 実験用パラメータの操作
• 簡易デバッグメニューの作成

ログを大量に流す代わりに、
「見たい情報だけを1か所に集約する」イメージです。

OnGUIの基本的な仕組み

OnGUIは、MonoBehaviourに次のメソッドを定義するだけで使えます。

void OnGUI()
{
    GUILayout.Label("Speed : " + speed);
}

このメソッドは、GUIイベントごとに複数回呼ばれるという特徴があります。
そのため、重い処理は書かず、表示と操作に専念させるのがコツです。

GUILayoutを使うと配置が一気に楽になる

IMGUIには、GUI と GUILayout の2系統があります。

• GUI： Rectで座標を指定する
• GUILayout： 自動レイアウト

デバッグ用途であれば、
GUILayoutを使うのがおすすめです。

ラベル・ボタン・トグルなどを、
画面サイズを気にせずサクッと並べられます。

簡易デバッグウィンドウの考え方

OnGUIを使うと、
「このデバッグ、どこに書いたっけ？」という問題も減らせます。

ウィンドウ内に、

• 現在の状態表示
• テスト用ボタン
• ON/OFF切り替え

をまとめておけば、
デバッグ専用の操作パネルとして機能します。

OnGUIデバッグが辛くなる瞬間

ただし、OnGUIも万能ではありません。

• 要素が増えるとコードが肥大化しやすい
• 表示ON/OFF管理が煩雑になる
• 複数人開発だと把握しづらい

「ちょっとしたデバッグ」のつもりが、
いつの間にか巨大なOnGUIになっている……というのは、よくある話です。

実行時デバッグを一段階ラクにしたいなら

ここまでOnGUIを使ってきた人ほど、

「これ、もう少し楽に管理できないかな？」

と感じるタイミングが来ます。

そんなときに便利なのが、
ランタイムデバッグを前提に設計されたツールです。

Debugging Essentials
✅ Unity Asset Storeでチェックする

数値表示・切り替え・可視化をまとめて扱えるため、
OnGUIを自作するよりスッキリするケースも多いです。

---

Inspector拡張という別解｜「描かずに見える」デバッグ

ここまで、Gizmos・Debug.DrawLine・OnGUIと、
「描画して可視化する」デバッグ手法を見てきました。

でも実は、もうひとつ有力な選択肢があります。
それが Inspector拡張 です。

「線やGUIを描かなくても、
必要な情報が分かりやすく並んでいればいい」
そんなケースでは、Inspector拡張の方が相性が良いことも多いんです。

Inspectorデバッグのよくある悩み

標準のInspectorだけでデバッグしようとすると、
こんな壁にぶつかりがちです。

• [SerializeField]が増えすぎて探しづらい
• 状態・設定・デバッグ用変数が混在する
• 実行中に変更したい値が埋もれる

「見えてはいるけど、見やすくはない」
これがInspectorデバッグの正直なところです。

Inspectorを整理するだけで理解度が変わる

Inspector拡張を使うと、

• 情報をグループ分けできる
• 実行中だけ表示したい項目を切り替えられる
• ボタンで処理を呼び出せる

といったことが簡単にできるようになります。

結果として、

「今このオブジェクトが、どんな状態なのか」

を、Inspectorを見るだけで把握できるようになります。

Gizmos・OnGUIとInspector拡張の使い分け

ここで、立ち位置を整理しておきましょう。

• Gizmos： 空間構造・範囲の理解
• Debug.DrawLine： 実行中の挙動確認
• OnGUI： 数値・状態・操作
• Inspector拡張： 状態の整理と管理

すべてを描画で解決しようとせず、
「見るだけで足りる情報」はInspectorに任せると、
デバッグ全体がかなりスッキリします。

Inspector拡張を一気に楽にしたいなら

Inspector拡張を自前で作ることもできますが、
正直なところ、作り込み始めると時間が溶けやすいです。

そこで定番なのが、
Inspector拡張を前提に設計されたアセットです。

Odin Inspector
✅ Unity Asset Storeでチェックする

情報整理・実行中デバッグ・開発効率の底上げまでカバーできるため、
中〜大規模プロジェクトほど効果を実感しやすいです。

---

3つの可視化手法の使い分け早見表

ここまで、Gizmos・Debug.DrawLine / Debug.DrawRay・OnGUI、そしてInspector拡張を見てきました。
それぞれ理解すると、「で、結局どれを使えばいいの？」と迷いやすくなります。

そこでこの章では、
目的別に一発で判断できる早見表として整理します。

可視化手法の比較表

手法	主な用途	表示タイミング	向いているケース
Gizmos	構造・範囲の確認	Editor（Sceneビュー）	当たり判定、探索範囲、向きの確認
Debug.DrawLine / DrawRay	挙動の可視化	Play Mode中	Raycast、衝突、移動・AI挙動
OnGUI（IMGUI）	数値・状態・操作	Play Mode中	変数監視、フラグ切替、実験用UI
Inspector拡張	状態管理・整理	Editor / Play Mode	大量の変数、状態の俯瞰

迷ったときの判断フロー

「どれを使うか分からない」ときは、次の順番で考えるとスムーズです。

• 空間的な情報？ → Gizmos
• 実行中の挙動？ → Debug.DrawLine / DrawRay
• 数値や状態を見たい・操作したい？ → OnGUI
• 整理して確認したいだけ？ → Inspector拡張

無理に1つで完結させる必要はありません。
目的ごとに役割を分担させるのが、デバッグを楽にするコツです。

「全部盛り」にしないのがコツ

デバッグ可視化でよくある失敗が、
「便利だから」と全部を常時表示してしまうことです。

• 線が多すぎて何が重要か分からない
• デバッグUIが画面を占領する
• 後から見た自分が理解できない

---

まとめ｜「見えるデバッグ」が開発効率を変える

Unityのデバッグは、
「とりあえずDebug.Logを仕込む」だけでは、どうしても限界があります。

この記事で紹介してきたように、

• Gizmos： 構造や範囲を理解する
• Debug.DrawLine / DrawRay： 実行中の挙動を確認する
• OnGUI： 数値・状態・操作をまとめて管理する
• Inspector拡張： 情報を整理して俯瞰する

それぞれ役割がはっきり分かれています。

大切なのは、
「どれか1つに頼ること」ではなく「目的に合わせて使い分けること」です。

私自身も、以前はログだらけのデバッグで遠回りしていましたが、
可視化を取り入れてからは

「あ、原因これだ」

と気づくまでの時間が、はっきり短くなりました。

デバッグは地味な作業に見えますが、
実は開発効率と品質を一気に引き上げる伸びしろでもあります。

今回紹介した手法の中から、
まずは1つでも取り入れてみてください。
それだけで、Unity開発のストレスはかなり減るはずです。

---

あわせて読みたい

デバッグ可視化を理解したあとに読んでおくと、
Unity開発全体の見通しがさらに良くなる記事をまとめました。

• 【Unity最適化】Updateを減らしてゲームのパフォーマンスを向上させる方法
• 【徹底解説】Unityのガベージコレクション(GC)を最適化して処理落ちを防ぐ方法
• Unity初心者向け｜読みやすいコードを書く7つのコツ
• Unityのエラーを解決！初心者がよくつまずくポイントと対処法
• Unityで最適化をマスター！軽量でスムーズなゲームを作る方法

デバッグは「不具合を直す作業」だけではなく、
コードの書き方・設計・最適化とも深くつながっています。

気になるテーマから、ぜひ続けて読んでみてください。

---

よくある質問（FAQ）