Azure Linux 4.0 公開と Azure Container Linux GA|変更点と移行のポイント

  • URLをコピーしました!
目次

はじめに

2026 年 5 月 18 日、Microsoft は Open Source Summit North America 2026 のキーノートで、サーバ向けの自社 Linux ディストリビューション「Azure Linux 4.0」の Azure Virtual Machines 向けパブリックプレビューと、「Azure Container Linux(ACL)」の一般提供(GA)開始を発表しました。Azure Linux 自体はこれまで AKS(Azure Kubernetes Service)のコンテナホスト用途に限定された存在でしたが、4.0 では Azure 全顧客が VM イメージとして利用できる汎用ディストリビューションへと位置付けが大きく変わります。

「Microsoft が Linux ディストリビューションを出す」というニュースは、AWS の Amazon Linux や Google の Container-Optimized OS と並ぶ動きとしても注目されていますが、インフラを運用する立場では「自社の Azure 環境に何が起き、何を選ぶべきか」という具体的な判断材料の方が重要です。本記事では発表の一次情報を整理した上で、運用観点での評価ポイントを実務目線でまとめます。

この記事でわかること
  • Azure Linux 4.0 と Azure Container Linux の位置付けの違い
  • Fedora ベース・RPM ベースへの転換が持つ意味
  • AKS 向け Azure Linux 3.0 ユーザーの今後の選択肢
  • サポート期間・アップデートポリシーなど運用上の前提
  • Red Hat、Ubuntu など既存ディストリビューションとの関係性

※本記事の情報は 2026 年 5 月時点の公式発表に基づいています。Azure Linux 4.0 はパブリックプレビュー段階であり、GA 時に仕様が変更される場合があります。最新情報は Azure Linux GitHub リポジトリ および Microsoft 公式ブログ をご確認ください。

Azure Linux 4.0 とは|発表の概要と位置づけ

Azure Linux 4.0 は、Microsoft が Azure 向けに最適化したオープンソース Linux ディストリビューションです。今回の発表でポイントとなるのは、これまで AKS 向けコンテナホスト OS として限定提供されていたものが、Azure VM 全般で利用できる汎用ディストリビューションに格上げされる点と、コンテナホスト向けの系統が「Azure Container Linux」として分離・GA 化される点の 2 点です。

Open Source Summit 2026 での発表内容

発表は Microsoft Azure OSS およびクラウドネイティブ部門のコーポレートバイスプレジデント Brendan Burns 氏のキーノート内で行われました。Microsoft 公式ブログでは、Azure Linux 4.0 のパブリックプレビューと Azure Container Linux の GA が、AI ワークロードを支える基盤として位置付けられていることが明示されています。

参考: From open source to agentic systems: Microsoft at Open Source Summit North America 2026
“we’re announcing two updates that strengthen exactly that: the upcoming public preview of Azure Linux 4.0 on Azure Virtual Machines and the general availability of Azure Container Linux, our immutable container-optimized operating system (OS), with the broader rollout at Microsoft Build on June 2.”
(Azure Virtual Machines 上での Azure Linux 4.0 のパブリックプレビュー公開と、イミュータブルなコンテナ最適化 OS である Azure Container Linux の一般提供を発表する。本格的なロールアウトは 6 月 2 日の Microsoft Build で行う。)
https://opensource.microsoft.com/blog/2026/05/18/from-open-source-to-agentic-systems-microsoft-at-open-source-summit-north-america-2026/

Microsoft はあわせて、Azure における Linux の規模感も示しています。

参考: Microsoft Open Source Blog
“more than two-thirds of customer cores in Azure run Linux, and the platforms running Microsoft 365, GitHub, and OpenAI’s ChatGPT all sit on Linux foundations.”
(Azure 上の顧客コアの 2/3 以上が Linux 上で動作しており、Microsoft 365、GitHub、OpenAI の ChatGPT を支える基盤もすべて Linux 上に構築されている。)
https://opensource.microsoft.com/blog/2026/05/18/from-open-source-to-agentic-systems-microsoft-at-open-source-summit-north-america-2026/

