Axumとは｜RustのWebフレームワークの特徴とActix Webの違い

Axumとは｜Tokioチームが開発するRust製Webフレームワーク

結論として、Axumは「HTTPサーバーの土台そのもの」ではなく、既存のRust非同期スタックの上に薄く乗る層です。自前でランタイムやHTTP実装を抱え込まない設計になっています。

公式リポジトリはTokioプロジェクトの傘下にあり、ライセンスはMITです。GitHubのスター数は2026年11月15日に確認した時点で約27.8k（スター数は日々変動するため、現在値は公式リポジトリでご確認ください）。docs.rsで確認できる最新の公開バージョンは、同日時点で0.8系です。

Tokio・hyper・towerとの関係

Axumを理解する近道は、下から順に積み上がる構造を押さえることです。

公式ドキュメントでも、axumは Tokioランタイムとhyperの上で動くことを前提にしている と明記されています。ランタイムから独立させることは当面の目標ではない、という立場です。

この割り切りの見返りが、towerエコシステムとの相互運用性です。towerは「リクエストを受けてレスポンスを返す処理」をServiceという共通の型で抽象化するクレートで、その前後に共通処理を挟み込む仕組みをLayer（レイヤー）と呼びます。タイムアウト、トレーシング、圧縮、認可といった処理は、axum専用の仕組みを覚え直さずにこのLayerとして足せます。

マクロを使わないという設計判断

Axumの売り文句で最初に出てくるのが「マクロなしのルーティング」です。ルートは属性マクロではなく、Routerという普通の構造体にパスとハンドラ関数を登録していく形で書きます。

マクロを避けると何が変わるか。地味ですが、効きます。

• コンパイルエラーが、マクロ展開後の読めないコードではなく 自分が書いた関数の上に出る

• rust-analyzerの補完・定義ジャンプがそのまま効く

• ルーティング定義を変数に入れて組み立てたり、条件分岐で切り替えたりしやすい

その代わり、型が合わないときのエラーメッセージがtrait bound（その型が満たすべき条件をコンパイラに伝える制約）の話になりがちで、慣れるまでは読みづらいという弱点もあります。この点は後述します。

Extractorという考え方

Extractorは、リクエストから必要な部分だけを型として受け取る仕組みです。JSONボディ、パスパラメータ、クエリ文字列、ヘッダ、共有状態（State）などが、それぞれ対応する型として用意されています。

ハンドラ関数の引数に「欲しいもの」を型で並べると、axumが順番に取り出してくれる。パースに失敗すれば、その時点で適切なステータスコードを返します。手続き的にリクエストを分解する書き方と比べて、意図が引数リストに出るのが利点です。

内部的には FromRequest / FromRequestParts というトレイトの実装で、自前のExtractorも定義できます。認証済みユーザーを表す型を作って、全ハンドラで受け取る、といった使い方が定番です。

ミニFAQ：AxumはRustの公式フレームワークですか？

Rust公式ではありません。Tokioプロジェクトが開発・保守しているサードパーティのクレートです。ただしTokioはRustの非同期処理で採用例が多い部類のランタイムであり、その中核チームが手がけている点が、Axumが選ばれる理由の一つになっています。

Axumの主な特徴

各特徴を、実装時に効いてくる形で整理します。

型システムでリクエストの形を縛る

JSONボディを受け取るなら、対応する構造体を定義してJson型のExtractorで受けます。デシリアライズに失敗したリクエストはハンドラに到達しません。バリデーションの一段目を型が肩代わりする形です。

ただし 型で表現できるのは「形」までで、業務ルールの検証は別です。「金額は0より大きい」「開始日は終了日より前」といった制約は、別途バリデーション用のクレートを組み合わせるか、ハンドラ内で明示的に検証します。

Towerミドルウェアをそのまま使える

tower-httpが提供する機能を、レイヤーとして重ねるだけで使えます。

• リクエスト/レスポンスのトレーシング

