Stripe Billing vs. Chargebee vs. Recurly: SaaSサブスクリプションプラットフォームの選び方

あなたはSaaSプロダクトをローンチし、最初の有料顧客10人を獲得した。そして今、実際以上に重く感じられる決断を前にしている——どのサブスクリプション請求プラットフォームの上に構築するか、という決断だ。選択を誤れば、18ヶ月後には何も壊れないよう祈りながら、数千件のアクティブなサブスクリプションを移行する慌ただしい1週間を過ごすことになる。正しく選べば、請求は二度と意識することのない、目に見えないインフラになる。

この賭け金は現実のものだ。サブスクリプション解約全体のおよそ20〜40%は非自発的なもの——つまり顧客が解約するつもりはなかったのに、カードの有効期限が切れたり決済が拒否されたりして、誰もそれに気づけなかったケースだ。この単一の失敗モードだけで、業界全体で月次経常収益（MRR）の推定9%が失われており、有効期限切れのカードだけで全支払い失敗の42%を占めている。どの請求プラットフォームを選ぶかは、あなたがまだ気づいていないとしても、毎月静かに失われていく収益に対する最前線の防御策でもあるのだ。

成長中のSaaS企業の間で話題を独占するのは3つのプラットフォームだ——Stripe Billing、Chargebee、そしてRecurly。それぞれ異なるタイプの企業に最適化されている。どれが自社に合うのか、その見分け方を紹介する。

クイックアンサー​

• 開発者主導のプロダクトで、チームは小規模、スピード重視？ → Stripe Billing
• 非エンジニアがチケットを起票せずに価格を変更する必要がある？ → Chargebee
• 複雑な契約や従量課金を伴うエンタープライズB2B、あるいは支払い回収が最大のレバー？ → Recurly

では、その理由を詳しく見ていこう。

Stripe Billing：開発者のデフォルト​

エンジニアがすでに単発決済のためにStripeを導入しているなら、Stripe Billingは最も抵抗の少ない選択肢だ。これは後付けのサードパーティツールではなく、あなたがおそらくすでに運用している決済インフラのネイティブな拡張である。

強みとなる点：

• APIの一貫性。 Stripeのドキュメントが充実していることは有名で、CLIを使えばウェブフックやサブスクリプションイベントのローカルテストが本当に苦労なく行える——2、3人のエンジニアリングチームにとって実際に時間の節約になる。
• 自分で構築する必要のない顧客ポータル。 Stripeにはブランド化可能な構築済みの顧客ポータルが用意されており、購読者はサポートにメールを送ることなく、プランのアップグレード・ダウングレードや支払い方法の更新ができる。
• 透明性のある従量課金制の料金体系。 別途プラットフォームの購読料はかからず、処理した経常収益のおよそ0.5%を支払うだけだ。ただしStripe Tax（取引ごとに+0.5%）やStripe Revenue Recognition（+0.25%）といった追加モジュールが必要な場合は、その分費用が積み上がる。

弱点となる点： Stripe Billingは強力だが、コードファーストな設計だ。価格モデルが複雑化してくると——例えば階層制＋従量課金＋超過料金に、期中アップグレードや年間契約の按分計算が絡んでくるようなケースでは——プラットフォームが標準で想定していないエッジケースを処理するために、独自ロジックを書いて保守し続けることになりがちだ。また開発者向けに作られているため、マーケティングや財務チームのメンバーがエンジニアリングを介さずに安全にプランを調整することは通常できない。

最適な対象： 月間MRRが約50万ドル未満の、開発者主導のアーリーステージSaaS企業で、「決済を受け付ける」から「サブスクリプションを運用する」までの最短ルートを求めており、請求ロジックの一部をコードで管理することに抵抗がない企業。

Chargebee：価格実験のために作られたプラットフォーム​

