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 関連の小ネタや便利技から、日常のアニメ・ゲーム布教なども幅広く投稿してるので、
ご興味のある方は是非フォロー・いいねをお願いします。