この記事の途中に、以下の記事の引用を含んでいます。
新しい幕開け？Rust 1.90.0の登場が意味するもの
2025年9月、Rust開発コミュニティが「Rust 1.90.0」のリリースを発表しました。
このアップデートは単なるバグ修正や小規模な改善にはとどまらず、今後のRustエコシステム全体の方向性を示唆する意欲的な内容となっています。
では、公式発表の内容を正確に押さえつつ、プログラマやシステム開発に携わるみなさんに「何がどう変わり、なぜ大きな意味を持つのか」を深掘りしていきます。
公式発表から読み解く主なアップデート内容
まず、公式ブログの主張を引用し、要点を紹介します。
“The x86_64-unknown-linux-gnu target will now use the LLD linker for linking Rust crates by default. This should result in improved linking performance vs the default Linux linker (BFD), particularly for large binaries, binaries with a lot of debug information, and for incremental rebuilds.”
“cargo publish –workspace is now supported, automatically publishing all of the crates in a workspace in the right order (following any dependencies between them).”
“as of Rust 1.90, we have demoted the x86_64-apple-darwin target from Tier 1 with host tools to Tier 2 with host tools … Over time, it’s likely that reduced test coverage for this target will cause things to break or fall out of compatibility with no further announcements.”
ここで公式が強調しているのは、大きく分けて以下の３点です。
- デフォルトリンカのLLD化（x86_64-unknown-linux-gnu向け）によるビルド性能の向上
- Cargoによるワークスペース単位のパブリッシュ自動化など、開発・配布ワークフローの刷新
- x86_64-apple-darwin（macOS x86_64）のTier 2格下げというサポート方針転換
これらの変化がもたらす実際のインパクトや、背景にある業界全体の流れについて解説します。
見逃せない進化：高速化とワークフロー自動化の舞台裏
1. リンク時間短縮は、想像以上に重要だ
Rustユーザーにとって日々の生産性を左右する「ビルド速度」は、絶えず議論の的です。
公式が指摘する通り：
“LLD should be backwards compatible with BFD, and you should not see any difference other than reduced compilation time.”
LLD（LLVMプロジェクト由来のリンカ）は、従来のGNU BFDリンカよりも多くの場合で高速にリンク処理を終えることで知られています。
とくに、「デバッグ情報の多い大型アプリ」や「逐次ビルド」を日常的に行う開発現場で、その差は顕著です。
実際に、C++界隈でもLLDの普及によって10倍の時短があった事例も報告されています。
RustのデフォルトリンカとしてLLDが採用されたのは、現場の声やベンチマークデータに裏打ちされた選択であり、今後のCI/CDやクラウドビルドのパイプライン高速化にも直結する進化といえるでしょう。
2. Cargo Universe：パッケージ配布の未来系
また、Cargoサブコマンドの進化も見逃せません。
“cargo publish –workspace is now supported, automatically publishing all of the crates in a workspace in the right order (following any dependencies between them).”
従来は、ワークスペース内の複数クレートを正しい順でpublishするのに、外部ツールや人力による手順管理が不可欠でした。
このアップデートでCargo自体が「依存関係のグラフを逆算し、適切な順序で一括公開」してくれるため、ヒューマンエラーのリスクが大幅減。
たとえば企業内やオープンソースの大規模プロジェクトで、「15個のライブラリを一気に更新したいが、依存関係が絡んで深夜リリースでトラブル…」という事態を減らせます。
3. Apple標準アーキテクチャの移行と今後のリスク
最後にmacOS（x86_64）がTier 1からTier 2に格下げされた点。
“as of Rust 1.90, we have demoted the x86_64-apple-darwin target from Tier 1 with host tools to Tier 2 with host tools …”
ここでTierというのは、Rust公式がどこまでビルドテストやサポートを担保するかの「信頼度レベル」に近いものです。
つまり、x86_64のMac上での不具合は、これまでより優先度が下がり、将来的に目立ったバグや非互換が出ても「即修正されない」「下手をすると切り捨てられる」リスクが高くなります。
これは、AppleやGitHubが既にx86_64環境向けのリソース縮小を始めている流れに適応したもの。
逆にいえば、今後はApple Silicon（arm64）へのマイグレーションが「必須」になる時代が本格的に到来することを意味します。
業界動向を踏まえた批判的考察
1. LLDデフォルト化のジレンマ
LLDは基本的にBFD互換ですが、極端に古いシステムや一部の複雑なリンクケースにはまだ「完全移行が難しい」場合もあります。
Rustコミュニティは「–Clinker-features=-lld」で簡単に元のリンカへ戻せる“エスケープルート”も用意している点は評価できますが、それでも新旧ツールチェーンの混在やCI環境の保守には注意が必要。
また、ごく一部のセキュリティ・ミッションクリティカルな業務では「検証済みツールセット縛り」が発生します。
今後は「LLD固有のバグ報告」「既存プロジェクトとのリンク互換性」について、エンタープライズ利用者こそ検証を急ぐべきです。
2. Cargoのワークスペースpublish機能に潜む“非原子的”問題
“Note that publishes are still not atomic — network errors or server-side failures can still lead to a partially published workspace.”
一方で、公式も言及しているとおり「publishは全体でアトミックに（＝すべて成功or全部失敗）」とはなりません。
もし5つのクレートのうち3つ目でネットワーク障害やnpm側の障害が生じた場合、「中途半端に2つだけ新バージョン化されてしまった…」という状況が起こり得ます。
業務運用では「事前にdry-runでバリデーションチェックをかける」など、慎重な手順が引き続き欠かせません。
3. macOS x86_64の切り捨ては何を導くか
Appleはすでにx86_64のMacBookの新規開発・販売を停止し、世界的にもM1/M2以降のApple Silicon（arm64）中心へと強烈にシフトしています。
Rustは業界トレンドを的確に追いつつも、しばらくはx86_64-apple-darwinもTier 2で「最低限のサポート」を維持します。
しかし、今後2～3年でmacOSにおけるx86_64のエコシステムが一気に縮小し、「ある日突然動かなくなった！」となるリスクも高まってきました。
エンタープライズエンジニアや個人開発者は、今のうちに「MシリーズMacやarm64ベースCIへの一本化」「クロスビルドの自動化/検証」など、環境移行を計画的に進めることが急務です。
まとめ：Rust 1.90.0がもたらす未来と、私たちへのアクション
Rust 1.90.0は開発速度・省力化・業界トレンド適応という三拍子で、着実な進化をとげました。
公式が「多くの貢献者に感謝している」と述べている通り、コミュニティとユーザーのフィードバックが形になったアップデートです。
今、現場でRustを使っている方は「LLDリンカへの乗り換えテスト」や「Cargoの新機能を活用した自動化」、macOS x86_64環境の今後に備えた「早期マシン移行やクロスビルド検証」など、余裕をもった準備が求められます。
また、Rust初心者や導入を検討している方にとっても、「モダン言語として時流に乗り遅れない」という安心感・信頼感が、このリリースから伝わってきます。
運用面の注意点（非アトミックなpublish、デフォルトリンカ移行トラブル等）も十分認識し、2026年以降の先を見据えたラスト活用をすすめていきたいところです。
categories:[technology]
コメント