「Microsoft は Windows の会社」という従来のイメージとは異なり、現時点で Azure の主要ワークロードは Linux が支えているという事実関係を踏まえると、自社ディストリビューションを汎用 VM 向けに展開する判断は実態に沿ったものといえます。

Azure Linux 4.0 と Azure Container Linux の二本立て

今回の発表で最も重要なのは、Azure 向けの Linux 基盤が 2 系統に整理されたことです。

項目Azure Linux 4.0Azure Container Linux(ACL)
用途汎用 VM イメージ(サーバワークロード全般)コンテナホスト専用(主に AKS)
上流Fedora LinuxFlatcar Container Linux
パッケージ管理RPM ベースパッケージマネージャー非搭載(イミュータブル)
提供形態パブリックプレビュー(サインアップ制)一般提供(GA)
想定する変更パッケージ追加・カーネル選択など柔軟システムパッケージ変更不可(コンテナ内のみ変更可)
提供開始2026 年 5 月 18 日(プレビュー)2026 年 5 月 18 日(GA)

Microsoft の説明によれば、これまで AKS 向けに提供されていた Azure Linux 3.0 のポジションは、今後 Azure Container Linux に置き換わる形になります。

参考: ZDNet — Microsoft releases its first server Linux distribution: Azure Linux 4.0
“we had Azure Linux only available to third-party customers through AKS specifically, and that was Azure Linux 3.0. Going forward, this will be ACL.”
(これまで Azure Linux は AKS を通じてのみサードパーティ顧客に提供されており、それが Azure Linux 3.0 だった。今後それは ACL となる。)
https://www.zdnet.com/article/microsoft-releases-its-first-server-linux-distribution-azure-linux-4-0/

つまり、汎用サーバ向けは Azure Linux 4.0、コンテナホスト用途は ACL という役割分担が明確になったということです。

公開タイミングと今後のスケジュール

現時点で押さえておきたいスケジュール感を整理します。

  • 2026 年 5 月 18 日: Azure Linux 4.0 パブリックプレビューのサインアップ開始、Azure Container Linux が GA
  • 2026 年 6 月 2 日(Microsoft Build): Azure Container Linux の本格ロールアウト
  • WSL イメージ: Azure Linux 4.0 の WSL 版が提供予定(時期は別途アナウンス)

公開時点で Azure Linux 4.0 はまだダウンロード可能なイメージとしては公開されておらず、aka.ms/AzureLinuxForm で早期アクセス用のサインアップが受け付けられています。GA 時期は明示されていませんが、サポート期間や運用方針は次章以降で解説するとおり、すでに一通り固められています。

Azure Linux 4.0 の技術的特徴|Fedora ベースへの転換

Azure Linux 4.0 の最大の技術的変化は、ディストリビューションの上流が Fedora Linux に統一されたことです。前身の CBL-Mariner 系統からの大きな転換であり、Azure 上で Linux を運用するインフラエンジニアが理解しておくべき変更点が複数あります。

Mariner からの系譜と Fedora 派生の意味

Azure Linux の起源は、Microsoft 社内で利用されていた CBL-Mariner(Common Base Linux – Mariner)です。Mariner は Xbox、Azure Kubernetes Service、Azure Arc などのバックエンドで長年使われてきた内部用ディストリビューションで、3.0 で AKS 向けの外部提供が始まり、4.0 で汎用化と Fedora ベースへの移行が同時に実施された形になります。

参考: ZDNet — Microsoft releases its first server Linux distribution: Azure Linux 4.0
“So we’ve been running Azure Linux for many years internally, and we got through to 3.0, and we only allowed it on as a container host on AKS. What we’ve done is make it a general-purpose, so this is all the learnings that we’ve had in the heritage of Mariner.”
(Azure Linux は社内で長年運用されてきた。3.0 までは AKS のコンテナホスト用途に限っていたが、今回それを汎用化した。これは Mariner の系譜で蓄積された学びの集大成である。)
https://www.zdnet.com/article/microsoft-releases-its-first-server-linux-distribution-azure-linux-4-0/

