MicrosoftがRustをtier-1にした — 宣言ではなくバックエンドの問題
MicrosoftがRustをtier-1にした — 宣言ではなくバックエンドの問題
プラットフォームベンダーが新しい言語を「一級」として受け入れるのは好意の表明なのか、それとも数十年分のツールチェーン投資を複製しないという決定なのか?
導入
2026年9月10日、Rust Foundationのブログに「RustはMicrosoftでTier-1言語である」というゲスト記事が掲載された。筆者はVictor Ciura、Microsoft DevDiv/CoreAIのRustツーリングチームのプリンシパルエンジニアである。Hacker Newsで701ポイント、コメント459件を記録した。
冒頭の段落は、この発表が方向転換ではないことを明確にする。RustがMicrosoftにとって戦略的に重要であることは、もはや驚くべきことではないというのだ。Azure CTOのMark Russinovichがネイティブコード戦略を示した時点から、Rustプロジェクトの支援に数百万ドルが投じられた以降の数年まで続く流れである。
新しいのは地位の定義だ。記事はこう書く。今日、RustはC++、C#、TypeScriptと並んで、Microsoftの社内開発で最もよく支援されている言語の一つである。この「Tier-1言語」というエンジニアリング上の地位が意味するのは、社内チームにローカル開発から本番までの舗装された道を提供するということだ。安全なツールチェーンのビルド、生産的な開発者ツール、品質ワークフロー、深いプラットフォーム統合、そしてMicrosoftのソフトウェアが満たすべきSDL要件への準拠が、その内容である。
Hacker Newsのある利用者はこのリストをそのまま引用して要点を突き(@gshubert17)、別の利用者は既存のTier 1言語のリストがC++・C#・TypeScriptだったことを明示した(@swiftcoder)。つまりこれは新しい言語を一つ追加した出来事ではなく、三つしかなかったリストを四つにした出来事である。
rustc_codegen_utc — 発表の実際の中身
この記事が単なる広報文と異なるのは中盤からだ。発表の実体は地位の宣言ではなくコンパイラのバックエンドである。
記事はまず問題設定を提示する。WindowsプラットフォームとMSVCは数十年にわたり共進化してきており、CとC++が開発プラットフォームの構成要素だった。MSVCとWindowsが革新を生み出すとき、その機能がC++とRustの両方で利用可能でなければならず、両者の相互運用が滑らかでなければならないというのだ。ハイブリッドなRust/C++プロジェクトにおいてこれは極めて重要である。
その目標に向けた最も重要な投資として示されたのが rustc_codegen_utc だ。これはrustcのための代替コード生成バックエンドであり、rustc_codegen_llvm、rustc_codegen_gcc、rustc_codegen_cranelift と同じアーキテクチャ系統に属する。同一のバックエンドインターフェースに差し込まれ、rustcの共有コンパイラ機構をMSVCバックエンド(UTCと呼ばれる)へ接続する。
何を得ようとしているのか。記事が列挙したリストは具体的だ。Windowsツーリングエコシステムおよび ABI との高い互換性、バイナリのハードニングとコードセキュリティ機能、Hotpatchを含むリンク後の準拠・解析・サービシング、ハイブリッドプロジェクトのための滑らかなRust/C++相互運用、言語をまたぐインライン化・最適化・SPGO(サンプルプロファイル誘導最適化)、デバッグとクラッシュダンプ解析、プロファイリング・診断・カバレッジである。
核心の論理はその次の文にある。これらの能力とワークフローはMSVCの技術スタックの上で長年かけて作られてきた。rustcをそのバックエンドに接続すれば、Windows固有のあらゆる能力を並行して再実装することなく、Rustが同じプラットフォーム投資の上に乗れる。結果はWindowsにおけるRustとC++のための統合されたコード生成プラットフォームだ。
展開状況も数字で示される。rustc_codegen_utc はMicrosoft DevDivの専任チームが投入された主要な投資であり、2026年初頭から本番投入可能な状態だった。Rust 1.90以降セルフホストされており、現時点で100を超えるMicrosoftのプロジェクトリポジトリがこれでビルドしている。このロールアウトは毎週より多くのリポジトリが採用しながら続いている。
なぜLLVMでは足りなかったのか
ここで自然な疑問が出る。Rustは既にLLVMバックエンドでWindowsバイナリを問題なく生成している。なぜバックエンドをもう一つ作るのか。
答えはコード生成の品質ではなく、その周辺のエコシステムにある。記事が挙げた対照がこの点を明確にする。他のプラットフォームでは、ハイブリッドなRust/C++プロジェクトがC++コードをClangでビルドすれば、二つの言語は既に同じLLVMのコード生成プラットフォームに到達できる。rustc_codegen_utc は、MSVCがネイティブのプラットフォームコンパイラであるWindowsネイティブのC++プロジェクトに対して、同じ共有バックエンドの機会を作るというのだ。
つまりこれはRustのための機能ではなく、接合面のための機能である。一つのリポジトリの中にRustとC++が同居し、両方が同じセキュリティレビューと署名、ホットパッチ、クラッシュダンプ解析のパイプラインを通らなければならないとき、二つの言語が別々のバックエンドから出てくるなら、そのパイプラインは二組になる。Hotpatchがリストに含まれていることは特に示唆的だ。再起動なしに稼働中のシステムへパッチを当てる機能は、リンク後のツールチェーンとシンボル情報に強く依存しており、こうした能力は言語ランタイムではなくプラットフォームのツールチェーンに紐づいている。
記事自体もこれが問題の半分であることを認めている。コード生成、プラットフォーム固有の癖、ABI、例外処理、リンク後のツールは相互運用の課題の半分にすぎないというのだ。高忠実度の言語レベル相互運用、FFI契約、バインディング、言語意味論の違い、そしてビルドシステムが、社内と業界全体で取り組んでいる問題の一部として残っていると述べている。
Hacker Newsで出た反応のうち、この発表の性格を最もよく突いたのは次のものだ。ある利用者は、これは非常に大きなニュースであり、CとC++の言語ツーリングで役割を担うすべての主要OSベンダーが、いまやグリーンフィールド開発のためのシステムプログラミング言語の選択肢を多様化したと整理した。そしてMSVC統合に関する噂について、ついに公の情報が出たと付け加えた(@pjmlp)。「噂」という語が重要だ。この作業は2026年初頭から本番投入可能な状態だった。発表は作業の開始ではなく、既に100リポジトリへ展開された後の公表である。
相互運用についての懐疑的な問いも出たが、同じ利用者がWindowsの既存の答えを想起させた。COMとWinRTは、VB 5がVBXをOCXへ置き換えて以来Windowsで言語間相互運用を行う方式であり、.NET Frameworkの設計における中核機能であり、Windows 8でWinRTが導入された際に刷新されたというのだ。windows-rs クレートを見よ、とも付け加えた(@pjmlp)。つまりRustはWindowsで相互運用のために新しい機構を発明したのではなく、既存の機構に編入されつつある。
tier-1が実務で意味すること
この発表をどう読むべきか。まず二つの過大解釈を取り除く方がよい。
第一に、これはC++の終了宣言ではない。記事自身が明記している。RustはMicrosoftでTier-1言語になったが、数十年の開発を経たC++が依然として支配的だというのだ。統合コード生成プラットフォームを使う理由も、両者の保守と進化のコストを最小化するためだと述べている。ハイブリッドなシステムが今後何年も二つの言語を併用するという前提が、文書全体に敷かれている。
第二に、これは開発者体験全般の完成でもない。Hacker NewsでVisual Studio対応の話が出ると、ある利用者は自分がVSでRustバイナリをデバッグしプロファイルしてきたと述べつつ、主な苦労を具体的に挙げた。標準コンテナと列挙型に対するデバッガのビジュアライザ支援が貧弱だったというのだ。彼は標準コンテナ用のnatvisファイルを自分で書いて一部を修正し、そのファイルが何度か壊れたこともあり、自動的にpdbへ含まれないので専用のクレートまで作ったと書いた。その後Rust自体に #[debugger_visualizer] 属性が安定化され、同じ仕事ができるようになったという経緯も添えている(@MaulingMonkey)。別の利用者は、レガシーなC/C++コードベースと共有する必要がある場合を除けば、VSがRustにとって最適な環境ではないだろうと見た(@jeroenhd)。
この二つの視点を合わせると、tier-1の実際の意味が見えてくる。それは「この言語は良い」ではなく「この言語で書いたコードが我々の組織の準拠・セキュリティ・サービシングの手続きを通過できる」という意味だ。社内チームにとって重要なのは表現力ではなく舗装された道である。安全なツールチェーンのビルドがあり、クラッシュダンプを解析でき、SDLレビューを通過し、ホットパッチを発行できるか。これらの問いにすべて「はい」と答えられて初めて、大規模組織における言語の選択肢になる。
実務者にとっての示唆もここから出てくる。組織に新しい言語を導入するとき、議論はたいてい言語の長所をめぐって起きるが、実際に導入を阻むのはほとんど常に周辺のツールだ。ビルドの再現性、依存関係のサプライチェーン検証、デバッグシンボル、プロファイラ連携、セキュリティスキャナの対応、インシデント対応時のダンプ解析といったものである。Microsoftがバックエンドをもう一つ作ってまで解決しようとしたのは、まさにこのリストだ。数十年分のツールチェーン投資を二組維持する代わりに、新しい言語を既存の投資の上へ引き上げる方を選んだのである。
もう一つ注目すべきは、この発表がどこに掲載されたかである。Microsoftの社内ブログではなくRust Foundationのゲストポストであり、記事は最後にRustプロジェクトのZulipにある専用の議論トピックへ読者を案内する。相互運用の残り半分についても財団のInteroperability Initiativeを指し示す。社内バックエンドを作った企業がその成果を財団のチャネルで発表し、アップストリームの議論へ接続する構成は、フォークではなく編入を志向する信号として読む方が自然だ。もちろん信号は約束ではない。rustc_codegen_utc がいつどのような形でアップストリームのrustcで使えるようになるのかは、この記事には書かれていない。
見通しは三つに分かれる。楽観的に見れば、rustc_codegen_utc の存在はWindowsでRustを採用しようとする他の組織にも同じ経路を開く。既に100を超える社内リポジトリが使い、毎週増えているなら、外部公開と安定化は時間の問題かもしれない。悲観的に見れば、バックエンドが一つ増えることは保守負担が一つ増えることだ。LLVMバックエンドでのみ再現するバグとUTCバックエンドでのみ再現するバグが分かれれば、クレートのエコシステムがその差を引き受けることになる。現実的には当面Microsoft社内のユースケースに最適化された状態が続き、外部の採用はWindowsネイティブ統合が切実な領域から選択的に起きるだろう。
結論
この発表で引用に値する一文は地位の宣言ではなく根拠である。記事は rustc_codegen_utc の差別点は単純だと言う。rustcを、MicrosoftがWindowsを中心に数十年かけて構築してきたネイティブバックエンドとプラットフォームのエコシステムへ接続することだ、と。
「Rustがtier-1になった」という見出しは感情的に読まれやすい。しかしこの記事が実際に示したのは勝利宣言ではなくコスト計算である。Windowsのセキュリティ機能、サービシングのツール、診断インフラをRust用に作り直すのか、それともRustをそのインフラへ差し込むのか。Microsoftは後者を選び、その選択が「tier-1」という語の中身を成している。
あなたの組織が次の言語を導入するとき、議論は何をめぐって起きるだろうか。その言語の文法だろうか、それともその言語で作ったバイナリが障害発生時に解析可能かどうかだろうか。二つ目の問いに答えられないなら、導入はまだ始まっていない。
出典: