FastAPI で作った HTTP API を Rust に置き換えるとしたら？
登場人物：
- ずんだもん（質問役）：Rust 初心者。FastAPI には慣れている。
- めたん（解説役）：Webフレームワークと非同期処理に詳しい技術オタク。
- つむぎ（補足ナレーション）：仕様整理や長期的視点の提案が得意。
この記事は ChatGPT で生成しました。
ずんだもん：VOICEVOX の HTTP API って FastAPI で作られてるけど、Rust に置き換えるとしたらどこから手をつけるといいの？
めたん：まず考えるべきは「何を置き換えるか」だね。VOICEVOX Core はすでに Rust 製だから、対象は HTTP サーバー部分、つまり FastAPI の代替だよ。
つむぎ：FastAPI は非同期処理、スキーマバリデーション、OpenAPI 生成など、便利な機能がそろっているの。これを Rust で全部カバーするのは簡単じゃないわ。
ずんだもん：Rust に FastAPI みたいな便利なフレームワークはあるの？
めたん：部分的にはあるよ。たとえば、axum は人気だけど OpenAPI 自動生成は utoipa を別途使う必要がある。一方 poem は OpenAPI 生成を統合していて FastAPI に一番近い。
つむぎ：ただし、FastAPI のような依存性注入や pydantic ベースのバリデーションは Rust では serde を使って手動で書くことになる。開発体験はまだ追いついていないわね。
ずんだもん：じゃあ、非同期処理とか HTTP/3 の話になるとどうなるの？
めたん：非同期処理は Rust では tokio が事実上の標準。だけど VOICEVOX Core は同期 API だから、Web サーバーから spawn_blocking() を使って別スレッドで処理させる必要がある。HTTP/3 に対応したいなら quinn（Tokio ベース）か s2n-quic（AWS製）などが選択肢になるよ。
つむぎ：逆に言えば、ローカル用途で負荷が低いなら、あえて async-std や tide のような軽量構成もありね。
ずんだもん：なるほど、FastAPI の開発体験は良いけど、Rust のほうが性能と配布の面で有利なんだね。
めたん：そう。Rust 製なら単一バイナリで配布できるし、起動も高速。Web UI の静的ファイル配信も同じバイナリに統合できる。
つむぎ：ただ、そのぶんコード量は増えるし、OpenAPI やリクエストのバリデーションも自分で組む必要があるから、今の FastAPI を「開発用」、Rust を「実行用」に分ける戦略も検討の価値があるわ。
ずんだもん：ありがとう！Rust 化するときに何を得て、何を手放すかを見極めるのが大事だってよくわかったよ！
補足：2025年時点で VOICEVOX Core の開発版は Rust 側において 同期・非同期の両APIを段階的に実装中であり、Python バインディングの構成も
voicevox_core/からcore/へと変更されつつある。async_synthesis()のような非同期 API の導入が進んでおり、HTTP サーバーと統合する際の柔軟性が今後さらに高まる見込み。
Discussion