free-tier-strategy

無料枠の設計

開発者が実際に使えるものを作り、価値を実感し、罠にはめられたように感じたり不満を抱いたりすることなく、自然に有料プランへ移行できる無料枠を設計しましょう。

概要

開発者向けツールには無料枠が必要です。開発者は購入前に試せることを期待しており、その試用には意味があることを求めています。14 日間のタイマーや機能を制限したデモでは不十分です。しかし、無料枠はビジネスを維持できるものでなければなりません。どちらか一方に偏ると、制限が厳しすぎれば利用が広がらず、寛大すぎれば収益が失われます。

最適な無料枠は、個人の開発者には寛大に感じられ、プロジェクトの成長に合わせて自然に有料プランへ移行できるものです。

始める前に

/devmarketing-skills/skills/developer-audience-context スキルを確認してください。無料枠の設計は、趣味で開発する人、スタートアップ、企業のどの層を対象にするかによって大きく異なります。また、ユニットエコノミクスも把握しましょう。無料ユーザー 1 人あたりの実際のコストはいくらでしょうか？

無料トライアル、無料枠、フリーミアムの違い

定義

無料トライアル： 期間限定で全機能を利用可能（14 日間または 30 日間）

• 最適なケース：手厚いサポートを伴うエンタープライズ営業
• 不向きなケース：セルフサービス型の利用形態を持つ開発者向けツール

無料枠： 利用量や機能に制限がある、永続的な無料プラン

• 最適なケース：セルフサービスで利用が広がる開発者向けツール
• 必要なこと：制限を慎重に設計する

フリーミアム： 無料枠に加えて、有料で利用できるプレミアム機能を提供

• 最適なケース：趣味での利用とプロ向けの利用を明確に区別できるツール
• 必要なこと：プレミアム機能に明確な価値があること

オープンコア： オープンソースの無料版に商用機能を追加

• 最適なケース：インフラストラクチャやプラットフォーム
• 必要なこと：活発なオープンソースコミュニティ

モデルの選び方

要素	無料トライアル	無料枠	フリーミアム	オープンコア
営業形態	手厚いサポート型	セルフサービス型	セルフサービス型	混合型
評価にかかる期間	数週間	数か月	数か月	無制限
有料化への圧力	高い	低い	中程度	なし
コミュニティ形成	低い	中程度	中程度	高い
サポートコスト	高い	低い	中程度	変動

開発者向けツールには、ほとんどの場合、無料トライアルではなく永続的な無料枠が必要です。 開発者はサイドプロジェクトを作り、将来の利用に備えてツールを評価し、ほかの人にツールを勧めます。こうした活動には、長期にわたって無料で使えることが欠かせません。

適切な利用制限

適切な制限の指標

API 呼び出し／リクエスト

• 開発者にとって理解しやすく、追跡できます
• アプリケーションの成長に合わせて自然に拡大します
• 例：月 10,000 件のリクエスト

コンピューティングリソース

• コストとの関係が明確です
• 開発者が予測しやすい指標です
• 例：月 500 分のビルド時間

ストレージ

• 理解しやすい指標です
• データの増加に伴い、自然にアップグレードを促します
• 例：1GB のストレージ

シート／ユーザー数

• コラボレーションツールに適しています
• チームの成長に伴い、自然にアップグレードにつながります
• 例：最大 3 人のチームメンバー

不適切な制限の指標

無料枠を装った期間限定トライアル

• 「90 日間利用がないと無料枠の期限が切れます」
• 不安と不満を生みます

恣意的な機能の組み合わせ

• 「無料：プロジェクト 3 件、各プロジェクトにつき環境 2 つ、環境ごとにデータベース最大 5 個、データベースごとに 100MB」
• 評価するには複雑すぎます

成功を罰するような制限

• 「月間アクティブユーザー 100 人まで無料」
• 最も成功した無料ユーザーほど、早く制限に達します

ちょうどよい範囲

無料枠の制限は、次の条件を満たす必要があります。

1. 十分な利用を可能にする - 実際のサイドプロジェクトを作成して実行できます
2. 趣味での利用をカバーする - 個人プロジェクトで支払いが必要になることはありません
3. 時間ではなく成長をきっかけにする - プロジェクトの成功に伴ってアップグレードが必要になります
4. 簡単に予測できる - 開発者がいつ制限に達するかを把握できます

例：適切な制限の構成

Vercel：

• 個人プロジェクトは無制限
• 月 100GB の帯域幅
• サーバーレス関数の利用制限
• 趣味での利用は永久に無料

Supabase：

• データベースストレージ 500MB
• 帯域幅 2GB
• 月間アクティブユーザー 50,000 人
• ソーシャル認証は無制限

PlanetScale：

• データベース 1 個
• 月 10 億行の読み取り
• 月 1,000 万行の書き込み
• ストレージ 5GB

