1 章 · 2026 年のモダン Rust — 2024 edition がもたらしたもの

2025 年 2 月 20 日、Rust 1.85 がリリースされた。そして同じ日、**2024 edition** が新規プロジェクトのデフォルトになった。Rust の edition は 3 年周期でやってくる「言語設計の決算」で、2015 → 2018 → 2021 を経て 4 つ目にあたる 2024 は、非同期とライフタイムをもっとも大きく見直した。

主要な変化 5 点:

1. **RPIT ライフタイムキャプチャの規則変更(`-> impl Trait`)** — スコープ内のライフタイムをすべてキャプチャするようになった。以前 `.unwrap()` や `boxed()` で逃げていた `+ '_` の地獄が大幅に減る。

2. **trait に `async fn` が正式に入った** — 1.75 で安定化された AFIT が 2024 edition と組み合わさり、`dyn` trait の async もライブラリで受けやすくなった。

3. **`gen` ブロック / `gen fn`** — Python の generator 風文法が Rust に入った。`Iterator` を手書きする機会が減る。

4. **async closures (`async ||`)** — クロージャの中でもう一度 `async move { ... }` を包むパターンがなくなる。

5. **never type fallback が `!` に統一** — 以前は推論が曖昧だと `()` に落ちていたが、いまは `!` に落ちる。エラーメッセージが明確になり、「なんでコンパイラがこれを選ぶ?」の瞬間が減る。

この 5 つを合わせると、「2021 edition で書いた Rust」と「2024 edition で書いた Rust」は同じ言語に見えない。Web / サーバを書く人にとってとくに体感が大きい — Tokio 1.x + Axum 0.8 + Tower の組み合わせは「Express 級の軽量コード」に近づいた。

本稿はその変化のうえに乗っている 2026 年 5 月時点の Rust エコシステムをまとめて見る。Web、DB、ゲーム、デスクトップ、モバイル、ML、組み込み、ツール、IDE — そして韓国・日本の導入状況まで。

2 章 · Rust 1.85 + Edition 2024 — gen blocks、async closures、never type fallback

2.1 gen blocks — Iterator を手書きしなくていい

// 2021 edition: Iterator を手で実装

struct Counter { n: u32, max: u32 }

impl Iterator for Counter {

type Item = u32;

fn next(&mut self) -> Option<u32> {

if self.n < self.max { self.n += 1; Some(self.n) } else { None }

}

}

// 2024 edition (1.85, gen gate を通過したとき): gen fn

gen fn counter(max: u32) -> u32 {

let mut n = 0;

while n < max {

n += 1;

yield n;

}

}

`yield` がキーワードになり、`gen fn` は自動で `impl Iterator<Item = u32>` にコンパイルされる。async 版 `async gen` / `Stream` 統合も同じトラックで進む。

2.2 async closures

// 2021 edition: クロージャの中で async move {} をもう一度包む

let xs = vec![1, 2, 3];

let futs = xs.into_iter().map(|x| async move { process(x).await });

// 2024 edition: async closure そのもの

let xs = vec![1, 2, 3];

let futs = xs.into_iter().map(async |x| process(x).await);

`tokio::spawn` / `futures::join_all` / `stream::then` あたりのコードが一行ずつ短くなる。

2.3 RPIT ライフタイムキャプチャ

// 2021 edition: 'a を明示的にキャプチャしないとコンパイルエラー

fn names<'a>(xs: &'a [String]) -> impl Iterator<Item = &'a str> + use<'a> {

xs.iter().map(|s| s.as_str())

}

// 2024 edition: スコープ内のライフタイムが自動でキャプチャされる

fn names<'a>(xs: &'a [String]) -> impl Iterator<Item = &'a str> {

xs.iter().map(|s| s.as_str())

}

`+ use<'a>` のような注釈がいらなくなる。トレードオフは「以前キャプチャされなかったライフタイム」がキャプチャされ、一部コードが意図せず使えなくなる可能性があること — migration lint が指摘する。

2.4 never type fallback

`Result::Err::<i32, _>(panic!())` で `_` が以前は `()` に推論され、奇妙な trait 衝突を起こすことがあった。いまは `!` に落ちる。マクロを書く人がほっとする変化。

3 章 · Tokio — async ランタイムの標準

2026 年時点、Rust の async ランタイムは **事実上 Tokio 1.x の単独標準**。競合は `async-std`(開発停滞)、`smol`(組み込み / シングルスレッド)、`monoio`(Cloudflare 製、io_uring 専用)程度。