Chargebeeが存在する理由は、ひとえに柔軟性にある。これは価格モデルの変更を見込むチームにとって第一選択のプラットフォームであり——SaaS創業から1〜2年目の創業者であれば、おそらくあなたもそうなるだろう。成功しているSaaS企業のほぼすべてが、顧客が実際に何に価値を感じるかを学びながら、少なくとも一度は価格を見直している。

強みとなる点：

• ノーコードでのプラン管理。 プロダクトチームや財務チームは、プルリクエストを開くことなく、価格ティア、アドオン、クーポン、従量課金と定額のハイブリッドモデルを作成・テスト・変更できる。
• 複雑さを本当の意味で扱える。 従量超過を伴う階層制の価格設定、期中アップグレードのある年間契約、複数エンティティにまたがる請求——これら3社の中でも、回避策なしでネイティブに対応できるのはChargebeeだけであることが多い。
• 強力な会計連携。 収益認識や会計・ERPシステムへのエクスポートは、Stripe Billingの標準ツールよりも成熟している傾向があり、コントローラーや外部の記帳担当者が毎月帳簿を締めるようになった段階で重要になってくる。

弱点となる点： 無料枠を超えると、Chargebeeの料金は大きく跳ね上がる（累計請求額がおよそ10万ドルを超えると、数百ドルから1000ドル超の定額月額料金が発生し始める）。そのため、収益前や立ち上げたばかりの段階では、純粋な収益比率型のモデルよりも大きなコミットメントとなる。

最適な対象： 最初の価格モデルを超えて成長していくSaaS企業、特に非エンジニア（グロース責任者や財務リードなど）が請求設定を直接管理する必要がある企業。

Recurly：出血を止めるために作られたプラットフォーム​

Recurlyのポジショニングはより狭いが、適した企業にとっては他の2社よりも価値がある——支払い失敗によって静かに失われているお金を減らすために存在しているのだ。

強みとなる点：

• コア機能としてのスマートなダニング。 Recurlyの機械学習で最適化された再試行ロジックは、拒否された請求をいつ、何回再試行するかを決定する。早すぎる段階で諦めたり、逆に試行回数が多すぎて顧客を苛立たせたりする固定スケジュールでの再試行とは異なるアプローチだ。
• 解約予測。 Recurlyの分析機能は、解約前にリスクのあるアカウント——通常とは異なる利用の落ち込みや、繰り返される決済失敗寸前の状態——にフラグを立て、チームが介入する機会を与えてくれる。
• プラットフォーム料金のない収益比率型の料金体系。 Stripe Billingと同様の仕組みで、小規模企業にとって手が届きやすい一方、エンタープライズ級の契約にも十分対抗できる。

弱点となる点： Recurlyの核となる強み——ダニングと回収——が最も重要になるのは、実際の取引量がある程度大きくなってからだ。顧客40社を抱える5人のスタートアップではその違いをほとんど感じないだろうが、月に数万件の請求を処理する企業ではすぐに実感するはずだ。数字がそれを裏付けている——自動化されたダニングは、放っておけば失われてしまう支払いの40〜70%を回収するのに対し、介入がまったくない場合の回収率はおよそ15%にとどまる。

最適な対象： 支払い失敗が測定可能で増加傾向にあるコスト項目となっているサブスクリプション事業——特にB2Cや大量取引のB2B——、あるいは複雑な従量課金と契約条件を持つエンタープライズB2B SaaS。

一目でわかる比較表​

切り替えコストは現実のもの——早めに計画しておこう​

この決断を「後で使わなくなったら切り替えればいい」という低リスクなものとして扱いたくなるかもしれない。しかし実際には、稼働中のサブスクリプション基盤を請求プラットフォーム間で移行することは、成長中のSaaS企業が引き受けうる中でも特に痛みを伴うプロジェクトの一つだ。単にデータベースのテーブルを移すだけではなく、次のようなものを移すことになる。

