夜間バッチ・定期処理の設計：失敗の検知と安全な再実行の考え方

夜間バッチや定期処理の設計で最も大切なのは、「失敗しないこと」よりも「失敗したらすぐ気づけて、何度やり直しても結果が壊れないこと」です。外部サービスの一時的な不調、想定外のデータ、サーバーの再起動など、定期処理が止まる原因は完全には取り除けません。だからこそ、失敗と未実行を確実に検知する仕組みと、同じ処理を二回流しても二重登録や二重送信が起きない作り（冪等性）を、最初から設計に組み込んでおく必要があります。

この記事は、売上集計、データ同期、請求書の作成、メール配信といった定期処理を自社サービスや社内業務で動かしている事業責任者、開発や運用の担当者、そして「朝来たらバッチが止まっていて、どこまで処理されたか分からない」という経験をした方に向けて書いています。バッチ処理の失敗パターン、検知の仕組み、安全な再実行のための設計原則、運用手順の整え方を順番に説明します。

読み終えたときに、自社の定期処理のどこに弱点があるかを点検し、開発会社や社内の担当者と「どう直すべきか」を具体的に話せるようになることを目指しています。

バッチ処理・定期処理とは何か

バッチ処理とは、データをためておき、決まったタイミングでまとめて処理する方式のことです。用語の詳細はバッチ処理の解説ページにまとめています。業務システムや自社サービスでは、次のような処理がバッチとして動いていることが多くあります。

• 前日の売上や利用状況を集計し、レポートやダッシュボードに反映する
• 外部サービス（決済、会計、EC、CRMなど）とデータを同期する
• 月次の請求データを作成し、請求書を発行・送付する
• 期限が近い契約や未払いの顧客にリマインドメールを送る
• 古いデータの削除や、バックアップの取得を行う

これらは利用者の操作とは関係なく、夜間や早朝など決まった時刻に自動で動きます。画面を持たないため、止まっていても誰も気づかない、というのがバッチ処理特有の怖さです。画面のエラーなら利用者が教えてくれますが、バッチの失敗は「翌朝のレポートの数字がおかしい」「顧客から請求書が届かないと連絡が来た」といった形で、時間が経ってから表に出ます。

バッチ処理が失敗する典型的なパターン

設計を考える前に、どんな失敗が起こりうるかを整理しておきます。

この表から分かるように、「エラーが出たら通知する」だけでは半分以上の失敗を見逃します。特に、実行されなかったケースと、成功扱いだが中身が誤っているケースは、意識して検知の仕組みを作らない限り見つかりません。

失敗を検知する仕組みの設計

検知の仕組みは、次の三段構えで考えると抜けが少なくなります。

1. 異常終了の通知

処理がエラーで終わったときに、チャットやメールに通知を送ります。最も基本的な仕組みですが、通知先が個人のメールだと、休暇や退職で見られなくなります。チームで見るチャンネルに送り、誰が確認するかを決めておきます。通知には、どのバッチが、いつ、どこで、どんなエラーで止まったかを含めると、初動が速くなります。

2. 未実行・未完了の検知

「決まった時刻までに完了の記録がなければ警告する」仕組みです。バッチが正常に終わったら完了時刻を記録し、別の監視の仕組みがその記録を定期的に確認します。予定の時刻を過ぎても完了の記録がなければ、実行されなかったか、途中で止まったか、時間がかかりすぎていると判断して通知します。バッチ自身がエラーを報告する仕組みとは別に、外側から見張る仕組みを持つのがポイントです。監視全般の考え方はサービス監視とアラートの設計でも解説しています。

3. 結果の妥当性チェック

処理が正常に終わっても、結果がおかしいことがあります。処理件数が普段より極端に少ない・多い、合計金額が前日と大きく違う、といった条件で警告を出します。たとえば「普段は数百件ある注文の同期が0件だった」という状況は、エラーにはなりませんが、多くの場合は連携先の不調か設定の誤りです。毎回の処理件数と所要時間を記録しておけば、こうした変化に気づけます。

この三つがそろうと、「止まった」「始まらなかった」「動いたが結果がおかしい」のいずれにも気づけるようになります。システムの稼働を見張る監視（システムモニタリング）の考え方を、バッチ処理にも当てはめるイメージです。

安全な再実行のための設計原則

失敗に気づいたら、次は再実行です。このとき「とりあえずもう一度流す」で問題が起きないように作っておくことが、バッチ設計の要になります。

冪等性：何度実行しても結果が同じになる

冪等性（べきとうせい）とは、同じ処理を何回実行しても、一回実行したときと同じ結果になる性質のことです。バッチ処理では、これが再実行の安全性を決めます。

冪等でない処理の例は、「注文データを取得して、売上テーブルに行を追加する」というものです。途中で失敗して再実行すると、前回すでに追加した行がもう一度追加され、売上が二重に計上されます。冪等にするには、次のような工夫をします。