Tokio が標準になった理由:

- **エコシステムの重さ**: hyper、reqwest、sqlx、tokio-postgres、axum、tower、tonic すべて Tokio 上で動く

- **スケジューラの品質**: work-stealing スケジューラは Go の GOMAXPROCS 並みに成熟

- **`tokio::select!` / `JoinSet` / `LocalSet`** のような一級機能

- **io_uring サポート**(`tokio-uring`) — Linux でネットワーク IO を syscall 一回で処理

// もっとも基本的な Tokio サーバ

use tokio::net::TcpListener;

use tokio::io::{AsyncReadExt, AsyncWriteExt};

#[tokio::main]

async fn main() -> std::io::Result<()> {

let listener = TcpListener::bind("0.0.0.0:8080").await?;

loop {

let (mut socket, _) = listener.accept().await?;

tokio::spawn(async move {

let mut buf = vec![0; 1024];

loop {

let n = match socket.read(&mut buf).await {

Ok(0) => return,

Ok(n) => n,

Err(_) => return,

};

if socket.write_all(&buf[..n]).await.is_err() { return; }

}

});

}

}

`#[tokio::main]` はマルチスレッド work-stealing ランタイムを作り、`tokio::spawn` はその上にタスクを投げる。シングルスレッドが必要なら `current_thread` ランタイムへ — 組み込み / WASM ではこの選択が重要になる。

4 章 · Axum 0.8 — Tower ベースの人気 Web フレームワーク

Axum は Tokio チームが直接作る Web フレームワーク。2024 年 11 月の 0.8 でルータのパス構文が `:id` → `{id}` 形式に変わったのが最大の変更点。

use axum::{Router, routing::get, extract::Path};

#[tokio::main]

async fn main() {

let app = Router::new()

.route("/", get(|| async { "hello" }))

.route("/users/{id}", get(get_user))

.route("/health", get(|| async { "ok" }));

let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await.unwrap();

axum::serve(listener, app).await.unwrap();

}

async fn get_user(Path(id): Path<u64>) -> String {

format!("user {}", id)

}

Axum の魅力:

1. **Tower ミドルウェアと互換** — `tower-http` の `CompressionLayer`、`TraceLayer`、`CorsLayer` をそのまま差し込める

2. **Extractor が関数シグネチャに乗る** — `Path`、`Query`、`Json`、`State` を引数で受けると自動パース

3. **型でルーティングを保証** — ハンドラの署名が間違っていればコンパイルエラー

4. **WebSocket / SSE が一級サポート**

use axum::{Json, extract::State};

use serde::{Deserialize, Serialize};

#[derive(Deserialize)] struct CreateUser { name: String }

#[derive(Serialize)] struct User { id: u64, name: String }

async fn create_user(

State(db): State<DbPool>,

Json(body): Json<CreateUser>,

) -> Json<User> {

let id = sqlx::query_scalar!("INSERT INTO users(name) VALUES($1) RETURNING id", body.name)

.fetch_one(&db).await.unwrap();

Json(User { id: id as u64, name: body.name })

}

このパターンが 2026 年の Rust バックエンドの事実上の標準。Loco もこの上に乗っている。

5 章 · Actix-Web 4 / Rocket 0.5 — 性能 vs DX

5.1 Actix-Web 4 — ベンチマークの王

TechEmpower ベンチマークで Actix-Web はほぼすべてのラウンドで上位を守る。独自のアクターシステム(`actix`)があるが、4.x は Tokio 互換性を高めたので普通の async/await でも問題なく動く。

use actix_web::{get, web, App, HttpServer, Responder};

#[get("/users/{id}")]

async fn get_user(path: web::Path<u64>) -> impl Responder {

format!("user {}", path.into_inner())

}

#[actix_web::main]

async fn main() -> std::io::Result<()> {

HttpServer::new(|| App::new().service(get_user))

.bind("0.0.0.0:3000")?

.run()

.await

}

「数字でもう 1ms 削りたい」ときは Actix を見る。難点はエラー処理 / ミドルウェア API が Axum/Tower ほどスッキリしていないこと。

5.2 Rocket 0.5 — ついに async

Rocket はマクロ駆動 macro-magic スタイルで有名だが、async 化が遅すぎた(2023 年 11 月にやっと 0.5 stable)。2026 年は学習用 / 社内ツール / 趣味用としてはまだ魅力的だが、本番級の新規プロジェクトは Axum/Loco に流れる傾向。

