A&A INSIGHTS
従量課金の実装を請けるとき：計測もれと二重計上を、誰がいつ直すか決める
従量課金の実装で請求額がずれたとき、誰が調べて誰が直すか。計測もれ・二重計上・締め後到着は気づける主体が違うため、見積書には三行に分けて書きます。Stripeの利用量記録の仕様とLovableの公開事例から整理しました。
Read in English
この記事の要点
計測もれ・二重計上・締め後到着を、一つの条項でまとめて引き受けないでください。決済基盤が知らせてくれるのは「不正なイベント」だけで、送らなかったイベントと二回送ったイベントは基盤から見れば正常なので、受託側が自分の台帳と突き合わせる以外に気づく方法がありません。
答え：三つの失敗は「誰が気づけるか」が違う
A&Aの考え方
計測もれ・二重計上・締め後到着を、「請求のずれは対応します」という一つの条項でまとめて引き受けないでください。決済基盤が知らせてくれるのは「不正なイベント」だけです。送らなかったイベントと、二回送ったイベントは、基盤から見ればどちらも正常です。だから受託側が自分の台帳と突き合わせる以外に、気づく方法がありません。
A&Aの考え方
気づける主体が違えば、直す責任の置き場所も変わります。基盤が不正だと言ってくれる失敗は、通知を受けて送り直す処理を作れば終わります。基盤が何も言わない失敗は、受託側が件数を数え続ける仕組みを作らないかぎり、顧客からの指摘が唯一の検知手段になります。顧客からの指摘が検知手段である失敗は、必ず信用の問題として戻ってきます。
A&Aの考え方
だから見積書に書くのは一行ではなく三行です。失敗の種類ごとに、検知の方法、訂正の期限、訂正作業を誰の時間で行うかを分けて書きます。以下はその三行の中身と、三行に分ける必要がない場合の見分け方です。
遅れは不具合ではなく、仕様として書かれている
出典に基づく事実
Stripeの利用量記録の資料は、集計が非同期であることを明記しています。「Stripe processes meter events asynchronously, so aggregated usage in meter event summaries and on upcoming invoices might not immediately reflect recently received meter events.」（Stripeはメーターイベントを非同期に処理するため、メーターイベントの集計や次回の請求書に出る利用量は、直前に受け取ったイベントをすぐには反映しないことがある）。
出典に基づく事実
同じ資料は、記録の頻度を実装側が決めるものとしています。「You can decide how often you record usage in Stripe, for example as it occurs or in batches.」（Stripeへ利用量を記録する頻度は実装側が決められる。たとえば発生ごとでも、まとめてでもよい）。発生ごとに送るかまとめて送るかは、基盤が課す制約ではなく、受託側が選ぶ設計です。
A&Aの考え方
この二つを並べると、請求額が「その時点で届いている分」でしかないことが分かります。顧客が「今日使った分が請求書に出ていない」と言ったとき、それは不具合ではなく、資料に書かれたとおりの挙動です。ただし、資料にそう書いてあることと、顧客がそれを了解していることは別です。了解を作るのが仕様説明の仕事です。
A&Aの考え方
ここで注意したいのは、遅れを仕様として説明しても、それだけでは何も解決しないことです。「遅れます」と伝えた先に、どこまでの遅れを正常として扱い、どこからを訂正の対象にするかの線が必要になります。その線を引くために、失敗を三つに分けます。
| 失敗の種類 | 基盤から来る信号 | 受託側が用意する検知と、訂正の置き場所 |
|---|---|---|
| 計測もれ（送らなかった） | なし。基盤は本来何件届くべきだったかを知らない | アプリ側に残した送信予定の合計と、基盤側の集計値を日次で比較する。35暦日の内側なら同じ経路で送り直して訂正する |
| 二重計上（二回送った） | なし。重複は不正ではないので、正常なイベントとして集計に入る | 発生後の検知はできない。実装前に冪等キーの定義を決めるのが唯一の対策。打ち消しで収まらない過大分は請求書側へ回す |
| 締め後到着（遅れて届いた） | 35暦日を越えた分は不正として通知される。内側の遅れには信号がない | 内側で遅れた分は突き合わせで拾う。期限は顧客の帳簿訂正の締切と35暦日の短いほうを日付で書く |
基盤が知らせてくれるのは「不正なイベント」だけ
出典に基づく事実
同じ資料は、メーターイベントに誤りがあった場合に基盤側がイベントを発行すると説明しています。ひとつは「This event occurs when a meter has invalid usage events.」（メーターに不正な利用イベントがあるときに発生する）、もうひとつは「This event occurs when usage events have missing or invalid meter IDs.」（利用イベントのメーターIDが欠けている、または不正であるときに発生する）です。
出典に基づく事実
資料は不正と判定される理由の一覧も載せています。タイムスタンプが過去に遠すぎる場合、未来になっている場合、顧客が見つからない場合、値が欠けている場合、値が不正な場合などが別々に挙げられています（ページ上では下線でつながれた識別子として書かれているため、ここでは意味だけを訳しています）。
出典に基づく事実
そして資料は、その後の作業を実装側の仕事として明示しています。「Correct and resend invalid events for re-processing.」（不正なイベントは訂正し、再処理のために送り直す）。通知を受け取った側が直す、という分担がここで決まっています。
A&Aの考え方
ここがこの記事の出発点です。基盤は「届いたが不正だったイベント」については知らせてくれて、しかも直す責任が実装側にあることまで書いています。裏を返せば、基盤が知らせてくれる範囲はそこまでです。届かなかったイベントについて、基盤は知らせる材料を持っていません。これは資料に書かれた記述ではなく、書かれていないことからのA&Aの読みです。
二重計上は、設計時にしか防げない
出典に基づく事実
資料は重複の防止を実装側の責任として書いています。「Use idempotency keys to prevent reporting usage for each event more than one time because of latency or other issues.」（遅延やその他の問題によって、同じイベントの利用量を複数回報告してしまうことを防ぐために、冪等キーを使う）。
出典に基づく事実
続けて資料は、識別子を指定しない場合の挙動も書いています。「If you don’t specify an identifier, we auto-generate one for you.」（識別子を指定しない場合は、こちらで自動生成する）。つまり冪等キーを設計しないという選択も通ります。
A&Aの考え方
資料は識別子について「Every meter event corresponds to an identifier that you can specify in your request.」（すべてのメーターイベントは、リクエストで指定できる識別子に対応する）としたうえで、重複を防ぐには冪等キーを使えと指示しています。この並びからA&Aが読み取るのは単純なことです。自動生成に任せれば重複が防がれるのなら、その指示は要りません。つまり自動生成に任せた場合、同じ利用実績を二回送ると、基盤から見れば別のイベントが二件届いただけになります。不正ではないので、前節の通知は飛びません。重複は正常なイベントとして集計に入ります。
A&Aの考え方
だから二重計上は、検知の問題ではなく設計時の一回の決定です。何を同一の利用実績とみなすか、つまりどの業務上の単位をキーにするかを実装前に決めておけば発生せず、決めずに進めれば、後から基盤の側では気づけません。見積書の二重計上の行に書くのは「調査します」ではなく、キーの定義そのものです。
A&Aの考え方
ここは顧客と言葉を合わせる必要がある場所でもあります。「同じ処理」が何を指すかは業務の言葉で決まります。同じ依頼への再試行を一件と数えるのか二件と数えるのかは、キーの作り方で決まってしまうので、実装の都合で決めずに、顧客の数え方に合わせます。
計測もれには、外からの信号がない
A&Aの考え方
計測もれは、受託側のコードが基盤を呼ばなかった失敗です。送信処理が落ちていた、例外で抜けた、再試行が尽きた、キューが詰まった。どれも基盤の外で起きるので、基盤には知らせる材料がありません。
出典に基づく事実
資料が記録の頻度を実装側の判断としている以上（「You can decide how often you record usage in Stripe, for example as it occurs or in batches.」）、基盤は「本来何件届くべきだったか」を知りません。期待件数を知らない相手は、欠けた件数を報告できません。
A&Aの考え方
したがって計測もれの検知手段は、受託側が持つ二つ目の数えしかありません。自分のアプリケーション側に「送るべきだった分」を合計で残し、基盤側の集計値と毎日突き合わせます。資料が「aggregated usage in meter event summaries」（メーターイベントの集計に出る利用量）と書いているとおり、集計された値は基盤側にあります。足りないのは基盤側の数字ではなく、それと比べる相手です。この突き合わせは実装でもあり、運用でもあります。
A&Aの考え方
この運用を見積書に載せないと、そのまま無償の作業になります。載せ方は二通りあります。突き合わせの仕組みを作る工数を構築費に含め、毎日見て差分を調べる作業を運用の有償範囲として別に切り出すか、あるいは突き合わせの画面を顧客側の業務として引き渡し、差分が出たときの調査だけを時間清算で請けるか。どちらでもよいのですが、決めないという選択はありません。
A&Aの考え方
顧客からの指摘を検知手段にしてはいけない理由も、ここで書いておくべきです。顧客が気づくのは請求書を見たときで、それは締めの後です。締めの後に見つかった計測もれは、次節の訂正の制約に直接ぶつかります。
締め後到着は、判断ではなく日付の計算
出典に基づく事実
資料はタイムスタンプに有効範囲を定めています。「Make sure the timestamp is within the past 35 calendar days and isn’t more than 5 minutes in the future.」（タイムスタンプは過去35暦日以内で、未来方向は5分を超えないこと）。5分の未来許容については「The 5-minute window is for clock drift between your server and Stripe systems.」（この5分は、自社サーバーとStripeのシステムとの間の時計のずれのため）と説明されています。
A&Aの考え方
つまり締め後到着は二つに割れます。35暦日の内側に収まる遅れは、正しいタイムスタンプのまま受け付けられます。35暦日を越えた遅れは、この経路では送れず、不正として通知されます。前者は訂正が効き、後者は訂正の経路そのものがありません。
A&Aの考え方
見積書に書くのは「どのくらい遅れたら対応するか」という判断基準ではなく、日付の計算です。顧客の締めが月末で、訂正の受付を翌月の何日までとするか。その期限が35暦日の内側に収まっているか。収まっていなければ、期限ではなく経路を先に設計し直す必要があります。
A&Aの考え方
ここは顧客の会計の締めと噛み合わせる場所です。受託側が技術的に送れる期限と、顧客が帳簿を直せる期限は別物で、短いほうが実際の期限になります。どちらが短いかを確認しないまま「35日以内なら直せます」と書くと、守れない約束になります。
多く数えた訂正と、少なく数えた訂正は別の作業
出典に基づく事実
資料は負の利用量について明記しています。「If the overall cycle usage is negative, Stripe reports the invoice line item usage quantity as 0.」（その請求サイクル全体の利用量が負になる場合、Stripeは請求明細の利用量を0として報告する）。値そのものは小数を取れるとされており、「The numerical usage value in the payload accepts decimal values.」と書かれています。
A&Aの考え方
この一文が効いてくるのは、打ち消しの範囲です。差し引きのイベントを送って直せるのは、そのサイクル全体の利用量が正のままで収まる範囲までです。それを越えてサイクル全体が負に振れると、請求明細の利用量は0として報告されます。0は返金ではありません。
A&Aの考え方
だから過大計上と過小計上は、同じ条項に入れてはいけません。過小計上は、35暦日の内側であれば同じ利用量の経路で送り直して直せます。過大計上が利用量の経路で戻せるのは、同じサイクルの中で打ち消せる範囲までです。その範囲を越えた分と、すでに請求が出てしまったサイクルの分は戻りません。だから過大計上には、請求書側の訂正という別の経路を先に用意しておく必要があります。これは別のシステムであり、たいていは別の担当者です。
A&Aの考え方
見積書への影響は具体的です。過小計上の訂正は、受託側が自分のコードと経路の中で完結できるので、構築費と運用費の範囲に収まります。打ち消しで収まらない過大計上の訂正は、顧客側の請求業務と会計処理に入っていくので、受託側が引き受けられるのは「どのイベントが過大だったかを特定して渡すところまで」です。その線を引かずに「請求のずれは直します」と書くと、顧客の経理作業まで引き受けたことになります。
A&Aの考え方
なお、請求書側で訂正するという進め方はA&Aの提案です。出典は、サイクル全体の利用量が負になる場合に請求明細の利用量が0として報告されるという挙動を書いているだけで、その場合にどう訂正すべきかは何も述べていません。
公開事例が示すのは、「定義」までが速いということ
出典に基づく事実
StripeがLovableについて公開している事例ページは、同社がLovable CloudとLovable AIの提供にあたって従量課金の機能を使い、二週間で「to define meters and rate cards」（メーターとレートカードを定義する）ところまで進み、「automatically bill customers for actual consumption」（実際の消費量に応じて顧客へ自動的に請求する）に至ったと述べています。ページの数値欄には「2 weeks to implement usage based billing」と書かれています。
出典に基づく事実
同じページは規模にも触れており、「4.6 million credits being granted every month」（毎月460万クレジットが付与されている）としています。これはStripeが自社の顧客事例として公開した記述であり、独立した監査ではありません。
A&Aの考え方
この記述を受託の工数の根拠にはできません。読み取れるのは、速かったのが「定義」と「自動請求の開通」だということです。メーターを決め、レートカードを決め、消費量に応じて請求が出るようにする。ここは基盤が引き受けてくれる部分です。
A&Aの考え方
一方、ここまで扱ってきた三つの失敗の分担は、この事例ページには出てきません。出てこないことが問題なのではありません。基盤が速くしてくれる部分と、受託側が決めなければ誰も決めない部分が別だということです。そして見積もりで削られやすいのは後者です。
A&Aの考え方
自社サービスとして作るLovableの立場と、他社のサービスに実装する受託の立場は、ここで分かれます。自社なら請求のずれの調査も自社の仕事で、費用の出所は同じ財布です。受託なら、その調査が誰の時間なのかを先に決めないかぎり、納品後に無償で出てきます。
見積書に足す三行の中身
A&Aの考え方
三行はどれも同じ三項目を持ちます。検知の方法、訂正の期限、訂正作業を誰の時間で行うか。項目をそろえておくと、顧客側でも比較して読めます。
A&Aの考え方
計測もれの行。検知は受託側が作る突き合わせで、アプリ側に残した送信予定の合計と、基盤側の集計値を日次で比べます。期限は、顧客の帳簿訂正の締切と35暦日のうち短いほう。担当は、突き合わせの実装が構築費、毎日の確認と差分調査が運用費です。
A&Aの考え方
二重計上の行。ここには検知ではなく定義を書きます。何を同一の利用実績とするかのキーと、その業務上の根拠。あわせて、発生後の検知手段が基盤側にないことも明記します。担当は、キーの設計が構築費。定義の変更が必要になった場合は仕様変更として別扱いにします。
A&Aの考え方
締め後到着の行。検知は二経路あり、35暦日を越えた分は基盤からの不正通知、内側で遅れた分は突き合わせで拾います。期限は判断基準ではなく日付で書きます。担当は、通知を受けて送り直す処理が構築費、期限を過ぎた分の扱いは顧客の会計判断です。
A&Aの考え方
そして三行の下に、過大計上についての一行を足します。過大計上は利用量の経路では戻らないので、受託側の責任範囲は過大だったイベントの特定と引き渡しまでであること。請求書側の訂正は顧客の業務であること。この一行がないと、前の三行は「全部直します」と読まれます。
架空の例：「使った分だけ請求したい」を三行に割る
仮想例
以下は架空の設計例です。A&Aの実案件ではなく、発生率や成果を示すものでもありません。顧客は画像の自動補正をサービスとして売っている会社で、受託側は「補正を一枚通したら一件」で請求する仕組みの実装を請けたとします。
仮想例
二重計上の行から決めます。同一の利用実績を「補正ジョブのID一つ」と定義し、冪等キーにそのIDを使う。ここで顧客に確認するのは、利用者が同じ画像をやり直した場合の数え方です。顧客が「やり直しは課金しない」と言うなら、キーはジョブIDではなく、画像IDと版の組になります。この確認を先にしておかないと、実装の都合で数え方が決まってしまいます。
仮想例
計測もれの行は突き合わせで埋めます。補正の完了を自分のデータベースに一行ずつ残し、その日の合計と、基盤側の集計値を翌朝比べる。差分が出たら、残っている行のうち送信済みの印がないものを送り直す。この「翌朝の比較と送り直し」を運用費の対象として書き出します。
仮想例
締め後到着の行は日付で埋めます。顧客の締めが月末、帳簿の訂正受付が翌月5日までだとすると、受託側の訂正期限は翌月5日です。35暦日のほうが長いので、実際の期限は顧客の会計が決めています。5日を過ぎて見つかった分を翌月の利用量として扱うのか、請求書側で処理するのかを、顧客の経理と先に決めておきます。
仮想例
最後に過大計上の一行です。やり直しの数え方を後から変えた結果として過去分が過大だったと分かった場合、受託側は過大だったジョブIDの一覧を出すところまでを請ける。その一覧をもとにクレジットを出すのか次回請求で調整するのかは、顧客の請求業務として残します。
A&Aの考え方
この例で重要なのは、三行のうち二行が実装ではなく確認で埋まっていることです。二重計上のキーと、訂正受付の期限は、どちらも顧客に聞かないと決まらず、聞けば決まります。見積もり前の一回の打ち合わせで終わる作業が、決めないままだと納品後の無償調査になります。
この整理が当てはまらない場合と、主張しないこと
A&Aの考え方
まず反例です。計測の単位が受託側の作るシステムの内側で生まれ、しかも取引として確実に保存されている場合、この三行は作りすぎです。
A&Aの考え方
たとえば完了したジョブが一行ずつ自分のデータベースに残るなら、計測もれは「送信処理が動いたか」だけに縮みます。日次の合計を一つ比べれば足ります。三行に分けた運用を設計して維持するほうが、起きる問題より高くつきます。その場合は「毎日の合計比較を一本だけ入れる」と書くのが誠実です。
A&Aの考え方
三行が費用に見合うのは、計測のもとになる出来事が受託側の管理外で起きるときです。顧客の既存システムが発火元である、第三者からのWebhookを数える、利用者の端末側の操作を数える。こうした場合は、後から真実を再構成できないので、起きた時点で拾う仕組みが必要になります。
出典に基づく事実
次に出典の条件です。35暦日、未来5分、そして顧客ごとの組み合わせ上限（資料は「For each customer on a meter, Stripe accepts up to 100 unique combinations across all events.」とし、上限に達した後に新しい組み合わせを持ち込むイベントについては「Events that introduce a new dimension combination after either limit is reached are invalid」としています）は、いずれも2026年10月3日に読んだ時点の記述です。
出典に基づく事実
同じ資料は、基本的な従量課金とMetronomeを比べる案内を持ち、さらに毎秒1万件まで送れるAPI v2のメーターイベントストリームという別の経路も説明しています。どの経路を使うかで制約は変わります。実装の直前に現行の資料を読み直してください。
A&Aの考え方
主張しないことを並べます。本文の三行の分担、検知の置き場所、過大計上を請求書側で扱うという進め方は、すべてA&Aの設計です。出典はいずれも契約、見積もり、検収、訂正の期限、調査時間の負担者について何も述べていません。
A&Aの考え方
訂正の期限と責任分担は、顧客の会計処理と、顧客が自分の利用者と結んでいる契約に依存します。返金や再発行が法的に可能かどうかはA&Aが判断する範囲ではなく、読者が自身の顧問に確認する事項です。Lovableの二週間は同社の体制での記述であり、受託の工数見積もりの根拠にはなりません。A&Aは所要日数の目安を示しません。
A&Aの考え方
A&Aの実案件での請求ずれの発生率、調査件数、訂正件数は示しません。価格水準も示しません。本文の数値例は架空のシナリオです。
次の一歩：いま請けている一件の見積書に、三行を足す
A&Aの考え方
手元の従量課金の案件を一件開いて、見積書に三行を足してください。各行に、検知の方法、訂正の期限、担当を書きます。書けない欄が出たら、それは顧客に聞いていない項目です。
A&Aの考え方
書けない欄のうち、二重計上のキーの定義と、訂正受付の期限は、顧客との一回の確認で埋まります。先に埋めるほど安く、納品後に埋めるほど高くつきます。
A&Aの考え方
計測の設計を含むサービス構築のご相談は、開発のご相談として承っています。隣接する判断としては、数え方そのものの定義を扱った「AIエージェントの成果課金を始める前に：「完了一件」をどう数えるか」、顧客への開示を扱った「AI SaaSのクレジット制をどう説明するか：使える量と追加支出を見せる」、納品後の運用分担を扱った「AIの仕組みを納品したあと、止まった仕事を誰が戻すのか」が参考になります。全体の流れは「AIネイティブGTMとは？一人・少人数で顧客獲得から継続まで回す実践ガイド」にまとめています。
請求のずれは、三つの別々の失敗です。基盤が不正として知らせてくれるものと、受託側が数え続けるしかないものを分け、検知の方法、訂正の期限、担当を三行に書き分けてから見積もってください。そのうえで、同じサイクルで打ち消せる範囲を越えた過大計上は利用量の経路では戻らないため、請求書側の経路も先に決めておいてください。
出典・編集情報
記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。
- Record usage for billing with the API
Stripe · undated documentation page
確認日 2026-10-03 - Riding the AI boom: How Lovable grew into a vibe-coding juggernaut with Stripe
Stripe · undated customer story
確認日 2026-10-03
AIを活用した記事制作
調査・執筆・翻訳・編集上の確認にAIを活用しています。資料に基づく事実、A&Aの考え方、仮想例は、それぞれ本文に明記しています。
編集上の確認日: 2026-10-03