Azure Kubernetes Service（AKS）で AI/ML ワークロードを動かす場合、今回まず確認すべき点は「新しい設定を必ず有効化すること」ではなく、AKS Automatic と AKS Standard のどちらで運用責任を持つかを整理することです。Microsoft Learn の「AI and ML workloads in Azure Kubernetes Service (AKS)」は、AI 推論、機械学習、LLM、MLOps を AKS 上で扱う際の基本方針を、AKS Automatic と AKS Standard の違いに沿ってまとめています。(Microsoft Learn)
特に管理者は、既存クラスターへ即時適用が必要な変更があるかだけでなく、ノード管理、GPU 利用、アップグレード、監視、セキュリティ、ネットワークの責任分界を確認する必要があります。該当ページのメタデータ上の更新日は 2026年6月5日と表示されているため、本記事では 2026年7月3日時点で公開されている公式情報として、影響範囲と確認ポイントを実務向けに整理します。(GitHub)
Azure の新機能・変更点：「AI and ML Workloads in Azure Kubernetes Service (AKS)」で確認すべきポイント
今回の公式情報は、AKS に新しい AI 機能が単独で追加されたというよりも、AI/ML ワークロードを AKS で運用する際の設計判断を整理した内容です。対象は AKS Automatic と AKS Standard の両方です。公式ページでは、AI/ML ワークロードの多くの実装プラクティスは両モードに共通する一方、違いは「プラットフォームの所有範囲」と「Day 2 operations」、つまり本番運用開始後の管理責任にあると説明されています。(Microsoft Learn)
実務上の結論は明確です。短期間で本番向けの標準構成を用意したい場合は AKS Automatic が候補になります。一方で、ネットワーク、ID、GPU ノードプール、アップグレード方式、セキュリティポリシーを細かく制御したい場合は AKS Standard を選ぶべきです。(Microsoft Learn)
今回の更新で重要な影響範囲
| 対象 | 影響 | 管理者が確認すべきこと |
|---|---|---|
| 新規に AKS で AI/ML 基盤を作るチーム | クラスターモード選定が初期設計の重要項目になる | AKS Automatic で標準化するか、AKS Standard で細かく設計するかを決める |
| 既存の AKS Standard 利用組織 | 即時移行が必要というより、明示的な設定責任が再確認される | 監視、セキュリティ、ノードプール、GPU、アップグレードチャネルを棚卸しする |
| AKS Automatic 利用組織 | 事前構成済みの運用・セキュリティ・監視を前提に AI/ML を載せやすい | Automatic で未対応の拡張機能や Windows ノード要件がないか確認する |
| LLM や生成 AI をセルフホストしたい組織 | KAITO / AI toolchain operator add-on が候補になる | GPU クォータ、リージョン、Linux ノード、モデルサイズ、運用監視を確認する |
| グローバル展開する企業 | リージョン、GPU 在庫、ネットワーク設計、データ所在が重要になる | 利用リージョンごとに GPU VM の可用性、通信経路、監査要件を確認する |
公式ページの範囲では、既存の AKS クラスターに対して一律に適用される強制的な移行期限や、全ユーザー共通の設定変更期限は示されていません。ただし、関連する AKS Automatic の公式情報では、AKS 1.36 以降の新規 Automatic クラスターで、アプリケーション ルーティング アドオンの既定が Managed NGINX ingress から Kubernetes Gateway API に変わる点が示されています。既存 Automatic クラスターは直接影響を受けないものの、移行検討を始めるべき対象です。(Microsoft Learn)
AKS Automatic と AKS Standard の違いを AI/ML 視点で理解する
AKS で AI/ML ワークロードを動かす場合、単に「Kubernetes が使えるか」ではなく、GPU、スケーリング、モデル配布、監視、セキュリティ、アップグレード時の可用性まで考える必要があります。公式情報では、AKS Automatic は本番向けの既定値が多く、AKS Standard は運用者がより明示的に構成を選べるモードとして整理されています。(Microsoft Learn)
| 比較項目 | AKS Automatic | AKS Standard | AI/ML 運用での判断基準 |
|---|---|---|---|
| クラスター運用 | 本番向けの既定構成が多い | 構成とライフサイクルを運用者が細かく管理 | Kubernetes 運用専任者が少ない場合は Automatic が扱いやすい |
| ノード管理とスケーリング | システムノードやノード自動プロビジョニングが事前構成される | ノードプールとスケーリング戦略を明示的に設計する | GPU ノードを細かく分けたい場合は Standard が向く |
| アップグレード | クラスターとノード OS イメージの自動アップグレードが事前構成される | 手動またはアップグレードチャネルを選択 | 変更タイミングを厳密に統制したい場合は Standard を検討 |
| セキュリティ | Deployment safeguards や Pod Security Standards のベースラインが事前構成される | セキュリティやポリシーを明示的に有効化する | セキュリティ標準を早く揃えたい場合は Automatic が有利 |
| 監視 | CLI やポータル作成フローでは Managed Prometheus や Container Insights が既定 | 監視コンポーネントを明示的に有効化 | 既存の監視基盤と統合する場合は Standard の自由度が高い |
| ネットワーク | マネージド仮想ネットワーク、ingress / egress の既定パターンが用意される | ネットワークモデルや ingress / egress を選択 | 閉域網、独自 DNS、既存ネットワーク統合が複雑なら Standard または Automatic のカスタムネットワークを検討 |
AI/ML ワークロードでは、アプリケーション本体よりも周辺運用が難しくなりがちです。たとえば、LLM 推論では GPU ノードの確保、モデルイメージの配布、推論 API の監視、ピーク時のスケールアウト、オフピーク時のスケールダウンが必要になります。これらを「どこまで Azure 側の既定値に任せるか」「どこから自社で設計するか」が、AKS Automatic と AKS Standard の選択基準です。
AI/ML ワークロードで AKS を使う主なシーン
AKS は、コンテナー化された AI/ML アプリケーションをスケーラブルかつ高可用に運用するための基盤として位置付けられています。公式ページでは、トレーニングや推論向けの高性能インフラ、オープンソースフレームワークや既存 DevOps プロセスとの統合、マネージド Kubernetes による運用信頼性、ポリシーやプラットフォーム制御によるセキュリティ強化、需要に応じたコスト最適化が利点として整理されています。(Microsoft Learn)
生成 AI アプリケーションを AKS に載せる
Azure OpenAI または OpenAI を利用するアプリケーションを AKS にデプロイする構成では、フロントエンド、API、メッセージキュー、データベース、トラフィックシミュレーターなどを含むマイクロサービス構成が例示されています。公式のサンプルでは MongoDB や RabbitMQ を簡略化のために含めていますが、本番では永続ストレージなしでステートフルコンテナーを動かすのではなく、Azure Cosmos DB や Azure Service Bus などのマネージドサービス利用が推奨されています。(Microsoft Learn)
実務では、次のような使い分けが考えられます。
| シーン | 推奨される考え方 |
|---|---|
| 社内チャットボットや要約アプリ | Azure OpenAI などの API サービスを使い、AKS 側はアプリケーション実行基盤にする |
| RAG アプリケーション | ベクトル検索、ドキュメント取り込み、API、UI を分離し、CI/CD と監視を整える |
| 顧客向け生成 AI サービス | レート制限、認証、監査ログ、モデル応答の安全対策を AKS 側の運用設計に含める |
| 規制業界の AI アプリ | データ所在、ネットワーク分離、キー管理、監査証跡を設計段階から確認する |
LLM をセルフホストする
大規模言語モデルを自社環境でホストしたい場合、AKS では AI toolchain operator add-on と KAITO が選択肢になります。公式情報では、KAITO は Kubernetes 上でオープンソース LLM ワークロードのデプロイと管理を簡素化し、vLLM と統合して効率的な推論を支援すると説明されています。AI toolchain operator add-on では、OpenAI 互換 API、プロンプトフォーマット、ストリーミング応答などの機能も示されています。(Microsoft Learn)
ただし、セルフホストは「API 料金を下げられる可能性がある」だけで判断すると失敗します。GPU クォータ、GPU VM のリージョン別可用性、モデルサイズ、推論性能、セキュリティ監査、パッチ適用、モデル更新の運用まで含めて比較する必要があります。公式トラブルシューティングでも、GPU クォータ不足や対象リージョンでの GPU インスタンス未提供が、KAITO ワークスペースの準備完了を妨げる要因として挙げられています。(Microsoft Learn)
Ray を使った分散学習・チューニング
分散学習やハイパーパラメーターチューニングでは、Ray と KubeRay を AKS にデプロイする構成が公式ドキュメントで紹介されています。Ray は分散コンピューティングと機械学習ワークロード向けのオープンソースフレームワークで、AKS 上では複数ノードにまたがるトレーニングや推論を支援します。(Microsoft Learn)
特にチューニングジョブでは、複数のワーカーが同時にデータを読み書きするため、ストレージがボトルネックになりやすくなります。公式情報では、Ray クラスターの分散チューニング用途において、BlobFuse / Azure Blob Storage がクラウドスケールの並列アクセス、高スループット、コスト効率の観点から有力な選択肢として整理されています。(Microsoft Learn)
管理者が確認すべき設定変更ポイント
今回の公式情報を受けて、管理者が最初に行うべきことは「既存環境に何かをすぐ入れること」ではありません。先に、現在の AKS 環境が AI/ML ワークロードに耐えられる状態かを棚卸しすることです。
クラスターモードを標準化する
新規環境では、AKS Automatic を標準にするか、AKS Standard を標準にするかを決めます。小規模チーム、PoC から本番化までのスピード重視、Kubernetes 運用の専任者が少ない組織では AKS Automatic が候補になります。Microsoft Learn では、AKS Automatic はクラスターセットアップ、ノード管理、スケーリング、セキュリティ、AKS Well-Architected recommendations に沿った事前構成を Azure が担うと説明されています。(GitHub)
一方で、既存のハブスポークネットワーク、専用 GPU ノードプール、厳密なメンテナンスウィンドウ、独自のセキュリティ製品、複雑な ingress / egress 制御がある場合は、AKS Standard のほうが適するケースがあります。重要なのは、どちらが優れているかではなく、運用責任をどこに置くかです。
GPU クォータとリージョンを事前に確認する
AI/ML ワークロードでは、CPU やメモリだけでなく GPU の調達可否がボトルネックになります。KAITO を使う場合も、サブスクリプションにモデルデプロイで必要な GPU VM クォータがあり、AKS リソースと同じリージョンで利用できることが前提になります。(Microsoft Learn)
確認すべき項目は次のとおりです。
| 確認項目 | 具体的な確認内容 |
|---|---|
| GPU VM クォータ | 利用予定モデルに必要な GPU ファミリのクォータがあるか |
| リージョン | 対象リージョンで必要な GPU VM サイズが提供されているか |
| コスト | 常時稼働、スケールアウト、検証環境を含めた月額見積もりを取っているか |
| スケール戦略 | ピーク時にノードが増え、オフピーク時に縮退できる設計か |
| 調達リスク | グローバル展開時に全リージョンで同じ GPU が使える前提にしていないか |
GPU は「あとから増やせばよい」と考えると、PoC では動いたのに本番リージョンでは必要な VM サイズが確保できない、という事態が起こります。AI/ML 基盤の設計では、最初にリージョンと GPU クォータを確認するのが安全です。
AI toolchain operator add-on の前提条件を確認する
AI toolchain operator add-on を使う場合は、AKS クラスター作成時または既存クラスター更新時に --enable-ai-toolchain-operator と --enable-oidc-issuer を指定する手順が公式ドキュメントで示されています。また、Azure CLI 2.76.0 以上、kubectl、GPU クォータなども前提として示されています。(Microsoft Learn)
注意すべき制限もあります。公式情報では、AI toolchain operator add-on は Windows OS SKU を現在サポートしておらず、KAITO ワークスペースの instanceType として AMD GPU VM サイズもサポートされていません。対応リージョンについても、利用前に最新の公式情報で確認する必要があります。(Microsoft Learn)
監視とログを「モデル運用」まで広げる
AKS Automatic では、Azure CLI や Azure portal の作成フローを使う場合に Managed Prometheus と Container Insights が既定となる一方、AKS Standard では監視コンポーネントを明示的に有効化する必要があります。(Microsoft Learn)
AI/ML ワークロードでは、通常の Kubernetes メトリックだけでは不十分です。少なくとも次の観点を監視対象に含めます。
| 監視対象 | 見るべき理由 |
|---|---|
| Pod / Node / GPU 使用率 | 推論遅延やスケール不足を早期に検知する |
| API レイテンシ | ユーザー体験と SLA に直結する |
| エラー率 | モデル API、前処理、後処理、外部サービス障害を切り分ける |
| キュー長 | バッチ処理やイベント駆動処理の詰まりを検知する |
| モデル品質指標 | 精度劣化、応答品質低下、再学習の必要性を判断する |
| コスト指標 | GPU の過剰稼働や検証環境の消し忘れを見つける |
MLOps の観点では、モデル性能しきい値を使って劣化を検出し、再学習パイプラインにつなげる設計も重要です。公式の MLOps ベストプラクティスでも、アラートによるデータ取り込みフローの起動、モデル性能しきい値による再学習パイプラインのトリガー、構成ドリフト検出やリリースガバナンスの自動化が挙げられています。(GitHub)
セキュリティは「クラスター」と「モデル・データ」で分けて考える
AKS Automatic は、Azure RBAC、Workload Identity、OIDC、Deployment safeguards、Pod Security Standards などの多くのベースラインを事前構成または既定化する方向で整理されています。ただし、これは AI/ML ワークロード全体のセキュリティが自動で完成するという意味ではありません。(GitHub)
AI/ML では、以下のように責任を分けて管理する必要があります。
| レイヤー | 管理ポイント |
|---|---|
| クラスター | RBAC、Pod Security、ネットワークポリシー、アップグレード、監査ログ |
| コンテナー | イメージスキャン、脆弱性対応、署名、SBOM、不要イメージ削除 |
| モデル | モデルの出所、バージョン、ライセンス、改ざん検知 |
| データ | 個人情報、機密データ、学習データの取り扱い、保存場所 |
| 推論 API | 認証、認可、レート制限、プロンプトインジェクション対策、ログ管理 |
| MLOps パイプライン | 承認フロー、再学習条件、ロールバック、変更履歴 |
AKS Automatic を使う場合でも、モデルレベル、データレベル、パイプラインレベルのセキュリティは利用者側の責任です。公式の MLOps ベストプラクティスでも、モデルコンテナーイメージの CVE スキャンや、取り込んだデータ、モデル変更、メトリックの監査証跡を維持することが重要とされています。(GitHub)
移行期限と廃止予定で注意すべきこと
「AI and ML workloads in Azure Kubernetes Service (AKS)」の概要ページ自体には、既存 AKS クラスターを特定日までに移行しなければならないという内容は確認できません。したがって、今回のポイントは「期限対応」よりも「設計標準の見直し」です。(Microsoft Learn)
ただし、関連する AKS Automatic の情報として、次の点は管理者が把握しておくべきです。
| 項目 | 内容 | 実務上の対応 |
|---|---|---|
| AKS 1.36 以降の ingress 既定 | 新規 AKS Automatic クラスターでは、アプリケーション ルーティング アドオンの既定が Kubernetes Gateway API になる | Managed NGINX ingress 前提のテンプレートや手順を見直す |
| 既存 Automatic クラスター | 既存クラスターは直接影響を受けないが、Gateway API への移行検討が推奨される | 新規構築標準を Gateway API 前提に更新する |
| AKS Automatic の SKU 移行 | AKS base SKU と Automatic SKU 間の移行はサポートされない | Standard から Automatic へ切り替える場合は再作成・移行計画として扱う |
| Managed system node pools | 新規 Automatic クラスターでは managed system node pools が既定で有効 | 既存 Automatic 環境の構成差異を確認する |
| 未対応機能 | AKS Automatic では Windows ノードや一部拡張機能が未対応 | AI/ML 周辺製品や既存アプリ要件と照合する |
AKS Automatic の managed system node pools に関する公式情報では、Windows ノードがサポートされないこと、Azure Machine Learning 拡張機能など一部拡張機能がサポート対象外であること、AKS base SKU と Automatic SKU 間の移行がサポートされないことが示されています。AI/ML 基盤を Automatic に寄せる場合、Azure Machine Learning との接続方式や既存拡張機能の利用有無を必ず確認してください。(Microsoft Learn)
実務で使える判断基準
AKS Automatic を選びやすいケース
AKS Automatic は、Kubernetes の細かな運用よりも、AI アプリケーションやモデル運用に開発リソースを集中したい場合に向いています。たとえば、社内向け生成 AI アプリ、RAG アプリ、API ベースの推論サービスを素早く本番化したい場合です。
向いているケースは次のとおりです。
| 条件 | 理由 |
|---|---|
| Kubernetes 専任運用者が少ない | ノード管理、スケーリング、セキュリティの既定値を活用しやすい |
| 標準構成で早く本番化したい | 本番向けベースラインを作る手間を減らせる |
| 新規プロジェクトで設計自由度が高い | Automatic の前提に合わせてアーキテクチャを組みやすい |
| 監視やセキュリティの初期設定を省力化したい | Managed Prometheus、Container Insights、ポリシーの既定値を活用しやすい |
ただし、Automatic は万能ではありません。独自 DNS、特殊なネットワーク、Windows ノード、未対応拡張機能、既存標準との整合性がある場合は、事前検証が必要です。
AKS Standard を選びやすいケース
AKS Standard は、細かなインフラ制御が必要な AI/ML 基盤に向いています。たとえば、GPU ノードプールをモデル種別ごとに分ける、閉域網と専用 DNS を使う、アップグレードタイミングを厳密に管理する、既存の監視・セキュリティ製品と統合する、といった要件がある場合です。
向いているケースは次のとおりです。
| 条件 | 理由 |
|---|---|
| GPU ノードプールを細かく設計したい | モデルサイズや推論特性ごとにノードを分けられる |
| 既存ネットワークとの統合が複雑 | ingress、egress、DNS、ファイアウォールを明示的に管理しやすい |
| アップグレードを厳密に制御したい | 手動またはチャネルを選んで運用しやすい |
| 独自のセキュリティ基準がある | ポリシー、監視、ランタイム制御を自社標準に合わせやすい |
Standard を選ぶ場合は、Automatic で事前構成される領域を自社で設計・運用する覚悟が必要です。特に AI/ML では、GPU、モデル管理、データアクセス、監視、再学習パイプラインまで含めると運用範囲が広がります。
管理者向けチェックリスト
既存環境を確認する場合は、次の順番で棚卸しすると実務に落とし込みやすくなります。
| チェック項目 | 確認内容 | 優先度 |
|---|---|---|
| クラスターモード | AKS Automatic か AKS Standard か。新規標準はどちらにするか | 高 |
| Kubernetes バージョン | AKS 1.36 以降の ingress 既定変更に関係するか | 高 |
| ingress / Gateway | Managed NGINX ingress 前提の構成がないか | 高 |
| GPU クォータ | 利用予定リージョンで必要な GPU VM クォータがあるか | 高 |
| ノード設計 | CPU / GPU / システム / ユーザーのノード分離が適切か | 高 |
| AI toolchain operator | 利用予定なら OIDC、CLI、Linux、GPU、リージョン要件を満たすか | 高 |
| 監視 | Managed Prometheus、Container Insights、Grafana、既存監視基盤をどう使うか | 中 |
| セキュリティ | RBAC、Workload Identity、Pod Security、イメージスキャン、監査ログを確認したか | 高 |
| MLOps | モデルバージョン、再学習、ロールバック、承認フローを定義したか | 中 |
| コスト | GPU の常時稼働、検証環境、未使用ノードの削除手順を決めたか | 高 |
| IaC | クラスター、アドオン、ポリシー、モデルデプロイをコード化しているか | 中 |
| 未対応機能 | Automatic で使えない拡張機能や Windows ノード要件がないか | 高 |
失敗しやすいポイント
「Automatic なら AI 基盤が全部自動で完成する」と考える
AKS Automatic は、クラスター運用やベースライン設定の負担を減らします。しかし、モデルの品質管理、データ保護、プロンプト対策、モデルバージョン管理、再学習パイプライン、利用者認証まで自動化してくれるわけではありません。
AI/ML ワークロードでは、Kubernetes の運用だけでなく、モデルとデータのライフサイクル管理が必要です。Automatic を使う場合でも、MLOps、監査、セキュリティの設計は別途必要です。
GPU クォータを後回しにする
LLM や分散学習の PoC では、最初に小さなモデルで成功し、本番化で大きな GPU が必要になることがあります。このとき、サブスクリプションの GPU クォータや対象リージョンでの GPU 提供状況を確認していないと、移行直前に止まります。
KAITO でも、GPU クォータ不足やリージョンで対象 GPU インスタンスが利用できないことが、ワークスペース準備失敗の原因になり得ると公式情報で示されています。(Microsoft Learn)
サンプル構成をそのまま本番に使う
公式サンプルは学習や検証を目的としており、本番アーキテクチャそのものではありません。Azure OpenAI / OpenAI を使う AKS サンプルでも、MongoDB や RabbitMQ のようなステートフルコンテナーを永続ストレージなしで本番利用することは推奨されておらず、Azure Cosmos DB や Azure Service Bus のようなマネージドサービス利用が推奨されています。(Microsoft Learn)
本番では、サンプルから次の点を必ず変更します。
| サンプルから見直す項目 | 本番での考え方 |
|---|---|
| データベース | マネージド DB または永続ストレージを使う |
| メッセージキュー | Azure Service Bus などのマネージドサービスを検討する |
| シークレット | Kubernetes Secret だけでなく Key Vault 連携を検討する |
| ingress | TLS、認証、WAF、Gateway API などを設計する |
| 監視 | アプリ、モデル、インフラ、コストをまとめて見る |
| 可用性 | レプリカ、PDB、ゾーン冗長、バックアップを検討する |
KAITO のリソース削除を忘れる
KAITO でモデルをデプロイした後、不要になった場合はワークスペースを削除するだけでなく、KAITO デプロイによってプロビジョニングされた GPU ノードプールを手動で削除する必要があると公式手順に記載されています。GPU ノードは高コストになりやすいため、検証環境では削除手順を Runbook 化しておくべきです。(Microsoft Learn)
これから取るべき行動
まず、既存 AKS クラスターを一覧化し、AKS Automatic / AKS Standard、Kubernetes バージョン、ingress、ノードプール、GPU 利用、監視、セキュリティポリシー、利用アドオンを確認してください。次に、AI/ML ワークロードの種類を「Azure OpenAI などの外部 API 利用」「LLM セルフホスト」「Ray による分散学習・チューニング」「MLOps パイプライン」に分け、必要な運用責任を整理します。
新規構築では、運用負荷を下げたいなら AKS Automatic、細かな制御が必要なら AKS Standard を候補にします。既存環境では、無理に移行するのではなく、監視、セキュリティ、GPU、ingress、アップグレード、MLOps の不足を埋めることが先です。
今回の「AI and ML workloads in Azure Kubernetes Service (AKS)」で最も重要なのは、AI/ML ワークロードを「アプリをコンテナーで動かすだけ」と捉えないことです。AKS を AI 基盤として使うなら、クラスター設計、GPU、ネットワーク、セキュリティ、モデル管理、コスト管理を一体で設計する必要があります。まずは小さな検証環境で、AKS Automatic と AKS Standard のどちらが自社の運用体制に合うかを比較し、その結果を標準構成として IaC と運用手順に落とし込むのが現実的な進め方です。
コメント