Fedora ベースへの移行は、RPM エコシステムの恩恵を受けつつ、Microsoft 独自のパッケージキュレーションを Azure 向けに行う戦略の現れです。Azure Linux 4.0 の GitHub リポジトリ(microsoft/azurelinux)の説明でも、Fedora を上流とする位置付けが明示されており、Azure Linux 自体は Fedora 上に TOML 設定ファイルとオーバーレイを適用する形で構築されています。

RPM ベース・MIT ライセンス・GitHub 公開

Azure Linux 4.0 は完全なオープンソースとして公開されます。Microsoft 公式の説明は次のとおりです。

参考: ZDNet — Microsoft releases its first server Linux distribution: Azure Linux 4.0
“we made a decision to use Fedora as an upstream, so it’s using RPMs in the Fedora ecosystem. Microsoft curates the packages and the supply chain to fit Azure’s cloud platform.”
(Fedora を上流として採用し、Fedora エコシステムの RPM を利用する。Microsoft は Azure クラウドプラットフォームに合わせてパッケージとサプライチェーンをキュレーションする。)
https://www.zdnet.com/article/microsoft-releases-its-first-server-linux-distribution-azure-linux-4-0/

ライセンスは MIT ライセンス(個別パッケージはそれぞれの spec ファイルに従う)で、ソースコードは GitHub の microsoft/azurelinux リポジトリの 4.0 ブランチに置かれています。これは Red Hat Enterprise Linux のように一部が非公開・有償サブスクリプション制になっているわけではなく、Fedora と同様にコードを誰でも閲覧・取得できるモデルである点が重要です。

なお、現時点(2026 年 5 月)では 3.0.20260510 がリポジトリ上の最新リリースとしてマークされており、4.0 のバイナリイメージはまだプレビュー段階にあります。実環境への投入はパブリックプレビューの安定状況を見極めてから判断するのが現実的です。

Python 3.12、pylock などパッケージ構成の注目点

Azure Linux 4.0 では、システム標準の Python が Python 3.12 となり、新しいサンドボックス機能 pylock が含まれます。pylock は Python のプロジェクトごとに分離された mount namespace 内で仮想環境を作成する仕組みで、共有ホスト上で複数の Python アプリケーションを動かす際の依存関係の混在を防ぐことを意図したものです。

また、Microsoft は Fedora ELN SIG(Enterprise Linux Next Special Interest Group)の場で x86-64-v3 命令セット向けにパッケージをビルドする提案を Fedora 45 に対して行っており、Azure Linux 4.0 のパフォーマンス最適化と密接に結びついています。x86-64-v3 は 2013 年以降の比較的新しい CPU(AVX2 など)を前提とする ABI で、より新しい命令を活用できるぶん性能面で有利ですが、古い CPU では動作しない点に注意が必要です。

Azure 向けのカーネル・サプライチェーン最適化

Azure Linux 4.0 のカーネルは Azure インフラ専用にキュレーションされたものが採用されます。Microsoft 側の説明では、サプライチェーン全体を Microsoft が管理することを価値として打ち出しています。

参考: ZDNet — Microsoft releases its first server Linux distribution: Azure Linux 4.0
“because we are taking care of the supply chain of all the pieces to build the distribution, we have minimal surface area of the packages, curated kernel, and customizations for running on Azure to support all the hardware, and we also have best-in-class security.”
(ディストリビューション構築に関わるサプライチェーン全体を自社で管理しているため、パッケージの攻撃面を最小化し、Azure 上の全ハードウェアをサポートするためにキュレーションされたカーネルとカスタマイズを提供できる。)
https://www.zdnet.com/article/microsoft-releases-its-first-server-linux-distribution-azure-linux-4-0/

サプライチェーンセキュリティは、近年 Linux カーネルの脆弱性報告数が増加していることも背景にあります。カーネル CVE への対応と AI ワークロード基盤としての信頼性を両立させるためには、ディストリビューターが上流からビルド成果物まで一貫して管理することの重要性が増しているという文脈です。Linux カーネルの脆弱性対応の難しさについては、関連記事「Dirty Frag CVE-2026-43284 の解説」も参照ください。

