Azure Storage documentation update: update JS override for storageは、Azure Storageの保存先設定やBLOB/Queue/Fileの動作を変える更新ではありません。結論から言うと、Azure Storage Resource Providerの仕様ファイルで、JavaScript SDK向けのDeletedAccounts.get生成ルールを分離する変更です。
特に確認すべきなのは、Node.js/TypeScriptで@azure/arm-storageを使い、削除済みストレージアカウントの取得処理を直接呼び出しているコードです。PRは2026年5月20日にAzure/azure-rest-api-specsへマージされ、変更ファイルはspecification/storage/Storage.Management/client.tspです。PR上ではJavaScript SDK向けのBreaking Changeラベルも付いているため、SDK更新時にはコンパイル確認と実行テストを行うべきです。(GitHub)
まず押さえる結論
| 観点 | 重要ポイント |
|---|---|
| 変更の実体 | Azure StorageのTypeSpec定義にあるJavaScript向けoverride更新 |
| 主な対象 | @azure/arm-storageでDeletedAccounts.get相当の操作を使う開発者 |
| 影響が薄い範囲 | 通常のBlob/Queue/File/Tableのデータ操作、Azureポータル上のストレージ設定 |
| 確認すべきこと | SDK更新時のメソッド引数、型定義、ラッパー関数、CIのTypeScriptコンパイル |
| すぐ取るべき行動 | 利用箇所の検索、SDKバージョン固定、検証環境での取得テスト |
今回の更新は「Azure Storageそのものの仕様変更」というより、Azure REST API仕様から生成されるSDKの形に関わる変更です。azure-rest-api-specsリポジトリはMicrosoft AzureのREST API仕様の基準となるリポジトリであり、仕様完了後にはSDKやAPIリファレンス生成につながる位置づけです。(GitHub)
Azure Storageの「update JS override for storage」は何の更新か
このPRのタイトルはupdate JS override for storageです。差分を見ると、対象はAzure Storageの管理プレーン仕様であるStorage.Management/client.tspの1ファイルのみです。PRのファイル変更は22件で、17行追加・5行削除と表示されています。(GitHub)
変更の中心は、DeletedAccounts.getに対するoverride指定です。以前はJava、Go、Python、JavaScriptが同じoverrideに含まれていましたが、更新後はJavaScriptだけを別のgetDeletedAccountCustomizedForJsとして分離しています。(GitHub)
変更前:
DeletedAccounts.get の override 対象に java, go, python, javascript を含める
変更後:
java, go, python 用の override と
javascript 専用の override を分けるここでいう「JS override」は、ブラウザーのJavaScriptやWeb Storage APIの話ではありません。Azure SDK for JavaScript/TypeScriptを生成する際に、特定の操作のクライアント側メソッドやパラメーターの扱いを調整するための定義です。
変更点：DeletedAccounts.getのJavaScript向け定義が分離された
今回のPRでは、DeletedAccounts.getに対してJavaScript専用のgetDeletedAccountCustomizedForJsが追加されています。差分上では、JavaScript向けのoverrideが@@override(DeletedAccounts.get, getDeletedAccountCustomizedForJs, "javascript")として定義されています。(GitHub)
Microsoft Learnの現行リファレンスでは、@azure/arm-storageのDeletedAccountsOperations.getは次の形で説明されています。(Microsoft Learn)
get: (
deletedAccountName: string,
location: string,
options?: DeletedAccountsGetOptionalParams
) => Promise<DeletedAccount>また、StorageManagementClientはコンストラクターでTokenCredentialとsubscriptionIdを受け取り、プロパティとしてdeletedAccountsを持ちます。つまり、一般的な利用コードではsubscriptionIdをgetメソッドの引数に直接渡すのではなく、クライアント生成時に指定します。(Microsoft Learn)
import { StorageManagementClient } from "@azure/arm-storage";
const client = new StorageManagementClient(credential, subscriptionId);
const deletedAccount = await client.deletedAccounts.get(
deletedAccountName,
location
);実務上の確認ポイントは、既存コードがこの形に沿っているかです。特に、古い生成結果や自作ラッパーに合わせて、apiVersionやsubscriptionIdをメソッド引数として独自に差し込んでいる場合は、SDK更新後に型エラーや実行時エラーになる可能性があります。
対象となる操作は「削除済みストレージアカウントの取得」
DeletedAccounts.getは、削除済みストレージアカウントのプロパティを取得する管理プレーン操作です。Microsoft LearnのREST APIリファレンスでは、Deleted Accounts - GetはStorage Resource Providerの操作として説明され、指定された削除済みアカウントリソースのプロパティを取得するとされています。(Microsoft Learn)
REST APIのURIは、次の構造です。(Microsoft Learn)
GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Storage/locations/{location}/deletedAccounts/{deletedAccountName}?api-version=2026-04-01必要な主なパラメーターは以下です。
| パラメーター | 種類 | 役割 |
|---|---|---|
subscriptionId | path | 対象サブスクリプションのID |
location | path | 削除済みアカウントが存在するAzureリージョン |
deletedAccountName | path | 削除されたストレージアカウント名 |
api-version | query | 利用するREST APIバージョン |
応答例には、削除済みアカウントのcreationTime、deletionTime、restoreReference、元のstorageAccountResourceIdなどが含まれます。復旧判断や監査、削除済みリソースの棚卸しに使われる情報です。(Microsoft Learn)
影響範囲：通常のストレージ利用者よりSDK利用者が優先確認
今回の変更は、Azure Storageアカウントのネットワーク設定、暗号化、アクセスキー、Blobコンテナー、Queue、File共有などを直接変更するものではありません。影響を受けやすいのは、管理APIをSDK経由で呼び出しているコードです。
| 対象者 | 影響度 | 確認すべき内容 |
|---|---|---|
| JavaScript/TypeScript開発者 | 高 | @azure/arm-storageのdeletedAccounts.get利用箇所、引数順、型定義 |
| SDK生成・社内SDK管理担当 | 高 | TypeSpecから生成したクライアントの差分、APIレビュー結果 |
| Azure管理者 | 中 | 削除済みストレージアカウントを監査・復旧する自動化スクリプト |
| DevOps/SRE | 中 | CI/CDでSDKを自動更新していないか、ロックファイルを固定しているか |
| Bicep/ARM/Terraform利用者 | 低 | 通常のデプロイ定義への直接影響は限定的 |
| Blob/Queue/File/Tableのアプリ開発者 | 低 | データプレーン操作だけなら影響は基本的に限定的 |
PR上ではAPIViewがAPIレベルの変更を検出し、TypeSpec、Go、Java、JavaScript、Python、C#のAPIレビューを作成しています。さらに、ラベルとしてBreakingChange-JavaScript-Sdkのほか、GoとPythonのBreaking Change関連ラベルも付与されています。(GitHub)
ただし、Breaking Changeラベルがあるからといって、すべてのAzure Storage利用者がすぐ影響を受けるわけではありません。実際に影響が出るのは、該当するSDKパッケージの新バージョンを取り込み、かつ対象操作を利用している場合です。
開発者が確認すべきコード
まず、リポジトリ内で@azure/arm-storageとdeletedAccountsの利用箇所を洗い出します。TypeScriptなら、型チェックで早期に検出できます。
grep -R "@azure/arm-storage" .
grep -R "deletedAccounts.get" .
grep -R "DeletedAccounts" .PowerShell環境では、次のように検索できます。
Select-String -Path .\**\*.ts,.\**\*.js -Pattern "deletedAccounts.get","DeletedAccounts","@azure/arm-storage"確認するポイントは、単にメソッドが存在するかではありません。次のようなコードは、SDK更新時に壊れやすいので注意が必要です。
| 見直すべきコード | 理由 |
|---|---|
as anyで型エラーを回避している | SDKの正しい引数順変更を検出できない |
自作ラッパーでapiVersionを先頭引数にしている | 現行のget定義とずれる可能性がある |
deletedAccountNameとlocationを変数名だけで渡している | 引数順の誤りに気づきにくい |
SDKを^指定で自動更新している | 意図せず新しい生成結果を取り込む可能性がある |
| JavaScriptのみで型チェックしていない | TypeScriptなら検出できる問題が実行時まで残る |
おすすめは、deletedAccountNameとlocationを明確な変数名で分け、呼び出し直前にログやテストで確認できるようにすることです。
const deletedAccountName = "sto1125";
const location = "eastus";
const result = await client.deletedAccounts.get(
deletedAccountName,
location
);REST APIリファレンスでも、URI上の順序はlocations/{location}/deletedAccounts/{deletedAccountName}ですが、JavaScript SDKのgetメソッドはdeletedAccountName、locationの順で定義されています。URIの順序をそのままSDK引数に当てはめないことが重要です。(Microsoft Learn)
管理者・運用チームが確認すべき設定
Azure管理者が見るべきポイントは、ポータル設定の変更ではなく、運用スクリプトや監査ジョブです。
たとえば、次のような用途でDeleted Accounts - Getを使っている場合は、SDK更新前に検証してください。
- 削除済みストレージアカウントの復旧可否を確認する
- 誤削除対応フローで
restoreReferenceを取得する - 削除済みリソースを定期的に棚卸しする
- 監査ログやインシデント対応で元の
storageAccountResourceIdを記録する
REST APIリファレンスでは、Deleted Accounts - Getの応答にrestoreReferenceや元のストレージアカウントのリソースIDが含まれる例が示されています。復旧や監査でこの情報を使っている組織では、SDK更新後も同じ値を取得できるか確認しておくべきです。(Microsoft Learn)
移行・展開時の安全な進め方
SDKや生成コードに関わる変更は、本番環境に入る前の検証が重要です。次の順序で進めると、影響を小さくできます。
| 手順 | 作業 | 判断基準 |
|---|---|---|
| 1 | @azure/arm-storageの利用箇所を洗い出す | deletedAccounts.get利用の有無を確認 |
| 2 | package-lock、pnpm-lock、yarn.lockを確認する | SDKの自動更新が起きない状態にする |
| 3 | 検証ブランチでSDKを更新する | TypeScriptコンパイルが通るか確認 |
| 4 | 削除済みアカウント取得の単体テストを実行する | deletedAccountNameとlocationが正しく渡るか確認 |
| 5 | 検証環境で実APIを呼び出す | 200応答または想定どおりのエラーになるか確認 |
| 6 | 本番展開を段階的に行う | 監査ジョブや復旧フローの失敗率を監視 |
特にCI/CDでnpm updateや依存関係の自動更新を許可している場合は、SDKの更新タイミングを制御してください。今回のPRは仕様側の変更であり、実際のアプリケーションに影響するタイミングは、該当SDKパッケージを取り込んだ時点です。
失敗しやすいポイント
「documentation update」だから安全だと思い込む
今回の情報はドキュメント更新のように見えますが、実体はTypeSpec上のSDK生成定義の変更です。PRではAPIViewによるAPIレベル変更の検出やBreaking Changeラベルが確認できます。単なる文章修正として扱わないほうが安全です。(GitHub)
REST APIのパス順とSDKの引数順を混同する
REST APIのURIではlocationが先に見えますが、JavaScript SDKのDeletedAccountsOperations.getはdeletedAccountName、locationの順です。リファレンス上のメソッド定義を基準に確認してください。(Microsoft Learn)
JavaScriptだけを見て、周辺の自動化を見落とす
PRタイトルはJS overrideですが、PR上ではGo、JavaScript、PythonのBreaking Change関連ラベルも付与されています。複数言語でAzure Storageの管理APIを使っている組織では、JavaScriptだけでなく、削除済みアカウント取得を行う周辺ツールも確認すると安全です。(GitHub)
型チェックなしで本番更新する
TypeScriptなら、引数や戻り値の差分をコンパイル時に検出しやすくなります。一方、素のJavaScriptでas any相当の緩い実装をしている場合、問題が本番実行時まで残ることがあります。少なくとも該当処理には統合テストを用意しましょう。
よくある質問
AzureポータルのStorage設定を変更する必要はある？
基本的には不要です。今回の変更は、Azure Storageの管理プレーン仕様におけるJavaScript SDK生成向けoverrideの更新です。ネットワーク規則、アクセスキー、暗号化、Blobコンテナー設定などを直接変える内容ではありません。
Blob StorageやQueue Storageの通常利用に影響する？
通常のデータプレーン操作だけを使っているアプリでは、影響は限定的です。対象はStorage Resource ProviderのDeletedAccounts.get、つまり削除済みストレージアカウント情報を取得する管理APIです。(Microsoft Learn)
すぐにSDKを更新すべき？
急いで本番へ入れる必要はありません。まずは現行コードで@azure/arm-storageとdeletedAccounts.getを使っているかを確認してください。使っていない場合、直接影響はほとんどありません。使っている場合は、検証環境でSDK更新、型チェック、実APIテストを行ってから本番に展開します。
確認すべき最小チェックリストは？
| チェック項目 | 完了の目安 |
|---|---|
@azure/arm-storageを使っているか | package.jsonまたはロックファイルで確認済み |
deletedAccounts.getを使っているか | ソース検索で確認済み |
| SDKバージョンが固定されているか | lockfileと依存バージョンを確認済み |
| TypeScriptコンパイルが通るか | CIで成功 |
| 削除済みアカウント取得テストがあるか | 検証環境で成功 |
| 本番展開時の監視項目があるか | エラー率、ジョブログ、復旧フローを監視 |
まとめ：まずは利用箇所の棚卸しから始める
Azure Storage documentation update: update JS override for storageは、Azure Storageの運用設定変更ではなく、Azure Storage Resource Providerの仕様からJavaScript SDKを生成する際のoverride更新です。主な確認対象は、@azure/arm-storageでDeletedAccounts.getを使っているNode.js/TypeScriptコードです。
次に取るべき行動は明確です。まず@azure/arm-storageとdeletedAccounts.getの利用箇所を検索し、SDKバージョンを固定します。そのうえで、検証環境でTypeScriptコンパイルと削除済みアカウント取得テストを実行してください。該当操作を使っていない場合は大きな対応は不要ですが、依存関係の自動更新がある環境では、SDK更新時のCI結果を必ず確認しましょう。
コメント