VBAでループ処理や条件分岐を書いていると、
「この条件では何もせずに次の処理へ進みたい」
という場面に必ず出会います。
しかし、ここで多くの人が混乱するのが、
VBAにはContinueステートメントが存在しない
という事実です。
そのため、
- どうやって次の処理へ進めればいいのか分からない
- Exitを使ってしまい処理が止まる
- GoToを多用してコードが読めなくなる
といった問題が発生しやすくなります。
実務では、
「何もしない」=重要な処理制御
です。
この記事では、
VBAでContinueの代替となる
IF文を使った「何もしない」設計について、
単なる書き方ではなく、
- 保守性
- 再利用性
- 読みやすさ
- 業務設計
の観点から、実務レベルで徹底解説します。
目次
- ✅ VBAでContinueが使えない理由を正しく理解する
- ・Continueが存在しない背景
- ・よくある誤解
- ・重要な理解
- ✅ IF文で「何もしない」処理を実現する基本設計
- ・基本的なContinue代替パターン
- ・ なぜこの書き方にしているのか
- ・ 別の書き方との比較
- ・ 実務での判断
- ✅ ループ内で安全にスキップする実務パターン
- ・複数条件を安全にスキップする例
- ・ この設計の意図
- ・ 実務での重要な原則
- ✅ Exit・GoToとの違いを正しく理解する
- ・Exit Forの例
- ・GoToの例
- ・ GoToの問題点
- ・ 実務での結論
- ✅ 「何もしない」設計が必要になる典型的な業務パターン
- ・代表的なスキップ対象
- ・実務例
- ✅ Continue的な設計を関数化して再利用する考え方
- ・関数化した例
- ・呼び出し側
- ・ この設計のメリット
- ✅ 「何もしない」処理は最も重要な制御である
- ✅ まとめ:VBAでContinueの代替は「何もしない設計」で実現する
✅ VBAでContinueが使えない理由を正しく理解する
VBAを学び始めた人が最初につまずくポイントの一つが、「Continueが使えない」という仕様です。多くのプログラミング言語ではContinueが用意されているため、同じ感覚でコードを書こうとするとエラーになります。また、無理に代替手段を探してGoToを使ってしまい、コードが複雑になるケースも少なくありません。この違いを理解しないまま処理を書き続けると、将来の修正やトラブル対応で大きな負担になります。まずは「なぜContinueがないのか」を理解することが、安全な設計の第一歩です。
・Continueが存在しない背景
VBAは、
業務処理を安定して実行すること
を目的として設計された言語です。
そのため、
- 明示的な条件制御
- 分岐の見える化
- 処理の安全性
が重視されています。
Continueのように
処理を途中で飛ばす命令は、
誤用するとバグを生みやすいため、
最初から用意されていないという考え方です。
・よくある誤解
次のように書こうとして失敗します。
Continue For
このコードは
VBAでは使用できません。
・重要な理解
VBAでは、
「何もしない」ことで次の処理へ進む
これがContinueの代替になります。
✅ IF文で「何もしない」処理を実現する基本設計
「何もしない」という処理は、初心者には単純に見えるかもしれません。しかし実務では、この部分の設計が非常に重要になります。特に大量データを扱う処理では、「対象外データを安全にスキップする」ことが品質を左右します。また、意図が不明確なスキップ処理は、後からバグの原因になることがあります。そのため、「何もしない」ことを明確に表現する設計が必要になります。ここでは最も基本となる書き方を確認していきましょう。
・基本的なContinue代替パターン
Dim i As Long
For i = 1 To 10
If Cells(i, 1).Value = "" Then
' 空白行は処理しない
Else
Call ProcessRow(i)
End If
Next i
・ なぜこの書き方にしているのか
この設計では、
- 空白データを安全に無視できる
- 処理対象だけを明確にできる
- 将来条件が増えても対応できる
というメリットがあります。
・ 別の書き方との比較
危険な例:
If Cells(i, 1).Value <> "" Then
この書き方は一見シンプルですが、
- 条件が増えると読みにくくなる
- 意図が分かりにくい
- 修正ミスが起きやすい
という問題があります。
・ 実務での判断
処理しない条件を明示する
これが基本です。
✅ ループ内で安全にスキップする実務パターン
実務では、単純な条件だけでなく、複数の理由によって処理をスキップする必要があります。例えば、空白データ、エラー値、処理済みデータなどです。これらを個別に判断しながら安全に次の処理へ進む設計が求められます。また、条件の順序を誤ると、不要な処理が実行されることがあります。この章では、複数条件を扱う実務パターンを整理していきます。
・複数条件を安全にスキップする例
Dim i As Long
For i = 1 To 100
If Cells(i, 1).Value = "" Then
' 空白データ
ElseIf Cells(i, 1).Value = "処理済み" Then
' 既に処理済み
ElseIf IsError(Cells(i, 1).Value) Then
' エラー値
Else
Call ProcessRow(i)
End If
Next i
・ この設計の意図
このコードは、
処理対象を最後に残す
という構造になっています。
・ 実務での重要な原則
順序:
- 処理しない条件
- 例外条件
- 処理対象
ループ内で安全にスキップできるようになると、不要な処理やエラーを防ぐことができます。
しかし実務では、そのあと「次の処理を続けるのか」「処理を中断するのか」といった判断が非常に重要になります。
この判断を正しく設計することで、処理の安定性と保守性は大きく向上します。
条件分岐を使って次の処理へ進む具体的なパターンについては、
次の記事で実例を交えて詳しく解説しています。
→【VBA】If文を使って次の処理へ進む方法|条件分岐・スキップ・中断の実例解説
✅ Exit・GoToとの違いを正しく理解する
Continueの代替を考えるとき、多くの人がExitやGoToを使おうとします。しかし、これらは目的が異なる命令です。誤って使用すると、処理が途中で終了したり、コードの流れが分かりにくくなったりします。特にGoToの多用は、保守性を著しく低下させる原因になります。ここでは、それぞれの違いを明確に整理しておきましょう。
・Exit Forの例
If Cells(i, 1).Value = "終了" Then
Exit For
End If
意味:
ループ自体を終了する
・GoToの例
If Cells(i, 1).Value = "" Then
GoTo NextRow
End If
Call ProcessRow(i)
NextRow:
・ GoToの問題点
- 流れが追いにくい
- バグが増える
- 保守が困難になる
・ 実務での結論
Continueの代替として:
IF文が最も安全
です。
ExitやGoToの違いを理解できたら、次に重要になるのは
「どのタイミングで処理を終了させるべきか」という判断です。
特にExit Subは、
エラー回避や条件不一致時の安全な終了処理として、
実務では非常に頻繁に使われます。
誤った場所でExitを使うと、
処理が途中で止まり、思わぬ不具合を引き起こすこともあります。
Exit Subを安全に使うための具体的な設計と実例については、
次の記事で詳しく解説しています。
→【VBA】Exit Subの基本~実用的な使い方|処理制御と安全なマクロ設計を完全解説
✅ 「何もしない」設計が必要になる典型的な業務パターン
「何もしない」という判断は、特別なケースではありません。むしろ業務処理では日常的に発生します。ここを正しく設計できないと、不要な処理が実行されたり、エラーが連鎖したりします。また、仕様変更時に大きな修正が必要になることもあります。ここでは、実務で頻繁に登場する典型パターンを整理しておきます。
・代表的なスキップ対象
- 空白データ
- 無効データ
- 処理済みデータ
- 重複データ
- エラー値
- 条件未達データ
・実務例
例えば:
- CSV取り込み処理
- 売上データ集計
- 顧客一覧処理
- メール送信処理
- 在庫更新処理
これらはすべて:
スキップ設計が必須
です。
「何もしない」という判断は、実務では非常に重要な設計の一つです。
しかし、その意図をコードとして正しく表現できていないと、
後から見た人が誤解したり、将来の仕様変更で不具合を生む原因になります。
特にElseIfを使った空分岐は、
「何もしない」のではなく「何もしないと明確に判断した」ことを示す設計です。
その具体的な書き方と実務での判断基準については、
次の記事で詳しく解説しています。
→【VBA】IF文でElseIfを用いて何も処理しない方法|空分岐の正しい設計と実務判断
✅ Continue的な設計を関数化して再利用する考え方
同じスキップ条件を複数の処理で使う場合、条件を関数化することで保守性が大きく向上します。特に業務システムでは、同じ判断ロジックが複数箇所に存在することがあります。これを個別に書いてしまうと、仕様変更時にすべて修正する必要があります。関数化することで、変更箇所を一か所に集中できます。ここでは、再利用性を高める設計を紹介します。
・関数化した例
Function ShouldSkipRow(targetCell As Range) As Boolean
If targetCell.Value = "" Then
ShouldSkipRow = True
ElseIf targetCell.Value = "処理済み" Then
ShouldSkipRow = True
ElseIf IsError(targetCell.Value) Then
ShouldSkipRow = True
Else
ShouldSkipRow = False
End If
End Function
・呼び出し側
If ShouldSkipRow(Cells(i, 1)) Then
' 処理しない
Else
Call ProcessRow(i)
End If
・ この設計のメリット
- 再利用できる
- 修正が楽になる
- バグを減らせる
- 意図が明確になる
✅ 「何もしない」処理は最も重要な制御である
多くの人は「処理を書くこと」ばかりに意識が向きます。しかし実務では、「処理しない判断」の方が重要になることが多いです。例えば、誤ったデータを処理してしまうと、システム全体に影響が及ぶことがあります。そのため、「何もしない」という判断は、安全性を守るための重要な制御です。この考え方を理解しておくと、コードの品質が大きく向上します。
「何もしない」という判断は、単に処理を省略することではありません。
それは「どの条件で処理を行い、どの条件で処理を行わないか」という
業務ルールそのものをコードに表現する設計です。
この判断を曖昧にしたままマクロを作り続けると、
後から誰も触れなくなる「ブラックボックス化」を招く原因になります。
マクロを長く安全に使い続けるための設計の考え方については、
次の記事で実務視点から詳しく解説しています。
→ Excelマクロがブラックボックス化する前に考える設計の考え方
✅ まとめ:VBAでContinueの代替は「何もしない設計」で実現する
- VBAにはContinueが存在しない
- IF文で「何もしない」ことで代替できる
- スキップ条件は明示的に書く
- ExitやGoToと役割を混同しない
- 処理しない判断が安全性を高める
- 条件は関数化すると保守性が向上する
- 「何もしない」は重要な制御である
Continueの代替は、特別な命令ではありません。
それは:
正しい条件設計
です。
この考え方を身につけておけば、
- バグが減る
- 修正が楽になる
- 処理が安定する
- 引き継ぎが簡単になる
という状態を作れるようになります。