Fedora Linux 44が、2026年4月28日に正式リリースされた。当初4月14日を予定していたリリース日は2週間遅延したが、その背後にあったのはインストーラーのクラッシュバグと、ゼロデイ相当のセキュリティ脆弱性への対処という、開発コミュニティが「品質より日程」の誘惑を退けた結果である。リリースされた最終ビルド「RC-1.7」には、200件以上のセキュリティ脆弱性を修正したFirefox 150と、PackageKitにおける権限昇格バグの修正が含まれている。この判断の経緯と、Fedora 44が技術的に何を意味するのかを整理してみたい。
2週間の延期が生んだもの：品質保証の舞台裏
Fedora Projectは2026年4月16日の最終Go/No-Go会議で、「NO-GO」の決断を下した。問題はAnacondaインストーラーが複数の環境でクラッシュするという、最も基本的な動作の信頼性に関わるものだった。具体的には、インストール工程の終盤でAnacondaが間欠的にクラッシュする事象と、BtrfsパーティションレイアウトでインストーラーがAbortする事象の2件がブロッカーバグとして特定された。これらはどちらも、ユーザーが新規インストールを完了できないという致命的な欠陥である。
その後、4月23日に開催された第2回Go/No-Go会議では、品質保証チームが要求テストのほぼ100%を完了した旨を報告し、プロジェクトは晴れて「GO」を宣言した。採用されたRC-1.7ビルドは、元のターゲット日付から2週間後という遅れをもたらしたが、その間にFirefox 150とPackageKitのセキュリティパッチが統合された点は無視できない。PackageKitの脆弱性は、未認証のコードがroot権限で実行される可能性があるという種類のもので、もし4月14日のリリースが強行されていれば、インストール直後のシステムが即座にリスク下に置かれていたことになる。
ただし、「小さなパーティションサイズに関してインストーラーが警告を出さない」という軽微な問題はwaivedとして処理されている。waivedとは、開発チームが問題を認識した上で、リリースを遅らせるほどの重大性がないと判断した場合に使う用語だ。この問題は以前のFedoraバージョンにも存在し、広範な障害は引き起こしていないという実績が判断根拠となった。
GNOME 50：Waylandへの最終的なコミット
Fedora Linux 44 WorkstationはGNOME 50を搭載する。GNOME 50の最大の変化は、X11互換コードが本体から除去された点にある。Waylandをデフォルトとする方針はFedora 39頃から継続されてきたが、今回は「X11をインストールすることは可能だが、公式サポート対象外」という段階まで踏み込んだ。X11互換コードの除去は、デフォルト設定の変更とは次元が異なる。Fedora WorkstationというプロダクトがWaylandに特化したアーキテクチャとして再定義された、という意味合いを持つ。
アクセシビリティ、カラーマネジメント、リモートデスクトップの各機能が改善されたほか、Digital Wellbeing構想の一環として、スクリーンタイム制限と就寝時刻をSettingsアプリから直接設定できるネイティブのペアレンタルコントロールが導入された。ドキュメントビューア、ファイルマネージャー、カレンダーといったデフォルトアプリケーションも更新されており、デスクトップ環境全体の統一感が向上している。
VRR（可変リフレッシュレート）の正式サポートと、Fractional Scaling（分数スケーリング）の改善も今回の注目点だ。高解像度ディスプレイ環境では、HiDPIスケーリングと整数倍率の間で生じるぼやけや文字の不鮮明さが長年の課題だったが、分数スケーリングの精度向上はそこへの直接的な回答となる。
KDE Plasma 6.6とPlasma Login Manage：デスクトップ統合の再定義
Fedora KDE Plasma Desktop 44はPlasma 6.6を採用し、注目すべき変更としてKDE Plasma Login Manager（KDE PLiMo）がデフォルトのディスプレイマネージャーとして設定された。従来のSSDMからの切り替えであり、電源投入直後から一貫したKDEエクスペリエンスが提供される。
この変更にはメリットと留意点の両面がある。メリット面では、すべてのFedora KDE版が共通のout-of-the-box体験を持つようになり、ハードウェアベンダーがFedora KDEをプリインストールして販売しやすい環境が整う。初回起動時のウェルカムウィザードが統一されることは、エンタープライズ向けのデプロイメントや教育機関でのLinux採用という文脈で見ると、意外に大きな意味を持つ。Fedora KDE Plasma Desktop EditionがFedora Readyとして完全サポートされるようになったことも、このベンダー連携を後押しする。
一方、Plasma Login Managerは現時点ではSSDMと比べて機能の範囲が限られており、セッション別のテーマカスタマイズや細かなユーザーセッション管理をSSDMで運用してきたユーザーは設定の移行が必要になる。とりわけ複数のデスクトップ環境を混在させているシステムや、カスタムWayland/X11セッションを登録していた構成は、Plasma Login Manager移行後に動作を確認することが望ましい。
Wine NTSYNCとLinux 6.19：ゲーミング用途への影響
Fedora 44には、WindowsアプリケーションとゲームのLinux上での動作を改善するNTSYNCカーネルモジュールが統合された。NTSYNCはWindowsのNT同期プリミティブをLinuxカーネルレベルで実装するものであり、Wine・Proton経由でWindowsゲームを動作させる際のスレッド同期オーバーヘッドを大幅に削減する。
従来の実装では、Windows APIのSync処理がuserspaceレイヤーでエミュレーションされていたため、特にマルチスレッドを多用するゲームでCPUオーバーヘッドが無視できなかった。NTSYNCはこれをカーネルモジュールとして処理することでレイテンシを削減し、Steam（Proton）やWine上でのゲームパフォーマンス向上と安定性改善につながる。WineとSteamはパッケージの「推奨（recommendation）」としてwine-ntsyncパッケージが指定されるため、インストール後は以降のブート時に自動的に有効化される。ユーザーが手動で設定を行う必要はない。
搭載カーネルはLinux 6.19で、古いAMD GPUに対してドライバの最適化により最大40%のパフォーマンス向上が実現しているほか、Intel第16世代とAMD Zen 6（開発コードネーム）への初期サポートが追加されている。ゲーミングLinuxという観点では、NTSYNCとLinux 6.19の組み合わせはこれまでで最も実用的な選択肢を提供するリリースの一つとなった。
パッケージ管理とシステム基盤の刷新：DNF5への完全移行
Fedora 44ではパッケージマネージャーがDNF5へ完全移行した。DNF5はメタデータのダウンロードと依存関係の解決アルゴリズムを根本から書き直したもので、メモリ消費量の大幅な削減と処理速度の向上が実現している。パッケージのインストールや更新が「体感として速くなった」という次元ではなく、アーキテクチャ的に設計し直された結果であり、大規模なシステム更新やサーバー環境でのパッケージ管理においてその差はより顕著に現れる。
ツールチェーン面では、GCC 16、LLVM 22、Python 3.14、PHP 8.5、Ruby 4.0、Go 1.26、Perl 5.42、glibc 2.43、RPM 6.0といった、ほぼ全ての主要コンポーネントが最新版に更新されている。開発者用ディストリビューションとしてのFedoraの立ち位置を考えれば、これらの更新はシステムの基盤ではなく開発ツールそのものとして機能する。Go 1.26とPython 3.14が手元の開発環境に即座に入ってくるという事実は、fedoraをコードを書く場所として選ぶ動機に直結する。
Ansible 13のサポートも追加されており、既存のPlaybookを持つ運用チームは公式ポーティングガイドで互換性を確認する必要がある。MariaDBはバージョン付きパッケージレイアウト（mariadb11.8）に移行し、デフォルトの非バージョンmariadbパッケージはFedora 44で11.8をインストールするようになった。
OpenSSLのロード時間改善も地味ながら実用的な変更の一つだ。ca-certificatesにディレクトリハッシュサポートが有効化されたことにより、システム起動時やWebアプリケーションの初期化時に発生していたOpenSSLの初期化コストが削減される。
Fedora Atomic DesktopsとFUSE2の廃止
Fedora Atomic Desktops（Silverblue、Kinoite等の不変システムOSフレーバー）はFUSE2ライブラリのサポートを廃止した。この影響を直接受けるのは、AppImageフォーマットのアプリケーションを使用しているユーザーだ。AppImageの一部はFUSE2を使ってマウントポイントを作成するため、FUSE2が取り除かれた環境では動作しない可能性がある。FlatpakやDistroboxを主力とするFedora Atomic環境における今回の廃止は、コンテナベースのアプリケーション配布への移行をより強く促す方向性と一致している。
Fedora Cloud版では、/bootパーティションがBtrfsサブボリュームに置き換えられた。これはクラウドイメージのディスク使用効率を向上させ、イメージサイズの縮小につながる変更で、クラウドプロバイダーとの連携やIaCによる自動デプロイ環境で恩恵を受けやすい。
Budgie 10.10とAArch64対応：エコシステムの拡張
Fedora SpinsとしてBudgie 10.10のサポートが追加された。Budgie 10.10はWayland対応が大幅に強化されており、Fedora 44のWayland中心のエコシステムへのコミットメントと整合する形での採用となる。軽量でありながら洗練されたデスクトップ環境を求めるユーザーに対して、GNOMEやKDE以外の選択肢が拡充される。
AArch64（ARM64）のEFIシステムサポートが強化されたことで、Windows on ARMラップトップ上でFedoraを動かすシナリオへの対応が進んだ。ARM ベースのPC市場が拡大する中で、FedoraのAArch64サポートはx86_64と対等な地位に近づいている。
Nixとの統合機能強化も今回のリリースに含まれている。Nixパッケージマネージャーとその再現可能ビルドの哲学に親しんでいる開発者が、Fedoraベースのシステム上でNixのエコシステムを利用しやすくなった。Fedoraのrpmベースのパッケージ管理とNixの宣言的な環境定義を並行して活用できる構成は、開発環境の再現性を重視するチームにとって、既存のワークフローを維持しながらFedoraを採用する際の障壁を下げる。
「品質より日程」を退けた意思決定の構造的意味
Ubuntu 26.04 LTSのリリースから1週間後というタイミングでのFedora 44リリースは、競合意識という観点では微妙な位置づけになる。当初の計画ではUbuntu 26.04より1週間先行してリリースされるはずだったが、ブロッカーバグへの対処がそれを狂わせた。ただし、この「後れを取った」という評価は表面的に過ぎる。FedoraとUbuntu LTSはリリースサイクルという根本的な構造が異なる——Fedoraは約6ヶ月ごとに最新技術を取り込む俊足型であるのに対し、Ubuntu LTSは5年間の長期サポートを約束する安定運用型だ。両者のユーザー層は重なりながらも棲み分けられており、数日の前後関係が市場シェアの逆転を引き起こす性質のものではない。
Fedoraが取った選択は、コミュニティから一定の支持を得ている。多くのユーザーが「遅れても安定版の方がいい」という意見を表明しており、それはFedoraが長年にわたって構築してきた「最先端だが信頼できる」というブランドイメージの反映でもある。PackageKitの権限昇格バグは、もし修正されずにリリースされていれば、悪意あるローカルコードをroot権限で実行できる状態を生んでいた。この種の脆弱性が修正済みの状態でリリースできたことは、2週間の遅延分のコストとして十分な価値がある。
FedoraのGo/No-Go体制は、リリースエンジニアリング、品質保証、開発の各チームが合議で判断する構造になっている。「NO-GO」の判断を下す際にプロジェクトリードが圧力に屈せず、その後のコミュニティからの反応が概ね支持的だったという事実は、ガバナンスの形式よりも実際の運用文化が機能しているかどうかを問うものだ。オープンソースプロジェクトにおいてリリース日程はマーケティング上の意味を持つが、Fedoraのコミュニティはその圧力よりもシステムの整合性を優先するという選択を繰り返し行ってきた。その蓄積が、ディストリビューションとしての信頼の実体を形成している。