Monetization

マネタイズ・価格設定

目的

プロダクトの収益モデル選択から価格設定・課金実装・効果測定まで一気通貫で設計する。 MVPの段階からマネタイズを組み込み、「課金意思の検証」をプロダクト検証の中核に据える。

使うタイミング

• 新規プロダクトのビジネスモデルを決めるとき
• freemiumの無料・有料の線引きを設計するとき
• 価格改定・値上げを実施するとき
• 決済実装(Stripe等)の設計・レビューをするとき
• 転換率・解約率・LTVなどの収益指標を整理するとき

収益モデルの選択肢

モデル	向いているケース	向かないケース
サブスクリプション	継続的に価値を提供するSaaS・ツール	一度使えば完結するもの
買い切り	デスクトップツール・テーマ・テンプレート	継続サポートが重いもの
freemium	ネットワーク効果がある・限界費用が低い	サポートコストが高い・機能数が少ない
従量課金	API・インフラ・AI処理など使量が変動するもの	予算予測が難しいユーザーには不安感あり
広告	月数十万PV以上のメディア・ツール	個人規模(月数百円が現実)
アフィリエイト	コンテンツ・比較サイト	プロダクト型には馴染みにくい
スポンサー	OSSライブラリ・ニュースレター・ポッドキャスト	ユーザー規模が小さいうちは困難
OSS+有料サポート/クラウド版	企業ユーザーがいるOSS	個人ユーザーだけでは成立しにくい

進め方

1. 課金意思の検証を最初に置く

   • LP段階でプランページを作り「購入する」ボタンのクリック率を測る
   • MVPの目的を「機能の検証」より「支払い意思の確認」に設定する

2. 収益モデルを1つに絞る

   • 上記の表を参照し、プロダクト特性と一致するモデルを選ぶ
   • 最初から複数モデルを組み合わせない(管理コストが跳ね上がる)

3. 価値メトリクスを決める(freemiumの場合)

   • 無料版で価値が伝わり、有料版で「もっと使いたい」が生まれるメトリクスを選ぶ
   • 例: シート数・月次実行回数・容量・エクスポート機能・チーム人数
   • 無料版だけで満足完結しないラインを意識する

4. 価格を設定する(価値ベース)

   • ユーザーが得る価値の10〜20%を目安に算出する
   • コストプラス(原価+利益)では安くなりすぎる
   • 競合価格をアンカーにしつつ、自プロダクトの差別化ポイントを価格に反映する
   • 松竹梅の3プランを用意する(梅=freemium or 入門、竹=メイン、松=チーム/エンタープライズ)
   • 年額プランは月額×10ヶ月相当(2ヶ月分無料)が定番

5. 「安すぎ」の罠を回避する

   • 安い価格帯はサポートコストに見合わない客層を集める
   • 値上げは既存ユーザーを価格据え置き(grandfathering)で実施すると反発が小さい
   • 段階的値上げ: 新規ユーザーから適用→3〜6ヶ月後に既存も移行案内

6. 決済実装を設計する

   • Web課金: Stripe Billing(サブスク)、Stripe Checkout(買い切り)
   • アプリストア課金: iOS/Android経由は手数料15〜30%を考慮する
   • Web課金とアプリ内課金を使い分ける場合はストアガイドラインを事前確認
   • 特商法・前払式支払手段の対応は [[legal-compliance]] を参照

7. 基本指標を設定する

   • 無料→有料転換率: 2〜5%が相場
   • 月次解約率(チャーン): 月2%以下を目標
   • LTV = 単価 ÷ 月次解約率
   • LTV > CAC × 3 を健全ラインの目安にする

成果物テンプレート

# マネタイズ設計シート

## 収益モデル
- 選択モデル: (サブスクリプション / 買い切り / freemium / 従量課金 / ...)
- 選択理由: 

## プラン表

| プラン | 月額 | 年額 | 主な機能・制限 |
|---|---|---|---|
| 梅(無料/入門) | ¥0 / ¥xxx | - / ¥xxx | - |
| 竹(スタンダード) | ¥xxx | ¥xxx | - |
| 松(チーム/プロ) | ¥xxx | ¥xxx | - |

## 無料・有料の線引きと根拠
- 価値メトリクス: (例: 月100回まで無料)
- 無料版の目的: (価値を体験させる / ネットワーク効果 / ...)
- 有料化トリガー: (例: 100回を超えるユーザーは本格利用者)

## 収益シミュレーション(月次)

| 指標 | 数値 |
|---|---|
| 月間訪問者数 | xxx |
| 無料登録率 | xx% |
| 無料→有料転換率 | xx%(目標2〜5%) |
| 有料ユーザー数 | xxx |
| 平均月額単価 | ¥xxx |
| 月次売上(試算) | ¥xxx |
| 月次解約率 | xx% |
| LTV | ¥xxx |

## 値上げ・改定方針
- 既存ユーザー: grandfathering(価格据え置き)で対応
- 告知期間: xx日前にメール通知
- 次回見直しタイミング: (例: ユーザー数xxx人到達時 / 半年後)

チェックリスト

• 課金意思の検証をMVPに組み込んだか
• 収益モデルを1つに絞ったか
• 価値ベースで価格を設定したか(コストプラスになっていないか)
• 3プラン構成(松竹梅)を用意したか
• 年額割引を設定したか
• 無料版の「満足完結」を防ぐ線引きができているか
• 訪問者数×登録率×転換率×単価で月次収益を試算したか
• LTV > CAC × 3 を確認したか
• 特商法表記・返金ポリシーを整備したか([[legal-compliance]]参照)
• 値上げ時のgrandfathering方針を決めたか

アンチパターン

• 「ユーザーが増えてから考える」: 後から課金を追加すると既存ユーザーの反発が大きい。MVPから設計する
• 広告収益だけを当てにする: 個人規模では月数百円が現実。広告をメイン収益にするには月数十万PVが必要
• 競合より安くするだけの価格設定: 差別化ではなくコスト競争になる。価値で価格を決める
• 一度決めた価格を永遠に上げない: プロダクトが成長しても初期価格のまま放置すると機会損失。grandfatheringを活用して定期的に見直す
• freemiumで無料版を充実させすぎる: 無料版だけで満足されると有料転換が起きない
• 複数の収益モデルを同時に導入する: 管理・計測が複雑になり、ユーザーにとっても分かりにくい

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

役割	担当タスク
司令塔(メインモデル)	収益モデルの最終選択・価格の意思決定・設計シートのとりまとめ
Opus相当	収益シミュレーションの設計・価格戦略の批判的レビュー・長期LTV分析
Sonnet相当	競合価格調査・シミュレーション計算・Stripe実装設計・転換率分析
Haiku相当	競合サービスの価格情報収集・プラン表のフォーマット整形

関連スキル

• [[mvp-development]] — MVPにマネタイズ検証を組み込む
• [[market-research]] — 競合価格・市場規模の調査
• [[legal-compliance]] — 特商法表記・前払式支払手段・返金ポリシー
• [[growth-launch]] — 有料転換率向上・グロース施策
• [[requirements-definition]] — 課金機能の要件定義
• [[implementation]] — Stripe等の決済実装
• [[monitoring-operations]] — 転換率・解約率・LTVの継続計測
• [[idea-generation]] — 収益モデルのアイデア発散