AKS AutomaticとAKS Standard、情シスはどちらを選ぶべきか

自動化による安全性と、個別制御の自由度のトレードオフを整理する

確認日：2026年7月8日対象読者：情シス担当者、クラウド運用担当者、Azure担当者、経営層、監査対応担当者対象領域：Azure Kubernetes Service、AKS Automatic、AKS Standard、運用責任、変更管理、監査証跡、クラウドガバナンス

結論

情シスが新規にAKSを選定する場合、一般的な本番ワークロードはAKS Automaticを第一候補にすべきです。一方で、ネットワーク、ノードプール、Windowsノード、アップグレード周期、既存の自動化、規制対応のための詳細な統制を明示的に制御したい場合はAKS Standardを選ぶべきです。

理由は、AKS Automaticはノード管理、スケーリング、セキュリティ、監視、アップグレードなどをAzure側が事前構成・自動化するため、情シスの運用負荷と設定漏れリスクを下げやすいからです。Microsoft公式でも、AKS Automaticは多くのチームとワークロードに推奨され、AKS Standardはクラスター構成やノードプールを完全に制御したい場合に推奨されると説明されています。

数字で見ると、選定時に最低限確認すべき項目は15項目です。1. ワークロード特性、2. Kubernetes成熟度、3. ネットワーク要件、4. Windowsノード要否、5. Dapr要否、6. Azure Machine Learning拡張要否、7. ノードSKU制御、8. アップグレード承認、9. SLA、10. 監視、11. セキュリティ既定値、12. コスト、13. 監査証跡、14. 既存IaC、15. 運用責任です。

1. まず整理すべきこと：AKS AutomaticとAKS Standardは「思想」が違う

AKSには、AKS AutomaticとAKS Standardという2つのクラスター モードがあります。Microsoft公式では、AKS Automaticは運用環境対応の既定値を使用したフルマネージド エクスペリエンスであり、Azureがノード管理、スケーリング、セキュリティ、監視、アップグレードを自動的に処理すると説明されています。一方、AKS Standardは、クラスター構成とノードプールの管理を完全に制御するモードです。

つまり、両者の違いは「どちらが高性能か」ではありません。違いは、誰がどこまで運用判断を持つかです。

図1：AKS AutomaticとAKS Standardの基本思想

AKS Automatic
────────────────────────────────────
Azure側の事前構成・自動化を活用
  ↓
情シスの運用負荷を下げる
  ↓
標準化された安全な既定値で始める
  ↓
一般的な本番ワークロード向き


AKS Standard
────────────────────────────────────
情シス・プラットフォームチームが詳細制御
  ↓
ネットワーク、ノード、アップグレード、拡張機能を設計
  ↓
自由度は高いが運用責任も大きい
  ↓
特殊要件・規制要件・既存標準がある環境向き

2. 確認できた公式情報

表1：Microsoft公式情報で確認できた主な事実

項目	AKS Automatic	AKS Standard
基本位置付け	運用対応の既定値を持つフルマネージド寄りのAKS	クラスター構成・ノードプールを細かく制御するAKS
Microsoft公式の推奨	多くのチーム・ワークロードに推奨	特定のインフラ要件や既存自動化がある場合に推奨
ノード管理	Azureがノードプロビジョニング、スケーリング、アップグレードを自動処理	ノードプールを手動で作成・管理
セキュリティ既定値	Azure RBAC、Workload Identity、OIDC Issuer、デプロイ保護機能、Image Cleaner等が既定で有効	機能ごとのオプトイン
監視	Managed Prometheus、Container Insights、Azure Monitorダッシュボードが既定でオン	機能ごとのオプトイン
Windowsノード	サポートされていません	Windowsノードプールが必要な場合の選択肢
Dapr拡張	サポートされていません	要件に応じて検討
Azure Machine Learning拡張	サポートされていません	要件に応じて検討
移行	AKSベースSKUとAutomatic SKU間の移行はサポートされていません	設計時に将来移行を考慮

