【bat】ERRORLEVEL以外でエラーを検知する方法

【bat】ERRORLEVEL以外でエラーを検知する方法 bat

バッチファイルのエラー判定といえば ERRORLEVEL が定番ですが、実務では ERRORLEVEL だけに頼ると誤判定や取りこぼしが発生する場面も少なくありません。

特に、コマンド仕様が特殊な場合や、処理結果そのものを確認したいケースでは、ERRORLEVEL 以外の観点でエラーを検知する設計が有効になります。

ここでは、ERRORLEVEL を使わず、または補助的に使いながらエラーを検知する代表的な方法を整理します。

ファイルやディレクトリの存在で判定する

処理結果としてファイルやディレクトリが生成される場合、その存在有無で成功・失敗を判断できます。

ERRORLEVEL に依存しないため、コマンド仕様の違いを意識せずに済む点がメリットです。

somecommand

if not exist output.txt (
  echo 出力ファイルが存在しません
  exit /b 1
)

ファイル生成やコピー、ダウンロード処理では、最も安全性の高い判定方法の一つです。

想定した内容が出力されているかを確認する

処理結果がログやテキストに出力される場合、その内容を確認して成否を判断する方法もあります。

特定の成功メッセージやエラーメッセージの有無を条件にすることで、ERRORLEVEL が信用できないコマンドでも判定可能になります。

somecommand > result.log

find "SUCCESS" result.log > nul
if %ERRORLEVEL% neq 0 (
  echo 成功メッセージが見つかりません
  exit /b 1
)

この方法は外部ツール実行時の判定によく使われます。

想定外の出力があるかで異常を検知する

エラー時に特定の文字列が出力される場合、それを検知する設計も有効です。

標準出力と標準エラー出力を分離できないバッチでは、ログ内容そのものが判定材料になります。

somecommand > result.log

find "ERROR" result.log > nul
if %ERRORLEVEL% equ 0 (
  echo エラーが検出されました
  exit /b 1
)

エラーメッセージの仕様が安定しているツールで特に有効です。

戻り値ではなく副作用で判断する

処理の成功によって環境変数が設定される、レジストリが更新される、設定ファイルが書き換わるなど、副作用を確認する方法もあります。

これは「処理が最後まで到達したか」を確認できるため、途中失敗を確実に検知できます。

somecommand

reg query HKCU\Software\MyApp > nul
if %ERRORLEVEL% neq 0 (
  echo レジストリが更新されていません
  exit /b 1
)

標準エラー出力の有無で判定する

コマンドが標準エラー出力にメッセージを出す場合、その有無を利用できます。

標準エラーをファイルにリダイレクトし、空かどうかを確認します。

somecommand 2> error.log

for %%A in (error.log) do if %%~zA neq 0 (
  echo 標準エラー出力が検出されました
  exit /b 1
)

ERRORLEVEL が常に 0 を返すツールでも、異常を検知できるケースがあります。

処理時間や応答で異常を推測する

想定より極端に早く終わる、またはすぐに制御が戻る処理は、内部で失敗している可能性があります。

タイムアウトや待機処理と組み合わせることで、間接的に異常を検知することもできます。

start /wait somecommand

if not exist expected_result.txt (
  echo 想定結果がありません
  exit /b 1
)

ERRORLEVELと併用する設計が現実的

ERRORLEVEL を完全に使わないよりも、補助的な判定と組み合わせる方が現実的です。

ERRORLEVEL で即座に失敗を検知しつつ、結果物やログで最終確認を行うことで、誤判定を大幅に減らせます。

somecommand
if %ERRORLEVEL% neq 0 exit /b 1

if not exist output.txt exit /b 2

まとめ

ERRORLEVEL は便利な仕組みですが、すべてのエラーを正確に表現できるわけではありません。

実務では、ファイルの有無、出力内容、副作用、標準エラーといった複数の観点を組み合わせることで、より信頼性の高いエラー検知が可能になります。

ERRORLEVEL を「唯一の判定基準」にせず、「複数ある判断材料の一つ」として扱うことが、壊れにくいバッチ設計につながります。