タスクスケジューラのタスクが実行されない・0x1で終わる ── 原因の切り分けと安全な運用設計

「PowerShell で作った集計スクリプトを毎朝 6 時に動かしたい」「手で実行すれば動くのに、タスクスケジューラに載せると動かない」。業務自動化の相談を受けていると、最後はほぼ必ずこの話になります。

当ブログでも、ログ整理の自動化、Pester によるスクリプトのテスト、C# からの PowerShell 実行、Power Automate による業務自動化と、自動化の話を続けて書いてきました。これらの記事はどれも、最終的には「タスクスケジューラで定期実行する」ことを前提にしています。ところが、そのタスクスケジューラ自体が意外と癖の強い仕組みで、「手動なら動くのに定期実行だと失敗する」「いつの間にか止まっていたことに誰も気づかなかった」という事故が後を絶ちません。

この記事では、タスクスケジューラの仕組みのうち運用事故に直結する部分──実行アカウントとログオン種別、「実行されない」ときの切り分け、戻り値 0x1 の典型原因、ログの残し方、多重起動の制御──を、実務でつまずく順に整理します。

1. まず結論

• タスクスケジューラのトラブルの大半は、スクリプトそのものではなく「誰として・どういうセッションで実行されるか」の理解のずれから生じます。「ユーザーがログオンしているかどうかにかかわらず実行する」を選んだ瞬間に、対話セッションともログオン時の環境とも別の世界で動くことを前提に設計してください。¹
• 「実行されない」の調査は履歴（History）タブとイベントログが起点です。ただしタスク履歴は既定で無効なので、運用に乗せる前に「すべてのタスク履歴を有効にする」を必ず有効化しておきます。²
• 「前回の実行結果」に出る 0x1 はタスクスケジューラのエラーではなく、起動したプログラム自身が終了コード 1 を返したという意味です。原因はスクリプト側にあるので、終了コードを設計し、ログを自分で残す仕組みを先に作ります。³
• PowerShell スクリプトは -NoProfile -NonInteractive -ExecutionPolicy Bypass -File "フルパス" の形で呼び出し、スクリプト内のパスは $PSScriptRoot 基準にするのが基本形です。「開始（オプション）」欄に引用符を入れてはいけないという古典的な罠もここで踏みがちです。
• パスワード変更でタスクが黙って死ぬ事故を避けるには、実行アカウントの設計（サービスアカウントの棚卸し、ドメイン環境なら gMSA の検討）が必要です。⁴
• 多重起動の制御(既定は「新しいインスタンスを開始しない」)、実行時間制限（既定 3 日）、電源条件（既定は AC 電源時のみ）は、既定値のまま気づかず運用してしまう代表的な設定です。登録時に必ず明示的に決めてください。⁵

2. タスクスケジューラの構造 ── トリガー・操作・条件・設定

タスクスケジューラのタスクは、大きく 4 つの要素でできています。

GUI（taskschd.msc）で作ったタスクは XML としてエクスポートできます。タスク定義を Git で管理したい場合や、複数台に同じタスクを配る場合は、XML エクスポート＋schtasks /Create /XML、あるいは PowerShell の ScheduledTasks モジュール（New-ScheduledTaskAction / New-ScheduledTaskTrigger / New-ScheduledTaskSettingsSet / Register-ScheduledTask）でスクリプト化しておくのがおすすめです。⁵

$action   = New-ScheduledTaskAction -Execute 'pwsh.exe' `
    -Argument '-NoProfile -NonInteractive -ExecutionPolicy Bypass -File "C:\Jobs\Cleanup-Logs.ps1"' `
    -WorkingDirectory 'C:\Jobs'