AKS Automaticでは、Dapr拡張、Azure Machine Learning拡張、Windowsノードはサポートされず、AKSベースSKUとAutomatic SKU間の移行もサポートされないことがMicrosoft公式に記載されています。

3. 情シス向けの結論：迷ったらAutomatic。ただし赤信号があればStandard

図2：選定フローチャート

START
  │
  ▼
Kubernetesが本当に必要か？
  │
  ├─ いいえ / 単純なWeb API中心
  │      └─ Container Apps等も比較検討
  │
  └─ はい
       │
       ▼
Windowsノード、Dapr、Azure ML拡張が必須か？
       │
       ├─ はい → AKS Standard
       │
       └─ いいえ
            │
            ▼
ネットワーク、ノードSKU、アップグレード周期を
厳密に個別制御する必要があるか？
            │
            ├─ はい → AKS Standard
            │
            └─ いいえ
                 │
                 ▼
Kubernetes運用成熟度が高く、既存標準があるか？
                 │
                 ├─ はい → AKS Standardも候補
                 └─ いいえ → AKS Automaticを第一候補

4. AKS Automaticを選ぶべきケース

AKS Automaticは、Azure Well-Architected Frameworkの推奨事項に沿った事前構成を提供し、ノード管理、スケーリング、セキュリティポリシー、アップグレードの組み込み構成により、プラットフォームエンジニアリングにかかる時間を短縮するとMicrosoft公式で説明されています。

表2：AKS Automaticが向いているケース

ケース	理由
新規の本番アプリケーション	運用対応の既定値で始めやすい
Kubernetes専任チームが小さい	ノード管理や監視設定の初期負担を下げやすい
標準的なWeb/APIワークロード	自動スケーリング、監視、セキュリティ既定値を活用しやすい
迅速に本番運用へ進みたい	プラットフォーム設計の意思決定を減らせる
ノードSKUやCNIを細かく指定しなくてよい	Automaticのマネージドな設計と相性がよい
監視・セキュリティの設定漏れを減らしたい	Managed Prometheus、Container Insights等が既定で有効

図3：AKS Automaticの運用イメージ

情シス・開発チーム
  │
  │ アプリケーション、マニフェスト、権限、監視確認
  ▼
AKS Automatic
  │
  ├─ ノード自動プロビジョニング
  ├─ 自動スケーリング
  ├─ 自動アップグレード
  ├─ セキュリティ既定値
  ├─ 監視既定値
  └─ SLA込みの運用基盤

5. AKS Standardを選ぶべきケース

AKS Standardは、ネットワーク、ノードプール、アップグレード周期、承認を明示的に制御したい場合に使う選択肢としてMicrosoft公式に示されています。また、厳格なコンプライアンス管理と監査証跡が必要な規制環境では、AKS Standardの規制対応アーキテクチャが選択肢として説明されています。

表3：AKS Standardが向いているケース

ケース	理由
Windowsノードが必要	AKS AutomaticではWindowsノード非対応
Dapr拡張が必要	AKS AutomaticではDapr拡張非対応
Azure Machine Learning拡張が必要	AKS AutomaticではAzure ML拡張非対応
ネットワークを厳密に設計したい	CNI、サブネット、NSG、FW、ルーティングを細かく設計したい場合
ノードプールを細かく分けたい	CPU/GPU、ワークロード別、業務別、可用性要件別など
既存のIaC標準がある	Terraform/Bicep/GitOps等で既存設計に合わせたい場合
アップグレード承認を厳密化したい	変更管理委員会、CAB、監査承認が必要な場合
規制・監査で全構成の明示制御が必要	コンポーネント単位で説明責任を持つ必要がある場合

図4：AKS Standardの運用イメージ