機能を制限する戦略

無料機能の原則

無料プランには、次のことに必要なすべてを含めるべきです。

1. 製品を十分に評価する
2. 実際のプロジェクトを構築してリリースする
3. 小規模な本番環境で運用する

無料で提供する機能

• 中核となる機能
• すべてのインテグレーションと SDK
• 標準的な認証
• 基本的なモニタリングとログ
• ドキュメントとコミュニティサポート
• 開発環境とテスト環境

有料プランで提供する機能

コラボレーション機能：

• 個人開発者を超えるチームメンバー数
• アクセス制御と権限
• 監査ログ

スケールとパフォーマンス：

• より高いレート制限
• より多くのコンピューティングリソースとストレージ
• プレミアムインフラストラクチャ（専用インスタンス）

エンタープライズ要件：

• SSO/SAML
• SLA と稼働率の保証
• 優先サポート
• コンプライアンス認証
• 個別契約

機能制限に関するアンチパターン

開発者にとって基本的なニーズを制限する：

Bad: Custom domains require paid plan
(Custom domains are table stakes)

Bad: CI/CD integration requires paid plan
(This is how developers deploy)

Bad: Environment variables limited on free
(This is basic functionality)

評価を妨げる制限：

Bad: "Advanced features" available for 7 days then locked
(Developers can't properly evaluate)

Bad: Production deploys require credit card
(Can't demonstrate to stakeholders)

「無料プラン税」への不満を避ける

不満を生む要因

1. 隠れた品質低下 - 無料プランは遅く、信頼性が低い
2. 機能の削除 - 無料で提供されていた機能を有料に移す
3. 予想外の制限 - 事前の警告なしに上限に達する
4. 見下したメッセージ - 「アップグレードして基本機能を解放しましょう」
5. サポートでの差別 - 無料ユーザーを二級ユーザーとして扱う

無料プランで好印象を生む方法

期待値を明確にする：

Free tier includes:
- Everything you need to build and launch
- No credit card required
- No time limits

Upgrade when you need:
- Team collaboration
- Higher usage limits
- Priority support

上限に達した際に適切に対応する：

You've used 8,000 of 10,000 free API calls this month.

Options:
- Wait for reset on March 1st
- Upgrade to Pro ($29/mo) for 100,000 calls
- Request temporary limit increase (for launches)

機能を誠実に比較する： 有料プランをよく見せるために、無料プランの機能を人為的に制限してはいけません。

GitHub のモデル

GitHub の無料プランの変遷は、適切な方法の好例です。

1. 無料のプライベートリポジトリ（以前は有料）
2. パブリックリポジトリ向けの無料 CI/CD 分数
3. オープンソースのメンテナー向けの無料 Copilot
4. 組織向けの手厚い無料プラン

結果：開発者は GitHub を気に入り、より多くの機能が必要になれば喜んで料金を支払います。

アップグレードのきっかけとタイミング

自然なアップグレードのきっかけ

成長によるきっかけ：

• 使用量の上限に達する（帯域幅、ストレージ、API 呼び出し）
• チームメンバーを追加する
• プロジェクトや環境を増やす
• より長い履歴の保存期間が必要になる

成熟によるきっかけ：

• 本番環境に移行する
• 稼働率 SLA が必要になる
• コンプライアンス要件を満たす必要がある
• プレミアムサポートを利用したい

きっかけの伝え方

悪い例：しつこく促す

[Popup every login]
Upgrade to Pro! 50% off this week only!
[Dismiss] [Upgrade]

良い例：状況に応じて伝える

[When approaching limits]
You're at 85% of your free tier API calls.
Your current usage suggests you'll hit the limit in 3 days.

[View usage] [Explore plans]

さらに良い例：役立つ情報を提供する

[When adding 4th team member]
Free tier includes 3 team members.

To add more collaborators, upgrade to Team ($25/user/mo).
This includes: [benefits relevant to teams]

[Not now - stay with 3] [Upgrade to Team]

タイミングの原則

1. ワークフローを中断しない - アップグレードの案内で操作を妨げない
2. 上限に達する前に警告する - 70％、85％、95％の通知
3. きっかけを説明する - 「このメッセージが表示されている理由は……」
4. 代替案を提示する - 「アップグレードするか、我慢するか」だけにしない
5. 選択を記憶する - 閉じた案内を毎日繰り返さない

オープンソースと商用モデル

オープンコアモデル

Open Source (MIT/Apache)          Commercial
─────────────────────────────────────────────────
Self-hosted core                  Cloud hosting
Community support                 Priority support
Standard features                 Enterprise features (SSO, audit)
                                  Compliance and SLAs

オープンコアを成功させる方法

境界を明確にする： 開発者が、何がオープンソースで何が商用なのかを正確に把握できるようにします。

良い例（GitLab）：

• Community Edition：完全な Git プラットフォーム
• Enterprise Edition：高度なセキュリティとコンプライアンス
• SaaS：CE または EE の機能を備えたマネージドホスティング

オープンソースは実用的でなければなりません： オープンソース版は、機能を不当に制限せず、本当に役立つものであるべきです。開発者は「オープンソースウォッシング」に気づき、不満を抱きます。

商用化の戦略

クラウドとセルフホスト：

• オープンソース：無料でセルフホスト
• 商用：マネージドクラウドホスティング
• 例：Plausible、Metabase、Supabase

エンタープライズ機能：

• オープンソース：個人や小規模チーム向けの完全な機能
• 商用：SSO、監査ログ、コンプライアンス
• 例：GitLab、Sourcegraph

サポートと SLA：

• オープンソース：コミュニティサポート
• 商用：優先サポート、稼働率 SLA
• 例：ほとんどのオープンソースデータベース

コミュニティとの関係

推奨事項：

• オープンソースに誠実に貢献する
• コミュニティからの貢献を受け入れる
• 商用化に関する判断について透明性を保つ
• オープンソースプロジェクトには無料の商用利用プランを提供する

避けるべき事項：

• ライセンスを変更したり、利用条件を突然変更したりしない（HashiCorp、Redis、Elasticを参照）
• コミュニティが構築した機能を商用化して競合しない
• 主にマーケティング目的でオープンソースを利用しない
• 商用利用の範囲に関するコミュニティのフィードバックを無視しない

料金ページでの伝え方

制限を明確に表示する

Free                    Pro ($29/mo)           Enterprise
─────────────────────────────────────────────────────────
10,000 API calls        100,000 API calls      Unlimited
1GB storage             50GB storage           Unlimited
3 team members          25 team members        Unlimited
Community support       Email support          Priority + SLA

無料プランに関するFAQの質問

すべての料金ページに、次の質問を含める必要があります。

• 「無料プランは本当に永久に無料ですか？」
• 「制限に達するとどうなりますか？」
• 「商用プロジェクトで無料プランを利用できますか？」
• 「無料プランの利用にクレジットカードは必要ですか？」

料金ページの例

優れた例：Vercel

• 無料プランの内容が明確
• 機能ごとの制限を比較できる
• 使用量計算ツールがある
• 「Hobby」という位置付け（「制限付き」ではない）

優れた例：Supabase

• 充実した無料プランを目立つように表示
• 制限の数値が明確
• 機能比較表がある
• オープンソースであることが分かる

成功している無料プランの例

Stripe

• 無料プランに月額料金がない
• 取引に対してのみ料金が発生（2.9% + 30¢）
• テストモードは無制限かつ永久に利用可能
• すべての機能を利用できる
• 成功する理由：コストが収益に連動する

Cloudflare

• 充実した無料プラン（帯域幅無制限）
• プレミアム機能との違いが明確
• ほとんどのサイトで実際に役立つ無料プラン
• 成功する理由：無料ユーザーが支持者になる

MongoDB Atlas

• 512MBのストレージを永久に無料で利用可能
• 共有クラスター（学習には十分）
• すべての機能をテストできる
• 成功する理由：開発者は無料で学び、企業が料金を支払う

Algolia

• 10,000件のレコードが無料
• 月間10,000件の検索リクエスト
• APIをすべて利用できる
• 成功する理由：アプリケーションの成長に合わせて拡張できる

無料プランの問題例

アンチパターン：隠れたトライアル

90日間利用がないと期限切れになる、または初期期間後に制限が縮小される「無料プラン」。

アンチパターン：機能の牢獄

中核機能が有料プランに限定され、無料プランでは評価に役立たない。

アンチパターン：サポートの砂漠

無料ユーザーが利用できるのはAIチャットボットだけで、バグの報告であっても人によるサポートを受けられない。

アンチパターン：突然の梯子外し

以前は無料だった機能が、既存ユーザーへの適用除外措置もなく有料化される。

ツール

使用量の追跡と制限

• Lago - オープンソースの使用量ベースの課金
• Metronome - 使用量の計測と課金
• Orb - 使用量ベースの課金プラットフォーム
• Stripe Billing - 従量課金に対応

利用制限のための機能フラグ

• LaunchDarkly - 機能フラグの管理
• Flagsmith - オープンソースの代替製品
• PostHog - 分析機能付きの機能フラグ

コンバージョン分析

• Amplitude - 無料から有料へのコンバージョンを追跡
• Mixpanel - ファネル分析
• ProfitWell - SaaSの指標と料金設定

関連スキル

• /devmarketing-skills/skills/usage-based-pricing - 開発者向けツールの料金モデル
• /devmarketing-skills/skills/developer-signup-flow - 開発者を無料プランに誘導する
• /devmarketing-skills/skills/developer-onboarding - 無料プランのユーザーを定着させる