Azure Container Linux(ACL)とは|AKS 向けのイミュータブル OS

Azure Container Linux は、Azure Linux 4.0 と同時に発表されたもう一つの Linux 基盤で、コンテナホスト専用に最適化されたイミュータブル OS です。Azure Linux 4.0 が汎用 VM 向けに位置付けられるのに対し、ACL は AKS をはじめとするコンテナワークロードに特化しており、設計思想も大きく異なります。

Flatcar Container Linux のプロダクト化

ACL のベースは、CNCF プロジェクトでもある Flatcar Container Linux です。Flatcar はもともと CoreOS Container Linux の後継として Kinvolk が開発を進めていたディストリビューションで、Microsoft が Kinvolk を 2021 年に買収して以降、Microsoft の管理下で開発が継続されてきました。

参考: ZDNet — Microsoft releases its first server Linux distribution: Azure Linux 4.0
“purpose-built, immutable, secure by default, production-ready operating system, and Azure Container Linux is the productization of that, but we’re still investing in the upstream Flatcar ecosystem and pulling that downstream into a productized exterior experience just for container workloads, so it’s a container hosting in AKS.”
(目的特化型でイミュータブル、デフォルトでセキュア、プロダクションレディな OS であり、Azure Container Linux はそれを製品化したもの。引き続き上流の Flatcar エコシステムにも投資し、その成果を下流に取り込んでコンテナワークロード専用の製品体験として提供する。AKS のコンテナホスティング用途を想定している。)
https://www.zdnet.com/article/microsoft-releases-its-first-server-linux-distribution-azure-linux-4-0/

Flatcar 自体は引き続き上流のオープンソースプロジェクトとして維持され、ACL はその下流のプロダクト版という位置付けになります。Bottlerocket(AWS)や Talos Linux など、コンテナホスト専用 OS のエコシステムに Microsoft が正式参入する形と理解しておくと整理しやすいです。

イミュータブル設計とパッケージマネージャー非搭載の意味

ACL の最大の特徴は、システムレベルでのパッケージ変更を許容しないイミュータブル設計です。

参考: ZDNet — Microsoft releases its first server Linux distribution: Azure Linux 4.0
“Everything’s baked in, so there is no package manager. We bake the bits into the immutable, and they’re in the immutable version. So Azure Container Linux is the immutable version. So you shouldn’t be changing any system packages or any application packages. Anything that you need to change is customer workloads run in containers.”
(すべてが組み込まれているためパッケージマネージャーは存在しない。バイナリはイミュータブルなイメージに焼き込まれており、Azure Container Linux はそのイミュータブル版である。システムパッケージもアプリケーションパッケージも変更すべきではない。変更が必要なものはすべてコンテナ内で動くユーザーワークロードとして扱う。)
https://www.zdnet.com/article/microsoft-releases-its-first-server-linux-distribution-azure-linux-4-0/

実運用での意味合いをまとめると次のとおりです。

  • yum / dnf / apt などのパッケージマネージャーは利用できない
  • OS イメージは丸ごと更新する方式(A/B パーティション切り替え型の更新)
  • 設定変更や追加バイナリの導入は、すべてコンテナ側で行う
  • ホスト OS は実質「Kubernetes ノードを動かす最小限の基盤」として扱う

従来の汎用 Linux に慣れている運用者にとっては、「ホストに SSH で入って yum install する」という習慣そのものを切り替える必要があります。一方で、ノード OS の構成ドリフトが構造的に発生しないこと、攻撃面が最小化されることは、大規模なクラスタ運用ではメリットとして大きい設計です。

Azure Linux 3.0 from AKS から ACL への位置付け変更

これまで AKS のノード OS として Azure Linux 3.0 を選択していた利用者の今後の選択肢は、Azure Container Linux への移行が想定される流れになります。Azure Linux 3.0 自体は今後一定期間サポートが継続されますが、Microsoft のプロダクトラインとしては「AKS のノード OS は ACL」「VM 全般は Azure Linux 4.0」という整理に統一されていく方向です。

