Fastify を1年運用してわかった Express との違い

Fastify と Express を1年使って出した答えを、先に3点でまとめます。

1. 個人開発SaaS の API 中心構成 (JSON API 多用) なら Fastify が学習コスト分の見返りあり、特に schema validation 内蔵によるバグ低減効果が大きい
2. ただし Express で 6-12ヶ月運用して「不便」を実感してからの移行が現実的、最初から Fastify は学習コストの方が重い
3. 2026 年は Hono / Elysia など TypeScript first 系の選択肢も増えたので「Express vs Fastify 二択」は既に古い、新規ならエッジ実行や Bun 採否も含めて再検討する余地あり

以下、GramShift Web 側を Express → Fastify に移行して 1年運用した実体験ベースで、定量的な違いと判断軸を共有します。

あなたがNode.jsでWebサーバーを書くとき、ExpressとFastifyのどちらを選ぶべきか悩んだことがあるはずです。私はGramShift Web側 (gramshift.com、Stripe webhook受信、Heartbeat受信、ダッシュボード API) を、最初Expressで作り、後にFastifyに移行しました。1年運用してわかった具体的な違いと、Fastifyに移行して得たメリットを共有します。

当初Expressで作った理由とその限界

GramShift Web側の初期実装はExpressでした。理由は単純で、Node.jsエコシステムで最も普及しているフレームワークだったからです。情報量が大きく多く、ChatGPTに質問しても的確な回答が返ってくる、ライブラリの組み合わせも豊富です。

しかし、運用4-5ヶ月目に2つの不満が出てきました。第一に、リクエストのバリデーションを手動で書く工数が多い。typebox やJoi等で補強していましたが、ルートごとに記述が増えて煩雑になります。第二に、エラーハンドリングが try-catch まみれになり、コードの見通しが悪い。これらの不満が積み重なり、Fastify への移行を検討するきっかけになりました。

Fastify に移行して得た3つのメリット

Express から Fastify に移行して、明確に良くなったのは以下の3点です。

• JSON Schema validation 内蔵: ルート定義に schema を書くだけで、リクエストボディの型チェックを自動化できる
• パフォーマンス向上: ベンチマークで Express の約 2-3倍の RPS が出る、私のケースでも実測で 1.5倍程度の改善
• エラーハンドリングが宣言的: setErrorHandler() で集中管理、try-catch の散乱がなくなる

とくに JSON Schema validation のメリットは大きく、API バグの大幅減少につながりました。Express では「リクエストボディの ユーザーID が undefined だった」のようなエラーが本番でちらほら出ていましたが、Fastify移行後はゼロになりました。

具体的な書き方の差

同じエンドポイントを Express と Fastify で書き比べると、Fastify のシンプルさが明確に分かります。

// Express の場合
app.post('/api/users', async (req, res) => {
 if (!req.body.email || !req.body.password) {
 return res.status(400).send({ error: 'Missing required fields' });
 }
 try {
 const user = await createUser(req.body);
 res.send(user);
 } catch (e) {
 res.status(500).send({ error: e.message });
 }
});

// Fastify の場合
fastify.post('/api/users', {
 schema: {
 body: {
 type: 'object',
 required: ['email', 'password'],
 properties: {
 email: { type: 'string', format: 'email' },
 password: { type: 'string', minLength: 8 }
 }
 }
 }
}, async (req) => {
 return await createUser(req.body); // バリデーション自動、エラーは setErrorHandler で集中処理
});

Fastify の書き方は、API ドキュメントとしての可読性も高く、後から読み返しても意図がすぐ伝わります。schema を一度書けば Swagger 自動生成も可能なので、API ドキュメントを別途書く手間も省けます。

Express から Fastify への移行コスト

Express から Fastify への移行は、コードの大半を書き直す必要があります。私のケースでは、約 15エンドポイントを移行するのに丸2日かかりました。具体的にはミドルウェア (CORS、認証、ロギング) の書き換えに半日、ルート定義の書き換えに1日、エラーハンドリングの集中化に半日、という配分です。

移行作業中は、Express版と Fastify版を並行運用しました。リバースプロキシ (nginx) で一部のエンドポイントだけ Fastify版に振り、徐々に切替える形です。これで「移行中にサービスが止まる」リスクをゼロにできました。

Node.js Web フレームワークシェアの実態 (2024-2026)

Express を選ぶか Fastify を選ぶかは「業界がどっちを使ってるか」も影響します。一次情報で確認しました。

Stack Overflow Developer Survey 2024 (survey.stackoverflow.co/2024/technology) によると、Web フレームワークの「過去1年使用」項目で Express は約 17.8% (Node.js 系で最大シェア)、Fastify は約 3.4%。シェアは10倍以上の開きがあり、Express の絶対的優位は揺るぎません。

npm 週次ダウンロード数 (npmtrends、2026年5月時点) の比較:

• Express: 約 3,500万/週 (依然として圧倒的トップ)
• Fastify: 約 280万/週 (Express の約 8%)
• Hono: 約 70万/週 (2022年公開で急成長、前年比 +180%)
• Koa: 約 200万/週 (横ばい)

GitHub stars でも Express 65k+ / Fastify 32k+ / Hono 19k+ / Koa 35k+ と、Express がリードしています。ただし、Fastify と Hono は前年比 +40-80% で伸びており、特に Hono は Cloudflare Workers 普及に伴って個人開発者層で支持を拡大中です。

