セイテクエンジニアのブログかつて山市良と呼ばれたおじさんのブログ vol.214　タスクスケジューラとサマータイム（DST）: 丑三つ時が消えない日本でよかった｜セイテク・シス管道場（Web）

vol.214　タスクスケジューラとサマータイム（DST）: 丑三つ時が消えない日本でよかった｜セイテク・シス管道場（Web）

2026年06月29日配信
2026年06月29日更新
執筆者：山内和朗

　「セイテク・シス管道場（Web）」では、Windows Serverの要素技術やシステム管理の基本的な部分に焦点を当ててきました。シリーズ最終回も近い今回も、引き続きタスクスケジューラとタスクの話。日本では馴染みの薄いサマータイム（DST《Daylight Saving Time》）のスケジュールへの影響について。

DSTの開始/終了日にタスクが実行されない/2度実行される問題

　丑三つ時とは少し曖昧さのある時刻表現ですが、一般にAM2:00～2:30頃を指すと言われています。多くの国ではサマータイム（DST）が採用されており、開始日時や終了日時は各国で異なりますが、米国の場合、それは3月第2日曜日のAM2:00に始まり、タイムゾーンはPST（米国太平洋標準時《UTC-8》）からPDT（アメリカ太平洋夏時間《UTC-7》）に切り替わって時刻が1時間進みます（AM1:59→AM3:00）。そして、11月第1日曜日のAM2:00に終了し、タイムゾーンはPSTに戻され、時刻が1時間戻ります（AM1:59→AM1:00）。つまり、DSTへの切り替えのその日、日本の丑三つ時を含むAM2:00～2:59は米国に存在しません。

　幸いなことに、現在の日本にはDSTが導入されていませんが、戦後数年導入されたことがあったそうです。その後も、DST導入の議論が何度か湧きあがりましたが、結局、導入には至っていません。DSTが導入されている国々の多くは、ITシステムが普及するずっと前からこの制度が導入されていました。しかし、DSTに馴染みのない日本においては、日照時間の有効活用（近年では酷暑対策）の効果が薄く、導入による社会的コストとリスクが見合わないということのようです。だからといって、将来、導入されないとも言い切れません。今後も酷暑が進むと、再び議論に上がる可能性はあります。

　さて、米国を例にしますが、DST開始日（今年は2026年3月8日AM2:00）に丑三つ時を含むAM2:00～2:59が消える問題は、タスクスケジューラには大きな影響があります（図1）。タスクスケジューラは原則として、ローカル時間でスケジュールが評価されます。DST開始日に、毎日や曜日指定でAM2:00～2:59にスケジュールされたタスクは実行されません。タスクには「スケジュールされた時刻にタスクを開始できなかった場合、すぐにタスクを実行する」オプションがありますが、このオプションがオンになっていたとしても、タスクが実行されることはありません。なぜなら、スケジュールされた日時は存在しない時刻だからです。

図1:　DST開始日のAM2:00～2:59の間の時刻にスケジュールされたタスクは、その時間帯自体が存在しないためトリガーされず、実行されない

　一方、DSTの終了日（今年は2026年11月1日AM2:00）、AM1:00～1:59が2回繰り返されることになります（図2）。そのため、この期間にスケジュールされたタスクは2回実行される可能性があります。可能性があるとしたのは、タスクの設定により、タスクが既に実行中の場合の扱いを設定できる（例、新しいインスタンスを開始しない）からです。

図2　DST終了日には、AM1:00～1:59の間の時刻が2回存在するため、この時間帯にスケジュールされたタスクは2回トリガーされる可能性がある

　繰り返し実行のタスク（毎時など）はDSTの影響を受けないものの、DST開始時には実行回数が減り、DST終了時には実行回数が増えるなど、実行回数の観点では影響を受けます。

「タイムゾーン間で同期」で問題緩和も、完全に解決できない理由

