Azure REST APIのAKS 2026-03更新まとめ：stable/2026-03-01とpreview/2026-03-02-previewの影響

Azure REST APIでAKSを管理している場合、今回まず確認すべきなのは「新しいAPIバージョンを使うべきか」ではなく、「自社のテンプレート、SDK、自作RESTクライアントが新しいスキーマ差分に耐えられるか」です。2026年5月5日時点で注目されているこの更新は、Microsoft.ContainerService/aks に stable/2026-03-01 と preview/2026-03-02-preview を追加するレビューリクエストです。対象はAKSのARM、つまりControl Plane APIであり、Kubernetes APIそのものの変更ではありません。(GitHub)

AKSクラスタやノードプールをAzure Portalだけで操作している読者への影響は限定的です。一方、ARMテンプレート、Bicep、TerraformなどのIaC、Azure SDK、自作の管理ツール、CI/CDからREST APIを直接呼び出しているチームは、api-version、スキーマ検証、列挙値、読み取り専用フィールドの扱いを確認しておくべきです。

Azure REST APIのAKS更新で何が変わるのか

今回のPRは、Azure REST API仕様リポジトリにAKS向けの新しいAPIバージョンを追加するものです。PR上では、stable/2026-03-01 と preview/2026-03-02-preview の追加が示され、SwaggerやGo、Python、Java、JavaScript向けの生成APIレビューも用意されています。記事執筆時点ではレビュー対象のPRとして扱われており、実運用で使う前にはMicrosoft LearnのREST APIリファレンス、SDKのリリース状況、自社環境での検証結果を合わせて確認する必要があります。(GitHub)

確認項目	内容	実務で見るべきポイント
対象サービス	Azure REST APIの `Microsoft.ContainerService/aks`	AKSクラスタ、ノードプール、関連プロファイルの管理API
追加バージョン	`stable/2026-03-01`、`preview/2026-03-02-preview`	本番利用はstable、検証や新機能確認はpreviewが基本
APIの種類	ARM、Control Plane API	KubernetesのPodやDeploymentを操作するAPIではない
主な影響先	IaC、SDK、自作RESTクライアント、CI/CD	`api-version` 固定、スキーマ検証、列挙値処理を確認
注意点	PR段階の情報を含む	SDKやドキュメント公開タイミングとずれる可能性がある

stable/2026-03-01で確認したい主な変更点

stable/2026-03-01 は、previewではなく安定版のAPIバージョンとして追加される想定です。すべての環境で即座に切り替える必要はありませんが、今後の標準バージョン候補として、テンプレートや管理ツールの対応状況を確認しておく価値があります。

特に確認したいのは、artifactStreamingProfile のstable側への追加です。仕様上、Artifact Streamingはコンテナイメージのオンデマンド読み込みによってコールドスタートを短縮するための設定として説明されており、AKS側だけでなくAzure Container Registry側のイメージでもArtifact Streamingを有効にする必要があります。コンテナ起動時間を改善したい環境では魅力的ですが、CIでのイメージ作成、ACR運用、ノードプール設定まで一体で確認する必要があります。(GitHub)

また、OSSKU に AzureContainerLinux が追加されています。仕様では、Azure Linuxをベースにしたコンテナ最適化OSとして説明されています。既存のテンプレートやポリシーでOS SKUを許可リスト方式にしている場合、新しい値を未知の値として拒否しないか確認が必要です。(GitHub)

もう一つ見落としやすいのが、PR上でBreaking Changeとして検出されている nodeImageVersion と zones の扱いです。PRの説明では、これらのフィールドを読み取り専用ではなく変更可能な扱いに寄せる差分として説明されています。自作クライアントや型定義で「このフィールドはread-only」と決め打ちしている場合、更新処理や差分検出のロジックを見直す必要があります。(GitHub)

preview/2026-03-02-previewで追加される機能は検証向けに見る

preview/2026-03-02-preview には、ノードプール、ネットワーク、セキュリティ、アップグレード制御に関する多くの差分が含まれます。preview APIは新機能の検証に役立ちますが、AKSのpreview APIは一定期間で終了する前提があるため、本番の標準APIとして安易に固定するのは避けるべきです。Microsoftは、AKSのpreview APIについてリリース日からおおむね1年程度のライフスパンを示しています。(Microsoft Learn)