• CORS

• gzip・brotliによる圧縮

• 静的ファイル配信

• タイムアウト、同時実行数の制限

自作のミドルウェアもtowerのServiceとして書けるため、axumを離れても同じ資産を使い回せます。gRPCサーバーのtonicもtowerベースなので、RESTとgRPCを同居させる構成では書き味が揃うという副次的な利点があります。gRPCの前提は「gRPCとは｜RESTとの違い・Protocol Buffersと使いどころ」で整理しています。

エラーハンドリングが予測しやすい

Axumのハンドラは、レスポンスに変換できる型を返します。IntoResponse（その型をHTTPレスポンスへ変換する方法を定義するトレイト）をエラー型に実装しておけば、ドメインのエラーがそのままHTTPステータスに写像されます。

ここで散らかりやすいのが「どこでステータスコードを決めるか」です。実務では、アプリ全体で1つのエラー型を定義し、そこにIntoResponseを1回だけ実装する形に寄せると見通しが良くなります。ハンドラごとに個別対応していくと、同じ404が別の形で5箇所に散る、というよくある事態になります。

つまずきやすいのはtrait boundのエラー

初学者がほぼ必ず踏むのが、ハンドラの型が合わないときのエラーです。「the trait bound ... is not satisfied」という形で出てきますが、原因はExtractorの順番だったり、Stateの型が合っていなかったり、ハンドラ内で握っている値がSendでなかったりと、メッセージと原因が離れていることが多い。

公式はdebug_handlerという属性マクロを用意していて、これを付けると原因箇所が絞り込まれたエラーになります。マクロなしが売りのフレームワークで、デバッグにはマクロを使うというのは少し皮肉ですが、実務では最初に覚えておきたい道具です。

標準装備と外部クレートの線引き

Axumは意図的に機能を絞っています。セッション管理、認証、ORM、バリデーションは本体に含まれません。これらは外部クレートを選んで組み合わせる前提です。

「薄い」ことは自由度でもあり、初期構築の手間でもあります。チームにRust経験者が1人もいない状態で選ぶと、この組み合わせを決める工程が最初の山になります。

AxumとActix Webの違い

結論から言うと、新規プロジェクトでTokio周辺に寄せたいならAxum、一次提供のcrateを揃えて早く組みたいならActix Web、という分かれ方をします。性能はどちらを選んでも致命的な差にはなりにくい段階に来ています。

設計思想とルーティングの書き方

Axumは、Routerに対してパスとハンドラ関数を登録します。ハンドラは普通のasync関数です。Actix Webは属性マクロ（get、postなど）をハンドラに付けてルートを宣言する書き方が一般的です。

なおActix Webは、もともとアクターモデルのフレームワークであるactixから派生した経緯を持ちます。ただし現在のActix WebでWebアプリを書く際に、アクターを直接扱う場面は限定的です。名前の由来として押さえておく程度で、「Actix Webを使う＝アクターモデルで設計する」という理解にはならないようご注意ください。

マクロを使う側は宣言が関数の直上にまとまるため読みやすい反面、ルーティングを動的に組み立てる場面ではAxumのほうが素直に書けます。

ランタイムモデル

Actix Webはワーカーごとにシングルスレッドのランタイムを起動する構成、Axumはマルチスレッドのtokioランタイム上で動きます。この違いは、ハンドラ内で保持する値に要求される制約（SendやSyncの有無）に表れます。

Actixのモデルでは、ワーカー内に閉じた状態を扱いやすい場面があります。逆にAxumは、共有状態をArcで包んでStateとして渡す形が基本です。

性能差をどう見るか

第三者が公開している合成ベンチマーク（固定のレスポンスを返すだけのエンドポイントに負荷をかけ、秒あたりのリクエスト数を測る種類のもの）では、高負荷時にActix Webがやや上回る結果が報告されることがあります。ただしこれは 測定環境・バージョン・計測条件に強く依存する数字で、公開元によって結論が食い違います。

