2024.09.19 フレームワーク

HonoXとは？Hono×Viteのメタフレームワークの特徴・使い方・採用判断

HonoXは、軽量WebフレームワークHonoにViteを組み合わせ、ファイルベースルーティング・SSR・Islands（部分ハイドレーション）を足したメタフレームワークです。2026年7月時点の最新はv0.1.56で、まだ0.1系（アルファ）のため同一メジャー内でも破壊的変更が入ります。本記事では定義と仕組み、始め方、Cloudflare Workersへのデプロイに加え、アルファ版をどの案件で採用・回避すべきかまで判断できるよう最新版で整理します。

まとめ

  • Honoがエッジ／サーバー側のルーティングとリクエスト処理を、Viteが開発サーバーとビルドを担う。
  • HonoXが足すのはファイルベースルーティング・SSR・Islands・クライアントエントリの4点。データ取得層やORMは持たないミニマル設計。
  • 最新はv0.1.56（0.1系アルファ）。破壊的変更が入る段階なので、本番採用はバージョン固定と影響範囲の確認が前提。
  • 個人開発やエッジ前提の小〜中規模フルスタック／APIに向く。長期安定・大規模・実績重視ならNext.jsやAstroが無難。

以下で、Honoとの違い・具体的な始め方・Islands・デプロイ・採用判断の順に掘り下げます。

HonoXの定義とHono×Viteの構成

メタフレームワークとは、ベースのライブラリやフレームワークに、ルーティング・レンダリング・ビルドといったアプリの土台となる規約を足した上位のフレームワークを指します。HonoXは、そのベースにHono、ビルド基盤にVite、描画にUIライブラリ（既定はHono JSX）を据えた構成です。Hono単体はルーターとハンドラーの薄い層ですが、HonoXはそこに「ページを置けばURLになる」開発体験を加えます。

HonoとViteそれぞれの役割

観点 Hono Vite
担当 ルーティング・リクエスト処理 開発サーバー・ビルド
実行場所 エッジ／サーバー 開発時・ビルド時
主な接点 createApp・ミドルウェア honox/viteプラグイン

Honoはリクエストを受けてレスポンスを返す実行時の中核、Viteはコードをまとめて配信可能にする開発・ビルド時の道具、と役割が分かれています。「hono vite」で調べる際は、この2つが別レイヤーである点を押さえると設定が読みやすくなります。

HonoXが提供する機能・しない機能

提供するのはファイルベースルーティング、SSR、Islandsによる部分ハイドレーション、クライアントエントリの4点です。一方で、独自のデータ取得層・状態管理・ORMなどは持たず、レンダラーすら差し替え可能（Bring Your Own Renderer）という薄さを保っています。必要な機能はHonoのミドルウェアや外部ライブラリで足す前提であり、「全部入り」を期待するとNext.jsとの差に戸惑います。

HonoXの始め方とプロジェクト構成

プロジェクトの雛形はcreate-honoで作成し、テンプレート選択でx-basicを選ぶのが最短です。生成されるのはViteにhonox()プラグインを組み込んだ最小構成で、app配下のディレクトリ規約が中心になります。

# 雛形を作成（プロンプトで x-basic を選択）
npm create hono@latest my-app

# 構成の例
app/
  routes/      # ファイルベースルーティング
  islands/     # インタラクティブ部品
  server.ts    # サーバーエントリ
  client.ts    # クライアントエントリ

サーバーエントリのapp/server.tsでcreateApp()を呼ぶとHonoインスタンスが返り、Honoのミドルウェアがそのまま使えます。Viteの設定はhonox/viteのプラグインを差すだけです。

// app/server.ts
import { createApp } from 'honox/server'
export default createApp()

// vite.config.ts
import honox from 'honox/vite'
import { defineConfig } from 'vite'
export default defineConfig({ plugins: [honox()] })

ファイルベースルーティングとcreateRoute

app/routesに置いたファイルのパスがそのままURLになります。ハンドラーはhonox/factoryのcreateRouteで定義し、default export がGET、名前付きexport（POST／PUT／DELETE）が各メソッドに対応します。1ファイルに複数メソッドを同居させられるため、フォーム送信も同じ場所に書けます。

// app/routes/index.tsx
import { createRoute } from 'honox/factory'

export default createRoute((c) => {
  return c.render(<h1>Hello, HonoX!</h1>)
})

export const POST = createRoute(async (c) => {
  const { name } = await c.req.parseBody()
  return c.redirect('/')
})

レンダラーとネストレイアウト（_renderer.tsx）

ページの外枠はapp/routes/_renderer.tsxで定義します。既定はhono/jsx-rendererのjsxRendererで、ディレクトリごとに_renderer.tsxを置けばレイアウトを入れ子にできます。ほかに_middleware.ts（ディレクトリ単位のミドルウェア）、_error.tsx、_404.tsxといったアンダースコア始まりの特別ファイルが用意されています。