変更領域	代表的な追加・変更	確認ポイント
ノードプールネットワーク	`secondaryNetworkInterfaces` によるマルチNIC関連設定	VM SKUごとのNIC上限、サブネット設計、作成後に変更できない項目を確認
ノード公開IP	`nodePublicIPPrefixIDs`	最大2件、IPv4/IPv6の組み合わせ、`enableNodePublicIP` との整合性を確認
Kubelet設定	`kubeReserved`、`hardEvictionThreshold`	CPU・メモリ予約、Pod退避条件、Linuxノードプールでの挙動を検証
ノード中断制御	`nodeDisruptionProfile`	再イメージ化、再デプロイ、メンテナンスウィンドウとの関係を確認
セキュリティ	クラスタレベルの `enableFIPS`、Entra ID SSH、IMDSアクセス制御関連	組織ポリシー、アドオン、全ノードプールの整合性を確認
ネットワーク	`managedNATGatewayV2`、Cilium関連、mTLS関連	既存ネットワーク設計、監視、通信制御との互換性を確認
GPU・イメージ	NVIDIA GPU管理、Prepared Image関連	GPUノードプールや高速起動要件がある環境で検証
運用API	ロードバランサー再バランス、操作ステータス、削除時のPDB無視パラメータ	自動化ツールでのエラーハンドリングと監査ログを確認

preview側では、secondaryNetworkInterfaces や nodePublicIPPrefixIDs のように、作成後の変更が難しい、または作成後に変更できない設定が含まれます。仕様では、セカンダリNICはエージェントプール作成時に指定し、作成後は変更不可と説明されています。nodePublicIPPrefixIDs も、既存の nodePublicIPPrefixID とは同時に使えず、プレフィックス変更時にはノードプールの再作成が必要になる旨が示されています。(GitHub)

クラスタレベルのFIPS設定も注意が必要です。enableFIPS は、AKS管理コンポーネント、アドオン、ノードOS、すべてのノードプールでFIPS対応を求める設定として説明されています。単にクラスタプロパティを有効化するだけでなく、既存ノードプール、OS SKU、アドオン、運用ポリシーまで含めて確認する必要があります。(GitHub)

誰が対応すべきか

今回のAzure REST API更新で対応が必要になるのは、AKSを「画面で見るだけ」の利用者ではなく、API仕様に依存してAKSを管理しているチームです。特に、次のような環境では影響調査を早めに行うべきです。

対象者・システム	影響が出やすい理由	まず確認すること
ARMテンプレート・Bicep利用者	`api-version` をテンプレート内で固定している	`Microsoft.ContainerService/managedClusters` と `agentPools` のAPIバージョン
Terraform・PulumiなどのIaC利用者	Provider側のスキーマとAzure REST API仕様に差が出ることがある	Providerの対応状況、plan差分、未知フィールドの扱い
自作RESTクライアント	JSONスキーマや列挙値を独自に定義している場合がある	unknown enum、read-only扱い、PUT/PATCH時の欠落
Azure SDK利用者	SDK生成タイミングがREST API仕様更新より遅れることがある	利用中SDKのバージョン、生成モデルの差分
SRE・基盤運用チーム	ノードプール更新、FIPS、マルチNIC、PDB関連の運用影響がある	非本番クラスタでの作成・更新・削除テスト
セキュリティ・ネットワーク担当	FIPS、IMDS、mTLS、Cilium、公開IPプレフィックスが関係する	組織ポリシー、監査、通信制御の整合性

特に注意したいのは、自作ツールで「Azure APIのレスポンスは常に既知の列挙値だけを返す」と仮定しているケースです。OSSKU、AgentPoolMode、ネットワーク関連のenumに新しい値が加わると、パースエラーやデプロイ拒否につながることがあります。未知の値をエラーにするのではなく、ログに記録したうえで処理を継続できる設計にしておくと、将来のAPI追加にも強くなります。

すぐにapi-versionを上げるべきか

結論として、全環境で急いで api-version を上げる必要はありません。APIバージョンの変更は、新機能を使いたい場合や、将来の標準化に備えて検証する場合に計画的に行うべきです。

判断	向いているケース	注意点
既存APIバージョンを維持	現在のAKS管理が安定しており、新機能を使う予定がない	ただし将来の移行に備えてスキーマ差分は把握しておく
`stable/2026-03-01` を検証	Artifact StreamingやAzureContainerLinuxなど、stable側の差分を使いたい	本番反映前にテンプレート差分、SDK対応、CI検証を行う
`preview/2026-03-02-preview` を検証	マルチNIC、FIPS、nodeDisruptionProfileなどpreview機能を試したい	非本番環境で検証し、preview APIを本番標準にしない
SDK更新を待つ	SDK中心でAKSを管理している	REST API仕様とSDKの反映タイミングに差が出る可能性がある

