Spring Cloud Azure 7.2.0 shipsを見て、「今回は何が増えたのか」だけを追うのは半分しか正解ではありません。今回の重要点は、7.2.0 が Spring Boot 4.0.0〜4.0.5 と Spring Cloud 2025.1.0〜2025.1.1 に対応し、Azure App Configuration では起動時の一過性障害に備える startup-timeout を追加したことです。つまり、7.2.0 は派手な機能追加よりも、Spring Cloud Azure の中心テーマが「互換性追従」と「運用耐性」にあることを示すリリースです。 (GitHub)
そして、もっと大事なのは Spring Cloud Azure が 7.x への一本化で進んでいるわけではないことです。現在の公式ドキュメントは 4.20.0 / 5.25.0 / 6.2.0 / 7.2.0 を同時に対象とし、Microsoft Learn の BOM 注記でも Spring Boot 4.0.x は 7.2.0、3.5.x は 6.2.0、3.1.x〜3.5.x は 5.25.0、2.x は 4.20.0 を使うよう案内しています。結論を先に言えば、今の Spring Cloud Azure の運用方針は「常に最新へ」ではなく、「Spring Boot 世代ごとに正しい系列を選ぶ」です。 (GitHub)
Spring Cloud Azure 7.2.0 shipsが意味するもの
2026年4月20日の Spring Cloud Azure 7.2.0 では、azure-sdk-bom が 1.3.6 に上がり、App Configuration Config で startup-timeout が追加され、JSON の content type 判定まわりの不具合も修正されました。リリースノートだけ読むと小さな更新に見えますが、注目すべきは「設定取得の失敗でアプリが起動できない」という実運用の痛点に正面から手を入れている点です。 (GitHub)
特に startup-timeout は、Azure App Configuration を起動時に読み込む構成で効きます。一時的なネットワーク障害や依存サービスの揺らぎがあっても、一定時間は backoff 付きで再試行するため、起動直後の不安定さをアプリ側で吸収しやすくなります。プロダクトオーナーや IT 意思決定者の視点では、これは単なる設定項目ではなく、起動成功率と運用復旧性に関わる改善です。 (GitHub)
Spring Cloud Azureのロードマップは「複数レール運用」で読む
2026年に入ってからの動きを追うと、Spring Cloud Azure の方向性はかなりはっきり見えます。
- 2026年2月4日の 7.0.0 は、Spring Boot 4.0.0〜4.0.2 互換の 7.x 系列を立ち上げ、OAuth2 の on-behalf-of フロー修正や、App Configuration を無効にしていても接続文字列検証が走る不具合を直しました。 (GitHub)
- 2026年3月6日の 5.25.0 は、Spring Boot 3.1〜3.5 を広くカバーしつつ、Service Bus / Event Hubs の
ConnectionDetails、Docker Compose、Testcontainers 連携を追加しました。 (GitHub) - 2026年3月11日の 7.1.0 は、Boot 4 系列向けに同じく
ConnectionDetails、Docker Compose、Testcontainers を取り込みつつ、Key Vault JCA の優先順位問題、JMS のデフォルトConnectionFactory変更、App Configuration の tag-based filtering と feature flag refresh 修正まで入れています。 (GitHub) - 2026年3月25日の 6.2.0 は、Spring Boot 3.5 系の専用レールとして動き、5.25.0 や 7.1.0 と同じくローカル検証・統合テスト寄りの改善を取り込みました。 (GitHub)
- 2026年4月22日には 4.20.0 も出ており、Boot 2.x 系列でも Service Bus の request-reply 対応や Azure Messaging の自動有効化が入っています。 (GitHub)
この並びから読めるのは、Spring Cloud Azure の実際のロードマップが「最新一本で前進」ではなく、「Boot 2 / 3 / 4 の現実に合わせた並行メンテナンス」であることです。しかも単なる保守ではなく、開発・テスト・運用に効く機能が複数系列へ横展開されています。公式ドキュメントが 4.20.0 / 5.25.0 / 6.2.0 / 7.2.0 を同時に扱っていることも、その読み方を裏づけます。 (GitHub)
ここで注意したいのは、古い記事だけでサポート方針を判断しないことです。2024年の公式ブログでは 4.x は 4.19.0 を最終版として 2025年6月まで hotfix を続けると案内されていましたが、実際には 2026年4月に 4.20.0 が出ており、現行ドキュメントでも 4.20.0 が対象に入っています。つまり、Spring Cloud Azure の運用判断は、過去の発表文ではなく、現在のリリースタグと現在のドキュメントで確認すべきです。 (Microsoft for Developers)
Spring Cloud Azureの中期トレンドは4つある
互換性追従が最優先
Spring Cloud Azure のロードマップは、製品サイトの派手な一枚絵よりも、Wiki の Timeline、Version Mapping、そして Spring Boot の新リリースに追従する公開イシューに表れます。Timeline ページ自体が「Spring Cloud Azure の timeline を追跡するためのページ」と説明されており、公開イシューでも spring-boot-dependencies / spring-cloud-dependencies への整合、サンプル、MS Docs、Version Mapping 更新が定型タスクとして並んでいます。少なくとも公開情報からは、Spring Cloud Azure が Spring エコシステムのリリース列車に追従することを最優先に運用されていると読めます。 (GitHub)
パスワードレス認証が標準路線
2026年1月更新の公式ドキュメントでは、Spring Cloud Azure の passwordless authentication は Azure Identity Extensions を土台にし、コードや設定ファイル、環境変数に資格情報を置かずに Azure サービスへ接続する方向として整理されています。対象も JDBC、Redis、Service Bus JMS まで広がっており、認証の標準路線が「接続文字列」から「Microsoft Entra / Managed Identity」へ寄っていることは明白です。4.0 世代の設計変更でも、Managed Identity と credential chain がコアテーマとして整理されており、この方向性は一時的ではありません。 (Microsoft Learn)
ローカル再現性と統合テストの強化
5.25.0、6.2.0、7.1.0 のリリースを見ると、最近の投資はクラウド本番だけに向いていません。Service Bus / Event Hubs 向けの ConnectionDetails を追加し、Docker Compose と Testcontainers に対応させ、さらに 2026年3月にはそれぞれ専用の公式ドキュメントも公開されました。Spring Boot の service connection と自然につながるので、接続情報を手で配線しなくても、ローカルや CI で Azure 依存をかなり現実的に再現できます。これは「Azure 連携のテストは結局クラウドに上げないとできない」という状態からの脱却を意味します。 (GitHub)
App Configuration中心の設定運用が強くなる
App Configuration は 7.x の中でも特に追いかける価値があります。7.0.0 では「無効なのに接続文字列検証が走る」問題を修正し、7.1.0 では env=prod や team=backend のようなタグ条件で設定値や feature flag を絞り込めるようになり、load balancing ありの feature flag refresh も改善されました。さらに 7.2.0 では起動時の retry/backoff まで入りました。これは、設定管理を単なる convenience ではなく、起動経路と運用可用性の中心に据え始めているサインです。 (GitHub)
Spring Cloud Azureのバージョン戦略
以下は、Microsoft Learn の公式対応表をベースに、実務上の判断基準を加えて整理したものです。 (Microsoft Learn)
| 現在の Spring Boot | 基本の選択 | 向いているケース | この選び方の意味 |
|---|---|---|---|
| 4.0.x | 7.2.0 | 新規開発、Boot 4 移行を進めるサービス | 7.x を正面から使う。7.1〜7.2 の改善を取り込みやすい |
| 3.5.x | 6.2.0 | Boot 3 のまま最新寄りでそろえたい | Boot 4 へ同時に動かさず、検証範囲を抑えられる |
| 3.1.x〜3.5.x | 5.25.0 | Boot 3 系が混在する既存ポートフォリオ | 3.x を広くカバーしやすく、既存資産を束ねやすい |
| 2.x | 4.20.0 | 保守・延命が主目的のレガシー資産 | まだ更新はあるが、将来の主戦場としては考えない |
表の対応関係は公式の BOM 注記に基づいています。実務上は、3.5.x だから必ず 6.2.0 に急ぐとは限りません。5.25.0 でも Docker Compose / Testcontainers / ConnectionDetails は入っているため、Boot 3 系が混在している大規模環境では 5.25.0 を基準線にした方が運用は安定しやすいです。逆に、Boot 4 へ行く前提があるのに 5.x や 6.x に長く留まると、将来の移行を先送りするだけになります。 (GitHub)
たとえば、Boot 3.3 + Key Vault + Service Bus の既存業務 API なら、まず 5.25.0 を基準に BOM を固定し、パスワードレス認証と統合テストの整備を先に終わらせる方が失敗しにくいです。Boot 4 と 7.x への移行は、その次の波で進めた方が、変更の原因切り分けがしやすくなります。逆に、新規の高変更領域や、すでに Boot 4 の採用方針が固まっているサービスなら、7.2.0 を前提に設計した方が二重投資を避けやすいです。 (Microsoft Learn)
Spring Cloud AzureとAzure Spring Appsは別軸で見る
ここは戦略上、かなり重要です。Spring Cloud Azure はライブラリの話ですが、Azure Spring Apps は実行基盤の話です。Azure Spring Apps は 2025年3月17日に 3年間の提供終了期間へ入り、2028年3月31日に廃止予定です。しかも提供終了期間中、Azure Spring Apps では新機能追加は行わず、Microsoft は Azure Container Apps での新機能と機能強化を優先すると明言しています。一方で、Spring Cloud Azure のドキュメントとリリースは 2026年も複数系列で更新されています。つまり、ライブラリの継続性と実行基盤の将来は同じではありません。 (Microsoft Learn)
Azure Spring Apps を使っているなら、運用方針は二段で考えるべきです。まずアプリごとに Spring Boot 世代に合った Spring Cloud Azure 系列を選ぶ。次に、実行基盤は Azure Container Apps か AKS へどう移すかを別プロジェクトとして設計する。Microsoft は Spring Cloud アプリを Azure Container Apps へ移すためのガイドも公開しており、移行後の推奨事項としてサービスディスカバリ、Gateway、中央構成管理まで整理しています。大規模な基幹システムほど、この二つを一気にまとめない方が安全です。 (Microsoft Learn)
Spring Cloud Azureで失敗しやすい判断
- BOM を使わず、スターターごとに個別バージョンを指定すること。 公式ドキュメントは
spring-cloud-azure-dependenciesをdependencyManagementに入れて全依存をそろえる前提です。ここを崩すと、動くけれど検証されていない組み合わせを自分で作ることになります。 (GitHub) - Spring Boot 3 系のまま 7.x へ上げること。 公式の対応表では 7.2.0 は Boot 4.0.x 向けです。Boot 3 側は 5.25.0 か 6.2.0 の範囲で選ぶのが筋です。 (Microsoft Learn)
- Azure App Configuration を本番起動経路に入れているのに、起動失敗の試験をしないこと。 7.0、7.1、7.2 と App Configuration 関連の修正が続いている時点で、ここが現場の故障点だと分かります。起動時の一過性障害、feature flag refresh、タグ選択は必ず試験対象に入れるべきです。 (GitHub)
- Service Bus JMS の既定挙動変更を見落とすこと。 6.2.0 と 7.1.0 では sender 側の既定
JmsConnectionFactoryが変わっているため、送信・受信のふるまい、キャッシュ、パフォーマンス観点の再確認が必要です。 (GitHub) - 古いサポート記事だけで 4.x を「終わった系列」と決めつけること。 2024年ブログの説明だけを見るとそう読めますが、現実には 2026年4月の 4.20.0 と現行ドキュメントが存在します。サポート判断は、いま見えているタグと公式 docs で行うべきです。 (Microsoft for Developers)
- Spring Cloud Azure と Azure Spring Apps の将来を同じ話として扱うこと。 ライブラリはアクティブでも、実行基盤の投資先は別です。この二つを混同すると、移行順序を誤ります。 (Microsoft Learn)
次にやること
- まず、アプリ一覧を Spring Boot バージョン / 利用 Azure サービス / 認証方式 / 設定ソース / 実行基盤 の5列で棚卸しします。ここで初めて、5.x・6.x・7.x のどれをどのアプリに当てるかが見えます。
- 次に、アプリごとに 1つの系列 を決め、BOM を固定します。系列をまたいだ個別依存の寄せ集めは避けます。
- そのうえで、PoC では機能試験より先に 起動試験 と 統合試験 を回します。具体的には、App Configuration 一時障害時の起動、パスワードレス認証、Service Bus / Event Hubs の接続、Docker Compose / Testcontainers を使ったローカル再現性です。 (GitHub)
- Azure Spring Apps を使っている組織は、ライブラリ更新と同時に全部やろうとせず、実行基盤移行の計画を別線で切るのが安全です。Azure Container Apps への移行ガイドがあるので、まずはそこを前提にロードマップを引き直すのが現実的です。 (Microsoft Learn)
Spring Cloud Azure 7.2.0 ships を起点に読むべきメッセージは、「7.x に急げ」ではありません。自社の Spring Boot 世代ごとに正しいレールを選び、認証・設定・テスト・実行基盤を分離して計画せよ。これが、いまの Spring Cloud Azure を最も外さずに使う運用方針です。 (Microsoft Learn)
コメント