#[macro_use] extern crate rocket;

#[get("/users/<id>")]

async fn get_user(id: u64) -> String { format!("user {}", id) }

#[launch]

fn rocket() -> _ {

rocket::build().mount("/", routes![get_user])

}

直感的ではある。ただし同じ機能を Axum のほうがより素直に書ける。

6 章 · Loco — Rails for Rust

Loco は 2023 年 8 月に登場した、**「Rust の Rails」**を標榜するフルスタックフレームワーク。Axum + sea-orm + tower + sidekiq-rs のようなコンポーネントを束ね、「scaffold 一行で CRUD が動く」体験を作る。

cargo install loco-cli

loco new my_app

cd my_app

cargo loco start

Rails 風 generator

cargo loco generate scaffold post title:string body:text

cargo loco db migrate

cargo loco start

この 2 行で `/posts` の CRUD ルータ、sea-orm モデル、マイグレーション、validator、view までできる。バックグラウンドワーカーは Sidekiq、メールは `lettre`、認証は JWT — 束が決まっているので決定コストが低い。

Loco のポジション:

- **Rails / Phoenix / Laravel が好きだが Rust に移りたい人**

- 「Rust で何を選ぶか」の決定疲れが大きいチーム

- 難点: 束が決まっているぶん、その束から外れようとすると素の Axum を書くより重い

2026 年時点、Loco は 0.13 前後で安定化中で、韓国・日本のスタートアップでも「サイドプロジェクトとして一番負担の少ない Rust フルスタック」という評価が増えている。

7 章 · Leptos 0.7 — fine-grained reactivity フロント

Leptos は SolidJS に着想を得た **fine-grained reactivity** モデルの Rust フロントエンドフレームワーク。0.7(2024 年後半 → 2025 年安定)で reactive system が大きく書き直され、SSR / hydration / islands がいっそう滑らかになった。

use leptos::prelude::*;

#[component]

fn Counter() -> impl IntoView {

let (count, set_count) = signal(0);

view! {

"Count: " {count}

}

}

fn main() { leptos::mount::mount_to_body(Counter); }

Leptos の魅力:

1. **VDOM がない** — signal が直接 DOM ノードを更新。React より速くメモリも少ない

2. **`view!` マクロ**が JSX 風の文法を提供

3. **SSR + hydration** が Rust 一言語で完結(Next.js のような分離がない)

4. **`cargo-leptos`** がビルド / HMR / SSR サーバをまとめる

5. **server functions** — `#[server]` マクロで関数をサーバで実行、クライアントから呼べる

#[server(GetTodos)]

async fn get_todos() -> Result<Vec<Todo>, ServerFnError> {

let pool = use_context::<DbPool>().expect("pool");

sqlx::query_as!(Todo, "SELECT * FROM todos").fetch_all(&pool).await

.map_err(|e| ServerFnError::new(e.to_string()))

}

この関数はクライアントが直接呼べる RPC になる — type-safe、no boilerplate。Remix loaders / Next server actions / SolidStart actions と同じコンセプト。

8 章 · Dioxus / Yew — React/Elm 風オプション

8.1 Dioxus — React-like

Dioxus は React にもっとも近い Rust フロントエンド。VDOM があり、hooks があり、コンポーネントが関数。2024 年に 0.6、2025 年に 0.7 と上がり、「デスクトップ・モバイル・Web・サーバ」を一つのツリーからビルドする。

use dioxus::prelude::*;

fn App() -> Element {

let mut count = use_signal(|| 0);

rsx! {

button { onclick: move |_| count += 1, "Count: {count}" }

}

}

fn main() { dioxus::launch(App); }

`dioxus serve` 一行でデスクトップ・Web・iOS・Android が同じコードから出る — Tauri / Capacitor と違う、独自のレンダラトラック。

8.2 Yew — Elm/React-like、もっとも古い選択肢

Yew は Rust フロントエンドの中でもっとも古い(2017)プロジェクト。Elm 風のメッセージパターンから始まり、いまは React hooks に似た API に落ち着いている。Leptos / Dioxus が新しく見えるが、Yew は安定性とドキュメントの良さが武器。

use yew::prelude::*;

#[function_component]

