Actix-webとは？Rust製高速Webフレームワークの特徴・導入手順・Axum比較まで徹底解説

Rustで本番運用に耐えるWebサーバーを構築するとき、フレームワーク選定は避けて通れません。Actix-webはGitHubスター数24,000超、TechEmpowerベンチマークで常に上位に位置する高速フレームワークとして、多くのプロジェクトで採用されています。

本記事ではActix-webの読み方・基本概念から実装手順、競合フレームワークとの違い、そして「actix-web事件」の経緯と現在のメンテナンス体制まで、実務で必要な情報を体系的にまとめています。

Actix-webの基礎知識 — 読み方・定義・ライセンス

Actix-webは「アクティクス ウェブ」と読みます。Rust言語で記述されたオープンソースのWebアプリケーションフレームワークで、Apache 2.0とMITのデュアルライセンスで提供されています。

もともとActixはErlangのアクターモデルに着想を得たRust向け並行処理フレームワークとして誕生しました。actix-webはそのエコシステム上に構築されたHTTPサーバー／Webフレームワークです。2026年2月時点の最新安定版はv4.12.1（2024年11月リリース）で、Tokioランタイム上で動作します。

Actix-webが高速である4つの技術的理由

Actix-webはTechEmpowerフレームワークベンチマークで全言語・全フレームワーク中トップクラスの成績を継続的に記録しています。その速度の背景には、以下の4つの技術的要因があります。

1. Rustのゼロコスト抽象化とメモリ安全性

Rustはガベージコレクタ（GC）を持たず、所有権システムによってコンパイル時にメモリ安全性を保証します。ランタイムのGCオーバーヘッドがゼロであるため、C/C++に匹敵する実行速度を達成しながらメモリ関連バグを排除できます。

2. Tokioベースの非同期I/O

Actix-web 4.xはTokioランタイム上で動作し、async/awaitによる非同期I/Oを全面的に活用しています。スレッドプールベースの同期I/Oと異なり、OSスレッドの切り替えコストなしに数万の同時接続を処理できます。

3. マルチワーカーアーキテクチャ

HttpServerはデフォルトでCPUの論理コア数と同数のワーカースレッドを起動します。各ワーカーが独立したTokioランタイムを保持するため、ロック競合を最小限に抑えつつCPUコアを最大限に活用します。

4. 型駆動による最適化

Actix-webのExtractorパターンでは、リクエストのパース処理がコンパイル時に型情報で決定されます。動的ディスパッチ（vtable呼び出し）を避け、インライン展開可能な静的ディスパッチが使われるため、リクエスト処理のオーバーヘッドが極めて小さくなります。

Actix-webの主要機能一覧

Actix-webは本番運用に必要な機能を標準で備えています。

環境構築とHello Worldの実装手順

前提条件

Rustのツールチェーンが必要です。未インストールの場合はrustup.rsから導入してください。

# Rustのバージョン確認（1.72以上推奨）
rustc --version

プロジェクト作成

cargo new actix-hello && cd actix-hello

依存クレートの追加

Cargo.tomlの[dependencies]セクションに以下を追記します。

[dependencies]
actix-web = "4"

Hello Worldサーバーの実装

src/main.rsを以下の内容に置き換えます。

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

#[get("/")]
async fn hello() -> impl Responder {
    HttpResponse::Ok().body("Hello, Actix-web!")
}

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

起動と動作確認

cargo run

ブラウザまたはcurlでhttp://127.0.0.1:8080/にアクセスすると「Hello, Actix-web!」と表示されます。

curl http://127.0.0.1:8080/
# => Hello, Actix-web!

ルーティングとExtractorの実装パターン

パスパラメータの取得

web::Pathエクストラクタを使うと、URLパスに含まれる動的パラメータを型安全に受け取れます。

use actix_web::{get, web, HttpResponse, Responder};

#[get("/users/{id}")]
async fn get_user(path: web::Path<u32>) -> impl Responder {
    let user_id = path.into_inner();
    HttpResponse::Ok().body(format!("User ID: {}", user_id))
}

JSONリクエストの受信

web::Jsonエクストラクタとserdeを組み合わせると、POSTリクエストのJSONボディを構造体に自動デシリアライズできます。

use actix_web::{post, web, HttpResponse, Responder};
use serde::Deserialize;

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

#[post("/users")]
async fn create_user(body: web::Json<CreateUser>) -> impl Responder {
    HttpResponse::Created()
        .json(serde_json::json!({"name": body.name, "email": body.email}))
}

クエリパラメータの取得

use actix_web::{get, web, HttpResponse, Responder};
use serde::Deserialize;

#[derive(Deserialize)]
struct Pagination {
    page: Option<u32>,
    per_page: Option<u32>,
}

#[get("/items")]
async fn list_items(query: web::Query<Pagination>) -> impl Responder {
    let page = query.page.unwrap_or(1);
    let per_page = query.per_page.unwrap_or(20);
    HttpResponse::Ok().body(format!("Page: {}, Per page: {}", page, per_page))
}

ミドルウェアの設計と実装

Actix-webのミドルウェアはリクエスト／レスポンスのパイプラインに処理を差し込む仕組みです。

組み込みミドルウェアの適用例

use actix_web::{App, HttpServer, middleware};

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .wrap(middleware::Logger::default())   // アクセスログ
            .wrap(middleware::Compress::default())  // レスポンス圧縮
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

CORS設定

actix-corsクレートを追加すると、クロスオリジンリクエストを制御できます。

