2026年4月21日のFedora ELN SIG議事録で、MicrosoftのAzure Linuxを「多かれ少なかれFedora上にリベースしたい」という発言が記録された。背景にあるのは、Fedora 45向けに提案されたx86_64-v3パッケージの追加である。Azure LinuxはMicrosoftがAzureのクラウド基盤やエッジ向けに育ててきたRPM系の社内Linuxで、AKSではコンテナホストOSとして利用されている。今回見えた変化は、Microsoftが単独で新しい派生ディストリビューションを増やす話ではなく、Fedoraのビルド基盤とマイクロアーキテクチャ対応を上流として使えるかどうかという、より実務的な分岐点である。
4月21日の議事録が示したAzure側の動機
Fedora ELN SIGの2026年4月21日会合では、microarchitecture supportの議題として、Fedora 45のx86_64-v3パッケージ提案が取り上げられた。議事録では、Microsoftがこの変更を支援しており、計算資源を提供できる可能性があるとの発言に続き、この変更はFyra LabsとAzureが主導していると説明されている。さらに、Azure Linuxについて「Fedora上にリベースしたい」「性能のためにx86_64-v3が必要だ」とする発言が残っている。Phoronixは4月25日、この議事録を根拠に、MicrosoftがAzure LinuxをFedoraベースへ移す可能性を報じた。
Fedora側の公開議事録で明確になったのは、Azureの動機と必要条件が参加者の発言として記録された、という点である。議事録には、当初はこの目的でディストリビューション全体をフォークする漠然とした案があったが、現在のFedora側の方向へ誘導されたという説明もある。つまり焦点は、Azure Linuxの名前や配布形態がすぐ変わるかどうかではなく、MicrosoftがFedoraの仕組みに性能最適化の道を求めている点にある。正式なロードマップではない一方、単なる外部観測よりは強い材料である。
2026年4月14日にFedora Discussionへ投稿されたChange Proposalは、Fedora 45で既存のx86_64-v1向けビルドに加え、x86_64-v3向けパッケージを提供する内容である。提案者はLleyton Gray氏、Kyle Gospodnetich氏、Owen Zimmerman氏で、PhoronixはGospodnetich氏をMicrosoftのLinuxエンジニアとして紹介している。提案文は、Fedora Engineering Steering Committeeの承認があって初めて実装されるものだと明記しており、現時点ではまだ提案段階だ。ここを読み違えると、「Azure LinuxがFedoraベースになる」と確定情報のように扱ってしまうが、実際にはFedora 45のビルド方針とAzure Linuxの将来設計が交差した段階である。
x86_64-v3提案が要求する配布基盤
Fedora 45の提案は、x86_64_v3を新しい一次アーキテクチャとして扱い、既存のx86_64パッケージをv3向けにもビルドするという設計である。提案文によれば、x86_64のマイクロアーキテクチャ別パッケージをインストールするための基盤はlibsolvとRPMに存在するが、DNF、Koji、Pungiには追加対応が必要になる。具体的には、Kojiでx86_64アーキテクチャレベルを扱えるようにし、redhat-rpm-configにx86_64_v2/v3/v4のコンパイラフラグ定義を加え、DNF5が互換性のある上位レベルのパッケージを透過的に選べるようにする。リリースエンジニアリング側には、x86_64_v3のリポジトリとイメージを有効化して配布する作業も発生する。
x86_64-v3対応の狙いは、近年のIntelやAMDのCPUが持つ命令セットをディストリビューション全体でより使いやすくする点にある。Fedoraの提案文は、v3ベースラインをサポートするシステムでは、Fedora 45へのアップグレード時にDNFが利用可能なx86_64-v3パッケージを選ぶとしている。ユーザー体験の説明も、上位ベースライン向けにコンパイルされたパッケージは対応システムで性能が向上する可能性がある、という慎重な表現にとどまる。Azure Linux側の発言が「性能のため」とされているのは、この仕組みをクラウドのホストOSやコンテナ基盤へ持ち込んだとき、同じCPU資源から引き出せる効率が事業上の意味を持つためである。
Fedoraの議論では、利点だけでなくコストも正面から出ている。4月14日のDiscussionでは、全パッケージをv1とv3の両方で再構築する場合、重複パッケージのディスク容量、ビルド時間、compose、ミラー同期、ユーザー説明の負担が大きいとの反対意見が示された。別の参加者は、v3をサポートするマシンで構築したディスクをv3非対応のマシンへ移す場合や、仮想マシンをv3非対応ホストへライブマイグレーションする場合に、DNFや周辺ツールが上位マイクロアーキテクチャを使わない設定を持つ必要があると指摘している。Fedora側でこの問題を解くことは、Azure Linuxのような大規模運用向けディストリビューションにとっても、単なる最適化以上の意味を持つ。
Azure LinuxはすでにRPM系の「小さな共通基盤」だった
MicrosoftのGitHubリポジトリは、Azure LinuxをMicrosoftのクラウド基盤とエッジ製品・サービス向けの内部Linuxディストリビューションと説明している。READMEは、小さな共通コアのパッケージ集合を用意し、各チームがその上に追加パッケージを重ねてワークロード用イメージを作る設計だと述べる。パッケージ生成とイメージ生成を行うビルドシステムを持ち、RPM Package Managerを使ってセキュリティ修正を配布する点も明記されている。さらに、Fedora ProjectのSPECファイル、Photon OS Project、Linux from Scratchへの謝辞があり、Azure Linuxが完全に孤立した独自OSではなく、既存のLinuxエコシステムから多くを取り込んでいることもわかる。
Microsoft LearnのAKS向け文書では、Azure Linux Container HostはAKSでコンテナワークロードを実行するために最適化されたOSイメージとされる。文書は、Microsoftがこれを保守し、Microsoft製のオープンソースLinuxであるCBL-Marinerを基にしたと説明している。Azure Linux Container Hostは必要なパッケージだけを含む軽量な構成で、AKS上では約500パッケージとされ、最大5GBのディスク削減につながるという。Microsoftはパッケージをソースからビルド、署名、検証し、月次でセキュリティパッチを出し、重要な更新は必要に応じて数日内に提供すると説明している。
Azure Linux 3.0は、AKS 1.32で一般提供され、Linux Kernel 6.6、containerd 2.0、systemd v255、SymCryptを含む構成になった。Microsoftは2025年4月1日のCommunity Hub投稿で、Azure Linux 3.0がx86_64とARM64をサポートし、AzureのCobaltアーキテクチャのような新しいプラットフォームにも対応していくと説明していた。Microsoft Learnは、AKS 1.31から1.32へアップグレードする顧客はAzure Linux 3.0へ自動的に移るとしており、Azure Linux 2.0については2025年11月30日にAKSでのサポートとセキュリティ更新が終了し、2026年3月31日からノードイメージが削除されると案内している。つまりAzure Linuxは、実験的な社内成果物ではなく、AKSのライフサイクルと結びついた運用基盤である。
Fedora側の合意形成が次の焦点になる
Azure LinuxがFedoraへ近づく場合、読者が見るべき点は「MicrosoftがLinuxに本気か」という一般論ではない。より具体的には、Microsoftが自社のクラウドOSの性能要件を、Fedoraのパッケージング、ビルド、リリースエンジニアリングにどこまで持ち込むのかである。Fedora 45のChange Proposalは、承認、実装、Beta Freeze前の判断、必要ならv3パッケージを取り下げて次リリースへ延期するContingency Planまで含む。Azure側の需要が強くても、Fedora側の合意形成、インフラ負荷、ツール対応、ユーザー互換性の説明を飛ばすことはできない。
Azure Linuxの利用者にとって、Fedoraベース化が直ちに日々の操作を変えるとは限らない。AKSのAzure Linux Container Hostは、Microsoftが検証、署名、ライフサイクル管理するホストOSであり、ユーザーは通常、ディストリビューションの上流よりもAKSのバージョン、ノードイメージ、Kubernetesの互換性を通じて影響を受ける。一方で、Fedora側のx86_64-v3対応が進めば、Microsoftは独自フォークで性能最適化を抱え込むより、上流の仕組みを使ってAzure Linuxのビルドと配布を整えられる可能性がある。この場合、メリットは性能だけでなく、RPM、DNF、Koji、Pungiといった周辺ツールの改善をFedora、ELN、将来のEnterprise Linux系へ波及させられる点にもある。
2026年4月時点で最も強い結論は、Azure Linuxの将来がFedoraのx86_64-v3議論に接続された、というところまでである。Microsoftの正式ロードマップ、Fedora Engineering Steering Committeeの判断、Fedora 45での実装可否、AKS向けAzure Linuxへの反映時期はまだ確認できない。Phoronixの報道が注目されたのは、Microsoftが自社Linuxを持ちながら、性能最適化のためにFedoraの上流構造へ近づく動きが見えたからである。次に見るべきなのは、Fedora 45のx86_64-v3提案がどの形で通るか、そしてAzure Linux側がその成果を単なる参照にとどめるのか、実際のベース再設計へ進めるのかである。