2026年5月3日公開・更新分として確認すべきポイントは、Azure SDK for JavaScript の @azure/arm-storagemover が Storage Mover の API Version 2025-12-01 に合わせて生成され、接続リソースやジョブ定義まわりの操作・モデルが広がったことです。すぐに対応が必要なのは、JavaScript／TypeScript で Azure Storage Mover を自動操作している開発チーム、Bicep・ARM テンプレート・Terraform AzAPI で API バージョンを固定しているインフラ担当、Private Link やクラウド間移行の構成をコード化している運用チームです。
今回の Azure SDK documentation update は、単なるドキュメント文言の修正ではありません。GitHub の PR では @azure/arm-storagemover 向けの SDK 生成が行われ、構成ファイルは specification/storagemover/StorageMover.Management/tspconfig.yaml、API Version は 2025-12-01、SDK Release Type は stable とされています。PR 自体は 2026年4月2日に main ブランチへマージされています。(GitHub)
Azure SDK documentation updateで何が変わったのか
今回の更新の中心は、Azure Storage Mover の管理プレーン SDK である @azure/arm-storagemover の生成内容が、Storage Mover の新しい API 面に追従したことです。
特に重要なのは、ConnectionsOperations の追加です。Storage Mover の移行ジョブと Private Link Service を結び付ける「Connection」リソースを、SDK から作成・取得・一覧化・削除できるようになっています。SDK のクライアントにも connections 操作グループが追加されており、StorageMoverClient から client.connections として扱える構造になっています。(GitHub)
変更点を実務目線で整理すると、次のようになります。
| 確認項目 | 内容 | 実務で見るべきポイント |
|---|---|---|
| 対象パッケージ | @azure/arm-storagemover | JavaScript／TypeScript で Storage Mover を操作しているか |
| 生成元 API | Storage Mover Management API 2025-12-01 | REST API、Bicep、Terraform AzAPI の apiVersion と差がないか |
| SDK上の主な追加 | ConnectionsOperations、Connection 関連モデル、S3 HMAC 関連モデル、スケジュール・検証関連プロパティ | 移行ジョブ、Private Link、クラウド間移行の自動化コードに影響するか |
| リリース種別 | stable | プレビュー専用ではなく、本番導入候補として検証対象に入れる |
| ランタイム条件 | package.json では Node.js >=20.0.0 | CI/CD、Azure Functions、コンテナの Node バージョンを確認する |
GitHub 上の changelog では、3.1.0 (2026-04-06) として ConnectionsOperations、Connection、ConnectionProperties、S3WithHmacEndpointProperties、ScheduleInfo、SchedulerTime、DataIntegrityValidation、TriggerType などの追加が記載されています。あわせて、KnownVersions に V20250801 と V20251201 が追加されています。(GitHub)
影響を受けやすい利用者
今回の Azure SDK documentation update で優先的に確認すべきなのは、次のようなケースです。
| 利用状況 | 対応優先度 | 理由 |
|---|---|---|
@azure/arm-storagemover をアプリや運用ツールで利用している | 高 | SDK の型、操作グループ、生成コードの変更が直接影響する |
| Storage Mover のジョブ定義をコードで作成・更新している | 高 | connections、schedule、dataIntegrityValidation などの新しいプロパティを使う可能性がある |
| Private Link を使った Storage Mover 構成を自動化している | 高 | Connection リソースの作成・承認状態・削除条件を考慮する必要がある |
| Bicep、ARM テンプレート、Terraform AzAPI で Storage Mover を管理している | 中 | Microsoft.StorageMover/...@2025-12-01 への対応可否を確認する必要がある |
| Azure ポータルだけで Storage Mover を操作している | 低 | SDK 変更の直接影響は少ないが、今後の自動化時には参考になる |
逆に、Azure Storage Mover を使っていないアプリ、または SDK ではなくポータル操作だけで完結している環境では、すぐにコード変更が必要になる可能性は高くありません。ただし、移行ジョブの作成やクラウド間移行を今後コード化する予定があるなら、今回の 2025-12-01 対応を前提に設計した方が安全です。
注目すべき変更点
ConnectionsOperationsの追加
最も分かりやすい変更は、Storage Mover の Connection リソースを SDK から扱えるようになった点です。
ConnectionsOperations には、次の操作が定義されています。
| 操作 | 役割 |
|---|---|
createOrUpdate | Connection リソースを作成または更新する |
get | 指定した Connection を取得する |
list | Storage Mover 内の Connection を一覧化する |
delete | Connection を削除する |
SDK の classic operation wrapper では、これらのメソッドが ConnectionsOperations として定義されています。また、削除については「この Connection を使用しているアクティブなジョブがある場合は 409 を返す」とコメントされています。(GitHub)
実務では、Connection を「作れば終わり」と考えないことが重要です。REST API のサンプルでは privateLinkServiceId を指定して Connection を作成し、レスポンスに connectionStatus が返る構造になっています。サンプル上では作成後の状態として Pending Approval が示されており、Private Link Service 側の承認フローを運用手順に含める必要があります。(Microsoft Learn)
Job Definitionに接続・スケジュール・整合性検証の観点が追加
Job Definition まわりでは、移行ジョブの作り方に関係するプロパティが増えています。Microsoft Learn の 2025-12-01 API では、properties.connections、properties.dataIntegrityValidation、properties.preservePermissions、properties.schedule が Job Definition の要求本文に含まれています。(Microsoft Learn)
Bicep／ARM テンプレートのリファレンスでも、Job Definition のプロパティとして次のような項目が確認できます。
| プロパティ | 用途 | 確認ポイント |
|---|---|---|
connections | ジョブに関連付ける Connection の一覧 | Private Link やクラウド間移行で必要な接続を指定しているか |
dataIntegrityValidation | チェックサム検証モード | 移行後検証の要件に合うか |
preservePermissions | 権限保持の有無 | SMB/NFS など権限情報を扱う移行で要件を満たすか |
schedule | ジョブ実行スケジュール | 日次・週次・月次・一回実行などの運用ルールに合うか |
sourceName / targetName | ソース・ターゲットのエンドポイント名 | 既存テンプレートで必須項目を満たしているか |
ScheduleInfo では、frequency に Daily、Weekly、Monthly、Onetime、None が定義され、executionTime の分は 0 または 30 が許可値として示されています。スケジュール実行を自動化する場合は、「毎時15分」などの値を安易に入れないよう注意が必要です。(Microsoft Learn)
S3 HMAC関連のモデルが追加
changelog では、S3WithHmacEndpointProperties、S3WithHmacEndpointUpdateProperties、AzureKeyVaultS3WithHmacCredentials、S3WithHmacSourceType、KnownS3WithHmacSourceType などの追加も確認できます。これは、Storage Mover のクラウド間移行や S3 系ソースを扱う構成で重要になる可能性があります。(GitHub)
ここで注意したいのは、資格情報をコードに直接埋め込まないことです。名前からも分かる通り、Azure Key Vault に格納された資格情報を参照するモデルが追加されています。実装時は、アクセスキーやシークレットを環境変数やリポジトリに置くのではなく、Key Vault、Managed Identity、RBAC の組み合わせで設計するのが基本です。
api-versionの扱いも確認対象
生成された Connection 操作のコードでは、要求 URL に api-version が入り、指定がなければ 2025-12-01 が使われる構造になっています。たとえば createOrUpdate、get、list の処理では context.apiVersion ?? "2025-12-01" が使われています。(GitHub)
SDK を使う場合は自動的に処理される部分が多い一方で、手書き REST、AzAPI、既存の Bicep テンプレートでは apiVersion の固定値が残りやすいです。古い API バージョンのまま新しいフィールドを送ると、無視されたり、検証エラーになったりする可能性があります。
移行前に確認するチェックリスト
SDK を更新する前に、まず「どこで Storage Mover を操作しているか」を洗い出してください。
npm ls @azure/arm-storagemover
npm view @azure/arm-storagemover versions --json
grep -R "@azure/arm-storagemover" -n .
grep -R "Microsoft.StorageMover" -n .
grep -R "2025-07-01\|2025-08-01\|2025-12-01\|2023-03-01" -n .確認すべき観点は次の通りです。
| チェック項目 | 判断基準 |
|---|---|
| 現在のSDKバージョン | 3.0.1 以前から更新する場合、追加された型・操作を確認する |
| Node.js バージョン | package.json の条件に合わせ、CI/CD と実行環境が Node.js 20 以上か確認する |
| IaC の API バージョン | Microsoft.StorageMover/...@2025-12-01 に更新する必要があるか確認する |
| Job Definition の作成処理 | connections、schedule、dataIntegrityValidation を使うか判断する |
| Private Link 承認手順 | Connection 作成後の connectionStatus を監視する仕組みがあるか確認する |
| 削除処理 | アクティブなジョブがある Connection を削除しようとしていないか確認する |
SDK リポジトリ上の package.json では @azure/arm-storagemover のバージョンが 3.1.0、Node.js エンジンが >=20.0.0 とされています。既存の Azure Functions、コンテナ、GitHub Actions、Azure DevOps Pipeline が Node.js 18 以前で動いている場合は、SDK 更新より先にランタイム更新の影響を確認してください。(GitHub)
実装で使える確認例
Connection を作成する処理は、概念的には次のような流れになります。実際の型や import は利用している SDK バージョンで確認してください。
import { DefaultAzureCredential } from "@azure/identity";
import {
StorageMoverClient,
type Connection
} from "@azure/arm-storagemover";
const subscriptionId = process.env.AZURE_SUBSCRIPTION_ID!;
const resourceGroupName = "rg-migration";
const storageMoverName = "mover-prod";
const connectionName = "connection-private-link";
const client = new StorageMoverClient(
new DefaultAzureCredential(),
subscriptionId
);
const connection: Connection = {
properties: {
description: "Private Link connection for Storage Mover jobs",
privateLinkServiceId:
"/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-network/providers/Microsoft.Network/privateLinkServices/pls-storage-migration"
}
};
const result = await client.connections.createOrUpdate(
resourceGroupName,
storageMoverName,
connectionName,
connection
);
console.log(result.properties?.connectionStatus);このコードで見るべき点は、作成後の成功・失敗だけではありません。connectionStatus が Pending、Approved、Rejected、Disconnected、Stale のどれになるかを運用側で確認し、承認待ちのままジョブを開始しないようにします。Connection の定義では connectionStatus、jobList、privateEndpointName、privateEndpointResourceId、privateLinkServiceId などのプロパティが示されています。(Microsoft Learn)
既存コードで失敗しやすいポイント
APIバージョンだけ古いまま残る
SDK を更新しても、Bicep や Terraform AzAPI の type が古いままだと、テンプレート側では新しいプロパティを扱えません。
たとえば Connection リソースは、Bicep では次のように 2025-12-01 のリソースとして定義されます。
resource connection 'Microsoft.StorageMover/storageMovers/connections@2025-12-01' = {
parent: storageMover
name: 'connection-private-link'
properties: {
description: 'Private Link connection'
privateLinkServiceId: privateLinkServiceId
}
}Microsoft Learn のテンプレートリファレンスでは、Microsoft.StorageMover/storageMovers/connections@2025-12-01 の properties として description、jobList、privateLinkServiceId が示されています。(Microsoft Learn)
Connection作成後の承認を見落とす
Connection は作成できても、Private Link Service 側の承認が必要な構成では、作成直後に利用可能とは限りません。サンプルレスポンスでも connectionStatus が Pending Approval の例が示されています。移行ジョブを自動起動する場合は、Connection 作成後に状態を確認し、承認完了後にジョブ定義を作る、またはジョブを開始する流れにしてください。(Microsoft Learn)
削除処理で409を想定していない
Connection を削除する自動化スクリプトでは、アクティブなジョブが使っている Connection を削除しようとした場合の 409 を想定する必要があります。SDK の ConnectionsOperations.delete には、アクティブなジョブがある場合に 409 を返す旨が記載されています。(GitHub)
削除前には、少なくとも次の順序で確認しましょう。
| 順序 | 確認内容 |
| -: | ————————— |
| 1 | 対象 Connection に紐づくジョブ定義があるか |
| 2 | 実行中または保留中の Job Run がないか |
| 3 | 移行停止後に削除しても再実行計画に影響しないか |
| 4 | 削除後に IaC の再適用で意図せず再作成されないか |
2.x系から一気に上げる
3.1.0 の changelog は機能追加が中心ですが、2.x から更新する場合は別です。3.0.0 では削除操作、シグネチャ、モデル構造に関する breaking changes が記載されています。現在 2.1.x を使っている場合は、3.0.0 の破壊的変更も含めて確認してください。(GitHub)
対応手順
今回の更新に対応するなら、次の順序で進めると安全です。
| 手順 | 作業 | 完了条件 |
| -: | ————————– | ———————————————————————— |
| 1 | 利用箇所を棚卸しする | SDK、REST、IaC、運用スクリプトの利用箇所が一覧化されている |
| 2 | npm上の公開バージョンとlockfileを確認する | 実際に導入可能なバージョンと現在の固定バージョンが分かる |
| 3 | Node.js 実行環境を確認する | ローカル、CI/CD、本番実行環境が Node.js 20 以上に対応できる |
| 4 | 2025-12-01 のAPI差分を見る | Connection、Job Definition、S3 HMAC、スケジュール関連の利用有無を判断できる |
| 5 | 開発環境でSDK更新を試す | TypeScript の型エラー、ビルド、単体テストが通る |
| 6 | Storage Mover のスモークテストを行う | Connection の create/list/get/delete、Job Definition の create/update が検証済み |
| 7 | 本番適用手順を作る | 承認フロー、ロールバック、監視項目が明文化されている |
更新コマンドは、公開バージョンを確認してから実行します。
npm view @azure/arm-storagemover version
npm install @azure/[email protected]
npm test
npm run buildパッケージ公開状況、組織内のレジストリミラー、lockfile の固定によっては、すぐに同じバージョンを取得できないことがあります。その場合は、リリース一覧、npm、GitHub changelog、Microsoft Learn の API リファレンスを突き合わせてから適用してください。
今回の更新で取るべき次の行動
今回の Azure SDK documentation update は、Storage Mover をコードで管理しているチームにとって、Connection、Private Link、Job Definition、スケジュール、データ整合性検証の設計を見直す良いタイミングです。
まずは @azure/arm-storagemover の利用箇所と API バージョン固定箇所を洗い出してください。次に、2025-12-01 の新しいモデルを使う必要があるかを判断し、開発環境で client.connections と Job Definition 更新処理を検証します。最後に、本番適用前に Node.js 20 以上の実行環境、Private Link 承認フロー、Connection 削除時の 409 対応をチェックリスト化しておくと、移行自動化の失敗を減らせます。
コメント