pricing

価格設定（何に、どのように課金するか）

価格は最後に決める数字ではありません。これはポジショニングの判断であり、市場に対して、自分たちは何者で、何を置き換え、どれほどの価値があると考えているのかを伝えます。恐れではなく、根拠に基づいて決めましょう。

こんなときに使います： 価格をなんとなく決めている、直感で価格を設定してしまい今さら変えられないと感じている、無料の範囲をどこまでにするか分からない、開発者には使われているのに誰も支払わない、あるいは「開発者はこれにお金を払わない」と考えて、そもそも一度も課金したことがない場合です。

核心となる考え方

3つの判断を、この順番で行います。多くの創業者は3つ目に飛びつき、なぜ何も成約しないのかと悩みます。

1. 価値指標（何に対して課金するか）。価格設定で最も重要な判断です。これを間違えると、どのような料金プランを設けても補えません。
2. パッケージ構成（何を無料にし、有料にし、エンタープライズ向けにするか、何をきっかけにアップグレードを促すか）。
3. 価格（各プランの具体的な金額）。

そのすべてに通じるルールが1つあります。顧客が得る価値を基準に価格を設定し、自社のコストや恐れを基準にしないこと。 AWS の請求額は価格戦略ではありません。

まず、価格を設定できる段階に達していますか？

ユーザーが戻ってくるという確かな証拠が得られるまでは、利用を制限しないでください。2週目の継続率が低い状態で課金の壁を設けても、漏れのあるファネルが小さくなるだけです。まず継続率を証明し、それから収益化しましょう（know-if-its-working を参照）。例外は1つだけです。購入者からすでに「X に対して料金を支払えますか」とメールが届いている場合は、どの段階にいてもゴーサインです。支払う意思を明確に示すことは、最も強力なシグナルです。

フレームワーク：価値指標

顧客がより多くの価値を得るほど増えるものに対して課金しましょう。優れた指標には、次の特徴があります。

• 顧客の成功に応じて増えるため、顧客の成長に合わせて請求額も増えます（シート数、アクティブユーザー数、プロジェクト数、イベント数、API 呼び出し数、GB 数、ビルド数、監視対象のエンドポイント数など）。
• 十分に予測しやすいため、財務担当者が費用を予測できます。一晩で10倍に跳ね上がるような従量課金は、予想外の請求と解約を招きます。
• 一文で分かりやすく説明できるものです。開発者が支払額をおおよそ予測できなければ、導入されません。

Does the value come mostly from more PEOPLE using it (collaboration, seats)?
├─ YES → per-seat, but watch for seat-sharing and bot accounts deflating it
└─ NO  → value comes from more USAGE (events, calls, compute, data)
         → usage-based, with a floor and caps so the bill stays predictable

ハイブリッド型は一般的で、問題ありません。基本料金に従量課金を組み合わせます。価値がマシンや使用量に左右される場合は、シート単位の課金を避けましょう（増やしたいものに課税することになります）。また、価値が人間同士のコラボレーションにある場合は、完全な従量課金を避けましょう（チームがアクセスを制限するようになります）。

フレームワーク：パッケージ構成（無料から有料への境界）

OSS または PLG の開発者向けツールでは、無料プランは慈善ではなく、ユーザー獲得の手段です。 境界を決める問いは、「どこまで無料で提供できるか」ではなく、「個人のハッカーには不要でも、本格的なチームには必要なものは何か」です。

• 無料／オープンソース： 1人の開発者、またはごく小さなチームが利用するための中核的な価値です。日々のワークフローに組み込まれるだけの十分な価値を提供しましょう。これがユーザー獲得につながります。
• 有料（チーム）： 個人ではなく企業にとって重要になる機能です。コラボレーションとシート数、より高い上限とスケール、SSO、監査ログ、ロール、コンプライアンス（SOC 2、オンプレミス、データレジデンシー）、サポート、SLA などです。
• エンタープライズ： 「お問い合わせください」という形です。セキュリティ審査、調達手続き、個別契約が必要になる段階から始まり、通常は誰かが SSO や DPA を求めた時点がその境目です。

アップグレードは、恣意的な制限に達したときではなく、価値を実感したタイミングで促しましょう。良い例：「3人目のチームメンバーを追加した」「イベント数が1万件を超えた」「SSO が必要になった」。悪い例：カウントダウンタイマーや、その機能なしではツールが役に立たないような機能を隠すことです。

目安として、チーム、スケール、信頼に対して課金し、個人が得る価値は無料で提供しましょう。 開発者は「会社でこれが必要だ」という理由で設けられた課金の壁なら受け入れます。しかし、「宣伝されていた機能」に課金の壁を設けることには反発します。

フレームワーク：価格を決める