サポート期間や自動アップグレード方針については次章で詳しく整理します。

想定ユースケースと利用上の注意点

Azure Linux 4.0 と ACL は明確に役割が分かれており、選択を誤ると運用上の制約に直面します。ここでは公式情報から読み取れる想定用途と適用範囲外を整理します。

サーバ用途に最適化|デスクトップ GUI の提供予定なし

Azure Linux 4.0 は VM 向けに汎用化されたものの、デスクトップ用途は明確に想定されていません。Microsoft はこの点について次のように述べています。

参考: ZDNet — Microsoft releases its first server Linux distribution: Azure Linux 4.0
“It’s optimized for server-side in the cloud.”
(クラウド上のサーバサイド用途に最適化されている。)
https://www.zdnet.com/article/microsoft-releases-its-first-server-linux-distribution-azure-linux-4-0/

GUI 環境については「no plans(提供予定なし)」と明言されており、開発者用のローカル環境としても CLI ベースでの利用が前提となります。「サーバ用途最適化」が具体的に何を意味するかというと、おおむね以下のような構成になります。

  • 最小パッケージ構成(不要なデーモンや GUI ライブラリは含まれない)
  • クラウド初期化に必要なコンポーネントは標準搭載(cloud-init、systemd など)
  • Azure メタデータサービスや診断エージェントとの統合
  • 不要なネットワーク機能・サービスの初期無効化

サーバ用途であれば、Azure 上で動かす Web サーバ、アプリケーションサーバ、データベース、Kubernetes ノード、AI 推論ノードなど幅広いケースに対応できる設計です。

WSL イメージによるローカル開発との一貫性

Microsoft は Azure Linux 4.0 を WSL(Windows Subsystem for Linux)イメージとしても提供する計画を明らかにしています。

参考: ZDNet — Microsoft releases its first server Linux distribution: Azure Linux 4.0
“And as of today, we have it as a VM image for your VM host on Azure. We’re going to announce WSL images as well.”
(現時点では Azure 上の VM ホスト向け VM イメージとして提供している。今後 WSL イメージも発表する予定である。)
https://www.zdnet.com/article/microsoft-releases-its-first-server-linux-distribution-azure-linux-4-0/

これは、開発者のローカル環境と Azure 上の本番環境を同一の OS イメージで揃えることを意図したものです。

参考: ZDNet — Microsoft releases its first server Linux distribution: Azure Linux 4.0
“The idea is that we offer you a consistent experience to do your development on your machine, and that you can take your workloads as you develop them on your machine and run them with VS Code. You can run your applications on that, and know that the platform is the same that you’re running on the cloud, so that you have that kind of consistency between environments.”
(開発機上で一貫した開発体験を提供し、開発したワークロードを VS Code でそのまま動かせる。アプリケーションを動かすプラットフォームがクラウド上と同じだと保証されるため、環境間の一貫性が得られる。)
https://www.zdnet.com/article/microsoft-releases-its-first-server-linux-distribution-azure-linux-4-0/

「ローカルで動いたものが本番でも動く」を OS レイヤーで担保する考え方で、コンテナイメージのベース OS を Azure Linux に揃える運用との親和性が高くなります。WSL 上での Linux 操作の基本については、関連記事「Ubuntu ファイルパーミッションの基本」も参照ください。

Red Hat、Ubuntu など既存ディストリビューションとの関係

Azure Linux 4.0 の登場により、Azure 上で既に Red Hat Enterprise Linux や Ubuntu を利用している組織が移行を強制されるかという点について、Microsoft は既存ディストリビューションのサポートを継続すると明言しています。