// app/routes/_renderer.tsx
import { jsxRenderer } from 'hono/jsx-renderer'

export default jsxRenderer(({ children, title }) => (
  <html>
    <head><title>{title}</title></head>
    <body>{children}</body>
  </html>
))

Reactを使いたい場合は_renderer.tsxを@hono/react-rendererのreactRendererに差し替え、あわせてcreateClientのハイドレーション処理をReact用に指定します。描画層を交換できるのがHonoXの薄さの表れです。

Islandsによるインタラクティブ化

HonoXは既定でサーバー描画（SSR）し、クライアント側のJavaScriptを配りません。ボタンやカウンターなど操作が必要な部品だけを「島（Island）」として切り出すと、その部分にだけJavaScriptがハイドレーションされます。島はapp/islandsディレクトリに置くか、$counter.tsxのように$接頭辞を付けたファイルとして認識させ、app/client.tsでcreateClient()を呼びます。考え方の背景はアイランドアーキテクチャとは？仕組み・Astroの実装・PPRとの違いで整理しています。

// app/islands/counter.tsx
import { useState } from 'hono/jsx'

export default function Counter() {
  const [count, setCount] = useState(0)
  return <button onClick={() => setCount(count + 1)}>count: {count}</button>
}

// app/client.ts
import { createClient } from 'honox/client'
createClient()

ビルドとデプロイ（SSG・Cloudflare Workers）

本番ビルドはクライアントとサーバーを分けて2回実行します（先に--mode client、続けて通常ビルド）。全ページを静的化したい場合は@hono/vite-ssgを追加すればSSGになります。デプロイ先としてCloudflare Workersを選ぶ場合は、@hono/vite-build/cloudflare-workersとdev-serverアダプターを設定し、wranglerで公開します。Cloudflare Workers側の前提はCloudflare Workersとは？対応言語・無料枠・使い方・料金を最新版で総まとめを参照してください。

// vite.config.ts（Cloudflare Workers 向け）
import build from '@hono/vite-build/cloudflare-workers'
import adapter from '@hono/vite-dev-server/cloudflare'
import honox from 'honox/vite'
import { defineConfig } from 'vite'

export default defineConfig({
  plugins: [honox({ devServer: { adapter } }), build()],
})

// ビルドとデプロイ
vite build --mode client
vite build
wrangler deploy

HonoXを採用すべき場面・避けるべき場面（アルファ版の判断）

採用の可否は好みではなくバージョンの現実で決めるべきです。HonoXは2026年7月時点でv0.1.56、0.1系のアルファであり、公式も同一メジャー内で破壊的変更が入ると明言しています。つまり「動くこと」と「半年後もそのまま動くこと」は別問題です。

向いているのは、個人サイトやブログ、エッジ配信前提の小〜中規模フルスタック、Honoに慣れたチームの実験用途、少量のUIを持つ軽量APIです。逆に、長期の安定運用・大規模チーム・豊富なプラグインエコシステムを前提とする案件では避け、Next.jsやAstroなど成熟した選択肢を採るべきです。判断に迷ったら、まずバージョンを固定し、破壊的変更の追随コストを許容できるかを先に決めてください。なお「島だけ欲しくフレームワークの土台は要らない」ケースでは、Hono単体にhono/jsx-rendererを足すだけで足りることも多く、HonoXを入れない選択も有力です。

よくある質問

HonoXとHonoの違いは何ですか？

Honoはルーターとハンドラーを提供する薄いWebフレームワークで、HonoXはそのHonoにViteを組み合わせ、ファイルベースルーティング・SSR・Islands・クライアントエントリを足したメタフレームワークです。HonoXの内部はHonoインスタンスなので、Honoのミドルウェアはそのまま使えます。

HonoXは本番環境で使えますか？

技術的には可能ですが、2026年7月時点でv0.1.56の0.1系アルファであり、同一メジャー内でも破壊的変更が入ります。本番で使うならバージョンを固定し、アップデート時の影響範囲を確認できる体制を前提にしてください。安定性を最優先する案件では他フレームワークが堅実です。

HonoXでReactは使えますか？

使えます。既定はHono JSXですが、レンダラーを差し替えられる設計（Bring Your Own Renderer）のため、@hono/react-rendererを導入しcreateClientのハイドレーションをReact用に設定すればReactで描画できます。

HonoXの最新バージョンは？

2026年7月時点の最新はv0.1.56で、リリースは0.1系が続いています。バージョンは頻繁に更新されるため、導入前にnpmや公式リポジトリのリリースで最新を確認してください。

メタフレームワークとは何ですか？

ベースのフレームワークやライブラリに、ルーティング・レンダリング・ビルドなどアプリの土台となる規約を足した上位のフレームワークを指します。HonoXはHonoを土台にしたメタフレームワークで、Next.js（React土台）やAstroなどと同じ位置づけです。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る