LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

夜のうちに終わるはずのバッチ処理が、朝になっても終わっていない。オンラインの受付を始める時刻が迫っている——。バッチ処理遅延調査とは、決まった時間帯にまとめて流す処理（バッチ処理）が予定の時刻までに終わらなかったときに、どのジョブで時間がかかったのか、なぜそうなったのかを確かめる作業を指します。性能改善のための調査を外部エンジニアに頼む場面では、処理を速くする手を考える前に、遅れがどこから来たのかを見てもらうことになります。

本記事では、IPA（情報処理推進機構）の「情報処理システム高信頼化教訓集（ITサービス編）」から、夜間バッチや処理量の予測が絡んだ3つの事例を取り上げ、発注側が見落としやすい点、渡す記録、再実行と打ち切りの決め方を整理します。調査を頼めば原因がすぐに見つかって直る、という性質の作業ではない点も、先に押さえておきます。

バッチ処理遅延調査とは

バッチ処理の遅れは、一つのジョブだけで終わりません。夜間のジョブは順につながっていることが多く、前のジョブが遅れると後ろのジョブも待たされ、最後は朝の業務の開始に響きます。教訓T26の事例では、オンライン業務を22時に終え、0時にシステム日付を変え、5時に業務日付変更のバッチ処理を流し、7時にオンライン業務を始める、という日次の流れが自動で運用されていました。^*2

遅れの形は、大きく3つに分けられます。一つ目は、処理するデータが増えて、ジョブの処理時間そのものが延びる形です。二つ目は、ジョブ同士の待ち合わせや順序が崩れて、処理が止まったり未処理のまま残ったりする形です。三つ目は、処理量が決められた上限を超えて、ジョブが異常終了する形です。性能改善と聞くと一つ目の形を思い浮かべがちですが、二つ目と三つ目は、処理を速くしても防げません。

手がかりにするIPAの教訓集は、システムの障害事例の情報を分析し、対策の手法を整理して、そこから導いた教訓をまとめたものです。^*4 取り上げるのは、処理量が上限を超えた教訓T18、ジョブの順序が崩れた教訓T26、処理量の予測を誤った教訓G5の3つです。順に見ていきます。

処理量が上限を超えた事例

教訓T18のA社のシステムは、日中のオンラインと夜間バッチで構成されていました。日中に受け付けたサービスの要求を夜間バッチに渡し、そこで処理を完結させる流れです。ある日、特別な事象をきっかけに、オンラインで大量の入力処理が集中しました。オンラインの側ではデータの制限をしていなかったため、そのまま夜間バッチに渡され、夜間バッチの処理能力の制限値を超えて異常終了しました。

制限値を広げて夜間バッチを再実行しましたが、異常終了のときに欠落したデータを元に戻す作業が難航し、予定より長い時間がかかりました。ぎりぎりの時点で、翌朝の通常の時刻にオンラインを始めるため、夜間バッチを中断してオンラインへの切り替えに着手します。ところが強制的に中断した結果、残りのバッチを自動で運行できなくなり、手動で流すしかなくなりました。膨大な作業が生まれ、処理の失念や誤処理による副次的な障害も多数起きています。影響は日を重ねるごとに広がり、収束までに10日間を要しました。^*1

教訓集は根本原因として、バッチシステムの1日の処理量には上限があり、超えたときは異常とみなして処理を止めることが確認できていなかった点を挙げています。バッチ処理を一度強制的に中断すると、以降の処理を自動で運行できず手動に頼るしかないことも、把握できていませんでした。^*1

遅れの調査では、処理の速さと並んで、処理量の上限と止めたあとの戻し方を確かめる必要があります。外部エンジニアには、ジョブごとの処理件数の推移と、分かっている上限値や制限値を渡します。

ジョブの順序が崩れた事例

教訓T26のA社は、営業店にサービスを提供するオンラインシステムを動かしていました。ある日、定刻になってもオンライン業務が始まらず、取引が止まりました。ログを調べた結果、通常は朝方に終わる業務日付変更の処理が、この日は正常に終わっていなかったことが分かりました。取引ができるようになるまで、数時間を要しています。^*2