• 有効な支払い方法。 関わるプラットフォームによっては、保存されているカード情報をプログラム的に移行できない場合があり、一定割合の顧客が支払い情報を再入力する必要が生じ、切り替え時に解約するリスクを負うことになる。
• 按分計算と契約状態。 期中のサブスクリプション、未使用クレジットが残る年間契約、カスタム割引などは正確に再現する必要があり、そうしなければ顧客への請求が誤り、サポートへの問い合わせが一気に増えてしまう。
• 過去データのレポート連続性。 請求プラットフォームのデータモデルに依存するMRR、解約率、コホートダッシュボードは、過去データの補完を慎重に計画しておかない限り、移行の前後で不連続な数値を示すことがある。
• ダニングと回収ロジック。 例えばコスト面の理由でRecurlyから移行する場合、そのスマートな再試行機能が静かに守ってくれていた回収率を、自分たちで再構築する責任を引き継ぐことになる。

だからといって永久に縛られるわけではない——実際に移行を成功させている企業は数多くある。ただ「今は一番安いものを選んで、後で切り替えればいい」という考え方は、その「後で」が実際にどれほど高くつくかを過小評価しているということだ。今日の請求額だけを最適化するよりも、12〜18ヶ月後の自社のモデルに合ったプラットフォームに多少余裕を持たせておくほうが、たいていの場合は安上がりになる。

シンプルな決め方​

次の3つの質問を順番に自分に問いかけてみよう。

1. エンジニアリングチームは小規模で、請求ロジックはシンプルか？ イエスなら、Stripe Billingが最速でリリースまで導いてくれる。
2. 非エンジニアが価格を変更する必要があるか、あるいは自社のモデルはすでに複雑（階層＋従量＋契約）か？ イエスなら、Chargebeeは高めの価格に見合う価値がある。
3. カード決済の失敗や非自発的解約によって、測定可能な規模の収益を失っているか？ 支払い失敗が拡大するコストセンターになっているなら、Recurlyの専門性はそれ自体で元が取れる——多くの場合、最初の数件の回収取引だけで。

月間MRRがおよそ10万ドル未満の創業者は、「セットアップの容易さ」を重視すべきだ。MRRが50万ドルを超えると、判断基準は支払いパフォーマンスと回収へとシフトする。なぜなら、ダニングの回収率がわずか数パーセント改善するだけでも、規模が大きくなれば実際の金額として大きな差になるからだ。

どのプラットフォームを選んでも、ここには注意しよう​

どの請求プラットフォームが勝つとしても、自然には解決しない問題が一つある——サブスクリプション収益は、集金するだけでなく正しく記録されなければならない、ということだ。Stripe、Chargebee、Recurlyのいずれで決済が成功しても、それが銀行口座に着金した瞬間に自動的に帳簿上の「収益」になるわけではない。繰延収益、返金、按分クレジット、そして失敗後に回収された請求はすべて、請求プラットフォームが報告する内容と突き合わせて調整する必要がある。決済プロセッサーのダッシュボードを財務の唯一の真実として扱っている創業者は、たいてい最初の資金調達や確定申告の前に、帳簿の混乱に驚かされることになる。

ここで良い記帳習慣が早い段階から効いてくる。サブスクリプションのすべての請求、返金、ダニングによる回収、プラン変更は、請求プラットフォームのレポートUIだけでなく、あなたの元帳に記録されるべき取引なのだ。そのUIは、もともと会計システムを兼ねるようには作られていない。

請求スタックと同じくらい帳簿もクリーンに保とう​

適切なサブスクリプション請求プラットフォームを選ぶことは、問題の半分を解決するにすぎない——その収益を正確に記録することが、もう半分だ。Beancount.ioは、SaaS創業者に対して、透明性があり、バージョン管理され、Stripe、Chargebee、Recurlyからのエクスポートと簡単に突き合わせられるプレーンテキスト会計を提供する。ベンダーロックインもブラックボックスの元帳もない。経常収益をどのように扱うかはドキュメントを、元帳のビジュアルダッシュボードはFavaをチェックしてほしい——そして無料で始めて、あなたのコードベースと同じくらい監査可能な財務記録を維持しよう。