【VBA】デバッグでエラー箇所を見つける方法｜止まる・分からないを最短で解決する実務手順

Excel VBAでマクロを作成・修正していると、
誰もが必ず次のような状況に直面します。

• エラーは出るが、どこが原因か分からない
• エラー行は表示されるが、そこが本当の原因ではない
• エラーが出たり出なかったりする
• 実行時エラーなのか、構文エラーなのか判断できない

特に実務では、

• コード量が多い
• 条件分岐やループが複雑
• 他人が書いたマクロを修正している

といった要因が重なり、
「エラー箇所の特定」に一番時間を取られる ケースが非常に多くなります。

この記事では、
Excel VBAにおける 「エラー箇所を見つけるためのデバッグ方法」 をテーマに、

• エラーの種類ごとの考え方
• VBAエディタが教えてくれる情報の正しい読み方
• ブレークポイント・ステップ実行の使い方
• Debug.Print を使った切り分け手法
• 実務で再現しないエラーへの対応策

を、順序立てて・実務視点で 徹底解説します。

✅ VBAで「エラー箇所が分からない」とはどういう状態か

※最初に問題を言語化します。

・よくある勘違い

多くの人が次のように考えがちです。

エラーが出た行 ＝ 原因の行

しかし、VBAではこれは 半分しか正しくありません。

実際には、

• エラー行は「結果が表面化した場所」
• 原因は もっと前の処理 にある

というケースが非常に多いです。

・エラー箇所特定で重要なのは「流れ」

VBAのデバッグでは、

• どの順番で処理され
• どの時点で状態が壊れ
• 最終的にどこでエラーになったか

という 処理の流れを追う視点 が最も重要です。

✅ まず最初にやるべき基本確認

※ここを飛ばすと遠回りします。

・エラーの種類を確認する

VBAのエラーは、大きく次の3種類に分かれます。

1. コンパイルエラー
2. 実行時エラー
3. 論理エラー（エラーは出ないが結果がおかしい）

この分類を間違えると、
デバッグ方法も間違えます。

・エラーメッセージを必ず読む

エラーが出たら、

• 表示されたメッセージ
• エラー番号
• 強調表示された行

を 必ずそのまま確認 します。

「よく分からないから閉じる」は、
最悪のスタートです。

✅ コンパイルエラーでエラー箇所を見つける方法

※実行前に止まるエラーです。

・コンパイルエラーの特徴

• マクロを実行した瞬間に止まる
• 黄色や赤でコードが強調表示される
• 文法・構造ミスが原因

代表例：

• 構文エラー
• Next に対する For がありません
• ユーザー定義型は定義されていません

・対処手順

1. 強調表示されている行を見る
2. その 直前のコード を確認する
3. 対応する構文（If / End If、For / Next）を確認

コンパイルエラーは「前後関係」が原因のことが多い
これを覚えておくだけで、特定が早くなります。

参考：【VBA】「コンパイルエラー: ユーザー定義型は定義されていません。」｜型エラーを完全整理

✅ 実行時エラーでエラー箇所を見つける方法

※最も頻出で、最も厄介です。

・実行時エラーの特徴

• 処理途中まで進む
• ある行で突然止まる
• データや状態によって再現性が変わる

代表例：

• 型が一致しません
• オブジェクトが必要です
• インデックスが有効範囲にありません

・まずやるべきこと

エラーが出たら、
「デバッグ」ボタンを押す のが鉄則です。

すると、

• エラー行が黄色で表示
• その時点で処理が停止

します。

・エラー行だけを信じない

重要なのは、

この行でエラーが出た
＝ この行が悪い

とは限らない、という点です。

多くの場合、

• 変数に想定外の値が入っている
• オブジェクトが Nothing のまま
• 配列の範囲が壊れている

といった 事前状態の破綻 が原因です。

✅ ブレークポイントでエラー箇所を特定する

※ここからが本格デバッグです。

・ブレークポイントとは

ブレークポイントとは、

• 指定した行で
• 強制的に処理を止める

ための機能です。

行の左側をクリックするか、
カーソルを置いて F9 を押すと設定できます。

・使い方の基本戦略

1. エラーが出る行の 少し前 にブレークポイント
2. 実行して処理を止める
3. そこから 状態を確認しながら進める

「止めて考える」ことが、エラー特定の近道 です。

✅ ステップ実行で処理の流れを追う

※エラー箇所特定の最重要スキルです。

・ステップ実行とは

ステップ実行は、

• 1行ずつコードを実行
• 状態の変化を確認

できる機能です。

主に使うキー：

• F8：1行ずつ実行

・ステップ実行で見るべきポイント

