Excel VBAでマクロを開発していると、
誰もが一度は次のような 「どうにもならない状態」 に直面します。
- ブレークポイントを置いても止まらない
- F8（ステップ実行）ができない
- Debug.Printを書いても何も出力されない
- エラーは出ているのにデバッグ画面に入れない
- そもそもVBAエディタが反応しない
この状態は単に「操作を知らない」のではなく、
VBAが“デバッグできない状態”に陥っている ことが原因です。
しかも厄介なのは、
- コード自体は正しそうに見える
- 昨日までは動いていた
- 別のPCではデバッグできる
といったケースが多く、
原因が1つではない 点です。
この記事では、
Excel VBAで 「デバッグできない」時に考えられる原因と、その具体的な対策 を、
- 状態別
- 原因別
- 実務での発生頻度順
で体系的に整理し、
「今どこを疑うべきか」 が分かるように徹底解説します。
目次
- ✅ VBAで「デバッグできない」とはどういう状態か
- ・よくある「デバッグできない」症状
- ・まず意識すべき大前提
- ✅ 原因①：そもそもデバッグ対象のコードが実行されていない
- ・よくある勘違い
- ・確認方法
- ✅ 原因②：ブレークポイントが有効になっていない
- ・ブレークポイントが無効になるケース
- ✅ 原因③：On Error Resume Next が影響している
- ・On Error Resume Nextの影響
- ・典型的な失敗例
- ✅ 原因④：End ステートメントで強制終了している
- ・Endの影響
- ・よくあるパターン
- ✅ 原因⑤：イベントマクロの中でデバッグしようとしている
- ・イベントマクロの特徴
- ・デバッグできない理由
- ✅ 原因⑥：Excelが「実行中状態」のままになっている
- ・実行中状態とは
- ・この状態で起きる問題
- ✅ 原因⑦：Debug.Printが出力されない
- ・よくある原因
- ✅ 原因⑧：コンパイルエラーが残っている
- ・コンパイルエラーがあると
- ・確認方法
- ✅ 原因⑨：他のアドイン・マクロが干渉している
- ・起きやすい環境
- ・症状
- ✅ 原因⑩：VBAエディタ自体が不安定
- ・兆候
- ✅ デバッグできない時のチェックリスト（実務用）
- ✅ デバッグしやすいコードを書くという発想
- ・ログを前提にした設計
- ・抜け道を用意する
- ✅ RPA（UiPath）連携時に特に注意すべき点
- ✅ まとめ：デバッグできない原因は「コード以外」にあることが多い
✅ VBAで「デバッグできない」とはどういう状態か
※まず状況を正確に定義します。
・よくある「デバッグできない」症状
一口にデバッグできないと言っても、実際には次のように分かれます。
- ブレークポイントで止まらない
- F8を押してもステップ実行にならない
- Debug.Printがイミディエイトに出ない
- エラーで止まるが、デバッグに入れない
- VBAエディタ自体が固まる
どの状態かによって、原因も対策もまったく異なります。
・まず意識すべき大前提
VBAのデバッグは、
- 「VBAが実行中かどうか」
- 「どこから実行されているか」
に強く依存します。
そのため、
コードは合っているのにデバッグできない
という場合、
コード以外の要因 を疑う必要があります。
✅ 原因①：そもそもデバッグ対象のコードが実行されていない
※最初に必ず確認すべきポイントです。
・よくある勘違い
- 書いたSubが実行されていない
- 別のマクロが動いている
- イベントが発火していない
この状態では、
いくらブレークポイントを置いても止まりません。
・確認方法
Debug.Print "ここを通過"
これを、
- Subの最初
- イベントの先頭
に書き、
イミディエイトウィンドウに出るか を確認します。
出なければ、
そのコードは実行されていません。
・対策
- 実行しているマクロ名を再確認
- ボタン・ショートカットの割り当て確認
- イベント（Workbook_Openなど）が本当に発火しているか確認
✅ 原因②：ブレークポイントが有効になっていない
※意外と多い初歩的原因です。
・ブレークポイントが無効になるケース
- コードを一度リセットした
- Endステートメントで強制終了した
- VBAエディタが不安定になっている
この場合、
赤い丸が表示されていても止まらない
ことがあります。
・対策
- 一度ブレークポイントをすべて外す
- 再度F9で設定し直す
- VBAエディタを再起動する
✅ 原因③：On Error Resume Next が影響している
※実務で非常に多い原因です。
・On Error Resume Nextの影響
On Error Resume Next
が有効な状態では、
- 実行時エラーが発生しても
- 処理が止まらず
- デバッグ画面に入らない
という挙動になります。
・典型的な失敗例
On Error Resume Next
' 本来はここでエラーが出て止まるはず
x = 1 / 0
Debug.Print "通過"
この場合、
- エラー箇所が分からない
- Debugもできない
という状態になります。
・対策
On Error GoTo 0
を使い、
- 必要な箇所だけ Resume Next
- それ以外ではエラーを出す
設計に戻します。
参考：【VBA】Application.Gotoメソッドとは：セル・範囲を移動
✅ 原因④：End ステートメントで強制終了している
※デバッグ不能を引き起こす代表例です。
・Endの影響
End
が実行されると、
- VBA全体が即座に終了
- ブレークもDebugもできない
状態になります。
・よくあるパターン
- デバッグ用に一時的にEndを書いた
- 消し忘れたまま開発を続けている
・対策
- Endをすべて削除
- Exit Sub / Exit Function に置き換える
Endはデバッグの敵
という意識を持つことが重要です。
✅ 原因⑤：イベントマクロの中でデバッグしようとしている
※中級者がハマりやすいポイントです。
・イベントマクロの特徴
- Workbook_Open
- Worksheet_Change
- Worksheet_SelectionChange
これらは、
- 自動で発火
- 実行タイミングが特殊
という特徴があります。
・デバッグできない理由
- 開いた瞬間に処理が終わる
- 再現操作が難しい
- 無限ループ防止で止まらない
・対策
If False Then Exit Sub
などで一時的に止めたり、
通常のSubから呼び出してデバッグ します。
✅ 原因⑥：Excelが「実行中状態」のままになっている
※見落とされがちですが重要です。
・実行中状態とは
- ブレーク中
- エラーで停止中
- ステップ実行中
これらはすべて 実行中扱い です。
・この状態で起きる問題
- 新しいデバッグができない
- F8が効かない
- ブレークが無視される
・対策
- VBEの「リセット」ボタンを押す
- Ctrl + Break で中断
- 実行状態を完全に解除する
✅ 原因⑦：Debug.Printが出力されない
※デバッグ不能と誤解されやすいケースです。
・よくある原因
- イミディエイトウィンドウが非表示
- 出力位置を見ていない
- 条件分岐に入っていない
参考：【VBA】デバッグ（Debug.Print）で変数の中身を確認する方法｜不具合を最短で特定する
・対策
- Ctrl + G でイミディエイトを表示
- 出力文の直前に「通過ログ」を入れる
Debug.Print "ここまで来た"
✅ 原因⑧：コンパイルエラーが残っている
※意外と盲点です。
・コンパイルエラーがあると
- 実行自体できない
- デバッグ以前の問題
・確認方法
VBEのメニューから、
- 「デバッグ」
- 「VBAProjectのコンパイル」
を実行します。
・対策
- すべてのコンパイルエラーを解消
- エラーが出なくなるまで修正
参考：【VBA】「コンパイルエラー: ユーザー定義型は定義されていません。」｜型エラーを完全整理
✅ 原因⑨：他のアドイン・マクロが干渉している
※実務環境でよく起きます。
・起きやすい環境
- 業務PC
- RPA連携
- アドイン多数
・症状
- デバッグが不安定
- 止まったり止まらなかったりする
・対策
- Excelをセーフモードで起動
- アドインを一時無効化
- 問題切り分けを行う
✅ 原因⑩：VBAエディタ自体が不安定
※最終的にここに行き着くこともあります。
・兆候
- 反応が遅い
- 操作が効かない
- 明らかに挙動がおかしい
・対策
- Excelを再起動
- PCを再起動
- 一時ファイル削除
「再起動」は恥ではなく、立派な対策 です。
✅ デバッグできない時のチェックリスト（実務用）
※迷ったらこの順で確認してください。
- 本当にそのコードは実行されているか
- On Error Resume Next が残っていないか
- End が書かれていないか
- 実行中状態が残っていないか
- ブレークポイントは有効か
- イミディエイトは見えているか
- コンパイルエラーはないか
✅ デバッグしやすいコードを書くという発想
※対策の最終形です。
・ログを前提にした設計
Debug.Print "[開始] 処理A"
・抜け道を用意する
If cnt > 10000 Then Exit Sub
「デバッグできる設計」＝「壊れにくい設計」
という意識が重要です。
✅ RPA（UiPath）連携時に特に注意すべき点
※実務ではここが評価されます。
- 自動実行ではデバッグが効かない
- VBA単体で検証できる構造にする
- Debug.Printで事前確認する
VBA側でデバッグ不能なコードは、RPAではさらに地獄
という認識が必要です。
✅ まとめ：デバッグできない原因は「コード以外」にあることが多い
- 実行されていない
- エラーを握りつぶしている
- 強制終了している
- 実行状態が残っている
VBAで「デバッグできない」と感じた時は、
焦ってコードを疑う前に、環境と状態を疑う
これが最短ルートです。
正しい原因切り分けができれば、
- デバッグ不能は必ず解消できる
- 開発効率は一気に上がる
- VBAが怖くなくなる
ぜひ、
この記事を 「デバッグできなくなった時のチェックマニュアル」
として活用してください。