情シス・プラットフォームチーム
  │
  ├─ ネットワーク設計
  ├─ ノードプール設計
  ├─ アップグレード設計
  ├─ セキュリティ制御
  ├─ 監視設計
  ├─ コスト設計
  ├─ IaC管理
  └─ 監査証跡管理
        │
        ▼
AKS Standard
  │
  └─ 自由度は高いが、設計・運用責任も大きい

6. 重要な誤解：AKS Automaticでも運用責任は消えない

ここが非常に重要です。

AKS Automaticは、クラスター側の多くの運用を自動化します。しかし、アプリケーションの信頼性、マニフェスト、レプリカ数、プローブ、PodDisruptionBudget、権限設計、コンテナーイメージ管理、監査説明までAzureが代わりに保証してくれるわけではありません。

Microsoft公式のAKS信頼性ベストプラクティスでも、AKS Automaticがクラスター レベルで信頼性の既定値を提供する場合でも、ワークロードマニフェストにはプローブ、レプリカ数、中断予算、トポロジルールなどのアプリケーション固有の信頼性設定が必要と説明されています。

表4：AKS Automaticでも情シス・開発側に残る責任

領域	Automaticで軽くなる部分	それでも残る責任
ノード管理	ノード自動プロビジョニング等	ワークロードのリソース要求・制限設計
スケーリング	HPA/KEDA/VPA等の事前構成	適切な閾値、最小・最大レプリカ、業務ピーク設計
可用性	SLAや信頼性既定値	複数レプリカ、プローブ、PDB、DB設計
セキュリティ	既定のセキュリティ設定	Namespace、RBAC、秘密情報、イメージ管理
監視	監視機能の初期構成	アラート閾値、障害時手順、監査保存期間
アップグレード	自動化・事前構成	メンテナンス期間、影響確認、事前検証
監査	一部証跡を取りやすい	変更理由、承認者、例外管理、規程整備

7. SLAの見方：APIサーバーSLAとアプリSLAは別物

AKS Automaticには、対象となるPod準備操作の99.9%が5分以内に完了することを財務的に保証するPod readiness SLAが含まれるとMicrosoft公式で説明されています。また、AKS AutomaticにはKubernetes APIサーバーの99.95%可用性を保証するアップタイムSLAが含まれると説明されています。

一方、AKSの価格レベルに関する公式情報では、StandardレベルとPremiumレベルには既定でアップタイムSLAが含まれ、可用性ゾーンありの場合は99.95%、可用性ゾーンなしの場合は99.9%のKubernetes APIサーバー可用性、Freeレベルは金銭的保証のあるSLAなしと説明されています。AKS AutomaticクラスターはStandardレベルで事前構成され、クラスターアップタイムSLAとPod readiness SLAの両方が含まれると記載されています。

表5：SLAで誤解しやすい点

項目	説明
APIサーバーSLA	Kubernetes APIサーバーの可用性に関するSLA
Pod readiness SLA	対象Podの準備操作が一定時間内に完了することに関するSLA
アプリケーションSLA	自社アプリ、DB、外部API、認証、ネットワークを含む業務サービス全体の可用性
注意点	AKSのSLAがあることと、自社アプリが停止しないことは同じではない

図5：SLAの責任範囲イメージ

Microsoft側の主な範囲
────────────────────────
Kubernetes APIサーバー
AKSマネージド機能
AutomaticのPod readiness SLA対象範囲


利用企業側の主な範囲
────────────────────────
アプリケーション設計
DB設計
外部API依存
Ingress/WAF設計
認証認可
マニフェスト
リリース手順
監査証跡

8. 自動化と自由度のトレードオフ

表6：自動化と自由度の比較

観点	AKS Automatic	AKS Standard
導入スピード	速い	設計・構築に時間がかかる
初期設計の難易度	低め	高め
ノード運用	自動化	自社設計・自社運用
ネットワーク自由度	制約あり	高い
セキュリティ既定値	強い	自社で明示構成
監視の初期設定	既定で有効なものが多い	自社で有効化
コスト最適化	自動化により設計負担を下げやすい	詳細制御できるが運用設計が必要
監査対応	標準的な説明に向く	詳細な独自統制に向く
学習負荷	比較的低い	高い
運用責任	一部Azureへ寄せられる	自社側が広く持つ