• どの行が実行されたか
• どの If 分岐に入ったか
• ループが何回回ったか

「想定と違う動き」を見つけた瞬間が原因発見ポイント です。

✅ Debug.Printでエラー箇所を切り分ける

※実務で最も使われる方法です。

・なぜDebug.Printが有効なのか

Debug.Printを使うと、

• 実行を止めず
• 変数の中身
• 処理の通過点

を確認できます。

・エラー箇所特定の基本パターン

Debug.Print "処理A開始"
' 処理A

Debug.Print "処理B開始"
' 処理B

Debug.Print "処理C開始"
' 処理C

イミディエイトウィンドウを見ることで、

• どこまで出力されたか
• どこで止まったか

が一目で分かります。

・値の変化を追う

Debug.Print "i=" & i & " , 値=" & Cells(i, 1).Value

「いつ」「どの値で」壊れたか
を把握するのが目的です。

✅ If文・条件分岐でのエラー箇所特定

※論理ミスが原因の代表例です。

・If文に入らない原因を探す

Debug.Print "判定前 x=" & x

If x > 10 Then
    Debug.Print "If通過"
End If

これにより、

• xの値が違う
• 型が違う
• 空白や文字列が混ざっている

といった原因を即特定できます。

参考：【VBA】If文の複数条件をリストで判定する方法｜効率的な条件分岐の書き方と応用

✅ ループ処理でのエラー箇所特定

※「途中で止まる」原因を探す。

・ループの進行を確認する

For i = 1 To lastRow
    Debug.Print "i=" & i
    ' 処理
Next i

出力が途中で止まれば、
その直後が怪しい箇所 です。

参考：【VBA】セルの値が一致したら処理を実行する方法｜If文・ループ・実務活用例

・特定条件だけログを出す

If Cells(i, 1).Value = "" Then
    Debug.Print "空白行 i=" & i
End If

全部出さず、怪しい条件に絞る
これが実務デバッグのコツです。

✅ エラーが再現しない場合の対処法

※実務で非常に多いケースです。

・データ依存エラーを疑う

• 空白
• 想定外の文字
• 0件データ

が原因であることがほとんどです。

参考：【VBA】型変換（CInt/CLng/CStr/CDate）の使い分けと注意点｜実務のデータ処理

・事前チェックを入れて切り分ける

If Cells(i, 1).Value = "" Then
    Debug.Print "事前チェックで空白"
    GoTo ContinueLoop
End If

エラーを出す前に状態を確認する
これが安定化の第一歩です。

✅ On Error Resume Next は最終手段

※使い方を間違えると危険です。

・よくある誤用

On Error Resume Next
' 全処理
On Error GoTo 0

これでは、

• エラー箇所が見えない
• 原因特定ができない

状態になります。

・正しい使い方

On Error Resume Next
Set rng = Range("A2:A100").SpecialCells(xlCellTypeVisible)
On Error GoTo 0

If rng Is Nothing Then
    Debug.Print "対象なし"
End If

エラーが出ると分かっている箇所だけに限定
これが鉄則です。

参考：【VBA】For-Nextループが上手く動作しない原因と対応策｜止まる・回らない・想定外を防ぐ

✅ 実務で使えるエラー箇所特定の黄金手順

※迷ったらこの順で進めてください。

1. エラーの種類を確認
2. デバッグで止める
3. エラー行の前後を確認
4. ブレークポイントを置く
5. ステップ実行で流れを追う
6. Debug.Printで値を出す

この手順を守れば、
ほとんどのエラーは特定できます。

✅ よくある勘違い

※遠回りの原因です。

・「エラー行を直せばOK」

→ 原因はもっと前にあることが多いです。

・「とりあえずOn Error Resume Next」

→ 原因が分からなくなります。

✅ RPA（UiPath）連携時のエラー箇所特定

※実務ではここが評価されます。

• VBA単体で正常か
• データ差分で壊れていないか
• 想定外入力に耐えられるか

VBA側でエラー箇所を特定できる状態にしてからRPAに渡す
これがトラブルを減らす王道です。

✅ まとめ：エラー箇所は「止めて・見て・出力する」で必ず見つかる

• エラーの種類を見極める
• エラー行を盲信しない
• ブレークポイントとステップ実行を使う
• Debug.Printで状態を可視化する
• 流れを追えば、必ず原因に辿り着ける

VBAのデバッグは、
才能ではなく手順 です。

正しい方法で、

• 止めて
• 確認して
• 切り分ける

これを繰り返せば、
どんな複雑なコードでも
必ずエラー箇所を特定できるようになります。

ぜひ、
この記事の手順をそのまま使い、
「エラーが怖くないVBA開発」 を身につけてください。