🚀 新規事業
TERASU_配信アーキテクチャ構想
最終更新 2026年06月08日 ／ 40_新規事業/TERASU/TERASU_配信アーキテクチャ構想.md
TERASU 配信アーキテクチャ構想（量産100〜1000社）
2026-06-06 大串との議論から。顧客HP量産（ゆくゆく 100〜1000社）を見据えたホスティング選定と段階的ロードマップ。
2026-06-08 大串決定：for SaaS 移行で確定（前倒し）。
「Cloudflare Pagesがもうすぐ100プロジェクト上限」を受け、顧客HP配信を for SaaS へ前倒し移行することを決定。決め手＝Custom Hostnamesは100ホスト名まで$0（無料枠内なので100社未満の今移行してもコスト増なし）。
→ 開発依頼書化済み：TERASU_for_SaaS配信基盤_開発依頼書（別セッションで実装）。
→ 2026-06-08 追加判断：大串「今後を考えてもう切り替える」→ A案(当面Pagesしのぎ)は見送り、即 for SaaS 構築GO（別セッションで実装着手）。基盤完成まで既存顧客HPはPages配信を継続（不安なら上限引き上げ申請で保険）。
→ Vercel／レンタルサーバーは不採用で確定（静的HP量産に不向き）。
30秒で全体像
| 観点 | 一言 |
|---|---|
| 結論 | ゴール=Cloudflare for SaaS（Custom Hostnames・最大5万ドメイン・1000社で約$90/月・帯域無制限） |
| 今の布石 | テンプレHTML と 顧客データ を分離して作る（移行が「データ流し込むだけ」になる） |
| 進め方 | 今 Pages+Git連携 → 100社見えたら for SaaS へ段階移行 |
| 不採用 | Vercel（帯域従量で1000社規模は高額・静的HPに機能過剰） |
ホスティング比較（量産観点）
| 観点 | Cloudflare | Vercel |
|---|---|---|
| 帯域 | 無制限・無料 | 従量（バズ/DDoSが高額請求に） |
| DDoS防御 | 全プラン無料・世界最大級 | 基本のみ・WAFはPro以上 |
| CDN拠点 | 300〜330 | 30+ |
| 量産上限 | Pages=100プロジェクト/アカウント / for SaaS=5万ドメイン | プロジェクト無制限でないうえ帯域コストの壁 |
| 静的HP | 最適 | 機能過剰（Next.js/SSR向け） |
→ TERASUのHPは静的HTML（kurokitec再現テンプレ）なので、Cloudflareの強みが全部活き、Vercelの強み（SSR/DX）は活きない。
段階的ロードマップ
| フェーズ | 顧客数 | 構成 | コスト |
|---|---|---|---|
| 立ち上げ | 〜数十社 | Pages + Git連携（顧客ごと1プロジェクト） | 無料 |
| 成長期 | 〜100社 | Pages上限が見えたら for SaaS 設計着手 | 無料 |
| 量産期 | 100〜1000社 | Cloudflare for SaaS（Workers+R2+Custom Hostnames） | ~$90/月（100社超分のみ$0.10/月/社） |
| 大規模 | 〜5万社 | 同 for SaaS（上限5万） | 従量 |
今すぐ1000社基盤を作るのは過剰投資。まず Pages+Git連携で始め、100社が見えた時点で for SaaS 基盤を依頼書化して本格構築する。
今打つべき布石（最重要・最初から守る）
テンプレHTML と 顧客データ（テキスト・画像）を分離して作る。
- TERASUのAI量産は元々「テンプレHTML × 顧客データ」が構造なので自然
- これさえ守れば for SaaS（マルチテナント配信）への移行は データを流し込むだけ
- NG: 顧客ごとに完成HTMLをべた書き → 100社時点の移行が地獄になる
量産期の構成イメージ（1000社対応・for SaaS）
| 要素 | 役割 |
|---|---|
| Cloudflare Workers | アクセスされたドメイン → 顧客ID解決 → コンテンツ配信 |
| R2 | 画像・アセットのストレージ |
| KV / D1 | 各顧客サイトのHTML/データ |
| Custom Hostnames API | 顧客の独自ドメインを自動登録（最大5万） |
→ 各顧客は独自ドメインで自分のサイトを持ち、TERASUは 1つの基盤で全社分を配信。
事故防止（本番巻き戻り対策）
2026-06-04・06-06 に自社TERASU公式HPで「古い版で本番上書き」事故が2回発生した教訓。
- Git連携deployを唯一の本番経路にする（直接アップロード=
wrangler/vercel --prod直叩きを封じる）→ 古い版で巻き戻せなくなる - 自社TERASU公式HP（Cloudflare Pages直接アップロード）は monitor自動復旧 で保険済（2026-06-06実装・ver番号チェックで10分以内に自動復旧）
- 顧客量産フローは最初から Git連携 + 権限一元化 で設計し、同じ事故を構造的に防ぐ
次アクション
- 今: Pages + Git連携で開始。「データ/テンプレ分離」を制作フローに徹底
- 100社が見えたら: for SaaS基盤（Workers+R2+Custom Hostnames）を開発依頼書化して別途構築
関連
- _SCALE_TERASU_HP_バージョン管理表（自社公式HP・monitor自動復旧・ver15巻き戻り事故）
- 事業詳細 / 競合優位性
- memory:
project_vercel_pro_adoption.md（要更新: 量産はCloudflare for SaaS が結論。Vercelは静的HP量産に不向きと判明）