【デバッグ強化】Unityのコンソールログを活用して効率的にバグを特定する方法

はじめに

Unityで開発をしていると、
「エラーは出ているけど、どこを直せばいいかわからない」
「Debug.Logは出しているのに、原因特定に時間がかかる」
こんな経験、ありませんか？

実はこれ、ログを出していないからではなく、ログの使い方が整理されていないことが原因なケースがとても多いです。

UnityのConsoleログは、ただのメッセージ表示欄ではありません。
使い方を理解すれば、「どこで・何が起きているか」を一瞬で把握できる、デバッグ最強の武器になります。

この記事では、

• Debug.Log / Warning / Errorの正しい使い分け
• Consoleウィンドウで見るべきポイント
• 初心者がやりがちなログの失敗例
• 実務でも使えるログ設計の考え方

を、順番に解説していきます 🙂

「とりあえずログを出す」状態から一歩進んで、
ログを使って最短でバグを潰せる状態を目指していきましょう。

---

結論：デバッグが速くなる人のログの共通点

先に結論から言うと、デバッグが速い人は「ログを出す」よりも、ログを設計しています。

• Debug.Log / Warning / Error を役割で使い分けている（＝重要度がひと目で分かる）
• Consoleを「眺める場所」ではなく「絞り込む道具」として使っている（＝探す時間が減る）
• ログは“後で消す前提”で出している（＝出しっぱなし地獄にならない）

逆に、デバッグに時間がかかるときは「情報が足りない」より、情報が多すぎて埋もれていることがほとんどなんですよね。

---

Unityコンソールの役割と「見るべきポイント」

まず大前提として、UnityのConsoleウィンドウはログを一覧で眺める場所ではありません。

Consoleの本当の役割は、
「問題が起きた場所へ一気にジャンプするための入口」です。

そのため、Consoleを開いたら最初に見るべきなのは――
ログの量ではなく、どこで壊れているかなんですね。

まずは「赤いエラー」から確認する

Consoleにエラー（赤色）が出ている場合は、基本的に他のログは一旦無視してOKです。

エラーは「この処理は正常に動いていません」というUnityからの明確なサインなので、
ここを放置したまま別のDebug.Logを追っても、遠回りになりがちです。

エラーログをクリックすると、スタックトレースが表示されます。
この中にあるスクリプト名や行番号をクリックすれば、原因箇所に直接ジャンプできます。

「エラー文は読んでいるけど、意味がよくわからない…」という場合は、
以下の記事で、初心者がつまずきやすいエラーの読み解き方を詳しく解説しています。

スタックトレースは「一番上」だけ見ればいい

スタックトレースはずらっと行が並びますが、
最初は一番上の自分のスクリプトだけを見れば大丈夫です。

UnityEngineやSystemから始まる行は、Unity内部の処理なので、
初心者のうちは深追いしなくてOKです。

まずは、

• どのスクリプトで
• どの行で
• 何が起きたか

---

Debug.Log / Warning / Error の正しい使い分け

「ログは全部Debug.Logで出している」という方、実はかなり多いです。

でも、Unityには最初から役割の違う3種類のログが用意されています。
ここを使い分けられるようになるだけで、Consoleの見やすさが一気に変わります。

Debug.Log：処理の流れ・状態確認用

Debug.Logは、「今ここを通っているか」「変数の中身は何か」を確認するためのログです。

たとえば、

• 関数が呼ばれているか
• if文のどちらに入ったか
• 数値が想定通りか

といった正常系の確認に向いています。

逆に、処理が止まる・ゲームが進まないような状況をDebug.Logだけで流してしまうと、
重要な情報が他のログに埋もれてしまいます。

Debug.LogWarning：放置すると危険な状態

Warningは、今すぐ致命的ではないけど、想定外な状態を知らせるためのログです。

たとえば、

• nullではない想定だが、一部の条件で空になる
• 設定ミスがあるが、処理自体は継続できている

