Cloudflare Workersで業務アプリを作る前に：低コストだけで選ばない技術スタック設計

安い実行環境は、選定基準を軽くしてよい理由にはならない

AIコーディングで業務アプリを作る時間は短くなりました。問い合わせ管理、簡易CRM、社内検索、申込フォーム、レポート生成などは、以前より小さく試しやすくなっています。

その一方で、作りやすくなるほど迷いやすいのが技術スタックです。

Next.js、Astro、Hono、Rails、Laravel、Cloudflare Workers、Vercel、Supabase。候補を並べ始めると、どれも魅力的に見えます。特にCloudflare Workersのようなサーバーレス実行環境は、低コストで小さく始めたい会社にとって有力な選択肢です。

ただし、業務アプリは「安く動く」だけでは足りません。誰が操作したかを追えるか。権限を分けられるか。SSRが必要か。DBやログの制限を理解しているか。AIで作った差分をどう確認するか。

低コストな基盤ほど、先に見るべき論点を増やしておく必要があります。

Cloudflare Workersで見える魅力

Cloudflare Workersは、Cloudflare公式ドキュメントで、Cloudflareのグローバルネットワーク上でアプリを構築、デプロイ、スケールできるサーバーレス基盤として説明されています。JavaScriptやTypeScriptなどの言語、React、Vue、Svelte、Next、Astroなどのフレームワークにも触れられています。

2026年6月5日時点の公式情報では、WorkersにはFree/Paidの料金体系、リクエスト、CPU時間、メモリ、subrequest、Workers Logsなどの制限や料金項目が整理されています。つまり、単に「無料枠がある」ではなく、どの処理がどの制限に当たるのかを見ながら設計するサービスです。

業務アプリで魅力になるのは、主に次の点です。

小さなAPIやフォーム処理を低コストで始めやすい
静的アセット、API、DB、KV、R2などを同じCloudflare周辺で組み合わせやすい
Wranglerやフレームワークガイドが整備されており、試作を始めやすい
Honoのような軽量フレームワークと組み合わせやすい
アクセスが少ない初期アプリでも、固定費を抑えやすい

特に、AIで小さな社内ツールを複数作る場合、アプリごとの固定費は無視できません。使われるか分からない試作品に、最初から大きなサーバーや重いDBを用意すると、検証前に維持費が膨らみます。

Cloudflare Workersは、その「まず小さく作る」段階の候補になります。

料金の前に見る5つの設計論点

安さに惹かれて実行環境を決める前に、少なくとも5つの論点を見ます。

1. 監査ログをどこまで取るか

業務アプリでは、画面が動くことより「誰が、いつ、何をしたか」が後から追えることが重要になる場面があります。

問い合わせを削除した。顧客情報を更新した。見積金額を変えた。メールを送った。こうした操作は、アプリの便利さとは別に、説明責任の問題になります。

Workers Logsやプラットフォーム側のログで足りるのか、アプリ側で監査ログテーブルを持つべきか、外部のログ基盤へ送るべきか。ここを先に決めます。

2. SSRが本当に必要か

SSRは、初期表示、SEO、認証後の画面構成に関わります。一方で、SSRを入れるとアプリの実行環境、キャッシュ、エラー調査、CPU時間の見方が複雑になります。

会社紹介、ブログ、資料ページが中心なら、Astroのように静的生成や必要部分だけのインタラクションを得意とする選択肢が合うことがあります。CloudflareのAstroガイドでも、Astroは多くのコンテンツをビルド時またはサーバー側でレンダリングし、必要な部分だけJavaScriptを追加する思想として説明されています。

一方で、管理画面、複雑な検索、認証後の操作が中心なら、API、DB、権限、画面状態をどう分けるかが主題になります。SSRの有無だけでなく、業務操作の流れから選びます。

3. バックエンドを「普通に」書けるか

業務アプリでは、ルーティング、認証、バリデーション、DB操作、エラー処理、監査ログを読みやすく保つ必要があります。

Honoは公式ドキュメントでCloudflare Workers向けのセットアップが示されており、TypeScriptで書き、Wranglerでローカル実行やデプロイを進められます。こうした軽量バックエンドは、Workers上で小さなAPIを作る時に候補になります。

