AIプロダクトの無料体験を「コスト最小・転換最大」に設計する5ステップ——Bolt.newの60日$40M ARR達成から逆算する使用量課金PLG

Bolt.newが倒産寸前から60日で$40M ARRに到達した話は、別のケーススタディで詳しく書いています。この記事では、その成長を支えた「無料体験の設計」を自社プロダクトで再現するための具体的な手順を説明します。

目標は「コスト最小・転換最大」のフリーミアム設計です。無料で使わせながら運営コストを抑え、プロダクトへの依存度が高まったタイミングで自然にアップグレードが起きる仕組みを作ります。押し売りではなく、ユーザーが自分で「払いたい」と判断する構造です。

Bolt.newが実際にやった設計の核心

2024年秋、Bolt.newは一度サーバーコストが売上を上回り、会社が崩壊しかけました。無料で提供していたAIコード生成が、ユーザー数の増加とともに赤字を拡大させていたからです。

そこから行った根本的な変更が「デバイスオフロード」です。AIの処理の一部をサーバーからブラウザ側に移すことで、ユーザーが増えてもサーバーコストが比例して増えない構造を作りました。同時に、トークンベースの使用量課金を導入し、「使えば使うほど有料プランの価値を感じる」サイクルを設計しました。

この記事で再現するのはその構造です。デバイスオフロードはプロダクトによって難易度が異なりますが、使用量課金と依存度ベースの転換設計は、ほとんどのAI・SaaSプロダクトに適用できます。

始める前に確認する3つの前提条件

この設計を機能させるには3つが必要です。まず、使用量を数値で測れる単位があること。AIプロダクトならトークン数、API呼び出し回数、生成回数などです。「月3回まで無料」のような回数制限でも機能しますが、細かく制御できるほど転換率は上がります。

次に、無料ユーザーのコストを一定以下に抑える手段があること。クラウドリソースの使用量上限をかけるか、処理の一部をクライアント側に移すかが主な選択肢です。「無料ユーザー1人あたりの限界コスト」を計算できていない場合は、先に把握してください。

最後に、ユーザーの使用データをリアルタイムで取得できること。「このユーザーは無料枠の80%を使い切った」「3日連続で使っている」を検知できなければ、適切なタイミングでアップグレードを促せません。

5ステップで設計する使用量課金PLGの仕組み

ステップ1：課金の「単位」を1つに絞る

最初にやるべきことは課金単位の決定です。複数の指標を組み合わせると設計が複雑になり、ユーザーも混乱します。AIプロダクトならトークン数が最も直感的ですが、「生成回数」や「処理時間」のほうが理解されやすいケースもあります。

重要なのは透明性です。ユーザーが使う前に「これくらい使えば、これくらいかかる」を自分で計算できる状態を作ります。無料枠の上限はこの単位を基準に設定します。「1ユーザーあたりの限界コスト」を起点に逆算し、赤字にならない無料枠を決めてください。Bolt.newは最初ここを計算せずに設定して失敗しました。

ステップ2：無料ティアのコスト上限を設計する

無料ユーザーが増えてもサーバー代が比例して増えない設計が必要です。最も効果的な方法は処理のオフロードです。AIの推論処理をすべてサーバーで行うのではなく、WebAssemblyや軽量モデルのブラウザ実行など、可能な部分をクライアント側に委ねます。

完全なオフロードが難しい場合は使用量キャップで対応します。1日のトークン消費上限、1ヶ月の無料クレジット上限などをSupabaseのuser_usageテーブルで管理し、超えたらリクエストをブロックします。このとき大事なのがブロック時の体験設計で、エラーではなくアップグレードの入口として見せることです。「今月の無料分をすべて使い切りました。続けるにはこちらから」という画面が、最も転換率の高いページになります。

ステップ3：使用量データをリアルタイムで記録する