黄色で表示されるので、
「今は動いているけど、あとで直す必要がある箇所」がひと目で分かります。

Debug.LogError：必ず直すべき致命的な問題

Errorは、処理が破綻している状態を示します。

このログが出ている場合は、
他のDebug.Logを追う前に、まずErrorを潰すのが鉄則です。

初心者の方がやりがちなのが、
Error相当の内容をDebug.Logで出してしまい、赤ログが一切出ない状態にすること。

これだとConsoleを見たときに「何が一番ヤバいのか」が分からなくなってしまいます。

---

「読めるログ」を出すための実践テクニック

「ログは出ているのに、後から見返すと意味がわからない」
これも、かなりよくある悩みです。

原因はシンプルで、ログが“自分にしか分からない書き方”になっていることがほとんどなんですね。

ここでは、Consoleを開いた瞬間に状況が理解できる、
実務でもそのまま使えるログの書き方を紹介します。

変数の値は「何の値か」まで書く

よくあるNG例がこちらです。

Debug.Log(score);

これ、出した瞬間は分かっても、
ログが10行、20行と並んだあとでは「これ何の数値だっけ？」となりがちです。

おすすめなのは、文字列補間を使って意味を一緒に出すことです。

Debug.Log($"Score: {score}");

これだけで、Console上での可読性が大きく変わります。

Contextを指定して「どのオブジェクトか」を即特定する

Debug.Logには、第2引数としてContextを渡せるのをご存じでしょうか？

Debug.Log("Enemy damaged", gameObject);

このように書くと、Console上のログをクリックしたときに、
該当するGameObjectがHierarchy上で自動的に選択されます。

オブジェクトが大量にあるシーンでは、
これだけで「どれが原因か探す時間」がほぼゼロになります。

重要なログは“目立たせる”

UnityのConsoleは、リッチテキストに対応しています。

たとえば、

Debug.Log("<color=red>HPが0になりました</color>");

このように色を付けるだけでも、
大量のログの中から重要なものを一瞬で見つけられます。

すべてを派手にする必要はありませんが、
「ここは必ず見たい」というログだけ装飾するのがコツです。

---

Consoleウィンドウを使いこなして“探す時間”を減らす

ログの出し方を整えても、Consoleの使い方が雑なままだと、
「情報はあるのに見つけられない」状態になってしまいます。

ここでは、大量のログの中から必要な情報だけを一瞬で拾うための、
Consoleウィンドウの実践的な使い方をまとめます。

Log / Warning / Error のフィルタは必ず使う

Console右上にある「Log」「Warning」「Error」のトグルは、
飾りではなく最重要機能です。

基本ルールはとてもシンプルで、

• 問題が起きたら Error（赤）だけON
• 挙動が怪しいときは Warningを追加
• 流れ確認は Logを必要なときだけ

この順番を意識するだけで、Consoleは一気に見やすくなります。

検索バーは「ログのタグ探し」に使う

Console上部の検索バーは、
スクリプト名・タグ・キーワードで絞り込むための機能です。

たとえば、

• [Player]
• [AI]
• [Sound]

のようなタグをログに含めておくと、
関連ログだけを瞬時に抽出できます。

Collapseは「異常検知」に使う

CollapseをONにすると、同じ内容のログが1行にまとまります。

毎フレーム同じログが出ている場合、
CollapseをONにした瞬間に異常な回数が一気に可視化されます。

「何かが暴走しているかも？」という検知にとても便利です。

Error Pauseで“壊れた瞬間”を捕まえる

Error PauseをONにしておくと、
Debug.LogErrorが出た瞬間に再生が一時停止します。

これにより、

• どのオブジェクトが
• どの位置で
• どんな状態だったか

を、その場で確認できます。

「原因は分からないけど、突然動かなくなる」というケースでは、
まずError PauseをONにしてみてください。

Console操作とあわせて、
「そもそもゲームが動かない・進まない」原因を体系的に切り分けたい場合は、
こちらの記事も参考になります。

