Axum と Actix-web: 本番環境ではどちらの Rust フレームワークですか?

Axum と Actix-web は両方とも、Rust のリファレンス非同期ランタイムである Tokio 上で実行されます。 Actix-web README にはこれを率直に「Tokio との完全な互換性」と記載しており、その公式コード例では歴史的な actix フレームワークのアクターを一切使用していません。注釈 #[get(...)]が付いた古典的な async fn ハンドラーで十分です。 「Actix-web には必ずアクターが必要である」という混乱は、現在の API には対応しなくなりました。

Axum は東京の直接軌道で誕生しました。リポジトリは GitHub 組織 tokio-rsに属しており、その公式ドキュメントは明確です — 「axum は tokio および hyper と連携するように設計されています。ランタイム層とトランスポート層の独立性は、少なくとも当面は目標ではありません。」

つまり、競合する 2 つのランタイムの選択ではなく、同じ非同期エンジン上に HTTP API を構築する 2 つの方法の選択になります。この比較では、ミドルウェア モデル、宣言されたメモリ セキュリティ、ネイティブ HTTP サーフェス、crates.io と GitHub で測定された導入の 4 つの検証可能な領域をカバーし、サポート コードとともに、Aurabase の Rust コア が Axum を選択した理由を説明します。

Axum は独自のミドルウェア システムを構築しません。独自の README によれば、タイムアウト、トレース、圧縮、認証など、すべてが tower::Serviceに依存しており、Tower エコシステムを介してすべてが「無料」で提供されます。 Hyper または Tonic アプリケーション用に作成されたミドルウェアは、調整せずに Axum アプリケーションでそのまま再利用できます。

Actix-web は逆の道をたどります。ユーザー ガイドに記載されている独自のミドルウェア システム (Logger、Session、CORS など) を、独自の関連する HTTP クライアント (awc) に埋め込みます。これはより統合されたプラットフォームであり、組み立てる部品は少なくなりますが、他の汎用 Rust 非同期エコシステムとの直接的な再利用も少なくなります。

