技術入門 2026年5月11日

Hono.js入門Q&A｜「Expressと何が違う？」「Next.jsとどう使い分ける？」など10の疑問に答えます【2026年版】

Hono.jsのよくある疑問10個に現役エンジニアが実例コード付きで回答。Expressとの速度差・TypeScriptネイティブ対応・Cloudflare Workers連携・Node.js/Bun対応まで徹底解説。

Hono.jsNode.jsTypeScriptCloudflare WorkersAPIフレームワーク

※当サイトはアフィリエイトプログラムに参加しています。記事内のリンクから商品を購入すると、当サイトに報酬が支払われることがあります。詳しくはプライバシーポリシーをご覧ください。

「Hono.jsって最近よく聞くけど、結局Expressと何が違うの？」

これ、4月末に社内Slackで後輩から聞かれた質問です。

で、答えようとしたら意外と説明が難しかった。「軽い」「速い」は知ってるけど、具体的に何がどう違うのかを言語化しようとすると、思ったより時間がかかりました。（ここ書くのに30分悩んだ）

この記事では、Hono.jsについてよく聞かれる10の疑問に、実例コード付きで答えていきます。

「名前は知ってるけど、よくわかってない」という方のために書きました。結論から言うと、Expressユーザーであれば移行コストはかなり低いです。

Hono.js - 軽量Webフレームワーク

Hono.jsについてよくある10の疑問

Q1. Hono.jsってそもそも何ですか？

A. Cloudflare Workers向けに生まれた、超軽量・高速なWebフレームワークです。ただし今ではNode.js・Bun・Denoでも動きます。

Hono（「炎」を意味する日本語）は、Cloudflare Workers上での動作を念頭に設計されたWebフレームワークです。2021年に公開され、2024〜2025年にかけて急速に普及しました。

コードを見るのが一番早いです。

import { Hono } from 'hono'

const app = new Hono()

app.get('/', (c) => c.text('Hello Hono!'))
app.get('/users/:id', (c) => {
  const id = c.req.param('id')
  return c.json({ id, name: '田中太郎' })
})

export default app

Expressを知っている人なら「ほぼ同じだ」と感じるはずです。ここがポイントなんですが、既存のExpressの知識がほぼそのまま使えます。

Q2. ExpressやFastifyと何が違うんですか？

A. バンドルサイズと起動速度が桁違いに違います。正直、そこが一番の差です。

僕が実際に計測したわけじゃないんですが、公開されている数値とDockerコンテナで試した感覚を合わせると:

	Hono	Express	Fastify
バンドルサイズ	約13KB	約600KB	約76KB
TypeScript	ネイティブ対応	別途`@types`必要	別途`@types`必要
エッジランタイム	○	✕	△（一部のみ）
学習コスト（Express経験者）	低い	—	中程度

Expressの約1/50のサイズというのは、Cloudflare WorkersやVercel Edge Functionsのようなサイズ制限のある環境で大きな意味を持ちます。

「でも普通のNode.jsサーバーならExpressでよくない？」という意見もわかります。社内ツールレベルなら好みの問題です。ただ、APIサーバーを新規で作るなら、Honoを選ぶ理由が多くなってきています。

Q3. Cloudflare Workersでしか使えないですか？

A. 全く違います。Cloudflare Workers「にも」対応している、が正しい表現です。

Hono.jsが動くランタイム一覧:

Cloudflare Workers / Pages
Node.js（@hono/node-serverアダプタ使用）
Bun（ネイティブ対応・追加パッケージ不要）
Deno（ネイティブ対応）
AWS Lambda
Vercel / Netlify Functions

Bunへの移行を1ヶ月試したレポートでも触れましたが、Bun上でHonoを使うとリクエスト処理が体感1.5〜3倍くらい速くなります（正確な数値は環境で変わるので参考程度に）。

どのランタイムでもアプリ本体のコードが変わらないのが最大のメリットです。

Q4. Node.jsでHono.jsを使うには何が必要ですか？

A. npmで2パッケージ入れるだけです。

npm install hono @hono/node-server

import { serve } from '@hono/node-server'
import { Hono } from 'hono'

const app = new Hono()

app.get('/users', (c) => {
  const users = [
    { id: 1, name: '田中太郎' },
    { id: 2, name: '佐藤花子' },
  ]
  return c.json(users)
})