参考: ZDNet — Microsoft releases its first server Linux distribution: Azure Linux 4.0
“We still have a great ecosystem of partners, right? This changes nothing with those relationships. If you want to run Red Hat, if you want to run Ubuntu, that’s absolutely okay. We have eight endorsed distros on our platform, and we will continue to work with those.”
(優れたパートナーエコシステムは引き続き維持される。今回の発表でそれらの関係性は何も変わらない。Red Hat を使いたければ Red Hat を、Ubuntu を使いたければ Ubuntu を選んで問題ない。当社のプラットフォーム上には 8 つの認定ディストリビューションがあり、引き続き協力していく。)
https://www.zdnet.com/article/microsoft-releases-its-first-server-linux-distribution-azure-linux-4-0/

実務的な判断軸を整理すると次のようになります。

状況推奨される選択
既存システムが RHEL / Ubuntu / SLES などで標準化されている既存ディストリビューションの継続利用を推奨
ISV のサポート要件で特定ディストリビューションが指定されている該当ディストリビューションの継続利用を推奨
Azure 上に新規構築するシステムで OS の選択肢が自由Azure Linux 4.0 を選択肢として評価する価値あり
AKS の新規クラスタを構築するAzure Container Linux を有力候補として評価
セキュリティ・サポート責任を Microsoft に一本化したいAzure Linux 4.0 / ACL の採用メリットが大きい

Azure Linux 4.0 は「既存の選択肢を置き換える」ものではなく、「選択肢を増やす」ものとして捉えるのが現実的です。

ライフサイクル・サポート体制

Azure Linux 4.0 を本番環境で運用する際の判断材料として、サポート期間とアップデート方針は最も重要な情報の一つです。Microsoft はこの点を比較的明確に示しており、運用設計時に押さえておくべき前提を整理します。

サポート期間 2 年とカーネルの安定性

Azure Linux 4.0 の各バージョンに対するサポート期間は 2 年間です。

参考: ZDNet — Microsoft releases its first server Linux distribution: Azure Linux 4.0
“We have two years of support.”
(サポート期間は 2 年である。)
https://www.zdnet.com/article/microsoft-releases-its-first-server-linux-distribution-azure-linux-4-0/

2 年というサイクルは、RHEL の 10 年や Ubuntu LTS の 5 年(標準サポート)と比較するとかなり短めです。長期間同じバージョンを塩漬けで運用するスタイルには合いません。一方、サポート期間内のカーネルバージョンは固定的に運用される方針です。

参考: ZDNet — Microsoft releases its first server Linux distribution: Azure Linux 4.0
“what we try to do is pick specific kernel versions that we’re using for over the lifetime of the two years of support for that specific version, and then we offer an upgrade pathway for customers as well, so it’s fully supported and then upgradable in the two years.”
(特定のカーネルバージョンを 2 年間のサポートライフタイム全体で利用し続けるように選定し、その上で顧客向けにアップグレード経路を提供する。2 年間にわたってフルサポートかつアップグレード可能である。)
https://www.zdnet.com/article/microsoft-releases-its-first-server-linux-distribution-azure-linux-4-0/

「カーネルバージョンは 2 年間維持しつつ、セキュリティパッチは適宜バックポートされる」という運用モデルです。カーネル ABI の互換性を保ちながらセキュリティを担保する考え方で、エンタープライズ Linux ディストリビューションの典型的なアプローチと同じです。

月次セキュリティアップデートのリズム

Microsoft は Azure Linux に対して 月次のセキュリティアップデートを提供する方針を示しています。月次定例の枠とは別に、深刻な CVE が発生した際にはパッチ適用済みイメージを臨時で提供するという運用が明示されている点が重要です。

参考: ZDNet — Microsoft releases its first server Linux distribution: Azure Linux 4.0
“we’ve got to make sure that our customers can keep up to date with the rate of change and the rate of disclosures and patches, so we’ve really baked that into the core of the operating system, that we can take those updates really quickly, so that you’re not waiting.”
(顧客が脆弱性開示やパッチのペースに追随できるようにする必要がある。OS のコアにその仕組みを組み込んでおり、待たされることなく素早くアップデートを取り込める。)
https://www.zdnet.com/article/microsoft-releases-its-first-server-linux-distribution-azure-linux-4-0/

