Azure REST APIの2026年5月5日付け更新では、AKS AI Manager向けに AIModel、ModelDeployment、ModelSource に関するAPI追加が提案されています。結論から言うと、既存のAKS運用者全員がすぐ変更する内容ではなく、AKS上でLLMなどのAIモデルを管理・配置する基盤をREST APIやSDKから自動化したいチームが確認すべき更新です。ただし、主なソースであるGitHub PR #42883は記事執筆時点でDraft扱いで、ARMレビューやTypeSpec Validationの指摘も残っているため、実装前には最新のPR状態と公開済みドキュメントを必ず確認してください。(GitHub)
Azure REST APIに追加されるAKS AI Manager関連APIの位置づけ
今回の更新は、Azure REST APIのうち Microsoft.ContainerService 名前空間に属するAKS AI Manager向けAPI仕様の追加です。PRでは、APIバージョンとして 2026-05-02-preview が追加され、ContainerServiceAIManagerClient というサービス名のTypeSpec定義に AIModel、ModelSource、ModelDeployment が組み込まれています。(GitHub)
AKS AI Managerは、AKS上でAIモデルの管理やデプロイを扱うための管理プレーンAPIとして整理されています。従来のAKSクラスター管理APIそのものではなく、AIモデルの選択、外部モデルソースの登録、名前空間単位のモデルデプロイ、推論エンドポイント情報の取得といった運用をREST APIで扱いやすくする方向の更新と見るのが自然です。
特に重要なのは、今回のAPIが単に「モデルを置く」だけではなく、次のような実務上の論点をAPI仕様に含めている点です。
| 確認項目 | 実務上の意味 |
|---|---|
AIModel | 利用可能なAIモデルをAzure Resource Managerリソースとして参照する |
ModelSource | Hugging Faceなど外部モデルレジストリと認証情報を管理する |
ModelDeployment | AI Managerのnamespace配下にモデルをデプロイし、VM SKU、レプリカ、オートスケールを指定する |
calculateCost | GPU SKU別の概算時間単価やデプロイ可否を確認する |
listAccessInfo | OpenAI互換のベースURLとAPIキーを取得する |
このため、影響を受けやすいのは「Azureポータルで手動操作している担当者」よりも、Terraform、Bicep、Azure CLI、SDK、REST API、社内CI/CDなどでAIモデル基盤をコード化しているチームです。
変更点の概要
PR #42883では、specification/containerservice/resource-manager/Microsoft.ContainerService/aimanager 配下に複数のTypeSpec、OpenAPI JSON、サンプルJSONが追加されています。ファイル一覧には aimodel.tsp、modeldeployment.tsp、modelsource.tsp、aimanagers.json、各種examplesが含まれています。(GitHub)
今回の変更を運用目線で整理すると、確認すべきポイントは次の4つです。
| 変更領域 | 追加・変更内容 | 確認すべき人 |
|---|---|---|
| APIバージョン | 2026-05-02-preview が追加 | REST APIやSDKのバージョンを固定している開発者 |
| モデル管理 | AIModel リソースと calculateCost アクション | GPUコストやモデル選定を自動化したい基盤チーム |
| モデルソース管理 | ModelSource リソース、Hugging Face、認証情報 | 外部モデルレジストリを使うMLOps担当者 |
| デプロイ管理 | ModelDeployment リソース、レプリカ、VM SKU、autoscaling | AKS上で推論基盤を運用するSRE、Platform Engineering担当者 |
| アクセス情報 | namespace単位の listAccessInfo | 推論APIをアプリから呼び出す開発者、セキュリティ担当者 |
AIModel APIで確認すべきこと
AIModel は、Microsoft.ContainerService が提供するAIモデルを表すリソースとして定義されています。TypeSpec上では、リソースプロバイダーによって管理され、自動プロビジョニングされるモデルであり、ModelDeployment から参照できるものとして説明されています。(GitHub)
AIModelは「作成するモデル」ではなく「参照するモデル」と考える
AIModel でまず押さえるべき点は、利用者が任意のモデルを自由に登録するためのリソースというより、プラットフォーム側が管理するモデルカタログ的な役割に近いことです。定義では resolvedSpec が読み取り専用で、ライセンス、gatedモデルかどうか、最大コンテキスト長などが含まれます。(GitHub)
実務では、次のような流れで使うことが想定されます。
| 利用シーン | 確認する項目 |
|---|---|
| モデル選定 | resolvedSpec.license、gated、maxContextLength |
| デプロイ前確認 | モデル名、ARMリソースID、サポートされるSKU |
| コスト見積もり | calculateCost の結果 |
| アプリ要件との照合 | コンテキスト長、ライセンス条件、アクセス制限 |
たとえば、社内チャットボット向けに長い社内文書を扱う場合、最大コンテキスト長が不足すると検索拡張生成、いわゆるRAGの設計に影響します。単に「有名なモデルだから使う」ではなく、APIで取得できるモデル仕様をデプロイ前の判定条件に入れるのが安全です。
calculateCostはGPU費用と実行可否の事前確認に使える
AIModel には calculateCost アクションが追加されています。このアクションは、指定したレプリカ数に対して、GPU SKU別の価格プラン、必要VM数、時間単価、合計時間単価、価格時点、デプロイ可能かどうかを返す仕様です。デプロイ可能でない場合の理由として、GPUクォータ不足、リージョン非対応、非効率なデプロイなどのコードが定義されています。(GitHub)
これは、AKS上でAIモデルを動かすチームにとってかなり実用的です。LLM推論基盤では、モデル選定よりもGPU SKU、クォータ、リージョン、レプリカ数の組み合わせでコストが大きく変わります。calculateCost をCI/CDや申請ワークフローに組み込めば、デプロイ後に「GPUが足りない」「想定より高い」「指定リージョンでSKUが使えない」と気づくリスクを下げられます。
calculateCostを使う判断基準
| 判断したいこと | 見るべきフィールド |
|---|---|
| その構成でデプロイできるか | feasible |
| デプロイできない理由 | infeasibleCode、infeasibleMessage |
| GPUコストの概算 | vmHourlyPrice、totalHourlyPrice、currency |
| スケール時の影響 | replicas、vmsPerReplica |
| 価格情報の鮮度 | priceAsOf |
注意点として、calculateCost はコストや実行可否の判断材料であり、実際の請求額を保証するものではありません。価格、リージョン、クォータ、SKU提供状況は変わる可能性があるため、予算管理ではAzure Cost Managementや実際の請求データと併用するべきです。
ModelSource APIで確認すべきこと
ModelSource は、AI Managerに登録する外部モデルソースを表します。TypeSpecでは、外部モデルレジストリ、たとえばHugging Faceと、そこからアーティファクトを取得するための資格情報を記述するリソースとして定義されています。(GitHub)
Hugging Faceなど外部モデルレジストリを使うチームは要確認
今回の仕様では、ModelSourceType として HuggingFace が定義されています。credentialは任意で、公開モデルのように認証が不要なケースでは省略できる一方、gatedモデルやプライベートモデルでは認証情報が必要になる可能性があります。(GitHub)
実務で重要なのは、ModelSource を「モデルの置き場所」ではなく、モデル取得元と認証の管理単位として扱うことです。
たとえば、次のような設計が考えられます。
| ケース | ModelSource設計の考え方 |
|---|---|
| 公開モデルのみ利用 | credentialなし、sourceTypeを明確化 |
| gatedモデルを利用 | アクセストークンをcredentialとして登録 |
| チームごとにモデル取得元を分ける | AI Manager配下にチーム単位のModelSourceを作成 |
| 本番・検証で認証情報を分ける | 環境ごとにModelSourceを分離 |
credentialの扱いはKey Vaultやローテーション設計とセットで考える
仕様では InlineCredential があり、value はsecretとして扱われます。とはいえ、リクエストペイロードにシークレットを含める運用では、CI/CDログ、API呼び出しログ、IaCの状態ファイル、レビュー履歴に漏れないよう注意が必要です。(GitHub)
実装時は、少なくとも次を確認してください。
| 確認項目 | 失敗しやすいポイント |
|---|---|
| CI/CDログ | RESTリクエスト本文や環境変数がログに出る |
| IaCのstate | シークレット値が状態ファイルに残る |
| 権限管理 | モデル取得用トークンに過剰な権限を付ける |
| ローテーション | トークン更新時にModelDeploymentが影響を受ける |
| 削除時 | ModelSource削除後も依存するDeploymentが残る |
特にHugging Faceのgatedモデルを使う場合、モデルの利用条件やライセンス確認も運用フローに含める必要があります。APIで登録できるからといって、商用利用や再配布が許可されているとは限りません。
ModelDeployment APIで確認すべきこと
ModelDeployment は、AI Manager namespace内で実行されるモデルデプロイを表すリソースです。modelResourceId、modelSourceResourceId、performanceMode、vmSize、replicas、autoscaling、overrides、status などが定義されています。(GitHub)
作成時に決める項目と後から変えられる項目を分けて確認する
ModelDeployment では、作成時に固定される項目と、PATCHで変更できる項目を分けて理解することが重要です。modelResourceId、modelSourceResourceId、vmSize は作成時と読み取りの対象として定義され、変更不可の扱いです。一方、performanceMode、replicas、autoscaling、overrides はPATCH対象として定義されています。(GitHub)
| 項目 | 役割 | 運用上の注意 |
|---|---|---|
modelResourceId | デプロイするAIModelのARMリソースID | 作成後変更できない前提で設計する |
modelSourceResourceId | モデル取得元のModelSource | 外部モデル取得が必要な場合に指定 |
vmSize | デプロイに使うAzure VM SKU | 作成後変更できないため、事前検証が重要 |
performanceMode | Balanced、Latency、Throughput | APIや利用者要件に合わせて選ぶ |
replicas | 希望レプリカ数 | autoscaling有効時は無視される |
autoscaling | 自動スケール設定 | min/maxとGPUクォータを合わせて確認 |
overrides | エンジンや量子化などの上書き | PATCH時はオブジェクト全体置換に注意 |
status | エンドポイントや実行状態 | 読み取り専用として監視に使う |
最も失敗しやすいのは vmSize の選定です。モデルが動くGPU SKU、リージョンでの提供状況、サブスクリプションのGPUクォータ、コスト、可用性を事前に確認せずに作成すると、デプロイのやり直しが必要になります。AIModel.calculateCost と組み合わせて、vmSize を決めてから ModelDeployment を作成する流れが現実的です。
performanceModeはアプリのSLOから選ぶ
performanceMode には Balanced、Latency、Throughput が定義されています。Balanced は遅延とスループットのバランス、Latency は低遅延、Throughput は総処理量を重視するモードです。(GitHub)
選び方は、モデルの性能だけでなく、アプリケーションのSLOから逆算します。
| アプリケーション | 推奨される考え方 |
|---|---|
| 社内チャットボット | 応答待ち時間が重要なら Latency を検討 |
| バッチ要約処理 | 同時処理量を重視するなら Throughput を検討 |
| PoCや検証環境 | まず Balanced で始め、実測後に変更 |
| API利用量が読めない本番環境 | autoscaling と組み合わせて段階的に調整 |
ただし、performanceMode は万能ではありません。GPU SKU、モデルサイズ、量子化、入力トークン長、同時接続数によって実際の性能は変わります。初期設定だけで判断せず、status.peakTokensPerMinute やアプリ側のレイテンシメトリクスも見て調整してください。
autoscaling有効時はreplicasの扱いに注意
ModelDeployment では replicas を指定できますが、autoscaling.enabled がtrueの場合、replicas は無視される仕様です。autoscaling には minReplicas と maxReplicas があり、maxReplicas を指定しない場合はサブスクリプションのGPUクォータから既定値が導かれる説明があります。(GitHub)
これは便利ですが、コスト管理の観点では注意が必要です。上限を明示しないまま本番トラフィックを受けると、想定以上にGPUリソースを消費する可能性があります。
本番環境では、次のような設定確認を推奨します。
| 確認項目 | 推奨アクション |
|---|---|
| 最小台数 | 障害時や低トラフィック時の最低性能を満たす値にする |
| 最大台数 | 月額予算とGPUクォータから逆算して決める |
| スケール条件 | 実際のトークン量、同時リクエスト数、レイテンシを監視する |
| 予算超過 | Azure予算アラートと組み合わせる |
| 検証環境 | maxReplicasを低めに固定する |
namespaceのlistAccessInfo追加で変わること
今回の更新では、AI Manager namespaceに listAccessInfo アクションが追加されています。これは、namespace単位のLLM gateway endpointと、クライアント認証に使うAPIキーを返すアクションです。レスポンスにはOpenAI互換のベースURL、primaryKey、secondaryKey、lastRotatedAtが含まれます。(GitHub)
この変更は、アプリ開発者にも影響します。推論APIを呼び出すアプリケーションは、Azure Resource Manager上のModelDeploymentを直接操作するのではなく、取得したOpenAI互換エンドポイントに対してリクエストを送る構成になる可能性があります。
APIキーはログに出さない、平文保存しない
仕様上、primaryKey と secondaryKey はsecretとして定義されています。説明でも、Authorization: Bearer <key> または api-key: <key> として使い、ログ出力や平文保存を避けるべき内容になっています。(GitHub)
実装時は、次のルールをチームで統一してください。
| 項目 | 推奨 |
|---|---|
| 保存先 | Key Vault、CI/CDのsecret store、Kubernetes Secretなど |
| ログ | HTTPヘッダー、レスポンス本文、環境変数をマスク |
| ローテーション | primary/secondaryを使って無停止切り替え |
| 監視 | lastRotatedAt を見て古いキーを検出 |
| 権限 | listAccessInfo を呼べるRBACを必要最小限にする |
特に注意したいのは、listAccessInfo の呼び出し権限です。このAPIを呼べるユーザーやサービスプリンシパルは、推論エンドポイントへのアクセス情報を取得できる可能性があります。単に「読み取り権限だから安全」と見なさず、運用上はシークレット取得権限に近い扱いにするべきです。
既存環境への影響範囲
今回のAPI追加は、既存のAKSクラスター作成、Node Pool管理、通常のPod運用に直接の破壊的変更を加えるものではありません。影響が出やすいのは、AKS AI ManagerやAIモデルデプロイを自動化するコード、SDK生成、API仕様検証、社内ドキュメントです。
| 対象 | 影響 |
|---|---|
| 通常のAKS利用者 | 直接影響は限定的 |
| REST APIを直接呼ぶ開発者 | api-version=2026-05-02-preview の利用可否を確認 |
| SDK利用者 | 生成予定のSDKパッケージや型の変更を確認 |
| IaC担当者 | 新リソース種別をIaCで扱うか検討 |
| MLOps担当者 | モデルソース、モデル選定、デプロイ、コスト見積もりの自動化に影響 |
| セキュリティ担当者 | ModelSource credential、listAccessInfo、APIキー管理に注意 |
| FinOps担当者 | GPU SKU別コスト見積もり、autoscaling上限を確認 |
PR上では、Swagger、TypeSpec、Go、Python、JavaScript、JavaのAPIレビューが作成されたことも示されています。SDKを使うチームは、REST APIだけでなく、各言語SDKにどのような型やメソッドとして反映されるかも追跡する必要があります。(GitHub)
移行・設定確認の進め方
現時点で実務チームが取るべき対応は、すぐに本番へ組み込むことではなく、既存のAI/AKS運用と照らし合わせて影響を棚卸しすることです。特にPRがDraftである点を踏まえ、検証環境での調査と設計レビューを先行させるのが安全です。
確認手順
| 手順 | やること | 判断ポイント |
|---|---|---|
| 1 | PRと公式ドキュメントの最新状態を確認 | Draftか、merge済みか、APIバージョンが変わっていないか |
| 2 | AKS AI Managerを使う予定があるか確認 | 既存AKS運用だけなら優先度は低い |
| 3 | モデル管理フローを整理 | AIModel、ModelSource、ModelDeploymentのどれを使うか |
| 4 | GPU SKUとコスト管理を確認 | calculateCostを申請・CIに組み込むか |
| 5 | シークレット管理を設計 | ModelSource credentialとlistAccessInfoをどう保護するか |
| 6 | SDK・IaCの対応を確認 | REST API直呼びか、SDK生成待ちか |
| 7 | 検証環境で作成・更新・削除を試す | immutable項目、PATCH挙動、削除時影響を確認 |
REST APIやIaCで特に見直すべき項目
既存の自動化スクリプトにAKS AI Manager関連リソースを追加する場合は、次の観点で見直してください。
| 見直し対象 | チェック内容 |
|---|---|
| API version固定 | 2026-05-02-preview を使う箇所を明示し、安定版と混在させない |
| リソースID生成 | AIModel、ModelSource、ModelDeployment の親子関係を正しく組み立てる |
| 名前規則 | modelDeploymentName や modelSourceName は小文字・数字・ハイフン中心の制約に注意 |
| PATCH処理 | overrides は全体置換のため、差分更新のつもりで一部だけ送らない |
| 非同期処理 | Create/Deleteで長時間操作になる可能性を前提にポーリングを設計 |
| eTag | If-Match、If-None-Match を使う場合は競合更新を考慮 |
| シークレット | credentialやAPIキーをログ、state、レビュー画面に残さない |
よくある誤解と注意点
すぐに本番で使える正式APIとは限らない
PR #42883はDraftであり、マージ前の次ステップとして PublishToCustomers ラベル、ARMレビュー、ARM Modeling Review、TypeSpec Validationへの対応が示されています。つまり、この記事の内容は「変更案として公開された仕様」をもとにした整理であり、正式公開時に項目名、必須項目、レスポンス構造、APIバージョンが変わる可能性があります。(GitHub)
本番実装では、Microsoft LearnのREST APIリファレンス、Azure SDKリリースノート、Azure CLIの対応状況、GitHub PRの最終差分を確認してください。
AIModelの名前にスラッシュが含まれる可能性がある
AIModel.name は、上流モデルIDに一致する説明があり、例として microsoft/Phi-4-mini-instruct のような形式が示されています。また、/ はワイヤ上で %2F としてURLエンコードする必要があると説明されています。(GitHub)
REST APIを直接呼ぶ場合、ここは実装ミスが起きやすいポイントです。モデル名をそのままURLパスに埋め込むと、意図しないパス区切りとして解釈される可能性があります。
サンプルJSONの値をそのまま使わない
PRに含まれるexamplesには、自動生成されたようなプレースホルダー値やランダム文字列が含まれています。たとえば AIModels_CalculateCost、ModelDeployments_CreateOrUpdate、ModelSources_CreateOrUpdate のサンプルには、実運用でそのまま使えない値が入っています。(GitHub)
実装時は、サンプルの構造だけを参考にし、モデルID、VM SKU、リソースID、credential、レプリカ数は自社環境に合わせて設定してください。
OpenAI互換エンドポイントでもAzure OpenAIそのものとは限らない
listAccessInfo ではOpenAI互換のbase URLが返る説明になっていますが、これはAzure OpenAI Serviceの管理APIと同じものという意味ではありません。AKS AI Manager namespaceで公開されるLLM gateway endpointとして扱うのが安全です。(GitHub)
アプリ側では、OpenAI互換クライアントを使える可能性がある一方、認証方式、対応モデル、APIパス、ストリーミング、エラー形式、レート制限は実際の公開ドキュメントで確認する必要があります。
対応すべきチーム別チェックリスト
Platform Engineeringチーム
AKS上でAI推論基盤を標準化するチームは、AIModel、ModelSource、ModelDeployment を社内のセルフサービスポータルやGitOpsフローにどう組み込むかを検討してください。
- モデル選定、コスト見積もり、デプロイ申請を一つのワークフローにまとめる
calculateCostの結果を申請承認や予算チェックに使うvmSizeとmodelResourceIdは作成後変更しにくい前提で設計する- namespace単位でアクセス情報と責任範囲を分ける
MLOpsチーム
外部モデルレジストリを使う場合、ModelSource が運用の中心になります。
- Hugging Faceなどのモデル利用条件を確認する
- gatedモデル用トークンの取得、保管、ローテーションを設計する
- publicモデルとprivateモデルでModelSourceを分ける
- モデル取得失敗時の再試行、監視、アラートを設計する
アプリ開発チーム
アプリから推論APIを呼び出す場合、listAccessInfo の結果として返るendpointとAPIキーの扱いが重要です。
- endpointを環境変数や設定ファイルで切り替えられるようにする
- APIキーをログ出力しない
- primary/secondary keyを使った無停止ローテーションを想定する
- OpenAI互換クライアントを使う場合も、実際の対応範囲を検証する
セキュリティ・ガバナンス担当
今回のAPIでは、モデル取得用credentialと推論アクセス用APIキーの2種類の重要情報が登場します。
ModelSourceのcredential登録権限を制限するlistAccessInfoの実行権限を最小化する- Key VaultやSecret Storeとの連携を標準化する
- 監査ログで誰がアクセス情報を取得したか追跡する
- ライセンスやgatedモデルの承認プロセスを整備する
いま取るべきアクション
今回のAzure REST API更新は、AKS AI Managerを使ったAIモデル運用をREST APIで自動化するための重要な追加です。特に AIModel によるモデル参照、calculateCost によるGPUコスト確認、ModelSource による外部モデルレジストリ管理、ModelDeployment によるnamespace単位の推論基盤構築、listAccessInfo によるOpenAI互換エンドポイント取得は、MLOpsとPlatform Engineeringの運用設計に直結します。
一方で、主なソースのPRはDraftで、レビューや検証が完了していない状態です。まずは本番実装ではなく、次の3点から始めるのが現実的です。
- PR #42883とMicrosoft Learnの公開状況を確認し、
2026-05-02-previewが正式に参照可能か確認する。 - 自社のAIモデル運用フローに、
AIModel、ModelSource、ModelDeploymentのどれが必要か整理する。 - credential、APIキー、GPUコスト、autoscaling上限、immutable項目を中心に、検証環境で設計レビューを行う。
AKSでAI推論基盤を運用する予定があるなら、この更新は単なるREST APIの追加ではなく、モデル基盤を「手作業」から「管理プレーンAPIによる自動化」へ移すための下地になります。正式公開後に慌てて対応するのではなく、いまのうちに権限設計、コスト管理、モデルソース管理、デプロイ標準を見直しておくと移行がスムーズです。
コメント