図6：トレードオフの見取り図

自動化・標準化を重視
↑
│       AKS Automatic
│       ・安全な既定値
│       ・運用負荷低減
│       ・標準ワークロード向き
│
│
│
│       AKS Standard
│       ・詳細制御
│       ・特殊要件対応
│       ・運用責任大
│
└────────────────────→ 個別制御・自由度を重視

9. 選定基準：15項目チェック表

表7：AKS Automatic / AKS Standard 選定チェック表

No.	確認項目	Automatic向き	Standard向き
1	新規ワークロードか	はい	既存標準がある
2	Kubernetes運用成熟度	低〜中	高い
3	専任プラットフォームチーム	小さい	ある
4	Windowsノード	不要	必要
5	Dapr拡張	不要	必要
6	Azure ML拡張	不要	必要
7	ネットワーク制御	標準でよい	厳密に制御
8	ノードSKU制御	標準でよい	厳密に指定
9	GPU/特殊VM	要確認	詳細設計したい
10	監視	既定値を活用	独自標準あり
11	セキュリティ	既定値重視	独自ポリシー重視
12	アップグレード	自動化重視	承認・時期を厳格管理
13	監査証跡	標準証跡で足りる	詳細証跡が必要
14	規制対応	一般統制	厳格な個別統制
15	IaC標準	これから整備	既存標準に合わせる

10. 赤信号ルール：この条件ならStandardを強く検討

表8：Automaticを避けるべき可能性が高い条件

赤信号	理由
Windowsノードが必要	AKS AutomaticではWindowsノードがサポートされていません
Dapr拡張が必要	AKS AutomaticではDapr拡張がサポートされていません
Azure Machine Learning拡張が必要	AKS AutomaticではAzure ML拡張がサポートされていません
AKSベースSKUからAutomaticへそのまま移行したい	公式に移行はサポートされていません
MC_リソースグループを直接変更する運用がある	AKS Automaticではnodeリソースグループのロックダウンが事前構成されています
既存の厳格なネットワーク標準がある	Standardで詳細設計した方が説明しやすい場合があります
監査上、全コンポーネントの構成変更を自社管理したい	Automaticでは一部がAzure管理となるため、責任分界の説明が必要です

AKS Automaticの制限として、nodeリソースグループのロックダウン、Dapr・Azure Machine Learning拡張の非対応、Windowsノード非対応、AKSベースSKUとAutomatic SKU間の移行非対応がMicrosoft公式に記載されています。

11. ノード自動プロビジョニングの考え方

AKSでは、ワークロードをデプロイするときに適切なVMサイズを選ぶ必要があります。Microsoft公式では、Node Auto Provisioning、NAPは、保留中のPodリソース要件を使って、効率的かつコスト効率の高いVM構成を決定し、ワークロードに最適なVM構成を自動的にプロビジョニング・管理すると説明されています。AKS AutomaticではNAPが既定で事前構成され、AKS Standardでは明示的に有効化・構成します。

図7：NAPの考え方

Podが要求するCPU / Memory / GPU等
        │
        ▼
保留中Podのリソース要求を確認
        │
        ▼
適切なノード構成を判断
        │
        ▼
必要なVMをプロビジョニング
        │
        ▼
Podをスケジューリング

表9：NAPの選定観点

観点	AKS Automatic	AKS Standard
NAPの状態	事前構成	明示的に有効化・構成
VM選定	自動化を活用	自社で詳細制御
運用負荷	低い	高い
チューニング自由度	制限あり	高い
向いている組織	Kubernetes運用を標準化したい情シス	プラットフォームチームがある組織

