想定キーワード
- AI API 課金 バグ
- SaaS 課金設計
- API 使用量 上限
- Stripe 課金 チェック
- 無料枠 悪用 対策
- AI SaaS 赤字 対策
外部に処理を頼むウェブ上のサービスで怖いのは、ユーザーが使ってくれないことだけではありません。
もっと怖いのは、使われるほど赤字になることです。
別のサービスに文章を書いてもらう仕組み。
別のサービスに画像を作ってもらう仕組み。
別のサービスに録音を文字にしてもらう仕組み。
別のサービスに文章を翻訳してもらう仕組み。
別のサービスに動画を処理してもらう仕組み。\
これらは、1回ごとにコストが発生します。
そのため、課金設計や使用量制限を間違えると、ユーザーが無料で使い放題になり、運営側だけが外部へ払う費用を払い続けることになります。
利用料金の処理に不具合があると、ネット上で使ってもらうソフトを運営するほど損失が増える、ということです。
使われるたびに外部へ払う費用が増える
一般的なネット上のサービスでも、動かしておくコンピューターの費用はかかります。
しかし外部へ料金を払うサービスは、ユーザーの操作ごとに外部へ払う費用が発生します。
たとえば、
ユーザーが生成ボタンを押す
↓
別のサービスに文章などの処理を頼む
↓
運営者に外部へ払う費用が発生する
↓
ユーザーが無料なら売上は0円
この構造では、使用量制限がないと危険です。
ソフトの安全性を扱うOWASPの指針でも、外部に処理を頼むと、計算に使う力、作業中の情報を一時的に保持する場所、結果などを保存する場所、外部へ払う費用が使われ、制限が弱いと運営費用が増えることがあるとされています。
よくある支払いの処理や使える範囲の不具合
1. 登録した本人だと確かめる前に別のサービスへ処理を頼める
サービスの紹介ページやフォームから、登録した本人として入っていない人でも、別のサービスへ文章などを作る処理を頼めてしまう場合です。
ユーザー登録前に試せる体験は便利ですが、制限がないと悪用されます。
2. 決済前に有料処理が走る
「購入する」ボタンの前に、裏側で生成処理が動いている。
または、決済ページに行っただけで処理が予約される。
こうなると、売上なしで外部へ払う費用が発生します。
3. 決済失敗時に権限が付く
Stripeなどの決済で失敗しているのに、アプリ側では有料ユーザー扱いになる。
これは致命的です。
4. 無料枠がリセットされすぎる
メールアドレスを変える。
その人の利用状況などを端末に保存する小さな記録を消す。
別端末で開く。
複数アカウントを作る。
これで無料枠を無限に使えると、外部へ払う費用が膨らみます。
5. 上限超過時の停止処理がない
1日あたり、1ユーザーあたり、通信を送ってきた場所を表す1つの番号あたり、1プロジェクトあたりの上限がない。
この場合、不具合や悪用で大量処理されても止まりません。
必須の課金・上限チェックリスト
□ 登録した本人として入っていない人が、費用の高い処理を別のサービスへ頼めないか
□ 無料ユーザーの1日上限があるか
□ 無料ユーザーの月間上限があるか
□ 有料ユーザーにも合理的な上限があるか
□ 外部に処理を頼む前に権限チェックしているか
□ 決済成功後だけ権限が付くか
□ 決済失敗・キャンセル時に権限が付かないか
□ 二重クリックで二重実行されないか
□ ページの読み直しで再実行されないか
□ 同じ内容を複数のページで同時に処理しても上限を超えないか
□ 異常な連続利用を検知できるか
□ 管理者が一時的に無料枠を閉じられるか
□ 外部へ払う費用が一定額を超えたら警告が出るか
外部に処理を頼む前に見るべき3条件
費用の高い処理を実行する前に、最低限この3つを確認するべきです。
1. 誰が実行するのか
2. その人に実行権限があるのか
3. 今月/今日の上限を超えていないか
このチェックが別のサービスへ処理を頼んだ後だと遅いです。
必ず外部に処理を頼む前に止める必要があります。
支払いと利用できる範囲を確かめてから処理する流れ
ユーザー入力
↓
登録した本人として入っているか確認する
↓
プラン確認
↓
使用量確認
↓
決済が必要なら支払い画面へ
↓
支払い側から届いた成功の通知を確かめる
↓
権限付与
↓
外部に処理を頼む
↓
使用量記録
↓
結果表示
この流れを崩すと、どこかで無料利用や権限漏れが起きやすくなります。
管理者用の緊急停止機能
外部へ料金を払うサービスでは、管理者が緊急停止できる仕組みも必要です。
無料生成を一時停止
費用の高い処理だけ停止
特定ユーザーを停止
特定の通信元を表す番号を制限
1日の全体上限を設定
異常利用時に自動でメンテナンス表示
これは防火扉です。
サービスが成長する前でも、先に作っておいた方が安全です。
まとめ
別のサービスに文章などの処理を頼む仕組みを使った継続料金を払ってネットで使うソフトでは、支払いの処理や使える範囲の不具合がそのまま赤字につながります。
便利な機能を作るだけでは足りません。
- 誰が使えるのか
- 何回使えるのか
- いつ課金するのか
- 決済成功をどう確認するのか
- 上限超過時にどう止めるのか
- 異常利用時にどう閉じるのか
ここまで設計して初めて、安全に公開できます。
外部へ料金を払うサービスは、作るよりも「赤字にならないように使わせる」設計が重要です。
次にできること
外部に処理を頼むウェブ上のサービスを作る場合は、課金・上限・完成条件をチェックリスト化してから公開するのがおすすめです。