---

ログだけに頼らない高度なデバッグ手法

数値や文字のログだけでは、
「結局、今シーンで何が起きているの？」とイメージしづらい場面も多いですよね。

そんなときに役立つのが、UnityのDebugクラスが持つ“止める・検証する・可視化する”機能です。

Debug.Assertで「前提条件」をコードに残す

Debug.Assertは、「本来こうなっているはず」という前提をチェックするための機能です。

Debug.Assert(target != null, "targetがnullです");

このように書いておくと、条件が満たされなかった瞬間にエラーとして通知されます。

特に、

• nullになってはいけない参照
• 範囲外になってはいけない数値

などは、Assertで明示しておくとバグの早期発見につながります。

Debug.Breakで「その瞬間」に止める

Debug.Breakを呼び出すと、
スクリプトから強制的にエディタの再生を一時停止できます。

「この処理が走った直後の状態を見たい」
「特定条件に入った瞬間を確認したい」
そんなときにとても便利です。

IDEのブレークポイントがうまく使えない場合の、
保険的な手段として覚えておくと役立ちます。

Debug.DrawLine / DrawRayで“見える化”する

Raycastや方向判定などは、
数値ログだけ見ていても原因が分かりにくいことが多いです。

そんなときは、

• Debug.DrawLine
• Debug.DrawRay

を使って、Sceneビュー上に直接描画してしまうのが一番早いです。

「当たっていると思っていたRayが、実は全然違う方向を向いていた」
なんてことも、一目で気づけます。

デバッグの“見える化”については、
以下の記事でより実践的にまとめています。

---

実務で差がつくログ設計と整理の考え方

ここまでで、Consoleの見方やログの出し方はかなり整ってきたと思います。
ただ、もう一段レベルを上げるために大事なのが、「ログは一時的なコード」という意識です。

実務や長期開発では、
ログをどう出すかよりも、どう整理して消すかで差がつきます。

Update内でログを出さない、が基本

まず覚えておいてほしいのが、
Update内でのDebug.Logは基本NGという考え方です。

Updateは毎フレーム呼ばれるため、
何気なく置いたログが1秒間に何十回、何百回と出続ける原因になります。

ログが大量に出ると、

• Consoleが埋もれる
• 本当に重要なログが見えなくなる
• エディタの動作が重くなる

と、デバッグ効率が一気に下がってしまいます。

ログは「イベント単位」で出す

実務では、ログは状態変化が起きたタイミングで出すのが基本です。

たとえば、

• 攻撃が当たった瞬間
• シーンが切り替わったとき
• エラー条件に入ったとき

こうした「意味のある瞬間」だけに絞ることで、
Consoleは時系列のメモとして使えるようになります。

タグを付けて「後から探しやすく」する

ログメッセージの先頭に、簡単なタグを付けるのもおすすめです。

Debug.Log("[Player] HPが減少しました");

これだけで、Consoleの検索バーに「Player」と入力すれば、
関連ログだけを一瞬で抽出できます。

小さな工夫ですが、ログが増えてきたときの差はかなり大きいです。

ログは「必ず消す前提」で書く

最後に一番大事な考え方です。

Debug.Logは、最終的に消される運命のコードです。

原因調査が終わったら、

• 不要なログは削除する
• 必要なものだけ残す
• Editor専用にする

この整理をしないまま開発を続けると、
「ログが多すぎて何も分からないプロジェクト」になってしまいます。

---

実機デバッグ・チーム開発で役立つデバッグツール

ここまで紹介してきた方法は、主にUnityエディタ上でのデバッグが中心でした。

ただ、実際の開発ではこんな壁にぶつかることも多いです。

• スマホ実機だとConsoleログが見えない
• Editorでは再現しない不具合が起きる
• チームメンバーから「この操作でバグった」とだけ報告が来る