12. スケーリングと監視：Automaticは入口を整えてくれるが、設計は必要

Microsoft公式では、AKS AutomaticではHPA、KEDA、VPAなどのスケーリングツールが事前構成されるため、チームはセットアップ、テスト、メンテナンスコストを負わずに済む一方、AKS Standardでは各機能に手動構成と継続的なチューニングが必要と説明されています。また、AKS AutomaticではManaged PrometheusとContainer Insightsが既定で有効になり、AKS Standardでは可観測性を個別に設定すると説明されています。

表10：スケーリング・監視の運用比較

項目	AKS Automatic	AKS Standard
HPA	事前構成	手動構成
KEDA	事前構成・有効	アドオンを手動導入・構成
VPA	事前構成・有効	手動有効化・構成
Managed Prometheus	既定で有効	個別設定
Container Insights	既定で有効	個別設定
情シスの主な責任	閾値・アラート・業務影響確認	機能有効化から設計・運用まで

13. アップグレード責任：Automaticは楽だが、承認設計は必要

AKS Automaticでは、クラスターアップグレードがstableチャネルを使うよう事前構成され、マイナーバージョンN-1の最新パッチへ自動アップグレードされます。特定のメンテナンス要件がある場合は、計画メンテナンス期間を設定できます。AKS Standardでは、要件に応じてアップグレードチャネルを選択する必要があります。

表11：アップグレード運用の比較

項目	AKS Automatic	AKS Standard
クラスターアップグレード	stableチャネルで事前構成	チャネル選定が必要
運用負荷	低い	高い
変更管理	メンテナンス期間・影響確認が重要	承認・検証・実行手順が重要
監査説明	「Azureの事前構成に従う」説明が中心	「自社で選んだ設定」の説明が中心
リスク	自動化の影響を見落とす	手動管理漏れ・遅れ

図8：アップグレード運用の責任範囲

AKS Automatic
────────────────────
Azureの事前構成
  ↓
自動アップグレード
  ↓
情シスは影響確認・メンテナンス期間・事後確認を管理


AKS Standard
────────────────────
情シスがチャネル・周期・承認を設計
  ↓
検証環境で確認
  ↓
本番承認
  ↓
実行・監視・証跡保管

14. Kubernetesバージョン管理を甘く見ない

AKSでは、KubernetesのGAマイナーバージョンについて、最新のGAバージョンNと、以前の2つのマイナーバージョンN-1、N-2がサポートされるとMicrosoft公式に記載されています。また、Kubernetes 1.19以降では、サポートされるバージョンを利用し続けるために、1年に1回以上アップグレードできるようにする必要があると説明されています。 

表12：バージョン管理で台帳化すべき項目

項目	記録内容
クラスター名	AKSクラスター名
モード	Automatic / Standard
Kubernetesバージョン	現在のバージョン
サポート状態	N / N-1 / N-2 / サポート外
アップグレード方針	自動 / 手動 / 承認制
メンテナンス期間	曜日・時間帯
検証環境	事前検証の有無
承認者	情シス責任者、アプリ責任者等
影響確認	API、Ingress、DB、認証、監視
事後確認	ログ、メトリック、問い合わせ状況

15. 運用責任分界表

表13：AKS Automatic / AKS Standard / 利用企業の責任整理

領域	AKS Automatic	AKS Standard	情シスが説明すべきこと
コントロールプレーン	Azure管理	Azure管理	SLA、リージョン、障害時連絡経路
システムノード	Azure管理寄り	自社管理寄り	誰がノード設計を持つか
ユーザーノード	自動化	自社設計	VM/SKU/容量の根拠
ネットワーク	標準化・制限あり	詳細制御	VNet、DNS、FW、Private Endpoint
監視	既定有効の機能あり	明示設定	何を監視し、誰が見るか
セキュリティ	既定値が強い	自社構成	RBAC、Policy、Image、Secrets
アップグレード	自動化寄り	自社制御	メンテナンス期間と承認
ワークロード	自社責任	自社責任	Manifest、Probe、PDB、Replica
監査証跡	標準証跡＋台帳	詳細証跡＋台帳	変更理由・承認・結果

