従量課金の設計で最初に決めるのは料率ではありません。1件を何で数えるかです。
ここが曖昧なまま実装に入ると、請求の根拠を後から説明できなくなります。利用者から「この数字は何ですか」と聞かれて答えられない課金は、値段が妥当でも信用されません。
位置情報を使うスタンプラリーのサービスが、この定義を公開していたので、設計の題材として読みます(2026年9月時点の掲載内容です)。
候補になる数え方
「参加人数」と言ったとき、実装上の候補は複数あります。
A. 参加ページを開いた回数 → PV。水増ししやすい
B. 参加ページを開いた一意の端末数 → Cookie/LocalStorage 依存。消すと増える
C. 会員登録した人数 → 登録を必須にする設計が要る
D. 何らかの行為を完了した人数 → 定義が要るが、意味が明確
このサービスが採っていたのは D でした。定義はこうです。
初めてスタンプを1個以上取得した人数を数えます。ページを見ただけの人は含みません。(料金ページより)
なぜ D が扱いやすいか
3つあります。
1. 利用者に説明できる。 「現地へ行って1個押した人の数」で言い切れます。A や B は「なぜこの数字なのか」の説明が長くなります。
2. 告知の成否と課金が連動しない。 SNS で拡散して閲覧が跳ねても、請求は増えません。主催者は告知を躊躇しなくて済みます。A を採ると、拡散するほど費用が増えるという逆インセンティブが生まれます。
3. サーバー側のイベントで数えられる。 スタンプ取得はサーバーに記録が要る操作なので、クライアントの状態に依存せず数えられます。B はブラウザのストレージが消えると同じ人を二重に数えます。
3つ目は、この手のサービスでは特に大きい論点です。参加者に会員登録を強制しない設計(このサービスも会員登録は必須ではない)を採ると、一意な人の識別は本質的に困難になります。「初めてスタンプを取得した」というイベントを1回だけ記録する形にすれば、識別の精度が課金の精度に直結しません。
判定をどこに置くか
課金単位の話と地続きで、判定の置き場所も公開されていました。
位置の判定はすべてサーバー側で行い、押せる範囲・期間・回数はサーバーが持っている設定で確認します。参加者の画面から判定結果を書き換えることはできません。
「範囲・期間・回数」の3つを同じ場所で見ている、と明記されているのが要点です。範囲だけサーバーで見て、期間の判定をクライアントに置く、という混在をやると、期限切れのラリーに押せてしまいます。
課金の観点でも、押印イベントがサーバーに集約されていることが前提になります。クライアントが「押しました」と申告する形だと、課金対象の数を自己申告で作れてしまいます。
防げないものを、仕様に書く
興味深かったのは、限界も書いてあった点です。
位置情報を偽装するアプリを使われた場合は、GPSだけで完全に防ぐことはできません。
そのうえで、QRコードの併用・達成後の現地引き換え・押印の時刻や順序の確認、という運用側の対策が挙げられていました。
サーバー側判定で守れるのは「クライアントから判定結果を書き換えられないこと」であって、「クライアントが送ってくる位置が本物であること」ではありません。この2つは別物です。前者は設計で担保でき、後者は端末の外側の問題なので設計では閉じません。
ドキュメントでこの線を引いているかどうかは、そのサービスの設計を信頼できるかの目安になります。
上限に達したときの設計
人数課金には、上限に触れたときの振る舞いという論点もあります。
このサービスは、開催中でも上位の枠へ差額のみで変更でき、決済確認後に自動で枠が広がる、という形でした。ダウングレードはできません。
課金の設計として見ると、アップグレードのみ・差額精算・即時反映という組み合わせです。返金処理を持たずに済み、差額計算も単純な引き算になります。「小さく買って必要なら足す」に利用者を誘導する形なので、過大な枠を最初に売らない設計とも言えます。
まとめ
従量課金を設計するときのチェック項目として、今回読んだ内容はそのまま流用できます。
- 1件の定義を、利用者に1文で説明できるか
- その定義は、サーバー側のイベントだけで数えられるか
- 告知の成否と請求額が連動していないか
- 判定の範囲・期間・回数が、同じ場所で評価されているか
- 設計で閉じない部分(端末の外側)を、ドキュメントに明示しているか
- 上限に触れたときの操作が、返金を伴わない方向に設計されているか
値段を決めるより先に、この6つを埋める。順番としてはそちらが先だと思います。
本ページはプロモーションが含まれています
Top comments (0)