業務日付変更の処理では、ジョブを管理する機能から2つの運用ジョブXとYが起動され、並列に動きます。各ジョブの先行するサブ処理が終わると完了メッセージを送り、管理する機能がそれを受けて後続のサブ処理を起動する仕組みでした。この日はサブ処理X1が遅れ、Y1がかなり先に終わりました。X1とY1の完了メッセージが同じ内容だったため、管理する機能はY1からのメッセージをX1からのものと取り違え、X1が終わる前に後続のX2を起動しました。その結果、処理に論理的な矛盾が生じてX2が未処理となり、バッチ処理は正常に終わりませんでした。

過去のログを調べると、同じような終了時刻の逆転はときどき起きていたものの、ごく短い時間の差だったため、問題にならずに済んでいたことも分かりました。根本原因は、ジョブYをジョブXの流用で作った際に完了メッセージの内容がそのまま写されていたことと、Yの設計者がXの仕様書を十分に調べていなかったことです。X2が未処理になっていることに気づかず、原因の究明に時間がかかった点も問題とされています。^*2

きっかけはX1の遅れでしたが、X1を速くしても、順序が逆転するたびに同じ危うさが残ります。遅れの調査を頼むときは、ジョブの一覧だけでなく、どのジョブがどのジョブを待っているかという順序の関係も渡します。

処理量の予測を誤った事例

教訓G5のXシステムは業界の共同システムで、稼働から1年がたち、業界での普及率が稼働当初の2倍に増える時期に差しかかっていました。業務の性質上、年度末に処理が集中する傾向があります。キャパシティの予測が不十分だったため、想定を大幅に上回る負荷がサーバーにかかり、ミドルウェアの潜在的な不具合が表に出て、システムが止まりました。年度末の数日間にわたり、止まるか、応答が極度に悪くなる状態が続き、利用を大幅に制限せざるを得なくなっています。^*3

このシステムは、端末からのオンラインの要求でバッチ処理を起動し、結果をオンラインで返す形でした。アプリケーションサーバーで流量の制御はしていたものの、負荷の重いバッチ型の業務に含まれる1トランザクション当たりのデータ数が、予測よりはるかに多かったのです。DBサーバーの中でSQL処理のタイムアウトが多発し、それがミドルウェアの不具合によるメモリリークを引き起こして、アプリケーションサーバーが止まりました。

教訓集は根本原因を、年度末のピーク時の処理件数の予測の誤りとしています。その背景として、利用各社が運営を委託先に任せきりにし、自社のシステムなら行うような責任を持った予測をしていなかった点を挙げています。^*3

外部エンジニアに調査を頼む場面に置き換えると、処理件数がこの先どう増えるかは、頼む側が持っている情報です。年度末や月末に処理が集まる業務、取引先や利用者が増える予定といった見込みを渡さないまま、今の遅れだけを直してもらうと、次の山で同じことが起きかねません。

ジョブの時刻をそろえる

3つの事例に共通するのは、遅れが見えた場所と、原因があった場所が別だったことです。外部エンジニアが短い時間で当たりを付けられるよう、社内で次の記録をそろえておきます。

なかでも役に立つのが、ジョブごとの開始と終了の時刻を一枚の表にまとめたものです。どのジョブが延びたのか、どのジョブが待たされていただけなのかは、平常の日と並べて見ないと分かりません。

原因調査を頼むときの一般的な準備は「外部エンジニアに不具合の原因調査を頼む手順」で、遅れが特定のSQLに絞れている場合は「SQLチューニングの目標の決め方」でまとめています。日々のバッチ運用そのものは「バッチ運用の勘所」が参考になります。

再実行と打ち切りの決め方

遅れの調査を頼む前に、社内で決めておきたいことがあります。バッチが朝までに終わらないとき、再実行するのか、途中で打ち切って業務を始めるのか、その判断を誰がするかです。教訓T18では、ぎりぎりの時点で夜間バッチを中断した結果、自動の運行ができなくなり、手作業の多さから副次的な障害が重なりました。判断の時刻と判断する人が決まっていないと、こうした決断がその場の勢いで行われます。

