Hono + Inertia + React のデプロイ完全ガイド — Cloudflare Workers / Vercel / Bun サーバの選び方と CI/CD【2026年版】

Hono は複数ランタイムで動くため、デプロイ先の選定が初手のキードライバーになります。判断軸は次の3つ： - ランタイム: Workers / Vercel Functions / Node / Bun のどれで動かすか - ロケーション: エッジ（世界中で実行）か、特定リージョン（東京・大阪）か - 運用負荷: マネージド（Workers / Vercel）か、自前 VPS か、コンテナ（ECS / Cloud Run）か この3軸の組み合わせで、自然に候補が3〜5個に絞れます。

- グローバル配信のSaaS / マーケサイト寄り: Cloudflare Workers - 国内向け業務システム・社内ツール: Vercel（東京リージョン）または Fly.io（東京）。Postgres 併設が楽なら Fly.io / Render / Railway - 既存 AWS 資産が多い大企業: ECS Fargate / Cloud Run - 小規模で1台で済ませたい: Bun on VPS（さくら / Vultr / Hetzner） - エンタープライズ要件で SLA・監査が必要: Vercel Enterprise / 専用クラウド 意外と「Workers + 東京の Postgres（Hyperdrive）」の組み合わせが日本国内向けでも実用速度に乗るケースが増えています。

Inertia は SSR をサポートしますが、案件によっては不要です。判断軸： - SEOが重要なページがある: SSR 推奨 - 完全に認証ウォールの内側: SSR 不要、CSRで充分 - 初回表示の体感速度を最重要視: SSR がやや有利 SSR を有効化すると Hono サーバ側に React の SSR レンダラーが乗るため、ビルド・運用がやや重くなります。「最初から全部入り」より、必要なページだけ後から有効化するアプローチが実用的です。

GitHub Actions で組む最小ワークフロー： 1. trigger: `push` to `main` および PR 2. install: `bun install` 3. lint / typecheck: `bun run lint`、`bun run typecheck` 4. test: `bun test` 5. build: `bun run build`（クライアント・サーバ） 6. deploy: - Cloudflare Workers: `wrangler deploy` - Vercel: `vercel --prod`（または Vercel Git 連携で自動） - Fly.io: `flyctl deploy` 本番デプロイは `main` への push 時のみ、PRはプレビュー環境にデプロイ、というパターンが運用しやすいです。

デプロイ先によってシークレット管理は異なります。 - Cloudflare Workers: `wrangler secret put`、または `.dev.vars`（ローカル） - Vercel: ダッシュボードからの環境変数管理、または `vercel env` - Fly.io: `flyctl secrets set` - VPS: `.env` を sops / age で暗号化、または Vault / AWS Secrets Manager 共通の鉄則： - Git にシークレットを絶対コミットしない - 本番・ステージング・開発で別の鍵を使う - ローテーション手順を最初から決めておく

本番運用で最低限欲しいもの： - エラー追跡: Sentry（フロント・バック両方計装） - アプリログ: Workers なら Logpush / Logtail、Vercel なら Vercel Logs、それ以外は Datadog / Better Stack / Loki などへ集約 - アップタイム監視: Better Stack / UptimeRobot - APM: 必要に応じて Datadog APM や Cloudflare Workers Analytics - DBスローログ: 業務アプリは特に重要 社内ダッシュボードを Slack / Discord に集約すると、レビュー文化と相性が良くなります。

- Workers のサイズ制限: コードバンドルにNodeネイティブモジュールを含めると爆発する。Workers向けに `nodejs_compat` フラグや代替ライブラリを使う - Cookie / セッションストア: Workers ではメモリストアが使えないため、KV / D1 / 外部 Redis などに置く - ファイルアップロード: 大ファイルは R2 / S3 へ直接、サーバ経由しない設計に - Cron: Workers Cron Triggers / Vercel Cron / 外部スケジューラを使い分け - タイムゾーン: 日本向けは `Asia/Tokyo` を明示、サーバ・DB・クライアントで揃える

オブライトでは、案件特性に応じて Cloudflare Workers / Vercel / Fly.io / 自社運用VPS の組み合わせを使い分けています。中小〜中規模の業務システム・社内ツール案件では「Hono + Inertia + React on Vercel または Fly.io + Postgres」がコスト・運用・スピードのバランスがよく、しばしば第一候補になります。AI 機能を組み込みたい場合は、 AI 導入コンサルティング や OpenClaw と組み合わせて、エッジ実行のメリットを活かしたハイブリッド構成も検討します。

本シリーズはこれで完結です。 - Part 1: スタック概要・なぜ選ぶか - Part 2: 環境構築完全手順 - Part 3: フォーム＆CRUD実装パターン - Part 4: 認証完全ガイド - 第5回（本稿）: デプロイ完全ガイド 全5回を通じて、Next.js でも Remix でもないフルスタックの一連の流れを実装可能な形で示しました。実案件への適用や PoC のご相談は Web 開発 / ソフトウェア開発 / お問い合わせ からどうぞ。

Q1: Workers と Vercel、初手で悩むんですが A: グローバルかつコスト重視なら Workers、UI と DX の心地よさ・チームでの扱いやすさを取るなら Vercel。日本国内中心なら Vercel の東京リージョン or Fly.io 東京が分かりやすいです。 Q2: マルチリージョンの DB はどうする？ A: Workers + Hyperdrive で外部 Postgres にプロキシ、または Neon / Turso / D1 を選択肢として検討。CRUD 中心の業務系なら Tokyo シングルリージョンで十分なケースが多いです。 Q3: ロールバックは？ A: Vercel・Workers ともに直近のデプロイへの即時ロールバックが可能。ロールバック時の DB マイグレーションの取り扱いだけ、設計段階で決めておくと安全です。 Q4: ステージング環境は必要？ A: 業務システムでは強く推奨。プレビュー環境（PR ごと）と長期ステージング環境を分けて運用すると、リリース前の最終確認が楽になります。

- Cloudflare Workers ドキュメント - Vercel ドキュメント - Fly.io ドキュメント - Hono — Cloudflare Workers ガイド - Inertia.js — Server-side Setup