Skip to content
Published on

Rust Web バックエンドフレームワーク 2026 完全ガイド - Axum・Actix-web・Rocket・Poem・Loco.rs・Pavex・Salvo・Warp・Hyper 徹底解説

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

1. なぜ 2026 年に Rust バックエンドなのか

2026 年の Rust バックエンドはもはや「期待の新人」枠ではありません。Cloudflare が Pingora で NGINX を置き換え、Discord が読み取り API を Go から Rust に移し、Anthropic が AI インフラの一部を Rust で書いていることで、「メモリ安全性と GC なしの性能」という二兎が現実に追えることが本番環境で検証されました。

Rust Web の中核価値は三つです。コンパイル時に検出されるメモリ安全性により午前 3 時の segfault ページ呼び出しがほぼゼロになり、Tokio ベースの async/await で Go と同等あるいはワークロードによっては上回るスループットを出し、強力な型システムによって API 契約をコンパイラが検証します。

2. Tokio 1.42: Rust 非同期の基盤

Tokio は事実上の Rust Web 標準ランタイムです。2026 年 5 月時点で Tokio 1.42 は安定性と性能の頂点と言えます。

// Cargo.toml
[dependencies]
tokio = { version = "1.42", features = ["full"] }

// main.rs
#[tokio::main(flavor = "multi_thread", worker_threads = 4)]
async fn main() {
    println!("Hello from Tokio runtime");
}

主要コンポーネントはマルチスレッドのワークスティーリングスケジューラ、tokio::net TCP/UDP、tokio::sync チャネル/ミューテックス、tokio::time タイマー、tokio::fs ノンブロッキング I/O です。Axum、Actix-web、Poem、Salvo、Loco.rs はいずれも Tokio 上で動作します。

3. Hyper 1.x: すべての土台

Hyper 1.x は Rust Web スタックの最下層に位置します。HTTP/1.1 と HTTP/2 を直接扱うライブラリで、Axum と Actix-web を含むほぼすべての上位フレームワークが内部的に Hyper を使用します。

use hyper::{body::Incoming, Request, Response};
use hyper::server::conn::http1;
use hyper::service::service_fn;
use hyper_util::rt::TokioIo;

async fn handle(req: Request<Incoming>) -> Result<Response<String>, hyper::Error> {
    Ok(Response::new(format!("Hello {}", req.uri().path())))
}

Hyper で直接サーバを書くケースは少ないですが、デバッグや極限の最適化を行う際に内部構造を把握しておくと役立ちます。

4. Axum 0.8: 事実上の標準

Axum は Tokio チームが直接開発したフレームワークで、2026 年現在 Rust Web の事実上の標準です。tower ミドルウェアエコシステムをそのまま使え、Extractor パターンによってハンドラのシグネチャを見るだけで入力が分かります。

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

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

async fn get_user(Path(id): Path<u64>) -> Json<User> {
    Json(User { id, name: format!("User-{id}") })
}

#[tokio::main]
async fn main() {
    let app = Router::new().route("/users/:id", get(get_user));
    let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await.unwrap();
    axum::serve(listener, app).await.unwrap();
}

Axum 0.8 の強みはマクロをほとんど使わずに、関数シグネチャに Extractor を書くだけでルーティングが完成する点です。引数の型が Path、Query、Json、State などの Extractor を実装していればそれで通ります。

5. Actix-web 4.x: 性能チャンピオン

Actix-web 4.x は TechEmpower ベンチマークで長年トップを維持してきた性能チャンピオンです。元は Actor モデルベースでしたが、4.x からは通常の async/await でも自然に書けます。

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

#[get("/hello/{name}")]
async fn hello(name: web::Path<String>) -> impl Responder {
    format!("Hello {}", name)
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| App::new().service(hello))
        .bind("0.0.0.0:8080")?
        .run()
        .await
}

Actix-web の魅力は raw throughput です。単一インスタンスで秒間数十万リクエストを処理する事例が多々あります。ただし内部 API がマイナーバージョンの間でも変更されることがあり、移行コストが発生する場合があります。