fn Counter() -> Html {

let count = use_state(|| 0);

let onclick = {

let count = count.clone();

Callback::from(move |_| count.set(*count + 1))

};

html! { <button {onclick}>{"Count: "}{*count}</button> }

}

fn main() { yew::Renderer::<Counter>::new().render(); }

選択ガイド(2026 年 5 月時点):

- **Fine-grained reactivity + SSR がコア → Leptos**

- **React 風メンタルモデル + フルスタックでモバイル / デスクトップまで一つのコード → Dioxus**

- **実績あるライブラリ・ドキュメント・チュートリアル → Yew**

9 章 · データベース — sqlx / Diesel 2 / SeaORM

9.1 sqlx — async、raw SQL、コンパイル時チェック

sqlx は raw SQL を書きつつ **コンパイル時に DB に接続してクエリを検証する**。マクロが魔法。

use sqlx::PgPool;

#[derive(sqlx::FromRow)]

struct User { id: i64, name: String }

async fn get_user(pool: &PgPool, id: i64) -> Result<User, sqlx::Error> {

sqlx::query_as!(User, "SELECT id, name FROM users WHERE id = $1", id)

.fetch_one(pool).await

}

`query_as!` マクロがコンパイル時に PostgreSQL に接続して `id` / `name` カラムの型を検証する。CI で SQL のタイポを捕まえる。難点: ビルド環境に DB が必要(`sqlx prepare` で offline モード可)。

9.2 Diesel 2 — sync ORM の定石

Diesel は sync API + 強力な型ベースのクエリビルダ。2022 年の 2.0 で ergonomics が大きく改善。async が必須でなければ(CLI、シングルスレッドのワーカー、マイグレーションツール)Diesel はまだ強い。

use diesel::prelude::*;

#[derive(Queryable)]

struct User { id: i64, name: String }

let users: Vec<User> = users::table

.filter(users::name.like("alice%"))

.load(&mut conn)?;

9.3 SeaORM — async ORM、ActiveRecord スタイル

SeaORM は sea-orm-cli で DB から entity を生成し、`Entity::find().filter(...).all(&db).await` のような ActiveRecord 風 API を提供する。Loco が SeaORM を採用したことで地位を上げた。

use sea_orm::{EntityTrait, QueryFilter, ColumnTrait};

let users = users::Entity::find()

.filter(users::Column::Name.contains("alice"))

.all(&db).await?;

選び方:

- **raw SQL に慣れていてコンパイル時チェックが重要 → sqlx**

- **型ベースのクエリビルダ + sync で OK → Diesel 2**

- **ORM スタイル + async + 多様な DB サポート → SeaORM**

10 章 · Bevy 0.15 — ECS ゲームエンジン

Bevy は Rust 代表のゲームエンジンで、**ECS(Entity-Component-System)**アーキテクチャが核。2024 年 11 月リリースの 0.15 は required components、animation system の書き直し、picking、エラーハンドリング標準化が目玉。

use bevy::prelude::*;

#[derive(Component)] struct Player;

#[derive(Component)] struct Velocity(Vec3);

fn main() {

App::new()

.add_plugins(DefaultPlugins)

.add_systems(Startup, spawn_player)

.add_systems(Update, move_player)

.run();

}

fn spawn_player(mut commands: Commands) {

commands.spawn((Player, Velocity(Vec3::ZERO), Transform::default()));

}

fn move_player(time: Res<Time>, mut q: Query<(&mut Transform, &Velocity), With<Player>>) {

for (mut t, v) in &mut q {

t.translation += v.0 * time.delta_secs();

}

}

ECS の本質は「データ(Component)と振る舞い(System)を分離し、システムは自分が見たいコンポーネントの組み合わせだけをクエリする」。OOP ゲームコードでおなじみの多重継承 / 巨大な base クラスがなくなる。

2026 年時点の Bevy:

- インディーゲーム / Game Jam でシェアが急上昇

- 大手スタジオは Unity / Unreal を離れられないが、「Unity が価格政策で揺れる間に Rust 側へ漏れ始めた」シグナルが見える

- 弱点はいまだエディタ(公式エディタは alpha)とモバイルビルドパイプライン

11 章 · Tauri 2 — デスクトップ + モバイル

Tauri は Electron の代替。webview を native で起動(macOS は WKWebView、Windows は WebView2、Linux は WebKitGTK)し、バックエンドロジックは Rust で書く。**2024 年 10 月リリースの Tauri 2** の最大の変更点は **モバイル(iOS / Android)対応**。

