| name | saas-pricing-design |
| description | SaaS の料金プランをコスト構造から逆算して設計し、パラメータ調整可能な Excel (Numbers 互換・実機検証込み) と収支サマリを作るワークフロー。「料金プランを設計したい」「SaaS の料金体系を決めたい」「利用料金をいくらにすべきか」「インフラコストから値付けしたい」「収支シミュレーションを Excel にまとめたい」「赤字にならない料金にしたい」などで起動。 |
saas-pricing-design
システムを SaaS として提供する際の料金プランを、コスト構造から逆算して設計する。成果物は「営業担当（非エンジニア）に渡せるパラメータ調整可能な Excel」と「収支サマリ + 意思決定ポイント」。
設計思想
- コスト構造に収入構造を写像する: 固定費は基本料で、変動費は従量で回収する。これで規模がどう動いても構造的に赤字にならない
- 最小構成で検算する: 最大構成の利益ではなく、最小契約構成 (テナント 1 社) の黒字が設計の下限を決める
- 数値はすべてパラメータ化: 単価・人数・為替をハードコードせず、Excel の入力セルで営業自身が試算できる形にする
- 修正のたびに実機検証: Excel の数式は Numbers 実機で計算値を読み取って照合する (互換性問題は静かに全セル 0 になる)
前提条件
| 依存 | 用途 | 必須か |
|---|
| macOS + Numbers.app | Excel 数式の実機検証 (verify_numbers.sh) | 必須 (検証ステップ) |
| python3 + openpyxl | Excel 生成テンプレートの実行 | 必須 |
| uv | 補助の数式エンジン検証 (uv run --with formulas) | 任意 |
| WebSearch / WebFetch | 他インフラ検討時・価格再裏取り時 | 条件付き |
ワークフロー (7 ステップ)
参照ドキュメント
バンドル済みアセット
Step 1: ヒアリング
AskUserQuestion で抽象 → 具体の順に確認する。最初から細部を聞かない。
- ゴールと構造: 誰が払うか (テナント構造。例: ホテル + 派遣会社)。単一テナントか、テナントが増えていくか
- 規模と季節性: 現在のアクティブユーザー数 (平均/繁忙期、テナントあたり)、繁忙月数、将来の成長見込み
- 下限と制約: 最小契約構成 (テナント 1 社があり得るか)、データの法定保存年数 (勤怠なら労基法 3〜5 年)、月次運用工数とエンジニア単価
- インフラ: Cloudflare (Workers + D1 + R2) ベースで良いかを必ず確認。他インフラ・他認証サービスを検討したい場合のみ Step 2 で Web 裏取りを行う
ユーザーの回答があいまいな数値 (「だいたい 300 人」) は、保守側 (収入は少なく、コストは多く) に倒して仮置きし、仮置きした値を出力に明示する。
Step 2: コスト構造の把握
- Cloudflare + Cognito 構成: infra-cost-model.md の既定値を使う。ただし記載の確認日から時間が経っている場合は公式ページで再裏取りする
- 他インフラ・他 SaaS を検討する場合: 同ドキュメントの「Web 裏取り手順」に従い、候補ごとにサブエージェントを並列起動して公式 pricing ページから「無料枠・課金単位・ハード上限」の 3 点を確認する
- コストは「固定費 (人件費 + 基本料)」と「変動費 (ユーザー数・データ量比例)」に分類して表にする。MAU ティア段差型の課金 (Auth0 型) は、テナント増で跳ねる時点を必ず試算する
Step 3: 使用量モデル
1 ユーザあたりの月間使用量を仮置きする (既定値は infra-cost-model.md 参照):
- API リクエスト / DB 書込行 / DB 読取行 / データ蓄積 MB
- 蓄積は「人月」ベースで計算する: 年間人月 = 平均アクティブ × 通常月数 + 繁忙アクティブ × 繁忙月数。平均 MAU だけで計算すると繁忙期の蓄積を取りこぼす
- ハード上限チェック: D1 は 1 DB = 10GB。保存年数 × テナントあたり蓄積から「1 DB に収容できるテナント数」を余裕率 (既定 80%) 込みで算出し、超過時の方針 (テナント別 DB 分割 / R2 アーカイブ / Postgres 移行) を決める
Step 4: 料金体系設計
pricing-principles.md の原則に従う。出力は必ず:
- 料金表 (課金先 × 月額 × 含まれるもの)
- 最小構成の検算 (従量ゼロでも 収入 ≥ 固定費 か)
- テナント +1 の限界コスト (ほぼ全額利益になる構造か)
Step 5: Excel 生成
assets/generate_pricing_template.py を案件リポジトリの scripts/ にコピー# TODO マーカー箇所 (テナントの呼称・料金既定値・使用量モデル) を案件に合わせて調整- excel-recipe.md の Numbers 互換ルールを厳守 (シート間参照はクォートなし・相対参照、「=」始まりの備考禁止、fullCalcOnLoad)
- 実行して xlsx を生成
Step 6: 検証 (数式を修正したら毎回必ず実行)
bash ~/.claude/skills/saas-pricing-design/assets/verify_numbers.sh \
docs/料金プラン.xlsx \
"料金プラン:B50" "料金プラン:B54" "料金プラン:B55" "インフラ詳細:B22"
- Numbers 実機読み取り: 上記スクリプトで主要セル (収入合計・コスト合計・利益・年間利益・ストレージ原価) の計算値を取得
- 期待値照合: 同じロジックを Python で並行計算し、全セル一致を確認
- 0 や ERROR が出たら excel-recipe.md の「トラブルシューティング」を参照 (ほぼ Numbers 互換ルール違反)
Step 7: サマリ提示
ユーザーへの最終報告に含めるもの:
- 月次収支 (平均月 / 繁忙月) と年間収支の表
- 損益分岐: 固定収入と固定費の比較、最小構成の損益
- 感度分析: Excel 内の早見表 (ユーザー数別・テナント数別) の要点
- 意思決定ポイント: ユーザーが決めるべき残論点 (契約ミニマム条項の要否、保存年数、係数の実測更新など) を番号付きで提示
よくある落とし穴
- Excel が Numbers で全セル 0 円になる → シート間参照のクォート/絶対参照、または「=」始まりテキストが原因。excel-recipe.md 参照
- 繁忙期の蓄積を平均 MAU で計算して過小評価 → 人月ベースで計算する
- 登録ユーザー数で課金設計してしまう → 課金単位は「当月 1 回以上利用した人」など機械計測可能な定義にする (休眠アカウント課金は顧客と揉める)
- MAU ティア型 SaaS の段差を見落とす → テナント数を 2 倍・5 倍にしたときの認証コストを必ず試算する
- インフラ価格を記憶で書く → 既定モデルの確認日が古ければ必ず公式ページで再確認する