Linux カーネルの脆弱性報告数が増加傾向にある状況で、CVE 開示から修正イメージ提供までのリードタイムを短縮する設計を OS レイヤーに織り込んでいる点は、運用観点では評価できるポイントです。

自動アップグレード機構(オプトイン/オプトアウト)

Azure Linux 4.0 と ACL は、VM と AKS の双方でセキュリティ更新の自動アップグレードをオプトインできる仕組みを備えています。

参考: ZDNet — Microsoft releases its first server Linux distribution: Azure Linux 4.0
“Whether they’re VMs or AKS, we have the ability to opt in to automatic upgrades based on security.”
(VM でも AKS でも、セキュリティに基づく自動アップグレードへのオプトインが可能である。)
https://www.zdnet.com/article/microsoft-releases-its-first-server-linux-distribution-azure-linux-4-0/

大規模なクラスタやスケールアウト構成では、アップグレードは段階的に適用される設計で、全ノードが同時に再起動して可用性が損なわれることを避ける配慮がなされています。業務システム側の依存関係が複雑なケース向けにはオプトアウトも可能です。

運用設計上の判断軸を整理すると次のとおりです。

運用方針推奨設定想定されるシステム例
セキュリティ最優先・ステートレス自動アップグレード有効(オプトイン)を推奨Web フロントエンド、API ゲートウェイ、AKS の汎用ノードプール
業務継続性最優先・厳格な変更管理が必要手動アップグレード(オプトアウト)を推奨基幹システム、DB サーバ、認証基盤
段階的に評価したい検証環境でオプトイン、本番はオプトアウト全般

移行・採用時に押さえておきたいポイント

ここでは、すでに Azure 上で Linux ワークロードを運用している場合、または新規に Azure Linux 4.0 / ACL を採用しようとする場合の判断材料を整理します。

Azure Linux 3.0 から 4.0 への移行(インプレース更新の可否)

既存の Azure Linux 3.x ユーザーにとって重要なのは、4.0 への移行がインプレース更新で済むのか、それとも別途移行作業が必要かという点です。Microsoft は明確に前者の方向を示しています。

参考: ZDNet — Microsoft releases its first server Linux distribution: Azure Linux 4.0
(Q: Azure Linux 3.0 から 4.0 へマイグレーション無しでアップグレードできるか)
“Yes.”
(はい。)
https://www.zdnet.com/article/microsoft-releases-its-first-server-linux-distribution-azure-linux-4-0/

ただし、これは現時点での口頭ベースの説明であり、実際のアップグレードコマンドや手順は公式ドキュメントで未公開です。Azure Linux 4.0 はまだパブリックプレビューのサインアップ段階で、GitHub の 4.0 ブランチにソースは存在するものの、バイナリイメージ・GA リリースは出ていません。

参考: GitHub — microsoft/azurelinux
“The 4.0 branch holds the sources for Azure Linux 4.”
(4.0 ブランチには Azure Linux 4 のソースが格納されている。)
https://github.com/microsoft/azurelinux

Fedora ベースに切り替わる 4.0 では RPM の依存解決が大きく変化する可能性があるため、本番適用前にはステージング環境で十分に検証することを推奨します。具体的な手順は GA 後に公式ドキュメントで公開されてから確認することを推奨します。

CVE 対応の早期化と運用への影響

Azure Linux 4.0 / ACL では、Microsoft がサプライチェーン全体を管理することで CVE 対応を早期化することを謳っています。

参考: ZDNet — Microsoft releases its first server Linux distribution: Azure Linux 4.0
“if a serious Common Vulnerabilities and Exposures (CVE) appears, Microsoft promises to offer a patched image as soon as those patches come out.”
(深刻な CVE が発生した場合、パッチがリリースされ次第パッチ適用済みイメージを提供することを Microsoft は約束している。)
https://www.zdnet.com/article/microsoft-releases-its-first-server-linux-distribution-azure-linux-4-0/

運用観点で評価できる点と注意すべき点を整理します。