cargo install create-tauri-app

cargo create-tauri-app

cd my-app

cargo tauri dev

iOS / Android ビルド

cargo tauri ios dev

cargo tauri android dev

Tauri vs Electron:

| 項目 | Tauri 2 | Electron |

| --- | --- | --- |

| バックエンド言語 | Rust | Node.js |

| webview | OS native | Chromium バンドル |

| バイナリサイズ | ~3-10 MB | ~80-150 MB |

| メモリ | ~50-100 MB | ~150-400 MB |

| モバイル | iOS/Android | 非対応 |

Electron の圧倒的な強みは「Chromium がどこでも同じ」こと。Safari WebKit / WebView2 の微妙な差をデバッグするのが Tauri のコスト。それでもメモリ / バイナリの差は大きく、Rust バックエンドが与えるシステムコールの安全性が魅力。

// src-tauri/src/lib.rs

#[tauri::command]

fn greet(name: &str) -> String { format!("Hello, {}!", name) }

#[cfg_attr(mobile, tauri::mobile_entry_point)]

pub fn run() {

tauri::Builder::default()

.invoke_handler(tauri::generate_handler![greet])

.run(tauri::generate_context!())

.expect("error while running tauri application");

}

フロントから `await invoke('greet', { name: 'Alice' })` を呼ぶと Rust 関数が実行されて結果が返る。RPC コードの自動生成、capability システム、プラグインエコシステムが v2 で整った。

12 章 · ML — Burn / Candle / mistral.rs

Rust の ML エコシステムは 2024-2025 で急速に成長した。核は 3 つ:

12.1 Candle — HuggingFace のミニマリスト ML

Candle は HF が作る「PyTorch より軽く、ONNX より親しみやすい」Rust ML ライブラリ。WASM に直接コンパイルでき、Metal / CUDA / CPU バックエンドを選べる。

use candle_core::{Device, Tensor};

let device = Device::Cpu;

let a = Tensor::randn(0f32, 1.0, (2, 3), &device)?;

let b = Tensor::randn(0f32, 1.0, (3, 4), &device)?;

let c = a.matmul(&b)?;

println!("{:?}", c.shape());

`candle-transformers` には LLaMA、Mistral、Whisper、Stable Diffusion などのモデルがすでに移植されている。デスクトップ / エッジで推論だけしたいなら Candle がもっとも軽い。

12.2 Burn — 学習まで

Burn は学習 / 推論の両方を Rust でやりたい人のためのフルスタック ML フレームワーク。PyTorch に近い API、バックエンド抽象化(WGPU、CUDA、NdArray、LibTorch)、autodiff。

use burn::tensor::{Tensor, backend::Backend};

fn linear<B: Backend>(x: Tensor<B, 2>) -> Tensor<B, 2> {

let w = Tensor::random([784, 10], Distribution::Default, &x.device());

x.matmul(w)

}

12.3 mistral.rs — LLM 推論最適化

mistral.rs は LLM 推論を Rust でもっとも速く絞ったライブラリのひとつ。PagedAttention、quantization(GGUF、GPTQ、AWQ)、grammar-constrained 出力、OpenAI 互換 server を一つのバイナリにまとめている。

mistralrs-server --port 1234 plain -m mistralai/Mistral-7B-Instruct-v0.2

選び方:

- **推論だけ + デスクトップ / エッジ → Candle**

- **学習まで Rust で → Burn**

- **LLM サービングを早く立てる → mistral.rs**

13 章 · Embassy — async embedded

Embassy は組み込み Rust の **async 標準**。RTOS なしで、async/await で割り込み・DMA・タイマを扱う。STM32 / nRF / RP2040 / ESP32(一部)の HAL が一緒に進化している。

#![no_std]

#![no_main]

use embassy_executor::Spawner;

use embassy_time::{Duration, Timer};

use embassy_stm32::gpio::{Level, Output, Speed};

#[embassy_executor::main]

async fn main(_spawner: Spawner) {

let p = embassy_stm32::init(Default::default());

let mut led = Output::new(p.PC13, Level::High, Speed::Low);

loop {

led.toggle();

Timer::after(Duration::from_millis(500)).await;

}

}

伝統的な組み込みコードは割り込みハンドラを手書きし、「いまどの状態?」のような state machine を手で回す。Embassy はそれを async/await で自然に表現する — `Timer::after(...).await` が割り込みベースの sleep にコンパイルされる。

