「Express で書いた問い合わせ API を Heroku で動かしているが、月数千円のランニングコストが気になる」「LP に置く API のレイテンシをミリ秒まで削りたい」——コーポレートサイトや小規模 SaaS の受託で、軽量 API 基盤の刷新ニーズが高まっています。
そこでデファクトになりつつあるのが Hono と Cloudflare Workers の組み合わせです。ゼロコールドスタート、世界 300 都市から配信、月 1000 万リクエストまで実質無料という、コストとパフォーマンスを両立する選択肢です。本記事では、Express ベースの API を Hono + Workers にリプレースする受託案件の設計指針を整理します。
なぜ Hono + Workers なのか — 3 つの定量効果
Express + コンテナの構成と比較したときの差分を、受託の見積で説明しやすい指標で並べます。
| 指標 | Express + Cloud Run / ECS | Hono + Cloudflare Workers |
|---|---|---|
| コールドスタート | 数百 ms 〜 数秒 | 実質ゼロ |
| 月額固定費 | 最低 1,000〜3,000 円 / インスタンス | 月 10 万 req まで無料 |
| 世界配信 | 単一リージョン | 300+ 都市から自動配信 |
| デプロイ時間 | 数分（イメージビルド） | 数秒 |
| ランタイム | Node.js | V8 isolates（Web 標準 API） |
「月 1,000 万リクエスト以下、CPU 30 秒未満」のワークロード——多くの BtoB API はここに収まります——では、ランニングコストが 1/10 以下になるケースが珍しくありません。
最小構成のスケルトン
Hono のシグネチャは Express を触ったことがある人なら 30 分で理解できます。
import { Hono } from "hono";
import { cors } from "hono/cors";
import { logger } from "hono/logger";
type Env = { Bindings: { DB: D1Database; SECRET: string } };
const app = new Hono<Env>();
app.use("*", logger());
app.use("/api/*", cors({ origin: ["https://gleamhub.net"] }));
app.post("/api/contact", async (c) => {
const body = await c.req.json();
await c.env.DB.prepare(
"INSERT INTO contacts (email, message) VALUES (?, ?)"
).bind(body.email, body.message).run();
return c.json({ ok: true });
});
export default app;wrangler deploy で約 5 秒、エッジ配信が始まります。
認証 — 「Workers にセッションを持たせない」が定石
Workers は基本的にステートレスです。セッション ID を Workers 内で保持しようとすると詰むので、JWT + KV / D1 セッションストアで組むのが定石です。
- JWT 検証 —
hono/jwtミドルウェアで完結 - アクセストークンの短命化 — 5〜15 分。リフレッシュトークンは KV に
- OAuth 連携 — Workers 上で Auth.js を動かすパターンが安定
GitHub の Code Security リスク評価ガイド でも触れたように、シークレット管理は CI から wrangler secret put で自動投入し、コードに直書きしない運用を徹底します。
データベース連携 — 3 つの選択肢
Workers から DB を扱う場合、選択肢は次の 3 つに整理できます。
| 選択肢 | 強み | 弱み | 向いているケース |
|---|---|---|---|
| Cloudflare D1（SQLite） | 同一プラットフォーム、レイテンシ最小 | スキーマ進化に弱い | LP 問い合わせ、フォーム保存 |
| Hyperdrive 経由 PostgreSQL | 既存 RDS / Neon を流用 | 接続プール設計が必要 | 既存 SaaS の API 拡張 |
| PlanetScale / Turso | グローバル分散 | コスト | マルチリージョン SaaS |
既存 PostgreSQL が前提なら、PostgreSQL RLS で実装する SaaS マルチテナント設計 と Hyperdrive の組み合わせが受託で実績を積みやすい構成です。Drizzle ORM は Workers ランタイムに公式対応しているため、Drizzle ORM 移行ガイド と組み合わせる選択肢も有力です。
観測性 — 「ログだけでは足りない」
Workers のデバッグで最初につまずくのは「ログを追えない」ことです。次の 3 点セットで観測性を担保します。
- Tail Workers — リアルタイムログ転送。Datadog や Sentry に流せる
- Workers Analytics Engine — 高頻度メトリクスを SQL 風に集計
- OpenTelemetry SDK — トレース ID を上下流に伝搬し、エッジ → オリジン間を貫通
エンタープライズの本格採用では、OpenTelemetry 移行ガイド で紹介した分散トレース基盤と接続するパターンが増えています。
Workers で組まないほうが良いケース
万能ではありません。次のいずれかに当てはまるなら、別の構成を検討します。
- CPU 30 秒以上の重処理（PDF 生成・大規模画像処理）
- 常時接続が必要な WebSocket サーバー（Workers 単独より Durable Objects + 設計検討が必要）
- ファイルシステムや特殊バイナリに依存するライブラリ（headless Chromium、ネイティブ拡張等）
- オフライン環境を含む厳格な金融・医療系ワークロード
これらは Cloud Run や AWS App Runner のようなコンテナ実行基盤を併用するのが現実解です。AWS App Runner 移行ガイド も合わせて参照ください。
まとめ — 「軽い API はエッジで、重い処理はコンテナで」
2026 年の受託 API 基盤は、エッジとコンテナの使い分けが前提になります。Hono + Workers は「軽量 API・低コスト・グローバル配信」が必要な領域で、もはや第一候補と言って差し支えありません。
GleamHub では、Express からの段階移行、認証・DB 連携の設計、観測性の整備までを伴走支援しています。「コーポレートサイトの API を刷新したい」「SaaS のレイテンシを下げたい」といったご相談は、ぜひ お問い合わせ からどうぞ。