$trigger  = New-ScheduledTaskTrigger -Daily -At '06:00'
# 電源条件の既定は「AC電源時のみ開始・バッテリーに切り替わったら停止」。
# ノートPCや現場端末でも動かすジョブなら、ここで明示的に許可しておく
$settings = New-ScheduledTaskSettingsSet -StartWhenAvailable `
    -MultipleInstances IgnoreNew `
    -ExecutionTimeLimit (New-TimeSpan -Hours 2) `
    -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries
# パスワードを画面に表示させないよう Get-Credential 経由で受け取る
$cred = Get-Credential -UserName 'DOMAIN\svc-batch' -Message '実行アカウントの資格情報'
Register-ScheduledTask -TaskName 'KS-Cleanup-Logs' `
    -Action $action -Trigger $trigger -Settings $settings `
    -User $cred.UserName -Password $cred.GetNetworkCredential().Password

タスク定義がコードになっていれば、検証機で試したものをそのまま本番に持っていけますし、「どの設定で動いているか分からない」という状態も避けられます。

複数台への展開なら、GUI で作り込んだタスクを XML にエクスポートして schtasks で配る方法も実績があります。

rem 検証機で作ったタスクをエクスポート
schtasks /Query /TN "KS-Cleanup-Logs" /XML > KS-Cleanup-Logs.xml

rem 各端末でインポート（実行アカウントとパスワードは登録時に指定）
schtasks /Create /TN "KS-Cleanup-Logs" /XML KS-Cleanup-Logs.xml /RU DOMAIN\svc-batch /RP *

XML にはトリガー・条件・設定がすべて含まれるので、リポジトリに入れておけばタスク定義のレビューも差分管理もできます。逆に、手作業で 10 台に同じタスクを GUI 登録する運用は、1 台だけ設定が違う「はぐれタスク」を必ず生みます。台数が 2 桁になる前にコード化しておくのが安全です。

なお、この記事の内容は Windows 10 / 11、Windows Server 2016 以降のタスクスケジューラ（Task Scheduler 2.0 系）を前提にしています。もっと古い at コマンド由来のタスクが残っている環境では、まずそれらの棚卸しから始めてください。

3. 実行アカウントとログオン種別 ── 一番の事故ポイント

タスクのプロパティで選ぶ「ユーザーがログオンしているときのみ実行する」「ユーザーがログオンしているかどうかにかかわらず実行する」は、内部的にはログオン種別（LogonType）の選択です。ここの理解がずれていると、「手動では動くのに定期実行では動かない」の大半を説明できないまま迷走することになります。¹

3.1 3つのモードの違い

実務での典型的な事故はこうです。

• 共有フォルダーにアクセスするスクリプトを「パスワードを保存しない」（S4U）で登録した。ローカルのテストでは動いたが、本番では共有フォルダーへのアクセスだけが失敗する。→ S4U にはネットワーク資格情報がないため。
• 「ログオンしているかどうかにかかわらず実行」で登録した数か月後、ドメインのパスワード有効期限が来てパスワードを変更した。以後タスクはログオン失敗（0x8007052E）で止まり続けたが、誰も気づかなかった。
• GUI アプリを起動するタスクを「かかわらず実行」で登録した。アプリは起動しているが画面がどこにも表示されず、「動いていない」と誤解した。→ 非対話セッションで動いているため。対話的な画面が必要な処理は、この構成では原則動かせません。

また、Password / S4U で実行するアカウントには「バッチ ジョブとしてログオン」の権利（SeBatchLogonRight）が必要です。Administrators には既定で付与されていますが、専用の一般ユーザーをサービスアカウントにする場合はローカル セキュリティ ポリシー側の設定も確認してください。⁶

3.2 どのアカウントで動かすか

• SYSTEM: パスワード管理が不要で強力ですが、権限が強すぎます。ローカル完結の保守処理には便利でも、業務データを触るジョブを何でも SYSTEM にするのは避けるべきです。管理者権限が本当に必要かどうかの考え方は、別記事「Windowsアプリに管理者権限が必要なのはどんなときか」で整理しています。
• 専用のサービスアカウント（一般ユーザー）: 最小権限にできる反面、パスワード変更のたびにタスクを更新する運用が必要です。パスワード有効期限とタスクの棚卸しをセットで管理してください。
• gMSA（グループ管理サービスアカウント）: ドメイン環境なら第一候補です。パスワードはドメインコントローラーが自動管理するため、「パスワード変更でタスクが死ぬ」問題そのものがなくなります。タスクスケジューラは gMSA での実行をサポートしています。⁴

なお「最上位の特権で実行する」チェックは、UAC で分割されたトークンのうち管理者側（昇格済み）トークンで実行するという意味です。管理者権限が不要なジョブでは付けないでください。

4. 「実行されない」を切り分ける手順

4.1 履歴を有効にしてから疑う

タスクスケジューラの右ペインにある「すべてのタスク履歴を有効にする」は、既定で無効です。履歴が無効のままだと、失敗したという事実すら記録に残りません。運用に乗せる前に必ず有効化し、イベントログ（イベント ビューアー → アプリケーションとサービス ログ → Microsoft → Windows → TaskScheduler → Operational）とあわせて確認できる状態にしておきます。²

切り分けの基本手順は Microsoft のトラブルシューティングガイドの流れそのままで十分機能します。²

1. スクリプトを単体でテストする ── タスクに載せる前に、実行アカウントと同じ条件（可能なら runas や検証機）でスクリプト自体が完走することを確認する。
2. 状態列と履歴タブを見る ── そもそもトリガーされたのか、起動したが失敗したのかを区別する。トリガーされていなければトリガー設定・条件（電源・ネットワーク）を疑い、手動実行（右クリック → 実行）で操作自体は動くかを確認する。
3. 「ユーザーがログオンしているときのみ実行」に一時変更してみる ── これで動くなら、原因は非対話セッションや資格情報まわり（前章）にあると絞り込めます。

4.2 「前回の実行結果」の読み方

0x413xx 系はタスクスケジューラの状態コード、0x8007xxxx は Windows のエラーコード、そして 0x1 や 0x2 のような小さい値は起動されたプログラム自身の終了コードです。³ この区別がつくと、調べる場所（タスク設定か、スクリプトか）を最初から間違えなくなります。

4.3 条件・設定の既定値に注意

• 電源条件: 既定では「コンピューターを AC 電源で使用している場合のみタスクを開始する」が有効です。ノート PC を検証機にすると、バッテリー駆動時だけ動かない「再現しない不具合」になります。さらに Windows 10 以降、バッテリー節約機能が有効な間は多くのタスクのトリガーが遅延されます。⁷
• 開始時刻を逃した場合: PC がシャットダウンしていて開始時刻を過ぎた場合、既定では次のスケジュールまで実行されません。「スケジュールされた時刻にタスクを開始できなかった場合、すぐにタスクを実行する」（-StartWhenAvailable）を明示的に有効にするか、逃してよいジョブなのかを設計として決めておきます。⁵
• スリープ解除: 夜間ジョブでスリープ運用の PC なら「タスクを実行するためにスリープを解除する」（-WakeToRun）の要否も決めます。

4.4 トリガー設計そのものの注意

「実行されない」と思ったら、そもそもトリガーの設計が意図とずれていた、というケースもあります。

• 「毎月 31 日」は 31 日がない月には実行されません。 月末処理なら「毎月最終日」を意図した設計（月初に前月分を処理する、あるいはスクリプト側で日付判定する）に寄せたほうが安全です。
• 時刻はタスクを登録したマシンのローカル時刻です。 海外拠点の端末や、まれに UTC 設定で運用されているサーバーに同じ XML を配ると、実行時刻が拠点ごとにずれます。「全拠点で日本時間の朝 6 時」なのか「各拠点の朝 6 時」なのかを仕様として決めておいてください。
• 短い間隔の繰り返し（5 分ごとなど）をタスクスケジューラでやり始めたら要注意。 「1 日 1 回のバッチ」の道具立てとしては優秀ですが、分単位のポーリングや常時監視が必要になってきたら、それは常駐プロセスの領域です（後述の第 8 章）。
• イベントトリガーは強力ですが、対象イベントが本当に安定して記録されるかを先に確認する。 アプリケーションログの特定イベント ID をトリガーにする構成は、アプリの更新でイベントの出方が変わると黙って動かなくなります。時刻トリガー＋スクリプト内での条件判定のほうが、結果的に追いやすいことも多いです。

5. 0x1 で終わる典型パターンと PowerShell の正しい呼び出し方

0x1 はスクリプトが失敗したという結果でしかないので、原因はスクリプトの実行環境の差にあります。手動実行と定期実行で違うのは、主に次の点です。

• カレントディレクトリが違う: 「開始（オプション）」を指定しなければ C:\Windows\System32 などで動きます。相対パスで書かれたスクリプトはここで壊れます。スクリプト側は $PSScriptRoot 基準でパスを組み立て、タスク側は「開始（オプション）」に作業フォルダーを指定します。このとき「開始（オプション）」欄に引用符を付けてはいけません。スペースを含むパスでも引用符なしで書きます（付けると 0x8007010B で失敗します）。
• 環境変数・プロファイルが違う: ログオンスクリプトやユーザープロファイルで設定される環境変数、マップされたネットワークドライブ（X: など）は、非対話セッションには存在しないと考えてください。UNC パス（\\server\share\...）を直接使い、-NoProfile でプロファイル差を排除します。
• 実行ポリシーが違う: ユーザーには RemoteSigned を設定していても、サービスアカウントでは未設定ということがあります。タスクの引数で -ExecutionPolicy Bypass を明示します。
• ツールの終了コード規約が特殊: たとえば robocopy は「コピーすべきファイルがあり正常にコピーした」場合に 1 を返します。終了コードをそのまま返すラッパーだと、正常なのに 0x1 に見える、あるいはその逆が起きます。使う外部コマンドの終了コード規約は必ず確認してください。

PowerShell 呼び出しの基本形は次のとおりです。

プログラム/スクリプト:  pwsh.exe          （Windows PowerShell なら powershell.exe）
引数の追加:            -NoProfile -NonInteractive -ExecutionPolicy Bypass -File "C:\Jobs\Cleanup-Logs.ps1"
開始 (オプション):      C:\Jobs           （引用符なし）

-Command ではなく -File を使うのは、引数のエスケープが素直になることに加えて、スクリプトの exit n がそのままプロセスの終了コードになり、タスクスケジューラの「前回の実行結果」から成否を判別できるようになるためです。スクリプト側でも、成功なら 0、失敗なら 0 以外を明示的に返す設計にしておきます。

# コマンドレットの「非終了エラー」も catch に落とすため Stop に設定する。
# これがないと Copy-Item などの失敗が素通りして exit 0 になり得る
$ErrorActionPreference = 'Stop'

try {
    Main
    exit 0
}
catch {
    Write-Error $_
    exit 1
}

例外をどこで捕まえてどう記録するかの考え方は、別記事「例外の捕捉とログ設計」でも詳しく書いています。

6. ログは自分で残す

タスクスケジューラの履歴は「起動したか・終了コードは何か」までしか教えてくれません。スクリプトが何をどこまでやったかは、スクリプト自身がログとして残す必要があります。

最低限なら、タスクの引数でリダイレクトするのではなく（タスクスケジューラの「引数」欄でのリダイレクト記法はシェル経由でないため機能しません）、スクリプト内でトランスクリプトを取るのが手軽です。

$logDir = 'C:\Jobs\logs'
New-Item -ItemType Directory -Path $logDir -Force | Out-Null
Start-Transcript -Path (Join-Path $logDir ("cleanup-{0:yyyyMMdd}.log" -f (Get-Date))) -Append
try {
    # 本処理
}
finally {
    Stop-Transcript
}

ログ自体が溜まり続ける問題への対処（世代管理・アーカイブ）は、まさに「PowerShellスクリプト応用 ── ログ調査・アーカイブ・レポート化を安全に自動化する」で書いた内容がそのまま使えます。

一歩進めるなら、Windows イベントログへの書き込みも検討してください。ファイルログと違って、運用側が既に見ている場所（イベント ビューアー、既存の監視ツール）に成否が届くのが利点です。

# --- セットアップ時に一度だけ、管理者権限で実行する（インストーラーや初期設定スクリプト）---
if (-not [System.Diagnostics.EventLog]::SourceExists('KS-Jobs')) {
    [System.Diagnostics.EventLog]::CreateEventSource('KS-Jobs', 'Application')
}

# --- ジョブ本体（最小権限アカウントで実行）は書き込みだけを行う。
#     SourceExists は全ログの探索に管理者権限を要求し得るので、実行時には呼ばない ---
try {
    [System.Diagnostics.EventLog]::WriteEntry('KS-Jobs',
        "Cleanup-Logs failed: $($_.Exception.Message)",
        [System.Diagnostics.EventLogEntryType]::Error, 1001)
}
catch {
    # ログに書けないことを、元の失敗を握り潰す理由にしない
    Write-Warning "イベントログへの書き込みに失敗: $_"
}

2 点補足します。まず、イベントソースの登録（CreateEventSource）には管理者権限が必要です。ジョブ本体に登録処理を混ぜると、最小権限のサービスアカウントで動く本番の初回失敗時に「登録しようとして例外 → 肝心のイベントが書けない」という二重の失敗になります。上のように登録はセットアップ側へ分離し、実行時は書き込みだけにしてください。次に、この記事のタスク登録例のように実行エンジンを pwsh.exe にしている場合、Windows PowerShell 5.1 時代の New-EventLog / Write-EventLog コマンドレットは使えません（コマンドが見つからずスクリプトごと失敗します）。上のように .NET クラスを直接呼ぶ形なら 5.1 / 7 のどちらでも動きます。

そのうえで、「失敗したら人に届く」仕組み──メールや Teams / Slack への通知──を一つ入れておくと、「数か月止まっていたことに棚卸しで気づく」事故を防げます。凝った通知基盤は不要で、失敗時だけ Webhook に POST する数行でも十分に機能します。逆に「成功のたびに通知」は早晩読まれなくなるので、成功は週次のサマリー程度に抑え、失敗と「実行されなかった」（前回実行時刻が古い）を検知対象にするのがおすすめです。ログに何を書くべきかの基準は「例外の捕捉とログ設計」でも整理しています。

7. 多重起動と長時間実行の制御

前回の実行が長引いているうちに次のスケジュール時刻が来たらどうなるか。これは設定タブの「タスクが既に実行中の場合に適用される規則」で決まり、PowerShell では -MultipleInstances に対応します。⁵

あわせて「停止するまでの時間」（-ExecutionTimeLimit、既定 3 日）を現実的な値（想定実行時間の 2〜3 倍程度）に設定しておくと、ハングしたプロセスが翌日のジョブを道連れにする事故を防げます。⁵

注意したいのは、IgnoreNew や Queue が守ってくれるのは同じタスク定義の中だけだという点です。別のタスクが同じスクリプトを呼んでいる場合や、障害対応で人が手動実行した場合の衝突までは防げません。同じ資源（ファイル、DB、外部システム）を触る経路が複数あるなら、スクリプト側にも排他を持たせます。定石は名前付きミューテックスです。

$mutex = New-Object System.Threading.Mutex($false, 'Global\KS-Cleanup-Logs')
if (-not $mutex.WaitOne(0)) {
    Write-Warning '別のインスタンスが実行中のため終了します。'
    exit 0   # 「実行しなかった」を失敗にしない場合は 0、失敗扱いなら非 0 に
}
try {
    # 本処理
}
finally {
    $mutex.ReleaseMutex()
}

名前の先頭に Global\ を付けると、別セッション（別ユーザーのタスクと手動実行など）間でも排他が効きます。ロック取得を待つのか（WaitOne にタイムアウトを渡す）、即座にあきらめるのかは、ジョブの性質に合わせて決めてください。なお Global\ の名前付きオブジェクトはマシン上の誰からも見える点には注意が必要です。複数の利用者がログオンする共有サーバーでは、悪意や事故で同名のミューテックスを先に握られると、ジョブが永遠にスキップされ続ける（しかも exit 0 なら正常に見える）ことになります。そうした環境では、ミューテックスに ACL（MutexSecurity）を設定して取得できるアカウントを絞るか、少なくとも「取得できずにスキップした」ことを前節の通知・イベントログに乗せて、スキップの連続を監視で検知できるようにしてください。ファイルを介した連携での排他制御は「ファイル連携とロックのベストプラクティス」で詳しく扱っています。

8. タスクスケジューラの「やめどき」 ── 常駐サービスとの使い分け

タスクスケジューラは万能ではありません。要件が育ってきたときに、無理に使い続けるより仕組みを乗り換えたほうがよい境界があります。

「5 分ごとのタスク」でポーリングを始めると、起動のたびにプロセス生成・モジュール読み込みのコストがかかるうえ、前回の状態をファイルなどに退避する仕組みが必要になり、実質的に常駐プロセスを細切れに再実装することになります。この段階に来たら、.NET の Generic Host と BackgroundService で常駐化するのが素直です。実装パターンは「Generic HostとBackgroundServiceをデスクトップアプリで使う」で解説しています。

逆に、月次・日次のバッチをわざわざサービス化して自前でタイマー管理するのも過剰です。「実行間隔が時間単位以上・処理が独立・状態を持たない」ならタスクスケジューラ、それを外れ始めたら常駐化を検討する、という線引きで大きく間違いません。

9. 運用に乗せる前のチェックリスト

登録前に、次の項目を一度ずつ確認することをおすすめします。

• 実行アカウントは決めたか（SYSTEM を惰性で選んでいないか。ドメインなら gMSA を検討したか）
• ログオン種別の制約を理解したか（S4U ならネットワークアクセスなし。Password ならパスワード変更時の運用を決めたか）
• スクリプトを実行アカウント相当の条件で単体テストしたか
• -NoProfile -NonInteractive -ExecutionPolicy Bypass -File の形で呼んでいるか
• スクリプト内のパスは $PSScriptRoot / UNC 基準か（マップドライブ・相対パスに依存していないか）
• 「開始（オプション）」に引用符を入れていないか
• 終了コードを設計したか（成功 0 / 失敗非 0。外部コマンドの終了コード規約を確認したか）
• タスク履歴を有効にしたか。スクリプト自身のログと失敗通知はあるか
• 電源条件・StartWhenAvailable・多重起動・実行時間制限を明示的に設定したか
• タスク定義を XML または PowerShell スクリプトとしてリポジトリに保存したか

10. まとめ

タスクスケジューラは「スクリプトを書けば終わり」ではなく、実行アカウント・セッション・既定値という 3 つの前提を設計して初めて安定運用に乗ります。逆に言えば、この記事で挙げたポイント──ログオン種別の選択、履歴の有効化、終了コードとログの設計、多重起動と時間制限の明示──を登録時に一度押さえてしまえば、その後は驚くほど手がかからなくなります。

「手動なら動くのに定期実行だと動かない」は、ほぼ確実にセッションと環境の差が原因です。闇雲に設定をいじる前に、履歴タブでどこまで進んでいるかを確認し、この記事の切り分け手順を上から試してみてください。

関連記事

• PowerShellスクリプト応用 ── ログ調査・アーカイブ・レポート化を安全に自動化する
• Pesterで守るPowerShellスクリプト ── 保守フェーズのテスト戦略
• Power Automateで業務を自動化する ── クラウドフロー・デスクトップフローの使い分けとエラー処理設計
• Windowsアプリに管理者権限が必要なのはどんなときか

関連する相談領域

合同会社小村ソフトでは、PowerShell・タスクスケジューラによる業務自動化の設計レビューや、「動いてはいるが誰も直せない」状態になった定期ジョブの立て直しの相談を扱っています。

• 技術相談・設計レビュー
• Windowsアプリ開発
• 不具合調査
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。