バッチファイルを手動で実行すると問題ないのに、タスクスケジューラから起動したときだけ動作が異なる、失敗するといった現象はよくあります。
これは「実行環境の違い」が主な原因です。ここでは代表的な原因とその解決策を整理します。
原因1:作業ディレクトリが異なる
タスクスケジューラから実行されると、カレントディレクトリ(作業ディレクトリ)が C:\Windows\System32
になります。
バッチ内で相対パスを使っていると、ファイルが見つからず処理が失敗します。
@echo off
rem 手動実行では動くが、スケジューラ経由では失敗
copy data\input.txt backup\
解決策: パスは必ず絶対パスを使うか、バッチのあるフォルダへ移動してから処理を行います。
@echo off
cd /d "%~dp0"
copy "data\input.txt" "backup\"
原因2:権限の違い
タスクスケジューラは設定されたユーザー権限で実行されます。管理者権限が必要な処理でも、設定が不足していると失敗します。
解決策: タスクの「全般」タブで「最上位の特権で実行する」にチェックを入れてください。
原因3:ネットワークドライブが利用できない
映像処理やバックアップなどで Z: や X: などのネットワークドライブを参照している場合、タスクスケジューラからは利用できません。
これはログオンセッションとスケジューラのセッションが異なるためです。
@echo off
rem 手動実行ではZ:が使えるが、スケジューラではエラー
copy Z:\data\file.txt C:\backup\
解決策: UNCパス(\\server\share\path
)を直接指定してください。
@echo off
copy "\\server\share\data\file.txt" "C:\backup\"
原因4:環境変数やPATHの違い
手動実行では使えるコマンドが、タスクスケジューラ経由では「認識されません」となることがあります。これは PATH が異なるためです。
解決策: コマンドやプログラムは絶対パスで指定するか、バッチ内で PATH を明示的に設定します。
@echo off
set PATH=C:\Program Files\MyApp\bin;%PATH%
"C:\Program Files\MyApp\bin\mytool.exe" -option
原因5:対話型の入力やGUIが使えない
タスクスケジューラは非対話モードで動作します。pause や set /p などの入力待ち、GUIを開く処理は動作しません。
解決策: ユーザー入力を求めないように改修し、必要な値は引数や設定ファイルで渡してください。
まとめ
タスクスケジューラからの実行で動作が異なるときは、次のポイントを確認すると解決につながります。
- カレントディレクトリを固定する(
cd /d "%~dp0"
) - 管理者権限が必要なら「最上位の特権で実行」
- ネットワークドライブは UNCパスに書き換える
- コマンドは絶対パスで指定する/PATHを設定する
- 対話入力やGUIに依存しないようにする
これらを押さえておけば、タスクスケジューラ経由でも安定してバッチファイルを実行できるようになります。