A&A INSIGHTS
一人開発のAIサービスで無料体験を出す前に：試せる仕事と利用上限を決める
無料体験の「14日間」は請求を止めるだけで、推論費用は止まりません。一人でAIサービスを作る開発者に向けて、期間・実行量・終了時の扱いを別々の制御として決める手順を、Stripeの無料体験仕様とCloudflare AI Gatewayのレート制限という一次資料から組み立てます。
Read in English
この記事の要点
未課金の利用者にも同じ生成処理を開放しようとしている、一人開発のAIサービスの創業者に向けた記事です。Stripeの無料体験の仕様と、Cloudflare AI Gatewayのレート制限の仕様を読み合わせ、無料体験が止めているのは請求であって利用ではないこと、レート制限が抑えているのは速さであって通算量ではないことを確かめます。その上で、上限の単位を「完了した一件の仕事」に置き、期間終了時の扱いを解約・一時停止・請求書の三つから選ぶ手順と、公開前に確定させる六つの設定を提案します。出典の記述、A&Aの解釈、架空の設定例は区別しています。推奨する日数や件数、導入効果は示しません。
「14日間無料」は、推論費用の上限ではない
A&Aの考え方
一人でAIサービスを作っていて、未課金の利用者にも同じ生成処理を開放しようとしている段階の話です。無料体験の設計と聞くと、まず「何日間にするか」を決めたくなります。しかし日数は、課金基盤の中にある制御です。推論を何回動かしてよいかという制御は、そこにはありません。この二つを一つの設定で兼ねようとすると、利用者への約束と、自分に届くAPI請求がずれます。この記事では、期間、実行量、終了時の扱いの三つを別々に決める手順を、StripeとCloudflareの一次資料から組み立て、最後に登録フローまで含めた六つの設定にまとめます。
出典に基づく事実
従来の無料体験の資料は、新しい実装を作るなら「トライアルオファー」を使うことを推奨する、と明記しています。そのトライアルオファーの資料は、トライアルオファーによって、意図の強い見込み客を選別し、trial abuse（試用の悪用）を減らし、限られた期間だけ割引価格を提供できる、と説明しています。ただしこのページは公開プレビューの段階で、リクエストヘッダで2026-03-25.previewを指定し、サブスクリプションのbilling modeをflexibleにする必要があると書かれています。またトライアルオファーを使えない統合としてCheckout、Payment Links、Checkout Sessionsと組み合わせたElementsが挙げられており、Checkoutについては従来の無料体験（trial_end）を使うよう案内されています。
出典に基づく事実
従来の方法を説明する資料では、サブスクリプションの作成時にtrial_end（終了時刻のタイムスタンプ）またはtrial_period_days（日数）を渡すと無料期間を始められると書かれています。無料期間は730日（2年）以下でなければなりません。無料期間つきでサブスクリプションを作るときは支払方法を登録する必要がなく、金額0の請求書が即時に作られると説明されています。
出典に基づく事実
同じ資料の従量課金に関する節には、Stripeは試用期間中に記録された利用量を請求しないが、その利用量はメーターイベントの集計で確認できる、と書かれています。そして試用期間が終わると、記録されていた利用量の請求が再開します。
A&Aの考え方
この二つを並べると、無料体験が止めているのは「顧客への請求」であって「利用そのもの」ではないことが分かります。A&Aの読み取りでは、ここが個人開発でいちばん見落とされる境目です。利用量は記録され続けており、記録されているということは、その裏で実際に推論が動いているということです。顧客の請求書が0であることと、自分のAPI明細が0であることは、まったく別の話です。
実行量の上限は、課金基盤の外側に置く
出典に基づく事実
Cloudflare AI Gatewayのレート制限の資料は、レート制限を「アプリケーションに到達するトラフィックを制御し、高額な請求と不審な活動を防ぐもの」と説明しています。上限は「特定の時間枠の中で送信されるリクエスト数」として定義でき、例として60秒あたり100リクエストという指定が挙げられています。
出典に基づく事実
同じ資料は、固定窓とスライディング窓を区別しています。10分あたり10リクエストという制限を12:00から始めた場合、固定窓は12:00〜12:10、12:10〜12:20と区切られるため、12:09に10件、12:11に10件を送ると合計20件がすべて成功します。スライディング窓では直近10分に10件を超えるので失敗します。上限を超えたリクエストには429 Too Many Requestsが返り、そのリクエストは処理されません。APIで既定のレート制限を設定する場合は、新しいゲートウェイを作成するPOSTリクエストにrate_limiting_interval、rate_limiting_limit、rate_limiting_techniqueの値を含める、と書かれています。
A&Aの考え方
この仕様から読み取れるのは、レート制限が「速さ」の制御であって「通算量」の制御ではない、ということです。窓が明ければ上限は戻ります。ところが無料体験で必要になるのは、多くの場合「通算で何件まで」という累計の上限です。60秒あたり5リクエストという設定は、一日中使い続ける利用者を止めません。累計を止めたいなら、ゲートウェイのレート制限とは別に、自分のアプリケーション側に消化数のカウンタを持つ必要があります。これはA&Aの設計上の読みで、出典が述べている主張ではありません。
A&Aの考え方
もう一つ、レート制限が効くのはゲートウェイを経由した呼び出しだけです。管理画面のバッチ処理や社内スクリプトがモデルのAPIを直接叩いている経路があるなら、その分は数えられていません。無料体験の上限を設計するときは、どの経路が計測対象に入っているかを先に一覧にしてください。
| 決める項目 | どこで設定する制御か | 決めていないと起きること |
|---|---|---|
| 無料で試せる一件の仕事の定義 | 自分のアプリケーション（課金基盤にもゲートウェイにもない） | 利用者が何を試せるのか分からず、登録しても最初の一件が完了しない |
| 無料で許す通算件数 | 自分のアプリケーションの消化数カウンタ | 窓が明けるたびに上限が戻り、一人あたりの原価に天井がなくなる |
| 単位時間あたりのリクエスト上限 | ゲートウェイのレート制限（時間枠とリクエスト数） | 短時間の連打や自動化されたアクセスで、一日の請求が跳ねる |
| 期間の長さと終了時の扱い | 課金基盤の試用設定（解約・一時停止・請求書） | 期間が終わっても止まらない、あるいは黙って消えて再訪の導線が切れる |
| 終了前の通知の時期と経路 | 課金基盤のリマインダー設定（自動送信できる分と、自分で作る分の切り分け） | 請求が突然届いたと受け取られ、返金対応と解約が同時に発生する |
| アカウントを一つ作る手間 | 登録フロー（本人確認やcaptchaの有無） | 上限が一人あたりで効かなくなり、複数アカウントで原価が掛け算になる |
上限の単位を「リクエスト」ではなく「一件の仕事」にする
A&Aの考え方
リクエスト数で上限を書くと、利用者には意味が伝わりません。「20リクエストまで無料」と言われて、自分が何をどこまで試せるのか分かる人はいません。しかも1回の価値ある体験は、たいてい複数のリクエストでできています。前処理、本処理、やり直し、書き直しの依頼。内部の呼び出し回数は実装の都合で変わるので、そこを顧客との約束の単位にすると、実装を直すたびに約束が動きます。
A&Aの考え方
A&Aの提案は、上限の単位を「完了した一件の仕事」に置き、リクエスト数は原価側の指標として内部にとどめることです。一件とは、利用者が「できた」と言える成果物が一つ出るまでの一連の処理です。そのうえで、一件あたりに許すやり直しの回数を決めます。やり直しを無制限にすると、一件の原価が上限を持ちません。
仮想例
架空の例で確かめます。会議の録音から議事録を作るサービスを一人で作っているとします。一件の仕事を「60分以内の音声ファイル1本から、議事録1本を出すまで」と定義します。内部では文字起こし1回、要約1回、体裁の整形1回が走り、利用者が押せる「作り直し」は一件につき2回まで、とします。無料体験で許す仕事は通算3件。作り直しが文字起こしを再実行せず要約以降だけをやり直す実装なら、一人あたりの最大原価は音声3時間分の文字起こしと要約9回分に収まります。文字起こしからやり直す実装なら、同じ設定でも文字起こしは三倍になります。この前提を書き出さないと、上限の意味が変わります。数字はすべて説明のための仮のもので、A&Aの実測値ではありません。
体験が終わった瞬間の扱いを、三つから選ぶ
出典に基づく事実
支払方法を集めずに無料体験を始めた場合、期間が終わったときの動作をStripeの資料はtrial_settingsのend_behavior.missing_payment_methodで指定できると説明しています。cancelを指定すると、支払方法がないまま無料体験が終わった時点で即座に解約されます。pauseを指定すると一時停止し、請求サイクルが進まず、請求書も生成されません。顧客が後から支払方法を追加すれば同じサブスクリプションを再開でき、一時停止のまま無期限に置いておくこともできます。create_invoiceを指定すると期間終了時に請求書を発行し、確定時に支払方法がなければサブスクリプションはpast_dueに移ります。
出典に基づく事実
同じ資料は、試用がtrialingからactiveに移る数日前にcustomer.subscription.trial_will_endイベントが届くとし、これを受け取った時点で顧客の口座に請求できる支払方法があるか確認し、必要なら今後の請求について事前に知らせることを勧めています。加えて同じ資料は、無料体験のメッセージ設定から支払情報を集めるリマインダーメールを設定できるとし、顧客の試用がまもなく終わるときに自動でリマインダーメールを送るようサブスクリプションを設定できる、と書いています。
A&Aの考え方
三つの選択は、利用者に何を残すかの選択でもあります。解約は関係を切り、一時停止は設定と履歴を残したまま止めます。A&Aの読みでは、AIサービスの無料体験は一時停止のほうが合う場面が多いはずです。試用のあいだに利用者が作った文脈、たとえば用語集や出力の好みの設定は、その利用者にとっての乗り換え費用そのものだからです。それを消してしまうと、後で戻ってきたときに最初からやり直しになります。ただし一時停止を選ぶなら、停止中のアカウントがいつまで残るのかを自分で決めて、利用規約に書いておく必要があります。仕様として無期限に置けることと、無期限に置くべきことは別です。
支払方法を求めないと、上限はアカウント数で掛け算になる
出典に基づく事実
Stripeの資料は、支払方法を集めずに無料体験を始めることについて注意を添えています。支払方法なしで無料体験を始められるようにすると見込み客は速く製品を試せる一方で、スパマーが大量の偽の顧客、利用、サブスクリプションを作ることも可能にしてしまう、という指摘です。そのうえで、本物の顧客には簡単で、スパムには難しい申込フローを慎重に考えるよう勧め、例として無料体験を始める前にユーザーアカウントの作成とcaptchaの完了を求めることを挙げています。
A&Aの考え方
ここが、実行量の上限を「一人あたり」で考えているときに崩れる場所です。上限が一人3件でも、アカウントを10個作られれば30件です。レート制限もアカウントやキーの単位で効くので、同じ理屈で薄まります。A&Aの整理では、決めるべき数字は二つあります。一人あたりの上限と、新しいアカウントを一つ作る手間です。前者だけを下げると本物の利用者の体験が痩せ、後者を上げすぎると試してもらえません。どちらを動かすかは、一件あたりの原価が自分にとっていくらかで決まります。
公開前に確定させる六つの設定
A&Aの考え方
ここまでを、無料体験を公開する前に確定させる六つの設定にまとめます。前節までの比較表の各行に、そのまま対応します。第一に、無料で試せる一件の仕事の定義と、一件あたりのやり直しの上限。第二に、無料で許す通算件数。第三に、単位時間あたりの上限と、それを超えたときに画面へ出す文言。第四に、無料期間の長さと、期間が終わったときの扱い（解約か、一時停止か、請求書の発行か）、そして一時停止を選んだ場合にデータを保持する期間。第五に、終了前に何日前、どの経路で知らせるか。このとき、課金基盤の設定で自動送信できる分と、自分で作る必要がある分を分けて書きます。第六に、アカウントを一つ作る手間をどこまで課すか（本人確認やcaptchaを挟むかどうか）。第一と第二は自分のアプリケーションの中、第三はゲートウェイ、第四と第五は課金基盤、第六は登録フローにあります。六つが決まっていれば、料金ページと利用規約はそこから書けます。決まっていないものがあるなら、公開はそれが決まるまで待つほうが安全です。
仮想例
架空の記入例です。一件の仕事は「60分以内の音声1本から議事録1本」、やり直しは一件につき2回まで。無料の通算は3件。単位時間あたりは1時間に1件までとし、超えた場合は「あと何分で次の1件を開始できます」と残り時間を表示する。期間は14日で、終了時は一時停止を選び、停止中のデータは90日保持して、90日を過ぎたら削除する。終了の3日前のリマインダーは課金基盤の設定に任せ、当日のアプリ内通知だけを自分で作る。アカウント作成にはメール確認とcaptchaを挟み、同一ドメインの連続作成には間隔を置く。これらはすべて説明のための仮の値で、推奨値でも実測値でもありません。自分の一件あたりの原価を出してから、同じ六つを自分の数字で決めてください。
この記事が保証しないことと、次の一歩
A&Aの考え方
限界を四つ書いておきます。第一に、引用したStripeとCloudflareの記述はどちらもベンダー自身の技術文書であり、独立した監査でも効果の測定でもありません。仕様が正しく動くことと、その設計が自分の事業に合うことは別です。第二に、Stripeのトライアルオファーのページは公開プレビューの段階で、対応バージョンや使えるUI統合の条件は変わりえます。実装に入る直前に必ず最新の資料を読み直してください。第三に、Cloudflareのレート制限はゲートウェイを通る呼び出しにしか効かず、1リクエストあたりのトークン消費量を抑えるものでもありません。なお同じドキュメントの機能一覧には、レート制限とは別にspend limits（ベータ表記）という項目が並んでいます。累計の支出に関わる可能性のある機能ですが、本稿ではその内容を読んでおらず、動作については何も述べません。第四に、本文の数値例はすべて架空の設定で、A&Aが観測した原価、成約率、継続率ではありません。
A&Aの考え方
次の一歩は、六つのうち何個が決まっていないかを数えることです。決まっていないのが第三と第五だけなら、実装の作業が残っているだけです。第一、つまり一件の仕事の定義が決まっていないなら、無料体験の設計ではなく製品の設計に戻ってください。何を一件と呼ぶかが決まっていないサービスは、有料プランの説明も書けません。上限の設計は、商品の輪郭が決まってから初めて意味を持ちます。無料体験の先にある有料プランの説明を組み立てる段階なら、「AI SaaSのクレジット制をどう説明するか：使える量と追加支出を見せる」で、付与・失効・残量の見せ方を扱っています。顧客獲得から継続までの全体像は「AIネイティブGTMとは？一人・少人数で顧客獲得から継続まで回す実践ガイド」にまとめてあります。
無料体験の設計は日数から始まりません。期間は請求を止め、レート制限は速さを抑えますが、どちらも「無料で何件まで動かせるか」を決めてはくれません。試せる仕事の単位、無料の通算件数、窓あたりの上限、期間と終了時の扱い、終了前の通知、アカウントを作る手間。この六つを公開前に自分の言葉で決めておけば、利用者は何を試せるのかを読んで分かり、自分は一人あたりの最大原価を先に知れます。決めずに公開したものは、翌月のAPI請求と問い合わせとして戻ってきます。
出典・編集情報
記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。
- Use free trial periods on subscriptions | Stripe Documentation
Stripe · n.d.
確認日 2026-09-24 - Configure trial offers on subscriptions | Stripe Documentation
Stripe · n.d. (public preview)
確認日 2026-09-24 - Rate limiting · Cloudflare AI Gateway docs
Cloudflare · Last updated Jun 5, 2026
確認日 2026-09-24
AIを活用した記事制作
調査・執筆・翻訳・編集上の確認にAIを活用しています。資料に基づく事実、A&Aの考え方、仮想例は、それぞれ本文に明記しています。
編集上の確認日: 2026-09-24