AIエージェントの成果課金を始める前に：「完了一件」をどう数えるか

A&Aの考え方

成果課金で最初に決めるのは単価ではなく、完了一件の定義です。一件として数えてよいのは、顧客が自分の記録を見て「たしかに終わっている」と確認できる変化が起きたときだけです。人への引き継ぎと、対象外と判定した依頼は一件に含めず、消すのではなく別の行として数えて明細に並べます。締めの猶予を過ぎて届いた完了は、除外ではなく翌月の一件として計上します。同じ依頼への再試行は、二回目以降を数えずに一件へまとめ、二重請求を防ぎます。完了後の取り消しは完了として計上したまま取消行で戻し、顧客の記録と突き合わせるための照合キーを一件ごとに持たせます。これがこの記事の答えで、以下はその根拠と、契約前に埋める六行の書き方です。AIが回答した回数をそのまま解決件数として請求すると、再試行や人への引き継ぎが混ざった瞬間に、請求の根拠を説明できなくなります。成果課金の最初の設計は単価ではなく照合できる完了の定義だ、というのはA&Aの編集上の立場であり、特定の価格や契約条件を示すものではありません。

A&Aの考え方

この二つを並べると、成果課金の設計に必要な線が引けます。完了とは、顧客の側の世界で何かが変わったことです。返金の例なら、返金が実行され、顧客の取引記録にそれが現れている状態が完了です。一方で、ほとんどの場合という言葉が示しているのは、残りが必ず存在するということです。人へ引き継いだ案件は、人の確認が費用のかかる工程である限りこちらの工数としては重いのに、約束した成果物は渡っていません。A&Aの提案は、この残りを請求しないことではなく、別の単位として最初から数えることです。引き継ぎ件数を隠すと、値付けは人の手が入るほど不利になります。これはA&Aの見立てです。

A&Aの考え方

ここから言えるのは、メーターの数字は請求のための集計であって、業務が完了したことの正本ではないということです。非同期で集計される以上、ある瞬間の合計は最終値ではありません。冪等キーの存在は、重複が例外ではなく前提として扱われていることを示しています。A&Aの読み解きとしては、完了の正本は自社の業務側の記録に置き、そこから請求のメーターへ一方向に送る形にすべきです。請求側の数字を業務の完了記録として逆に使うと、顧客から問い合わせがあったときに、何が起きたのかを遡れません。そして送る単位は、最初の節で定義した完了一件と一致していなければ、照合そのものが成立しません。

A&Aの考え方

夜間に走る処理や、人の確認を挟んで翌朝に完了する案件を扱うサービスでは、この猶予の長さが月末の件数を直接動かします。A&Aの提案は、猶予の長さを技術設定として決めるのではなく、契約書に書いた締めの時刻と揃え、顧客への説明文にも書くことです。そして、猶予を超えて届いた完了は、こっそり当月へ押し込まずに翌月の一件として数えます。押し込みは一度は通りますが、顧客が自分の記録と突き合わせた瞬間に差分として現れ、そこから請求全体の信頼が崩れます。差分が出ること自体は避けられません。避けられるのは、その差分を説明できない状態です。

A&Aの考え方

ここまでを、契約前に埋める六行にまとめます。第一に、何をもって一件の開始とするか。顧客からの依頼が届いた時点か、こちらが処理を開始した時点か。第二に、顧客の側で何が変わったら完了とするか。これは顧客が自分の記録で確認できる変化でなければなりません。第三に、完了に含めないもの。人への引き継ぎ、対象外と判定した依頼、実行記録のない出力です。締めの猶予を過ぎて届いた完了はここには入りません。除外ではなく、翌月計上です。第四に、再試行の扱い。同じ依頼に対する二回目以降を数えないこと、そして重複をどのキーで排除するか。第五に、取り消しの扱い。完了後の取り消しを計上したうえで別行で戻すのか、取り消すのか。第六に、照合キー。顧客の記録と突き合わせるための識別子です。

A&Aの考え方

定義ができたら、請求書に添える明細の形を決めます。必要なのは合計件数だけの行ではなく、顧客が自分の記録から同じ数を再現できる材料です。A&Aの提案は五つの数字を並べることです。今月分として請求する完了件数、人へ引き継いだ件数、請求対象外とした件数（対象外の依頼と、実行記録のない出力）、当月の締めの猶予を過ぎて届き翌月へ繰り越す件数、そして前月から繰り越して今月の請求に入れた件数。この五つを出しておくと、顧客が自分の記録で数えた総件数と、請求書の件数が一致しない理由が、明細の中だけで説明できます。件数の内訳を出すと値引き交渉を招くように見えますが、A&Aの見立てはむしろ逆で、説明できない一つの数字のほうが交渉の材料になります。

A&Aの考え方

限界を三つ書きます。第一に、仕様は商売上の問いを何も決めません。引用したStripeの資料は利用量をどう記録し、いつ締めるかを説明しますが、一件の成果にいくらの価値があるか、適正な単価はいくらかについては何も述べていません。この記事も単価を示していません。メーターの実装手順そのものも本題ではなく、何を売った一件とするかだけを扱っています。第二に、Decagonの事例はベンダーが公開した記述で、独立した監査ではありません。掲げられている数字はDecagon自身が自社の製品と運用条件について公表した指標で（同ページの会社規模の記載は「Small」です）、他のチームの見込みにはなりません。出典自身の言葉は「ほとんどの場合」であり、残りの人手の経路には必ず費用がかかります。第三に、ここで示した照合の様式はA&Aの提案であって、どこかで観測された運用手順ではありません。引用した仕様は閲覧時点のもので、実装前に読み直す必要があります。

A&Aの考え方

次の一歩は、いま出している請求書を開いて、そこに書かれた件数を顧客が自分の記録から再現できるかを確かめることです。再現できないなら、単価の議論より前に定義の六行へ戻ります。顧客獲得から継続利用までの中で、この請求設計がどこに位置するかを確かめたい場合は、「AIネイティブGTMとは？一人・少人数で顧客獲得から継続まで回す実践ガイド」が全体の地図になります。単価そのものではなく、顧客に見せる使用量と追加の支払いの書き方を先に決めたい場合は、「AI SaaSのクレジット制をどう説明するか：使える量と追加支出を見せる」が近い題材です。何を完了とするかが顧客ごとに揺れていて自社だけで決め切れないなら、助言型の相談が向いています。定義がすでに固まっていて、業務記録から請求までの計測と照合をどう作るかが課題であれば、範囲を切った開発として進めるほうが早く終わります。