• 追加ではなく「あれば更新、なければ追加」にする。注文番号など一意のキーで判定する
• 対象期間のデータを一度消してから入れ直す（集計結果のように作り直せるデータの場合）
• 送信済み・処理済みのフラグを記録し、済んでいるものは飛ばす

特にメール送信や決済、外部への書き込みなど、取り消せない処理は、処理済みの記録を必ず残し、再実行時に重複しないようにします。

処理の単位を小さくし、途中から再開できるようにする

一万件のデータを一つの大きな処理で扱うと、九千件目で失敗したときに、どこまで済んだかが分からなくなります。一件ずつ、あるいは一定の件数ごとに処理済みの記録を残しておけば、失敗した箇所から再開できます。処理対象の日付や期間を引数で指定できるようにしておくと、「三日前の分だけやり直す」といった再実行も簡単になります。

二重起動を防ぐ

前回の処理がまだ終わっていないのに次の処理が始まると、同じデータを二つの処理が同時に扱い、結果が壊れることがあります。処理の開始時に「実行中」の印を付け、印があれば新しい処理は始めないようにする排他制御を入れます。手動での再実行と自動実行が重なるのを防ぐ意味でも重要です。

外部サービスの一時的な失敗は自動で再試行する

外部APIの一時的なエラーやタイムアウトは、少し待ってからやり直せば成功することが多くあります。回数と間隔に上限を設けて自動で再試行し、それでも失敗したら通知する、という二段構えにします。連携処理のリトライと不整合への備えは、API連携の障害対策：リトライ設計とデータ不整合への備え方で詳しく扱っています。

設計時に決めておくべき項目

開発会社や社内の担当者にバッチ処理を依頼するときは、次の項目を決めておくと、後から「失敗したらどうするのか」で困ることが減ります。

特に依存関係は見落とされがちです。「データ同期が終わってから集計する」「集計が終わってからレポートを配信する」という順序がある場合、時刻をずらして並べるだけでは、前の処理が遅れたときに崩れます。前の処理の完了を確認してから次を始める仕組みにしておくと安全です。

バッチを動かす仕組みの選び方

バッチをどこで、何を使って動かすかも、検知と再実行のしやすさに影響します。代表的な方法を比べておきます。

注意したいのは、最後の「個人のPCでの定期実行」です。担当者のPCでスクリプトやマクロを定時に動かしている場合、そのPCがスリープしていた、更新プログラムで再起動していた、担当者が長期休暇で電源を切っていた、といった理由で簡単に止まります。業務で頼っている処理なら、共有のサーバーやクラウド環境に移すことを優先して検討してください。

どの方法を選ぶ場合でも、「実行履歴を誰でも見られること」「失敗と未実行を通知できること」「手動で範囲を指定して再実行できること」の三点を満たしているかを確認します。この三点を満たせない仕組みは、作った人がいなくなった時点で、中身の分からない処理になってしまいます。

運用手順を整える：再実行を誰でもできるようにする

設計がしっかりしていても、再実行の方法を作った人しか知らなければ、担当者不在時に止まります。バッチごとに次の内容を手順書にまとめておきます。

1. このバッチが何をしているか、止まると何に影響するか
2. 失敗の通知が来たときに最初に確認すること（ログの場所、よくあるエラー）
3. 再実行の手順と、範囲の指定方法
4. 再実行してはいけない状況（たとえば、外部への送信が一部済んでいる場合）と、その場合の連絡先
5. 手作業で代替する方法（バッチが直るまで業務を回すための手順）
6. 復旧後に確認すること（件数、合計値、関係者への連絡）

手順書の書き方全般は運用手順書（Runbook）の作り方で詳しく説明しています。手順書は、実際に再実行が発生したときに使ってみて、分かりにくかった点をその場で直すと、だんだん実用的になっていきます。

よくある失敗とその避け方

• エラー通知だけで安心し、未実行に気づかない：完了の記録を外側から確認する仕組みを別に用意する。成功時にも短い完了通知を出すと、通知が来ないことで異常に気づける。
• 再実行で二重請求・二重送信が起きる：取り消せない処理には処理済みの記録を必ず残す。再実行前に、どこまで済んでいるかを確認する手順を手順書に入れる。
• タイムゾーンや日付の境界で処理対象がずれる：サーバーの時刻設定と業務上の日付の定義をそろえる。深夜0時をまたぐ処理は、対象期間を明示的に指定する。
• データ量の増加で処理時間が延び続ける：毎回の所要時間を記録し、完了期限に近づいてきたら処理の分割や見直しを検討する。
• バッチがいくつあるか誰も把握していない：実行中のバッチの一覧を作り、担当者、実行時刻、依存関係を記録する。現場で作られたスクリプトや自動化ツールも含めて管理する。