　サマータイム（DST）とタスクスケジューラ（タスク）についてインターネットを検索すると、“「タイムゾーン間で同期」をオンにすることで、DSTの影響を受けずに指定時刻にタスクを実行できる”というような検索結果が出てくると思います。半分正しいですが、この表現は誤解を招きかねません。「タイムゾーン間で同期」をオンにすると、開始日時をUTC（協定世界時）で保存し、そのUTC時刻にタスクが実行されるようになります（画面1）。そのUTC時刻は一度しか発生しません。しかし、タスクスケジューラの表示はあくまでローカル時刻なので、指定時刻に実行されるのではなく、実際にはAM2:30にスケジュールされたタスクがAM3:30に実行されたり（DST開始後）、AM1:30に実行されるタスクがAM0:30に実行されたり（DST終了後）することになります。UTC時刻では同じ日時なので、その点ではDSTの影響は避けられます。しかし、タスクスケジューラ上での表示はあくまでもローカル時刻なので、開始時刻によっては（ローカル時刻の）日付が変わってしまう可能性があり、その結果、同じ日に2回実行されたように見えることがあります（例、DSTでAM0:30にスケジュールされたタスクが、DST終了後には同日の23:30に実行される）。

画面1　2026年3月1日に8日AM2:30にスケジュールしたタスクdemo01（タイムゾーン間で同期オフ）とタスクdemo02（タイムゾーン間で同期オン）。demo01の次回実行時刻は存在しないその日の2:30を飛ばして1日後に、demo02のトリガーと次回実行時刻はAM3:30に。タイムゾーン間で同期オンの開始日時はISO 8601形式（日時とタイムゾーンを一意に表す形式）で保存、実行されるが、UTCに変換すると8日AM10:30

画面2　DST切り替え直後の状態。demo02に保存されている開始日時が「2026-03-07T02:30:00-07:00」から「2026-03-07T03:30:00-08:00」に変わったが、UTCだと変更なし（どちらも2026年3月8日 10:30《UTC》）

　「タイムゾーン間で同期」をオンにすれば、タスクのスキップや重複実行の可能性は解消されますが、完全に解決されるわけではありません。「タイムゾーン間で同期」のオン/オフに関係なく、DST開始日時と終了日時の影響を受ける時間（AM1:00～2:59、DST開始日のAM2:00～2:59とDST終了日のAM1:00～1:59）でのスケジュール設定を避けることをお勧めします。また、「タイムゾーン間で同期」をオンにした場合、日付のずれの影響（短い間隔で2回実行されたように見える現象）を吸収するためには、タイムゾーンごとにタスクをスケジュールしても安全な時間帯にスケジュール設定することを考慮するべきです。例えば、米国時間ならAM3:00～23:59の間にスケジュールされたタスクであれば日付のずれは起きにくいでしょう。

　サーバーやクラウド上のインスタンスでは、OSのタイムゾーンをUTCにして運用するのがベストプラクティスであり、クラウドではそれが一般的（既定値）です。ローカル時刻の概念を捨て、すべてUTC基準で扱うのです。UTCでは時間が常に連続するため、タスクのスキップや重複実行は完全に排除できます。クラウドの場合は、ログの日時が一貫する上、複数リージョンに分散したシステムでも時差を気にする必要がありません。ユーザーへの影響は、追加の時計として特定のタイムゾーンを設定してあげれば解消できるでしょう（画面3）。

画面3　クラウドではOSのタイムゾーンはUTC（この画面では現地時間）が一般的。ローカル時刻は、追加の時計で表示させることも

　DSTが導入されていない日本国内であれば、DSTの影響を意識する必要はまったくありません。しかし、海外が拠点の外資系企業、クラウドサービスと連携する場合、海外の顧客に対応する場合など、DSTやタイムゾーンの違いの影響とは無縁ではいられない可能性が高くなります。私自身はこれまでDSTとはまったく無縁で生きてきましたが、この記事を仕上げる過程でもかなり混乱しました。改めて、丑三つ時が消えない日本で本当によかったと感じています。丑三つ時には幽霊が出そうで怖い印象がありますが、システム的には、丑三つ時が忽然と消えてしまうことのほうが、よほど怖いことです。