2026年5月5日にレビュー対象として更新された Azure SDK の「[AutoPR @azure-arm-security]-generated-from-SDK Generation – JS-6203157」は、単なるドキュメント差し替えではなく、JavaScript/TypeScript向け管理プレーンSDK @azure/arm-security の生成結果に関する大きな変更です。結論から言うと、@azure/arm-security を使って Microsoft.Security、Azure Security Center、Microsoft Defender for Cloud 関連の自動化コードを書いている場合は、アップグレード前に 破壊的変更、Node.js要件、削除された操作グループ、list系APIの戻り値 を必ず確認する必要があります。PR上では @azure/arm-security 6.0.0-beta.7 が対象で、旧SDK v5.0.0との比較として多数の変更が記録されています。(GitHub)
Azure SDK documentation update JS-6203157とは
今回の Azure SDK documentation update JS-6203157 は、Azure SDK for JavaScript リポジトリの PR #38277 として作成された @azure/arm-security 向けの自動生成PRです。PR名は「[AutoPR @azure-arm-security]-generated-from-SDK Generation – JS-6203157」で、sdkauto/@azure-arm-security-6203157 ブランチから main へ3コミットを取り込む構成になっています。PR本文には、生成元として specification/security/resource-manager/Microsoft.Security/Security/tspconfig.yaml と Azure REST API Specs 側の CommitSHA 9f34e6a60fe3cd7a5dc68397cdb1bb2fff8ce1b5 が記録されています。(GitHub)
重要なのは、この更新が「Azure SDKのドキュメントだけを読む人」よりも、実際に @azure/arm-security を依存関係に入れている開発者や運用自動化担当者に影響しやすい点です。PR上のBreaking Change Analysisでは、旧SDK v5.0.0から新SDK 6.0.0-beta.7への移行として、生成方式が Swagger / AutoRest v4 から TypeSpec / emitter に変わったこと、複数サービスのAPIバージョン更新、削除対象のサービス群が整理されています。(GitHub)
まず押さえるべき変更点
今回の更新は、@azure/arm-security を「コンパイルが通るか」だけで判断すると見落としが出やすい内容です。特に、型定義、操作グループ、ページング、APIバージョン、実行環境の5点を分けて確認してください。
| 確認項目 | 内容 | 実務での影響 |
|---|---|---|
| 対象パッケージ | @azure/arm-security | Azure Security Center / Microsoft.Security関連のJavaScript SDK利用コードが対象 |
| 対象バージョン | 6.0.0-beta.7 | beta版のため、本番導入前にnpm公開状況とリリースノート確認が必要 |
| 比較対象 | v5.0.0 | 既存の安定版コードとの差分確認が重要 |
| 生成方式 | AutoRest v4 から TypeSpec / emitter へ | 型名、インターフェイス、列挙型、戻り値の形が変わる可能性 |
| 実行環境 | node >=20.0.0 が指定 | Node.js 18以前のCI/CDやFunctions実行環境では確認が必要 |
package.json 上では @azure/arm-security のバージョンが 6.0.0-beta.7、Node.jsエンジン要件が >=20.0.0 と示されています。既存のMicrosoft Learn上の概要ページではバージョン5.0.0として案内されているため、記事執筆時点のPR差分と公開済みドキュメント・npmパッケージの状態を混同しないことが重要です。(GitHub)
APIバージョン更新と削除対象サービス
PRのBreaking Change Analysisでは、複数のMicrosoft.Security関連サービスでAPIバージョンが更新されています。特に、Assessment、DefenderForStorage、SecurityConnectors、SecurityConnectorsDevOps、SqlVulnerabilityAssessments はAPIバージョンが新しくなっています。一方で、AdaptiveApplicationControls、AdaptiveNetworkHardenings、Connectors、CustomAssessmentAutomations、CustomEntityStoreAssignments、SoftwareInventories、IngestionSettings はTypeSpecのスコープから外れた扱いとして記録されています。(GitHub)
| 区分 | 主な対象 | 確認すべきポイント |
|---|---|---|
| APIバージョン更新 | Assessment、DefenderForStorage、SecurityConnectors、SecurityConnectorsDevOps、SqlVulnerabilityAssessments | 引数、戻り値、モデル構造、プレビューAPIの扱い |
| 操作グループ削除 | AdaptiveApplicationControls、AdaptiveNetworkHardenings、Connectors、CustomAssessmentAutomations、CustomEntityStoreAssignments、SoftwareInventories、IngestionSettings | 既存コードで該当APIを呼んでいないか |
| 型・インターフェイス変更 | 多数のType Alias、List wrapper、Union型、Known enum | TypeScriptの型エラー、import名、switch文の分岐 |
| ページング変更 | list 系APIの一部 | 配列前提の処理から for await 前提の処理へ見直し |
この変更は、Azureポータル上の設定画面を使うだけの利用者には直接影響しにくい一方、SDKでセキュリティ評価、価格設定、セキュリティコネクタ、SQL脆弱性評価、MDEオンボーディングなどを自動化しているチームには影響が出やすいです。
追加された機能と操作グループ
6.0.0-beta.7のCHANGELOGでは、多数の操作グループが追加されています。例として、APICollectionsOperations、DefenderForStorageOperations、AzureDevOpsOrgsOperations、GitHubReposOperations、GitLabProjectsOperations、GovernanceRulesOperations、HealthReportsOperations、SecurityStandardsOperations、SensitivitySettingsOperations、SqlVulnerabilityAssessmentSettingsOperations などが挙げられています。(GitHub)
これらは、Microsoft Defender for Cloudの範囲がクラウドセキュリティ、DevOpsセキュリティ、ストレージ保護、ガバナンス、脆弱性評価などに広がっていることを反映した変更と考えられます。ただし、新しい操作グループが追加されたからといって、既存環境で即座に利用できるとは限りません。Azureサブスクリプション側の機能有効化、リージョン、プレビュー機能、権限、対象リソースの状態によって利用可否が変わる可能性があります。
破壊的変更で特に注意すべき箇所
CHANGELOGでは、SecurityContacts.update の削除、Alerts、Assessments、Automations、MdeOnboardings、Pricings、SecurityConnectors、ServerVulnerabilityAssessment、SqlVulnerabilityAssessment... 系、SubAssessments などの操作で新しいシグネチャが記録されています。(GitHub)
SecurityContacts.updateの削除
SecurityContacts.update が削除されています。セキュリティ連絡先をSDK経由で更新している運用スクリプトがある場合、まず該当メソッドを呼んでいる箇所を洗い出してください。削除されたメソッドを安易に create や createOrUpdate 相当の処理で置き換えるのではなく、新しいAPIリファレンスで更新可能な操作が残っているか、PUT相当の再作成なのか、Azure側の仕様変更なのかを確認する必要があります。(GitHub)
SqlVulnerabilityAssessment系の引数変更
PRの分析では、SqlVulnerabilityAssessments のAPIバージョンが 2023-02-01-preview から 2026-04-01-preview に上がり、workspaceId の削除、引数順の変更、モデル再構成が指摘されています。影響対象には SqlVulnerabilityAssessmentBaselineRules.add、createOrUpdate、delete、get、list、SqlVulnerabilityAssessmentScanResults、SqlVulnerabilityAssessmentScans などが含まれます。(GitHub)
実務では、SQL脆弱性評価のベースラインやスキャン結果を自動取得しているコードでエラーが出やすくなります。特に、次のようなコードは確認してください。
grep -R "SqlVulnerabilityAssessment" ./src ./scripts
grep -R "workspaceId" ./src ./scriptsworkspaceId を引数やオプションに渡している場合、新しいSDKの型定義に合わせて呼び出し方法を修正する必要があります。
list系APIのページング変更
PRの分析では、MdeOnboardings.list、Pricings.list、ServerVulnerabilityAssessment.listByExtendedResource などで、非ページングの戻り値から PagedAsyncIterableIterator<T> を使う形への変更が示されています。(GitHub)
従来コードが「戻り値に value 配列がある」と決め打ちしている場合、次のような for await 形式に置き換える必要が出る可能性があります。
const results = client.pricings.list();
for await (const pricing of results) {
console.log(pricing.name);
}この修正で失敗しやすいのは、ページング処理をユーティリティ関数に閉じ込めているケースです。SDKの戻り値が変わると、呼び出し元だけでなく、共通関数やテストデータの形も同時に直す必要があります。
Type AliasからInterfaceへの変換
PRのBreaking Change Analysisでは、AutoRest v4時代の export type X = Base & {...} のような交差型エイリアスが、TypeSpec emitterでは export interface X extends Base {...} に変わることが説明されています。これは多くの場合、モデルの実体が大きく変わったというより、生成方式の違いとして表面化する変更です。(GitHub)
ただし、影響がないと決めつけるのは危険です。たとえば、次のようなコードはビルド時に確認が必要です。
import type { Pricing, SecurityAssessment, SecurityConnector } from "@azure/arm-security";同名のinterfaceとして残る場合は大きな修正が不要なこともありますが、Union型、Known enum、削除された型エイリアスに依存している場合は修正が必要です。特に、列挙値を switch で網羅しているコードや、型名を再エクスポートしている社内ライブラリでは影響が広がりやすくなります。
EnumとUnion型の変更
CHANGELOGでは、KnownAuthenticationType から AwsAssumeRole、AwsCreds、GcpCredentials がなくなったこと、KnownOfferingType から InformationProtectionAws がなくなったことなども記録されています。また、AdditionalDataUnion、AutomationActionUnion、CloudOfferingUnion、ResourceDetailsUnion などのUnion型変更も示されています。(GitHub)
この種の変更は、実行時エラーよりもTypeScriptのコンパイルエラーとして先に見つかることが多いです。逆に言えば、skipLibCheck や any を多用しているプロジェクトでは、問題の検出が遅れます。移行確認時は一時的に型チェックを厳しめにし、SDKまわりの型エラーを見逃さないようにしてください。
誰が対応すべきか
今回の Azure SDK documentation update で優先的に確認すべきなのは、次のようなチームです。
| 対象者 | 対応優先度 | 理由 |
|---|---|---|
@azure/arm-security を直接importしている開発者 | 高 | メソッド名、型、戻り値の変更を受ける可能性が高い |
| Defender for Cloud / Security Center設定を自動化している運用担当 | 高 | セキュリティ連絡先、価格設定、評価、コネクタ周辺の影響があり得る |
| SQL脆弱性評価をSDKで扱うチーム | 高 | SqlVulnerabilityAssessment... 系のシグネチャ変更が多い |
| Azure SDKのバージョンを自動追従しているCI/CD管理者 | 中 | betaや生成PRを不用意に取り込むとビルドが壊れる可能性 |
@azure/arm-security を使っていない一般的なAzure利用者 | 低 | 直接の影響は限定的 |
Microsoft Learnの現行概要ページでは npm install @azure/arm-security による導入と SecurityCenter クライアントの作成例が示されていますが、ページ上のバージョン表記は5.0.0です。PR上の6.0.0-beta.7情報と現行ドキュメントが一致していない場合は、PR、npm、Learn、GitHubのCHANGELOGを分けて確認してください。(Microsoft Learn)
移行前に確認する手順
本番環境で使っているプロジェクトでは、いきなりSDKを上げるのではなく、次の順番で確認すると安全です。
| 手順 | 実施内容 | 失敗しやすいポイント |
|---|---|---|
| 依存関係の確認 | npm ls @azure/arm-security で利用有無を確認 | 間接依存ではなく、社内共通ライブラリ経由で使っている場合がある |
| バージョン固定 | package.json と lockfile を確認 | ^ や latest 相当で意図せず更新される |
| 実行環境確認 | Node.js 20以上か確認 | CIだけ古いNode.jsを使っていることがある |
| 影響APIのgrep | SecurityContacts、Pricings、SqlVulnerabilityAssessment などを検索 | スクリプト、Functions、バッチ処理が見落とされる |
| TypeScriptビルド | 型エラーを確認 | skipLibCheck や any で問題が隠れる |
| 結合テスト | 実サブスクリプションまたは検証環境で実行 | Azure側の権限不足とSDK変更を混同しやすい |
確認用コマンドの例です。
npm ls @azure/arm-security
node -v
grep -R "@azure/arm-security" ./src ./scripts
grep -R "SecurityContacts\|Pricings\|SqlVulnerabilityAssessment\|SecurityConnectors" ./src ./scriptsbeta版を検証する場合は、npm上で該当バージョンが公開されているかを確認してからインストールしてください。
npm view @azure/arm-security versions --json
npm view @azure/arm-security versionPRやGitHub上のブランチに存在するバージョンと、npmで実際に取得できるバージョンは同じとは限りません。特に、今回のPRは5月5日にready for reviewになり、その後にCI失敗やmerge conflictへの対応コメントも残っています。レビュー・マージ・npm公開の状態を確認せずに本番更新するのは避けるべきです。(GitHub)
設定・構成面で確認すべきポイント
今回のPRには、SDK生成元として tspconfig.yaml と Azure REST API Specs 側のCommitSHAが明記されています。これは、問題が起きたときに「どのAPI仕様から生成されたSDKなのか」を追跡するために重要です。(GitHub)
実務では、次の情報をリリースメモや社内チケットに残しておくと、後から調査しやすくなります。
| 記録する項目 | 記録例 | 目的 |
|---|---|---|
| PR番号 | Azure/azure-sdk-for-js #38277 | 変更元の追跡 |
| 対象パッケージ | @azure/arm-security | 影響範囲の特定 |
| 対象バージョン | 6.0.0-beta.7 | 検証対象の明確化 |
| Spec設定 | specification/security/resource-manager/Microsoft.Security/Security/tspconfig.yaml | 生成元の確認 |
| SpecRepo CommitSHA | 9f34e6a60fe3cd7a5dc68397cdb1bb2fff8ce1b5 | API仕様差分の追跡 |
| Node.js要件 | >=20.0.0 | CI/CD・実行基盤の確認 |
| 影響API | SecurityContacts、SqlVulnerabilityAssessment、Pricings など | テスト範囲の決定 |
特に、Azure Functions、GitHub Actions、Azure DevOps Pipelines、社内バッチサーバーでNode.jsのバージョンが異なる場合、開発端末では動くのにCIで落ちることがあります。SDKのAPI差分だけでなく、実行環境の差分も同時に確認してください。
既存コードで見直すべき具体例
価格設定を取得する処理
Pricings.list は変更対象として記録されています。従来コードが戻り値の配列構造を前提にしている場合、ページング対応が必要になる可能性があります。(GitHub)
見直し前の典型例です。
const result = await client.pricings.list();
for (const item of result.value) {
console.log(item.name);
}見直し後は、新しいSDKの戻り値に合わせて次のような形を検討します。
for await (const item of client.pricings.list()) {
console.log(item.name);
}実際のメソッド名や戻り値は利用中のSDKバージョンで確認してください。ここで大切なのは、list の戻り値を配列として固定的に扱わないことです。
セキュリティ連絡先を更新する処理
SecurityContacts.update が削除されているため、既存コードに次のような処理がある場合は修正対象です。(GitHub)
await client.securityContacts.update(/* ... */);代替手段は、最新のAPIリファレンスとAzure REST API側の仕様で確認してください。連絡先設定は運用通知に直結するため、移行時は「コードが成功したか」だけでなく、実際に通知先やロール設定が期待どおり残っているかをAzureポータルやAPIで確認する必要があります。
SQL脆弱性評価の処理
SQL脆弱性評価では、ベースラインルール、スキャン、スキャン結果の取得に関する複数操作で新しいシグネチャが記録されています。PR分析では workspaceId の削除も指摘されているため、古い引数順やオプション指定を使っているコードは優先的に見直してください。(GitHub)
grep -R "workspaceId" ./src ./scripts
grep -R "SqlVulnerabilityAssessmentBaselineRules" ./src ./scripts
grep -R "SqlVulnerabilityAssessmentScans" ./src ./scriptsこの領域はプレビューAPIを含みやすく、Azure側の仕様変更も起きやすいです。SDKの型エラーを直すだけでなく、検証用SQLリソースで実際のスキャン開始、結果取得、ベースライン取得まで動作確認するのが安全です。
今回の更新を本番に取り込む判断基準
今回の更新は、次の条件を満たしてから本番適用を検討するのが現実的です。
| 判断基準 | 本番適用しやすい状態 | 保留した方がよい状態 |
|---|---|---|
| npm公開状況 | 対象バージョンがnpmで確認できる | GitHub上のPR情報しか確認できない |
| PR状態 | マージ済みでリリースノートが整っている | レビュー待ち、CI失敗、コンフリクト対応中 |
| Node.js | 本番・CIともNode.js 20以上 | 本番やCIがNode.js 18以前 |
| 影響API | 対象APIを使っていない、または修正済み | SecurityContacts や SqlVulnerabilityAssessment を多用している |
| テスト | 実サブスクリプションで結合テスト済み | TypeScriptビルドのみで確認している |
PR上では5月5日にready for reviewとなり、同日にレビュー依頼が出ています。その後、PRが大きすぎてCopilot reviewが実行できない旨や、CI失敗・breaking changesへの言及、pnpm-lock.yaml と sdk/security/arm-security/package.json のコンフリクト対応も記録されています。(GitHub)
つまり、2026年5月5日の情報として重要なのは、「すぐ更新すべき」というより、「更新候補の差分が見える状態になったので、対象プロジェクトは事前調査を始めるべき」という点です。
チームで使える確認チェックリスト
移行担当者は、以下を順番に確認してください。
[ ] package.json / lockfile に @azure/arm-security が含まれている
[ ] npmで対象バージョンの公開状況を確認した
[ ] Node.js 20以上でCIと本番が動くことを確認した
[ ] SecurityContacts.update を使っていないか確認した
[ ] SqlVulnerabilityAssessment 系APIを使っていないか確認した
[ ] Pricings.list などlist系APIの戻り値を配列前提にしていないか確認した
[ ] Type Alias / Enum / Union型の変更でTypeScriptエラーが出ないか確認した
[ ] Azure上の権限、ロール、サブスクリプション設定を検証環境で確認した
[ ] 変更前後で通知先、価格設定、評価結果、コネクタ設定が意図どおりか確認したこのチェックリストを使うと、SDK更新による「ビルドは通ったが運用スクリプトが一部だけ失敗する」という典型的な事故を減らせます。
よくある疑問
この更新はセキュリティ修正なのか
PR名に security が含まれていますが、これは @azure/arm-security、つまり Microsoft.Security / Azure Security Center 関連のSDKパッケージ名に由来します。少なくともPR上の内容は、脆弱性修正の告知ではなく、SDK生成・API仕様・型定義・ドキュメントの更新として扱うべきです。
@azure/arm-security を使っていなければ対応不要か
直接使っていなければ、影響は限定的です。ただし、社内共通ライブラリ、IaC補助スクリプト、監査スクリプト、セキュリティ設定の自動化ツールが間接的に使っている場合があります。npm ls @azure/arm-security とリポジトリ検索で確認してください。
beta版へすぐ移行すべきか
本番環境では慎重に判断してください。PRとCHANGELOG上では6.0.0-beta.7が対象ですが、beta版はAPIや型がさらに変わる可能性があります。新機能を検証したい場合は検証環境で導入し、本番は安定版をピン留めしておく方が安全です。
Microsoft LearnのドキュメントとPRの内容が違う場合はどちらを見るべきか
目的によって見る場所を分けます。現在利用中の安定版SDKの使い方を確認するならMicrosoft Learnやnpmの公開情報を見ます。将来の変更、破壊的変更、移行準備を確認するならGitHub PR、CHANGELOG、SDKリポジトリの差分を見ます。Microsoft Learnの概要ページではバージョン5.0.0が表示されているため、PR上の6.0.0-beta.7情報とは段階が異なる可能性があります。(Microsoft Learn)
まとめ：まず依存確認、次に破壊的変更の洗い出し
今回の Azure SDK documentation update JS-6203157 は、@azure/arm-security を使うJavaScript/TypeScriptプロジェクトにとって、移行前調査が必要な更新です。特に、SecurityContacts.update の削除、SqlVulnerabilityAssessment 系のシグネチャ変更、list 系APIのページング変更、TypeSpec / emitter移行による型定義の変化、Node.js 20以上の要件は優先して確認してください。
次に取るべき行動は明確です。まず npm ls @azure/arm-security で利用有無を確認し、該当する場合は影響APIをgrepします。そのうえで、npm公開状況、PRのマージ状況、Node.js実行環境、TypeScriptビルド、検証環境での結合テストを順番に進めてください。SDK更新は「バージョンを上げる作業」ではなく、セキュリティ運用の自動化が期待どおり動き続けるかを確認する作業です。
コメント