個人開発の最小事業システム：サイト・商品・決済・データ・自動化の公開チェックリスト

launch-checklist.md を開くと、/pricing はあるのに Stripe Product がありません。ログインはできてもサブスクリプション状態が同期されず、GA4 には page_view だけが届き、決済ボタンのクリックイベントはありません。フィードバックはメールで届いても、タスクには流れません。

個人開発では「動く」ことを公開条件にしがちです。有料ユーザーへの案内が手作業のままだったり、無料枠を超えてから初めて利用量を確認したりすると、その隙間が表面化します。

最小事業システムの価値は、ツール数が少ないことではなく、事業上の操作が最後まで完了することにあります。ユーザーが訪れ、商品を受け取り、支払い、権限を得て、データとフィードバックを残し、失敗時には対応を受けられる状態です。

最初のチェック表で途切れた受け渡しを探し、最低限実装する層と後回しにする層を決めます。

最小システム検収表：公開前に閉じるべきインターフェース

検収基準は「機能が全部ある」ではありません。各業務操作が開始から結果まで通ることです。公開前夜に Stripe webhook、Supabase RLS、GA4 イベントを追加することになるのは、早い段階で「画面が表示される」までしか確認していないためです。

公開前に確認したいインターフェースは次のとおりです。

検収領域	閉じるべきインターフェース	よくある抜け	検収操作
サイト入口	ページが開く、404 がない、静的資産が読み込まれる、ビルド回数を監視する	Cloudflare Free のビルド枠を超える、エラーログを誰も見ない	実機でトップと料金ページを開き、Cloudflare Pages のビルド履歴を確認する
プロダクト形態	コンテンツ/ツール/SaaS の形が明確で、料金ページに価格がある	説明だけで価格や購入経路がない、Stripe Product がない	Stripe Dashboard の Products/Prices を確認し、/pricing の表示を確認する
決済フロー	Checkout Session、webhook、権限付与、失敗/キャンセル処理、状態同期が動く	webhook がない、支払っても権限が付かない、返金状態が同期しない	Stripe のテスト決済を完了し、webhook ログとサブスクリプションテーブルを確認する
ユーザーシステム	ログイン、RLS、サブスクリプション同期、無料/有料の権限差が動く	ログインボタンだけで RLS がない、全員が有料内容を読める	ログイン後に subscriptions を確認し、無料アカウントで RLS を検証する
データイベント	GA4/GSC、5〜8 個の業務イベント、決済/登録/試用、エラー通知が動く	GA4 に page_view しかなく、決済クリックや登録完了がない	GA4 DebugView で収集を確認し、GSC Performance report でクエリとページを見る
フィードバック循環	送信でき、タスクに入り、サポートに対応状態がある	メールだけ届き、タスクボードや追跡状態がない	フィードバックを一件送り、ボードまたはメールキューへの到達を確認する
自動化境界	Webhook/API/Cron に使用量の警戒線、通知、ロールバックがある	失敗が通知されず、上限到達後に気づく	Workers の利用量を確認し、警戒線とエラー監視を設定する
コスト監視	Cloudflare/Supabase の使用量を記録し、無料枠とアップグレード条件を把握する	Supabase Free が停止する、Workers の上限超過に気づかない	Cloudflare 使用量と Supabase 稼働状態を確認し、移行条件を記録する

各行は、リポジトリ内の設定を見るだけでは終わりません。公開前に、決済を一度、ログインと権限確認を一度、イベント検証を一度、フィードバック送信を一度、実際に完了させます。

サイト入口：最小構成の技術スタックと境界

サイトは最初の層です。静的サイトや軽量フレームワークから始められますが、ビルド回数、ファイル数、動的関数はコスト表に入ります。Cloudflare Pages と Astro は保守負担を下げますが、無料枠は設計保証ではありません。

技術スタック選択表

プロダクト形態	推奨スタック	ビルドコスト	動的関数コスト	適した用途
コンテンツサイト	Astro / Hugo / Hexo	Cloudflare Pages Free：500 builds/month、20,000 files、25 MiB asset	Pages Functions は Workers に計上	ブログ、ドキュメント、SEO ページ、商品説明
ツールサイト	Astro + API 呼び出し	同上	API 呼び出しは Workers に計上（100,000 requests/day）	単一ページツール、検索、計算、データ可視化
SaaS	Astro + Supabase	同上	Workers + Supabase Edge Functions	複数ユーザー、サブスクリプション、権限、DB 読み書き

2026 年 7 月 26 日時点で、Cloudflare Pages 公式制限の Free プランは月 500 ビルド、20 分のビルドタイムアウト、最大 20,000 ファイル、1 資産 25 MiB です。Pages Functions のリクエストは Workers 枠を使い、Workers Freeには 1 日 100,000 リクエストと 1 回 10 ms の CPU が含まれます。

