LASSIC Media らしくメディア
ジョブ管理・バッチ基盤の移行を外注で刷新
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- ジョブ管理・バッチ基盤とは、ジョブネットの依存関係やスケジュールを制御し、日次・夜間の定型処理を回す仕組みです。
- 経済産業省が2025年5月28日に公表したレガシーシステムモダン化委員会の総括レポートでは、全産業で61%、従業員1万人以上の企業では74%にレガシーシステムが残っているとされています。
- クラウド移行先にはAWS Step FunctionsやAmazon EventBridge Schedulerのようなマネージド型ワークフロー、Apache AirflowのようなOSSのジョブスケジューラがあり、移行は棚卸しから並行稼働・切替までを段階的に進めることが実務的です。
目次
ジョブ管理・バッチ基盤とは——ジョブネットと依存関係を制御する仕組み
ジョブ管理・バッチ基盤とは、複数のジョブ(定型的に実行する処理単位)を決められた順序・時刻で実行し、失敗時の再実行や結果の監視までを一括して担う仕組みを指します。個々のジョブを依存関係でつないだまとまりは、一般に「ジョブネット」と呼ばれます。
ジョブ管理の役割は大きく5つに分けられます。時刻やイベントを起点にジョブを起動するスケジュール実行、前工程の完了を待って次工程を開始する依存関係の制御、異常終了したジョブを途中から再開するリラン(再実行)、実行結果を検知して担当者に知らせる監視・通知、そして稼働記録を残す実行ログの管理です。
この仕組みは、業務の追加や変更が積み重なるほど複雑になりやすいという特徴を持っています。次章では、長年運用してきたジョブ管理が具体的にどのような課題を抱えやすいかを見ていきます。
長年運用してきたジョブ管理が抱える構造的な課題——属人化・密結合・製品のEOL
ジョブネットは、業務の追加や変更が重なるたびに手直しされ、年数を経るほど前工程・後工程のつながりが増えていく傾向があります。担当者の異動や退職が重なると、なぜその順序で動いているのかという設計意図が引き継がれず、ジョブネット全体が触れにくい資産になりかねません。
この状態は、レガシーシステムに指摘される技術的な課題——老朽化、肥大化・複雑化、ブラックボックス化——とも重なります。経済産業省が2025年5月28日に公表したレガシーシステムモダン化委員会の総括レポートによると、全産業で61%、従業員1万人以上の企業では74%の企業にレガシーシステムが残っており、2018年時点の8割超からは緩やかに改善が進んでいるとされています*6。
ジョブ管理製品そのものの保守期限(EOL)も無視できない論点です。長年使ってきた製品のバージョンが保守終了を迎えると、セキュリティパッチの提供が止まるため、後継バージョンへの更新か他製品への置き換えを検討することになります。ライセンス費用や保守費用が、オンプレミス機器の老朽化と合わせて積み上がっていく点も、刷新を検討する動機の一つです。
ジョブ同士がファイルの受け渡しや共有ディスクを介してつながる「密結合」も、レガシー環境で見られやすい特徴です。あるジョブの出力ファイル名や配置場所を変えただけで、別のジョブネットが失敗するといった事態が起こりやすくなります。
クラウド移行で選択肢になるジョブ実行基盤——マネージド型ワークフローとOSSスケジューラ
オンプレミスで長年使われてきたジョブ管理製品(JP1、Systemwalker、千手、A-AUTOや、Cron・シェルスクリプトによる独自運用など)に対し、クラウドには複数の移行先候補があります。代表的な例が、AWSのAWS Step Functions*1やAmazon EventBridge Scheduler*2、Google CloudのCloud Composer(Managed Airflow)*4、Azure Data Factoryのスケジュールトリガー*5といった、クラウド事業者が提供するマネージド型のワークフロー・スケジューラです。
もう一つの選択肢がApache Airflow*3のようなOSSのジョブスケジューラです。DAG(有向非環グラフ)としてジョブの依存関係をコードで表現し、クラウド上のマネージドサービス(Cloud Composer等)として使う形態と、自前でホストする形態のどちらも選べます*3*4。
各方式の違いを整理すると、次の通りです。
| 項目 | レガシーなジョブ管理製品 | クラウド移行先の例 |
|---|---|---|
| 依存関係の表現 | 製品のGUIでジョブネットとして定義 | ステートマシンやDAG等、コードで定義*1*3 |
| スケジュール起動 | 製品固有のスケジューラ | cron式・rate式・1回限りの実行に対応*2 |
| 実行環境 | 自社のオンプレミスサーバーやエージェント | サーバーレスまたはマネージド型の実行基盤*1*2 |
| 得意な処理の傾向 | 汎用的なバッチ処理全般 | データ処理・ETLはCloud Composer等*4、サービス連携はワークフロー型が向く |
| 障害時の挙動 | 製品固有のリラン機能 | Retry・Catch等、ワークフロー側の機構*1 |
移行先を一つに絞り込む前に、既存のジョブがデータ処理中心か、複数サービスの連携中心かを見極めることが判断材料になります。Google Cloudも、データ処理主体のバッチにはCloud Composer(Managed Airflow)を、HTTPベースのサービス連携にはWorkflowsを使うという整理を公式に示しています*4。
ジョブ管理・バッチ基盤移行の進め方——棚卸しから並行稼働・切替まで
移行はまず、ジョブネットの棚卸しと可視化から始まります。既存のジョブ数、実行時刻、依存関係、異常時の対処手順を洗い出し、誰が見ても分かる形で図やドキュメントに残す工程です。この工程を飛ばすと、後段の再設計で判断材料が不足します。
次に進むのが、依存関係の再設計です。ジョブネットの前後関係を、移行先の仕組み(ステートマシンやDAG等)に合わせて組み直します。密結合になっていた部分を、この段階で疎結合な形に整理し直す機会にもなります。
移行先での実装が固まったら、旧環境と新環境を一定期間並行稼働させ、両方の実行結果を突き合わせます。処理件数や出力ファイルの差分を確認し、想定外の相違があれば原因を特定してから次の工程に進みます。
並行稼働で問題が見られなくなった段階で、本番の実行を新環境に切り替えます。切替後も旧環境のジョブ定義や実行ログはしばらく保全し、問い合わせや調査に対応できる体制を残しておくことが望まれます。
移行で見落としやすい落とし穴——リラン設計・暗黙の依存・バッチウィンドウ
移行作業でよく見落とされるのが、異常終了したジョブのリラン(再実行)手順です。旧製品ではジョブネットの途中から再開できていた処理が、移行先で仕組みが変わると最初からやり直すしかなくなる場合があります。リランの単位と手順は、移行の初期段階で確認しておきたい論点です。
ファイルの受け渡しによる暗黙の依存も、注意が必要な点です。あるジョブが生成したファイルを別のジョブが読み込む構成では、ファイル名の規則や配置場所、生成タイミングのずれが移行後の失敗要因になりやすくなります。棚卸しの段階で、こうした暗黙のつながりまで拾い出しておく必要があります。
深夜バッチのウィンドウ(実行が許される時間帯)の再設計も論点になります。オンプレミス時代に決めた開始・終了時刻が、クラウド環境のリソース起動やネットワークの応答を踏まえると、そのままでは収まらない場合があります。
ジョブの実行ユーザーや権限の整理も欠かせません。オンプレミスの実行ユーザーに紐づいていた権限を、クラウド側のIAM(Identity and Access Management。クラウドリソースへの権限を管理する仕組み)ロールなどに置き換える作業は、想定より工数がかかる場合があります。
内製と外注の分かれ目——ジョブ本数と依存関係の複雑さで判断する
ジョブの本数が少なく、依存関係も単純な環境であれば、自社の運用担当者が段階的に移行を進められる場合もあります。判断が分かれるのは、ジョブネットが数百規模に及ぶ環境や、複数部門の業務が絡み合って依存関係が積み重なっている構成です。
外部の専門パートナーに委託する場合は、依頼できる範囲の広さが選定の分かれ目になります。ジョブネットの棚卸しから依存関係の再設計、移行先での実装、並行稼働での検証、切替までを一括して任せられるかを確認します。元請（プライムベンダー）として複数の協力会社を束ねられる体制かどうかも、大規模な移行では確認しておきたい点です。
。移行対象のジョブ本数や依存関係の複雑さによって、必要な工数は変わってきます。現状のジョブネットを棚卸ししたうえで、内製・外注の切り分けを検討することが実務的です。
まとめ：ジョブ管理・バッチ基盤移行で押さえる3つの視点
本稿ではジョブ管理・バッチ基盤の移行について、公式情報をもとに整理しました。要点は3つに集約できます。第一に、ジョブ管理・バッチ基盤とは、ジョブネットの依存関係とスケジュールを制御し、日次・夜間の定型処理を回す仕組みです。第二に、長年の運用で属人化や密結合が進んだ環境は、経済産業省の総括レポートが指摘するレガシーシステムの課題と重なり、製品のEOLや保守費の上昇も刷新の動機になります*6。第三に、移行先にはマネージド型ワークフローやOSSのジョブスケジューラといった選択肢があり、棚卸しから並行稼働・切替までを段階的に進めることが、リスクを抑えた移行につながります。
よくある質問
ジョブ管理製品の保守期限(EOL)が近づいている場合、何から検討すればよいですか。
まず現行のジョブネットの依存関係と実行時刻を棚卸しし、影響範囲を把握することが出発点になります。保守期限までの残り時間と、移行先の選定・並行稼働に必要な期間を見比べたうえで、バージョン更新か他製品への移行かを判断します。
既存のジョブネットが複雑でドキュメントが整備されていない場合、移行はどう進めますか。
ジョブ管理製品の実行ログやスケジュール設定から、実際に動いている依存関係を機械的に洗い出す工程を先に行います。ドキュメントがない状態で設計だけを推測すると、移行後に想定外の依存関係が見つかりやすくなるため、実データに基づく棚卸しが欠かせません。
クラウドのマネージド型ワークフローとOSSのジョブスケジューラは何が違いますか。
マネージド型ワークフロー(AWS Step Functions*1やAmazon EventBridge Scheduler*2等)は、クラウド事業者が実行基盤を管理し、サービス連携やイベント駆動の処理に向いています。OSSのジョブスケジューラ(Apache Airflow*3等)は、DAGとしてコードで依存関係を表現でき、データ処理中心のバッチと相性がよい傾向があります*4。
移行中にジョブが失敗した場合のリラン(再実行)はどう設計しますか。
移行先の仕組みに応じて、失敗した工程だけを再実行できる単位を決めておくことが重要です。AWS Step Functionsであれば、RetryやCatchのステートを使って失敗時の挙動を組み込む方法があります*1。旧環境でのリラン単位と揃えられるかどうかを、移行前に確認しておきます。
移行作業を外部に委託する場合、何を確認すればよいですか。
ジョブネットの棚卸し方法、依存関係の再設計の進め方、並行稼働での検証範囲を、まず委託先とすり合わせます。加えて、元請（プライムベンダー）として複数工程を一括で任せられるか、切替後の運用体制まで対応できるかを契約前に確認しておくと、移行後のトラブルを抑えやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：AWS「What is Step Functions?」（AWS Step Functions Developer Guide）（https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html）
- *2 出典：AWS「What is Amazon EventBridge Scheduler?」（Amazon EventBridge Scheduler User Guide）（https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html）
- *3 出典：Apache Airflow「DAGs」（Apache Airflow Documentation）（https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dags.html）
- *4 出典：Google Cloud「Choose Workflows or Managed Airflow for service orchestration」（Google Cloud Documentation）（https://docs.cloud.google.com/workflows/docs/choose-orchestration）
- *5 出典：Microsoft「スケジュール トリガーを作成する」（Azure Data Factory & Azure Synapse、Microsoft Learn）（https://learn.microsoft.com/ja-jp/azure/data-factory/how-to-create-schedule-trigger）
- *6 出典：デジタル庁「企業のDXを阻む「レガシーシステム」とは？ユーザー企業がモダン化を進めるために取るべき対策とは【レガシーシステムモダン化委員会総括レポート：前編】」（経済産業省「レガシーシステムモダン化委員会総括レポート」2025年5月28日の紹介記事）（https://digital-agency-news.digital.go.jp/articles/2025-08-27-1）
