MicrosoftがRustを「Tier-1言語」に位置付けたというニュースが、窓の杜や@ITで取り上げられていました。MicrosoftがRustに対してどう動いているのかが気になりました。自分の技術選定の幅にRustを入れておけるかも考えたかったので、Rust Foundationに載った原文まで読んでみました。WindowsだけでなくMacのアプリも作れるクロスプラットフォームの選択肢として使えるか、という点も含めて整理します。
原文は誰が何を書いたものか
元記事は2026年9月10日にRust Foundationのブログへ載ったゲスト投稿です。筆者のVictor Ciura氏は、Microsoft DevDiv/CoreAIでRustのツールチェーンとライブラリを担当するPrincipal Engineerです。Microsoftの公式発表というより、社内でRustの基盤を作っている当事者が現状を報告した文章として読むのが近いと思います。
冒頭では、Azure CTOのMark Russinovich氏がRustConfの基調講演でRustへの戦略的な投資を語ったことに触れています。Microsoftが数百万ドル規模でRust Projectを支援してきたことも書かれていました。
「Tier-1」が指すもの
まず整理しておきたいのは、この「Tier-1」がRustコンパイラ側のターゲットTierとは別物だという点です。Rustには、どのOS・CPUの組み合わせをどこまで保証するかを示すTier 1〜3の区分があります。Windows向けのx86_64-pc-windows-msvcは、以前からそのTier 1に入っています。「WindowsでRustが動くようになった」という話ではありません。
今回の話は、Microsoft社内の開発言語としての格付けです。原文では、RustがC++、C#、TypeScriptと並んで「Microsoft社内開発で最も手厚くサポートされる言語の1つ」になったと書かれています。その中身は次のように説明されています。
a paved path from local development to production: secure toolchain builds, productive developer tooling, quality workflows, deep platform integration, and compliance with the SDL requirements.
ローカル開発から本番まで舗装された道がある、という意味です。安全にビルドされたツールチェーン、開発ツール、品質管理のワークフロー、プラットフォームとの統合、SDL（Security Development Lifecycle）への準拠が揃っている状態を指します。大企業で新しい言語を使おうとしたとき、障壁になるのは言語仕様よりこうした周辺の手続きです。そこが既存の主要言語と同じ扱いになったという点に、この発表の重みがあります。
対象の領域として、ファームウェア、ドライバ、カーネル、ハイパーバイザー、マイクロサービス、アプリケーションが挙げられていました。低レイヤーから業務アプリまで、ほぼ全域です。
中心にあるのはMSVCバックエンドとの接続
原文の大半は、rustc_codegen_utcという仕組みの説明に割かれています。RustコンパイラのコードをMSVCのバックエンド（社内では「UTC」と呼ばれている）で生成するための、代替のコード生成バックエンドです。通常のrustcはLLVMでコードを生成しますが、これをWindowsのネイティブコンパイラ基盤につなぎ替えるものです。
これで得られるものとして、原文は次の項目を挙げています。
- Windowsのツール群やABIとの互換性
- バイナリの堅牢化とセキュリティ機能
- Hotpatchを含む、リンク後のコンプライアンス対応と保守
- SPGOを含む、言語をまたいだ最適化とインライン展開
- デバッグ、プロファイリング、カバレッジ、クラッシュダンプ解析
進捗としては、2026年初頭から本番利用できる状態で、Rust 1.90以降はセルフホストされています。すでに100を超えるMicrosoftのリポジトリがこのバックエンドでビルドされ、採用は週単位で広がっているとのことでした。
ここから読み取れるのは、Microsoftが「Rustを使ってよい」と言うだけでなく、C++が長年積み上げてきたMSVCの資産をそのままRustにも使わせる方向へ、専任チームを置いて投資しているということです。
C++を置き換える話ではない
C++との関係について、原文ははっきり共存の立場を取っています。数十年の開発を経たC++がいまも支配的だと認めたうえで、RustとC++が同じプロジェクトに混在する「hybrid Rust/C++ projects」を前提に、両者のシームレスな相互運用を重視すると書いています。
rustc_codegen_utcで言語をまたいだインライン展開ができることも、この文脈で読むと意味がわかります。RustとC++を同じバックエンドに通せば、境界をまたぐ呼び出しも最適化の対象にできます。既存のC++コードを書き直さず、新しく書く部分からRustを混ぜていく進め方を支える仕組みです。
一方で、速度については注意が要ります。原文には、RustとC++の実行速度を比べる記述はありませんでした。RustがC++と同じくネイティブコードにコンパイルされ、ガベージコレクションを持たない言語であることは確かです。ただ今回の発表は「C++並みに速いから推す」という話ではありません。安全性とSDL準拠、そして既存のC++資産との地続きを整えた、という話です。
今後も手厚く支えるのか
「Microsoftは今後Rustを手厚くサポートするのか」という問いには、社内開発に関しては「する」と読んでよさそうです。Tier-1という格付け自体が継続的な支援の約束ですし、原文も最後に、Rustの開発ライフサイクル全体への持続的な投資を強調しています。専任チーム、100を超えるリポジトリでの採用、SDLへの組み込みまで進んでいて、実験段階はもう過ぎています。
ただし、原文が語っているのはあくまで社内開発の話です。rustc_codegen_utcを外部に公開するのか、upstreamに入れるのかについては書かれていませんでした。社外の開発者がVisual StudioやMSVCでRustを同じ水準で扱えるようになるかは、この記事からは判断できません。関連リンクと## 技術選定の幅としてどう見るか
自分の技術選定の選択肢としてRustを見ると、判断の材料は次の3つです。
1つ目は、Windows向けの選択肢として長く付き合いやすくなったことです。OSベンダー自身がTier-1言語に据え、ツールチェーンに投資し続けると言っているので、数年後に梯子を外される心配はしにくくなりました。
2つ目は、RustがWindows専用の言語ではないことです。MacやLinuxでも同じように動くので、Windowsのために覚えたRustがそのままMac向けのアプリにも使えます。デスクトップアプリをクロスプラットフォームで作るときの選択肢として、この点が一番大きいと考えています。具体的な候補が、次に書くTauriです。
3つ目として、速度だけを理由にRustを選ぶ根拠にはなりません。今回の発表が後押ししているのは、メモリ安全性とセキュリティ要件への適合です。速度が決め手なら、C++とRustのどちらでも届く場面は多く、慣れや既存の資産のほうが効いてきます。
の発表が後押ししているのは、メモリ安全性とセキュリティ要件への適合です。速度が決め手なら、C++とRustのどちらでも届く場面は多く、チームの習熟度や既存資産のほうが効いてきます。
自分が一押ししたいのはTauri
普段Webやサーバーの仕事が中心の自分にとって、Windowsのドライバやカーネルは縁遠い領域です。自分の手が届く範囲でこのニュースを受け止めるなら、関心があるのはデスクトップアプリのほうで、個人的に一押ししているのがTauriです。
Tauriは、アプリのロジックをRustで書き、画面はWeb技術で作るフレームワークです。フロントエンドのフレームワークは問わないので、普段使っているReactをそのまま持ち込めます。v2ではLinux、macOS、Windowsに加えてAndroidとiOSにも対応し、同じコードから各プラットフォーム向けのアプリをビルドできます。
Windowsを主戦場にしつつMacとも共存したい、という条件にはかなり素直に合います。バックエンドのRustは、今回MicrosoftがTier-1に据えた言語そのものです。Windows側で表示に使うWebView2もMicrosoft製のコンポーネントなので、OSベンダーが力を入れている部品の上に乗れます。すでにTauriでクロスプラットフォームのアプリを出しているところもあると思うので、選択肢として珍しいものではなくなってきているはずです。
ただ、今回の発表がTauriに直接効くわけではありません。rustc_codegen_utcは社内向けの話で、Tauriでビルドするときは従来どおりLLVMベースのrustcを使います。「OSベンダーがRustを見捨てにくくなった」という間接的な安心材料と捉えるのが正確です。
UIの文脈では悩ましい
一方で、UIの面では手放しで推しにくいところもあります。TauriはElectronのようにChromiumを同梱せず、OSに入っているWebViewで画面を描きます。アプリが小さく済むのはこのおかげですが、裏返すとOSごとに描画エンジンが変わります。WindowsはChromium系のWebView2、macOSはWebKit系のWKWebView、LinuxはWebKitGTKです。
そのため、Webでいうブラウザ差分の確認を、デスクトップアプリでもやることになります。CSSの対応状況やフォントの描画、スクロールの挙動が、WindowsとMacで微妙に違うことがあります。Electronなら「Chromiumで動けばどこでも同じ」と言えた部分を、自分で吸収しなければなりません。
見た目の作法も悩みどころです。Reactで描いた画面は、どちらのOSでも同じ見た目になります。これは一貫性という意味では長所ですが、Windowsらしさ、Macらしさからは外れます。メニューやウィンドウの振る舞いのようにOSの流儀が出る部分をどこまで合わせるかは、アプリごとに決める必要があります。
それでも、Reactで画面を書ける開発体験と、RustのバックエンドでOSの機能に触れられる構成の組み合わせは魅力的です。業務ツールのように見た目の作法より機能と配布のしやすさが効くアプリなら、TauriでWindowsとMacの両方を狙う選択は十分に現実的だと考えています。
既存のデスクトップアプリはRustに書き換えられるか
新規に作るならTauriでよいとして、気になるのは既存のアプリです。技術的には書き換えられますが、元が何で作られているかで手間が大きく変わります。そもそもMicrosoftの原文自体が、書き換えではなく共存を前提にしていました。書き換えるとしても、一気にではなく部分ごとに進める形になります。
元がElectronなら、Tauriへの移行が一番現実的です。画面側のReactはほぼそのまま持っていけます。書き直しになるのは、Node.jsで書いていたファイル操作やOS連携の部分で、これをRustのコマンドにして画面から呼び出す形に変えます。既存のNodeの処理を別プロセス（sidecar）として同梱し、段階的に移す手もあります。ただし前節のとおり、MacではWebKitで描画されるので、Chromium前提で書いた部分は確認が要ります。
元がC#のWPFやWinFormsだと、話は重くなります。Tauriに移すなら画面をWeb技術で作り直すことになり、実質は新規開発です。Rustで画面まで書くライブラリ（egui、Slint、icedなど）もありますが、WPFと同じ水準の部品や開発ツールはまだ揃っていません。C#のままで困っていないなら、移す理由は薄いと思います。
元がC++のネイティブアプリなら、画面はそのままに、中の処理を部品単位でRustへ置き換えていくのが向いています。C++との橋渡しにはcxxクレートなど、Windows APIの呼び出しにはwindows-rsクレートが使えます。Microsoftが社内でやっているのもまさにこの進め方です。
MSVC側の仕組みが外部にも開かれるかどうかとあわせて、引き続き追っておきたいと思います。