6. Rocket 0.5: 型安全の魔法

Rocket は Sergio Benitez が作ったフレームワークで、マクロベースの宣言的 API が特徴です。ルーティングを #[get("/users/<id>")] のような属性で表現するため可読性が非常に高いです。

#[macro_use] extern crate rocket;

#[get("/users/<id>")]
fn user(id: u64) -> String {
    format!("User {}", id)
}

#[launch]
fn rocket() -> _ {
    rocket::build().mount("/", routes![user])
}

Rocket 0.5 でようやく stable Rust と async の両方をサポートしましたが、Axum と Actix-web の人気に押されて採用は停滞しています。シンプルな API サーバ、学習用プロジェクト、可読性を最大化したい場合には今でも魅力的な選択肢です。

7. Warp 0.3 とフィルタパターンの衰退

Warp は Hyper のメンテナ Sean McArthur が作ったフィルタベースのフレームワークです。warp::path! や warp::filters::body::json などのフィルタを組み合わせてルートを構築する方式は新鮮でしたが、コンパイル時間の長さと型シグネチャの複雑さで 2024-2025 年にユーザが大量に Axum へ流出しました。

use warp::Filter;

#[tokio::main]
async fn main() {
    let hello = warp::path!("hello" / String)
        .map(|name| format!("Hello {}", name));
    warp::serve(hello).run(([0, 0, 0, 0], 3030)).await;
}

Warp は依然としてメンテナンスされていますが、新規プロジェクトで採用されるケースはほぼなくなりました。

8. Tide: async-std とともに沈む星

Tide は async-std ベースのフレームワークでした。async-std が 2024 年以降事実上の開発停止状態となったことで Tide も新規採用がなくなりました。既存プロジェクトは Tokio と Axum への移行が一般的です。

9. Poem 3.x: 簡単で強力

Poem は中国発のフレームワークで「簡単で強力」をモットーにしています。Axum と類似した Extractor パターンを使いつつ、poem-openapi で OpenAPI 生成が一級市民として統合されているため API ファースト開発に強いです。

use poem::{get, handler, listener::TcpListener, web::Path, Route, Server};

#[handler]
fn hello(Path(name): Path<String>) -> String {
    format!("hello: {}", name)
}

#[tokio::main]
async fn main() -> Result<(), std::io::Error> {
    let app = Route::new().at("/hello/:name", get(hello));
    Server::new(TcpListener::bind("0.0.0.0:3000")).run(app).await
}

Poem 3.x は WebSocket、SSE、GraphQL の統合が非常になめらかで、一つのフレームワークで多様な通信方式を扱いたい場合に良い選択です。

10. Salvo: 新興の有望株

Salvo は比較的新しいフレームワークで、極めて簡潔な API を志向します。ルーティング、ミドルウェア、OpenAPI のすべてが一貫したインタフェースで提供されるため学習曲線が低いです。

use salvo::prelude::*;

#[handler]
async fn hello() -> &'static str { "Hello from Salvo" }