決めておく内容は、たとえば次のようなものです。何時までに終わらなければ打ち切るか。打ち切ったときに、どのジョブを手で流すのか、翌日の夜に回せるのか。利用者や取引先への知らせを誰が出すのか。教訓T18の対策にも、異常終了しても途中から再開できる仕組みと対応の手順をあらかじめ考えておくことが挙げられています。^*1

外部エンジニアに頼む範囲も、この決めごとと分けて考えます。原因の調査だけを頼むのか、本番の環境で計測の設定を加えたり、ジョブを流し直したりする作業まで頼むのか。本番で何をしてよいか、行うならどの時間帯かを先に決めておくと、調べる側も手を動かしやすくなります。作業時間の上限と、途中で状況を知らせてもらう時点も決めておきます。どこまでの作業を頼めるか、結果をどう扱うかは、契約と相手の提供範囲で確かめてください。

報告で確かめる点

報告には、どのジョブで時間を使っていたのかと、その根拠（時刻の記録や件数、ログの該当箇所）を書いてもらいます。確かめられなかった点も書いてもらいます。教訓T26では、未処理のジョブに気づかなかったことが原因の究明を遅らせました。見ていない場所が分かっていれば、次に誰が何を見るかを決められます。

対策は、当面の対処と恒久的な直し方を分けて書いてもらうと、社内で判断しやすくなります。教訓T26では、完了メッセージを区別できるものに直し、念のためジョブXとYを並列から順番の処理に改めたうえで、全システムを調べて同じような箇所に同じ手を打ち、完了メッセージの一覧を文書に追記しています。^*2

監視の見直しも、報告に入れてもらう価値があります。教訓T26の対策には、運用の担当がトラブルに早く気づけるよう、未処理となったジョブを監視することが含まれていました。終わったジョブだけでなく、始まらなかったジョブや終わらなかったジョブに気づける仕組みがあるかは、調査のついでに見てもらいやすい点です。

まとめ：バッチ処理遅延調査を頼むときの3つの点

夜間バッチの遅れで性能改善のための調査を外部エンジニアに頼むとき、確かめておきたい点は3つです。第一に、ジョブの一覧と順序、ジョブごとの開始と終了の時刻、処理件数、処理量の上限、直前の変更をそろえていること。第二に、朝までに終わらないときに再実行するか打ち切るか、誰がいつ決めるかと、本番の環境でしてよいことを決めていること。第三に、時間を使ったジョブとその根拠、当面の対処と恒久的な直し方、確かめられなかった点を報告に書いてもらうことです。調査を任せられる人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「情報処理システム高信頼化教訓集（ITサービス編）」3.18 既存システムとのデータ連携に関する教訓（T18）（PDF）（https://www.ipa.go.jp/archive/files/000049555.pdf）。出典：問題（夜間バッチの異常終了から収束までの経緯）、原因（直接の原因と根本原因）、対策、教訓を参照（確認日2026年10月7日）（2026年10月確認）
2. *2　参考：IPA「情報処理システム高信頼化教訓集（ITサービス編）」3.26 既存システムの流用開発に関する教訓（T26）（PDF）（https://www.ipa.go.jp/archive/files/000057457.pdf）。出典：問題、図3.26-1（オンラインシステムの日次起動スケジュール）、原因（直接原因と根本原因）、対策、効果、教訓を参照（確認日2026年10月7日）（2026年10月確認）
3. *3　参考：IPA「情報処理システム高信頼化教訓集（ITサービス編）」2.5 共同利用システムの業務処理量予測に関する教訓（G5）（PDF）（https://www.ipa.go.jp/archive/files/000049532.pdf）。出典：問題、原因（処理形態と直接原因、根本原因とその背景）、対策、教訓を参照（確認日2026年10月7日）（2026年10月確認）
4. *4　参考：IPA「情報処理システム高信頼化教訓のリンク集（ITサービス編）」（アーカイブ）（https://www.ipa.go.jp/archive/digital/iot-en-ci/system/lesson.html）。出典：教訓集の説明と教訓の一覧（教訓T18・T26・G5の種類とタイトル）を参照（確認日2026年10月7日）（2026年10月確認）

Tweet