静的資産のリクエストが無料でも、システム全体が無料になるわけではありません。画像、動画、ダウンロードが多ければ、オブジェクトストレージ、CDN 処理、変換、egress も計算します。

AI 生成ページにも利用者価値が必要

Google Search の生成 AI コンテンツ指針は、調査や構成への AI 利用を認めています。一方、利用者への付加価値がないページを大量生成すると、scaled content abuse に抵触する可能性があります。入口ページには実際の商品、フィードバック、振り返りが必要で、自動生成した SEO ページの数では代替できません。

コンテンツサイトの性能は Astro 5 パフォーマンス改善も参考になります。最小システムは公開前に Lighthouse 100 を求めませんが、ページ、資産、CTA が動き、ビルド失敗を確認できる必要があります。

プロダクト層：コンテンツ、ツール、SaaS のどれを最初に作るか

プロダクト形態は、決済、ユーザー、データ、自動化の複雑さを決めます。コンテンツ、ツール、SaaS は同列の選択肢ではなく、運用責任が段階的に増える形です。最初は、最も慣れた技術、最も単純な決済、最も少ないユーザーデータを選びます。

プロダクト形態の判断表

プロダクト形態	技術の複雑さ	決済の複雑さ	ユーザーデータ	最初の版への適合
コンテンツサイト	低：静的 + CMS + SEO	低：買い切りまたは無料	低：メール購読、RSS、コメント	高：SEO 集客、コンテンツ収益、需要検証に向く
ツールサイト	中：静的 + API + 軽量バックエンド	中：買い切りまたはサブスクリプション	中：軽量ユーザー機能、使用履歴	中：中心機能と課金方式の検証に向く
SaaS	高：認証 + DB + サブスクリプション + RLS	高：継続課金、従量課金、返金	高：複数ユーザー、権限、状態、データ分離	低：支払需要が明確で技術に慣れた場合に向く

判断基準

最初の形は三つの要素で選びます。

1. 技術への習熟：Astro や Hugo に慣れていれば、コンテンツサイトで需要を早く確認できます。Supabase や Postgres に慣れていれば、ツールや SaaS の実装リスクを下げられます。
2. 決済の複雑さ：買い切りは通常サブスクリプションより単純で、サブスクリプションは従量課金より単純です。最初は買い切りまたは無料のリード獲得にし、複雑な課金は需要が出てから追加します。
3. ユーザーデータの必要量：コンテンツはメールと RSS、ツールは使用履歴、SaaS は本人識別、権限、サブスクリプション状態、データ分離が必要です。

プロダクト形態は肩書ではありません。中心機能が安定していないなら、アカウントセンター、チームスペース、テンプレート市場を先に作る理由はありません。

決済層：最後のボタンではなく、データモデルを決める入力

決済は最小システムで最もリスクの高い層です。データベース、ユーザー、権利、管理画面、通知の設計に影響します。Checkout で課金できても、webhook が権限を付けず、返金が状態に反映されず、期限切れ後もアクセスできれば履行失敗です。

決済フローの手順表

Stripe の最小決済ループは次の手順です。

手順	Stripe オブジェクト	閉じるべきインターフェース	よくある抜け
1. 商品を作る	Products	Stripe Dashboard で商品を作り、料金ページに価格を表示する	/pricing に価格があるが Stripe Product がない
2. 価格を作る	Prices	金額、通貨、期間、買い切り/継続/従量モデルを設定する	interval がない、従量課金に meter がない
3. Checkout Session を作る	Checkout Session	line_items、mode、success_url、cancel_url を設定する	success_url へ移動するだけで決済状態を確認しない
4. webhook を設定する	Webhook endpoint	checkout.session.completed、invoice.paid、customer.subscription.deleted などを受信する	webhook がなく、支払い後に権限が付かない
5. 履行する	独自ロジック	DB で権限を付け、決済後に確認通知を送る	追跡できない手作業に依存する
6. 返金を処理する	Refunds	状態更新、権限回収、返金通知を行う	返金後も有料アクセスが残る
7. 状態を同期する	Subscriptions	更新、解約、期限切れ後に状態を更新する	期限切れ後も権限が残る

料金モデル判断表

料金モデルはデータモデルを変えます。

料金モデル	データモデルへの影響	権限管理	適した用途
買い切り	ユーザーまたは購入記録に paid_at / purchase_id を追加	一度だけ、永久または期限付きで付与	デジタル商品、講座、テンプレート、単発ツール
サブスクリプション	user_id、stripe_subscription_id、status、current_period_end を持つ subscriptions を作る	期間に応じて付与・回収し、状態同期が必要	ツール、SaaS、会員コンテンツ
従量課金	user_id、meter、amount、timestamp を持つ usage を作る	使用量と残量を制御し、枠テーブルが必要	API、クラウドストレージ、計算サービス

