Microsoftが2026年5月18日、米ミネアポリスで開催されたOpen Source Summit North America 2026で「Azure Linux 4」を発表し、ソースコードをGitHubでMITライセンス公開しました（出典: gihyo.jp）。これまで独自寄りだったAzure LinuxがFedoraベースに大きく舵を切ったかたちで、AKS（Azure Kubernetes Service）のノード基盤としてどう向き合うかが、クラウド運用者にとって直近の検討事項になります。
本記事では、AKSのノードOS選定を運用する側の視点から、Azure Linux 4の位置づけと現場での向き合い方を整理します。先に結論を書くと、2026年5月時点のAKSデフォルトはAzure Linux 3.0のままで、Azure Linux 4はまだVMプレビュー＋Azure Container Linux（ACL）のGA予告の段階です。慌てて差し替える話ではなく、半年から1年スパンの移行計画として静かに準備しておくのが現実解になります。
Azure Linux 4はなにが変わったのか
従来のAzure Linux（旧称CBL-Mariner）は、Microsoftが社内インフラ向けに独自開発してきた要素が強いディストリビューションでした。Azure Linux 3まではこの色合いを残しつつ、AKSのノードOSや一部のAzureサービスで使われてきました。
Azure Linux 4で大きく変わったのは、ベースがFedora Linuxへと切り替わった点です。これはRHEL（Red Hat Enterprise Linux）系の上流に近い場所に位置取りを変えたことを意味します。アップストリームのコミュニティに乗ることで、パッケージの追従や脆弱性対応の速度を上げ、エコシステム全体の知見を取り込みやすくする狙いがあります。
具体的な技術ポイントは次のとおりです。
- ベース: Fedora Linux（gihyo.jpが明記）。これによりdnf／rpmベースのパッケージ管理が前提に
- ライセンス: MITライセンス（GitHubで公開）
- リポジトリ: github.com/microsoft/azurelinux の 4.0 ブランチ
- 発表の場: Open Source Summit North America 2026（2026年5月18～20日、米ミネアポリス）
- 現時点のステータス: VM向けはプレビュー受付中。Azure Container Linux（ACL）はGA予告
記事執筆時点（2026年5月）の重要な注意として、AKSの公式ドキュメント上ではまだAzure Linux 4が標準のノードイメージとして提供されているわけではありません。Microsoft LearnのSupported Kubernetes Versions in AKSを見ると、`–os-sku AzureLinux`を指定したKubernetes 1.32以降のクラスターはAzure Linux 3.0がデフォルトです。「Azure Linux 4が発表されたから即移行」という段階ではないということは押さえておく必要があります。
AKSノード基盤の現在地と選択肢
Azure Linux 4を語る前に、いまAKSノード基盤がどんな状態にあるかを整理しておきます。これを理解しておかないと、移行の優先順位を見誤ります。
2026年5月時点のAKSノードOS選択肢は、おおむね次の表のとおりです。
| OS SKU | デフォルト適用バージョン | 位置づけ | 運用者視点の注意 |
|---|---|---|---|
| Ubuntu 22.04 | Kubernetes 1.25～1.34 | 長年のAKSデフォルト | 採用実績が最も豊富。社内ナレッジを流用しやすい |
| Ubuntu 24.04 | Kubernetes 1.35以降 | 新規クラスターでの新デフォルト候補 | 1.35到達クラスターから自動で24.04側に寄せる必要 |
| Azure Linux 3.0 | `–os-sku AzureLinux`指定時の現行 | Microsoft自製・軽量寄り | 2026年5月時点でAzure Linux系のAKSデフォルト |
| Azure Linux 2.0 | サポート終了 | 退役済み | 2025-11-30サポート終了。2026-03-31以降ノードイメージ削除 |
| Azure Linux 4.0 | 未定（VMプレビュー段階） | Fedoraベースへの転換 | AKSデフォルト化はまだ。ACL GA待ち |
| Windows Server | Kubernetes対応バージョン | Windowsコンテナワークロード向け | 節度を持ってノードプール分離 |
Azure Linux 2.0は2025年11月末でサポート終了済み、2026年3月末以降はノードイメージ自体が消えていく流れです。まだ2.0を残しているクラスターがあれば、Azure Linux 4を待つ前に3.0かUbuntuへ退避するのが先決です。これは速報ではなくTo-Doとして放置しないことが重要です。
Fedoraベースへの転換が現場運用にもたらす変化
Azure Linux 4でベースがFedoraに切り替わったことは、運用者にとって地味ながら根本的な変化です。これまでパッケージ管理やSELinux周り、systemd周辺の挙動など、Microsoft独自色が残っていた部分が、RHEL/Fedoraエコシステムの「標準的な振る舞い」に寄っていくことが期待できます。
具体的に何が変わりそうかを、運用者の関心領域ごとに整理します。
パッケージ管理の面では、apt系のUbuntuと違い、dnf／rpmベースに統一されます。RHELやAlma Linux、Rocky Linuxを社内で扱ってきたチームには馴染みやすい一方、Ubuntuしか扱っていなかったチームには学習コストが発生します。
セキュリティ追従の面では、Fedoraの上流に近づくことでCVE対応のサイクルが見えやすくなる可能性があります。これまではMicrosoftのリリースサイクルに依存していた部分が、コミュニティの動きと連動するため、自社の脆弱性管理プロセスにも変化が出ます。
コンテナランタイム周りについては、containerdベースである点は変わらないものの、Fedoraの新しいカーネル機能やcgroup v2の扱いがより素直になることが見込まれます。kubeletの設定やリソース制御の挙動を、Fedora／RHELの一般的なドキュメントと突き合わせやすくなるのは現場として助かるポイントです。
PR
Docker／Kubernetes実践コンテナ開発入門 改訂新版（山田明憲 著・技術評論社）
AKSやEKS、ECSをまたいだコンテナ運用の基礎を一冊で押さえられる定番書の改訂版です。Azure Linux 4世代を見据えてAKSノード基盤を再評価するなら、まず手元に置いておきたい構成になっています。
AKSノード基盤交代のシナリオを描く
Azure Linux 4が将来AKSノード基盤として正式提供される前提で、運用者が今から準備しておくべきシナリオを3つの視点で整理します。
第1の視点は、現在のノードOS構成を棚卸しすることです。クラスターごとに`az aks nodepool list`で`–os-sku`と`–orchestrator-version`を確認し、Azure Linux 2.0が残っていないか、Ubuntu 22.04→24.04の切り替えがどのタイミングで来るかを見える化します。これをやっておかないと、Azure Linux 4登場時に「どこから手を付ければよいか」が判断できません。
第2の視点は、ノードOSに依存するカスタマイズを洗い出すことです。DaemonSetやkubeletのカスタム設定、ホスト側のpackageインストール、SELinuxの調整など、ノードOSに密結合した運用がある場合は、それらがFedoraベースで素直に動くかを事前に検証する必要があります。Azure Linux 3とAzure Linux 4でパッケージ名や挙動が変わる箇所が必ず出てくるので、ステージング環境での突合は欠かせません。
第3の視点は、ノードプール単位での段階移行を前提に置くことです。AKSはノードプールごとにOS SKUを変えられるので、本番クラスター全体を一気に切り替える必要はありません。新規アプリケーションを乗せる新しいノードプールでAzure Linux 4を試し、評価が固まってから既存ワークロードを順次移していくのが、リスクを最小化する筋道になります。
マルチクラウド運用への波及
Azure Linux 4のFedoraベース化は、Azure閉じた話に見えて、実はマルチクラウド運用の風景にも影響します。なぜなら、AWS／GCP／Azureを横断するチームでは、ノードOSの違いが運用負荷の主因のひとつだからです。
AWSのEKSではAmazon Linux 2023、GCPのGKEではContainer-Optimized OS（COS）、AzureのAKSではUbuntu／Azure Linuxという構図でしたが、Azure Linux 4がFedora／RHEL系の上流に揃ったことで、Amazon Linux 2023（Fedoraベース）との親和性が増します。これは「マルチクラウドだけど、Linuxレイヤの知見はある程度共通化できる」方向に世界が動いていることを意味します。
マルチクラウド観点で押さえるべきポイントを表にします。
| クラウド／サービス | 標準ノードOS | ベース系統 | 運用者の知見流用度 |
|---|---|---|---|
| AKS（Azure） | Ubuntu 22.04／24.04, Azure Linux 3 | Debian系／Fedora系 | Azure Linux 4でFedora系統に寄る |
| EKS（AWS） | Amazon Linux 2023 | Fedora系 | Azure Linux 4との親和性が高くなる |
| GKE（GCP） | Container-Optimized OS（COS） | Chromium OSベース／独自 | 独自路線、ノードOSをいじりにくい設計 |
| オンプレKubernetes | Ubuntu／RHEL／Alma／Rocky等 | 多様 | RHEL系ナレッジが幅広く流用可 |
マルチクラウドを運用しているチームは、Azure Linux 4の登場を「Linuxレイヤの社内標準を見直すきっかけ」として捉えるとよいでしょう。EKSとAKSでパッケージ管理コマンドが揃う方向に動くなら、社内のRunbookやAnsible Playbook、監視エージェントのレシピも統合しやすくなります。
移行検証チェックリスト
Azure Linux 4をAKSで採用するかどうかを判断するにあたって、社内で押さえておくべきチェック項目を整理します。これらは現時点の情報だけでも進められる準備項目です。
- 現行AKSクラスターのノードOS構成（os-sku、kubernetes-version、image-version）を棚卸ししたか
- Azure Linux 2.0残存ノードプールがある場合、Azure Linux 3もしくはUbuntu LTSへ退避済みか
- ノードOSに依存するDaemonSet（ログ収集、監視、セキュリティ）がある場合、Fedoraベースでの動作確認手順を用意したか
- パッケージ管理系のIaCコード（cloud-init／custom data等）にapt系コマンドが残っていないか
- SELinuxのenforce／permissiveを想定した社内ポリシーが整理されているか
- 新規ノードプールでAzure Linux 4プレビューを試すための検証クラスター予算を確保したか
- Azure Container Linux（ACL）GA時期と、自社のクラスターアップグレード計画の擦り合わせが済んでいるか
- マルチクラウド運用の場合、Amazon Linux 2023との運用統合可能性を技術ロードマップに記載したか
このチェックリストを四半期ごとのインフラ運用レビューに組み込んでおくと、AKSノード基盤の更新が遅れて手戻りが発生するリスクを下げられます。
セキュリティとサプライチェーンの観点
Azure Linux 4がFedoraベースに切り替わったことで、サプライチェーンセキュリティの観点でも変化があります。これまでMicrosoft独自の閉じたパッケージ群だった部分が、Fedoraの上流コミュニティと連動する形になるためです。
この変化はメリットとデメリットの両面があります。メリットは、CVE情報の流通速度がコミュニティと足並みを揃えやすくなること、SBOM（Software Bill of Materials）の整備がFedora系のツールチェーンを使えること、そして社内の脆弱性管理プロセスが他のRHEL系OSと共通化しやすくなることです。
デメリット側は、上流の影響範囲が広がる分、過去にMicrosoft閉じた問題ではなかったCVEが新たに自社の管理対象に入ってくる点です。F5の侵害事例のように、Linux系統を狙うサプライチェーン攻撃の話題は2026年に入って増えており、AKSノードOSの選定もこの文脈で見直す時期にきています（参考: ITmedia「Microsoft、F5侵害からActive Directory攻撃に発展した多段侵入事例を公開」）。
当ブログでは、Azure Linux 4のFedoraベース化そのものの背景や、Linuxディストリビューションの系統比較については、リナックスマスター.JP側の「Azure Linux 4.0登場｜Microsoftが本気で出した汎用LinuxとFedora系統」で別角度から整理しています。Linux系統論として読みたい方はそちらも参照してください。
FAQ
Q1: Azure Linux 4はいまAKSで使えますか？
A: 2026年5月時点では、Azure Linux 4はVM向けプレビューおよびAzure Container Linux（ACL）のGA予告段階です。AKSノード基盤としてのデフォルト提供にはまだ至っていません。AKSで`–os-sku AzureLinux`を指定すると現状はAzure Linux 3.0が選ばれます。
Q2: いまAzure Linux 2.0を使っているクラスターはどうすればよいですか？
A: Azure Linux 2.0は2025年11月30日でサポート終了済みで、2026年3月31日以降はノードイメージが削除されます。Azure Linux 4を待つ前に、Azure Linux 3.0かUbuntu LTSに必ず退避してください。これは速報を待たずに進めるべきタスクです。
Q3: UbuntuベースのAKSノードプールはどうなりますか？
A: Ubuntu系は引き続きAKSの主力ノードOSとして提供されます。Kubernetes 1.35以降はUbuntu 24.04がデフォルトです。Ubuntu系の運用を続ける選択も、Azure Linuxへ寄せる選択も、両方が現実的な選択肢として残ります。
Q4: Azure Linux 4を採用するメリットは何ですか？
A: Fedora上流に乗ることで、CVE対応や新カーネル機能の取り込みが速くなる可能性があります。また、EKSのAmazon Linux 2023もFedora系統なので、マルチクラウド運用のRunbook統合がしやすくなります。一方で、Ubuntuで蓄積したapt系ナレッジは流用しづらくなる面があります。
Q5: ノードOS切り替えで気をつけるべき技術的なポイントは？
A: 主なチェック項目は、(1) DaemonSetのコンテナイメージがFedoraベースのカーネルと互換性があるか、(2) ホストOSに直接パッケージを入れているIaCコードがapt依存になっていないか、(3) SELinuxのモードが社内ポリシーと合致するか、(4) ログ収集や監視エージェントが新OSで動作確認済みか、の4点です。
Q6: Open Source SummitでのMicrosoftの発表は他に何がありましたか？
A: Azure Linux 4のソースコード公開と並んで、Azure Container Linux（ACL）のGA予告が主な発表です。ACLはコンテナ実行に特化した軽量Linuxの方向性で、Azure Linux 4本体とは別系統として位置づけられています。両者を混同しないように整理しておくのが運用設計上の出発点です。
Q7: マルチクラウド運用でAzure Linux 4とAmazon Linux 2023を統合管理する場合のポイントは？
A: 両者ともFedora系統なので、dnf／rpmコマンド、systemd周辺、SELinuxの取り扱いに関する社内Runbookを共通化しやすくなります。一方で、AWS／Azureそれぞれの認証統合、ノードグループのスケーリング設定、ログ転送経路は依然としてクラウド固有なので、Linuxレイヤの統合とクラウド層の運用設計は分けて考える必要があります。
運用者として2026年下半期に向けて備えること
Azure Linux 4は、Microsoftが「独自ディストリビューションを維持する」のではなく「コミュニティに乗る」方向へ静かに舵を切った象徴的な動きです。AKSのノード基盤交代は1日2日で進む話ではなく、半年から1年単位で起こる地殻変動として捉えるのが妥当です。
運用者として2026年下半期に向けてやっておくことは、3点に絞れます。1点目はAzure Linux 2.0の完全退避を確実に終わらせること。2点目は新規ノードプールでのAzure Linux 4プレビュー検証を四半期計画に組み込むこと。3点目はマルチクラウドのLinuxレイヤを共通化する社内標準を整備し直すことです。
クラウドのノードOSは、表に出にくいけれど運用コストと安定性を支える土台です。発表のタイミングで一度立ち止まって自社の現在地を棚卸ししておくと、半年後に慌てなくて済みます。
PR
Kubernetes完全ガイド 第2版（青山真也 著・インプレス）
AKSノードプールの段階移行設計を考えるときに、Kubernetesそのものの仕様まで戻って判断したい場面が必ず出てきます。日本語でここまで深く解説された本はこれが筆頭で、現場の判断軸として手元にあると重宝します。
クラウド実務の最新動向を毎週お届けします。Azure・AWS・GCP横断のFinOps／インフラ運用の現場視点をお求めの方はぜひご登録ください。
