Spring Cloud Azure 7.2.0 ships を受けて、管理者が最初に確認すべきなのは「自分の環境が 7.2.0 の対象か」「App Configuration の起動時設定を変える必要があるか」「どの順で周知して段階展開するか」の3点です。2026年4月20日時点で GitHub Releases に 7.2.0 が掲載され、changelog では 2026年4月17日版として整理されています。今回の公式差分は、Spring Boot 4.0.0-4.0.5 / Spring Cloud 2025.1.0-2025.1.1 との互換性、azure-sdk-bom 1.3.6 への更新、Azure App Configuration の startup-timeout 追加、JSON content type 判定修正、Cosmos 側の定例リリースが中心です。(GitHub)
結論から言うと、すでに Spring Boot 4 系で Spring Cloud Azure 7.1.x を運用している組織なら、7.2.0 は比較的見通しのよいアップデートです。一方で、Spring Boot 3.x や 2.x のアプリに 7.2.0 を横展開するのは危険です。Spring Cloud Azure 7.x は Spring Boot 4 向けに設計されており、Boot 2.x 向けの 4.x 系は README 上で 2025年6月以降サポート終了と案内されています。(GitHub)
Spring Cloud Azure 7.2.0で管理者が先に把握すべき変更
| 項目 | 2026-04-20時点の見方 | 管理者への意味 |
|---|---|---|
| 公開タイミング | Releases 掲載は 4/20、changelog 版日付は 4/17 | 社内記録や変更票の日付ずれを防ぐ |
| 対応レンジ | Boot 4.0.0-4.0.5 / Cloud 2025.1.0-2025.1.1 | Boot 3/2 系を誤って同時更新しない |
| BOM | azure-sdk-bom が 1.3.6 に更新 | Azure SDK の推移依存差分も回帰対象にする |
| App Configuration | startup-timeout 追加、JSON content type 判定修正 | 起動時挙動と設定読込の確認が最優先 |
| Cosmos | 7.2.0 は regular release | Cosmos 専用ワークロードは設定見直しより回帰試験を優先 |
この整理は GitHub Releases と changelog の一次情報に基づいています。(GitHub)
まず判定する: あなたの環境は 7.2.0 の対象か
| 現行ベースライン | 7.2.0 の扱い | 管理者の判断 |
|---|---|---|
| Spring Boot 4.0.x + Spring Cloud 2025.1.x | 直接候補 | canary 対象にしてよい |
| Spring Boot 3.x | 直上げ対象ではない | Boot 4 移行と切り離して判断する |
| Spring Boot 2.x | 対象外 | 更改計画を先に立てる |
この判断の根拠は、Microsoft Learn のバージョン案内と Spring Cloud Azure README の方針です。Learn では Boot 4.0.x に spring-cloud-azure-dependencies 7.2.0 を使うよう案内され、README でも 7.x は Boot 4、6.x は Boot 3.5.x、5.x は Boot 3.x 向けと整理されています。(Microsoft Learn)
さらに、Spring Boot 4.0.5 は少なくとも Java 17 を要求します。共有ランタイムやコンテナベースイメージが古いままだと、依存関係だけ更新しても本番で起動できません。最初の棚卸しは、アプリの pom.xml や build.gradle だけでなく、実行基盤の JDK バージョンまで含めて行うべきです。(Home)
現行が 7.0.0 以前なら、7.2.0 だけでなく 7.1.0 の差分も一緒に確認した方が安全です。7.1.0 では Key Vault JCA provider の優先順位修正が入り、標準キーストア利用時の mTLS 破壊を避ける変更がありました。App Configuration でも feature flag 周りの更新が入っています。Key Vault 証明書や feature flag を使うサービスは、7.2.0 への変更票に 7.1.0 の回帰観点も含めておくのが実務的です。(GitHub)
導入前チェックリスト
Spring Cloud Azure 7.2.0 の導入で最初にやるべきことは、機能確認より先に「依存関係の線引き」を明確にすることです。BOM の一本化と対象アプリの切り分けができていないと、7.2.0 自体の差分が小さくても事故になります。(Microsoft Learn)
- 対象アプリを分ける
Boot 4 系だけを 7.2.0 対象にし、Boot 3/2 系は別トラックに分けます。共有 parent POM を一括更新する運用なら、特にここを先に固定します。 - BOM を 7.2.0 にそろえる
個別 starter や Azure SDK のバージョン指定を減らし、まず BOM 基準で依存関係を収束させます。 - 手動で pin している Azure SDK を洗う
azure-sdk-bomが 1.3.6 に上がるため、過去の一時回避で個別固定したバージョンが残っていると衝突しやすくなります。 - 利用中の Azure サービスを一覧化する
App Configuration、Key Vault、Service Bus、Event Hubs、Cosmos、Storage のうち、どれを本番で使っているかを先に確定します。今回の確認優先度は App Configuration 利用有無で大きく変わります。 - ロールバック単位を決める
共有 BOM 単位で戻すのか、サービス単位で戻すのかを先に決めます。7.2.0 は変更面が狭いので、ロールバックも小さくできる設計が向いています。
Maven なら、BOM の更新はまずこの形を基準にします。
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.azure.spring</groupId>
<artifactId>spring-cloud-azure-dependencies</artifactId>
<version>7.2.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>Gradle でも考え方は同じで、platform または dependency management 経由で BOM に寄せるのが基本です。個別の starter にバージョンを残す運用は、例外が必要な時だけに絞った方が後で追いやすくなります。(Microsoft Learn)
App Configuration利用時の設定差分チェックリスト
7.2.0 で運用者が最も見るべき差分は App Configuration です。startup-timeout は spring.cloud.azure.appconfiguration.startup-timeout 配下に追加され、既定値は 100 秒です。これは「起動時の一時障害をどこまで吸収するか」を決める設定で、恒久的な設定ミスを解決する機能ではありません。(GitHub)
| 確認項目 | 何を決めるか | 失敗しやすいポイント |
|---|---|---|
startup-timeout | 起動時リトライを何秒まで許容するか | 権限不足や誤 endpoint まで直ると誤解する |
stores[0].fail-fast | 読み込み失敗で起動を落とすか、ストアを読み飛ばすか | false のまま本番投入して silent degraded になる |
management.health.azure-app-configuration.enabled | UP / DOWN / NOT LOADED を監視対象にするか | fail-fast=false にしたのに状態監視を付けない |
stores[0].endpoint / endpoints | Managed Identity 前提に寄せるか、geo-replica を使うか | connection string を残し続けて secret 管理が増える |
stores[0].monitoring.* | pull refresh 間隔をどこまで許容するか | 既定値のまま多すぎる更新確認、または遅すぎる反映 |
| push refresh | 既存運用を継続するか | 新規設計で第一候補にしてしまう |
表の定義・既定値・状態値は公式 README と開発者ガイドに基づいています。(GitHub)
本番で App Configuration を必須依存にするなら、設定例は次のように考えると整理しやすいです。
spring:
config:
import: "azureAppConfiguration"
cloud:
azure:
appconfiguration:
startup-timeout: 120s
stores:
- endpoint: https://<your-store>.azconfig.io
fail-fast: true
monitoring:
enabled: true
refresh-interval: 30s
management:
health:
azure-app-configuration:
enabled: trueこの例では、startup-timeout は App Configuration 全体、fail-fast と monitoring はストア単位、health は運用監視の可視化として分けています。startup-timeout だけ増やしても、監視と失敗方針を一緒に決めなければ運用しやすくなりません。(GitHub)
逆に、開発環境や検証環境で「設定ストアが落ちていてもアプリ自体は起動させたい」なら、spring.config.import=optional:azureAppConfiguration と stores[0].fail-fast=false の組み合わせが候補になります。ただし、この場合は起動時に読み飛ばされたストアが refresh で自動復帰しない挙動があるため、NOT LOADED の監視を入れずに使うのは危険です。(GitHub)
複数ストア・ラベル・スナップショットを使う場合の追加確認
複数ストアを読む構成では、重複キーがあると後ろのストアが優先されます。複数ラベルでも同様に後ろのラベルが優先です。設定整理のつもりで順番を変えただけで、実効値が変わることがあります。共有設定とサービス固有設定を別ストアに分けている組織は、7.2.0 の更新時に依存順の棚卸しも一緒に実施した方が安全です。(GitHub)
スナップショットを使っている場合は、snapshot-name で読み込めますが、/application/ のようなプレフィックスを前提にしていた構成では trim-key-prefix を明示しないと意図したプロパティ名に変換されません。スナップショット運用は便利ですが、通常の key-filter 読み込みと同じ感覚で扱うとハマりやすい箇所です。(GitHub)
認証とフェールオーバーの見直し
App Configuration は、資格情報を明示しない場合 DefaultAzureCredential を使います。endpoint / endpoints 方式では Managed Identity やトークン資格情報を使えますが、connection-string 方式はサポートされていても README 上では非推奨です。運用設計としては、7.2.0 のタイミングで connection string を新規採用するより、endpoint と Managed Identity に寄せる方が長期運用しやすくなります。さらに、Managed Identity を使うなら App Configuration 側で App Configuration Data Reader ロール付与までを導入手順に含めるべきです。(GitHub)
geo-replication を使う場合、stores[0].endpoints は優先順で並べます。フェールオーバー対象になるのは 429、500 系、ネットワーク接続問題であり、認証失敗のようなクライアント側エラーでは切り替わりません。つまり、startup-timeout と複数 endpoint は「一時障害」には効きますが、「資格情報ミス」「RBAC 不足」「誤 URL」には効きません。ここを周知しておくと、障害切り分けがかなり速くなります。(GitHub)
refresh 設計も見直し対象です。README では monitoring.refresh-interval と feature-flag-refresh-interval の既定値が 30 秒、push-based refresh は「まだサポートされるが新規には推しにくい」状態です。既存運用で push を使っているなら即廃止までは不要ですが、新規導入ならまず pull ベースで十分かを先に判断した方が設計が単純になります。(GitHub)
周知チェックリスト
社内周知で大事なのは、技術詳細を全部流すことではなく、対象・非対象と要求アクションを最初に明確にすることです。Spring Cloud Azure 7.2.0 は「全アプリ一律更新」ではなく、「Boot 4 系の対象サービスを段階展開する更新」として伝える方が誤解が起きません。(Microsoft Learn)
- 開発チーム向け
7.2.0 は Boot 4 ライン向けであること、BOM でそろえること、App Configuration 利用アプリはstartup-timeout/fail-fast/ health indicator を見直すことを伝えます。 - 運用・SRE 向け
NOT LOADEDとDOWNを監視対象に含めること、起動時間が伸びる可能性があること、canary は App Configuration 利用サービスから始めることを共有します。 - IAM / セキュリティ向け
Managed Identity 利用有無、App Configuration Data Readerの付与、connection string の残存有無を確認してもらいます。 - リリース管理向け
Boot 3/2 系は今回の自動適用対象外にすること、ロールバック単位、canary 範囲、判定基準を先に決めます。
社内告知文に最低限入れるべき要素は、対象アプリ、対象外アプリ、変更点、確認依頼、反映予定日、問い合わせ先の6つです。ここが曖昧だと、技術的には小さい更新でも現場では大きな混乱になります。
展開順序チェックリスト
| 順番 | やること | 完了条件 |
|---|---|---|
| 1 | 依存関係の棚卸し | Boot / Cloud / JDK / BOM / 利用 Azure サービスが一覧化されている |
| 2 | 対象アプリの切り分け | Boot 4 系だけが 7.2.0 候補として分離されている |
| 3 | BOM 更新と手動 pin 削除 | ビルド定義が 7.2.0 基準で収束している |
| 4 | 起動時障害テスト | App Configuration の一時障害、認証不足、誤 endpoint の挙動が確認できている |
| 5 | canary 展開 | App Configuration を使う代表サービスで health と起動時間を確認できている |
| 6 | 本番段階展開 | 監視異常なし、ロールバック条件が明文化されている |
| 7 | 周知・記録更新 | 対象外サービスと今後の移行方針まで残っている |
7.2.0 の差分で最も確認価値が高いのは App Configuration なので、canary も「App Configuration を使っていない簡単なサービス」より、「実際に起動時読込と refresh を使う本命サービス」で行った方が意味があります。(GitHub)
失敗しやすいポイント
- 共有 parent POM を 7.2.0 に一括更新して Boot 3 系まで巻き込む
一番多い事故です。7.x は Boot 4 ラインとして扱う方が安全です。 startup-timeoutを“万能な再試行”だと思う
一時障害には有効でも、認証失敗や誤設定は直りません。fail-fast=falseにしたのに health を見ない
起動したように見えても、実際はストアがNOT LOADEDになっていることがあります。- 複数ストアの順序を変えて実効設定を変えてしまう
last wins を意識せずに整理すると、本番だけ値が変わります。 - connection string を残したまま本番展開する
機能的には動いても、秘密情報管理が重くなります。
これらはすべて、公式の互換性方針、App Configuration の失敗時挙動、複数ストアの優先順位、認証方式の説明から直接導ける落とし穴です。更新そのものより、設定方針を決めずに進めることの方が失敗要因になりやすいと考えておくと進めやすくなります。(Microsoft Learn)
迷ったらこう進める
Spring Cloud Azure 7.2.0 は、Boot 4 系向けの線をきれいに引き、App Configuration の起動時挙動を明示的に決めるための更新として扱うのが正解です。今日やることは3つだけで十分です。まず Boot / Cloud / JDK の棚卸しで対象サービスを確定すること。次に、対象サービスだけ BOM を 7.2.0 に上げて App Configuration の起動・認証・health を試験すること。最後に、Boot 3/2 系は今回の対象外と明記し、別の移行計画として切り出すことです。これで「出たから上げる」更新ではなく、「事故を増やさずに前へ進める」更新に変えられます。(Microsoft Learn)
コメント