PostHogをプロダクトに組み込み、1回の生成ごとに消費トークン数とユーザーIDをイベントとして送ります。累計使用量はSupabaseで管理し、PostHogはその集計をダッシュボードで可視化するために使います。

注目すべき指標は「無料枠の消費率」と「1週間の利用頻度」の2つです。消費率が70%を超えたユーザーと、3日以上連続でプロダクトを使ったユーザーが、アップグレードの主要ターゲットになります。PostHogのコホート機能でこのセグメントを作り、プロダクト内のメッセージやメールのトリガーとして使います。アップグレードしたユーザーの行動パターンが蓄積されれば、無料ティアの設計自体を最適化するヒントにもなります。

ステップ4：Stripe Billingで使用量課金を組む

Stripe Billingの「Metered Usage」機能を使います。まずStripeダッシュボードでサブスクリプションプランを作成し、課金タイプを「使用量に応じた課金」に設定します。単位を「1トークン」または「1,000トークン」として単価を入力してください。

プロダクト側では、ユーザーがトークンを消費するたびにStripe APIのcreateUsageRecord()を呼びます。Stripeが月末に使用量を集計して自動請求するので、請求ロジックを自前で実装する必要はありません。無料ティアのユーザーはStripeのサブスクリプションには入れずSupabaseで管理し、アップグレード時にStripeのCheckoutセッションを立ち上げてカード登録と同時にサブスクリプションを開始します。

ステップ5：依存度ベースのアップグレードトリガーを設計する

「そろそろ有料にしてください」という直接的なメッセージは転換率が低いです。代わりに「あなたは今日もこれだけ使っています」という事実を見せます。

無料枠の残量が30%を切ったタイミングで、プロダクト内に小さなバナーを表示します。「今月あと○○トークンで無料枠が上限です」という情報だけで、ユーザーは自分で判断します。さらに効果的なのが「使い切った直後」の体験設計です。無料枠が尽きたとき、次のアクションが有料プランへの誘導だけになるよう画面を設計します。このタイミングのCVRは、通常のタイミングの3〜5倍になることが多いです。PostHogでこのフローのコンバージョンを計測し、どのトリガーが最も機能するかをA/Bテストで検証してください。

ツールの選択肢：3段階で考える

メインスタックはStripe Billing、PostHog、Supabaseの組み合わせです。Bolt.newが実際に使っていた構成で、立ち上げ初期から本番運用まで対応できます。Stripe Billingは使用量課金の集計と請求を自動化し、PostHogは行動データの収集とコホート分析を担い、Supabaseは使用量データのリアルタイム管理を受け持ちます。

代替を探すなら、課金はLemonSqueezyでも使用量課金が可能です。トラッキングはMixpanelやAmplitudeでもPostHogと同等の機能があります。ただしPostHogはセルフホストができるため、データをStripeと一元管理しやすく、プライバシーポリシーの制約が強いプロダクトや、コスト削減を優先するケースで有利です。

初心者向けのアプローチとして、まず課金ロジックを持たずに「使用量カウンター」だけをSupabaseに記録するところから始めます。データが取れれば、後からStripeを組み込むのは難しくありません。いきなりフルで組む必要はありません。

向いている人・向いていない人

この設計が向いているのは、ユーザーが使うたびにサーバーコストが発生するAI・SaaSプロダクトです。生成AIを活用したツール、APIコールが多いサービス、クラウドリソースを消費するプロダクトなら、使用量課金は自然なフィットがあります。特に「使えば使うほど価値を感じる」プロダクトでは転換率が高くなりやすいです。

向いていないのは、使用量に関係なくコストが固定のプロダクトです。シンプルなウェブアプリや、サーバーレスで運営コストがほぼゼロのケースでは、シートベースのサブスクリプションのほうがシンプルで管理しやすいです。またユーザー数が少ない初期段階では、使用量データが蓄積されないためこの設計のメリットが薄く、ある程度のトラフィックが出てから最適化するほうが効率的です。