Excel VBAでマクロを作成・修正していると、
次のような場面に必ず遭遇します。
- 「この変数、今どんな値が入っている?」
- 「If文が通るはずなのに通らない」
- 「ループの途中でおかしくなっている気がする」
- 「エラーは出ないのに、結果が合わない」
こうした “目に見えない不具合” を最短で解決するための武器 が、
Debug.Print を使ったデバッグ です。
にもかかわらず、実務では、
- MsgBoxばかり使っている
- Debug.Printは何となく使っているだけ
- 出力はするが、どう読めばいいか分からない
- 配列・オブジェクトになると確認できなくなる
という人が非常に多いのが現実です。
この記事では、
Excel VBAの Debug.Print を使った変数確認(デバッグ) について、
- Debug.Print の基本と役割
- イミディエイトウィンドウとの関係
- 変数・配列・オブジェクトの確認方法
- 実務でよくあるデバッグパターン
- MsgBoxとの正しい使い分け
- 「勘に頼らない」デバッグ思考
を、初心者〜実務レベルまで一気に引き上げる構成 で徹底解説します。
目次
- ✅ Debug.Printとは何か
- ・Debug.Printは「開発者向けの出力命令」
- ・Debug.Printが表示される場所
- ✅ なぜMsgBoxではなくDebug.Printなのか
- ・MsgBoxデバッグの問題点
- ・Debug.Printの圧倒的メリット
- ✅ Debug.Printの基本的な使い方
- ・文字列を出力する
- ・変数の中身を確認する
- ・文字列と変数を組み合わせる
- ✅ If文・条件分岐のデバッグで使う
- ・If文の直前で値を確認する
- ・Else側も必ず確認する
- ✅ ループ処理のデバッグで使う
- ・ループ回数を確認する
- ・特定条件のときだけ出力する
- ✅ 配列の中身をDebug.Printで確認する
- ・1次元配列
- ・Forでまとめて確認する
- ・2次元配列の確認
- ✅ オブジェクト・Rangeの中身を確認する
- ・セルの値を確認する
- ・型を確認する(超重要)
- ・Nothingかどうかを確認する
- ✅ Debug.Printと「?」の使い分け
- ・? は即時評価用
- ・使い分けの考え方
- ✅ 出力が多すぎるときの整理方法
- ・区切り線を入れる
- ・どの処理の出力か明示する
- ✅ Debug.Printでよくある勘違い
- ・「Debug.Printは遅い」
- ・「Debug.Printは消し忘れると危険」
- ・「初心者向け」
- ✅ Debug.Printを使った実務デバッグ思考
- ・「値を予想してから確認する」
- ・「怪しい境界」に出力を入れる
- ✅ MsgBoxとDebug.Printの正しい使い分け
- ・Debug.Printを使う場面
- ・MsgBoxを使う場面
- ✅ RPA(UiPath)連携時のDebug.Print活用
- ✅ まとめ:Debug.Printは最強の「目」
✅ Debug.Printとは何か
※ここを誤解すると、使いどころが分かりません。
・Debug.Printは「開発者向けの出力命令」
Debug.Print は、
VBAの処理途中の情報をイミディエイトウィンドウに出力するための命令です。
Debug.Print "テスト"
この1行を書くだけで、
- 実行を止めず
- 画面を邪魔せず
- 処理の流れを壊さず
情報を確認できます。
・Debug.Printが表示される場所
Debug.Print の出力先は、
イミディエイトウィンドウ です。
- VBAエディタで
- Ctrl + G
を押すと表示されます。
Debug.Print は単体では意味を持たず、
イミディエイトウィンドウとセットで使うもの
という理解が重要です。
✅ なぜMsgBoxではなくDebug.Printなのか
※ここが分かると、デバッグ効率が激変します。
・MsgBoxデバッグの問題点
MsgBoxを使ったデバッグは、次のような欠点があります。
- 実行が止まる
- OKを押す必要がある
- ループ内だと地獄
- 処理速度が大幅に落ちる
MsgBox x
これをループ内で使うと、
開発効率は一気に下がります。
・Debug.Printの圧倒的メリット
Debug.Printには、次の強みがあります。
- 実行が止まらない
- 何回出力してもOK
- ループ・分岐の確認に最適
- 後からまとめて確認できる
実務デバッグではMsgBoxよりDebug.Printが圧倒的に有利
これがプロの共通認識です。
✅ Debug.Printの基本的な使い方
※まずは最小構成を押さえます。
・文字列を出力する
Debug.Print "処理開始"
イミディエイトウィンドウに
処理開始
と表示されます。
・変数の中身を確認する
Dim x As Long
x = 10
Debug.Print x
出力:
10
これが最も基本的なデバッグ用途 です。
・文字列と変数を組み合わせる
Debug.Print "xの値=" & x
出力:
xの値=10
実務では、
必ずラベル付きで出力する のが基本です。
✅ If文・条件分岐のデバッグで使う
※「通らない理由」を特定する。
・If文の直前で値を確認する
Debug.Print "判定前 x=" & x
If x > 5 Then
Debug.Print "If文に入った"
End If
これにより、
- 条件が成立していないのか
- そもそも値が違うのか
を即座に切り分けられます。
・Else側も必ず確認する
If x > 5 Then
Debug.Print "条件成立"
Else
Debug.Print "条件不成立 x=" & x
End If
Else側に出力を入れる
これだけで、デバッグ精度は大きく上がります。
参考:【VBA】If ElseIf Elseを使って「何もしない」条件分岐を実装する方法
✅ ループ処理のデバッグで使う
※最も使用頻度が高いパターンです。
・ループ回数を確認する
For i = 1 To 5
Debug.Print "i=" & i
Next i
これにより、
- 何回回っているか
- 途中で止まっていないか
が一目で分かります。
参考:【VBA】For-Nextループが上手く動作しない原因と対応策|止まる・回らない・想定外を防ぐ
・特定条件のときだけ出力する
For i = 1 To 100
If Cells(i, 1).Value = "" Then
Debug.Print "空白行 i=" & i
End If
Next i
必要な情報だけ出す
これが実務デバッグのコツです。
✅ 配列の中身をDebug.Printで確認する
※ここで詰まる人が非常に多いです。
・1次元配列
Dim arr As Variant
arr = Array("A", "B", "C")
Debug.Print arr(0)
Debug.Print arr(1)
Debug.Print arr(2)
・Forでまとめて確認する
Dim i As Long
For i = LBound(arr) To UBound(arr)
Debug.Print "arr(" & i & ")=" & arr(i)
Next i
配列は必ず LBound / UBound
これはデバッグでも鉄則です。
・2次元配列の確認
Dim r As Long, c As Long
For r = LBound(arr, 1) To UBound(arr, 1)
For c = LBound(arr, 2) To UBound(arr, 2)
Debug.Print "arr(" & r & "," & c & ")=" & arr(r, c)
Next c
Next r
一気に理解しようとせず、1要素ずつ確認
これがコツです。
✅ オブジェクト・Rangeの中身を確認する
※「値があるはずなのに動かない」時に必須です。
・セルの値を確認する
Debug.Print Cells(1, 1).Value
・型を確認する(超重要)
Debug.Print TypeName(Cells(1, 1).Value)
これにより、
- 数値だと思ったら文字列だった
- 日付だと思ったらDoubleだった
といった 型ズレ問題 を即発見できます。
・Nothingかどうかを確認する
If ws Is Nothing Then
Debug.Print "wsはNothing"
End If
オブジェクト系の不具合は、
Debug.Printで状態を出すのが最短 です。
参考:【VBA】IsEmpty / IsNull / IsNothing の違いを徹底解説|未初期化・Null・Nothingを正しく見分けよう
✅ Debug.Printと「?」の使い分け
※知っているとデバッグが速くなります。
・? は即時評価用
イミディエイトウィンドウでは、
? x
と入力すると、
その時点の x の値が表示されます。
・使い分けの考え方
- Debug.Print
- コード内でログを出す
- ?
- ブレーク中に値を確認
両方使えるようになると、
デバッグ速度は一段階上がります。
✅ 出力が多すぎるときの整理方法
※実務では必須です。
・区切り線を入れる
Debug.Print "----------------"
処理単位で区切ると、
ログが非常に読みやすくなります。
・どの処理の出力か明示する
Debug.Print "[初期化] x=" & x
「どこで出たログか分かる」
これが後で効いてきます。
✅ Debug.Printでよくある勘違い
※遠回りの原因です。
・「Debug.Printは遅い」
→ 通常業務では無視できるレベルです。
・「Debug.Printは消し忘れると危険」
→ 本番前に消せばOK。開発中は多用すべきです。
・「初心者向け」
→ 上級者ほど多用します。
✅ Debug.Printを使った実務デバッグ思考
※テクニックより重要です。
・「値を予想してから確認する」
ただ出力するのではなく、
- 本来はいくつになるはずか
- それと違うか
を意識すると、
原因特定が一気に早くなります。
・「怪しい境界」に出力を入れる
- Ifの直前
- ループの開始・終了
- データ取得直後
怪しい場所に集中して出す
これがプロのやり方です。
✅ MsgBoxとDebug.Printの正しい使い分け
※実務で評価されるポイントです。
・Debug.Printを使う場面
- 開発中
- 原因調査
- ロジック検証
・MsgBoxを使う場面
- ユーザーへの通知
- エラー内容の表示
- 処理完了メッセージ
開発用か、運用用か
で使い分けましょう。
✅ RPA(UiPath)連携時のDebug.Print活用
※実務ではここが効きます。
- VBA単体の動作確認
- RPA実行前の検証
- どこで失敗しているかの切り分け
Debug.Printでロジックを固めてからRPAに渡す
これがトラブルを減らす王道です。
✅ まとめ:Debug.Printは最強の「目」
- 実行を止めずに値を確認できる
- 変数・配列・オブジェクトを可視化できる
- MsgBoxより圧倒的に高速
- 勘に頼らないデバッグができる
Debug.Printを使いこなせるようになると、
VBA開発は
「何となく直す」から
「原因を特定して直す」
という段階に進みます。
ぜひ、
日々のVBA開発で
Debug.Printを“当たり前の道具”として使う習慣
を身につけてください。