16. 情シスが経営層へ説明すべきポイント

経営層に対しては、技術詳細よりも「リスクと責任」を説明する必要があります。

図9：経営層向け説明図

AKSを選ぶ
  ↓
Kubernetes運用責任が発生
  ↓
AutomaticならAzureの自動化を活用して運用負荷を下げる
  ↓
Standardなら自由度を得る代わりに自社責任が増える
  ↓
選定理由・責任分界・承認証跡を残す

表14：経営層向け説明表

経営層が知るべきこと	説明内容
Automaticを選ぶ意味	標準化・自動化により運用リスクを下げる選択
Standardを選ぶ意味	自由度を得る代わりに、情シスの運用責任が増える選択
コストの見方	VM費用だけでなく、設計・監視・障害対応・監査対応の人件費も含める
監査対応	モード選定理由、責任分界、アップグレード方針、承認記録が必要
障害対応	どこまでAzure、どこから自社責任かを事前に整理する

17. 選定台帳テンプレート

AKSの選定は、会議で「Automaticでよさそう」「Standardの方が自由」という話で終わらせてはいけません。監査・事故対応・後任引継ぎのために、選定理由を台帳化する必要があります。

表15：AKS選定台帳

項目	記入例
選定番号	AKS-SEL-2026-001
対象システム	顧客向けWeb API基盤
対象環境	本番 / 検証 / 開発
選定モード	AKS Automatic
選定理由	標準的なWeb APIで、Windowsノード・Dapr・Azure ML拡張不要。運用負荷低減を優先
不採用モード	AKS Standard
不採用理由	現時点で詳細なノード制御・カスタムCNI要件なし
必須要件	SLA、監視、Workload Identity、Private Access
制約確認	Windowsノード不要、Dapr不要、Azure ML拡張不要
ネットワーク	マネージドVNet / カスタムVNet
アップグレード方針	Automaticのstableチャネル、計画メンテナンス期間設定
監視	Managed Prometheus、Container Insights
セキュリティ	Azure RBAC、Workload Identity、OIDC、Policy
例外事項	なし
承認者	情シス責任者、システムオーナー
見直し時期	半年ごと、または要件変更時

18. 変更管理規程に入れるべき条項

NIST SP 800-128は、情報セキュリティが組織全体の構成管理に不可欠であることを前提とし、セキュリティ重視の構成管理を説明しています。クラウド基盤のモード選定、構成変更、アップグレード、監視設定は、技術作業ではなく、構成管理・変更管理・リスク管理の対象として扱うべきです。

規程文サンプル

第○条（AKSクラスター モードの選定）

1. Azure Kubernetes Serviceを利用する場合、対象システムの業務要件、
   セキュリティ要件、監査要件、ネットワーク要件、運用体制を確認し、
   AKS AutomaticまたはAKS Standardのいずれを採用するかを事前に選定する。

2. AKS Automaticを採用する場合は、Azureによる事前構成・自動化の範囲と、
   自社が引き続き責任を負うワークロード、権限、監視、変更管理、
   監査証跡の範囲を明確にする。

3. AKS Standardを採用する場合は、ノードプール、ネットワーク、
   アップグレード、セキュリティ機能、監視、ポリシー設定について、
   自社が設計・管理・証跡保管を行う範囲を明確にする。

4. Windowsノード、Dapr拡張、Azure Machine Learning拡張、特殊なネットワーク構成、
   厳格な監査要件その他の制約がある場合は、AKS Automaticの制限事項を確認し、
   必要に応じてAKS Standardを選定する。

5. 選定結果、選定理由、不採用理由、承認者、見直し時期は、
   AKS選定台帳に記録し、所定期間保管する。

