Spring Batch 5.2系のOSSサポートは2026年6月30日に終わり、無償の修正が届く系列は6.0系だけになりました。この記事では、5から6へ上げるときにコンパイルや起動が止まる箇所、データベースで必要な作業、そして移行後に黙って挙動が変わる箇所を、公式の移行ガイドとソースに加え、Spring Boot 4.1.1（Spring Batch 6.0.5）で実際に動かした結果で整理します。
まとめ：Spring Batch 6移行で先に押さえる6点
- 現行GAは6.0.5（2026年8月21日）。6.0系のOSSサポートは2027年7月31日まで。次の6.1は2026年11月30日リリース予定で、Spring Boot 4.2系が採用する。
- Javaの最低要件は17のまま。上がるのはSpring Framework 7などSpring側で、Spring Batch 6はSpring Boot 4系とセットで導入する。
- JobLauncherとJobExplorerは非推奨。起動はJobOperator、履歴の参照はJobRepositoryへ寄せる。JobLauncherの削除予定は6.2以降。
- Spring Boot 4ではspring-boot-starter-batchだけだとメタデータを保存しないResourcelessJobRepositoryになる。DBに履歴を残すならspring-boot-starter-batch-jdbcへ替える。
- スキーマはBATCH_JOB_SEQをBATCH_JOB_INSTANCE_SEQへ改名する。SQL ServerとOracleは改名以外の変更も入る。改名できない環境は環境変数SPRING_BATCH_JDBC_SCHEMA_LEGACY=trueで旧名のまま動く（6.0.3以降）。
- v5で記録したジョブインスタンスはv6から同じものと認識されない。失敗ジョブは再開されず最初から走り、完了済みのパラメータも再実行される。移行前に失敗ジョブを片付け、移行後に過去日付を再投入しない。
Spring Batchの現行バージョンとサポート期限（EOL）
系列ごとのOSS・商用サポート終了日
| 系列 | 初回リリース(計画) | OSSサポート終了 | 商用サポート終了 |
|---|---|---|---|
| 6.1.x | 2026-11-30 | 2027-12-31 | 2028-12-31 |
| 6.0.x | 2025-11-30 | 2027-07-31 | 2028-07-31 |
| 5.2.x | 2024-11-30 | 2026-06-30 | 2032-06-30 |
| 5.1.x | 2023-11-30 | 2025-06-30 | 2026-06-30 |
| 4.3.x | 2020-11-30 | 2023-06-30 | 2029-06-30 |
表はSpring公式のサポート世代APIの値で、初回リリース欄は計画日です。実際の6.0.0 GAは2025年11月19日でした。5系最後のOSSリリースは5.2.6（2026年6月10日）で、5.2系の2032年6月30日までのサポートはVMware Tanzuの有償契約が前提です。契約が無いまま5.2系に残ると、新しいCVEの修正は届きません。6.1は2026年10月時点でマイルストーン6.1.0-M2まで出ており、Spring Batch 7という系列はまだ計画表にありません。
Spring BootのBOMが決めるspring-batchのバージョン
| spring-boot-dependencies | spring-batch |
|---|---|
| 4.2.0-M2（開発版） | 6.1.0-M2 |
| 4.1.1 | 6.0.5 |
| 4.0.8 | 6.0.5 |
| 3.5.16 | 5.2.6 |
値はMaven Centralにある各版のpomのspring-batch.versionプロパティです。Spring Bootを使っているならspring-batchの版を個別に指定する必要は無く、Boot 4系ならBatch 6系、Boot 3系ならBatch 5系に決まります。Spring Batch 6はSpring Framework 7が前提なので、Boot 3のままBatchだけ6へ上げる構成は成り立ちません。移行はSpring Boot 4への移行と一体で計画します。Boot側の変更点はSpring Boot 4とは？最新バージョン4.1の変更点・新機能とSpring Boot 3との違い【2026年10月】、系列ごとの期限はSpring Bootバージョン一覧とサポート期限（EOL）【2026年10月】最新版は4.1、4.0の無償サポートは12月末終了にまとめています。
6.0系の中でも上げ方に注意が要るパッチがあります。6.0.5のリリースノートは、同梱のSpring Integration 7.0.6でJMSのヘッダ変換が許可リスト方式に変わったため、JMS経由のリモートチャンキングやリモートパーティショニングでワーカーの応答が突き合わせられずジョブが止まる、と注意しています。Spring Boot 4.1.1のBOMが指定するSpring Integration 7.1.1にも同じ修正（CVE-2026-47880）が入っているため、Batchの版に関係なく対象です。該当する構成では、Jms.messageDrivenChannelAdapterにcorrelationId・sequenceNumber・sequenceSizeを通すヘッダマッパーを設定してから上げてください。
Spring Batch 5から6で壊れる箇所
JobLauncher非推奨とJobOperatorへの一本化
// v5: JobLauncher で起動する
JobExecution execution = jobLauncher.run(job, jobParameters);
// v6: JobOperator で起動する（JobOperator が JobLauncher を継承）
JobExecution started = jobOperator.start(job, jobParameters);
// v6: ID(long)ではなく JobExecution を渡すメソッドへ
jobOperator.restart(started);
jobOperator.stop(started);
jobOperator.abandon(started);JobLauncherには@Deprecated(since = “6.0”, forRemoval = true)が付き、Javadocは「6.2以降で削除予定」としています。6.1.0-M2のjarにもまだ含まれているので、6.0・6.1の間は動きます。JobOperatorがJobLauncherを継承したため、既定の構成からJobLauncherのBeanは消えましたが、JobLauncher型で注入している箇所はJobOperatorのBeanに解決されます。Spring Boot 4.1.1で確かめると、JobLauncher型のBean名はjobOperatorの1件だけでした。JobRepositoryもJobExplorerを継承したので、JobExplorerのBean定義は不要です。
見落としやすいのはJobOperator側の非推奨です。restart(long)・stop(long)・abandon(long)・startNextInstance(String)など、実行IDやジョブ名を渡す旧来のメソッドはJobOperator.javaでも6.2以降の削除予定になっており、JobExecutionやJobを渡す版へ置き換えます。getJobNames()の移り先はJobRegistry#getJobNamesです。コンパイルが止まる変更は、JobStep#setJobLauncherのsetJobOperatorへの改名、JobStepBuilder#launcherのoperatorへの改名、JobLaunchingGatewayのコンストラクタがJobOperatorを取る変更です。TaskExecutorJobLauncher（後継はTaskExecutorJobOperator）とCommandLineJobRunner（後継はCommandLineJobOperator）は非推奨になっただけで、6.0・6.1の間はコンパイルが通ります。インクリメンタ付きのジョブでは、v6から利用者が渡したパラメータは警告付きで無視され、次のインスタンスのパラメータはフレームワークが計算します。
@EnableBatchProcessingの分割とJdbcDefaultBatchConfiguration
// v5
@EnableBatchProcessing(dataSourceRef = "batchDataSource", taskExecutorRef = "batchTaskExecutor")
class MyJobConfiguration { }
// v6
@EnableBatchProcessing(taskExecutorRef = "batchTaskExecutor")
@EnableJdbcJobRepository(dataSourceRef = "batchDataSource")
class MyJobConfiguration { }v6の@EnableBatchProcessingは共通の属性だけを持ち、ストア固有の属性は@EnableJdbcJobRepositoryと@EnableMongoJobRepositoryが受け持ちます。DefaultBatchConfigurationを継承していたクラスは、JDBCならJdbcDefaultBatchConfigurationへ付け替えます。JobRepositoryFactoryBeanはJdbcJobRepositoryFactoryBeanへの改名で非推奨になり、JobRegistryBeanPostProcessorは削除されました（MapJobRegistryが起動時にジョブを自分で登録します）。混同しやすいDefaultBatchConfigurerとBatchConfigurerは、v6ではなく5.0で非推奨期間なしに削除済みです。4系から6系へ一気に上げる場合は両方の断絶を同時に踏みます。
パッケージ移動とチャンク指向ステップの新実装
// v5（v6でも動くが非推奨。v6世代の間だけ残る）
new StepBuilder("myStep", jobRepository).chunk(5, transactionManager)
// v6の新実装
new StepBuilder("myStep", jobRepository).chunk(5).transactionManager(transactionManager)spring-batch-infrastructureのAPIはorg.springframework.batch.*からorg.springframework.batch.infrastructure.*へ移りました。core側もJobやJobExecutionはorg.springframework.batch.core.job、JobParameters関連はorg.springframework.batch.core.job.parameters、ChunkListenerなどのリスナーはorg.springframework.batch.core.listenerへ移っています。チャンク指向ステップは新実装のChunkOrientedStepに入れ替わり、旧実装は「v6世代の間は非推奨の形で残すが保守しない」と移行ガイドに明記されています。
挙動の変更で影響が大きいのはリスナーの例外です。v5のフォールトトレラントなステップでは、ItemReadListenerなどが投げた例外が読み書きの失敗として扱われ、スキップやリトライの対象になっていました。v6の新実装（chunk(int)で組んだステップ）では読み書きの失敗とみなされず、FatalStepExecutionExceptionでステップが失敗します。非推奨の旧実装chunk(int, transactionManager)は従来どおりStepListenerFailedExceptionで包みます。リスナーの例外を「スキップされるから大丈夫」と放置していたジョブは、新実装へ切り替えた時点で止まります。リスナー内で例外を捕まえるか、スキップさせたい処理をItemProcessorなどへ移してください。
Jackson 3の既定化とObservationRegistryの登録
JsonItemReader・JsonFileItemWriterと、Jacksonを使う実行コンテキストのシリアライザはJackson 3が既定になり、Jackson 2版のクラスは併存しません（例外はJackson2ExecutionContextStringSerializerで、非推奨の形で残っています）。なお、実行コンテキストのシリアライザ自体の既定はDefaultExecutionContextSerializer（Javaの直列化をBase64にした形式）で、v5とv6で変わっていません。メトリクスはMicrometerのグローバルな静的MeterRegistryを参照しなくなり、ObservationRegistryをBeanとして登録しないとバッチのメトリクスが出ません。Spring Boot 4でActuatorがObservationRegistryを登録している構成なら、BatchObservationAutoConfigurationがジョブとステップへ自動で紐付けます。素のSpring Batchで組んでいる場合は例外も出ずに計測だけが止まるので、移行後にダッシュボードの値が出ているかを確認項目に入れます。
Spring Boot 4のJobRepositoryの既定（starter-batchではメタデータ非保存）
spring-boot-starter-batchとspring-boot-starter-batch-jdbcの違い
<!-- Spring Boot 4: メタデータをDBに残すなら -jdbc 付きのスターター -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-batch-jdbc</artifactId>
</dependency>Spring Boot 4.1.1のspring-boot-starter-batchが依存するのはspring-boot-starterとspring-boot-batchの2つだけで、JDBCは含みません。Boot 3.5まではこのスターターがspring-boot-starter-jdbcを含んでいたため、同じ依存のまま上げると構成が変わります。spring-boot-batchの自動構成はDefaultBatchConfigurationを継承しており、v6のDefaultBatchConfigurationはメタデータを保存しないResourcelessJobRepositoryを返します。JDBCのジョブリポジトリを組むBatchJdbcAutoConfigurationはspring-boot-batch-jdbcにあり、spring-boot-starter-batch-jdbcがそれとspring-boot-starter-jdbcをまとめて引き込みます。
Spring Boot 4.1.1で両方を起動すると、starter-batchだけの構成ではJobRepositoryの実装がorg.springframework.batch.core.repository.support.ResourcelessJobRepositoryでした。さらに、v5のころのようにステップの定義でPlatformTransactionManagerを受け取っているコードは、starter-batchだけでは起動時に「required a bean of type ‘org.springframework.transaction.PlatformTransactionManager’ that could not be found」で止まります。v6のステップはトランザクションマネージャを省略できますが、旧コードのまま上げた場合はスターターをspring-boot-starter-batch-jdbcへ替えるのが確実な直し方です。Spring Bootのリファレンスも、自動構成できるストアをIn-memory・JDBC・MongoDBの3つとして並べています。
ResourcelessJobRepositoryとJDBCの再開挙動の比較
ステップputが値を実行コンテキストへ入れ、ステップreadが読んで1回目だけ失敗するジョブで比べた結果です。
| 操作（同じJVM内） | starter-batch（Resourceless） | starter-batch-jdbc＋H2 |
|---|---|---|
| 1回目の起動 | FAILED | FAILED |
| restartで再開 | COMPLETED（putも再実行） | COMPLETED（putはスキップ） |
| 同じパラメータで再投入 | JobInstanceAlreadyCompleteException | JobInstanceAlreadyCompleteException |
| ステップ間の実行コンテキスト | 読める（count=42） | 読める（count=42） |
| JVMをまたいだ履歴 | 残らない | 残る |
ResourcelessJobRepositoryは直近の1インスタンスと1実行しか保持せず、ステップの完了記録を持たないため、再開しても先頭のステップから走り直します。ResourcelessJobRepositoryのJavadocは、リスタート不要で実行コンテキストを使わないジョブ向けで、スレッドセーフではないと明記しています。失敗箇所からの再開・重複起動の防止・パーティショニングのどれか1つでも要るジョブは、spring-boot-starter-batch-jdbcを選んでください。「テーブルを作らなくてよい」だけで選ぶと、障害時に再開できない構成になります。
@EnableBatchProcessing併用時のBoot自動構成の無効化
@EnableBatchProcessingを付けるか、DefaultBatchConfigurationを継承したBeanを置くと、BatchAutoConfigurationとBatchJdbcAutoConfigurationはどちらも適用されません。spring.batch.jdbc.initialize-schemaによるテーブル作成やspring.batch.jdbc.table-prefixも効かなくなり、設定は@EnableJdbcJobRepositoryの属性で書くことになります。Boot 3から移行するプロジェクトで@EnableBatchProcessingが残っていると、プロパティを変えても反映されない原因になります。起動時のジョブ実行はJobLauncherApplicationRunnerが担い、spring.batch.job.enabled=falseで止め、ジョブが複数あるときはspring.batch.job.nameで指定します。
データベーススキーマの移行（BATCH_JOB_SEQの改名）
DB別の移行スクリプトの中身
| DB | migration-*.sql の内容 |
|---|---|
| PostgreSQL | ALTER SEQUENCE … RENAME TO |
| MySQL | RENAME TABLE（テーブルで擬似シーケンス） |
| MariaDB | RENAME SEQUENCE |
| H2 | 新シーケンス作成＋旧シーケンス削除（採番値は移さない） |
| Oracle | RENAME＋BATCH_JOB_EXEC_PARAMS_IDX作成 |
| SQL Server | VARCHAR→NVARCHAR変換＋一意制約の張り直し＋sp_rename |
| DB2 | Informix向けのみ（DB2 LUWは改名不可） |
v6.0.5の移行スクリプトは11種類のDB向けにspring-batch-coreのmigration/6.0配下にあります。5.2.6と6.0.5のschema-*.sqlを空白を無視して比べると、PostgreSQL・H2・MySQLの差はシーケンス名だけでした。一方、SQL Server版はJOB_NAMEやEXIT_MESSAGEなど主要な文字列カラムをNVARCHARへ変換し、Oracle版はBATCH_JOB_EXECUTION_PARAMSにインデックスを足します。SQL Serverのスクリプトは6.0.2までは一意制約JOB_INST_UNが残ったままカラムを変換しようとして失敗し、6.0.3で制約を外してから張り直す形に直りました。テーブルが大きい環境では、NVARCHAR変換に時間がかかる前提で停止時間を見積もります。H2版はコメントに「Copy last value」とあるのに採番値を移していないため、ファイルに永続化したH2では新シーケンスの開始値を手で合わせます。DB2 LUWは10.1以降シーケンスの改名ができないため、現在の採番値を読んでその値から新しいシーケンスを作る手順を自分で用意します。
改名せずに旧スキーマで動かすSPRING_BATCH_JDBC_SCHEMA_LEGACY
# 環境変数で指定する
SPRING_BATCH_JDBC_SCHEMA_LEGACY=true java -jar app.jar
# JVMのシステムプロパティで指定する
java -Dspring.batch.jdbc.schema.legacy=true -jar app.jar
# 効かない（Springの設定プロパティとしては読まれない）
java -jar app.jar --spring.batch.jdbc.schema.legacy=trueSpring Cloud Data Flowのように、Batch 5と6のジョブが同じスキーマを共有する環境向けに、6.0.3で旧名BATCH_JOB_SEQを使い続ける切り替えが入りました（6.0.3のリリースノート）。実装はJobRepositoryFactoryBeanがSystem.getenvとSystem.getPropertyを直接読むもので、Spring Bootのapplication.propertiesや–付きの起動引数では効きません。環境変数を使えない場合は、JdbcDefaultBatchConfigurationのgetJobInstanceIncrementerName()を上書きして”JOB_SEQ”を返す方法もあります。5.2.6のスキーマを作ったH2に6.0.5で接続すると、指定なしでは「シーケンス “BATCH_JOB_INSTANCE_SEQ” が見つかりません」（英語環境ではSequence “BATCH_JOB_INSTANCE_SEQ” not found）で失敗し、環境変数かシステムプロパティを付けたときだけジョブが完走しました。Boot 4.0系の初期パッチ（Batch 6.0.0〜6.0.2）にはこの切り替えが無いので、使うなら6.0.3以降に上げてからにします。
v5の実行履歴とv6のJOB_KEYの不一致
v5で失敗したジョブのv6での扱い（新インスタンスで先頭から実行）
移行ガイドは「パラメータの永続化形式が変わったので、v5で起動して失敗したインスタンスはv6で再起動できない」と書いています。実際の挙動は例外で止まるのではありません。Boot 3.5.16（Batch 5.2.6）で失敗させたジョブと同じパラメータを、同じDBに対してv6から投入すると、v6は既存のインスタンスを見つけられず、新しいインスタンス（instanceId=2）として先頭のステップから実行しました。BATCH_JOB_INSTANCEのJOB_KEYを見ると、同じパラメータでもv5とv6で値が違います。DefaultJobKeyGeneratorがハッシュの元にする文字列が、v5の「名前={value=…, type=…, identifying=…};」から、v6ではrecordになったJobParameterのtoString（JobParameter{name=’…’, value=…, type=…, identifying=…}）に変わったためです。
v5で完了済みのパラメータ再投入による二重実行
同じ理由で、v5で完了したジョブも保護されません。v5では同じパラメータの再投入はJobInstanceAlreadyCompleteExceptionで拒否されますが、v6から同じパラメータで投入すると別インスタンスとして最初から実行されました。日付をパラメータにした日次ジョブで、移行直後に「念のため昨日分を流し直す」と、v5で処理済みの日付がもう一度処理されます。集計の二重計上や二重送信を防ぐには、次の3点を移行手順に入れます。
- 移行前に、v5で失敗したまま残っているインスタンスを成功させるか破棄する。
- 移行後しばらくは、v5で実行済みの日付・パラメータを再投入しない運用にする（ジョブ側で処理済みの日付を確認する仕組みがあれば併用する）。
- ジョブ側の書き込みを冪等にしておく（キーで上書きする、処理済みフラグを見る）。
異常終了したジョブを再開するJobOperator#recover
JobExecution last = jobRepository.getLastJobExecution("slowJob", params);
// kill -9 などで STARTED のまま残った実行は、このままでは restart できない
JobExecution recovered = jobOperator.recover(last); // FAILED に変えて再開可能にする
jobOperator.restart(recovered);v5では、プロセスが強制終了されてSTARTEDのまま残った実行を再開するには、BATCH_JOB_EXECUTIONなどのステータスをSQLで手で書き換える必要がありました。6.0でJobOperatorにrecoverメソッドが追加され、この作業がAPIで済むようになっています。JDBCのジョブリポジトリでジョブを実行中にkill -9し、次の起動で試すと、restartは「job execution already running」のJobRestartExceptionで拒否され、recoverを呼ぶと実行がFAILEDになり、実行コンテキストにbatch.recovered=trueが入りました。その後のrestartはCOMPLETEDまで進みます。recoverは「本当にもう動いていない」ことを確認してから呼ぶ操作です。別ノードで実行中のジョブに使うと二重実行になるため、プロセスの生存確認を手順の前に置いてください。止め方の側は、6.0で追加されたグレースフルシャットダウンが、停止シグナルを受けた時点のステップを止めて再開可能な状態で記録します。コンテナでの停止猶予（SIGTERM後の待ち時間）の設計はグレースフルシャットダウンとは？SIGTERM受信後の停止順序と猶予時間の設計を実装者目線で解説で扱っています。
OpenRewriteで自動化できる範囲
OpenRewriteにはMigrate to Spring Batch 6.0 from 5.2（org.openrewrite.java.spring.batch.SpringBatch5To6Migration）があります。Maven Centralにあるrewrite-maven-plugin 6.46.1とrewrite-spring 6.37.1で、Boot 3.5.16の小さなバッチアプリに当てた結果、書き換わったのはパッケージ移動に伴うimportと、注入する型のJobLauncherからJobOperatorへの変更でした。jobLauncher.run(…)の呼び出しは残り、JobOperator型経由の呼び出しになったためコンパイラの非推奨警告も出なくなります。starter名も変わらないので、親pomをBoot 4.1.1へ上げるとビルドは通るのに、起動時にPlatformTransactionManagerが無いと止まりました。spring-boot-starter-batch-jdbcへ替えるとジョブは完走しています。import置換の量を減らす道具として使い、run()からstart()への書き換え、スターターの付け替え、スキーマ移行、履歴の扱いは手作業で残すと考えてください。なお、このレシピのライセンスはModerne Source Available Licenseで、レシピページはビルド済みの成果物をModerneの顧客向けとし、非商用なら自分でソースからビルドするよう案内しています。配布もMaven CentralからCode Genome Projectへ移行中なので、業務で使う前に条件を確認してください。
移行を先送りしてよい条件と作業の順序
先送りしてよいのは、VMware Tanzuの商用サポート契約で5.2系の修正が実際に届く場合だけです。作業はSpring Boot 4への移行として組み、次の順で進めると手戻りが減ります。
- v5で失敗したまま残っているジョブインスタンスを成功させるか破棄する（v6では再開されないため）。
- v5のうちに、リスナーで投げている例外をリスナー内で処理するよう直す（JobOperator#start(Job, JobParameters)はv6にしか無いため、JobLauncherからの置き換えは手順3の後に行う）。
- Spring Boot 4系へBOMを上げ、spring-boot-starter-batchをspring-boot-starter-batch-jdbcへ替え、importを置換する（OpenRewriteを使うならこの段階）。続けてJobLauncher・JobExplorerへの依存をJobOperator#start・JobRepositoryへ置き換える。
- @EnableBatchProcessingのJDBC属性を@EnableJdbcJobRepositoryへ分ける。Bootの自動構成に任せるなら@EnableBatchProcessingを外す。起動ログでJobRepositoryの実装型を確認する。
- 本番DBに移行スクリプトを当てる。当てられない間はSPRING_BATCH_JDBC_SCHEMA_LEGACY=trueで動かす（6.0.3以降）。
- ObservationRegistryを登録してメトリクスを確認し、v5で処理済みの日付を再投入しない運用を周知する。
XML名前空間（batch:とbatch-integration:）でジョブを定義している場合は、移行と同時にJava Configへ書き換えないでください。名前空間はv6で非推奨になっただけで動作は維持され、削除予定はv7です。まずv6で動かし、書き換えは別の作業にすると切り分けがしやすくなります。JDKの更新やJakarta EE移行を含む全体の進め方はJavaマイグレーションの進め方｜JDK 8→21/25の手順とSpring Boot・Jakarta移行で扱っています。バッチ基盤ごと業務システムを載せ替える場合は、システムマイグレーション・リプレイスの支援もご相談いただけます。
よくある質問
Spring Batchの最新バージョンはいくつですか？
2026年10月時点の安定版は6.0.5（2026年8月21日リリース）です。6.1は6.1.0-M2まで出ていて、2026年11月30日のリリースが予定されています。Spring Batch 7は計画表にまだ無く、XML名前空間の削除がv7の予定として告知されているだけです。
Spring Batch 6でJavaの最低バージョンは上がりますか？
上がりません。移行ガイドの冒頭に「最低Javaバージョンは変えず、Java 17以上のまま」とあります。Java 17が必須になったのはSpring Batch 5からです。Java側の版選びはJava 24の新機能と主要JEPまとめ｜非LTS版の位置づけとJava 25 LTSへの移行判断が判断材料になります。
JobLauncherはいつ削除されますか？
Javadocの予定では6.2以降です。6.1.0-M2のjarにはまだ残っているので、6.1までは動きます。削除に備えて、run呼び出しはJobOperator#startへ書き換えておきます。
メタデータのテーブルを作らずにSpring Batchを動かせますか？
動かせます。Spring Boot 4ならspring-boot-starter-batchだけでResourcelessJobRepositoryになります。履歴はプロセス内にしか残らないため、再開や重複起動の防止が要らず、ステップ間で実行コンテキストを受け渡さない使い捨てのジョブに限って選びます。
DefaultBatchConfigurerはSpring Batch 5以降どうなりましたか？
5.0で非推奨期間なしに削除されました。代わりにDefaultBatchConfiguration（v6のJDBC構成ならJdbcDefaultBatchConfiguration）を継承して必要なメソッドを上書きします。Spring Bootの自動構成を使うなら、継承せずプロパティで設定するのが簡単です。Spring Framework 7との関係はSpring Frameworkとは？特徴・DI/AOPとSpring Bootとの違い・最新版7を解説【2026年最新】で確認できます。