app.post('/users', async (c) => {
  const body = await c.req.json()
  return c.json({ id: 3, ...body }, 201)
})

serve(app, (info) => {
  console.log(`Listening on http://localhost:${info.port}`)
})

パッケージマネージャの選択についてはpnpm vs npm vs yarn 比較記事も参考に。pnpmユーザーはそのままpnpm add hono @hono/node-serverでOKです。

Q5. Next.jsとHono.jsはどう使い分ければいいですか？

A. 「フロントエンドが必要かどうか」で分けるのが一番シンプルです。

Next.js    → フロントエンド込みのフルスタックWebアプリ
Hono.js    → APIサーバー単体・エッジ関数・マイクロサービス

ちょっと話が逸れるんですが、僕が最近よく使うパターンは「Next.jsのフロントエンド + Hono.jsのAPIサーバー」という分離構成です。

Next.jsのRoute HandlersだけでAPIを作ると、だんだん肥大化してメンテしにくくなる経験がありました。APIだけ切り出してHonoで管理すると、責務がはっきりして快適です。「この設計が正解か」はまだ断言できないですが、チーム開発では評判が良かったです。

Q6. TypeScriptサポートはどうですか？

A. ネイティブ対応で、型推論が非常に優秀です。これが地味に嬉しい。

HonoはゼロからTypeScriptで書かれています。@types/honoみたいな別パッケージは不要で、honoをインストールするだけで型が使えます。

import { Hono } from 'hono'
import { z } from 'zod'
import { zValidator } from '@hono/zod-validator'

const app = new Hono()

const UserSchema = z.object({
  name: z.string().min(1),
  age: z.number().int().min(0).max(150),
})

app.post(
  '/users',
  zValidator('json', UserSchema),
  (c) => {
    const { name, age } = c.req.valid('json') // ← ここが型安全
    return c.json({ message: `${name}さん（${age}歳）を登録しました` }, 201)
  }
)

@hono/zod-validatorと組み合わせると、バリデーションと型推論が一緒に効いて非常に快適です。TypeScriptに慣れていない人はTypeScript入門記事から始めてみてください。

Q7. 最初の「Hello World」はどう書きますか？

A. 5行以内で書けます。

// Bun + Hono の最小構成（index.ts）
import { Hono } from 'hono'

const app = new Hono()
app.get('/', (c) => c.text('Hello World!'))

export default app

Bunならbun run index.tsだけで動きます。

# Bunのインストール（Mac/Linux）
curl -fsSL https://bun.sh/install | bash

# プロジェクト作成〜起動まで
bun init -y
bun add hono
bun run index.ts

コードを書いている様子

最初に試すならBunが一番手軽です。Node.jsがなくてもすぐ動かせます。

Q8. ミドルウェアはExpressと同じように使えますか？

A. 基本的な考え方は同じで、Hono独自の便利なミドルウェアも標準ライブラリに入っています。

import { Hono } from 'hono'
import { cors } from 'hono/cors'
import { logger } from 'hono/logger'
import { bearerAuth } from 'hono/bearer-auth'
import { compress } from 'hono/compress'

const app = new Hono()

// グローバルミドルウェア
app.use('*', logger())
app.use('*', compress())

// 特定パスにのみ適用
app.use('/api/*', cors({ origin: 'https://example.com' }))
app.use('/api/admin/*', bearerAuth({ token: process.env.API_SECRET! }))

app.get('/api/hello', (c) => c.json({ message: 'Hello' }))

export default app

hono/cors、hono/logger、hono/jwt、hono/compressなど、よく使うミドルウェアは追加パッケージ不要で使えます。REST APIの設計全般についてはREST API基礎記事もあわせてどうぞ。

Q9. 本番投入は早いですか？怖くないですか？

A. 正直、最初は少し怖かったです。でも小規模なAPIから始めれば問題ありませんでした。

4月の連休にCloudflare Workers上で本番稼働させてみた結果:

障害: 0件（1ヶ月運用）
レスポンス時間: Expressの時より改善（平均23ms→11ms、環境依存）
気になった点: エラーハンドリングのパターンがExpressと微妙に違って最初は混乱した