use actix_cors::Cors;

App::new()
    .wrap(
        Cors::default()
            .allowed_origin("https://example.com")
            .allowed_methods(vec!["GET", "POST"])
            .max_age(3600)
    )

アプリケーション状態の共有（App State）

複数のハンドラ間でDB接続プールや設定値を共有するには、web::Dataを使います。

use actix_web::{get, web, App, HttpServer, HttpResponse, Responder};
use std::sync::Mutex;

struct AppState {
    counter: Mutex<u32>,
}

#[get("/count")]
async fn count(data: web::Data<AppState>) -> impl Responder {
    let mut counter = data.counter.lock().unwrap();
    *counter += 1;
    HttpResponse::Ok().body(format!("Count: {}", counter))
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let state = web::Data::new(AppState {
        counter: Mutex::new(0),
    });

    HttpServer::new(move || {
        App::new()
            .app_data(state.clone())
            .service(count)
    })
    .bind("127.0.0.1:8080")?
    .run()
    .await
}

DB接続プールの共有にはsqlxやdieselのプールオブジェクトをweb::Dataに格納するパターンが一般的です。

Actix-web・Axum・Rocketの比較

Rustの3大Webフレームワークを、実務で選定に影響する観点で整理します。

選定の目安

• スループット最優先・既存のActixエコシステム資産がある → Actix-web
• Tokioエコシステムとの統合・towerミドルウェア再利用 → Axum
• プロトタイピング速度・Rust初学者のチーム → Rocket

Axumはtokioプロジェクト公式のフレームワークであり、towerのService/Layerを直接使える点が最大の強みです。一方、Actix-webは長年の本番運用実績とクレートエコシステムの厚みで優位に立っています。

actix-web事件とは — 経緯と現在

「actix-web事件」は2020年1月に発生した、Rustコミュニティで大きな議論を呼んだ出来事です。

発端

Actix-webのコードベースには多数のunsafeブロックが含まれていました。コミュニティのメンバーが「メモリ安全性に違反する可能性のあるunsafeコードが存在する」と指摘し、GitHubのIssueやRedditで議論が活発化しました。

メンテナーの辞任

当時の主要メンテナーであるNikolay Kim氏は、批判の激しさに疲弊し「オープンソースのメンテナンスはもう楽しくない」と表明。GitHubリポジトリを一時的に削除するという行動に出ました。

コミュニティによる復旧

リポジトリ削除後、コミュニティの有志がフォークを作成。その後Kim氏はリポジトリを復旧させ、メンテナンス権限を新しいチームに移管しました。現在はrobjtede氏を中心とする複数のコントリビューターが開発を継続しています。

現在のメンテナンス状況

2026年2月時点で、actix-webは活発にメンテナンスされています。リリース総数は470を超え、問題となったunsafeコードの大部分は安全なコードに書き換えられました。事件を経てコミュニティ主導のガバナンスが確立され、フレームワークとしての信頼性はむしろ向上しています。

Actix-webを本番環境で運用する際の注意点

Nginxとのリバースプロキシ構成

本番環境ではActix-webの前段にNginxを配置するのが一般的です。TLS終端、静的ファイル配信、ロードバランシングをNginxに任せ、Actix-webはアプリケーションロジックに専念します。

upstream actix_backend {
    server 127.0.0.1:8080;
}

server {
    listen 443 ssl;
    server_name example.com;

    location / {
        proxy_pass http://actix_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

グレースフルシャットダウン

HttpServerはCtrl+Cシグナル（SIGINT）を受け取ると、処理中のリクエストを完了してからプロセスを終了します。タイムアウトはshutdown_timeoutメソッドで設定できます。

HttpServer::new(|| App::new())
    .shutdown_timeout(30) // 30秒でタイムアウト
    .bind("127.0.0.1:8080")?
    .run()
    .await

ログ設定

env_loggerとactix_web::middleware::Loggerを組み合わせると、Apache互換フォーマットのアクセスログを出力できます。

std::env::set_var("RUST_LOG", "actix_web=info");
env_logger::init();

App::new().wrap(middleware::Logger::default())

よくある質問

Actix-webは「終了」したのですか？

Actix-webは終了していません。2020年のメンテナー交代を経て、新しいチームのもとで継続的にリリースが行われています。最新版は4.12.1（2024年11月リリース）で、GitHubでのコミット・Issue対応も活発です。

Actix-webの学習にはどんなリソースがありますか？

• 公式ドキュメント（英語）
• Actix非公式 日本語ドキュメント
• docs.rs/actix-web — APIリファレンス

ActixのアクターモデルはActix-web 4.xでも使われていますか？

Actix-web 4.xはTokioランタイムに移行しており、アクターモデル（actixクレート）への依存は必須ではなくなりました。Web APIの構築にはActix-web単体で十分です。ただし、WebSocketやバックグラウンドタスクなど、アクターモデルが適するユースケースでは引き続きactixクレートを併用できます。

まとめ

Actix-webはRustの所有権システムとTokio非同期ランタイムを基盤に、コンパイル時の型安全性と実行時の高スループットを両立するWebフレームワークです。HTTP/2、WebSocket、ミドルウェア、TLSといった本番運用に必要な機能を標準で備え、24,000超のGitHubスターと377名以上のコントリビューターによる活発なエコシステムが存在します。

2020年のメンテナー交代という危機を乗り越え、コミュニティ主導で安定した開発体制が確立されている点も、長期プロジェクトでの採用を後押しする要素です。