この記事では、Stripe を利用した従量課金システムの構築方法について紹介します。デジタルキューブが運営する WordPress 専用ホスティングサービス「Amimoto」そして「Shifter」において、なぜ従量課金によるプラン提供を開始したかや実装・運用後のノウハウなどをまとめました。月額課金型のウェブサービスを提供する企業や開発チームが、新しい料金モデルや顧客からのリクエストに応えるための新しい引き出しとしてお使いいただけたら幸いです。
顧客のビジネスニーズに応じた料金モデルを設計する
SaaS 事業の運営には、顧客の利用量を想定した価格体系とシステム構築の計画が欠かせません。このような顧客の利用権を管理する仕組みのことを「Entitlements Management」と呼びます。そして多くの場合、事前に設計した Entitlements と顧客の利用動向には想定外のズレが発生します。これは前提としたユーザーストーリーと実際のニーズが一致していないこともありますが、想定以上に顧客がサービスを重用してくれているという、事業者にとってありがたい現象によって発生することもあります。
問題となるのは、事前に設計した Entitlements の設計や価格モデルとの関連付けと、実際のユースケースで発生したずれをどのように吸収するかです。最も簡単な方法は、現在の価格モデルに設定している利用枠や権限などの Entitlements を変更することです。しかし一口に WordPress サイトといってもコーポレートサイトと EC サイト、そしてイベントのランディングページなどユースケースは多岐に渡ります。様々なユースケースをサポートするプランを設計することは事実上不可能であり、仮に成功した場合でも複雑なプラン体系によって顧客が導入検討や予算計画を立てることが困難になるなどの問題があります。
このような問題を解決する方法の1つとして、「実際に顧客が使用した分だけを請求する仕組み」つまりは従量課金によるアドオン・オプションプランを提供することを決定しました。ユーザーが公開したウェブサイトのトラフィック、転送量がベースとなる固定額プランの上限を上回った場合、追加で発生した転送量分の費用を翌月の請求にて支払うことができます。これによって顧客はトラフィックのスパイクなどによる計画外のアクセス数増加や、開発者またはライターが意図せずに大容量のメディアファイルを公開してしまった場合などに発生するサイトの停止状態を回避することができます。
Stripe で従量課金プランを提供する
Stripe で従量課金によるサブスクリプションを提供するには幾つかの API またはバッチ処理が必要です。ここでは主要な実装項目として3つの API またはバッチ処理を紹介します。
従量課金プランのサブスクリプションを契約する API
まず最初に必要となるのは、サブスクリプションを作成する API です。従量課金モデルの料金を含むサブスクリプションを作成する際であっても、 Stripe API の実装内容はほとんど変わりません。固定金額の料金と併用することも可能ですので、「基本料金 + 追加の従量課金ベース手数料」という決済代行会社や EC プラットフォームで見かけることの多いモデルも簡単に実装できます。
const subscription = await stripe.subscriptions.create({
currency: 'jpy',
customer: 'cus_SVXdGJeAg19L8I',
default_source: 'card_1RaWYe4ZjXP5AYPn7znqk48i',
off_session: true,
payment_behavior: 'error_if_incomplete',
proration_behavior: 'none',
items: [
{
price: 'price_1RaWXO4ZjXP5AYPnw9H0gBFi',
},
{
price: 'price_1RRpGV4ZjXP5AYPndkA7y9yi',
quantity: 1,
},
],
});
実装時の注意点として、「従量課金モデルの料金では、quantity を指定してはいけない」ことに注意しましょう。quantity は従量課金の計算に利用されるため、サブスクリプションの作成や Checkout Session を作成する際に数値を設定すると、以下のエラーが発生します。
{
"error": {
"message": "usage_type が `metered` の場合は、数量は指定できません。`line_items[0]` から数量を削除してください。",
"message_code": "checkout_quantity_not_allowed_for_metered_usage_type",
"param": "line_items[0]",
"request_log_url": "https://dashboard.stripe.com/test/logs/req_xxxxx",
"type": "invalid_request_error"
}
}
顧客の利用状況を計測し、Stripe に記録する API / バッチ処理
続いて、顧客が利用した数量を Stripe にレポートする仕組みも実装が必要です。2024年ごろまでは Usage Records API を利用してデータを登録していましたが、現在は生成 AI チャットやエージェントでも利用できるように改良された Meter API を利用します。
利用状況を記録するためのメーターは、ダッシュボード / CLI / API いずれからも作成できます。Stripe CLI を利用する場合、以下のコマンドで新しく作成することができます。
stripe billing meters create \
--display-name="Alpaca AI tokens" \
--event-name=alpaca_ai_tokens \
-d "default_aggregation[formula]"=sum \
-d "customer_mapping[event_payload_key]"=stripe_customer_id \
-d "customer_mapping[type]"=by_id \
-d "value_settings[event_payload_key]"=value
ダッシュボードから作成する場合、集計方法によって合計の利用量がどのような計算になるかをプレビューできます。初めて従量課金を実装される方は、ダッシュボードから作成されることをお勧めします。
なお、Usage Records API は 2025 年 3 月末以降にリリースされた API バージョンでは利用できません。そのため、新しく従量課金モデルを検討される方は、 Meter API で実装しましょう。2025 年 3月にリリースされた API バージョンでの変更内容については、別記事にて紹介していますので、併せてご覧ください。
あとは定期的なバッチ処理や API によって、顧客の利用状況を作成したメーターに登録するだけです。バッチ処理で日ごと・週ごとなど利用量を集計している場合は、次のコードのように集計した数値を文字列として payload.value に設定しましょう。また、どの顧客による利用かを判別するため、 payload.stripe_customer_id に該当顧客の Customer ID を設定する必要があります。集計スクリプトにて Stripe の Customer ID を収集する仕組みを忘れず実装しましょう。
const meterEvent = await stripe.billing.meterEvents.create({
event_name: 'alpaca_ai_tokens',
payload: {
value: '25',
stripe_customer_id: '{{CUSTOMER_ID}}',
},
});
回数に応じた集計をサポートする方法
Shifter におけるサイトのビルド回数や、メディアサイトにおけるコンテンツの閲覧数・ダウンロード数のような、顧客による操作の回数を従量課金の計測対象としたい場合は、実際の操作を行う API に先ほどの処理を追加しましょう。
const meterEvent = await stripe.billing.meterEvents.create({
event_name: 'build_wordpress',
payload: {
value: '1',
stripe_customer_id: '{{CUSTOMER_ID}}',
},
});
また、メーターを作成する際の設定において、「集計方法」を「カウント数」に設定しましょう。この設定にすることで、上記のメーターイベントが発生した回数を集計対象にするため、意図しない数量が設定されるリスクを軽減できます。
従量課金プランの利用状況を顧客が確認する API
従量課金プランを設計する上で、必須かつ実装漏れが起きやすい要件は「顧客が利用状況を把握できること」です。開発者やテスターは Stripe 上のデータをチェックしてテストや受け入れチェックを実施するため、リリース直前に「顧客が来月いくら支払うことになるかがわからない」という問題が発覚することもあります。 Meter API を利用する場合、「メーターの ID」と「対象の Customer Id」の 2 つがわかれば、データ取得の実装ができます。
const meterEventSummaries = await stripe.billing.meters.listEventSummaries(
'mtr_test_61Q8nQMqIFK9fRQmr41CMAXJrFdZ5MnA',
{
customer: 'cus_Pp40waj64hdRxb',
start_time: 1711584000,
end_time: 1711666800,
value_grouping_window: 'hour',
}
);
この他、 2025 年 6 月時点では公開プレビュー状態ながらも利用量アラートを設定する機能も用意されています。使いすぎや意図しない高額請求を防止するための仕組みとして活用できますので、こちらも併せて要件に組み入れることをご検討ください。
実運用における追加実装ポイント
Amimoto や Shifter における実装では、Stripe の組み込み部分以外にも追加の要件が発生しました。実際のプロジェクトに導入する上でのポイントとして紹介いたしますので、従量課金プランの導入を検討されている方は、ぜひ自社でも類似するケースや問題が発生しないかをご確認ください。
従量課金オプションの解約制御は計測対象によって変更する
弊社で導入した従量課金オプションは、ホスティングで提供する CDN の転送量をメーターとしました。そのため、すでに従量課金のメーターがまわり出しているサブスクリプションについては、当月の解約を条件付きで禁止する仕組みにしています。これは CDN の月間転送量累計という計測対象の性質上、オプションプランを解約すると本契約のプランだけでは転送量の利用量が超過してしまうためです。そのため、月が変わってメーターがリセットされたタイミングや、より上位のホスティングプランへの変更による超過状態を回避することが事前に必要となります。
一方で生成 AI チャットサービスのような「カウント数ベースで課金するモデル」であれば、解約した時点で追加の利用を制限できます。従量課金モデルを提供する場合は、期間中に顧客が解約を希望した場合にどのようなケースが発生するかを調査することをお勧めします。
後払いによる未払いリスク
基本的に Stripe でサブスクリプションを提供する場合、料金を事前に支払ってサービスを利用する先払いモデルです。しかし従量課金の場合は、次の支払いサイクルの請求で使った分を請求する後払いモデルとなります。そのため、請求が回収できなかった場合の損失が先払いモデルよりも大きくなるリスクがあります。
弊社では Stripe デフォルトの支払いリトライや再請求機能の活用と、従量課金プラン提供をクレジットカード支払いに限定することで、リスクと請求業務の煩雑化を回避しています。また、現在では公開プレビュー機能の「クレジット事前購入機能」を活用することで、回収漏れリスクをさらに軽減することが可能です。
おわりに：顧客の成長に寄り添う料金モデルへ
顧客の利用状況に応じた請求モデルは、事業者・顧客・システムすべての負担を軽減し、より多くの顧客に最適なサービスを提供できます。そして Stripe などの柔軟な請求モデルをサポートしているプラットフォームを利用することで、利用状況に応じた提案や実装を少ない手間で実装できます。しかし一方で、請求ロジックや利用量計測などの中核機能の実装に集中しすぎると、以下のようなビジネス的な要件を見落としてしまうリスクが生まれます。
- 利用状況の可視化：顧客が自身の利用量と予想請求額を確認できる仕組みの実装
- 解約制御の設計：計測対象の特性に応じた適切な解約ポリシーの設定
- 未払いリスクの管理：後払いモデル特有のリスクに対する対策
従量課金モデルは、SaaS 事業者にとって顧客の成長を支援しながら、自社の収益も最大化できる有効な選択肢です。本記事で紹介した実装方法と運用ノウハウを参考に、皆様のサービスに最適な従量課金システムの構築にお役立てください。
Stripe を活用したオンライン決済システム導入をサポートします
株式会社デジタルキューブは Stripe 公式パートナーとして、自社サービス開発で培った経験を活かし、Stripe を用いた決済システムの導入を支援します。多言語対応の決済フォーム実装、モバイル支払い対応、柔軟な従量課金システム構築など、ユースケースに合わせた活用方法の提案から、専用ダッシュボードの開発まで幅広くサポートします。
SaaS ダッシュボード開発や EC サイトへの Stripe 決済導入など、様々な導入実績があります。 API の呼び出しだけで決済機能を実装できる Stripe の利点を最大限に活かしたシステム構築をお手伝いします。
