ケーススタディ：中小企業向け業務統合SaaS
架空化した題材で「要件からアーキテクチャを選ぶ」演習をします。パターン集の応用編です。
題材となるサービス像（予想）
あるスタートアップが、現場の業務課題を起点に中小企業（数名〜50名規模）向けの業務統合SaaSを構想しているとします。次のような特徴を仮定します。
- 機能：CRM（顧客管理）、案件・進捗管理、勤怠、人事評価を1つに統合。加えて、それら全データを横断して働くAIエージェント層（入力代行、要約、次アクション提案）を差別化要素とする
- 技術スタック（公表ベース）：Cloudflare Workers、外部LLM API（Claude API）、Vercel
- 体制：当面は1〜2名の少人数開発。数か月以内のリリースを目指す
- 商売の性質：1社あたりの単価は低〜中。多数の会社に薄く広く提供するため、テナントあたりの限界コストを極小化したい
要件をデータ特性に分解する
設計の第一歩は、機能を「どんなデータをどう扱うか」に翻訳することです。
| 機能 | データ・処理の特性 | 適したCloudflareサービス |
|---|---|---|
| CRM・案件管理 | リレーショナル。会社ごとに完全分離が必要。読み取り中心 | D1（テナント別または共有+tenant_id） |
| 勤怠 | 打刻は書き込み集中。締め処理は月次バッチ。改ざん防止が必要 | D1+Queues+Cron Triggers |
| 人事評価 | 機微情報。厳格な権限制御と監査ログが必須 | D1+アプリ側RBAC+監査ログテーブル |
| 添付ファイル・帳票 | PDF・画像。配信量が読みにくい | R2（エグレス無料が効く） |
| AIエージェント層 | 会話状態の保持。長時間タスク。LLM費用の管理 | Agents SDK+Workflows+AI Gateway |
| 通知・外部連携 | 失敗リトライが必要な非同期処理 | Queues（+デッドレターキュー） |
| セッション・設定 | 読み取りが非常に多い小さなデータ | KV |
アーキテクチャ3案
Cloudflareオールイン
フロントも含めてCloudflareに集約し、運用面・コスト面を極限まで軽くする案
特徴：パターン2+パターン3+パターン6の合成です。プラットフォームが1つに集約されるため、デプロイ・監視・請求・権限管理がすべて1画面に収まります。テナント別D1で「他社データ混入が構造的に起きない」構成にできる点はB2B営業上の強みになります。
- 向く状況：開発者が1人でフロントの技術選定も自由に決められる。運用にかけられる時間が最少
- リスク：React系フレームワークのSSRをWorkersで動かすノウハウはVercelほど枯れていない。フロントをSPA+静的アセットに割り切れるかが分かれ目
費用感：固定費はWorkers Paid $5/月（約750円）のみ+従量。テナント増でも固定費が増えない。
Vercelフロント+Workersバックエンド（公表スタック忠実案）
公表されている技術スタック（Workers+Claude API+Vercel）をそのまま素直に構成した案
特徴：パターン7のフロント部分をVercelに置きつつ、データ基盤はD1系に寄せた構成です。Next.jsのエコシステム（画面開発の速度、プレビューデプロイ）を最大限使いながら、業務データとAI層はCloudflareで完結させます。既にこのスタックでベースが構築されている場合、これに近い形になっている可能性が高いと予想できます。
- 向く状況：画面開発の速度を最優先したい。Next.jsの経験者がジョインする可能性が高い
- リスク：2プラットフォーム分の設定・監視・請求管理。VercelとWorkersの間の認証設計（CORSとセッションの持ち方）を最初に固める必要がある
費用感：Workers $5/月+Vercel（無料枠〜Pro $20/月）。案Aよりやや高いが依然として軽量。
外部Postgres+Hyperdrive（RDB中心案）
将来のデータ規模・分析要件を先に見込み、最初からリレーショナルDBを外部に置く案
特徴：パターン7のデータ基盤重視版です。勤怠の締め集計や人事評価の複雑な集計、将来のBI・分析要件を見込むなら、最初からPostgres（行レベルセキュリティでテナント分離）を選ぶ判断もあります。Hyperdriveがあるため「エッジから遠いDB」の遅さは大部分を吸収できます。
- 向く状況：複雑なSQL・集計・外部BIツール接続が初期から見えている。RDB運用経験者がいる
- リスク：DBの固定費と運用（バージョンアップ、バックアップ検証）が増える。少人数期には過剰投資になりがち
費用感：Workers $5/月+マネージドPostgres（無料枠〜数千円/月）。3案の中では最も高いが、それでも従来型構成よりは軽い。
3案の比較と推奨
| 観点 | 案A：オールイン | 案B：Vercel併用 | 案C：外部RDB |
|---|---|---|---|
| 初期の開発速度 | 高い | 最も高い（画面開発） | 中 |
| 運用負荷（少人数） | 最小 | 小〜中（2基盤） | 中（DB運用あり） |
| 月額固定費の目安 | 約750円〜 | 約750〜3,750円 | 約750円+DB費用 |
| テナント分離の堅さ | DB物理分離が容易 | 同左 | RLS設計に依存 |
| 複雑な集計・分析 | 弱い（SQLite） | 弱い（SQLite） | 強い |
| AIエージェントとの親和性 | 高い（Agents SDK直結） | 高い | 中 |
推奨の考え方：少人数・短期リリース・低単価×多テナントという前提なら、基本は案B（公表スタックに忠実）で立ち上げ、AIエージェント層は案Aの要素（Agents SDK+AI Gateway）で作り込み、データ規模や分析要件が見えた段階で案Cへの移行パス（Hyperdrive）を確保しておくのが現実的です。重要なのは特定の案を正解として暗記することではなく、「体制・単価構造・データ特性から逆算して選び、移行パスを残す」という判断軸を示せることです。
面接で語れる設計論点
- テナント分離：共有DB+tenant_id列か、テナント別D1か。人事・勤怠という機微データを扱う以上、物理分離の説明しやすさは営業上も価値がある（パターン3）
- 権限モデル：「経営者・管理者・一般社員」のRBACに加え、人事評価は同じ管理者でも閲覧範囲が異なる。認可ロジックをどの層に集約するか
- 監査ログ：誰がいつ何を見たか・変えたかをQueues経由で非同期記録し、本体処理を遅くしない
- 勤怠の締め処理：月次バッチはCron Triggers+Workflowsで「途中失敗からの再開」を保証する（パターン8）
- AIエージェントのガードレール：エージェントに渡すツールは最小権限にし、書き込み系操作は人の承認を挟む。LLM費用はAI Gatewayで上限・可視化
- 1人開発の運用設計：observability有効化、デプロイのロールバック手順、Sentryなどの外部監視。1人だからこそ「見なくても回る」仕組みに投資する
想定問答
なぜAWSではなくCloudflareを選ぶのですか
この事業の前提（少人数開発・低単価×多テナント・売上ゼロ期間の固定費最小化）に対して、固定費が月額約750円から始まり、サーバー管理・スケール設定・VPC設計が不要という運用特性が合致するためです。AWSが劣るのではなく、専任インフラ担当を置けない体制ではCloudflareのマネージド度の高さがそのまま開発速度になります。一方で複雑な分析基盤や特殊なミドルウェアが必要になった場合は、その部分だけ外部サービスやAWSを併用します。
D1（SQLite）で業務SaaSのデータを持って本当に大丈夫ですか
1データベース10GBという制限がありますが、テナント別DB設計にすれば1社あたり10GBであり、中小企業の業務データでは実質的に問題になりにくいです。リードレプリカは追加費用なしで自動配置されます。弱点は複雑な集計・分析で、そこは（1）集計専用の仕組みを別に持つ、（2）Hyperdrive経由でPostgresへ移行する、という2段階のパスをあらかじめ用意しておきます。
テナント間のデータ分離はどう保証しますか
推奨はテナント別D1です。認証後にテナント台帳（共有D1またはKV）からそのテナント専用DBを解決して接続するため、SQLの書き間違いで他社データが返る事故が構造的に起きません。人事評価・勤怠という機微データを扱う以上、「アプリの規律で守る」より「構造で守る」方が顧客への説明も監査対応も強くなります。
AIエージェント層はどう実装しますか
Agents SDK（Durable Objectsベース）でユーザーごとにエージェントインスタンスを持たせ、会話状態は内蔵SQLiteに保持します。LLM呼び出しはすべてAI Gateway経由にして、トークン使用量・コスト・エラー率を一元管理します。長時間タスクはWorkflowsに切り出し、失敗時はステップ単位で再開します。エージェントに渡すツールは読み取り中心の最小権限とし、データを変更する操作はユーザーの確認を挟む設計にします。
勤怠・人事評価のような機微データのセキュリティはどう考えますか
層で重ねます。エッジ側でWAF+レート制限+ログインフォームへのTurnstile、アプリ側でRBACによる認可と監査ログ、データ側でテナント別DBによる物理分離です。管理・運用系の画面はZero Trust Accessを前段に置き、SSO+MFAを通過しない限り到達できないようにします。また、AIエージェントが人事評価データへ無制限にアクセスしない設計（ツール単位の権限制御）を明確に説明できることが重要です。
Vercelとの併用は複雑になりませんか
コストは2基盤分の設定・監視・請求管理と、フロント〜API間の認証設計（セッションの持ち方とCORS）です。得るものは画面開発速度とプレビュー環境です。立ち上げ期は画面の試行錯誤が最も多いのでVercelの価値が高く、プロダクトが安定したらフロントをWorkers静的アセットへ寄せて1基盤に統合する選択肢も残ります。最初に「どちらに何を置くか」の境界線を決めておけば複雑さは管理可能です。
ベンダーロックインのリスクはどう考えますか
データ層は逃げ道が確保しやすいです。R2はS3互換API、D1はSQLite形式でエクスポート可能、QueuesやKVのインターフェースも薄く抽象化できます。最もロックインが強いのはDurable Objects/Agents SDK特有の状態管理ですが、これは他基盤なら自前で作り込む部分をプラットフォームが肩代わりしている対価です。事業初期は「速く安く出せる価値」がロックインリスクを上回る、と整理して説明します。
ユーザーが増えたときのスケール戦略は
コンピュートは自動スケールするため、ボトルネックはデータ設計に集中します。（1）読み取り負荷はD1リードレプリカとKVキャッシュで吸収、（2）書き込みスパイク（朝の一斉打刻など）はQueuesで平準化、（3）1テナントの容量・クエリ複雑度が限界に近づいたらHyperdrive経由の外部Postgresへ段階移行、という順で対応します。移行パスを最初から設計に織り込んでおくことが肝です。