Stripe Products/Prices では、新しい Price を作り、lookup key を新しい Price に移せます。lookup key で価格を取得すれば、複数箇所に Price ID を直書きせずに済みますが、価格変更には公式の作成・有効化手順が必要です。

履行、返金、サブスクリプション状態は webhook とデータベースで処理します。フロントの success ページや Dashboard の手作業では不十分です。より詳しい比較は 一人会社の決済システム選定に続きます。

テスト決済の検証手順

公開前に Stripe のテスト環境で一連の決済を完了します。

1. Stripe Dashboard のテスト環境を使う
2. 成功、失敗、追加認証について Stripe の最新ドキュメントにあるテスト方法を使う
3. テスト情報で Checkout を完了する
4. Payments と Events を確認し、期待するイベントが発生したか確認する
5. subscriptions または権限レコードを確認し、状態同期を確認する
6. ログインして権限付与を確認し、権限のないアカウントでも再確認する

テスト完了後は、本番用の鍵、webhook endpoint、イベント署名、通知を別に確認します。

ユーザー層：本人識別、権限、サブスクリプション状態を分ける

ユーザーシステムはログインボタンだけではありません。本人識別、権限、サブスクリプション状態、データアクセス境界を区別します。ログインできても全員が有料データを読めるなら、問題はログイン部品ではなく認可です。

Supabase Auth はパスワード、magic link、OTP、ソーシャルログイン、SSO などを扱えます。認可では JWT とデータベース RLS を組み合わせます。認証が「誰か」を答え、RLS policy が「どの行を読み書きできるか」を決めます。

最小ユーザーシステム表

ユーザー能力	Supabase の能力	閉じるべきインターフェース	よくある抜け
認証	パスワード、magic link、OTP、ソーシャルログイン、SSO	ログインし、JWT を受け取り、自分のデータへアクセスできる	ログインボタンだけで認可がない
権限管理	RLS（行レベルセキュリティ）	自分のデータだけを読み、有料ユーザーだけが有料内容を使う	RLS が無効、または policy が広すぎる
状態同期	Stripe webhook → subscriptions	支払い、更新、解約、期限切れ後に状態を更新する	Stripe 内だけに状態があり、アプリへ届かない
データ境界	RLS policy	ユーザーは自分の行だけを扱い、管理者経路は別権限にする	分離を試さず、別ユーザーのデータが見える

Supabase プロジェクトは Postgres をデータの基盤とし、Auth、Storage、Realtime、Edge Functions がその周辺で動きます。サブスクリプション状態は信頼できるバックエンドが更新し、ブラウザに有料権限を決めさせません。

公開前に少なくとも二つのアカウントで RLS を検証します。一つは権限あり、もう一つは権限なしです。service role などの高権限キーがブラウザへ出ていないことも確認します。

データ層：分析スクリプト一つではなく、5〜8 個の業務イベント

GA4 を置いただけではデータ層になりません。最初は意思決定を変える 5〜8 個のイベントで十分ですが、訪問、クリック、中心操作、登録、決済、エラー、フィードバックを含めます。

業務イベント表

業務イベント	GA4 イベント名	発火条件	振り返り用途
ページ表示	page_view	ページ読み込み	入口ページと SEO 流入分析
決済ボタン	begin_checkout または独自イベント	購入または購読をクリック	転換経路と料金ページの評価
登録完了	sign_up	ユーザー登録完了	登録転換と流入品質
試用開始	独自 trial_start	試用または無料体験開始	試用転換と体験改善
決済完了	purchase	バックエンドが成功を確認	売上と決済経路の改善
エラー	独自 error_occurred	フロントエラー、API 失敗、中心操作の例外	安定性と修正優先度
フィードバック	独自 feedback_submit	問題や意見を送信	送信率と問題分類

GA4 は重要な業務操作を key event にできます。Realtime と DebugView で収集を検証し、本番の振り返りではパラメータ、流入元、重複除去も確認します。

データ振り返り手順

少なくとも週に一度は確認します。

1. GA4：業務イベントを見る：DebugView で収集を検証し、訪問から登録、試用、決済までの経路を確認します。
2. GSC：クエリとページを見る：総訪問だけでなく、クリック、表示、CTR、平均掲載順位、クエリ、ページを確認します。
3. プロダクト分析：詳細が必要な時期を判断する：GA4 の集計で特定ユーザーの操作回数や離脱点が分からなくなったら、PostHog などでファネル、リテンション、行動を見ます。

売上前でも GSC、ログ、エラー通知は必要です。流入クエリ、料金ページの詰まり、中心操作の失敗、高頻度エラーを早く見つけられます。有料ユーザーが来てから計測しても、それ以前の失敗原因は戻せません。

自動化層：初日に行うものと、リスクを増やすもの

