「全部Rustにすればいい」の翌年、半分は書いていなかった――高層ビルは、選んだ土地にしか建たない
2026年11月、チャットアプリ「Discord」の開発責任者が公開したのは、開発中の新規アプリのひとコマだった。メモリ使用量およそ290MB。現行アプリからの大幅な軽量化を狙うこの試みは、ブラウザーを丸ごと同梱する「Electron」をやめ、画面の描き方から作り替える道の途中にある。測定条件が異なる初期ビルドの1例にすぎないが、公開された数字には「Rustにすれば軽くなる」という期待が重ねられた。ただ、その裏側で開発者の評価はもっと静かに割れている。「次に使いたい」が7割を超える一方で、業務で書いていない人が半分。流行の正体と、向く場所・向かない場所の境目を整理する。
人気は本物、現場の半分は「書いていない」
開発者調査Stack Overflowの2025年版では、Rustを使った人の72%が翌年も使いたいと答えた。Google、Microsoft、Cloudflareといった巨大テック企業が基幹システムに採用し、Linuxカーネルでも2025年に導入実験を成功させることで合意されている。人気は本物だ。ただし分母に注意が必要で、回答者全体に広げるとRustの経験者はPythonやCより少ない。Rust公式のコンパイラ調査では、会社でRustを書いていないと答えた人がおよそ半分いた。
しかも、入った場所から出ていくチームもある。データベース周辺ツールのPrismaは、配布や実行環境への対応を見直した結果、独立したRustエンジンからTypeScriptを中心とした構成へ切り替えた。3年間Rustでゲーム開発に取り組んだスタジオは、機能を素早く試すペースが落ちたことを理由に、その言語での開発から撤退している。人気と現場定着の間に、何が横たわっているのか。
メモリ安全は「万能の盾」ではない
境目を理解する鍵は、Rustが売りにするメモリ安全の射程だ。借用チェックコンパイラがメモリ領域の寿命ミスをビルド時に排除するのは事実だが、バグには他にも種類がある。ファイルの存在を確認してから使うまでの一瞬の隙に別の処理が割り込む競合は、型検査を通過した後に起きる。「 unwrap（失敗すれば停止する呼び出し）」を乱用すれば本番環境で落ちるし、標準ライブラリの内部には安全を担保できない「unsafe」領域が実際に存在する。エラーを見つけるコストをビルド時に前払いするか、実行時に後払いするかという設計思想の違いであり、前払いを選んだ結果、試作の速さが犠牲になる現場が出る。
待ち時間という、毎日払い続ける税金
撤退理由で繰り返し登場するのがビルド時間だ。Rustはプログラムの構造を厳密に確認する分、コンパイルに時間がかかる。修正のたびにビルドを繰り返す開発スタイルでは、待ち金が積み上がって税金になる。「微修正で毎回5分待ちは長い」という嘆きは、試作と修正の反復が命であるUI開発やWeb開発で特に重い。対策として語られるのが、画面の描画と裏側の処理を分離し、重いコンパイルを要する部分とそうでない部分を分ける設計だ。つまりRustを「全部」に使うのではなく、効く場所にだけを置いて、反復の速さを守るのである。
本当に光る3つの領域
それでも、Rustが突出する領域ははっきりしている。1つ目はOSやカーネル、ドライバだ。Androidで観測されたデータでは、Rustでの変更はC++より処理完了までの時間が約25%短く、中規模から大規模の変更を差し戻す割合は約4分の1だった。型や借用の検査をコンパイラに任せられる分、人間は動作や設計の確認に時間を使える、とGoogleは説明している。2つ目は、極限の低遅延とメモリ制御が求められる高信頼インフラや通信基盤。Discordが既読状態を扱うサービスを移行した際は、元の環境で数分ごとに観測されていたガベージコレクションに伴う応答時間の跳ね上がりが解消された。3つ目は、起動の速さと処理性能がそのまま武器になるCLIツールやデータ処理ライブラリだ。複数ファイルを並行検索できるripgrep、Pythonのパッケージ管理ツールUV、データ処理ライブラリのPolarsは、いずれも処理の土台にRustを据えている。
「0から書き直し」の壁――95%完成で消えたcurlの実験
基盤領域で優秀だからといって、既存のCやC++のソフトウェアをすべてRustで0から書き直そうとする「RIIR（Rewrite It In Rust）」の流行には、強い警戒が求められている。2026年8月にJetBrainsが公開した検証レポートも、既存システムの全面的な書き直しには重大なリスクがあると指摘する。最も象徴的なのが、世界中の通信で使われるcurlにRust製のHTTPライブラリ「Hyper」を実験的な経路として統合しようとしたプロジェクトの座礁だ。開発者によれば作業は体感95%ほど進み、選択肢としては動いていた。それでも残るプロトコル完成後の作業と保守を続けられず、取りやめになった。
動いていたのに、なぜそこから先が続かなかったのか。何十年も使われてきたC系のソフトには、仕様書にも書かれていない細かい特殊な挙動や、外部との複雑な繋がりが無数に積み重なっている。実際の環境で使われて初めて見つかる挙動もあり、その差を埋めるには、新しい経路のテストと保守を永続的に続けられる人が必要になる。Linuxカーネルでも2025年初め、既存のCの機能をRustから使う窓口について、変更を誰がレビューし誰が保守するかが問題化した。Rustサブシステム担当者（Miguel Ojeda氏）は、既存のC側とRust呼び出し側の保守を分ける方針を示している。Ubuntuも互換性と安全性を検証したうえで、一部の基幹部品はRust製再実装ではなく既存のGNUツールを使い続けることを選んだ。さらに、依存する外部パッケージのビルド中に動くスクリプトや手続きマクロは、アプリを起動する前から開発環境でコードを実行する種別のもので、供給網の安全性という別の論点も生む。
使いどころは「バグのコスト」で決める
残される判断軸は単純だ。その software でバグが起きたとき、いくらの損害が出るか。本番停止やセキュリティ脆弱性が致命傷になる基盤・通信・常駐プロセスなら、ビルド時に前払いする検査のコストは十分すぎるほど元を取る。逆に、今日作った仮説を明日捨ててしまう試作や、画面の作り込みが中心のプロダクトでは、反復の速さの方が価値として上回る。チームの人数や機器の制約、ビルド環境の耐久年数も含めて、「どこからどこまでをRustの領土にするか」の境界線を引く設計力が、これからの実務では問われる。
ネットの反応
そもそも厳格さ云々よりもビルドが遅すぎる。頻繁にビルドする開発だと使い辛すぎる。
GPUIで自分用アプリを作ってるけど、微修正のたびにコンパイル5分待ちは長い。メモリ消費の少なさと速さがあると自分に言い聞かせてる。
堅牢で低レイヤーで長年変わらず使われ続けるLinuxカーネルあたりはうってつけでは。移行の問題はRustに限らずどの言語でもありそう。
Rust開発者はデバッガをほとんど使わないというのが興味深い。定義さえしっかりしてれば脳内デバッグで論理的にいける。静的型の大事さの証拠。
一番ひどいのはRust一つ覚えがビッグデータ処理を手製の変換コードでクラスタに載せて、RustなのにOOMしまくと頭を抱えてた例。実行時間の大半はIOなのに。実績あるマネージドなライブラリでよかった。
PHP系のメモリ安全性が原因の脆弱性トラブルが続発してる現状、Rustのようなメモリ安全な言語がトレンドになるのは当然の流れだと思う。
インタプリタとコンパイラが両立したRustがあれば使うけど、コンパイルは面倒。
AIの所感
「Rustは過大評価か」という問いに、数字を並べると答えは二つに割れる。人気と採用実績の面では過大どころか、カーネルとスマホOSに本格的導入された史上稀に見る成功例だ。一方「全部Rustに」という拡張の仕方は、curlの95%撤回とUbuntuのGNU継続が象徴するように、文化としてほぼ失敗している。本当の教訓は言語の優劣ではなく、ソフトウェア工学の会計原則にある気がする。メモリ安全はビルド時に前払いする保険料のようなもので、事故ったときの賠償額が巨大な領域では驚くほど割に合い、明日捨ててしまう試作では掛け金だけが嵩む。Discordの290MBも、Rust単体の魔法ではなく、Electronという「保険を外した古い建物」を建て替えたうえでの数字だ。高層ビルは地盤のいい土地にしか建たない。だとすれば、次世代のエンジニアに求められるのは新しい言語の熱狂ではなく、どの部屋まで鉄骨にして、どこを木造のまま残すかを見極める間取りの才だろう。