Fastify vs Hono — Node.js Webフレームワーク徹底比較
1. 結論
API サーバーを Node.js 専用で構築し、豊富なプラグインエコシステムを活用したいなら Fastify、Cloudflare Workers・Deno・Bun など複数ランタイムへのポータビリティを重視し、軽量かつモダンな開発体験を求めるなら Hono を選ぶべきです。どちらも高速なフレームワークですが、設計思想とターゲットランタイムが明確に異なります。
2. 比較表
| 観点 | Fastify | Hono |
|---|---|---|
| GitHub Stars(2025年6月時点) | ≈ 33k | ≈ 23k |
| 初回リリース | 2016年 | 2022年 |
| 対応ランタイム | Node.js(主対象) | Node.js / Deno / Bun / Cloudflare Workers / AWS Lambda / Vercel 等 |
| 設計思想 | Node.js 特化・プラグインアーキテクチャ | Web Standards 準拠・マルチランタイム |
| ルーティング | Radix Tree(find-my-way) | RegExpRouter / TrieRouter / LinearRouter(選択可) |
| バンドルサイズ(minified) | ≈ 2.2 MB(node_modules) | ≈ 14 KB(コアのみ) |
| TypeScript 対応 | ✅ 型定義同梱・ジェネリクスで型安全 | ✅ TypeScript ファースト設計・型推論が非常に強力 |
| スキーマバリデーション | JSON Schema(Ajv)組み込み | Zod / Valibot 等を zValidator ミドルウェアで統合 |
| プラグインエコシステム | 非常に豊富(公式 + コミュニティ 200+) | 成長中(公式ミドルウェア 40+) |
| 学習コスト | 中程度(プラグインシステムの理解が必要) | 低い(Express ライクな API で直感的) |
| ベンチマーク(req/s 目安) | Node.js 上で最速クラス | Edge ランタイムで最速クラス、Node.js 上でも高速 |
| ロギング | pino 組み込み | ミドルウェアで自由に選択 |
| ライセンス | MIT | MIT |
3. それぞれの強み
Fastify の強み
-
Node.js 上での圧倒的な最適化 内部で JSON のシリアライズを
fast-json-stringifyで高速化し、スキーマベースのバリデーションを Ajv でコンパイル時に最適化します。Node.js 環境に限れば、Express の約 3〜5 倍のスループットを誇ります。 -
成熟したプラグインアーキテクチャ
fastify-plugin/avvioによるカプセル化されたプラグインシステムは、大規模アプリケーションの関心の分離に優れています。認証(@fastify/jwt)、CORS(@fastify/cors)、Swagger(@fastify/swagger)など公式プラグインが充実しています。 -
JSON Schema ファーストなバリデーション ルート定義にスキーマを宣言するだけで、入力バリデーションとレスポンスのシリアライズ最適化が同時に行われます。OpenAPI ドキュメントの自動生成にも直結します。
-
構造化ロギングの標準搭載 pino が組み込まれており、リクエストライフサイクル全体のログが自動的に構造化 JSON で出力されます。
Hono の強み
-
真のマルチランタイム対応 Web Standards(
Request/Response/fetch)に準拠しているため、同じコードが Cloudflare Workers、Deno、Bun、AWS Lambda、Vercel Edge Functions、Node.js で動作します。 -
超軽量なコアサイズ コアが約 14 KB と極めて小さく、コールドスタートが重要な Edge / Serverless 環境で大きなアドバンテージがあります。
-
TypeScript の型推論が極めて強力 ルート定義・バリデーション・ミドルウェアを通じてエンドツーエンドで型が推論されます。
hc(Hono Client)を使えば、API クライアント側でもルートの型をそのまま利用でき、tRPC のような型安全な RPC 体験が得られます。 -
JSX サポート
hono/jsxにより、サーバーサイドで JSX を使ったテンプレートレンダリングが可能です。React に依存せず、軽量な SSR を実現できます。 -
直感的な API 設計 Express に近い
app.get()/app.post()スタイルで、学習コストが非常に低いです。
4. コード例で比較
以下では「ユーザー作成 API」を題材に、バリデーション付きの POST エンドポイントを両フレームワークで実装します。
Fastify
// fastify-app.ts
import Fastify from "fastify";
const app = Fastify({ logger: true });
// JSON Schema によるバリデーション定義
const createUserSchema = {
body: {
type: "object",
required: ["name", "email"],
properties: {
name: { type: "string", minLength: 1, maxLength: 100 },
email: { type: "string", format: "email" },
age: { type: "integer", minimum: 0, maximum: 150 },
},
additionalProperties: false,
},
response: {
201: {
type: "object",
properties: {
id: { type: "string" },
name: { type: "string" },
email: { type: "string" },
age: { type: "integer" },
createdAt: { type: "string" },
},
},
},
} as const;
interface CreateUserBody {
name: string;
email: string;
age?: number;
}
app.post<{ Body: CreateUserBody }>(
"/users",
{ schema: createUserSchema },
async (request, reply) => {
const { name, email, age } = request.body;
// 実際にはDBへの保存処理
const user = {
id: crypto.randomUUID(),
name,
email,
age,
createdAt: new Date().toISOString(),
};
reply.status(201);
return user;
}
);
// ヘルスチェック
app.get("/health", async () => {
return { status: "ok" };
});
app.listen({ port: 3000 }, (err) => {
if (err) {
app.log.error(err);
process.exit(1);
}
});
Hono
// hono-app.ts
import { Hono } from "hono";
import { zValidator } from "@hono/zod-validator";
import { z } from "zod";
const app = new Hono();
// Zod によるバリデーション定義
const createUserSchema = z.object({
name: z.string().min(1).max(100),
email: z.string().email(),
age: z.number().int().min(0).max(150).optional(),
});
app.post(
"/users",
zValidator("json", createUserSchema),
async (c) => {
// c.req.valid("json") の戻り値は自動的に型推論される
const { name, email, age } = c.req.valid("json");
// 実際にはDBへの保存処理
const user = {
id: crypto.randomUUID(),
name,
email,
age,
createdAt: new Date().toISOString(),
};
return c.json(user, 201);
}
);
// ヘルスチェック
app.get("/health", (c) => {
return c.json({ status: "ok" });
});
// Node.js で動かす場合
import { serve } from "@hono/node-server";
serve({ fetch: app.fetch, port: 3000 });
// Cloudflare Workers で動かす場合は以下だけでOK
// export default app;
Hono Client による型安全な API 呼び出し(Hono 独自の強み)
// client.ts — フロントエンドや別サービスから利用
import { hc } from "hono/client";
import type { AppType } from "./hono-app"; // ルート定義の型をインポート
const client = hc<AppType>("http://localhost:3000");
// パスもリクエストボディもレスポンスもすべて型安全
const res = await client.users.$post({
json: {
name: "田中太郎",
email: "tanaka@example.com",
age: 30,
},
});
const user = await res.json();
// user.id, user.name, user.email ... すべて型推論される
5. どちらを選ぶべきか — ユースケース別推奨
Fastify を選ぶべきケース
| ユースケース | 理由 |
|---|---|
| Node.js 専用の REST API サーバー | Node.js に最適化されたパフォーマンスとプラグインの恩恵を最大限に受けられる |
| 大規模なモノリシック API | プラグインによるカプセル化で、チーム開発時の関心の分離が容易 |
| OpenAPI / Swagger ドキュメントの自動生成が必須 | JSON Schema ベースの設計と @fastify/swagger の統合が非常にスムーズ |
| 既存の Express アプリからの移行 | @fastify/express プラグインで Express ミドルウェアを段階的に移行可能 |
| 構造化ロギングを標準で使いたい | pino が組み込まれており、追加設定なしで本番品質のログが得られる |
Hono を選ぶべきケース
| ユースケース | 理由 |
|---|---|
| Cloudflare Workers / Edge 環境へのデプロイ | Web Standards 準拠で、Edge ランタイムとの親和性が最も高い |
| マルチランタイム対応が必要 | 同じコードベースで Node.js・Deno・Bun・各種 Serverless に対応できる |
| フロントエンドとの型安全な連携 | Hono Client(RPC モード)により tRPC ライクな開発体験が得られる |
| Serverless / Lambda でコールドスタートを最小化したい | コアサイズが極めて小さく、起動が高速 |
| 軽量な SSR / MPA を構築したい | hono/jsx で React 不要の軽量サーバーサイドレンダリングが可能 |
| 新規プロジェクトでモダンな DX を重視 | TypeScript ファーストの設計と直感的な API で立ち上がりが速い |
6. まとめ
Fastify と Hono は、どちらも「Express の次」を担う高品質なフレームワークですが、設計のベクトルが異なります。
-
Fastify は「Node.js の性能を極限まで引き出す」ことに注力し、JSON Schema ベースのバリデーション・シリアライズ最適化、成熟したプラグインエコシステムを武器に、Node.js 上の本番 API サーバーとして信頼性の高い選択肢です。
-
Hono は「Web Standards に準拠し、どこでも動く」ことを設計原則とし、超軽量なコア、強力な TypeScript 型推論、マルチランタイム対応を武器に、Edge / Serverless を含むモダンなデプロイ戦略に最適化されています。
2025年現在のトレンドとしては、Edge Computing や Serverless の普及に伴い Hono の採用が急速に拡大しています。一方で、Node.js 上の堅牢な API サーバーという用途では Fastify の成熟度とエコシステムの厚みは依然として大きなアドバンテージです。プロジェクトのデプロイ先とチームの技術スタックを軸に選択するのが最善です。