主要クレート:

- `embassy-executor` — no_std async executor

- `embassy-time` — timer / delay

- `embassy-net` — TCP/IP(smoltcp ベース)

- `embassy-stm32` / `embassy-nrf` / `embassy-rp` — HAL

14 章 · ツール — cargo-binstall / rust-analyzer / RustRover / Helix

14.1 cargo-binstall — コンパイルなしで cargo ツールを入れる

`cargo install ripgrep` だと ripgrep を最初からビルドする。分単位の時間 + ノート PC の発熱。`cargo binstall ripgrep` は GitHub releases からビルド済みバイナリを取ってくる。

cargo install cargo-binstall

cargo binstall ripgrep fd-find sd dust tokei cargo-watch cargo-edit

cargo ツールの半分はすでに binstall メタデータを提供している。平均インストール時間が 30 秒 → 3 秒。

14.2 cargo-watch — ファイル変更で再実行

cargo binstall cargo-watch

cargo watch -x test

cargo watch -x run

cargo watch -x 'run --bin server'

Tauri / Leptos / Axum 開発でほとんどの人が起動しっぱなしにする。

14.3 cargo-leptos — Leptos 専用 dev server

`cargo leptos serve` が SSR サーバ + WASM クライアント + アセットハンドリングを一つにまとめる。HMR も効く — Next.js dev server に近い体験。

14.4 cargo-mobile2 — Rust モバイルビルド

Dioxus / Tauri / 一般の Rust ライブラリを iOS/Android ターゲットでビルドするラッパー。v1 が一部メンテ停止し、mobile2 fork が事実上の標準になった。

14.5 rust-analyzer — LSP

rust-analyzer は Rust LSP の事実上の標準。VS Code / Helix / Neovim / Zed どれでも最初の依存関係。2025 年にマクロ展開速度、async trait 推論、ライフタイムヒントが向上した。

14.6 RustRover — JetBrains 公式

JetBrains は 2023 年に IntelliJ-Rust を RustRover として正式リリース。2024 年 9 月から非商用は無料。デバッガ統合 / プロファイラ / リファクタリングが強い。

14.7 Helix — Rust で書かれたモーダルエディタ

Helix は Rust で書かれたモーダルエディタ(neovim 風だが selection-first)。LSP 統合、tree-sitter ベースのハイライトがデフォルトで、キーバインドは vim と異なる(selection → action)。軽さ / 起動の速さが魅力。

15 章 · 韓国 / 日本 — カカオ、トス、メルカリ、ZOZO、Sansan

15.1 韓国

- **カカオ** — 一部インフラ / 検索サービスで Rust。カカオ Enterprise が Rust の発表を時々出す

- **トス** — Tossbank の決済インフラの一部で Rust 採用事例(gRPC サーバ / latency-critical path)

- **ネイバー** — Hyperscale AI インフラで Rust 使用。NSML の一部コンポーネント

- **サムスン** — Tizen の一部、Galaxy ファームウェアの一部領域で Rust を検討

全体としては「全社導入」より「特定の latency-critical サービス / 特定のインフラコンポーネント」での部分導入が主流。

15.2 日本

日本は韓国より Rust 導入が一拍速い。

- **メルカリ** — Rust で検索 / 推薦の一部を移行。Tech Blog に多数のレポート

- **ZOZO** — ZOZOTOWN の一部マイクロサービスで Rust。WebAssembly 活用の事例もあり

- **Sansan** — 名刺 OCR / データ処理パイプラインのホットパスに Rust

- **サイバーエージェント** — 広告入札システム / ゲームバックエンドの一部で Rust

- **DeNA** — ゲーム / 配車の一部バックエンド

- **LINE(LY)** — メッセージング / メディア処理の一部

特にメルカリが 2022-2023 から継続的に Rust のケーススタディを公開しており、日本のシニアバックエンド市場で Rust の求人が目に見えて増えている。

16 章 · 誰が Rust を選ぶべきか — システム / 組み込み / フルスタック / ゲーム

Rust は万能薬ではない。フィットするケースと「あえて?」と思うケースがある。

16.1 Rust が輝く場所

- **システムプログラミング** — kernel module、driver、OS、仮想化。Linux カーネルが Rust を正式に受け入れた

- **組み込み** — Embassy + no_std で RTOS なしの async embedded

