Honoを本番で使うべきか？判断マトリクスと移行コスト
- 課題: Honoは速くて美しいが、「本番に投入する価値があるか」はベンチマークではなく移行コストと運用リスクの問題だ。
- 解決策: 5軸の判断マトリクス（対象ランタイム、型安全の必要性、エコシステム成熟度、チーム／採用、ロックイン）と隠れコストのモデル。
- 結果: 3つの明確なシナリオ——グリーンフィールドのエッジなら採用、安定したExpressモノリスなら見送り、本番フルスタックが今すぐ必要なら待ち。問題で決める。
短い答え: はい——新規のエッジAPI層やマイクロサービスを作り、端から端まで型安全にしたいなら。いいえ（または今はまだ）——安定して動いているExpressモノリスがあるなら。ExpressからHonoへは段階的に移行できないため、代償は書き直しであって漸進的な修正ではないからだ。これはベンチマークではなく、コストと運用リスクの判断だ。
TL;DR（エグゼクティブサマリー）
- 課題: Hono実践記はHonoが速く、小さく、型も良いことを示した。だが「試して気に入った」と「チームの本番に入れる」は別の判断だ。後者はコストとリスクを伴う。
- 解決策: req/秒の数字を眺める代わりに、5軸のマトリクスと隠れコストのモデル（移行、採用、エコシステム、可観測性）で判断する。
- 結果: 3つの明確なシナリオ。デリバリーマネージャーにとって正しい問いは「Honoは良いか」ではなく「自分の具体的な問題に対する3年間の総保有コストはいくらか」だ。
再定義：フレームワーク採用は技術ではなくデリバリーの判断
きれいなベンチマークはエンジニアを5分で説得する。だが実際に採用の成否を決めるのは、書き直しのコスト、チームが習熟するまでの時間、エッジケースに当たったときのライブラリの揃い具合、そして2年後に保守できる人を採用できるか——すべてデリバリーの変数であり、速度テストの変数ではない。
言い換えれば「HonoはExpressより速い」は、既に動いているシステムに入れるべきかにはほとんど関係しない。以下が私の使う枠組みだ。
なぜ移行コストが最大の変数なのか
多くの人が見落とすのがここだ：同一アプリ内でExpressからHonoへルートを一つずつ移すことはできない。 ExpressはNodeのreq/resに、HonoはWeb標準のRequest/Responseに依存する。二つのリクエスト／レスポンスモデルは根本的に異なり、一つのコードベース内で「ラップして並走させる」きれいな道はない。
実務上の帰結：
- すべてのルートハンドラは書き直しであって、修正ではない。
- Express固有のミドルウェア（
passport、multer、express-session…）はWeb標準互換版に置き換える必要がある——多くは@hono/*エコシステムに相当物があるが、すべてのケースで1対1ではない。 - だから安全な戦略はサービス単位のストラングラーパターンだ：新しいサービス／マイクロサービスをHonoで作り、古い方は動かし続け、二つのフレームワークを一つのアプリに混ぜない。
つまり移行コストは「ルート数」に比例せず、塊ごとの書き直しの判断になる。大規模で安定したExpressコードベースでは、この数字は便益を上回ることが多く、答えはいいえだ。
5軸の判断マトリクス
私はHonoを5つの軸で採点する。大半が右の列に傾けば採用、左に傾けば見送り。
| 軸 | 「Honoを使わない」に傾く | 「Honoを使う」に傾く |
|---|---|---|
| 対象ランタイム | 伝統的Node、長時間稼働サーバー | エッジ（Workers/Deno/Vercel）、複数ランタイム |
| 型安全の必要性 | 小さな社内API、クライアント少 | サーバー→クライアントの型をコード生成なしで流したい |
| 現状 | 大きく安定したExpressモノリス | グリーンフィールド、または新規切り出しサービス |
| チーム／採用 | Expressに習熟、Expressで採用 | TSファースト、エッジ/Bunで構築 |
| 周辺リスク許容度 | すべてのミドルウェアが既製品必須、自作ゼロ | エコシステムに無ければ自作してもよい |
読み方：現状と対象ランタイムの重みが最も大きい。移行コストを決めるからだ。この二つだけで大半のケースは採否を判定できる。
あまり見積もられない隠れコスト
移行以外に、ベンチマークに現れないコストがある：
- 約4年の若いエコシステム。 Honoのコアは本番対応でダウンロードも急増（2026年には週あたり数千万）だが、Expressより10年若い。たまにExpressなら一行の
npm installで済むミドルウェアを自作することになる。その分のエンジニア工数を見込む。 - 採用とバス係数。 Expressは候補者層が厚く10年分のドキュメントがある。Honoは新規のNodeバックエンドの大半を取りつつあるが、本番で動かした経験者の層はまだ小さい。問い：2年後に誰が保守するか？
- エッジでの可観測性。 Workersで動かすとはエッジの可観測性モデルに入ること：ログ／メトリクスはプラットフォームのツールを通り、分散レート制限はしばしばDurable Objectsを要し、キャッシュはCache APIを使う。難しくはないが別の運用モデルで、学習コストがある。
- ESMのみ。 旧インフラにCommonJSが残っていれば、その整理コストを数える。
3つのGo/No-Goシナリオ
シナリオA — グリーンフィールドのエッジAPI → 採用。 Cloudflare Workers/Deno上に新しいAPI/ゲートウェイ層やマイクロサービスを作り、ミリ秒のコールドスタートと端から端までの型安全が必要。Honoの本拠地だ。移行コストはなく利点だけ。採用する。
シナリオB — 安定したExpressモノリス → 見送り。 大きなExpressアプリがミドルウェア多数で問題なく稼働中。移行は全ハンドラの書き直しとミドルウェア置換を意味する——高コスト、高リスク、限界便益は低い。本当にエッジが必要なら、ストラングラーパターンでHonoの新サービスを切り出す。モノリスには触らない。
シナリオC — 本番フルスタックフレームワークが今すぐ必要 → 待ち。 Honoの上にNext風のもの（HonoX）が欲しい。方向は正しいが、HonoXはまだalphaでマイナーバージョンが壊れうる。今日の本番ではAPIにHono＋別立てのフロントエンドで、HonoXが安定するまで追う。
よくある質問
移行期間中、HonoとExpressを並行稼働できるか？
できる。ただし別サービスのレベルであって、一つのアプリ内で混ぜない。実務的には、新サービス（または新しいエンドポイント群）をHonoで作り、リバースプロキシ／ゲートウェイの背後に置き、古いExpressアプリからトラフィックを徐々に抜く——ストラングラーパターンだ。二つのリクエスト／レスポンスモデルは直接互換ではないため、一つのプロセスに二つのフレームワークを混ぜるのは負債を招く。
Honoは長期的に安全な賭けか？
エッジAPI層についてはそう考える根拠がある：Web標準の上に作られているため特定のランタイムへの依存が少なく、ダウンロードは急増し、多くの新規バックエンドアプリのデフォルトになりつつある。長期リスクはコアではなく周辺にある——若いエコシステムと不安定なHonoXだ。すべてを担わせるのではなく適切な役割（エッジAPI、マイクロサービス）で使うなら、長期的にも妥当な選択だ。
本記事はHono実践記（コード、ベンチマーク、ハマりどころ）の判断編だ。同じエッジアーキテクチャのクラスタ：運用におけるエッジAIとコンピュータビジョン。エッジのAPI層やインフラ再構築を検討中なら、プロジェクトストーリーやお問い合わせもどうぞ。