19. リリース・運用手順に入れるべき内容

表16：AKS運用手順書に入れるべき項目

項目	Automatic	Standard
クラスター作成手順	公式既定値の確認	詳細パラメーター設計
ネットワーク	標準構成・制約確認	VNet、CNI、DNS、FW設計
ノード設計	NAP前提	ノードプール、SKU、ゾーン設計
監視	既定機能の確認	Container Insights等の有効化
セキュリティ	既定有効機能の確認	Policy、RBAC、Workload Identity設定
アップグレード	stableチャネル、メンテナンス期間	チャネル、承認、検証手順
障害対応	Azure側・自社側の切り分け	自社設定範囲の切り分け
証跡保管	選定台帳、Activity Log、Pipeline	IaC、承認、変更履歴、監査資料

20. 監査で問われる質問

表17：監査質問と回答準備

監査で問われること	準備すべき証跡
なぜAKS Automaticを選んだのか	選定台帳、要件比較表
なぜAKS Standardを選んだのか	特殊要件、制約確認、承認記録
WindowsノードやDapr要件は確認したか	制約チェックシート
アップグレードは誰が管理するのか	アップグレード方針、メンテナンス予定
セキュリティ設定は誰が確認するのか	RBAC設計、Policy、監査ログ
監視は誰が見るのか	アラート一覧、運用当番表
障害時の責任分界はあるか	責任分界表、連絡フロー
例外はどう承認するのか	例外管理台帳
選定を見直すタイミングはあるか	定期レビュー記録

21. 例外管理：Automaticを選んだ後に特殊要件が出た場合

AKS AutomaticとAKSベースSKU間の移行はサポートされていないため、最初の選定で将来要件を見落とすと、後から設計変更が重くなる可能性があります。

表18：例外管理台帳

項目	記入例
例外番号	AKS-EX-2026-001
発生日	2026-07-08
対象クラスター	aks-prod-api
現在のモード	AKS Automatic
発生した要件	Dapr拡張の利用検討
制約	AKS AutomaticではDapr拡張非対応
対応案	代替設計 / AKS Standard再構築 / Container Apps検討
影響範囲	開発、運用、監査、コスト、移行期間
承認者	情シス責任者、事業責任者
期限	2026-08-31
最終判断	未定 / 承認済 / 却下

22. コスト判断：クラウド費用だけで比較しない

AKSの費用比較では、VMやSLAだけで判断してはいけません。情シスとして見るべきは、総運用コストです。

表19：総運用コストの見方

コスト項目	Automatic	Standard
クラスター設計	低め	高め
ネットワーク設計	標準中心	詳細設計が必要
ノード運用	自動化	自社運用
監視設計	既定値を活用	自社構成
セキュリティ設計	既定値を活用	自社構成
障害対応	切り分け中心	設計範囲が広い
監査対応	標準説明中心	詳細説明中心
人件費	下げやすい	上がりやすい
自由度	制限あり	高い

23. 実務判断マトリクス

表20：最終判断マトリクス

条件	推奨
新規システム、標準的Web/API、Linux中心、少人数情シス	AKS Automatic
Kubernetes運用をこれから始める	AKS Automatic
監視・セキュリティの設定漏れを減らしたい	AKS Automatic
Windowsコンテナーが必要	AKS Standard
Dapr拡張が必要	AKS Standard
Azure ML拡張が必要	AKS Standard
既存のKubernetes運用標準がある	AKS Standard
厳格なネットワーク分離・CNI設計が必要	AKS Standard
規制・監査上、全構成を自社で説明したい	AKS Standard
将来要件が未確定	Automatic制約を確認し、台帳にリスク記録

24. 山崎行政書士事務所としての支援領域

AKSの選定は、単なるAzure技術の話ではありません。本番環境でKubernetesを採用する以上、そこには、運用責任、監査証跡、変更管理、セキュリティ統制、委託先管理、社内規程、経営説明が関係します。

