Skip to content
Published on

モダン Rust 2026 — Rust 1.85 / Edition 2024 / Tokio / Axum 0.8 / Loco / Leptos / Bevy / Tauri 2 / Embassy 徹底ガイド

Authors

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-httpCompressionLayerTraceLayerCorsLayer をそのまま差し込める
  2. Extractor が関数シグネチャに乗るPathQueryJsonState を引数で受けると自動パース
  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! {
        <button on:click=move |_| set_count.update(|n| *n += 1)>
            "Count: " {count}
        </button>
    }
}

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 2Electron
バックエンド言語RustNode.js
webviewOS nativeChromium バンドル
バイナリサイズ~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

公式

Web / バックエンド

フロントエンド

DB

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

ML

組み込み

ツール / IDE

韓国 / 日本 事例