結論から言うと、2026年5月19日にマージされた「Azure REST API documentation update: Fabric Mirroring Review Fixes」は、Azure REST APIの実行基盤そのものを大きく変える更新ではなく、Azure Database for MySQL Flexible Server向けFabric Mirroring設定APIの仕様・OpenAPI・サンプルをARMレビューに合わせて修正する更新です。特に確認すべき点は、リソース名が小文字のdefaultに統一されたこと、PUTの非同期処理で202 Acceptedが削除されたこと、List操作がページング形式に整理されたこと、DELETEではなくPUTで有効・無効を切り替える前提が明確になったことです。(GitHub)
この変更は、Azure portalだけでFabric Mirroringを操作している利用者よりも、Azure REST API、ARM API、OpenAPI、SDK生成、CI/CD、TerraformのAzAPI、独自スクリプトでfabricMirroringSettingsを扱う管理者・開発者に影響します。とくにapi-version=2025-12-01-previewを前提に検証しているチームは、リクエストパス、レスポンスコード、LROポーリング、SDK差分を早めに確認しておくべきです。
Azure REST APIのFabric Mirroring Review Fixesとは何か
今回の「Fabric Mirroring Review Fixes」は、Azure REST API仕様を管理するAzure/azure-rest-api-specsリポジトリ上のPR #43298として公開・マージされた更新です。azure-rest-api-specsは、Microsoft AzureのREST API仕様の主要なソースとして位置付けられており、ここでの変更はOpenAPI、SDK生成、REST APIリファレンス、クライアント実装に波及する可能性があります。(GitHub)
対象は、Microsoft Fabricそのもののワークスペース操作APIではなく、Azure Resource Manager経由でAzure Database for MySQL Flexible ServerのFabric Mirroring設定を扱うARM API仕様です。変更ファイルを見ると、Microsoft.DBforMySQL/FlexibleServers/FabricMirroringSettings.tsp、2025-12-01-previewのサンプル、生成済みopenapi.jsonが更新されています。(GitHub)
混同しやすい点として、Microsoft Fabricのミラーリング機能自体は、Azure Database for MySQLのデータをFabric OneLakeへ継続的に複製し、分析・BI・データサイエンス用途で使えるようにする機能です。Microsoftの説明では、Azure Database for MySQLのデータをFabric OneLakeへ継続的にレプリケートできる機能として案内されています。(Microsoft Learn)
ただし今回のPRは、Fabric Mirroring機能全体の新機能発表ではありません。APIレビューで指摘された仕様上の不整合を直し、今後のREST API利用やSDK生成で誤解が起きにくい形に整える更新と捉えるのが実務上は正確です。
変更点の全体像
今回の更新で見るべきポイントは、次の4つです。
| 変更点 | 変更前に起きやすい問題 | 変更後に確認すべきこと |
|---|---|---|
| シングルトン名の修正 | Defaultや任意の3〜24文字名を使えるように見える | パス・サンプル・コードを小文字のdefaultへ統一する |
PUTの202 Accepted削除 | 非同期PUTは202で返ると想定して実装してしまう | 201 CreatedとAzure-AsyncOperationヘッダーでLROを扱う |
| List操作のページング整理 | nextLinkがあるのにx-ms-pageableがない不整合 | value配列とnextLinkを扱えるクライアントにする |
| DELETEなしの説明明確化 | 設定を削除して無効化する設計と誤解する | stateをEnabledまたはDisabledにしてPUTで切り替える |
PRの説明では、これらは過去のPR #39083に対するARM APIレビューコメントへの対応であり、対象はFabric Mirroringのみ、ReaderEndpointやRename ServerはこのPRでは扱わないと明記されています。(GitHub)
変更点：リソース名は小文字のdefaultに統一
もっとも分かりやすい変更は、FabricMirroringSettingsがシングルトンリソースとして扱われ、名前が小文字のdefaultに統一された点です。
更新前のサンプルではfabricMirroringSettingsNameやレスポンス内のnameにDefaultが使われていましたが、更新後はdefaultへ修正されています。TypeSpec側でも、以前のような任意の名前パターンではなく、FabricMirroringSettingsNameとしてdefaultを表す定義が追加されています。(GitHub)
実務上は、次のようなRESTパスに含まれる最後の名前部分をdefaultに合わせる必要があります。
PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforMySQL/flexibleServers/{serverName}/fabricMirroringSettings/default?api-version=2025-12-01-preview注意したいのは、単なる表記ゆれではなく、SDK生成やOpenAPI検証ではDefaultとdefaultが別物として扱われる可能性があることです。既存の検証コードやサンプルをコピーしたスクリプトにDefaultが残っている場合は、早めに修正しておくべきです。
確認すべきコード例
次のような値を使っている場合は見直し対象です。
{
"fabricMirroringSettingsName": "Default"
}修正後は、小文字に統一します。
{
"fabricMirroringSettingsName": "default"
}ARMテンプレート、AzAPI、独自のHTTPクライアント、CIのモックレスポンス、APIテスト用JSONに同じ表記が残りやすいため、リポジトリ全体でFabricMirroringSettings、fabricMirroringSettingsName、/fabricMirroringSettings/Defaultを検索すると効率的です。
変更点：PUTの202 Acceptedが削除され、201のLRO処理が重要に
今回の更新では、FabricMirroringSettingsのPUTから非推奨扱いの202 Acceptedレスポンスが削除されました。PRのレビューコメントでは、新しいリソースタイプにおける非同期PUTの202が非推奨であるため、ArmAcceptedLroResponseと関連する抑制を削除し、PUTは200または201を返す形にしたと説明されています。(GitHub)
ここで重要なのは、201 Createdが返ったからといって、処理が完全に完了したと早合点しないことです。更新後のサンプルでは、201レスポンスにAzure-AsyncOperationとRetry-Afterヘッダーが含まれ、provisioningStateもUpdatingとして扱われています。OpenAPI側では、長時間実行操作の最終状態取得方法がlocationからazure-async-operationへ変更されています。(GitHub)
失敗しやすい実装パターン
手書きのRESTクライアントでは、次のような実装がよくあります。
if status_code == 202:
poll_operation()
else if status_code == 200 or status_code == 201:
return successこの実装だと、201で非同期処理が始まったケースを完了扱いしてしまう可能性があります。今回の変更後は、レスポンスコードだけでなく、Azure-AsyncOperationヘッダーの有無を見てポーリングを行う実装にするのが安全です。
if response.headers contains "Azure-AsyncOperation":
wait according to Retry-After
poll Azure-AsyncOperation until succeeded or failed
else:
treat response as completedAzure SDKを使っている場合はSDK側のPollerが吸収することが多いものの、今回のPRではAPI変更チェックによりGo SDKのBreaking ChangeラベルやSwagger BreakingChangeの失敗が検出されています。SDKを生成・更新して使うチームは、言語別の生成結果を確認してから本番コードに取り込むべきです。(GitHub)
変更点：List操作はページング対応の形式へ
List操作も見直されています。以前はArmListSinglePageByParentが使われていましたが、nextLinkを含む応答スキーマとの整合性がないため、ArmResourceListByParentへ変更され、OpenAPIにはx-ms-pageableとnextLinkName: nextLinkが追加されています。(GitHub)
一方で、FabricMirroringSettingsはシングルトンであり、名前はdefaultのみです。そのため、機能的にはList結果は最大1件で、通常はnextLinkがnullになる想定です。PR上でも、シングルトンなのでページングは機能的には必要ないが、他のList操作と整合させるためにページングパターンへ変更したと説明されています。(GitHub)
実装上は、「1件しか返らないから単一オブジェクト」と決め打ちしないことが大切です。API仕様上はListなので、次のようにvalue配列として扱います。
{
"value": [
{
"name": "default",
"type": "Microsoft.DBforMySQL/flexibleServers/fabricMirroringSettings",
"properties": {
"state": "Enabled"
}
}
],
"nextLink": null
}nextLinkがある場合に備えて汎用的なページング処理を入れておくと、将来の仕様変更やSDK生成コードとの相性も良くなります。
変更点：DELETEではなくPUTで有効・無効を切り替える
今回のPRでは、DELETE操作がない理由に関する抑制コメントも修正されています。FabricMirroringSettingsは親サーバーに紐づくサーバー内在型のシングルトンであり、独立して作成・削除するリソースではなく、stateをEnabledまたはDisabledにしてPUTで切り替えると説明されています。(GitHub)
つまり、管理者が「Fabric Mirroring設定を消して無効化する」と考えてDELETEを探すのは誤りです。運用上は、設定リソースのライフサイクルを親のMySQL Flexible Serverに従属するものとして扱い、状態変更はPUTで行う前提に寄せる必要があります。
運用設計での考え方
Fabric Mirroringを一時停止・無効化する運用を自動化する場合は、次のような方針にすると安全です。
| やりたいこと | 推奨される考え方 |
|---|---|
| Mirroringを有効化する | fabricMirroringSettings/defaultへPUTし、state: Enabledを指定する |
| Mirroringを無効化する | DELETEではなく、PUTでstate: Disabledを指定する設計にする |
| 状態を確認する | GETまたはListでproperties.stateとprovisioningStateを確認する |
| 親サーバーを削除する | 親のMySQL Flexible Serverのライフサイクルとして扱う |
「削除できないリソース」は運用自動化で例外処理を生みやすい箇所です。監査ログや構成管理台帳でも、「削除済み」ではなく「無効化済み」として扱うように表現をそろえると、運用担当者間の誤解を減らせます。
管理者・開発者への影響範囲
今回の変更は、すべてのAzure利用者に影響するものではありません。影響が出やすいのは、Fabric Mirroring設定APIを直接または間接的に扱うケースです。
| 対象者 | 影響度 | 確認ポイント |
|---|---|---|
| Azure portalでのみ操作する管理者 | 低 | REST API仕様差分の直接対応は少ないが、プレビュー制限は確認する |
| REST APIを直接呼ぶ開発者 | 高 | default、201、LROヘッダー、nextLink処理を確認する |
| Azure SDKを使う開発者 | 中〜高 | SDK更新時の型名・メソッド・Poller挙動の差分を確認する |
| OpenAPIからクライアントを生成するチーム | 高 | enum、ページング、レスポンスコード差分で生成物が変わる可能性を確認する |
| Terraform AzAPIやARM JSONで扱う管理者 | 中 | リソース名、APIバージョン、PUTレスポンスを検証する |
| Fabric Mirroringの利用可否を判断するIT管理者 | 中 | MySQL側の前提条件、ネットワーク、テーブル制約を別途確認する |
特に、api-versionをプレビュー版に固定している場合は注意が必要です。PR #43298は2025-12-01-previewのOpenAPIやサンプルを更新しているため、同じAPIバージョンを前提にしたテストデータやモックも合わせて直す必要があります。(GitHub)
展開前に確認すべきチェックリスト
実務では、仕様変更の内容を読むだけでなく、自分たちのコード・設定・運用に残っている古い前提を洗い出すことが重要です。次の順番で確認すると、抜け漏れを減らせます。
| 確認項目 | 具体的な確認方法 | 見落とすと起きる問題 |
|---|---|---|
Default表記が残っていないか | コード、JSON、テスト、ドキュメントを全文検索 | SDK検証やAPI呼び出しで不整合が起きる |
| PUT後のLROを処理しているか | 201でもAzure-AsyncOperationを見ているか確認 | 未完了の状態を成功扱いする |
202だけを非同期開始条件にしていないか | HTTPステータス分岐を確認 | ポーリング漏れが発生する |
| Listを単一オブジェクトとして扱っていないか | value配列とnextLink処理を確認 | SDK更新時に型不一致が起きる |
| DELETEで無効化しようとしていないか | 運用手順と自動化スクリプトを確認 | APIが存在せず、無効化処理に失敗する |
| SDK生成結果を確認したか | Go、Python、C#、Javaなどの差分を見る | breaking changeを本番で踏む |
| プレビューAPIの扱いを決めているか | 本番利用可否、検証環境、ロールバック手順を整理 | 仕様変更時の対応が遅れる |
このチェックリストは、単に今回のPRに対応するためだけではなく、Azure REST APIのプレビュー版を使うときの基本作法としても有効です。プレビューAPIは機能検証に便利ですが、OpenAPIやSDKの仕様がレビュー過程で変わることがあります。自動化の中核に組み込む場合は、APIバージョン、SDKバージョン、レスポンス仕様を固定して検証する運用が欠かせません。
Fabric Mirroring自体の前提条件も確認する
今回のPRはREST API仕様の修正ですが、Fabric Mirroringを実際に使う場合は、MySQL側の要件も確認する必要があります。Microsoftのドキュメントでは、Azure Database for MySQLのFabric Mirroringは、複雑なETLを避けて既存のMySQLデータをFabric OneLakeへ統合する用途として説明されています。セットアップではAzure portalでFabric Mirroringを有効化し、その後Fabric portalでミラー化されたデータベースを作成する流れが示されています。(Microsoft Learn)
また、MySQL側には制限があります。たとえば、Fabric MirroringはMySQL 8.0系を対象とし、Burstable Compute Tier、カスタムポート、HA、Read Replica、Entra ID Authenticationなどに関する制約が記載されています。さらに、PITRで復元したサーバーではMirroringの再構成が必要で、メジャーバージョンアップ前にはMirroringを無効化し、完了後に再有効化する必要があると案内されています。(Microsoft Learn)
テーブル単位でも、主キーのないテーブルはミラーリングできない、DDL操作がレプリケーションに影響する可能性がある、サポートされないデータ型がある、といった制限があります。APIだけを正しく呼べても、MySQL側の前提条件を満たしていなければ展開時に詰まるため、REST API対応とあわせてデータベース設計も確認しましょう。(Microsoft Learn)
REST API実装で更新すべき具体例
手書きRESTクライアントやCI/CDでAPIを直接呼ぶ場合は、次の観点で修正します。
リクエストパスはdefault固定にする
古いサンプルや社内資料にDefaultが残っている場合は、小文字へ統一します。
GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforMySQL/flexibleServers/{serverName}/fabricMirroringSettings/default?api-version=2025-12-01-previewPUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforMySQL/flexibleServers/{serverName}/fabricMirroringSettings/default?api-version=2025-12-01-preview大文字小文字を気にしない実装に見えても、OpenAPIから生成したクライアントやテストコードでは差分として表面化しやすいため、仕様に合わせておくのが安全です。
PUT後はヘッダーを見てポーリングする
PUTのレスポンスで201が返った場合でも、Azure-AsyncOperationが含まれていれば非同期処理として扱います。
HTTP/1.1 201 Created
Azure-AsyncOperation: https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.DBforMySQL/locations/{location}/azureAsyncOperation/{operationId}?api-version=2025-12-01-preview
Retry-After: 30この場合、Retry-Afterを参考に待機し、Azure-AsyncOperationのURLをポーリングして完了状態を確認します。201を即時成功とみなすと、後続処理がprovisioningState: Updatingの状態で進み、Fabric側の設定やデータ連携確認でタイミング不整合が起きる可能性があります。
Listは配列とnextLinkを処理する
Listの結果が最大1件であっても、実装は配列として扱います。
items = []
response = call_list()
items.add_all(response.value)
while response.nextLink is not null:
response = call(response.nextLink)
items.add_all(response.value)現時点の仕様意図としてはnextLink: nullが自然ですが、ページング対応の形で実装しておくと、SDK更新や将来の仕様変更でも壊れにくくなります。
SDK利用者が注意すべきポイント
SDK利用者は、REST APIを直接書いていなくても影響を受ける可能性があります。PR上ではAPIレベルの変更が検出され、TypeSpec、Go、Python、C#、JavaのAPIレビューが作成されています。また、Go SDKではBreaking Changeラベルが付与されています。(GitHub)
SDK更新時に確認したいのは、次の3点です。
| 確認点 | なぜ重要か |
|---|---|
| 名前パラメーターの型 | FabricMirroringSettingsNameのenum化により、指定方法が変わる可能性がある |
| PUTメソッドの戻り値 | LRO Pollerや戻り値の型が変わる可能性がある |
| Listメソッドの戻り値 | ページング対応により、反復処理の型やメソッドが変わる可能性がある |
特にGo SDKのように型の差分がコンパイルエラーとして出やすい言語では、SDK更新を本番ブランチに直接入れるのではなく、検証ブランチでビルド、単体テスト、実APIへの疎通確認を行うのが現実的です。
管理者が運用手順に反映すべきこと
管理者は、今回の変更を単なる「ドキュメント修正」として流さず、運用手順の表現を見直すとよいでしょう。
まず、Fabric Mirroring設定を「作成・削除するリソース」ではなく、「親サーバーに属する設定状態」として説明します。無効化手順にDELETEを含めないことが重要です。
次に、ミラーリングの有効化後は即時完了ではなく、provisioningStateや非同期操作の完了を確認する流れを手順化します。運用担当者向けの手順書には、「PUT実行後、Azure-AsyncOperationが返る場合は完了まで待つ」と明記しておくと、トラブルシューティング時に役立ちます。
最後に、APIバージョンがプレビューであることを前提に、リリース前検証を組み込みます。たとえば、開発環境でGET、PUT、Listの3操作を実行し、レスポンスコード、ヘッダー、name、state、provisioningStateを記録してから本番環境に展開する流れが安全です。
今回の更新で対象外のもの
今回のPRは、Fabric Mirroring関連のレビュー修正に絞られています。PR説明では、ReaderEndpointやRename Serverは対象外とされています。(GitHub)
そのため、MySQL Flexible Server全体のAPI仕様が一括で変わったと解釈するのは避けるべきです。確認対象は、Microsoft.DBforMySQL/flexibleServers/fabricMirroringSettings、2025-12-01-preview、Fabric Mirroringの有効化・状態確認・List処理に限定して考えると整理しやすくなります。
また、Fabric Mirroring機能の制限や対応リージョン、ネットワーク要件は、REST API仕様だけでは判断できません。実際の導入可否は、Fabric Mirroringの公式ドキュメント、Azure Database for MySQLの制限、組織のセキュリティ要件を合わせて確認する必要があります。
まとめ：まずdefault、LRO、List、無効化手順を確認する
今回のAzure REST API documentation update: Fabric Mirroring Review Fixesは、見た目以上に実装へ影響する可能性がある仕様整理です。大きなポイントは、fabricMirroringSettingsの名前を小文字のdefaultに統一すること、PUT後の201とAzure-AsyncOperationを正しく扱うこと、Listをページング対応の配列として処理すること、DELETEではなくPUTでEnabled/Disabledを切り替えることです。
次に取るべき行動は明確です。REST API、SDK、AzAPI、OpenAPI生成、CIテストのどれかでFabric Mirroring設定を扱っているなら、まずリポジトリ内をDefault、fabricMirroringSettingsName、202 Accepted、ArmAcceptedLroResponse、nextLinkで検索してください。そのうえで、開発環境でGET、PUT、Listの動作を確認し、LRO完了待ちまで含めた手順に更新してから展開するのが安全です。
コメント