こうした場面では、ゲーム内でログや状態を確認できる仕組みがあるかどうかで、
デバッグ効率が文字通り桁違いになります。

ゲーム内コンソールを導入するメリット

ゲーム内コンソール系のツールを使うと、

• 実機でもDebug.Logを確認できる
• プレイヤー操作・状態・エラーをその場で確認できる
• 再現しにくい不具合の原因特定がしやすくなる

「Editorでは問題ないのに、実機だけおかしい」というケースでは、
ほぼ必須レベルの装備だと感じています。

おすすめのデバッグ・ログ拡張アセット

ここでは、導入するだけでデバッグ環境が一段レベルアップするアセットを紹介します。

Debug Toolkit – In Game Console
ゲーム内にコンソールを表示でき、実行中のログ確認やコマンド実行が可能です。

✅アセットストアでチェックする

SRDebugger – Console & Tools On-Device
実機向けデバッグの定番ツールで、ログ確認だけでなく各種デバッグUIも充実しています。

✅アセットストアでチェックする

Extended Debug Logs
ログに追加情報（呼び出し元など）を付与でき、原因追跡をより正確に行えます。

✅アセットストアでチェックする

こうしたツールは「常に必須」ではありませんが、
原因特定に時間がかかるプロジェクトほど、早めに導入した方が結果的に楽になります。

---

よくある誤解・初心者がやりがちなNG例

最後に、デバッグがなかなか楽にならない人がやってしまいがちな、
典型的なNGパターンを整理しておきます。

とりあえずDebug.Logを大量に出す

一番多いのがこのパターンです。

不具合が起きるたびにDebug.Logを追加していくと、
一時的には情報が増えますが、すぐにログの海になります。

結果として、

• 重要なログが埋もれる
• どこから読めばいいか分からない

という状態に陥りがちです。

直ったあともログを放置する

バグが直った瞬間はホッとしますが、
そのままDebug.Logを残し続けるのは危険です。

あとから別の不具合が出たとき、
「今のログなのか、昔の名残なのか分からない」状態になります。

ログは使い捨て。
役目を終えたら、必ず整理する癖をつけましょう。

Errorを無視してLogから見始める

Consoleを開いた瞬間、つい上から順にLogを読んでしまう人も多いです。

でも、Error（赤）が出ている場合は、
それ以外の情報はほぼノイズだと思ってOKです。

赤 → 黄 → 白、の順番を守るだけで、
デバッグの迷子になる回数はかなり減ります。

---

まとめ

UnityのConsoleログは、
「とりあえず出すもの」ではなく、バグ特定を最短にするための道具です。

この記事でお伝えしたポイントを振り返ると、

• ログは役割（Log / Warning / Error）で使い分ける
• Consoleは絞り込み・ジャンプのために使う
• ログは読める形で出し、必ず整理する

この3つを意識するだけで、
デバッグにかかる時間とストレスは確実に減っていきます。

私自身、ログ設計を意識するようになってから、
「原因が分からず数時間ハマる」ことが激減しました。

まずは今日から、
1つのDebug.Logを“読める形”に直すところから始めてみてください 🙂

---

---

参考文献・参考リンク

• Unity公式マニュアル：Consoleウィンドウ
• Unity公式リファレンス：Debug.Log
• Unity公式リファレンス：Debug.LogWarning
• Unity公式リファレンス：Debug.LogError
• Unity公式リファレンス：Debug.Assert
• SAMURAI ENGINEER：Debug.Logの使い方解説
• 【デバッグ強化】Unityのコンソールログを活用して効率的にバグを特定する方法
• UnityのlogMessageReceivedを使ったログ取得
• Qiita：UnityのDebug.Log最適化について
• UnityのDebug.Log最適化メモ
• Unity公式：Debugクラスを使ったQA・デバッグ改善
• Sentry公式ブログ：Unityデバッグのヒントとテクニック
• Unityデバッグ解説動画（YouTube）

---

よくある質問（FAQ）