こんな症状に心当たりはありませんか。
毎朝ちゃんと動いているはずなのに、出てくるファイルはいつも途中まで。エラーも出ていないのに、なぜ最後まで終わらないんだろう。
その症状、プログラムが壊れているとは限りません。「時間の設定」が実際にかかる時間と合っていないだけ、というケースがあります。見る場所は多くありません。
⚠️ この記事の情報は2026年8月時点のものです。画面の名称や項目の並びはWindowsの更新で変わることがあります。筆者のシステムは株価データを記録するための観測・研究用で、自動発注はしません（read-only）。実際のお金での発注はしていません（仮想発注のみ・実発注なし）。設定を変えるときは、まず現在の値をメモしてから触ってください。
Windowsのタスクスケジューラで「毎日◯時に自動実行」を組んだ。最初はうまくいっていた。ところが最近、出力が毎回途中で切れている——あるいは、ある日だけ何も出ない日がある。ログを開いても、致命的なエラーらしきものは見当たらない。そういう相談をよく見かけます。
この記事で持ち帰れるのは3つ。
- 「毎回途中で終わる」と「ある日だけ空振りする」は原因が別で、見る場所も別だと分かる
- 自分のパソコンで、危険な操作をせずに設定値を読み出す手順が分かる
- 直すときに「やってはいけない直し方」（上限を消す・無限に待たせる）が分かる
結論を先に。時刻を1か所ずらしたら、それに連動する「実行時間の上限」と「待ち時間」もセットで見直す。この2つは開始時刻から数えるため、開始時刻だけを動かすと静かに矛盾します。筆者はまさにこれで、終わる30分前に処理ごと強制終了されうる状態を作っていました。筆者の場合は、実際に切られる前に点検で見つけました——開始時刻を前倒しした当日に設定を読み返し、新しい開始時刻で初めて動く朝を迎える前に気づけた、という順番です。以下に出てくる上限と待ち時間の2つは、「実際に被害が出た記録」ではなく「計算で先に分かった矛盾」です。そのつもりで読んでください。
| 症状 | まず見る場所 |
|---|---|
| 毎回、だいたい同じ時刻で途中まで | タスクの「タスクを停止するまでの時間」（実行時間の上限） |
| ある日だけ、出力が丸ごと無い | まず電源・スリープの条件を除外し、そのうえで前工程の出力を待つ「待ち時間」の設定値 |
| ノートパソコンで、ある日だけ動かない | 「条件」タブの「コンピューターをAC電源で使用している場合のみタスクを開始する」と、スリープ関連の設定 |
| 最近、開始時刻を変えた記憶がある | 上限・待ち時間を連動して見直したかどうか |
| 同じ処理が二重に走っている気配 | 「設定」タブの「既に実行中の場合の規則」（新規開始しない、になっているか） |
| 手動なら動くが自動だと動かない | 「全般」タブの実行ユーザーと、ログオン中に実行する設定かどうか |
| 手順書の説明と実際の動きが違う | 説明文が昔の仕様のまま残っていないか |
「毎回途中で終わる」の正体は、実行時間の上限
タスクスケジューラには「タスクを停止するまでの時間」という項目があります。設定ファイル上の名前は ExecutionTimeLimit（実行時間の上限）。ここに書いた時間を超えても処理が終わらなければ、Windowsがタスクごと止めます。
これは本来ありがたい機能です。処理が固まって永久に居座るのを防ぐ、いわば非常ブレーキ。問題は、このブレーキが正常に終わるより先に効いてしまう場合があること。
筆者の例で言うと、こうでした。
- 自動実行の開始時刻：08:00
- 設定していた実行時間の上限：7時間
- つまり強制終了される時刻：08:00 ＋ 7時間 ＝ 15:00
- やりたい処理が終わる予定時刻：15:30
終わる30分前に、非常ブレーキが先に効く——という配置になっていました。この時刻に実際に切られた朝はまだ来ておらず、設定を読み返して足し算した時点で見つけています。
そのまま走らせていたら厄介だったのは、これがエラーとして目立たないことです。プログラムが自分で「異常です」と叫ぶわけではなく、外側から電源を落とされるのに近い。ログの最後は普通の行で終わり、出力ファイルだけが中途半端に残る。「なんとなく毎回途中」という、いちばん気づきにくい壊れ方になります。
逆に言えば、止まる時刻がいつも同じなら、それは強い手がかりです。処理の内容によって重い日・軽い日があるのに、切れる時刻だけ毎回そろっている。中身の問題ではなく、外側の時間設定の問題を疑う場面です。
なぜ上限がズレたのか（実録・置き去りにされた7時間）
7時間という値は、適当に決めたものではありませんでした。むしろ当時は正しかった。
設定した当初、この自動実行の開始時刻は 08:59 でした。08:59 ＋ 7時間 ＝ 15:59。処理の終了予定は 15:30 ですから、当時は約30分の余裕がある妥当な値だったわけです。
その後、開始時刻を 08:00 に前倒ししました。しかもこれは、気まぐれな変更ではありません。別の不具合を直すための修正でした。08:59 開始では前工程の準備が間に合わず、その日の収集がまるごとゼロになる日が実際にあったのです。だから起動を59分早めた。トリガー（起動条件）の時刻を1か所書き換えて、動作確認して、終わり。
このとき、上限の側を見直さなかった。不具合を直す変更が、別の不具合を仕込んだわけです。
片方だけ動かして、もう片方が取り残された。開始が59分前倒しになった分、上限も59分手前に移動している——頭では分かる話です。一般に、タスクスケジューラの画面では開始時刻とこの上限は別のタブに置かれています。トリガーは「トリガー」タブ、上限は「設定」タブ。編集中に目に入らない項目は、連動しているという意識を持ちにくい。それも確かにあります。
ただ、筆者の場合はもっと救いのない配置でした。この2つの値は、画面ではなく登録用のスクリプト1本の中に、十数行しか離れずに並んでいたのです。開始時刻の行を書き換えるとき、上限の行は同じ画面の中に映っていました。それでも片方だけ直した。
つまり「同じ画面・同じファイルに並んでいても見落とす」。目に入る場所に置けば防げる、という話ではなかったわけです。だから対策も、配置の工夫ではなく手順に落とすしかない。時刻を触ったら、その日のうちに「開始＋上限＝何時になるか」を電卓で1回出す。これだけで防げました。
直し方：上限は消さず、実測に合わせて伸ばす
変更前に、いまの値をメモ帳に控えておいてください。ここから先は設定を書き換える話です。
筆者が入れた修正は、上限を 7時間 → 8時間 に変えただけです。08:00 ＋ 8時間 ＝ 16:00。終了予定の 15:30 に対して30分ぶんの余地があります。この30分は空き時間ではなく、処理が終わったあとの後片付け（ファイルを閉じる、記録を書く）にかかる時間として見込んだものです。
この8時間や、あとで出てくる65分は筆者の環境の実測から出した値です。そのまま写さず、必ず自分の処理の終了予定時刻から計算し直してください。10時間かかる処理に8時間の上限をかければ、この記事を読んだせいで毎回強制終了される、という笑えない事態になります。
ここで大事なのは、上限そのものは撤廃しなかったこと。「もう二度と切られたくないから、上限なしにする」は一見スマートですが、処理が固まったときに止める人がいなくなります。翌朝までパソコンを占有し続ける自動処理は、途中で切れる自動処理よりたちが悪い。非常ブレーキは、位置を直すもので、外すものではありません。
「ある日だけ丸ごと空振り」は、待ち時間が1分足りなかった
もうひとつ、症状の出方がまったく違う問題も同時に見つかりました。こちらは「毎回途中」ではなく「ある日だけ、丸ごと何も出ない」タイプです。毎日ではなく、条件がそろった日にだけ起きます。
筆者の自動処理は、前の工程（筆者の場合は、毎朝こちらが手で走らせる別のツールです。ここは自動化できていません）が作るファイルを待ってから本番の処理を始めます。前工程がまだ終わっていないのに走り出しても、材料が無いので意味がない。だから「出てくるまで待つ」設計にしてありました。
その待ち時間の既定値が 55分。08:00 に始まって、55分待って、来なければあきらめる。60秒おきに「まだかな」と確認しに行く方式です。
ここで細かいようですが大事な点。この55分は起動時刻ちょうどから数え始めるわけではありません。起動直後の前処理（多重起動の確認、対象日の判定）を終えてから待ち始めるので、打ち切りはきっかり 08:55:00 ではなく、そこから数十秒うしろにずれます。
そして実際の記録を調べたら、いちばん遅かった日の前工程の完了時刻は 08:55:36 でした。
差は1分に満たない。
あと1分足らず待てば材料は届いていたのに、その直前に見切りをつける設定になっていた、ということです。なお、この設定で実際に空振りした日があったわけではありません（打ち切りの実時刻が秒単位で残っていないので、何秒差だったかも断定できません）。過去の記録の中に、いまの待ち時間なら取りこぼしていたはずの日が1件あった、という話です。
もし起きていれば、こういう見つけにくさになります。「たまたま前工程が遅かった日だけ」再現するので、翌日はふつうに動いてしまう。原因を突き止める前に忘れてしまう類のバグです。
変更前に、いまの値をメモ帳に控えておいてください。そのうえで、直し方は待ち時間を 65分（およそ 09:05 まで）に延長。実測の最遅 08:55:36 に対して約9分の余裕を確保しました。確認の間隔（60秒ごと）はそのままです。頻度を上げてもパソコンが忙しくなるだけで、届く時刻は早くなりません（この65分も筆者の実測から出した値です。そのまま写さないでください）。
ここでも、やらなかったことのほうが大事かもしれません。無限に待つようにはしていないし、待ちきれなかった日に前日のデータで代用することもしない。古い材料で「それらしい結果」を作るほうが、何も作らないより危ないからです。空振りは、空振りとして記録に残す。
自分のパソコンで確認する5ステップ（読み取りだけ）
ここから先は、設定を書き換えずに現状を読み出すだけの手順です。まず「今どうなっているか」を確定させてから、直すかどうかを決めてください。
- タスクスケジューラを開く。スタートメニューで「タスク スケジューラ」と入力すれば出ます。左側のツリーから、自分が登録したタスクを探します。
- 開始時刻を控える。タスクをダブルクリックして「トリガー」タブ。何時何分に始まる設定になっているかをメモします。
- 上限を控える。同じ画面の「設定」タブにある「タスクを停止するまでの時間」。既定では3日になっていることが多く、自分で短く変えていれば、その値です。
- 足し算する。開始時刻 ＋ 上限 ＝ 強制終了される時刻。この結果が、処理が終わる予定時刻よりあとに来ているかを見ます。前に来ていたら、それが原因の候補です。
- 待ち時間を探す（原本は開かない）。前工程の完了を待つ処理があるなら、その待ち時間はタスクスケジューラではなく、スクリプト側に書かれています。順番はこうです。(a) スクリプトのファイルを右クリック→コピーし、デスクトップに貼り付けて、そのコピーのほうを開く（原本は開かない）。(b) コピーを右クリック→「プログラムから開く」→メモ帳を選び、Ctrl＋F で「Wait」「Timeout」「Minutes」を1語ずつ検索する。(c) 見つかった値を紙かメモ帳に書き写し、保存せずに右上の×で閉じる。
5番目だけ、少し探しにくいかもしれません。スケジューラの画面には出てこないからです。「タスクスケジューラを全部見たのに見つからない」と感じたら、設定の置き場所が2か所に分かれていることを思い出してください。外側の上限はWindows側、内側の待ち時間は自分のスクリプト側です。
コピーのほうを開くのは、慎重すぎる作法ではありません。動いているスクリプトを直接開くと、キーが1つ当たって書き換わったり、エディタが文字コードを勝手に変換したりして、翌朝から自動処理が止まることがあります。しかも気づくのは翌日以降で、原因が「昨日、中を見ようとして開いたこと」だとは、まず結びつきません。読むだけならコピーで足ります。
「前回の実行結果」だけで判断しない
タスクスケジューラの一覧には「前回の実行結果」という列があります。ここが正常終了を示す表示（0x0）になっていても、安心はできません。この列は「起動したプログラムがちゃんと終了したか」しか表さないからです。中身が空っぽでも、材料が来なくて何も集められなくても、プログラムが自分の判断で行儀よく終われば 0x0 になります。
筆者の記録にも、まさにその日があります。前回の実行結果は 0x0（正常終了）なのに、その日の収集はゼロ。起動が遅すぎて前工程に間に合わなかった日でした。表示だけを見ていたら、何事もなかった日として通り過ぎていたはずです。
いっぽう、実行時間の上限で止められた場合は表示が変わります。この場合は 0x41306（前回の実行はユーザーによって終了されました）になるのが一般的です。「自分は止めた覚えがないのに、ユーザーによって終了と出ている」なら、止めたのはあなたではなく上限だと考えてよい場面です。
まとめると、判断材料は実行結果の表示より出力ファイルの中身。何時何分のデータまで入っているか。それが毎回同じ時刻でぷつりと終わっていたら、時間設定を疑う番です。
二重に走っている気がするとき
同じ処理が重なって動いている気配があるなら、見るのは「設定」タブの「既に実行中の場合の規則」です。ここが「新しいインスタンスを開始しない」になっていれば、前回がまだ走っている間は新しく起動しません。「並列で実行する」になっていると、遅い日に2本走って同じファイルを取り合います。迷ったら「新しいインスタンスを開始しない」が安全側です。
手動なら動くのに、自動だと動かないとき
この場合は「全般」タブの実行ユーザーと、その下の「ユーザーがログオンしているときのみ実行する」を見ます。別のユーザーで実行する設定になっていれば、あなたのデスクトップやネットワークドライブが見えず、材料にたどり着けません。逆に「ログオンしているときのみ実行する」なら、ログオフしていた朝はそもそも動きません。手で走らせたときと同じ条件になっているか、を確かめる場所です。
直すときに避けたい3つのやり方
原因が分かると、つい大きく振ってしまいます。筆者が意識的に避けたのは次の3つです。
1. 上限を外す・極端に長くする
切られると分かったのが悔しいからといって、上限をなしにしたり丸1日にしたりすると、固まったときの歯止めが消えます。必要なのは「正常な終了より少しあと」であって、「限りなく先」ではありません。
2. 実測を「分」に丸めて決める
1分足らずの差で取りこぼしかけた話が、この教訓そのものです。ここが自分でも意外だったのですが、55分という値は感覚で置いたものではありませんでした。過去の記録は見ていたのです。「前工程は 07:00〜08:55 に出てくる」と分布まで確認したうえで、いちばん遅い 08:55 を覆うつもりで55分にしていました。
落とし穴は、その先にありました。実測を「分」の単位に丸めたことです。記録上の最遅は 08:55 ではなく 08:55:36。丸めた瞬間に、36秒ぶんの裾が視界から消えていました。事故は平均ではなく端で起きるのに、その端を自分で削ってしまったわけです。
だから教訓は「実測を見る」ではなく、実測をどこまでの細かさで見るか。秒まで残っている記録なら、秒のまま扱う。丸めるなら、丸めた方向に余裕を足す。確認は数分で終わります。
3. 間に合わなかった日を、古いデータでごまかす
「前日のファイルで代用する」は、その場では穴が埋まったように見えます。けれど後から見返したとき、どの日が本物でどの日が代用かが分からなくなる。欠けた日は欠けたままにして、記録に「来なかった」と残すほうが、あとで直せます。
説明文が古いままだと、次の自分が迷う
同じ日にもう1つ直しました。設定を登録するためのスクリプトの先頭に書いてあった説明文が、すでに廃止した昔の動き方を現在の動きとして説明していたのです。
実害はすぐには出ません。動くのはコードであって、コメントではないからです。しかし半年後に自分が読み返したとき、あるいは調子が悪くて原因を探しているとき、この説明文は間違った方向へ全力で案内してくる。「書いてある動きと違うぞ」と悩んだ時間は、丸ごと無駄になります。
だから、同じファイルを開いたついでに現行の流れへ書き直しました。「あとで整える」と付箋を貼ると、その付箋は永遠に剥がれません。触ったファイルの説明文は、その場で現在形に直す。手間としては数分です。
非エンジニアが得た教訓
時刻の設定は、単独では存在しない。 開始時刻を1か所ずらしたら、そこから数えている上限や待ち時間もいっしょにずれます。別のタブに分かれていても、同じファイルに十数行差で並んでいても、見落とすときは見落とす。だから頭の中で束にして扱い、時刻を触った日は「開始＋上限＝何時？」を必ず1回計算する。これが今回いちばん高くついた学びでした。
安全装置は、位置を直すもので、外すものではない。 上限に切られたときの正しい反応は「上限を消す」ではなく「上限を実測に合わせて置き直す」。待ちきれなかったときの正しい反応も「無限に待つ」ではなく「実測の裾を覆う長さにする」。どちらも、止まるべきときに止まる性質は残したままです。
数字は、測ったあと「どこまで細かく見るか」でも負ける。 1分足らず足りなかった、という結末は、実測を見なかったせいではありません。実測を見たうえで分単位に丸め、秒の裾を落としたせいです。記録が秒まで残っているなら秒で扱う。丸めるなら、丸めた方向へ余裕を足す。事故は平均ではなく端で起きます。
そして、静かに壊れるものほど長生きする。 派手に落ちる不具合は翌日には直ります。今回の2つは、どちらも起きたときに「エラーが出ない壊れ方」をする種類でした。毎回同じ時刻で途切れる出力、たまにしか起きない空振り。今回は初回の実行を迎える前に計算で見つけられましたが、それは運が良かっただけです。定期的に動くものは、動いていること自体を確認する日を決めておくほうがいい——というのが、いまのところの結論です。
まとめ
- 毎回同じ時刻で途中まで → タスクスケジューラの「タスクを停止するまでの時間」を疑う。開始時刻＋上限を計算して、終了予定より前に来ていないか確かめる
- ある日だけ丸ごと出ない → まずノートパソコンの電源・スリープ条件を除外し、次に前工程を待つ待ち時間を疑う。待ち時間はスケジューラではなくスクリプト側に書かれている
- 筆者の実例は、開始 08:00 ＋ 上限7時間 ＝ 15:00 で、終了予定 15:30 の30分前に切られうる状態。上限を8時間に伸ばして解消した（上限は残した）。実際に切られる前に、点検の計算で見つけている
- 待ち時間は55分（08:55 を数十秒過ぎたあたりで打ち切り）で、実測の最遅 08:55:36 を1分に満たない差で取りこぼす設定だった。65分に延長（無限には待たせない）
- 開始時刻を変えた日は、上限と待ち時間をセットで見直す。値は過去の記録の「いちばん遅かった日」に合わせ、分に丸めずに秒まで見る
- 記事に出てくる8時間・65分・30分は筆者の環境の実測値。そのまま写さず、自分の処理の終了予定時刻から計算し直す
- 触ったファイルの説明文が古いままなら、その場で現在形に直す
設定を変える前に、現在の値をメモ帳に控えておいてください。直したつもりが別の不具合を呼んだとき、元に戻せるかどうかで復旧時間がまったく違います。
関連記事
無料テンプレート配布のお知らせ
Claude Codeを安全・便利に使うための設定テンプレート（CLAUDE.md）を無料配布しています。メールアドレスをご登録いただくと、すぐにダウンロードリンクをお送りします。
免責事項
本記事は執筆時点（2026年8月）の情報に基づく、筆者個人の体験の記録です。記事中の自動売買システムに関する記述は、特定の投資手法や自動売買の利用を推奨するものではありません。投資には元本割れのリスクがあり、最終的な判断はご自身の責任で行ってください。また、本記事ではセキュリティに関わる話題に触れていますが、悪用防止の観点から、具体的な脆弱性や攻撃手法の詳細は記載していません。AIツールの仕様は予告なく変更される場合があります。最新情報は各公式ドキュメントをご確認ください。本記事の内容を用いて生じたいかなる損害についても、筆者は責任を負いかねます。
コメント