「ここが正直微妙だった」と言うと、エコシステムの成熟度はまだExpressに及ばない点です。Expressは20年近くの歴史があり、Qiita記事やStack Overflowの回答が豊富です。Honoは新しいので「このユースケースをどう解決するか」を自分で調べる必要がある場面がまだあります。

デプロイ自動化にGitHub Actionsを使いたい場合はGitHub Actions入門2026が参考になります。

Q10. 正直、Express継続かHono移行か、どっちがいいですか？

A. 「これからAPI作る」なら迷わずHono。「既存Expressを移行する」なら費用対効果次第です。

ここまで読んでくれた人に正直に言うと、枯れた技術の安心感はExpressにあります。Expressのエコシステムは異次元に成熟していて、「○○したい」でGoogle検索すれば答えが出てくる確率が高い。

一方、これから新規でAPIサーバーを立てるなら、学習コストがほぼ同じなのでHonoを選ぶメリットが大きいです。TypeScriptネイティブ、軽量、マルチランタイム対応——この三拍子は実際の開発でじわじわ効いてきます。

ぶっちゃけ「正解はどっちか」と問われると**「状況次第」としか言えない**ですが、僕個人は新規APIプロジェクトでは今Honoを選んでいます。

まとめ：Hono.jsを選ぶ理由と向かない場面

Hono.jsは「Expressの使い勝手そのままに、軽量・高速・マルチランタイム対応」を実現したフレームワークです。

Honoが特に向いている場面:

Cloudflare Workers / Vercel Edgeにデプロイするとき
TypeScriptで型安全なAPIを書きたいとき
Bunで高速なAPIサーバーを作りたいとき
新規プロジェクトで軽量なバックエンドが欲しいとき

Expressのほうが向いている場面:

既存の大量のExpressプラグインに依存しているとき
チームのExpressの知見・ドキュメントが充実しているとき
「安定性・枯れた技術」を最優先するとき

「また新しいフレームワーク…」と感じる気持ちもわかります。当時の僕もそうでした。でも実際に触ってみると、Expressとの距離感が近くて移行コストが低いことに気づきました。

まずはNode.js入門記事でNode.jsを理解してから入るのがおすすめです。GraphQLのAPIを検討している方はGraphQL vs REST API比較記事も合わせてどうぞ。

よくある質問

Q: HonoとExpressはどちらを先に学ぶべきですか？

A: Expressから学ぶことをおすすめします。Expressは情報量が圧倒的に多く、詰まったときの解決策が見つかりやすいです。Expressの基本（ルーティング、ミドルウェア、レスポンス）を理解してから移行すると、Honoの学習コストはほぼゼロです。何年もの歴史と膨大なQiita記事・Stack Overflow回答があるExpressを入門に使うのは合理的な選択です。

Q: HonoはVercelのEdge Functionsでも使えますか？

A: 使えます。@hono/vercelアダプタを使うとVercel Edge Functionsで動かせます。ただしNode.jsランタイムとEdgeランタイムでは使えるAPIが違うので、Node.js固有の機能（fs、crypto等）を使っているコードはEdgeでは動きません。デプロイ先の選定についてはNext.jsデプロイ先比較2026も参考になります。

Q: HonoでREST APIを作るとき、バリデーションはどうするのがいいですか？

A: @hono/zod-validatorとzodの組み合わせが現状ベストプラクティスです。リクエストボディのバリデーションと型推論が同時に効くので、手書きの型アサーションが不要になります。本番APIに入れることで、不正なリクエストによるランタイムエラーを事前に防げます。本文のQ6のコード例が参考になります。

Q: Node.jsからBunに移行するときHonoのコードは書き直しですか？

A: ほぼ書き直し不要です。@hono/node-serverを削除して、Bunのネイティブサーバーとして動かすだけです。アプリ本体のコード（ルーティング・ハンドラ・ミドルウェア）はそのままで動きます。これがマルチランタイム対応の恩恵です。詳しくはBunへのNode.js移行1ヶ月レポートを参照してください。

追記（2026/05/11）: Hono v4が2026年4月にリリースされ、Streamingのサポートが強化されました。AIサービスとのストリーミングレスポンス（text/event-streamを使ったSSE）が書きやすくなっています。既存のコードへの破壊的変更はほぼないので、v3からv4への移行コストは低いです。