本番環境では、api-version を上げること自体を目的にしない方が安全です。たとえば、マルチNICやFIPS設定を使わないのにpreview APIへ切り替えると、将来のpreview終了やSDK差分に追随する運用コストだけが増える可能性があります。

実務で確認すべき変更点チェックリスト

API仕様の更新を見たときは、新機能の名前だけで判断せず、自社の管理方法に引き寄せて確認することが重要です。

`api-version` の固定箇所を洗い出す

最初に行うべき作業は、リポジトリ内でAKS関連のAPIバージョンを検索することです。ARMテンプレートやBicepだけでなく、シェルスクリプト、PowerShell、Azure CLIの az rest、GitHub Actions、社内ツールの設定ファイルにも埋め込まれていることがあります。

grep -R "Microsoft.ContainerService" .
grep -R "managedClusters" .
grep -R "api-version=2026-" .

Azureリソース自体に「このクラスタはどの api-version で作られた」という運用上の印が残るわけではありません。確認すべきなのは、リソースを作成・更新しているテンプレート、SDK、REST呼び出し側の指定です。

PUT更新で未知フィールドを消さない

自作RESTクライアントで特に危険なのが、GETした結果を古いモデルに読み込み、必要な項目だけ変更してPUTする実装です。古いモデルが新しいフィールドを保持できない場合、PUT時に未知フィールドを落としてしまう可能性があります。

AKSのAgent Pool APIには作成・更新操作があり、REST APIではAPIバージョンを指定して操作します。古い型定義で新しいAPIレスポンスを扱う場合は、未知フィールドを破棄しない設計、またはPATCH相当の更新方針を検討してください。(Microsoft Learn)

read-only前提のフィールドを見直す

nodeImageVersion と zones は、今回のPRでBreaking Change関連の確認対象として扱われています。自社ツールでこれらを「Azureが返すだけの読み取り専用値」として固定している場合、次のような問題が起きる可能性があります。

差分検出ツールが不要な変更として検出する
JSON生成時にフィールドを除外してしまう
SDK更新後に型定義の扱いが変わり、コンパイルやテストが失敗する
ポリシーで「指定してはいけないフィールド」として拒否してしまう

この種の変更は、見た目の機能追加よりも気づきにくいものです。新しいAPIバージョンを使わない場合でも、将来のSDK更新で型定義が変わる可能性があるため、CIのスキーマ検証に含めておくと安全です。

変更できない設定はノードプール再作成を前提にする

preview側の secondaryNetworkInterfaces や nodePublicIPPrefixIDs は、作成後の変更制約が強い設定です。たとえばマルチNICを後から追加したい場合、既存ノードプールに単純に追記して更新できるとは考えない方がよいでしょう。仕様上も、セカンダリNICは作成後に変更できない設定として説明されています。(GitHub)

このような設定は、既存ノードプールを変更するのではなく、新しいノードプールを作成し、ワークロードを移してから古いノードプールを削除する流れで計画するのが現実的です。

FIPSはクラスタ単体ではなく全体設計で見る

FIPS対応は、セキュリティ要件がある組織にとって重要な変更です。ただし、クラスタレベルの enableFIPS を有効にすれば完了、という単純な話ではありません。仕様では、AKS管理コンポーネント、アドオン、ノードOS、すべてのノードプールでFIPS対応が求められる旨が示されています。(GitHub)

そのため、FIPSを検討する場合は次の観点をセットで確認してください。

確認対象	見るべきポイント
既存ノードプール	すべてFIPS対応にできるか
OS SKU	利用中OSとFIPS要件が一致するか
アドオン	監視、ネットワーク、セキュリティ関連のアドオンが対応しているか
CI/CD	非対応ノードプールを誤って追加しない制御があるか
運用手順	障害時やスケール時にもFIPS要件を維持できるか

移行・検証のおすすめ手順

APIバージョンの移行は、いきなり本番テンプレートを書き換えるのではなく、差分が見える状態で段階的に進めるべきです。