したがって本記事では、具体的な差分の数値は選定根拠として扱いません。押さえるべきは次の点です。

• どちらもRust製として十分に高速な部類で、JavaやNode.jsからの移行で問題になるような差ではない

• 実アプリケーションのレイテンシは、DBクエリ、外部API呼び出し、シリアライズの設計に支配されるのが普通

• 性能が本当に要件になるなら、ベンチマーク記事ではなく自分のユースケースで実測するのが唯一確実な方法

フレームワーク間の性能差を選定の決め手にできる場面は、実務では限られます。

比較の早見表

ミニFAQ：すでにActix Webで動いているプロジェクトをAxumへ移すべきですか？

動いているなら急ぐ理由は薄いです。移行コストはルーティングとミドルウェアの書き換えに加えて、エラーハンドリングの設計見直しまで及びます。Tokio系のライブラリ（tonic、tower-http）と密に連携したい要求が出てきたときが、検討する実際的なタイミングです。

axum 0.8の変更点とバージョンの選び方

2026年11月15日に確認した時点で、crates.ioに公開されている最新の系列は0.8系です。公式リポジトリのmainブランチでは次のメジャー系列（0.9）に向けた開発が進んでいますが、同日時点では未公開でした。

技術記事の性質上、この情報は時間とともに古くなります。着手前に必ず公式のリリース情報とdocs.rsで、現在の最新安定版がどれかをご自身で確認してください。

パス構文が /:id から /{id} へ

0.8での最も目につく変更です。パスパラメータの書き方が変わりました。

• 旧：/users/:id → 新：/users/{id}