ただし、候補名だけで選ぶと危険です。フロントエンドとの連携、認証、DBマイグレーション、テスト、型定義、チームの習熟度まで含めて見ます。

4. DBとストレージの将来移行を考えるか

Workers周辺にはD1、KV、R2、Durable Objectsなどの選択肢があります。どれも便利ですが、用途が違います。

読み取り中心の設定データなのか、顧客ごとに分けたい業務データなのか、ファイル保存なのか、リアルタイム性のある状態管理なのか。ここを曖昧にしたまま「安いからCloudflareでまとめる」と決めると、後で移行が難しくなります。

最初の設計では、DBを変える可能性を残します。SQL方言、ORM、マイグレーション、エクスポート、バックアップ、テナント分離を、試作段階から軽く見ておきます。

5. チーム運用が実装速度に追いつくか

AIコーディングで実装が速くなると、レビューやリリースが詰まりやすくなります。小さなチームでも、差分が増えるほど人間の確認時間が足りなくなります。

ここで必要なのは、すべての差分を重く見ることではありません。

セルフレビューでよい変更
人間が必ず見る変更
自動テストで止める変更
本番には出すが、管理者だけに見せる変更
一般公開前に機能フラグで段階公開する変更

この分類を決めておくと、AIで速く作っても、リリース判断が崩れにくくなります。

小さな会社なら、候補を3分類に分ける

技術スタック選定で迷ったら、候補名の比較表を作る前に、アプリの性質を3つに分けます。

コンテンツ中心

会社サイト、ブログ、資料ページ、採用ページ、LPなどです。更新頻度、表示速度、SEO、編集しやすさが大事です。

この場合は、静的生成や部分的なインタラクションを得意とする構成が合いやすくなります。Optiensの公式サイトも、Astroを使ってブログやページを管理しています。

API中心

フォーム送信、Webhook、AIレポート生成、軽い社内処理、外部サービス連携などです。画面よりも、入力、処理、ログ、失敗時の扱いが大事です。

この場合は、Cloudflare WorkersとHonoのような軽量API構成、またはVercel Functions、Supabase Edge Functionsなどを比較します。見るべきなのは「どれが流行っているか」ではなく、ログ、権限、DB接続、リトライ、運用者の分かりやすさです。

管理画面中心

顧客管理、見積、承認、請求、在庫、問い合わせ対応などです。画面状態、権限、履歴、検索、CSV、通知が絡みます。

この場合は、フロントエンド体験だけで決めない方が安全です。監査ログ、DB設計、権限、リリース管理、運用手順が重くなるため、Supabase/Postgres系や既存SaaS連携の方が合う場合もあります。

Optiensの見方

Optiensでは、AI支援や小規模業務アプリの提案時に、技術スタックを「作りやすさ」だけで決めません。

まず、業務の目的を見ます。次に、利用者、データ、権限、ログ、公開範囲、将来の変更頻度を見ます。そのうえで、Cloudflare Workers、Vercel、Supabase、Astro、Next.jsなどの候補を比較します。

低コストな構成は大切です。しかし、安さは判断軸のひとつであって、唯一の判断軸ではありません。

小さく作るなら、壊れた時に戻せること。AIで速く作るなら、公開前に止まる場所があること。新しい技術を試すなら、半年後も担当者が読めること。

この3つがそろっていると、技術選定は趣味ではなく、事業の道具になります。

具体的な業務自動化の構築まで進めたい場合は、まず詳細版AI活用診断（¥5,500税込・MTGなし）で、導入可否、優先順位、構成案、費用前提を整理します。実装・API連携・初期動作確認は、導入支援として個別にお見積もりします。

まとめ

Cloudflare Workersは、小さな業務アプリやAI時代の試作にとって有力な選択肢です。公式ドキュメント上でも、フレームワーク、言語、ログ、料金、制限が整理されており、検討しやすい環境になっています。

ただし、業務アプリでは料金だけでは決めません。監査ログ、SSR、バックエンドの書きやすさ、DB移行、チーム運用を見ます。

新しい技術スタックを探すことは楽しい作業です。けれど、会社で使うなら最後は「何を作るのか」「誰が運用するのか」「どこで止めるのか」に戻る必要があります。