CanonicalはUbuntu全体をRustで書き直しているわけではありません。しかし、メモリ安全性と保守性の向上が移行コストを正当化すると判断した箇所で、中核システムコンポーネントの置き換えを始めています。Canonicalのエンジニアリング担当バイスプレジデントであるJon Seager氏がJetBrains主催の配信で説明したところによると、この決定は、サーバー、デスクトップ、エッジデバイス、自動車内で約1,500万件のデプロイを稼働させるプラットフォームに関する長期的なビジョンの一部です。
この方針は、存在するすべてのツールを再実装するキャンペーンではなく、Ubuntuが今後20年間に何を必要とするかという問いから出発しています。Canonicalは、特にメモリエラーへの耐性と信頼性が、産業システム、自動車、または重要インフラ内で動作するソフトウェアに影響を及ぼす要素となる場合、Rustがシステム開発のための説得力あるツール群を提供すると考えています。
全面的な書き換えではなく選択的な置き換え
これらのコンポーネントの最初のものはUbuntu 26.04 LTSに導入されました。GNU coreutilsをRustで再実装したuutils coreutilsがデフォルトの選択肢となり、GNUツールの動作との完全な互換性を実現することが明示的な目標とされています。つまり、動作上の小さな違いは必ずしも改善とはみなされず、スクリプトや従来の動作に依存するツールを壊す場合には、バグとみなされる可能性があります。
一方、sudo-rsは異なる道を進んでいます。sudoとの完全な一致を目指すのではなく、数十年にわたるセキュリティ上の知見を踏まえ、今日設計するとしたら権限付与ツールはどのような形になるかを再考しています。強い反応を引き起こした変更の一つが、端末でパスワードを入力する際に、デフォルトでアスタリスクを表示することです。Canonicalは、短期的な摩擦を生じさせる場合でも、これらの意図的な変更を受け入れると述べています。これは単なる互換置換ではなく、新しい設計の一部だと考えているためです。
時間と証明書も変更の対象
次のプロジェクトはntpd-rsです。Canonicalは2026年6月、Trifecta Tech Foundationを通じて同プロジェクトに資金を提供し、Ubuntuのデフォルトの時刻同期ツールにすることを発表しました。計画では、Ubuntu 26.10でアーカイブ化し、その後Ubuntu 28.04で完全にデフォルトの選択肢へ移行します。NTP、NTS、PTPをサポートする単一のツールによって、chronyとlinuxptpを段階的に置き換える予定です。
この変更が重要なのは、正確な時刻同期がネットワークサーバーだけに関係するものではないからです。航空機、自動車、ロボット内のマイクロコントローラー、定期的に鍵をローテーションする暗号システム、さらに位置情報に依存するシステムにも影響します。記事では、chronyとlinuxptpを併用する場合、複数のツールと時刻ソースの設定が必要になる可能性がある一方、ntpd-rsはメモリ安全性を活用し、これらの機能を一つのツールと一つの設定ファイルに集約することを目指していると説明しています。
UPKIプロジェクトは、これらの置き換えとは異なり、Rustlsプロジェクトと共同でゼロから始める新しいプロジェクトです。Linuxのシステムツールに証明書失効検証を追加することを目指しており、CanonicalはUbuntu 26.10での初登場を目標としています。この構想はcurl、wget、OpenSSLなどのツールに関連しています。記事によれば、これらのツールでは、ブラウザーに存在するものと同じ方法による証明書失効への対応が組み込まれていません。
ユーザーにとって実際に何が変わるのか
Canonicalは、これらの変更を導入するタイミングとしてLTSリリースの境界を選びました。これは、組織が通常この時点でシステムを更新すること、そして低レベルツールを変更する際にはロールバックの経路が重要になるためです。記事によれば、以前のリリースには15年間のマネージドサポートが提供され、従来のツールはアーカイブに残されます。そのため、既存の本番システムに新しい動作を、復帰の選択肢なしに強制することはありません。
ただし、プロジェクト間で互換性が統一されているわけではありません。uutils coreutilsでは、空のファイルから指定したバイト数を読み取ろうとした際、headがエラーを返すという実例がありました。一方、GNU coreutilsは0を返していました。この違いによって、Obsidian snapパッケージ内に隠れていたスクリプトが壊れたため、GNUと一致するように動作が変更されました。この例は、メモリ安全性によって、30年にわたり古いツールの周囲に蓄積されてきた前提との互換性の重要性がなくなるわけではないことを示しています。
課題はコードを書き終えた時点では終わらない
Rustを大規模なディストリビューションに導入するには、依存関係、ビルド、配布の連鎖にも対処する必要があります。Canonicalは、各crateを個別のdebパッケージとしてパッケージ化するのではなく、各パッケージ固有のcrateを一つのアーカイブにまとめる方式を採用しています。記事によれば、これにより依存関係の範囲を管理しやすくし、ビルドを決定的に保つことができます。ただし、正式な意味で再現可能というわけではありません。
2026年初頭には、Ubuntuアーカイブ内のすべてのRustパッケージにcargo auditableが適用されました。各Rustバイナリには、ビルドに使用されたcrateの名前とバージョンを記録する組み込みSBOMが含まれており、パッケージを再ビルドすると自動的に更新されます。このデータが脆弱性を防ぐわけではありませんが、依存関係の一つで問題が発見された際に、影響を受けるバージョンを特定しやすくします。
certi.newsの見解：ここでの真の変化は、Cで書かれたツールをRustで書かれたツールに置き換えることだけではありません。普及後の変更が難しいコンポーネントに、安全性、保守性、依存関係の追跡を実現する層を導入することです。一方、互換性の事例やsudo-rsの動作は、移行によってユーザーが気付く設計上の判断が生じる可能性を示しています。その成功は、実装言語に依存するのと同じ程度に、こうした違いを管理できるかどうかにかかっています。ntpd-rsとUPKIについて発表された日程は今後の目標であり、情報源は、変更の範囲が選択的で、従来のツールとロールバックの選択肢が依然としてCanonicalの戦略の一部であることを示しています。