Azure REST APIでAzure Service Bus名前空間を作成・更新している場合、今回のポイントは「Microsoft.ServiceBusに安定版API version 2026-01-01 が追加され、SBNamespaceProperties に ipV6Enabled が加わった」ことです。ipV6Enabled は、パブリックネットワークアクセスでIPv6を有効にするかを示す任意のbooleanプロパティです。既存APIをただちに壊す変更ではありませんが、ARMテンプレート、Bicep、Terraform AzAPI、独自RESTクライアント、SDK自動生成を使っているチームは確認が必要です。(GitHub)
特に注意したいのは、これはメッセージ送受信のデータプレーンAPIではなく、Service Bus名前空間を管理するAzure Resource Manager側の変更だという点です。api-version=2026-01-01 を使うか、ipV6Enabled を明示するか、GETレスポンスに新しいプロパティが返っても既存の処理が壊れないかを確認しましょう。
Azure REST API ServiceBus 2026-01-01で何が変わったのか
今回のAzure REST API documentation updateでは、Microsoft.ServiceBus 向けに新しい安定版API version 2026-01-01 が追加されました。PRの説明では、この安定版は 2025-05-01-preview をベースにしており、ipV6Enabled が SBNamespaceProperties に追加されたとされています。PR上では2026年5月5日に承認と PublishToCustomers ラベル付与が行われ、最終的なマージは2026年5月6日です。(GitHub)
主な変更点は次のとおりです。
| 変更点 | 内容 | 実務で見るべきポイント |
|---|---|---|
| 新しい安定版API version | Microsoft.ServiceBus に 2026-01-01 が追加 | REST呼び出し、ARMテンプレート、Bicep、SDK生成で使うAPI versionを確認する |
| 新プロパティ | properties.ipV6Enabled が追加 | IPv6を使う設計か、既存のネットワーク制御と矛盾しないか確認する |
| プロパティ型 | boolean、optional | 未指定時の挙動を勝手に決め打ちせず、GET結果で確認する |
| 対象リソース | 主にService Bus名前空間 | キュー、トピック、サブスクリプションのメッセージ処理そのものの変更ではない |
| 変更の性質 | 追加型の変更 | 厳格なJSON検証やSDKモデル生成では影響が出る可能性がある |
PRのSummaryでは「non-breaking, additive-only update」「new properties are optional」と説明されています。つまり、既存のリクエストに必ず ipV6Enabled を追加しなければならない変更ではありません。ただし、任意プロパティの追加でも、独自バリデーションや古いSDKモデルでは想定外のフィールドとして扱われることがあります。(GitHub)
ipV6Enabledとは何か
ipV6Enabled は、Service Bus名前空間の properties 配下に入るプロパティで、説明は「IPv6がパブリックネットワークアクセスで有効かどうかを示す値」です。名称は ipV6Enabled で、ipv6Enabled ではありません。大文字小文字を間違えると、JSONとしては別プロパティになってしまうため注意が必要です。(GitHub)
作成例では、次のように properties に指定されています。実際の環境では、リージョン、SKU、容量、既存のネットワーク設計に合わせて調整してください。
{
"location": "Japan East",
"sku": {
"name": "Premium",
"tier": "Premium",
"capacity": 1
},
"properties": {
"premiumMessagingPartitions": 1,
"publicNetworkAccess": "Enabled",
"minimumTlsVersion": "1.2",
"ipV6Enabled": true
}
}REST APIのURIは、名前空間作成・更新であれば次の形式です。
PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ServiceBus/namespaces/{namespaceName}?api-version=2026-01-01公式REST APIの従来版ドキュメントでも、Service Bus名前空間の作成・更新は Microsoft.ServiceBus/namespaces/{namespaceName} に対するPUTとして定義されています。今回の変更では、ここで利用するAPI versionに 2026-01-01 が加わったと考えると理解しやすいです。(Microsoft Learn)
影響を受けやすい利用者
今回のAzure REST API ServiceBus 2026-01-01対応で確認すべきなのは、Azure PortalだけでService Busを操作しているユーザーよりも、コードやテンプレートで名前空間を管理しているユーザーです。
| 利用状況 | 対応優先度 | 理由 |
|---|---|---|
| REST APIを直接呼び出してService Bus名前空間を作成している | 高 | api-version とリクエストJSONを直接管理しているため |
| ARMテンプレート、Bicep、Terraform AzAPIでService Busをデプロイしている | 高 | テンプレート内のAPI versionやプロパティ定義を確認する必要がある |
| OpenAPIからSDKやクライアントを自動生成している | 高 | 新しいモデルプロパティやAPI version enumの追加が生成物に影響する |
| 2025-05-01-previewを利用していた | 中〜高 | previewからstableへ移る判断材料になる |
| Service BusのパブリックアクセスをIPv6対応させたい | 高 | ipV6Enabled を使う可能性がある |
| メッセージ送受信だけをSDKで行っている | 低〜中 | 管理APIではないが、ネットワーク到達性の変更が間接的に影響する可能性がある |
| Azure Portal中心でIaCを使っていない | 低 | ただしネットワークポリシー上のIPv6対応方針は確認したほうがよい |
SDKについては、PR内でGo、Python、JavaScript、JavaなどのAPI reviewが作成されています。REST API仕様に追加された直後に、すべての言語SDKで同時に同じ形で使えるとは限りません。SDK経由で設定したい場合は、利用中のSDKパッケージのリリースノートや型定義に ipV6Enabled が反映されているかを確認してください。(GitHub)
移行すべきか判断する基準
2026-01-01 が追加されたからといって、すべての環境で即時移行が必要とは限りません。判断の目安は次のとおりです。
| 現在の状態 | 推奨判断 |
|---|---|
2025-05-01-preview を本番で使っている | stable版の 2026-01-01 への移行を検討する |
2024-01-01 など既存stableで問題なく運用している | IPv6対応が不要なら急いで変更せず、検証環境で差分確認する |
| IPv6対応をService Busのパブリックアクセスに組み込みたい | 2026-01-01 を使った検証を優先する |
| JSONスキーマを厳格に固定している | GETレスポンスやSDKモデルに新プロパティが入っても失敗しないか確認する |
| ネットワーク制御をIPv4前提で設計している | ipV6Enabled を有効化する前にセキュリティレビューを行う |
移行の判断で重要なのは、「API versionを上げること」と「IPv6を有効にすること」を分けて考えることです。api-version=2026-01-01 を使うだけなら、必ずしも ipV6Enabled: true を指定する必要はありません。一方で、IPv6を有効化するなら、アプリケーションだけでなくネットワーク、監視、セキュリティ運用まで含めて確認する必要があります。
設定前に確認すべきネットワーク上の注意点
ipV6Enabled は「パブリックネットワークアクセスでIPv6を有効にするか」を示すプロパティです。ここで混同しやすいのが、Service BusのIPファイアウォール、Private Endpoint、publicNetworkAccessの関係です。
Service BusのIP firewallドキュメントでは、IP firewall rulesはIPv4アドレスまたはIPv4 CIDR範囲で受信トラフィックを制限すると説明されています。また、Private EndpointとService EndpointはService BusのPremium tierでサポートされるとされています。(Microsoft Learn)
そのため、IPv6を有効化する場合は、少なくとも次を確認してください。
| 確認項目 | 確認内容 |
|---|---|
publicNetworkAccess | Disabled の場合、パブリックアクセス向けのIPv6設定が実質的に意味を持たない可能性がある |
| IP firewall rules | 既存の許可リストがIPv4前提なら、IPv6通信をどう扱うかを決める |
| Private Endpoint | private接続中心の構成では、パブリックIPv6有効化が必要か再確認する |
| 社内プロキシ・出口NAT | クライアントがIPv4とIPv6のどちらで出ていくか確認する |
| DNSと名前解決 | IPv6経路が使われる可能性を想定し、疎通確認を行う |
| 監視ログ | IPv6由来の接続を検知・調査できる運用になっているか確認する |
特に「IPv6を有効にすれば、既存のIPv4ファイアウォール設計のまま安全に動く」と考えるのは危険です。セキュリティチームがIPv6の許可方針を持っていない場合は、本番有効化の前にネットワークルール、監査ログ、インシデント対応手順を見直してください。
実務での確認手順
まずは、本番環境へ反映する前に、コード・テンプレート・ネットワークの3方向から確認します。
| 手順 | 作業 | 目的 |
| -: | ————————- | ———————————– |
| 1 | リポジトリ内のService Bus定義を検索する | どこでAPI versionを固定しているか把握する |
| 2 | 現在のAPI versionを確認する | 2024-01-01、preview、独自生成SDKなどを分類する |
| 3 | ipV6Enabled が必要か判断する | IPv6対応が要件なのか、単なる仕様追従なのか切り分ける |
| 4 | 検証環境で 2026-01-01 を使う | 作成・更新・GETのレスポンス差分を見る |
| 5 | 厳格なJSON検証を確認する | 未知のプロパティやoptional booleanで失敗しないか見る |
| 6 | IPv4/IPv6の疎通をテストする | クライアント、プロキシ、Firewall、DNSの挙動を確認する |
| 7 | 本番反映は段階的に行う | 監視しながら一部環境から切り替える |
リポジトリでは、次のような検索から始めると効率的です。
grep -R "Microsoft.ServiceBus/namespaces@" -n .
grep -R "api-version=.*2025-05-01-preview" -n .
grep -R "api-version=.*2024-01-01" -n .
grep -R "ServiceBus" -n ./infra ./deploy ./templatesREST APIを直接呼び出している場合は、GETで現在の名前空間状態を確認します。
GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ServiceBus/namespaces/{namespaceName}?api-version=2026-01-01レスポンスで確認したいのは、少なくとも次の項目です。
{
"properties": {
"publicNetworkAccess": "Enabled",
"ipV6Enabled": true
}
}ipV6Enabled はoptionalです。レスポンスに出ない、または期待した値と異なる場合は、SKU、リージョン、API version、サービス側の対応状況、テンプレートの反映状況を切り分けてください。未指定時の既定値を推測で運用ルールに組み込むのは避け、実際のGET結果で確認するのが安全です。
IaCやSDK生成で失敗しやすいポイント
今回の変更は追加型ですが、運用現場では次のような小さな差分が障害につながることがあります。
ipV6Enabled の大文字小文字を間違える
正しいプロパティ名は ipV6Enabled です。ipv6Enabled、ipv6enabled、ipV6enable などは正しくありません。ARMテンプレートやJSONでは大文字小文字が意味を持つため、レビュー時に必ず確認しましょう。
previewからstableへ移るだけで安心してしまう
2025-05-01-preview を使っていた場合、2026-01-01 への移行は自然な候補です。ただし、stableになったからといって、本番で即時反映してよいとは限りません。API version変更により、レスポンス、長時間実行操作、SDK生成結果、型定義が変わる可能性があります。
GETレスポンスの未知フィールドで処理が落ちる
独自ツールでService Bus名前空間のレスポンスをパースしている場合、未知のプロパティを許容する設計になっているか確認してください。特に、JSON Schemaで additionalProperties: false のような厳格な検証をしている場合、新しいプロパティの追加だけで処理が失敗することがあります。
publicNetworkAccess とIPv6設定を別々に考えていない
ipV6Enabled はパブリックネットワークアクセスに関するプロパティです。publicNetworkAccess が Disabled の構成、Private Endpoint中心の構成、Selected networks中心の構成では、IPv6有効化が期待どおりの効果を持つかを別途確認する必要があります。Service Busのネットワーク設定では、Public access、Selected networks、Disabledなどの選択肢があり、Selected networksでルールを設定しないとアクセス不能になるケースも説明されています。(Microsoft Learn)
SDKの対応をREST API仕様と同時だと思い込む
REST API仕様に追加されても、利用している言語SDKやCLI、Terraform providerにすぐ反映されるとは限りません。SDKでプロパティが見えない場合は、REST APIを直接使う、AzAPIのようにAPI versionを明示できる手段を使う、またはSDKの対応版を待つといった判断が必要です。
既存環境でのおすすめ対応方針
すでにService Busを運用している場合は、次の順序で進めるのが現実的です。
| フェーズ | 対応内容 |
|---|---|
| 調査 | どのテンプレート、RESTクライアント、SDKがService Bus名前空間を管理しているか洗い出す |
| 影響確認 | api-version 固定、JSONスキーマ、SDK生成、CI/CDの検証項目を確認する |
| 検証 | 検証用名前空間で 2026-01-01 と ipV6Enabled の挙動を確認する |
| セキュリティ確認 | IPv6通信、Firewall、プロキシ、監視ログ、アラートを確認する |
| 段階適用 | 非本番から本番へ、環境単位で順番に反映する |
| 運用化 | 手順書、IaC、レビュー観点、監視ルールに反映する |
IPv6対応が不要な環境では、まず 2026-01-01 の検証だけを行い、ipV6Enabled の有効化は後回しにして構いません。逆に、IPv6対応がセキュリティ要件やネットワーク要件に含まれている場合は、ipV6Enabled を単なる追加プロパティとして扱わず、通信経路全体の変更としてレビューしてください。
次にやるべきこと
今回のAzure REST API ServiceBus 2026-01-01更新で最初にやるべきことは、既存コードに Microsoft.ServiceBus のAPI version固定があるかを確認することです。そのうえで、IPv6対応が必要な環境だけ ipV6Enabled の検証を進めましょう。
特に、IaCでService Bus名前空間を管理しているチーム、OpenAPIからSDKを生成しているチーム、社内ネットワークでIPv6利用方針が決まっているチームは、今回の変更を早めにレビュー対象へ入れるべきです。一方、メッセージ送受信だけを行うアプリケーションでは、すぐにコード変更が必要とは限りません。ただし、名前空間のパブリックアクセス設定が変わると接続経路に影響する可能性があるため、インフラ側の変更予定はアプリチームにも共有しておくと安全です。
最終的には、api-version=2026-01-01 の採用可否、ipV6Enabled の有効化要否、ネットワーク制御の見直し範囲を分けて判断してください。API versionの更新とIPv6有効化を同時に本番反映すると、問題発生時の切り分けが難しくなります。まず検証環境でAPI versionだけを切り替え、次にIPv6設定を加える段階的な進め方が現実的です。
コメント