• 旧：/files/*path → 新：/files/{*path}

旧構文はpanicする仕様になっています。黙って挙動が変わるより、起動時に落ちたほうが安全という判断です。移行時は、まずルート定義を全数検索して書き換えるところから始めます。

ハンドラにSyncが要求されるようになった

Routerとメソッドルーターに登録するハンドラ・サービスにSyncが必要になりました。コンパイルが通らなくなった場合、ハンドラ内で保持している値がSyncを満たしていないケースを疑います。

Path Extractorの引数チェックが厳密に

タプルやタプル構造体でパスパラメータを受け取る場合、パラメータ数とタプルの長さが一致するか検査されるようになりました。従来は見過ごされていた不一致が、エラーとして表面化します。

移行作業の進め方

既存プロジェクトの移行は、次の順で確認すると手戻りが少なくなります。

1. ルート定義のパス構文を全置換する（/:param → /{param}）

2. ビルドを通し、Sync制約で落ちる箇所を洗い出す

3. Path Extractorでタプルを使っている箇所の引数数を確認する

4. 依存しているtower-http等のバージョン整合を取る

5. 統合テストでルーティングの網羅を確認する

作業量の目安を置くなら、エンドポイント30〜50程度・ミドルウェアは既製品のみ・統合テストが整備済みという条件で1〜3日程度が一つの見方です。ただしこれは筆者が想定した条件下での見積もりであり、調査データに基づく数字ではありません。ミドルウェアを自作している場合や、依存クレートが広範にわたる場合は、towerのバージョン差分の確認だけでこれを超えることがあります。

Axumが向いている案件・向いていない案件

向いているケース

• レイテンシとリソース効率が要件に書かれているAPIサーバー（広告配信、ゲームのバックエンド、金融系の計算サーバーなど）

• 既にTokio系のライブラリを使っており、作法を揃えたいプロジェクト

• gRPCとRESTを同居させる構成。REST APIとgRPCの両方を提供するゲートウェイ的な役割

• マイクロサービスのうち、処理が重く計算コストが支配的なサービス

向いていないケース

• 管理画面やCMSのように、機能を早く揃えることが最優先の案件。ORM・認証・テンプレートが揃ったフレームワークのほうが速い

• チームにRust経験者がおらず、学習期間を確保できない状況

• 仕様変更が頻繁で、型定義の書き換えコストが開発速度を直撃する立ち上げ期のプロダクト

Rustは所有権と借用の理解が前提になるため、Web開発の生産性だけを理由に採用すると割に合わない場面があります。言語そのものの特性は「Rustとは？ 特徴・用途から年収・将来性まで解説」で詳しく扱っています。

RustのWeb案件とAxumの位置づけ

掲載案件から見える傾向

以下の数字の母集団を先に明示します。フリコンの案件一覧ページで「Rust」のスキルタグを選択したときに掲載中として表示される案件を、ページ上の集計表示からそのまま引用した参考値です。次の4点にご注意ください。

• Rustエンジニア職種の案件内訳ではありません。Rustがスキル要件のどこかに含まれる案件（必須・歓迎を問わない）の横断集計です

• 掲載時点の提示単価であって、成約単価ではありません。面談を経た実際の契約額とは一致しません

• 平均はページ上に表示される集計値をそのまま引用したもので、単価の表記方法（上限・下限・応相談の扱い）による差は均されていません

• 掲載中の案件を対象とした時点のスナップショットです。募集終了案件は含まれず、日によって件数も平均も動きます

45件という規模は、JavaやPythonのタグと比べれば小さい部類です。母数が限られるため、この平均値は少数の高単価案件に引っ張られている可能性があり、相場そのものとして読むべき数字ではありません。経験年数別のレンジは「Rustフリーランスの単価相場と案件動向｜経験別月額と獲得の実践術」で整理しています。

自分がどのレンジを狙えるかを確かめたい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。

要件欄での書かれ方

公開されている募集要項を見る限り、Axumが単独で必須スキルとして指定されるケースは多くありません。多いのは次の形です。

• 「Rust（axum / actix-web いずれかの実務経験）」という並列指定

• 「tokio・axum・sqlx を用いたAPI開発経験」という周辺スキルとのセット

• Rust自体が「歓迎スキル」で、必須はGoやTypeScriptという構成

つまり、フレームワーク名よりも「Rustで非同期のAPIサーバーを本番運用した経験があるか」が見られていると読めます。Axumだけを深掘りするより、tokioの非同期モデル、sqlx等でのDBアクセス、エラー設計までを一通り説明できる状態を作るほうが、面談では効きます。

併記されやすい周辺スキル

DB別の件数を集計したデータは持ち合わせていないため、以下は募集要項の文面で見かけることが多い組み合わせとして挙げるものです。件数の多寡を示すものではありません。

• データベース：PostgreSQLとの組み合わせを見かけることが多い（sqlxやSeaORMがPostgreSQLとの相性を前提に語られる場面が多いことと対応しています）

• コンテナ：Docker、Kubernetes

• API仕様：OpenAPIでのスキーマ管理

• 周辺領域：WebAssembly、Tauri（Rustの経験が横展開しやすい領域）

実際のRust案件はRustの案件一覧で確認できます。案件を比較するときの優先順位の付け方は「案件の選び方｜フリーランスエンジニアが単価・稼働・スキルで決める優先順位」が参考になります。

ミニFAQ：Axumの経験だけで案件に入れますか？

フレームワーク単体での評価は難しいのが実情です。要件にはRustの実務経験2〜3年を前提とする案件が目立ちます。Axumの経験は「Rustで本番のAPIを書いた証拠」として機能しますが、入り口はRust本体の習熟度で判断されると考えたほうが現実的です。

ケース別｜どこから手をつけるか

出発点によって、詰まる場所が違います。

ケース1：Go・Node.jsでバックエンドを書いてきた人

HTTPの知識はそのまま使えます。詰まるのは言語側、特に所有権とライフタイムです。

最短ルートは、普段書いているCRUD APIをそのままAxumで書き直すこと。題材が分かっているので、言語の壁だけに集中できます。Goから来た方は、Go言語のgoroutineとtokioのタスクが似て非なるものである点を早めに押さえておくと混乱が減ります。

期間の目安を置くなら、他言語でのバックエンド実務が3年以上あり、週10時間を学習に充てられるという前提で、DB接続と認証を含む小規模APIを書けるところまで1〜2か月というのが一つの見方です。調査に基づく数値ではなく、前提条件が変われば大きく動く点はご承知おきください。

ケース2：Rustは書けるがWebは未経験

ここは比較的速い。Extractorの一覧と、towerのLayerの重ね方を押さえれば、1〜2週間で形になります。

むしろ注意すべきは設計のほうです。エラー型の設計、トランザクション境界、テストの書き方といった、フレームワークのドキュメントに書かれていない部分で手が止まります。公式リポジトリのexamplesディレクトリが実質的な設計カタログになっているので、先にひと通り眺めておくと遠回りが減ります。

ケース3：Rust自体が初めて

いきなりWebから入るのは勧めません。所有権・借用・ライフタイム、そしてResultによるエラー処理に先に慣れておくほうが、結果的に早い。

CLIツールを1本書いてから、Axumに進む。この順番であれば、trait boundのエラーに遭遇したときに「型の話をしている」と理解できる状態で読めます。順序を逆にすると、フレームワークの問題なのか言語の問題なのか切り分けられず、消耗します。

Axum案件に向けた実践チェックリスト

面談や参画前に、自分の状態を確認する項目です。

• [ ] tokioのタスクとスレッドの違いを、人に説明できるか

• [ ] ExtractorをFromRequestParts実装で自作したことがあるか

• [ ] アプリ共通のエラー型にIntoResponseを実装した設計を組んだことがあるか

• [ ] towerのLayerを自作、または既存Layerの適用順序を意識して並べたことがあるか

• [ ] sqlx等でDBアクセスを実装し、コネクションプールをStateで共有した経験があるか

• [ ] axum 0.8のパス構文変更を把握し、移行作業を説明できるか

• [ ] 統合テストでルーターを直接叩く書き方を知っているか

• [ ] 本番運用で、トレーシングとメトリクスをどう入れたか話せるか

参画前には、プロジェクトが使っているaxumのバージョンと、0.9系への移行計画の有無も確認しておきたいところです。メジャー更新が年単位で入るクレートでは、バージョンが固定されたまま放置されている現場もあります。依存の更新が止まっている場合、セキュリティ修正の取り込み方針まで含めて聞いておくと、参画後の齟齬を避けられます。

まとめ

Axumは、Tokio・hyper・towerの上に薄く乗るRust製Webフレームワークで、新規のAPIサーバーをTokio系のエコシステムに揃えて組みたい場合の第一候補になります。 Actix Webとの選択は性能差ではなく、towerの作法に寄せるかどうかで決まります。

• マクロを使わないルーティングとExtractorが設計の中心。エラーは自分のコードの上に出る

• 機能は意図的に絞られており、DB・認証・バリデーションは外部クレートを組み合わせる

• axum 0.8でパス構文が /:id から /{id} に変更。旧構文はpanicするため移行は必須

• 公開ベンチマークの差は測定条件依存が大きく、選定理由にはなりにくい。性能が要件なら自分のユースケースで実測する

• 案件要件ではAxum単体指定より「Rust＋axum/actix-web＋PostgreSQL」のセットが目立つ

• フリコン掲載のRustタグ案件は45件・掲載平均85万円・リモート可73%（2026年11月15日時点の横断集計）

次のステップとして、Rustの実務経験がすでにある方はRustの案件一覧で要件欄の書かれ方を確認してみてください。単価の体系的な上げ方は「【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？」で整理しています。

参照した一次情報は次のとおりです。

• axum 公式リポジトリ（tokio-rs/axum）

• axum API ドキュメント（docs.rs）

• Announcing axum 0.8.0（Tokio公式ブログ）

• tower ドキュメント

• Actix Web 公式サイト