#[tokio::main]
async fn main() {
    let router = Router::new().get(hello);
    let acceptor = TcpListener::new("0.0.0.0:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}

Salvo は 2025 年に GitHub スター数が急増し、特にアジア圏の開発者コミュニティで人気を得ています。

11. Loco.rs: Rails 着想のフルスタック

Loco.rs は「Rust の Rails」を標榜するフルスタックフレームワークです。CLI でモデル、コントローラ、マイグレーションを生成し、バックグラウンドジョブ、メーラー、セッション、認証まで箱の中に含まれています。

cargo install loco-cli
loco new my-app
cd my-app
cargo loco start

内部的には Axum と SeaORM を束ねて使用します。個別パーツを自分で組み立てるよりも「明日リリースするサイドプロジェクト」を素早く形にしたい開発者向きです。

12. Pavex: コンパイル時 DI

Pavex は Luca Palmieri(Zero To Production In Rust 著者)による新しいフレームワークです。最大の差別化要素はコンパイル時依存性注入です。専用のコード生成ステップを介してすべてのルートハンドラの依存関係をコンパイラが保証し、ランタイムオーバーヘッドがほぼゼロになります。

// Pavex blueprint
let mut bp = Blueprint::new();
bp.constructor(f!(crate::deps::db_pool), Lifecycle::Singleton);
bp.route(GET, "/users/:id", f!(crate::routes::get_user));

ビルドステップが増える欠点はありますが、「一度コンパイルが通れば壊れない」保証は大規模チームにとって魅力的です。

13. gotham と Rouille: 忘れられゆく選択肢

gotham はかつて安定性を強調したフレームワークでしたが活発な開発は停止しました。Rouille は非同期を用いない同期フレームワークで、シンプルなサイドカーや学習用には依然有効ですが、本番投入は稀です。

14. 非同期ランタイム 4 強

  • Tokio 1.42: 事実上の標準。ほぼすべてのライブラリが Tokio を前提にしている
  • async-std: 2024 年以降開発がほぼ停止
  • smol: 組み込みやミニマルな環境向けの軽量ランタイム
  • Glommio(DataDog): io_uring ベース、thread-per-core モデルで NVMe ヘビーなワークロードに強い
  • monoio(ByteDance): 同じく io_uring ベース、中国発プロジェクトで採用増

2026 年の新規プロジェクトは 99% Tokio を選びます。Glommio と monoio はデータベースエンジンやメッセージブローカーといった非常に特殊な I/O ワークロードでのみ検討の余地があります。

15. HTTP クライアントライブラリ

  • reqwest: 圧倒的な標準。同期/非同期、multipart、cookie、リダイレクトをすべてサポート
  • hyper: 低レベル HTTP、クライアントとしても利用可能
  • isahc: libcurl ベースの代替クライアント
  • ureq: 同期クライアント、async ランタイムを入れたくない CLI 向け
let body = reqwest::get("https://httpbin.org/get")
    .await?
    .text()
    .await?;

16. テンプレートエンジン

  • Askama: Jinja スタイル、コンパイル時型チェック、最も人気の高い選択肢
  • Tera: ランタイムテンプレート、Pythonic な文法
  • Maud: マクロベースの HTML 構築、type-safe
  • Yarte: 極限の性能に特化

代表的な Askama の例は以下のとおりです。

#[derive(Template)]
#[template(path = "hello.html")]
struct HelloTemplate<'a> { name: &'a str }

Vec<u8> や Result<T, E> のようなジェネリック型をインラインコードで安全に表現できる点も Askama が Rust 開発者にしっくり来る理由の一つです。

17. WebSocket: リアルタイム通信

WebSocket の実装は通常 tungstenite と tokio-tungstenite から始まりますが、Axum ユーザは axum::extract::ws を直接使うのが自然です。

use axum::extract::ws::{Message, WebSocket, WebSocketUpgrade};

async fn ws_handler(ws: WebSocketUpgrade) -> impl IntoResponse {
    ws.on_upgrade(handle_socket)
}

async fn handle_socket(mut socket: WebSocket) {
    while let Some(Ok(Message::Text(t))) = socket.recv().await {
        let _ = socket.send(Message::Text(format!("echo: {t}"))).await;
    }
}

18. GraphQL: async-graphql 7

async-graphql 7 は Axum、Actix-web、Poem、Salvo すべてに対するアダプタを提供します。コードファーストスキーマとマクロベースの定義が強力です。

use async_graphql::{Object, Schema, EmptyMutation, EmptySubscription};

struct Query;
#[Object]
impl Query {
    async fn hello(&self) -> &str { "world" }
}

19. ORM 4 強

  • Diesel 2: 同期ファースト、極めて厳格なコンパイル時検査。最も古く安定
  • SeaORM 1: 非同期、動的クエリに強い、Active Record スタイル
  • SQLx 0.8: クエリファースト、生の SQL を書きつつコンパイル時に検証
  • Toasty(Tokio チーム): ごく新しい ORM、NoSQL と SQL を同時にサポートする野心的な設計
  • rbatis: MyBatis 着想、XML ベースのマッピングが可能

新規プロジェクトであれば SQLx 0.8(型安全な生 SQL)か SeaORM 1(高レベル抽象)が最も無難な選択です。

20. データベースドライバ

  • tokio-postgres: PostgreSQL 非同期ドライバ、sqlx のバックエンド
  • sqlx: 複数 DB(PG、MySQL、SQLite、MSSQL)サポート
  • mysql_async: MySQL 専用の非同期ドライバ
  • mongodb: 公式 MongoDB Rust ドライバ

21. 認証、OpenAPI、シリアライズ、観測性

  • jsonwebtoken: JWT 発行/検証の標準クレート
  • axum-login: セッション/ログインミドルウェア
  • utoipa: Axum/Actix-web で OpenAPI を自動生成、最も活発なプロジェクト
  • aide: 代替の OpenAPI ジェネレータ
  • serde: シリアライズの絶対標準。JSON、YAML、MessagePack などあらゆるフォーマットの基盤
  • bincode: バイナリシリアライズ、高速 IPC
  • ciborium: CBOR エンコーディング
  • tracing: 構造化ログ/スパンの標準
  • opentelemetry-rust: OTLP エクスポート、Jaeger/Tempo 連携

22. テストとベンチマーク

ビルトインの #[test] でユニットテスト、tokio::test で非同期テスト、axum-test と tower-test でハンドラを直接呼ぶ統合テストを書きます。TechEmpower ベンチマークは毎ラウンド Actix-web と Axum が上位を維持し、一部のシナリオでは Go を上回るスループットを示します。

23. デプロイ選択肢

  • shuttle.rs: Rust 専用 PaaS、shuttle deploy の一行でデプロイ
  • Fly.io: グローバルエッジ、Dockerfile があれば十分
  • Cloudflare Workers: Rust を Wasm にコンパイルしてエッジへデプロイ
  • AWS Lambda Rust: コールドスタート 50-100 ms 程度、最小メモリ使用量

小規模プロジェクトは Shuttle、グローバルサービスは Fly.io または Cloudflare、AWS 縛りの環境では Lambda Rust が推奨です。

24. グローバル導入事例

  • Cloudflare: Pingora が NGINX を置き換え 1 日 4000 万リクエストを処理、Workers のコアも Rust
  • Discord: Go から Rust に移行した読み取り API が GC 遅延を解消
  • 1Password: バックエンドサービスの一部を Rust で書き直し
  • Vercel: Turborepo の中核モジュールが Rust
  • Figma: リアルタイム同期サーバに Rust 導入
  • Anthropic: AI インフラの一部を Rust で記述

25. 韓国と日本の導入状況

  • トス(Toss): 一部の決済 API を Rust で運用、並列性とレイテンシの利点を活用
  • NAVER Cloud: 一部のインフラサービスで Rust 採用
  • クーパン: リアルタイム推薦システムでの Rust 比率が増加
  • SmartHR(日本): 人事 SaaS バックエンドの一部に Rust を導入
  • Mercari(日本): 一部マイクロサービスを Go から Rust へ移行

26. フレームワーク選定の意思決定ツリー

  • グリーンフィールド API + モダン + 標準採用 → Axum 0.8
  • 極限スループット + 単一ノード性能 → Actix-web 4.x
  • Rails スタイルフルスタック + 高速プロトタイピング → Loco.rs
  • マクロベースの可読性 + 学習用 → Rocket 0.5
  • API ファースト + OpenAPI 自動化 → Poem 3.x または Axum + utoipa
  • コンパイル時 DI + 大規模チーム → Pavex
  • 新興 + アジアコミュニティ親和 → Salvo
  • レガシー移行 → Warp/Tide/Gotham から Axum へ

27. References

Discuss on Twitter • View on GitHub