- **高性能ネットワークサービス** — P99 レイテンシが ms 単位で重要なとき(メッセージング、決済、広告入札)

- **WebAssembly** — wasm-pack / wasm-bindgen / trunk。ブラウザで重い計算

- **CLI ツール** — ripgrep / fd / bat / dust / zoxide。配布が簡単で速い

- **ブロックチェーン / 暗号** — Polkadot、Solana、foundry、reth

- **ゲーム(特にインディー)** — Bevy ECS + メモリ安全性

16.2 Rust が重荷になる場所

- **CRUD 中心の社内システム** — Python/Go のほうが普通に速い(開発時間)

- **素早く prototype + よく destroy** — borrow checker が prototype の速度を削る

- **データ分析 / ML 学習そのもの** — Python のエコシステムが圧倒的

- **簡単なスクリプト** — Bash / Python / Deno で十分な領域

- **新人が多いチーム** — Rust の学習曲線は急

16.3 2026 年 Rust 学習ロードマップ

1. **The Rust Book** (rust-lang.org/book) — 無条件で最初の本。2024 edition 反映

2. **Rust by Example** — コード中心

3. **Rustlings** — 100 問以上の小さい練習問題

4. **Async Book** — async/await モデル

5. **Tokio Tutorial** — Tokio がどう動くか

6. **Axum 0.8 docs** + 簡単な CRUD を作る

7. (関心に応じて)**Bevy / Tauri / Leptos / Embassy** のどれかでトイプロジェクト

ここまで来れば、「Rust で本当に何かを作れる」段階。平均 3-6 ヶ月。速く進みたいなら最初のトイプロジェクトをできるだけ早く始める — 本だけ読んでも borrow checker には勝てない。

17 章 · 参考 / References

公式

- [Rust](https://www.rust-lang.org/)

- [The Rust Book (edition 2024)](https://doc.rust-lang.org/book/)

- [Rust 1.85 release notes](https://blog.rust-lang.org/2025/02/20/Rust-1.85.0/)

- [Edition 2024 guide](https://doc.rust-lang.org/edition-guide/rust-2024/index.html)

- [Async Book](https://rust-lang.github.io/async-book/)

Web / バックエンド

- [Tokio](https://tokio.rs/)

- [Axum](https://github.com/tokio-rs/axum)

- [Actix-Web](https://actix.rs/)

- [Rocket](https://rocket.rs/)

- [Loco](https://loco.rs/)

- [Tower](https://github.com/tower-rs/tower)

フロントエンド

- [Leptos](https://leptos.dev/)

- [Dioxus](https://dioxuslabs.com/)

- [Yew](https://yew.rs/)

- [Trunk](https://trunkrs.dev/)

DB

- [sqlx](https://github.com/launchbadge/sqlx)

- [Diesel](https://diesel.rs/)

- [SeaORM](https://www.sea-ql.org/SeaORM/)

ゲーム / デスクトップ / モバイル

- [Bevy](https://bevyengine.org/)

- [Bevy 0.15 release notes](https://bevyengine.org/news/bevy-0-15/)

- [Tauri](https://tauri.app/)

- [Tauri v2](https://v2.tauri.app/)

- [cargo-mobile2](https://github.com/tauri-apps/cargo-mobile2)

ML

- [Burn](https://burn.dev/)

- [Candle](https://github.com/huggingface/candle)

- [mistral.rs](https://github.com/EricLBuehler/mistral.rs)

組み込み

- [Embassy](https://embassy.dev/)

- [Embedded Rust Book](https://docs.rust-embedded.org/book/)

ツール / IDE

- [cargo-binstall](https://github.com/cargo-bins/cargo-binstall)

- [cargo-watch](https://github.com/watchexec/cargo-watch)

- [cargo-leptos](https://github.com/leptos-rs/cargo-leptos)

- [rust-analyzer](https://rust-analyzer.github.io/)

- [RustRover](https://www.jetbrains.com/rust/)

- [Helix](https://helix-editor.com/)

韓国 / 日本 事例

- [Mercari Engineering Blog (Rust)](https://engineering.mercari.com/blog/tags/rust/)

- [ZOZO TECH BLOG (Rust)](https://techblog.zozo.com/archive/category/Rust)

- [CyberAgent Developers Blog](https://developers.cyberagent.co.jp/blog/)

- [Kakao Tech (Korean)](https://tech.kakao.com/)

- [Toss Tech](https://toss.tech/)