ルーティングは、同じ明示的な構成ロジックに従います。 Axum は、ルートを宣言するための「マクロフリー API」を主張しています。Router::new().route(...) は通常の Rust 値のままです。Actix-web は、ハンドラーの直上に配置された HTTP メソッド (#[get(...)]) による専用マクロに依存しています。能力の差ではなく、二つの発言スタイル。

Axum はソース コードで #![forbid(unsafe_code)] を主張しています。フレームワークの 100% は安全な Rust で書かれており、抜け穴はありません。 Actix-web は README で同様の記述をしていません。これはフレームワークが危険であるという意味ではなく、プロジェクトによってそのような保証が公に示されていないというだけです。

2 つのフレームワークは異なる最小バージョンの Rust を設定します。Axum は Rust 1.80 から互換性があり、Actix-web は Rust 1.88 を必要とします。 Actix-web のウィンドウが狭くなり、ツールチェーンが古いバージョンでスタックしている場合に問題になる可能性があります。

Actix-web は、HTTP/1.x および HTTP/2、WebSocket、透過圧縮 (br、gzip、deflate、zstd)、OpenSSL または Rustls 経由の TLS など、大規模な HTTP サーフェスをクレート内に直接リストします。すべてが統合され、追加の依存関係を選択する必要はありません。

Axum は、ルーティング、エクストラクター、エラー処理など、意図的に最小限にとどめています。残り (圧縮、CORS、リクエスト制限、トレース) は、同じエコシステムのコンパニオン クレートである tower-httpから提供されます。たとえば、Aurabase は、パッケージ全体ではなく、意図的に選択された tower-http の cors、 trace、 compression-gzip、 request-id、 timeout 、および limit 機能のみを有効にします。

Actix-web は、「TechEmpower Framework Benchmarkによると、利用可能な最速の Web フレームワークの 1 つ」 (ラウンド r21、複合) という正確な外部ソースを引用してその速度を主張しており、独自の README に techempower.com への直接リンクが含まれています。これは自分で確認できるタイプの見積もりです。

Axum はこれに匹敵する主張を行っていない。その README は、「axum はハイパーの上にある比較的薄い層であり、追加されるオーバーヘッドはほとんどありません」という控えめな記述に限定されており、正式なプロジェクトの数値ではなく、サードパーティ コミュニティのベンチマークへの 2 つのリンクが含まれています。

crates.ioでは、Axum では、過去 90 日間で 436,464,896 件のダウンロードがあり、これには 109,000,226 件が含まれます。 Actix-web は、最近の同じウィンドウ (crates.io、2026 年 8 月 23 日にアクセス) での 9,730,975 を含む、合計 78,074,020 ダウンロードを蓄積します。この点において、差は明らかです。Axum は現在、Actix-web の約 11 倍の最新ダウンロードを受け取ります。

逆説: Actix-web は 2 つのうち古いもので、Axum の場合は 2021 年 7 月に公開されるのに対し、2017 年 10 月以降 crates.io で公開されています。 GitHub では、人気の差はさらに縮まっています。 26,931 個の スターが tokio-rs/axum 対 24,793 が に対して actix/actix-web (GitHub、2026 年 8 月 23 日にアクセス) — そして、Actix-web はより多くのフォーク (1,462 と比較して 1,880) を保持しており、これは歴史的な貢献者ベースがまだアクティブであることを示しています。

Actix-web は依然として廃止されていません。そのバージョン 4.15.0 は、この記事の執筆の 3 日前である 2026 年 8 月 21 日に公開されました。 GitHub の発行キューでは、Axum はオープン チケット 75 件を表示していますが、Actix-web のチケットは 192 件です。これはメンテナンスのシグナルなので注意して読んでください。ほぼ 4 年も長い歴史が機械化してキューを長くしており、これはプロジェクトが慎重でないことの証拠ではありません。

Aurabase のルート Cargo ワークスペースには 11 個のサービスがあります。認証とストレージを含め、API ゲートウェイ (aura-gateway) からネイティブ AI エンジン (aura-ai) まで、10 は Axum に直接依存しています。 11 番目の aura-migratorは、HTTP サーバーを使用しない移行 CLI ツールです。単純に、何も選択することができません。リポジトリに Cargo.toml はなく、ルート Cargo.lock のエントリも、推移的な依存関係であっても actix-webを宣言しません。 .rs ファイルには use actix_web::命令が含まれていません。

axum       = { version = "0.8", features = ["ws", "multipart", "macros"] }
tower      = { version = "0.5", features = ["full"] }
tower-http = { version = "0.6", features = ["cors", "trace", "compression-gzip", "request-id", "timeout", "limit"] }
hyper      = { version = "1", features = ["full"] }

この選択は表面的なものではありません。Aurabase ゲートウェイ (aura-gateway) は、ミドルウェアを tower::ServiceBuilder および Layer タワー ( TraceLayer、 TimeoutLayer、 RequestBodyLimitLayer) でスタックし、リクエスト識別子、認証、およびセキュリティヘッダー用に axum::middleware::from_fn を介して社内レイヤーによって補完されます。これはまさに、Axum の README で強調されている構成モデルです。Tower ミドルウェアは、ルーターの残りの部分とは独立してスタックされ、テストされ、再利用されます。

ソース: crates.io API (/api/v1/crates/axum、 /api/v1/crates/actix-web) および GitHub API、2026 年 8 月 23 日にアクセス。残りについては、公式 README tokio-rs/axum および actix/actix-web を参照してください。

モジュール式のマルチサービス Rust バックエンドを開始します。 Axum は自然に適合します。Aurabase が 10 個の HTTP サービス間で行うのと同様に、その Tower 構成により、サービス間でミドルウェアを共有することが容易になります。

既存の動作する Actix-Web コード ベースがあります。 急いで移行する必要はありません。 Actix-web は積極的に保守されており、依存関係を追加することなく、HTTP/2、WebSocket、圧縮をネイティブにカバーします。

tower-http を自分で組み立てることなく、できるだけ多くの HTTP 機能を 1 つのクレートで提供したいと考えています。 Actix-web はこのニーズに直接応えます。

既に Tower ミドルウェアを他の Hyper または Tonic (gRPC) サービスと共有しています。 Axum はこれらのレイヤーをそのまま再利用します。これが Aurabase で重視された議論です。