評価できるポイント

  • OS レイヤーの CVE 対応はディストリビューターに任せられる(自前でのカーネルバックポートが不要)
  • イメージベースの更新により、新イメージへの差し替え型運用に親和性が高い
  • Azure Monitor / Defender for Cloud との連携で適用状況を可視化しやすい

注意すべきポイント

  • OSS コミュニティが先にパッチを公開しても、Microsoft 経由でリリースされるまで時間差が生じる可能性がある
  • カーネルパラメータの大幅変更やカスタムビルドカーネルの利用は想定外
  • CentOS や RHEL ほどの第三者ツールサポートは当面揃わない可能性がある

CVE 対応の実例については、関連記事「PAN-OS CVE-2026-0300 の解説」も参照ください。

Azure 以外のクラウド・オンプレでの利用可否

Azure Linux 4.0 は MIT ライセンスのオープンソースであり、技術的には Azure 以外の環境でも動作させること自体は可能です。ただし、Microsoft 側のメッセージは明確に Azure 専用に最適化された存在と位置付けています。

参考: Microsoft Open Source Blog
“Azure Linux 4.0 is a Fedora-derived, RPM-based Linux distribution built and maintained by Microsoft. It’s open source, free to use, and optimized specifically for Azure infrastructure.”
(Azure Linux 4.0 は Fedora 派生で RPM ベースの Linux ディストリビューションであり、Microsoft が構築・維持している。オープンソースかつ無償利用可能で、Azure インフラ向けに特化して最適化されている。)
https://opensource.microsoft.com/blog/2026/05/18/from-open-source-to-agentic-systems-microsoft-at-open-source-summit-north-america-2026/

利用環境別の適合性をまとめると次のとおりです。

利用環境適合性補足
Azure VM / AKS高いMicrosoft の想定する主要用途
Azure Arc 経由のオンプレ検証の余地ありAzure 統合機能の一部は活用可能と想定される
AWS / GCP の VM動作はするが想定外Azure メタデータサービス前提の機能は無効化される
完全オンプレ・ベアメタル動作はするが想定外RHEL や AlmaLinux など別の選択肢の方が現実的

Azure 以外の環境では、Fedora 本体や RHEL 互換ディストリビューションを直接採用する方が、サポート体制とコミュニティリソースの両面で合理的です。

まとめ

Microsoft が Open Source Summit North America 2026 で発表した Azure Linux 4.0 と Azure Container Linux は、Azure 上の Linux 基盤を「汎用 VM 向け」と「コンテナホスト向け」に整理し直す大きな方針転換です。

  • Azure Linux 4.0 は Fedora ベース・RPM 系の汎用 VM 向けディストリビューションで、現在パブリックプレビューのサインアップ段階(GA 時期は未発表)
  • Azure Container Linux(ACL)は Flatcar ベースのイミュータブル OS で、AKS 向けコンテナホストとして 2026 年 5 月 18 日に GA
  • Azure Linux 3.0 の AKS 向けポジションは今後 ACL に移行する方向で整理されており、既存利用者は動向の注視を推奨する
  • サポート期間は 2 年間で、月次セキュリティアップデートと深刻 CVE への臨時パッチ提供が約束されている
  • 自動アップグレードはオプトイン制で、大規模クラスタでは段階的適用が行われる設計
  • Red Hat・Ubuntu など既存の 8 つの認定ディストリビューションとの共存は継続される方針で、移行を強制するものではない
  • 3.0 から 4.0 へのインプレース更新は「Yes」と明言されているが、具体的な手順は GA 後の公式ドキュメント公開を待って検証することを推奨する

以上、最後までお読みいただきありがとうございました。

よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

関西を拠点に活動する、現役インフラエンジニア。経験20年超。

大手通信キャリアにて、中〜大規模インフラ(ネットワーク・サーバ・クラウド・セキュリティ)の設計・構築およびプロジェクトマネジメントに従事。現場で直面した技術課題への対処や、最新の脆弱性情報への実務対応を、一次情報として発信しています。

保有資格
CCIE Lifetime Emeritus(取得から20年以上)/ VCAP-DCA / Azure Solutions Architect Expert

▶ 運営者プロフィール(詳細)

目次