＜目次＞
(１) バッチ処理の使用例やシステムにおける役割をご紹介
(１-１) バッチ処理の利用方針（大方針）
(１-２) バッチ処理の使用例
(１-３) バッチ処理を運用する仕組み（ジョブスケジューラ）について
(１-４) 参考：主な考慮ポイント
(１) バッチ処理の使用例やシステムにおける役割をご紹介
(１-１) バッチ処理の利用方針（大方針）
バッチ処理は主にユーザーの操作（画面操作）を伴わない、大量の連続した処理を一括で実施するのに適した処理です。通常、バッチ処理は夜間等のオンライン利用（ユーザーからの画面操作）がない時間帯にスケジュールされて、定期的に実行されます（日次、週次、月次など）。
(１-２) バッチ処理の使用例
●①ファイル連携
システム間でファイルの送受信や加工を行う処理です。次の②と組み合わせる事で、連携したのちに登録処理等を連続して実施する事もできます。
（例１）
他システムから連携ファイルを取得（ファイル移動等）し、そのデータを読み込んでDBに対してレコード登録処理を実行する。
（図１２１）
●②データの登録／更新／削除
DB・ファイル等のデータを登録／更新／削除する処理を、バッチ処理として作成し、ジョブスケジューラ（JP1、TWS等）で定期的に実行するパターンが多いです。これにより、データが自動的にメンテナンスする事が可能になります。
（例１）
最終更新日から１０年が経過したレコードは不要レコードとして「削除」の処理をする。
（例２）
ユーザーが入力したデータを、１日の終わりに辞書に一括で「登録」する処理を実行する。
(１-３) バッチ処理を運用する仕組み（ジョブスケジューラ）について
一般的な大規模システムにおいては、バッチ処理はジョブスケジューラ（JP1、TWS等）との組み合わせで、実行スケジュールに沿って定期的に処理が行なわれます。バッチ処理は主には夜間などの業務外の時間帯に、一括で行うメンテナンス処理（例：DB再編、ファイル再編など）の目的で実行されるケースが多いです。
（図１３１）
(１-４) 参考：主な考慮ポイント
●障害時の処理継続
サーバにおけるバッチ処理が障害で実行不可になったケース等は、冗長構成における他のサーバにて代理実行する等の仕組みを検討する必要があります。
例えば、次のようにAPサーバが5台の冗長構成になっているシステムがあるとします。この時、バッチ処理全般は通常時においてはAPサーバ#1号機で実行する運用にしていますが、もしも障害が発生してAPサーバ#1号機がダウンした場合は、バッチ処理をAPサーバ#4号機での実行に切り替えるといった運用を事前に決めて、それを検知・切り替えする仕組みを検討するといった具合です（下表の例では、障害時のバッチ処理は「手動実行」としているため、切り替えはなしの想定）。
（表）
| ＜サーバNo＞ | ＜運用方式＞ |
| APサーバ#1 | 「通常時」運用 （自動実行） |
| APサーバ#2 | 「障害時」運用 （手動実行） |
| APサーバ#3 | – |
| APサーバ#4 | – |
| APサーバ#5 | – |
●被災時の処理継続
被災時における「本番」と「災対」（災害対策環境）の切り替えもバッチ処理等で行われるケースが多いです。その際に、他システムIFからの参照先のホスト名やIPアドレスを切り替える処理が必要となります。