手順	作業内容	成功条件
現状把握	AKS関連の `api-version` 固定箇所を洗い出す	リポジトリ、CI、スクリプト、自作ツールの参照箇所が一覧化されている
差分確認	stableとpreviewで追加されたプロパティ、enum、制約を確認する	利用予定の機能と影響を受ける既存処理が分かっている
非本番検証	テストクラスタまたは検証用ノードプールで作成・更新・削除を試す	plan差分、RESTレスポンス、エラーが記録されている
SDK確認	利用中SDKの生成モデルや対応バージョンを確認する	コンパイル、単体テスト、型の差分確認が完了している
運用影響確認	ノード再作成、メンテナンスウィンドウ、Pod退避を確認する	SREとアプリ担当が影響範囲を把握している
本番適用	必要な機能だけを対象に段階的に反映する	ロールバック手順と監視項目が用意されている

検証時は、作成だけでなく更新と削除も必ず試してください。AKSのAPI変更は、クラスタ作成時には問題が出なくても、ノードプール更新、アップグレード、削除、再作成のタイミングで影響が出ることがあります。今回のpreviewでは、削除時にPod Disruption Budgetを無視するパラメータや、操作ステータス取得に関する差分も含まれているため、運用自動化ツールではエラーハンドリングも確認しておくべきです。(GitHub)

よくある失敗と回避策

preview APIを本番の標準にしてしまう

新機能を試すためにpreview APIへ切り替え、そのまま本番テンプレートの標準にしてしまうのは避けたいパターンです。preview APIは検証用途として有用ですが、ライフサイクルや仕様変更のリスクがあります。preview限定の機能が本当に必要な環境だけに絞り、利用理由を設計書やリポジトリに残しておくと、後から見直しやすくなります。(Microsoft Learn)

新しいenumを拒否してデプロイが止まる

OS SKUやネットワーク関連のenumが増えると、古いバリデーションで「許可されていない値」と判定されることがあります。特にセキュリティポリシーや社内のテンプレート検査で許可リストを使っている場合は、新しい値をどう扱うかを決めておきましょう。

すぐに許可しない場合でも、「未知の値を検出したら警告にする」「本番では拒否するが検証環境では許可する」など、環境ごとに扱いを分けると運用しやすくなります。

ノードプールの不変項目を通常更新で変えようとする

マルチNICや公開IPプレフィックスのような設定は、あとから差し替えるより、新しいノードプールを作って移行する前提で考える方が安全です。IaCでは、変更により再作成が必要な項目を事前に把握しないと、意図しないノードプール置き換えが発生する可能性があります。

本番反映前には、planやwhat-ifの結果を確認するだけでなく、ワークロード退避、Pod Disruption Budget、メンテナンスウィンドウ、オートスケールの挙動まで確認してください。

Artifact StreamingをAKS側だけで有効にする

Artifact Streamingは、AKS側のプロファイル設定だけで完結するものではありません。仕様上、コンテナイメージ側でもAzure Container RegistryでArtifact Streamingを有効にする必要があります。(GitHub)

そのため、AKS担当だけでなく、イメージをビルド・配布するCI/CD担当とも連携する必要があります。起動時間改善を目的に導入する場合は、次のように検証すると効果が分かりやすくなります。

検証項目	見るべき指標
Artifact Streamingなし	Pod起動までの時間、イメージpull時間
Artifact Streamingあり	初回起動、再起動、スケールアウト時の差分
イメージサイズ別	小さいイメージと大きいイメージで効果が違うか
ノードプール別	OS SKUやノードサイズで差が出るか

まず取るべきアクション

今回のAzure REST API更新で最初にやるべきことは、stable/2026-03-01 や preview/2026-03-02-preview へすぐ移行することではありません。まず、自社がAKSをどの経路で管理しているかを確認し、API仕様の変化に弱い箇所を洗い出すことです。

実務では、次の順番で進めるのが現実的です。

AKS関連の api-version 固定箇所を検索する
自作クライアントやCIで未知のフィールド、未知のenumを拒否していないか確認する
nodeImageVersion、zones、OS SKU、ノードプールネットワーク設定の扱いを確認する
stableで使いたい機能がある場合だけ、2026-03-01 の検証ブランチを作る
preview機能は非本番環境で検証し、本番標準にはしない
ノードプール再作成が必要になりそうな設定は、ワークロード移行計画とセットで検討する

AKSのREST APIバージョン更新は、見た目には単なる仕様ファイルの追加に見えます。しかし、IaC、SDK、自動化ツール、セキュリティポリシーに深く関わる環境では、APIの小さな差分がデプロイ失敗や意図しない再作成につながることがあります。

今回の更新は、AKS運用を見直すよいタイミングです。新機能を急いで使うよりも、まずは現在の管理方法を棚卸しし、stableで取り込むもの、previewで検証するもの、当面見送るものを分けて判断してください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。