山崎行政書士事務所では、Azure技術支援とクラウド法務・ガバナンス支援を一体で行います。

表21：支援できる内容

領域	支援内容
Azure技術支援	AKS Automatic / Standard選定、構成レビュー、運用設計
ネットワーク設計支援	VNet、Private Endpoint、DNS、FW、Ingress整理
セキュリティ支援	Entra ID、Workload Identity、RBAC、Policy、ゼロトラスト観点
監視設計	Azure Monitor、Container Insights、Managed Prometheus、アラート設計
変更管理	AKS選定台帳、変更申請、承認証跡、例外管理
規程整備	クラウド利用規程、AKS運用規程、リリース管理規程
監査対応	責任分界表、運用証跡、経営層向け説明資料
契約関連資料	クラウド利用、委託先管理、責任分界整理

行政書士業務の範囲を踏まえ、個別紛争対応や訴訟代理など弁護士領域に属する事項は切り分けたうえで、企業がクラウドを安全に活用するための規程整備、契約関連資料、監査説明資料、運用ルール整備を支援します。

25. まとめ

AKS AutomaticとAKS Standardの選定は、機能比較だけで決めるものではありません。

重要なのは、自動化によって安全性と運用効率を取るのか個別制御によって自由度と厳格な統制を取るのかという判断です。

一般的な本番ワークロード、新規導入、少人数情シス、標準的なWeb/API基盤であれば、AKS Automaticを第一候補にする価値があります。一方、Windowsノード、Dapr、Azure Machine Learning拡張、特殊ネットワーク、厳格な監査統制、既存のプラットフォーム標準がある場合は、AKS Standardを選ぶべき場面があります。

AKS選定で最も危険なのは、「なんとなくAutomatic」「自由度が高そうだからStandard」という判断です。

情シスが本当に行うべきことは、選定理由、責任分界、運用体制、承認証跡、見直し条件を台帳化することです。

AKS Automatic / AKS Standardの選定、運用責任の整理、変更管理規程、リリース手順、監査対応資料の整備は、山崎行政書士事務所へご相談ください。

出典・確認日

確認日：2026年7月8日

出典	確認した主な内容	最終更新日
Microsoft Learn：Azure Kubernetes Serviceとは	AKS AutomaticとAKS Standardの位置付け、推奨用途、機能比較	2026年6月4日
Microsoft Learn：AKS Automaticの概要	Pod readiness SLA、アップタイムSLA、Automaticの事前構成	2026年6月23日
Microsoft Learn：AKSの設計と運用を計画する	ほとんどの運用ワークロードではAutomatic、特殊要件ではStandard	2026年6月30日
Microsoft Learn：マネージド システム ノード プールを使用したAKS Automatic	Automaticの制限、Windowsノード非対応、Dapr/Azure ML拡張非対応、移行非対応	2026年6月2日
Microsoft Learn：AKS価格レベル	Standard/PremiumのアップタイムSLA、AutomaticのStandardレベル事前構成	2026年7月6日
Microsoft Learn：AKSクラスターの自動アップグレード	Automaticのstableチャネル事前構成、Standardのチャネル選択	2026年6月27日
Microsoft Learn：ノード自動プロビジョニング	NAPの仕組み、Automaticでは事前構成、Standardでは明示構成	2026年6月25日
Microsoft Learn：AKSコスト最適化	HPA/KEDA/VPA、Managed Prometheus、Container Insightsの違い	2026年6月25日
Microsoft Learn：AKS信頼性ベストプラクティス	Automaticでもワークロード側のプローブ、レプリカ、PDB等が必要	2026年6月11日
Microsoft Learn：AKSでサポートされるKubernetesバージョン	N、N-1、N-2のサポート、サポート継続とアップグレード	2026年6月17日
NIST SP 800-128	セキュリティ重視の構成管理、変更管理の考え方	2019年10月10日更新