バッチファイルでは、エラーが発生したにもかかわらず処理がそのまま進み、後続処理でさらに被害が拡大するケースが少なくありません。
この問題の多くは、「エラーを検知していない」のではなく、エラーを検知しても処理を止める設計になっていないことが原因です。
ここでは、バッチファイルでエラー発生時に処理を中断・終了させるための実務的な方法を、ERRORLEVEL の扱いを中心に整理します。
ERRORLEVELを使って即座に中断する基本形
最も基本的な方法は、対象コマンドの直後で ERRORLEVEL を判定し、エラーであれば exit /b で処理を終了させる形です。
重要なのは、判定を必ず直後に行うことです。
@echo off
somecommand
if %ERRORLEVEL% neq 0 (
echo エラーが発生しました
exit /b 1
)
echo 次の処理へ進みます
この構成では、somecommand が失敗した時点で以降の処理は実行されません。
if ERRORLEVEL構文で中断する場合
if ERRORLEVEL を使う場合は、「指定値以上」という判定仕様を前提にします。
0/非0 の二択で使うなら、1 以上をエラーとみなす形が分かりやすくなります。
somecommand
if errorlevel 1 (
echo エラーが発生しました
exit /b 1
)
この書き方は短く書けますが、複数の終了コードを扱う場合は順序に注意が必要です。
サブルーチン内でエラー時に中断する
call を使って処理を分割している場合、サブルーチン側で exit /b を使って終了コードを返し、呼び出し元で判定します。
サブルーチン内では、必ず exit /b を明示することが重要です。
@echo off
call :work
if %ERRORLEVEL% neq 0 (
echo work処理でエラー
exit /b 1
)
echo 全体正常終了
exit /b 0
:work
somecommand
if %ERRORLEVEL% neq 0 exit /b 1
exit /b 0
この構成により、エラー発生箇所で確実に処理を打ち切れます。
処理を中断せずにスクリプト全体を即終了する
バッチファイル全体を即座に終了したい場合は、exit を使います。
exit /b は「現在のバッチやサブルーチンから戻る」動作ですが、exit はコマンドプロンプト自体を終了させる点に注意が必要です。
somecommand
if %ERRORLEVEL% neq 0 (
echo 致命的エラー
exit 1
)
対話的なコマンドプロンプト上で実行している場合、ウィンドウが閉じるため、用途を選んで使う必要があります。
パイプ処理では中断条件を分解する
パイプ（|）を使った処理では、ERRORLEVEL は最後のコマンドの結果になります。
前段の失敗で中断したい場合、そのままでは検知できないため、処理を分解して判定します。
type data.txt > nul
if %ERRORLEVEL% neq 0 (
echo ファイル読み取り失敗
exit /b 1
)
find "ABC" data.txt > nul
if %ERRORLEVEL% neq 0 (
echo 検索条件に一致しません
exit /b 1
)
この形にすると、どこで中断されたのかが明確になります。
括弧ブロック内での中断判定
括弧ブロック内では %ERRORLEVEL% が固定されて見えることがあります。
状態を正しく判定したい場合は、遅延環境変数展開を使います。
@echo off
setlocal enabledelayedexpansion
somecommand
if !ERRORLEVEL! neq 0 (
echo エラーが発生しました
exit /b 1
)
ブロック内で中断判定を行う場合は、この形式が安全です。
エラーコードを付けて終了する意味
exit /b の引数で返す数値は、上位のバッチや呼び出し元から参照されます。
エラー理由ごとにコードを分けておくと、後続処理やログ解析がしやすくなります。
if %ERRORLEVEL% neq 0 exit /b 10
このように戻り値を設計することで、バッチ処理全体の可読性と保守性が向上します。
まとめ
バッチファイルでエラー時に処理を中断・終了するには、エラーを検知した瞬間に exit /b で制御を切る設計が基本になります。
ERRORLEVEL は直前のコマンドの結果であることを常に意識し、判定を後回しにしない構成が重要です。
中断条件と戻り値を明示的に設計することで、バッチファイルは「止まらない不安定な処理」から「信頼できる制御フロー」へと変わります。
