Hono + Inertia + React のデプロイ完全ガイド

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