私が GramShift Web 側を Fastify に移行した判断は、シェアではなく「個人 1人運用での生産性」を優先したからです。Stack Overflow に答えがある安心感は Express にありますが、Fastify でも主要な質問はカバーされており、運用上の不便はほぼ感じません。シェアより自分の運用感覚を信じる判断が、後から振り返ってもプラスだったと感じています。

Fastify v5 の新機能と GramShift Web 側で使っている機能

Fastify v5 は 2024 年 9 月リリース (公式 Migration Guide V5)、Node.js 20+ を要求します。GramShift Web 側は v4 → v5 への移行を 2025 年初頭に実施しました (Node.js を 22 LTS に上げるタイミングで同時更新)。

v5 の主要変更点で実運用に影響があったのは以下です。

• JSON Schema validator (ajv) の strict モード強化: 不正な schema 定義をビルド時に検出、本番で「validation が黙ってすり抜ける」現象が解消
• Plugin system の依存ツリー解決改善: 起動時間が体感で 200-300ms 短縮 (起動時 plugin 数 12 個の構成)
• Light My Request の HTTP/1.1 keep-alive サポート: テスト時のコネクション枯渇エラーが解消

GramShift Web 側で常用している Fastify エコシステムプラグイン:

• @fastify/cors: Desktop アプリ ↔ Web API のクロスオリジン許可
• @fastify/jwt: Desktop アプリの JWT 認証 (Heartbeat エンドポイント含む全 API)
• @fastify/rate-limit: Heartbeat エンドポイントの DoS 防御 (1 IP / 60秒 / 100リクエスト)
• @fastify/cookie + @fastify/csrf-protection: Web ダッシュボードの CSRF 対策
• @fastify/static: download/ ページの静的配信 (Electron インストーラの配布)

体験談を 1 つ。Heartbeat エンドポイント (Desktop アプリが 10 分間隔で死活情報を送る) を Fastify schema validation で記述してから、Desktop バージョン違いによる「想定外 payload で 500 エラー」が劇的に減りました。具体的には、過去 3ヶ月で本番でこの種のエラーが ゼロです。Express 時代は月 2-3 件出ていたので、schema validation の効果は実数で明確でした。

Express vs Fastify 二択ではない — 他の選択肢を検討した結果

2026 年時点で個人開発 SaaS の Node.js フレームワーク選定をするなら、以下も検討に値します。

フレームワーク	適する条件	個人開発 SaaS 視点の評価
Hono	Cloudflare Workers / Bun でエッジ実行、TypeScript first	VPS 中心なら過剰、エッジ運用なら最有力
Elysia	Bun ネイティブ、ベンチマーク最速級	エコシステム未熟、本番運用は時期尚早 (2026 年時点)
Koa	Express 系、移行コスト最小	Fastify との差別化が薄く、選ぶ理由が弱い
NestJS	大規模チーム向け、DI コンテナ + デコレータで構造化	個人開発には機能過剰、学習コスト高い

私は GramShift Web 側を VPS 上の Node.js プロセスで動かす設計のため、Edge 実行前提の Hono は採用しませんでした (検討はしたが、長所が活きない)。Fastify を選び続けて 1 年経った今でも、後悔はないという感覚です。

ただし、これから新規 SaaS や新規メディアサイトを立ち上げるなら話は別で、Hono + Cloudflare Pages の組み合わせは有力候補として真剣に検討しています。フレームワークは「既存資産」ではなく「これから作るもの」に対して最適なものを選ぶ柔軟性が、個人開発者の強みだと考えています。

2026 年は Bun の本番採用例も増えており (Vercel が部分採用、Discord が CI 採用)、Node.js + Express/Fastify 一辺倒の時代は終わりつつあります。フレームワーク選定の判断軸を持っておくことが、技術選定で迷子にならないコツです。

個人開発SaaSで Fastify を選ぶべき条件

個人開発SaaSで Fastify を選ぶべき条件は、以下のパターンです。

• API中心の構成 (フロントは別途)、JSON API を多用する
• リクエスト/レスポンスの型安全性を重視する
• パフォーマンスがクリティカル (1秒間に数百リクエスト以上)
• OpenAPI/Swagger ドキュメントを自動生成したい

逆に、シンプルな CRUD だけ、エコシステム重視、既存の Express コードベースが大量にある、という場合は Express のままで問題ありません。フレームワーク選択は技術的判断であると同時に、運用コストと開発体験の判断でもあります。

個人開発の技術選定記録は技術ログ、本番運用の試行錯誤は失敗談カテゴリに蓄積しています。

筆者: GRAMSHIFT — GramShift / saas-diary 開発者。本業 + 副業個人開発を 1 年継続中、Web フレームワーク Fastify / Electron Desktop / SQLite / Playwright を組み合わせた SaaS をフルスタック 1 人運用。

次に読むなら

本記事の内容を踏まえて、以下のテーマに進むと理解が深まります。

• 個人SaaSでSQLiteを選んだ理由 (PostgreSQLは過剰だった)
• VPSのメモリリークを発見した夜のデバッグ記録
• 個人開発者の2026年スタック (実際に毎日使っているツール)