安全な反復を減らす自動化もあれば、失敗時の損失を拡大する自動化もあります。AI コーディングツールは開発を速めますが、決済履行、権限、セキュリティ、業務データの検収はできません。

Codex などの coding agent は、リポジトリ理解、実装、レビュー、デバッグ、テスト、移行を支援できます。これは開発協力層です。決済履行、権限境界、本番の秘密情報、使用量通知、ユーザーフィードバックには責任者が必要です。

自動化境界の判断表

自動化	初日に行う価値	増えるリスク	使用量の警戒線
デプロイ自動化	Git push 後にビルド・デプロイ	ビルド枠を超える、失敗通知がない	Pages のビルド回数とタイムアウト
通知自動化	決済イベント → 権限記録 → 確認通知	webhook に再試行がなく、通知と権限がずれる	Workers のリクエスト、CPU、再試行量
バックアップ自動化	重要データを能動的に出力し、有料プランでバックアップを有効化	Free には自動バックアップがなく、出力失敗に気づかない	DB サイズ、ストレージ、復元確認
振り返り自動化	GA4/GSC の定期出力とレポート作成	頻度が高すぎ、API 枠とデータ遅延を無視する	GA4/GSC API quota
複雑な編成	決済 → 権限 → メール → CRM を観測可能にする	一つの失敗が全体を止め、冪等性とロールバックがない	各段階の失敗、再試行、dead letter
複数システム連携	Webhook、API、Cron、メール、CRM を連携	遅延が異なり、失敗の統一ログがない	動的リクエスト、キュー、外部 API 枠

Webhook/API/Cron の警戒線

Webhook、軽量 API、Cron は Cloudflare Workers で動かせますが、現在の上限をコスト表に入れます。

• Workers Free：100,000 requests/day、10 ms CPU/invocation。
• Workers Paid：1 アカウント月 5 ドルから。Standard は 10M requests/month と 30M CPU ms/month を含み、超過分は従量課金です。

静的資産と動的 Worker は課金方法が異なります。一つの「無料リクエスト数」だけでなく、リクエスト、CPU、再試行、ログ、KV、Queues、R2 などの合計を監視します。

デプロイ通知、決済確認、フィードバック振り分け、定期要約は初期に向きます。自動返金、本番データ削除、権限変更、一斉送信、価格変更は、監査、冪等性、ロールバックを検証するまで人の承認を残します。

コスト警戒線：無料枠は設計保証ではない

無料枠は開始時の予算であり、設計保証ではありません。Cloudflare と Supabase の境界は、動的リクエスト、CPU、ストレージ、egress、ビルド、ログ、利用形態で変わります。「永久無料」や固定ユーザー数は約束できません。

コストと境界の対照表

サービス	Free 枠	有料開始点または移行先	変更リスク	監視する境界
Cloudflare Pages	500 builds/month、20,000 files、25 MiB asset、20 分のビルドタイムアウト	対応する Cloudflare アカウントプランで Pages 上限を拡張	枠とプラン境界が変わり得る	ビルド回数、ファイル数、タイムアウト
Cloudflare Workers	100,000 requests/day、10 ms CPU/invocation、静的資産リクエストは無料	Paid は $5/account/month から、10M requests と 30M CPU ms を含む	価格、CPU、リクエスト、関連製品の枠が変わり得る	リクエスト数、CPU、再試行、使用量通知
Supabase	50,000 MAU、500 MB database、1 GB storage、5 GB egress、Free project 2 個、1 週間未使用で停止する場合がある	Pro は $25/month、$10 の compute credits を含む	プロジェクト、計算、流量、セキュリティ境界が変わり得る	MAU、DB、ストレージ、egress、稼働状態

数値は 2026 年 7 月 26 日に Cloudflare Pages limits、Workers pricing、Supabase pricingで再確認しました。枠と課金方法は変わるため、公開時にも公式ページを確認します。

Supabase Free は 1 週間未使用のプロジェクトが停止する場合があり、自動バックアップも含みません。「プロジェクトが開く」だけを正常性確認にせず、稼働状態、出力、復元、アップグレード条件を確認します。

Cloudflare の境界は Cloudflare Free 制限チェックリストと Cloudflare プラン比較にも整理しています。

まとめ

個人開発の最小事業システムは、短いツール一覧ではありません。重要な業務操作に入口、結果、失敗経路があり、訪問、商品提供、決済、権限、データ、フィードバック、障害対応まで続く状態です。

最初の版に完成度は要りませんが、検収できなければなりません。launch-checklist.md をリポジトリの横に置き、実ユーザーの経路で決済、権限、イベント、フィードバック、障害対応を通します。後からフロントエンド、バックエンド、デプロイ、データベース、決済、分析を育てても、欠けた受け渡しのために全体を作り直さずに済みます。