1. はじめに
1-1. アプリは「作って終わり」じゃない
あなたが作った（または引き継いだ）アプリ、本番環境で動かし続けるには何が必要か？
実際の現場では、アプリ本体以外にも様々な処理が必要です：
- 毎日のバックアップ
- 月末の集計処理
- 定期的なデータクリーンアップ
- ログのローテーション
これらは全て「定期処理（バッチ処理）」で実現されています。
社内勉強会にて、ソースを書いた後にどんなことが必要なのか？
についての説明が雑だったので、再度まとめてみました。
1-2. なぜバッチ処理が必要なのか
理由1：リアルタイムでやると重すぎる
例：月次売上集計
- 100万件のデータを集計
- リアルタイムでやると画面が固まる
- → 深夜に一括処理する
理由2：決まった時間に確実に実行したい
例：給与計算
- 毎月25日に必ず実行
- 人が忘れずに実行するのは困難
- → 自動化で確実に
理由3：人手でやるとミスが起きる
例：バックアップ
- 毎日手動でバックアップ → いつか忘れる
- → 自動化でミス防止
理由4：営業時間外に処理したい
例：システムメンテナンス
- データベースの再構築
- ユーザーに影響を与えない深夜に実行
1-3. アプリの全体構成図
この図のポイント
- アプリ本体とは別に「定期処理」が必要
- スケジューラが定期処理を起動する
- 今回は「定期処理」と「スケジューラ」について学ぶ
2. 定期処理（バッチ処理）とは
2-1. 定義
決まった時間に自動で実行される処理。ユーザーの操作なしに動く。
2-2. リアルタイム処理との違い
| リアルタイム処理 | 定期処理（バッチ処理） | |
|---|---|---|
| いつ動く？ | ユーザーが操作したとき | 決まった時間に自動 |
| 例 | 商品検索、注文処理 | 月次集計、バックアップ |
| レスポンス | すぐに結果を返す | 時間がかかってもOK |
| 実行回数 | 何度でも | 1日1回、月1回など |
2-3. 具体例
業務システムの例
- 給与計算（月末23時）
- 売上集計（毎日0時）
- 請求書発行（毎月1日9時）
- 在庫アラート（毎時）
システム運用の例
- データベースバックアップ（毎日3時）
- ログファイルの圧縮・削除（毎週日曜）
- セキュリティパッチ適用（毎月第2火曜）
- ディスク容量チェック（30分おき）
3. 定期処理の種類
3-1. 時刻ベース
特定の時刻に実行
例
- 毎日0時
- 毎週月曜9時
- 毎月1日23時
3-2. 間隔ベース
一定間隔で実行
例
- 5分おき
- 1時間おき
- 30秒おき
3-3. イベントベース
特定のイベント発生時に実行
例
- ファイルが配置されたら
- メール受信したら
- API呼び出しがあったら
4. スケジューラ：定期処理を動かす仕組み
4-1. スケジューラとは
定期処理を「いつ実行するか」を管理・制御するツール。
4-2. 環境別のスケジューラ
| 環境 | スケジューラ | 特徴 |
|---|---|---|
| Linux | cron | 標準機能、シンプル |
| Windows | タスクスケジューラ | GUI で設定可能 |
| 統合運用管理 | JP1（日立） SystemWalker（富士通） |
大規模システム向け |
| クラウド | AWS EventBridge GCP Cloud Scheduler |
サーバーレス |
| アプリ内 | Spring Scheduler Celery（Python） |
アプリに組み込み |
5. 各スケジューラの基本
5-1. cron（Linux）
設定方法
# crontabを編集
crontab -e
cron記法の読み方
0 9 * * *
│ │ │ │ │
│ │ │ │ └─ 曜日（0-7、0と7が日曜）
│ │ │ └─── 月（1-12）
│ │ └───── 日（1-31）
│ └─────── 時（0-23）
└───────── 分（0-59）
よくある設定例
| 設定 | 意味 |
|---|---|
0 9 * * * |
毎日9時0分 |
*/5 * * * * |
5分おき |
0 0 * * 0 |
毎週日曜0時 |
0 0 1 * * |
毎月1日0時 |
30 2 * * 1-5 |
月〜金の2時30分 |
設定例
# 毎日3時にバックアップ
0 3 * * * /opt/scripts/backup.sh
# 5分おきにログチェック
*/5 * * * * /opt/scripts/check_log.sh
5-2. タスクスケジューラ（Windows）
設定方法
- 「タスクスケジューラ」を開く
- 「基本タスクの作成」をクリック
- トリガー（実行タイミング）を設定
- 操作（実行するプログラム）を設定
PowerShellでの作成例
# 毎日9時にスクリプト実行
$action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "C:\Scripts\backup.ps1"
$trigger = New-ScheduledTaskTrigger -Daily -At 9am
Register-ScheduledTask -Action $action -Trigger $trigger -TaskName "DailyBackup"
5-3. JP1（統合運用管理ツール）
JP1とは
日立製作所の統合運用管理ソフトウェア。大規模システムのバッチ処理管理に使われる。
JP1でできること（バッチ処理の観点）
1. 複雑なスケジュール設定
cronでは難しい、業務に即したスケジュール設定が可能。
| 設定例 | cron | JP1 |
|---|---|---|
| 毎月末日 | 難しい | 「月末日」で設定可能 |
| 第2火曜日 | 不可能 | 「第2火曜日」で設定可能 |
| 営業日のみ | 不可能 | カレンダー機能で対応 |
| 休日の翌日 | 不可能 | カレンダー連動で可能 |
2. 処理の依存関係制御
複数の処理を順番に、または条件付きで実行。
処理1: データ抽出
↓ 成功したら
処理2: データ集計
↓ 成功したら
処理3: レポート作成
↓ 成功したら
処理4: メール送信
※どこかで失敗したら、そこで停止
cronとの違い：
- cron：各処理が独立、前の処理の成功を確認できない
- JP1：前の処理が成功したら次へ、失敗したら停止・通知
3. 自動監視・通知
処理の実行状況を自動監視し、異常時に通知。
監視項目
- 実行されたか
- 成功したか
- 処理時間は正常範囲か
通知設定例
条件: バックアップ処理が失敗
通知先: 運用担当者にメール
件名: [緊急] バックアップ処理失敗
4. リトライ・エラーハンドリング
失敗時の自動リトライや、エラー時の処理を設定可能。
リトライ設定例
処理名: データ取得API
リトライ回数: 3回
リトライ間隔: 5分
1回目: 失敗（タイムアウト）
↓ 5分待機
2回目: 失敗（接続エラー）
↓ 5分待機
3回目: 成功
5. 詳細なログ管理
全ての実行履歴を自動記録。
記録される情報
- 実行日時（開始・終了）
- 実行結果（成功・失敗）
- 処理時間
- 標準出力・エラー出力
- 実行ユーザー
6. 手動実行・停止制御
GUIから手動で実行・停止が可能。
用途
- テスト実行
- 障害時の手動リラン
- スケジュール外の臨時実行
- 想定外に長引いた処理の強制停止
7. 並列実行制御
複数の処理を同時に実行したり、実行数を制限したり。
例：同時実行数制限
データ処理を10個実行したいが、
サーバー負荷を考慮して同時3個まで
[処理1] [処理2] [処理3] ← 実行中
[処理4] [処理5] ... [処理10] ← 待機
処理1が終わったら処理4が開始
他の統合運用管理ツール
| ツール | 提供元 | 特徴 |
|---|---|---|
| JP1 | 日立 | 国内シェアNo.1、大規模向け |
| SystemWalker | 富士通 | JP1の競合 |
| Hinemos | NTTデータ | OSSベース、無償版あり |
| Rundeck | OSS | 軽量、Web UI |
5-4. クラウド（AWS EventBridge）
EventBridgeとは
AWSのイベント駆動型サービス。スケジュール実行やイベント検知ができる。
設定例（Lambda関数を毎日実行）
# EventBridgeルール
ScheduleExpression: cron(0 9 * * ? *) # 毎日9時（UTC）
Target: Lambda関数
注意点
- タイムゾーン：UTCで指定（日本時間-9時間）
- cron記法が少し違う：6つのフィールド（秒も指定可能）
他のクラウドスケジューラ
- GCP Cloud Scheduler
- Azure Logic Apps
6. cron / タスクスケジューラ / JP1 の比較
6-1. 機能比較表
| 項目 | cron （Linux） |
タスクスケジューラ （Windows） |
JP1 |
|---|---|---|---|
| OS | Linux/Unix | Windows | OS非依存 |
| 設定方法 | コマンド | GUI / PowerShell | GUI |
| 学習コスト | 低 | 低 | 高 |
| 営業日カレンダー | ✗ | ✗ | ✓ |
| 月末日指定 | △ | △ | ✓ |
| 依存関係 | ✗ | ✗ | ✓ |
| 並列実行制御 | ✗ | ✗ | ✓ |
| 監視機能 | ✗ | △ | ✓ |
| 自動通知 | △ | △ | ✓ |
| リトライ | △ | △ | ✓ |
| ログ管理 | △ | △ | ✓ |
| コスト | 無料 | 無料 | 有料 |
| 適用規模 | 小〜中 | 小〜中 | 中〜大 |
凡例
- ✓：標準機能で可能
- △：自分で実装すれば可能
- ✗：不可能
6-2. 使い分けの目安
cronを使う場合
✓ Linuxサーバーで動く
✓ シンプルな定期実行（毎日3時など）
✓ 処理が独立している
✓ 小規模システム
例:
- バックアップ（単独処理）
- ログローテーション
- 定期的なデータ削除
タスクスケジューラを使う場合
✓ Windowsサーバーで動く
✓ GUIで設定したい
✓ シンプルな定期実行
✓ 処理が独立している
例:
- Windowsサーバーのバックアップ
- レポートファイルの生成
- 定期的なスクリプト実行
JP1を使う場合
✓ 複数の処理に依存関係がある
✓ 複雑なスケジュール（月末営業日等）
✓ 大量のバッチ処理（100個以上）
✓ 自動監視・通知が必要
✓ 基幹システム（金融、製造等）
例:
- 月次決算処理（複数処理の連携）
- 給与計算（営業日カレンダー必須）
- 基幹システムのバッチ群
組み合わせ例
実際の現場では、組み合わせて使うことも多い。
中規模システムの例
JP1: 重要な業務バッチ（月次処理、給与計算等）
cron: システム保守系（バックアップ、ログ削除等）
7. 定期処理を作るときのポイント
7-1. 冪等性（べきとうせい）
何度実行しても同じ結果になること。
悪い例
# 毎回データを追加してしまう
def bad_batch():
db.insert({"date": today, "count": 100})
良い例
# 既存データを削除してから追加
def good_batch():
db.delete({"date": today})
db.insert({"date": today, "count": 100})
7-2. ログ出力
必ず実行ログを残す。
記録すべき情報
- 開始時刻
- 終了時刻
- 処理件数
- エラー内容
例
[2026-01-21 03:00:00] START: backup.sh
[2026-01-21 03:05:23] Backup completed: 1,234 files
[2026-01-21 03:05:23] END: backup.sh (Duration: 5m23s)
7-3. タイムアウト設定
処理が永遠に終わらないのを防ぐ。
例（Pythonでタイムアウト）
import signal
def timeout_handler(signum, frame):
raise TimeoutError("処理がタイムアウトしました")
signal.signal(signal.SIGALRM, timeout_handler)
signal.alarm(3600) # 1時間でタイムアウト
try:
heavy_processing()
except TimeoutError:
print("タイムアウト発生")
finally:
signal.alarm(0)
7-4. 排他制御
同じ処理が同時に動かないようにする。
ロックファイルの例
#!/bin/bash
LOCKFILE=/tmp/backup.lock
if [ -f $LOCKFILE ]; then
echo "既に実行中です"
exit 1
fi
touch $LOCKFILE
trap "rm -f $LOCKFILE" EXIT
# 処理
/opt/scripts/backup.sh
8. 運用のポイント
8-1. 監視
定期処理が正常に動いているか確認。
監視項目
- 実行されたか
- 成功したか
- 処理時間は正常範囲か
- エラーログは出ていないか
- リソース使用状況（CPU、メモリ、ディスク）
監視ツール
Zabbix
OSSの統合監視ツール。サーバー、ネットワーク、アプリケーションを監視。
監視設定例
アイテム名: バックアップジョブ実行確認
監視内容: /var/log/backup.log の更新時刻
チェック間隔: 10分
しきい値: 最終更新から3時間以上経過
アクション: 管理者にメール送信
その他の監視ツール
| ツール | 特徴 | コスト |
|---|---|---|
| Zabbix | OSS、多機能 | 無料 |
| Datadog | SaaS、セットアップ簡単 | 有料 |
| CloudWatch | AWS専用 | 従量課金 |
| JP1/IM | JP1との統合 | 有料 |
監視の重要性
監視がないと
- バックアップが失敗していることに気づかない
- ディスク容量不足でシステム停止
- データ欠損に誰も気づかない
監視があると
- 問題を早期発見
- 障害の予防
- 安心して運用できる
8-2. アラート設定
失敗時に通知を受け取る。
通知先
- メール
- Slack
- PagerDuty
例（cronでエラー時にメール）
0 3 * * * /opt/scripts/backup.sh || echo "Backup failed" | mail -s "Error" admin@example.com
8-3. リトライ設定
一時的なエラーで失敗したら再実行。
リトライ戦略
- 即座にリトライ：3回まで
- 時間を空けてリトライ：5分後、10分後、30分後
JP1でのリトライ設定
リトライ回数：3回
リトライ間隔：5分
9. よくある質問（FAQ）
Q1. バッチ処理と定期処理の違いは？
A. ほぼ同じ意味で使われます
- バッチ処理：まとめて処理する（対：リアルタイム処理）
- 定期処理：定期的に実行される処理
多くの場合、定期的に実行されるバッチ処理を指します。
Q2. 手動実行との使い分けは？
| 手動実行 | 定期処理 | |
|---|---|---|
| 頻度 | 不定期、臨時 | 定期的 |
| 例 | データ修正、緊急対応 | 日次集計、バックアップ |
| メリット | 柔軟性 | 自動化、ミス防止 |
Q3. 失敗したらどうなる？
A. スケジューラによって異なります
- cron：次回も通常通り実行される
- JP1：アラート通知、リトライ設定可能
- EventBridge + Lambda：Dead Letter Queueで記録
Q4. 深夜に実行するのはなぜ？
A. システム負荷を避けるため
- 日中：ユーザーが使用（高負荷）
- 深夜：ユーザーが少ない（低負荷）
重い処理は深夜に実行してシステムへの影響を最小化。
Q5. cronとJP1、どっちを使うべき？
| cron | JP1 | |
|---|---|---|
| 向いている | シンプルな定期実行 | 複雑な業務フロー |
| 規模 | 小〜中 | 大規模 |
| コスト | 無料 | 有料 |
判断基準
- 処理が単独で完結 → cron
- 複数処理の依存関係あり → JP1
Q6. 実行されないときはどうする？
A. まず以下を確認
- スケジュール設定が正しいか
- スクリプトのパスが正しいか
- 実行権限があるか
- サービスが起動しているか
確認コマンド例（Linux）
# cronが動いているか
systemctl status cron
# cron設定を確認
crontab -l
# ログ確認
grep CRON /var/log/syslog
10. まとめ
定期処理の3つのポイント
-
アプリは作って終わりじゃない
- バックアップ、集計、クリーンアップが必要
-
スケジューラで自動化
- cron、タスクスケジューラ、JP1、クラウド
-
運用を忘れずに
- 監視、アラート、ログ確認
スケジューラの選び方
| 状況 | 推奨 |
|---|---|
| シンプルな定期実行 | cron / タスクスケジューラ |
| 複雑な依存関係 | JP1 |
| クラウド環境 | EventBridge / Cloud Scheduler |
11. 参考資料
書籍
-
「絵で見てわかるシステム運用の仕組み」（水口克也 著）
- 運用業務全般の基礎知識
-
「インフラエンジニアの教科書」（佐野裕 著）
- インフラ・運用の実践的な解説
-
「AWSではじめるインフラ構築入門」（中垣健志 著）
- クラウドでの自動化・運用
オブジェクティブグループでは X の投稿も平日毎日行っています！
IT 関連の小ネタや便利技から、日常のアニメ・ゲーム布教なども幅広く投稿してるので、
ご興味のある方は是非フォロー・いいねをお願いします。