経験豊富な Rust 開発者 2 人に「Rust を学ぶ努力は報われたか」と聞くと、まったく正反対の答えが返ってくることがあります。1 人はキャリアには何の役にも立たなかったと言うかもしれませんし、もう 1 人は自分が下した技術的判断の中でも最良のものの一つだと言うかもしれません。どちらも正しい可能性があります。
この矛盾こそが「Rust は学ぶ価値があるのか」という問いの本質であり、一律の「イエス」があなたの役に立たない理由でもあります。Rust はコンパイル言語で、その安全なサブセットは、実行時にガベージコレクタを必要とせずに、メモリ安全性のルールをコンパイル時に強制します。
そこで私は答えを明言し、その答えが依存する条件を示し、その条件にかかるコストをお見せします。
短いバージョン
Rust は、コンパイラが特定の種類のバグを捕まえてくれることにお金を払う価値があるような、長く使い続けるものを作るなら学ぶ価値があります。今月中に CRUD アプリを出荷する必要がある人、これからプログラミングを学ぶ人、求人数を数えている人には向いていません。 評価：5 点中 4 点。元が取れる前にかかるコストの分を減点しています。
- 得られるもの： 安全な Rust では、所有権と借用のルールによって、use-after-free、二重解放、無効な参照、データ競合といったバグが、本番障害ではなくコンパイルエラーになります。売りはこれに尽きますし、良い売りです。
- 支払うもの： コンパイラは、今使っている言語が黙って決めているメモリ上の判断を明示的に書くよう求めます。最初のうちは、ツールが意地悪をしているように感じます。
- 存続性の問題は決着しています。 カーネルのメンテナたちは 2025 年 12 月の Maintainers Summit で Rust の実験を終えると結論づけ、Linux 7.0 で「実験的」というラベルが外れました。
- 流行の問題は決着しておらず、それは別の問題です。 Rust は TIOBE の 2026 年 9 月のインデックスで #10 に位置し、1 年前の #18 から上昇しています。
- 私がテストした Rust サービスは、実行よりもコンパイルにはるかに多くのメモリを必要としました。ビルド中のピークは 1 GB 近く、実行中のアイドル時は約 3.5 MB でした。
- 向いている人： すでに別の言語でプロダクトを出荷していて、メモリバグが高くつくものを作っている人、またはシステムソフトウェアに近い仕事をしている人。 向いていない人： 締め切りに追われている人、ゼロから始める人、求人が最も多い言語を探している人。
このレビューの作り方： ここでのビルドと実行時の数値は私自身のものです。Rust 1.98.1 をインストールし、小さな Axum の Web サービスを書き、コンパイルと実行にそれぞれ何が必要かを測定しました。これは専用ハードウェアではなくサンドボックス化されたコンテナで実行したもので、プロジェクトも 1 つだけなので、数値は法則ではなく一つのデータ点として扱ってください。それ以外はすべて一次情報または信頼できる情報源に基づいています。カーネルパッチとそれに関する LWN の報道、Google の Android セキュリティ関連の投稿、TIOBE 自身のインデックス（4 月のコメントは Slashdot の記録経由）、Linux 7.0 のマージウィンドウに関する Phoronix の記事、Binder の脆弱性に関する Linux カーネルの CVE 記録、Canonical 自身の声明、そして 2025 年の Stack Overflow 調査です。カーネルパッチは読みました。カーネルの Rust コードを監査したわけではありません。また、私は何年も Rust を書いてきたわけではないので、このレビューが言語そのものを評価している部分は、長年書いてきた実践者の意見を読み、その名前を挙げています。
コンパイラが与えてくれるもの
Rust で 2 つのスレッドに同じベクタへの可変参照を渡すと、そのコードはコンパイルできません。警告ではありません。締め切りに追われて抑制できる lint でもありません。ビルドできないのです。この拒否こそが、安全な Rust であなたが買っているものです。use-after-free、二重解放、無効な参照、データ競合のバグは、本番障害ではなくコンパイルエラーへと押し込まれます。Rust の抜け道（unsafe）はこれらの保証の一部を回避できるため、これはすべての Rust コードベースに対する絶対的な約束ではありません。
所有権とは、すべての値に、それを解放する責任を持つ所有者がちょうど 1 つあるということです。借用とは参照を貸し出せるということですが、コンパイラはその寿命を追跡し、参照が指す先より長生きすることも、可変の借用が他の借用と共存することも許しません。安全な Rust では、use-after-free、二重解放、無効な参照、データ競合のバグは、プログラムが実行される前に所有権と型システムによって捕まえられます。
ガベージコレクタがないこと、これが取引のもう半分です。誰が何をいつ解放するかは所有権によってすでに決まっているので、実行時にヒープを追跡する必要はありません。コレクタを含まないバイナリを出荷でき、調整に苦労するような停止時間も発生しません。
代償は、保証と同じ場所に現れます。今の言語があなたに代わって黙って行っているメモリ上の判断は、どれも Rust では明示的に書くよう求められます。誰がこれを所有するのか、その参照はどれだけ生きるのか、ほかの何かがそれを参照できるのか、スレッドの境界をまたぐのか。コンパイラは意地悪をしているのではありません。推測を拒んでいるのです。
つまり、これこそが Rust の求める代償を誰もが払う理由であり、私はそれが妥当だと思います。Rust が排除する種類のバグが、あなたが心配している種類のものでないなら、このレビューの残りを読んでも考えはおそらく変わらないでしょう。
Rust はまだ実験段階なのか、それとも今や本番インフラなのか？
Rust が実験的でなくなったのは 2025 年 12 月で、それを終わらせたのはカーネルメンテナ自身でした。2025 年の Maintainers Summit で、彼らは Rust が技術的にも社会的にもカーネル内で自らの役割を十分に果たしてきたと結論づけました。LWN の Jonathan Corbet は 2025 年 12 月 10 日にその合意を報じています。カーネル内の Rust は もはや実験的ではありません.
Rust が v6.1 でメインラインの Linux に入ったのは 2022 年で、まさにその実験を行うためでした。ラベルを削除する Miguel Ojeda のパッチは Summit の 3 日後に出され、 Linux 7.0 のマージウィンドウで取り込まれました.
「しかし実験は終わった。つまり、Rust はこれからも残るということだ。」
Miguel Ojeda、「rust: conclude the Rust experiment」、LKML、2025 年 12 月 13 日
それとは別に、それより前の出来事として、Google が Rust で書き直した Android の Binder ドライバ（Android のプロセスが絶えず通信に使っている IPC 層）が Linux 6.18 に取り込まれました。6.18 は 2025 年 11 月 30 日にリリースされています。このマイルストーンは Summit での合意とは切り離して考えてください。これはメンテナのグループがアイデアにお墨付きを与えたのではなく、企業が出荷製品をカーネル Rust に賭けたという出来事です。その後、カーネル Rust は初めての CVE を生みました： CVE-2025-68260。これは同じ Binder ドライバの競合状態で、Greg Kroah-Hartman が 2025 年 12 月 16 日に発表しました。6.18 で混入し、6.18.1 で修正されています。初期の報告はクラッシュに焦点を当てていましたが、Linux カーネルの CVE チームによる後のスコアリングでは CVE-2025-68260 は 7.8（High）と評価され、カーネルメモリの破壊を通じたローカル権限昇格の経路が説明されています。同じドライバ（rust_binder）には、その後も追加の CVE が積み重なっています。
Android では、証拠が数字で示されます。Google のセキュリティブログは 2022 年 12 月に、Android の Rust コードでは メモリ安全性の脆弱性が 1 件も発見されていない と述べています。対象は AOSP 内の約 150 万行の Rust コードで、Android 13 の新規ネイティブコード全体の約 21% にあたります。これは 2022 年時点の範囲での 2022 年の声明です。Google のその後の投稿は、より長期の傾向を示しています。メモリ安全性の問題は 2019 年には Android の脆弱性の 76% を占めていました が、2024 年には 24% になり、件数そのものも 220 件超から 36 件（予測）へと減少しています。これらの数字が意味を持つのは、置き換えた基準と比べたときだけです。その基準とは、非常に優秀なエンジニアが非常に優れたツールを使って書いた C と C++ です。
同じ方向を指す小さなシグナルがあと 2 つあります。 Asahi Linux の Apple AGX GPU ドライバは Rust で書かれており、Apple ではなく Asahi Linux プロジェクトがリバースエンジニアリングの取り組みとして開発したものです。 Canonical の rust-coreutils に関する発表によると、 Ubuntu 26.04 LTS はほとんどのユーティリティに rust-coreutils 0.8.0 を採用しています。3 つは GNU coreutils のまま残ります（cp, mv, rm）。2026 年 4 月 22 日の時点で TOCTOU の問題が 8 件未解決だったためです。Canonical は残りのユーティリティについて 26.10 を目標にしています。
これは私が最も高く評価する軸で、その理由は関わっているコミットメントの種類にあります。カーネルメンテナは一度結論づけた実験を撤回しませんし、Google はあの規模の書き直しを巻き戻しませんし、Canonical は様子見のために書き直した coreutils を LTS に入れたりしません。Rust の人気がどうなろうと、誰かがそのコードを何年も保守しなければならないのです。
Rust は終わったのか、それとも伸びが落ち着いただけなのか？
いいえ。Rust は 2026 年 1 月に TIOBE で過去最高タイの #13 に並びました。3 か月後には #16 に後退し、TIOBE の CEO である Paul Jansen は 2026 年 4 月、当時 Slashdot が引用したコメントの中で、Rust の人気の伸びは「頭打ちになりつつあるようだ」と書き、トップ 10 入りは「以前よりも遠のいたように見える」と述べました。
彼が述べていたのは、Rust が彼自身のインデックスで 過去最高の順位に達し その後それを手放したことでした。この順位には 2024 年 7 月に初めて到達していました。
TIOBE の 2026 年 9 月のインデックスでは、 Rust は #10 で、1 年前の #18 から上昇し、TIOBE が 1 月に過去最高と呼んだ #13 も超えています。
私の見方：頭打ちは本物でした。ただしそれはエアポケットであり、天井ではありませんでした。これはどちらの陣営の言い分よりも正確です。「Rust は失速した」は今では誤りですし、「Rust は上がる一方」は一度も正しかったことがないからです。
この注意点は両方向に効きますし、Slashdot の記事も当時それを指摘していました： ランキングは検索エンジン結果の月ごとのノイズで変動しているだけではないか インデックスが数えているのは、まさにその検索結果です。四半期で 3 つ順位が下がったことが Rust の失速を示す薄い証拠だったなら、6 つ順位が上がったことも Rust が勝っていることを示す薄い証拠にすぎません。天気として扱い、気候として扱わないでください。
感情面でより強いシグナルは Stack Overflow の調査で、Rust は またしても最も称賛される プログラミング言語に選ばれました（2025 年、72%）。過去 1 年間に使用し、今後も使い続けたいと答えた人の割合です。これは採用率ではなく継続利用の意向であり、この言語を続けて楽しめるかどうかを判断するなら、単なる人気よりも役に立つシグナルです。
勢いは曖昧で、私は上で述べた存続性よりも低く評価します。あなたが投資するのはランキングではないからです。
Rust を学ぶことのコスト
コストは早い段階で一気にやってきます。Python や Java や C# なら喜んで実行してくれるコードが、所有権モデルが腑に落ちるまでは理不尽に感じる理由で何度も拒否されます。そしてそれを先送りする方法はありません。ORM を完全に理解していなくても出荷でごまかせるようには、借用チェッカーを出荷でごまかすことはできません。
ここで私が驚いたのは、予想とは逆の方向に進む点です。r/rust の「Struggling to learn Rust」スレッドでは、最も反響を集めた返信が問題を難しさではなく不慣れさとして捉え直しており、スレッド全体としても、ガベージコレクション言語から来た経験豊富な開発者こそが苦労していると指摘しています。u/Voxelman はこう率直に述べています： 「Rust は難しくない。違うだけだ。」 同じスレッドで、彼らは自分自身の道のりも語っています。C64 Basic から始まり、さまざまな命令型言語を経て、初めて Rust に触れたときは「まったく WOW ではなかった」。古い習慣を捨てるのに時間がかかったからです。
それが請求書の中身です。8 年間 Python を書いてきた人は、ルールの集合を学ぶのではなく、誰が後片付けをしてくれるかという前提の集合を手放すことになります。知っていることが少ない人ほど、捨てるものも少ないのです。
もう 1 つ、そのスレッドで繰り返し現れるパターンがあり、それは順序の誤りを自信の問題に変えてしまいます。人々は Rust そのものではなく Web フレームワーク選びでつまずき、所有権が身につく前に Axum や Actix を通して言語を学ぼうとするのです。u/jmartin2683 の言葉を借りれば、それは 「rails を学ぶことで ruby を学ぼうとするようなもの」です。
コストに関する警告の多くは、的外れなものを指していると私は読んでいます。週末ではなく、継続的な練習の時間を確保してください。そして初期の挫折を、自分の能力に対する評決だと受け取らないでください。
Rust は実行よりビルドに大きなマシンが必要
意外だった発見はこれです。この Rust プロジェクトのビルドには、実行時より桁違いに多くのメモリが必要でした。私は小さな Axum サービス（Tokio の full フィーチャーセット、serde、serde_json、tower、JSON ルート 1 つ、依存ツリーに約 60 のクレート）を rustc と cargo 1.98.1 でビルドしました。リリースプロファイルには strip = true を設定し、クリーンな状態から 2 回ビルドしました：
# constrained: one compile job at a time
cargo build --release --jobs 1
# unconstrained: default parallelism, 4 vCPUs available
cargo build --releaseコンパイルジョブを 1 つに制限した場合（--jobs 1）、cargo、rustc、リンカ全体でのピークメモリは、2 つの測定方法のどちらを採るかによって 464 MB から 527 MB の間でした（最初の数値があまりにきれいに見えたので、2 通りの方法で測りました）。所要時間は 113 秒です。4 つの vCPU でのデフォルトの並列度では、ピークメモリはおよそ 2 倍の約 1 GB になり、ビルドは約 35 秒で終わりました。変数はプロジェクトではなく並列度です。ジョブが増えるほど同時に常駐する rustc プロセスも増えます。だからこそコンパイラは、何分も続けて 与えられたコアをすべて喜んで使い切る 数少ないワークロードの一つなのです。
完成したプログラムは strip 後で 1.3 MB、アイドル時のメモリ使用量はおよそ 3.3〜3.6 MB です。
デフォルトの並列度では、コンパイルに必要なメモリは実行時の 200〜300 倍です。ジョブを 1 つに制限しても、100 倍を優に超えます。本番で Rust サービスが必要とする分に合わせてサーバーのサイズを決めると、そのサービスをビルドできないマシンになってしまうことがあります。しかも失敗の仕方はきれいなエラーではありません。ビルドの途中で OOM キラーが rustc を強制終了するか、コンパイラが 20 分間スワップでスラッシングするかです。有効な答えは 2 つあります。1 つは余裕のある場所でビルドしてバイナリを出荷すること、つまり ビルド専用のマシンを分ける やり方で、重い Docker 作業と同じパターンです。もう 1 つは、そのマシン上でビルドし、余裕を持たせることです。この形のサービスなら、RAM 数 GB と vCPU 2 つあれば快適です。足りない場合の逃げ道は --jobs 1 です（そう、遅くなります。それがトレードオフです）。
作業しているマシンにその余裕がないなら、当社の セルフマネージド Linux VPS なら、時間単位または月単位の課金で root アクセスが得られ、ビルドを置いて、終わったら手放せる場所になります。ただし、これはあくまで自分で運用するサーバーであり、勝手に運用してくれるサーバーではありません。
1 つのプロジェクト、1 つの形、1 台のマシンです。マシンは専用サーバーではなく共有のサンドボックス化されたコンテナで、利用可能なメモリはおよそ 2 GB でした。そのため、制限なしでのピークは、より大きなマシンの場合よりも上限に近いところで動いていました。これは普遍的な定数ではありません。依存ツリーが 4 倍の大きさだったり、リリースプロファイルでリンク時最適化を有効にしたりすれば、数値は変わると考えてください。依存ツリーが大きいほど、またリンク時最適化やジェネリクスを多用したコードでは、ビルド時のメモリはさらに増えることがあります。私の測定値を普遍的な上限とは考えないでください。
これは、この言語を学ぶかどうかではなく、どう作業するかの問題に分類します。ぶつかる前に知っておいてください。
Rust を学ぶべき人
時間をかける価値があると私が言う状況は 3 つです。メモリバグが高くつく長寿命のソフトウェア、OS に近い仕事、そしてコンパイラと格闘することがメモリについての考え方にもたらす変化を求める場合です。どれにも、その時間が報われる理由があります。
すでに別の言語でプロダクトを出荷していて、メモリバグが高くつく長寿命のものを作っている。 稼働し続けなければならないサービス。他のチームが依存するライブラリ。use-after-free がターミナルのスタックトレースではなくインシデントレビューを意味するもの全般。これこそが、この保証全体が想定しているケースであり、最初に払うコストは作っているものの寿命全体で償却されます。
システムソフトウェアの近く、またはその内部で仕事をしている。 ドライバ、デバイス関連の作業、ベースシステムのユーティリティ、組み込み、OS の上ではなく下にあるものすべて。業界はここで、他の分野ではしていない形でコミットしており、メモリ安全性の証拠もここが最も強力です。
副次的な効果が欲しい。 あの r/rust スレッドの 2 人のコメント投稿者は、Rust のキャリア上の価値についてはまったく意見が異なりますが、この点では同じ結論にたどり着いています。 u/tyler_church、つまりキャリアへの影響はゼロだったと言う人でさえ、「他の言語で他のプログラムを書く方法への、もしかすると微妙な影響」はあったと認めています。 u/SirKastic23、つまり Rust を書いて報酬を得るようになって 2 年の人は、予想もしなかった形でコーディングスキルが広がったと言います。研究ではなく 2 人の意見にすぎませんが、Rust を仕事で書くことが一度もなくても残る見返りはこれです。履歴書の 1 行ではなく、考え方の変化です。
Rust を学ぶべきでない人
その時間を別のことに使ったほうがよい状況は 3 つです。今月中に締め切りがある、そもそもプログラミングを学んでいる最中である、あるいは求人での言及数で言語を選んでいる。最もよく質問されるのは 3 つ目です。
今月中に CRUD アプリやプロトタイプの締め切りがある。 Rust は、金曜日までに形になっていなければならない仕事にとって、まさに最悪のタイミングでやってきます。高速なビルドとガベージコレクションによるメモリ管理を備えたコンパイル言語が欲しく、Rust の所有権ベースの保証が不要なら、代わりに Go を選ぶのが自然です。
そもそもプログラミングを学んでいる最中である。 これは Rust で生計を立てている人たちの間でも本当に意見が割れる点で、r/rust のスレッドでの対立は両方向に及んでいます。なので私の立場は、コインがどちらに落ちるかにかかわらず、初心者にコイン投げを渡すのは悪いアドバイスだ、というものです。まずはもっと寛容な環境でマシンの仕組みを学び、それから戻ってきてコンパイラに締め直してもらいましょう。
求人での言及数で言語を選んでいる。 ここで数字は挙げません。Rust の給与や求人数について、私が擁護できる情報源までたどれる数字が見つからなかったからです。u/crusoe があの r/rust スレッドで述べているのは、ポジションが少なく、より専門的な市場です。これは 1 つのスレッドの 1 人のコメント投稿者の話であって労働市場のデータではないので、Rust の仕事が全般的に少ないという主張にするつもりはありません。求人の数が決め手になるなら、言語を選ぶ前に、目標とする市場の現在の求人を確認してください。
よくある質問
Rust は無料ですか？
はい。言語とその公式プロジェクトは 一般的にデュアルライセンスとなっており、 MIT ライセンスと Apache License 2.0 の 2 つが適用されます。ツールチェーンは rustup で無料でインストールできます。有料プランも、購入すべき商用ライセンスもありません。
Rust を習得するにはどれくらいかかりますか？
すでにプログラミングができるなら、構文はたいてい簡単な部分です。所有権と借用は、メモリについての考え方を変えるので時間がかかります。さらにライフタイムと非同期 Rust が、後からもう一段階の難しさを加えます。万人に当てはまる根拠のある期間は見つからなかったので、数字を挙げるつもりはありません。
Rust は最初のプログラミング言語として適していますか？
私の答えは「いいえ」ですが、この問いは経験豊富な実践者の間でも意見が分かれていることを知っておいてください。r/rust の「Struggling to learn Rust」スレッドで、 u/cassepipe は、Rust で一度挫折し、C と C++ を経由して戻ってきた経験から、Rust は「最初の言語としては良くない」ときっぱり言っています。一方で u/Voxelman は正反対の主張をしています。命令型言語は、後で捨てなければならない習慣を教えるので、始めるには悪い場所だというのです。同じ意見の対立は、 Rust 自身のユーザーフォーラムでも 4 ページにわたって続いています。報告できるような、コミュニティとして決着した答えはありません。
Rust は C++ を置き換えつつありますか？
いいえ。Rust は C や C++ と並んで追加され、特定の新しいコンポーネントに選ばれています。これは置き換えとは別のことです。Linux カーネルでは、Rust は既存の C コードベースを丸ごと置き換えるのではなく、それと並行して追加されています。Android では、Google が表明しているアプローチは、既存の C や C++ を変換するのではなく、新しいコードをメモリ安全な言語で書くというものです。長期間の共存を想定してください。
Rust は Go より速いですか？
これはベンチマークしていないので、どちらかが絶対的に速いとは言いません。Rust はメモリ割り当てをより細かく制御でき、ガベージコレクタを必要としません。Go はガベージコレクション付きのランタイムを使い、低レベルの制御の一部と引き換えに開発をシンプルにしています。どちらが速いかはワークロード、実装、ボトルネックによって決まるので、自分のアプリケーションに近いベンチマークを使ってください。
ディスカッション
コメント
ログインしてディスカッションに参加してください。