会議室で決めてはいけません。重要度の高い順に並べると、次のとおりです。

1. 支払い意思を遠回しに示す反応。 すでに届いている「Xにお金を払えますか？」というメッセージです。返信して、これがないことでどんなコストが発生していたか、社内で承認を得るにはいくらである必要があるかを尋ねましょう。費用がかからず、最も有力な価格調査です。
2. 価値を基準にする。 何を置き換え、どれだけ節約できるかを基準に価格を決めます。人件費込みで時給100ドルのチームの時間を月10時間節約できれば、1,000ドル相当の価値があります。50ドルを請求するだけでは、価値を取りこぼします。競合より安くするのではなく、提供した価値の一部を価格に反映しましょう。
3. 競合を基準にする。 購入者がすでに頭の中で想定している価格を把握しましょう。月額30ドルのツールと比較されるなら、99ドルにする理由か、9ドルにする理由が必要です。どちらでも勝てます。「だいたい同じで少し安い」では勝てません。
4. 価格帯を尋ねる（talk-to-users の通話で）：「いくらなら高すぎて検討しませんか？ いくらなら安すぎて品質を疑いますか？」その間が価格帯です。

把握しておきたい基準：

• 価格に誰も異議を唱えないなら、安すぎます。「高いですね」という反応が適度にあるのが健全です。
• 顧客が価格のおよそ10倍の価値を得られることを目指しましょう。およそ3倍を下回ると解約されます。予算審査で数字が通りません。
• 年間プランは約2か月分が無料（15～20％割引）です。資金の確保と顧客維持につながります。
• 高いプランを基準にしましょう。 高額プランを見せることで、売りたいプランが妥当に見えます。2段階より3段階のほうが成約率が高く、通常は中間プランが狙い目です。
• OSS／PLGでは、無料から有料への転換率は**2～5％**が一般的です。ほぼゼロなら、通常は価格ではなく、無料から有料に切り替わる境界線が間違っています。

もっともらしく見える失敗

• コスト積み上げ方式の価格設定。 「コンピューティングに8ドルかかるので、12ドルを請求します」。コストは下限であり、戦略ではありません。価値に基づいて価格を決めましょう。
• いつまでも課金しない。 「開発者はお金を払わない」は、たいてい「まだ尋ねていないし、尋ねるのが怖い」という意味です。支払い意思を遠回しに示すメールが、すでにその考えを否定しています。
• プランが多すぎる。 4つ以上あると、選択に迷って決められなくなります。セルフサービスでは3つが上限です。
• 無料プランが太っ腹すぎる。 実在する企業がアップグレードする必要のない状態なら、優れた無料ツールは作れても、ビジネスにはなりません。チーム、規模、SSO／コンプライアンスの要件に応じて、有料に切り替わる境界線を設定しましょう。
• マシンの価値で決まる製品にユーザー単位の課金をすること（または、コラボレーション製品に使用量課金をすること）。伸ばしたい行動そのものに課金することになります。
• 価格で競争する。 「最高のコストパフォーマンス」や「Xより安い」は、底値を競うことになり、誇大表現に関するルール上、証明もできません。割引ではなく、価値指標と導入のきっかけで勝ちましょう。
• 恐れに駆られて割引する。 最初の「高すぎる」に折れると、買い手は押せば値引きされると学び、こちらが自社の価値を信じていないことも伝わります。
• 上限のない使用量課金を公開する。 低い見出し価格よりも、予測可能性のほうが重要です。使用量モデルで解約を招く最大の要因は、予想外の高額請求です。

次の30分でやること

• 価値指標を一文で言い表しましょう：「___あたりで課金します」。顧客の成功に伴って増え、予測可能な指標か確認します。
• 無料から有料に切り替わる境界線を引きましょう。個人開発者が無料で使える範囲と、企業が料金を払う必要のある範囲（シート数、規模、SSO／コンプライアンス、サポート）を決めます。
• これまで遠回しに断ってきた**「Xにお金を払えますか？」というメッセージ**をすべて探しましょう。3つの質問（導入しない場合のコスト、承認可能なプランの内容、概算予算）を含む返信を作成します。
• それぞれに明確なアップグレードのきっかけを設けた3つのプラン（無料／OSS、チーム、エンタープライズ［お問い合わせ］）を考えましょう。
• 価値を基準にして、チームプランに実際の価格を設定しましょう。少し不安を感じないなら、安すぎます。

---

実際の開発者向けツールのGTM経験と、Adam Frankl（The Developer-Facing Startup）およびJakub Czakon（markepear.dev）のフレームワークをもとに作成しました。 価格は、設定する数字のなかで最も大きな影響力を持つ一方、一人で決めると最も間違えやすいものです。人の目で見た意見が必要ですか？ LinkedIn からご連絡ください。