具体的な場面の例

架空の一般的な例で考えてみます。

会員制のWebサービスを運営する会社で、毎晩深夜に「前日の利用データを集計して、翌朝のダッシュボードに反映する」バッチと、「月初に前月分の利用料を計算して請求データを作る」バッチが動いていたとします。ある月初、請求データ作成のバッチが外部の決済サービスの一時的な不調で途中まで処理して止まりました。担当者が翌朝気づいて手動で再実行したところ、途中まで作られていた請求データが二重に作成され、一部の顧客に二通の請求メールが届いてしまいました。

この会社が行った対策は三つです。一つ目は、請求データの作成を顧客ごとに「作成済み」の記録を残す形に改め、再実行しても作成済みの顧客は飛ばすようにしたこと。二つ目は、請求メールの送信を作成とは別の処理に分け、作成結果の件数と合計金額を担当者が確認してから送信する手順にしたこと。三つ目は、月初の決まった時刻までに完了の記録がなければ警告する監視を加えたことです。あわせて、再実行の手順と、再実行してはいけない状況を手順書にまとめました。

毎晩の集計バッチについても、処理件数と所要時間を記録するようにしたところ、会員数の増加に合わせて所要時間が少しずつ延びていることが分かりました。完了期限まではまだ余裕がありましたが、このままでは数か月後に朝の業務開始に間に合わなくなる見込みだったため、集計を日別に分けて並行して処理する形へ早めに見直しています。記録を取っていなければ、ある朝突然ダッシュボードが空になって初めて気づいていたはずです。

このように、バッチの失敗そのものは防げなくても、失敗後の被害は設計と手順で大きく小さくできます。

バッチ処理設計のチェックリスト

• 動いているバッチの一覧があり、担当者と実行時刻が分かる
• 異常終了したときに、チームで見る場所へ通知が届く
• 予定の時刻までに完了していないことを検知できる
• 処理件数や合計値が普段と大きく違うときに気づける
• 同じ処理を二回実行しても、二重登録や二重送信が起きない
• 処理対象の期間を指定して再実行できる
• 前回の処理が終わる前に次の処理が始まらない
• 外部サービスの一時的な失敗は、上限付きで自動再試行される
• 依存関係のある処理は、前の処理の完了を確認してから始まる
• 再実行の手順書があり、作成者以外も実行できる

よくある質問

Q. 既に動いているバッチが冪等かどうかは、どう確かめればよいですか？

開発担当者に「この処理を同じ条件で二回続けて実行したら、データはどうなるか」を聞くのが早道です。答えがすぐに出ない場合は、テスト環境で実際に二回実行して結果を比べてみます。二重登録や二重送信が起きるなら、再実行の手順を整える前に、処理の作りを見直す必要があります。

Q. 小さなサービスでも、ここまでの監視が必要ですか？

規模にかかわらず、請求や顧客への送信など、間違えると取り返しのつかない処理には必要です。一方、社内向けの集計のように、遅れても影響が小さく作り直せる処理なら、異常終了の通知と簡単な手順書から始めても構いません。処理ごとの影響の大きさで、手当ての厚さを変えましょう。

Q. バッチ処理をやめて、リアルタイムの処理に変えるべきでしょうか？

即時に反映したいデータが多いなら検討の価値があります。ただし、リアルタイム処理にも失敗時の再試行や不整合への備えは必要で、仕組みはかえって複雑になることもあります。まとめて処理した方が効率的な集計や請求は、バッチのままで監視と再実行を整える方が現実的な場合が多くあります。

Otsumuに相談できること

バッチの数が少なく、作った人が社内にいて、処理の中身を説明できる状態であれば、この記事のチェックリストを使って弱点を洗い出し、自社で改善を進めることは十分可能です。まずは異常終了の通知と、完了期限を過ぎたときの警告、再実行の手順書の三つから整えてみてください。

一方で、作った人がいなくなって中身が分からない、再実行のたびに二重登録が起きて手作業で直している、データ量の増加で処理が朝までに終わらなくなってきた、といった状況では、処理の作りそのものを見直す必要があります。原因の調査と設計の見直しには、システムの中身を読み解ける技術者の関与が欠かせません。

Otsumuでは、動いている定期処理の棚卸しと弱点の診断から、冪等性や再開性を持たせる作り直し、監視と通知の設計、運用手順書の整備までを一貫して支援しています。自らも事業を運営する立場から、止まっても慌てない運用を一緒に作ります。詳しくは自社サービス運用の自動化コンサルティングやシステム保守・運用のページをご覧ください。

自社のバッチ処理のどこから手を付けるべきか、まずは30分の無料相談で状況を伺いながら整理するところからお手伝いします。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01