先に要点
- Hono は Web 標準 API(「Request」 「Response」)ベースの 軽量 Web フレームワーク。Cloudflare Workers / Deno / Bun / Node / Vercel Edge / AWS Lambda など、ほぼあらゆるランタイムで同じコードが動く。
- API は Express に近く、「app.get('/users', c => c.json(...))」 のように直感的。学習コストが小さい 上に、Edge で動くサイズ感(数十KB) という両立がポイント。
- 型安全ルーティング、JSX 内蔵、RPC モード(クライアントから型付きで呼べる) など、TypeScript ファーストな機能が組み込まれている。Zod 連携も自然。
- 本命用途は Cloudflare Workers / Vercel Edge / Deno Deploy 等のエッジ実行基盤での API サーバ。Edge と Serverless の使い分け で 「Edge を選ぶ」 と決めた瞬間に、Hono は事実上の有力候補になる。
Hono ってよく見るけど、Express で十分じゃないの？ 「なぜ Cloudflare Workers と組み合わせるの？」 ── 2022年に登場した Hono は、「エッジで動かす Web フレームワーク」 として急速にデファクトの地位を固めつつあります。
ざっくり言うと、Hono は Web 標準 API でリクエストとレスポンスを扱う、軽量で速い Web フレームワーク です。 Express / Fastify のような書き心地を保ちつつ、どのランタイムでも動く 設計で書かれているため、「Cloudflare Workers で書いたコードをそのまま Node で動かす」 「Bun に移し替える」 のようなことが普通にできます。
この記事では、2026年5月時点の Hono の状況をベースに、何ができるか・Express との違い・どのランタイムで動くか・採用判断軸 を整理します。 仕様や互換性は活発に変化しているので、最終確認は 公式ドキュメント を見るのが安全です。
Hono の特徴 — 5つの核
「Hono を選ぶと何が嬉しいか」 を5つに整理します。
①Web 標準 API ベース
「Request」 と 「Response」 を使う設計。「Cloudflare Workers / Deno / Bun / Vercel Edge」 が前提とする世界と完全に同じ言語で書ける。
② 超軽量
Hono 本体は 数十KB。Edge ランタイムの 「Cold start 短く・配布サイズ小さく」 要件をそのまま満たす。
③ マルチランタイム
「 Cloudflare Workers / Deno / Bun / Node / AWS Lambda / Vercel / Fastly Compute」 …。同じコードがどこでも動く。ランタイム選定のロックインを避けられる。
④ 型安全ルーティング
「 URL パラメータの型」 「クエリの型」 「バリデーション結果の型」 が全部 TS の型として手に入る。Zod や Valibot と連携した検証が標準的。
⑤ JSX 内蔵
「 HTML 応答を返す API」 を JSX で書ける。React Server Components のような 「サーバで JSX」 体験が、API レベルでも手に入る。
「軽くて、速くて、どこでも動く」 のが Hono の体感を一言で表す部分で、特に Edge ランタイムでの開発体験 を大きく変えました。
基本の書き方 — 最小例
最小コードで雰囲気をつかみます。
import { Hono } from 'hono';
const app = new Hono();
app.get('/', c => c.text('こんにちは Hono!'));
app.get('/users/:id', c => {
const id = c.req.param('id');
return c.json({ id, name: 'Alice' });
});
export default app;
これだけで 「GET /」 と 「GET /users/:id」 の API ができます。「export default app」 した結果は、どのランタイムでも 「そのまま動かせる」 形になっています。
「c.json」 / 「c.text」 / 「c.html」
レスポンスを返すヘルパー。「c.json({...})」 で JSON、「c.text('...')」 で text、「c.html(...)」 で HTML を返す。「Response」 オブジェクトを返すのと同じことを短く書ける。
ミドルウェア
「app.use('/api/*', cors())」 のように、Express 風のミドルウェアを書ける。CORS、認証、ロギング、Rate Limit など標準で提供されるものが豊富。
バリデーション
「 zValidator('json', schema)」 のような形で Zod による入力検証を組み込める。「schema 通りでなければ自動で 400 を返す」 という典型処理が1行で書ける。
RPC モード
「Hono Client」 を使うと、サーバ側のルートをクライアントから 型付きで関数として呼べる。tRPC と似た体験を Hono 内で実現できる。
「Express の感覚で書けるが、現代的な機能と型安全性が揃っている」 のが、Hono の良いところを一行で言うとそうなります。
マルチランタイムの威力
「同じコードがあらゆるランタイムで動く」 は、具体的に何が嬉しいか整理します。
| ランタイム | 用途 | Hono との関係 |
|---|---|---|
| Cloudflare Workers | グローバル分散エッジ | 事実上の本拠地。最も Hono が真価を発揮する |
| Vercel Edge Functions | エッジ API / Next.js Route Handlers | そのまま動く。Vercel との組み合わせも自然 |
| Deno Deploy | セキュア + Web 標準のエッジ | シンプルに動く。Deno 標準 と相性◎ |
| Bun | 高速ランタイム | 「Bun.serve」 経由で動く。Hono の良い相棒 |
| Node.js | 業界標準 | 「@hono/node-server」 で動く。既存資産と並行運用可 |
| AWS Lambda | サーバレス | 「@hono/aws-lambda」 で動く。「Edge から AWS まで一気通貫」 |
| Fastly Compute | 競合エッジ | 動く。「どこで動かすか後で決める」 戦略が可能 |
「コードを動かす場所を後から決められる」 のは、「まずローカルで動かす → 開発が進んだら本番ホスティング決める」 のような柔軟性に直結します。 「AWS Lambda で動かしていたコードを Cloudflare Workers に移す」 ような大きな引っ越しも、Hono なら 「アダプタを差し替える」 程度の作業で済むことが多いです。
Express / Fastify との比較
「Express から Hono に乗り換える価値は？」 を整理します。
| 軸 | Express | Fastify | Hono |
|---|---|---|---|
| 登場時期 | 2010 | 2016 | 2022 |
| 主な実行環境 | Node.js | Node.js | マルチランタイム |
| API スタイル | コールバック | async / await | async / await + Context |
| 速度 | 普通 | 速い | 非常に速い(ベンチ上位) |
| 型サポート | 後付け | そこそこ | ファーストクラス |
| Edge / Workers | 非対応 | 非対応 | 対応 |
| エコシステム | 圧倒的に厚い | 厚め | 急成長中 |
| 主な選び所 | 歴史ある Node 案件 | Node で速度重視 | Edge / 新規 TS プロジェクト |
「Express でも問題なく動いている既存の Node サーバ」 をわざわざ Hono に置き換える理由は薄いですが、` 新規で Edge / Workers / Bun / Deno を意識するなら Hono がほぼ第一候補、というのが2026年現在の感覚です。
Cloudflare Workers との組み合わせ
Hono が最も力を発揮するのが Cloudflare Workers です。
Cloudflare Workers とは
世界中のエッジで V8 isolates ベースに動くサーバレス。「Cold start ほぼゼロ」 「グローバル分散」 が特徴。Hono の Web 標準 API ベースの設計と完全に噛み合う。
バインディングを使える
Cloudflare の D1(SQLite)、KV、R2(オブジェクトストレージ)、Durable Objects、Queues などを、Hono の Context から直接取り出して使える。「Cloudflare スタックでフルスタックを組む」 ことができる。
Wrangler との統合
Cloudflare の CLI 「wrangler」 とシームレスに連携。「wrangler dev」 でローカル開発、「wrangler deploy」 で本番デプロイ。
無料枠の手厚さ
Cloudflare Workers は無料枠が非常に大きく、「個人プロジェクトを商用にしても無料で運用できる」 規模感(Vercel Hobby の制約 とは対照的)。
「Hono + Cloudflare Workers + D1 + R2」 は、AI 時代の 「グローバルに動くフルスタック」 を最小コストで作る組み合わせとして強い人気を集めています。
JSX 内蔵 — Hono で HTML を返す
Hono は JSX を直接 import して使える ようになっています。
import { Hono } from 'hono';
const app = new Hono();
app.get('/', c => {
return c.html(
<html>
<body>
<h1>こんにちは Hono!</h1>
<p>JSX も書ける Web フレームワーク</p>
</body>
</html>
);
});
export default app;
「HTML を返す軽量サイト」 を Hono + JSX で書く、というスタイルが採れます。 これは htmx のような 「サーバで HTML を組み立てる」 派の哲学とも相性が良く、「React 一辺倒ではない選択肢」 として注目されています。
どこで詰まりやすいか
便利な反面、現場で踏みやすい注意点もあります。
①Node 専用ライブラリ
Hono 自体は Edge 互換ですが、「Node 専用 API を使うライブラリ」 を import すると Cloudflare Workers / Deno で動かない。「採用ライブラリの互換性」 を最初に確認するのが大事。
② エコシステムの厚み
Express の 「ミドルウェア数千」 のような蓄積はまだない。「典型的に欲しいもの」 は揃っているが、「ニッチな機能」 は自前で書くことになる場合がある。
③ ランタイム間の差
「Cloudflare Workers の CPU time 制限」 「Deno の権限モデル」 など、ランタイム固有の制約は残る。「同じコードが動く」 とはいえ、「同じ性能・同じ挙動」 を保証はしない。
④ 既存 Express 資産の移行
「 Express ミドルウェアを Hono 風に書き換える」 が必要になる。「数十のミドルウェアを使っている既存サービス」 を一気に移行するのは現実的ではないので、新規部分から Hono に寄せるのが安全。
「Hono は完璧」 ではなく、「ランタイム前提が新しいからこその制約」 と付き合う必要がある、というのが正確な認識です。
採用判断のチェックリスト
「Hono を選ぶか別の Web フレームワークにするか」 の判断材料を整理します。
「 新規 Edge / Workers / Deno / Bun の API サーバ」 を作るなら、まず Hono を検討 するのが2026年現在のスタンダードな入り口です。
AI 時代の Hono
AI 連携の文脈でも Hono の特徴は活きます。
Edge × AI ストリーミング
LLM 応答をストリーミングで返す API を、「Hono on Cloudflare Workers」 で書くと 世界中のユーザーに低遅延で AI 応答を届ける 構成が組みやすい。
小さなバイナリで素早く起動
「 AI ツールを社内向け / 個人向けに公開したい」 ときに、Hono + Workers の無料枠で 「動かし続けるコストがほぼゼロ」 で済む。
「AI で爆速にサービスを立ち上げて、低コストで世界中に出す」 という現代的な開発スタイルにおいて、Hono は重要な土台ピースのひとつです。
Hono に関するよくある質問
Q. Hono と Express、新規で書くならどっち？
A. Edge / Workers / Bun / Deno を視野に入れるなら Hono、純 Node で既存資産が大量にあるなら Express。「新規プロジェクトで TS フルスタック」 なら Hono を選んで困ることは少ないです。
Q. Express からの移行は大変ですか？
A. 小規模なら半日〜数日程度で移行できます。大規模で 「Passport / express-session / 独自ミドルウェア多数」 のような構成だと、「どれを Hono ネイティブで書き直すか」 の検討が時間を取ります。「新規部分から Hono に寄せる」 段階移行が現実的です。
Q. Hono だけで Web サイトを作れますか？
A. はい。「JSX + Hono Router」 で軽量なサイトが組めます。「React Server Components ほどリッチではないが、シンプルに HTML を返したい」 案件にちょうど合う粒度です。
Q. Cloudflare Workers と Vercel、どちらで Hono を動かすべきですか？
A. 用途で分けます。Cloudflare Workers: 純粋な API、グローバル分散、無料枠重視、Cloudflare スタック活用。Vercel: Next.js と統合、フロントと一緒に管理、Vercel エコシステム重視。「どっちも Hono で書けば後で乗り換えやすい」 のが Hono の良さです。
Q. Hono の RPC モードと tRPC、どちらを使うべきですか？
A. tRPC は 「内向き TS フルスタック」 に最適化されており、Hono RPC は 「Hono サーバの一機能」 です。「Hono を Edge で動かす API サーバとして使う」 ならそのまま RPC モードを使うのが自然、「tRPC エコシステム(React Query 統合など)」 をフル活用したいなら tRPC を選ぶ、と棲み分けます。
Q. Hono は商用利用できますか？
A. はい、MIT ライセンスで自由に商用利用できます。Cloudflare 公式のサンプルやチュートリアルでも標準的に使われており、企業採用も増えています。
Q. Hono の学習コストは？
A. Express を知っていれば数時間で書き始められる レベルです。「app.get / app.post / app.use」 の基本概念が同じなので、「違いは Context オブジェクトと Response の返し方」 を覚えれば十分。
参考リンク
- Hono: 公式サイト
- Hono Docs: Documentation
- Hono: GitHub
- Cloudflare Workers: 公式
- Wrangler: Documentation
- Vercel Edge Functions: 公式
- Deno Deploy: 公式