AWS Marketplaceのメータリング実装｜BatchMeterUsageと二重計上、送信漏れ対策

従量課金のSaaSをAWS Marketplaceに出品するとき、メータリングは「毎時間BatchMeterUsageを呼ぶだけの処理」と見積もられがちです。呼び出し自体は、たしかにその程度です。ところが、一度送った数量は訂正できません。

たとえば、集計ジョブがある1時間の使用量を、確定前に送ってしまったとします。あとから確定値で送り直すことはできますが、請求に使われるのは最初の数量です。（使用量メータリングの設定）二重計上や数量の食い違いは、APIの呼び方だけでなく、数量の決め方と送るタイミングからも生まれます。

本記事は、日本のSaaS販売者が従量課金を含むSaaS製品を新規に出品する場合を対象に、2026年10月5日に確認したAWSの公式ドキュメントと発表にもとづいて書いています。

メータリングが必要な料金モデルと請求の仕組み

使用量の送信が必要になるのは、二つの料金モデルです。SaaS Subscription（SaaSサブスクリプション。時間単位の使用量に応じて請求する従量課金の料金モデル）では、請求のすべてが、SaaSが送る使用量にもとづきます。SaaS Contract with Consumption（従量制料金によるSaaS契約。契約の料金に加えて超過分を従量で請求する料金モデル）では、契約の数量を超えた分だけを送ります。（使用量メータリングの設定）SaaS Contract（SaaS契約。契約期間と購入する権利をあらかじめ定め、前払いまたは支払スケジュールで請求する料金モデル）の製品では、SaaSは使用量を送らず、権利確認のAPIで購入内容を確かめます。（SaaS契約の料金）各モデルの比較は、AWS MarketplaceのSaaS料金モデルにあります。

SaaS Subscriptionの料金のガイドは、課金対象をすべて1時間ごとに計測して報告するよう定めています。AWSが請求できるのは、販売者から記録が届いたときだけで、記録が正しく送信され、受信されることの責任は、販売者が負います。（SaaSサブスクリプションの料金）送信漏れは、そのまま請求できない使用量になります。

送る単位は、製品の作成時に決めた料金ディメンションです。ディメンションのAPI名と単位は、作成後に変更できません。（SaaS製品の設定）何を一単位と数えるかは、AWS Marketplaceの料金ディメンションとは？で設計の観点を整理しています。

新規の連携機能でBatchMeterUsageに渡すべき値

BatchMeterUsageは、SaaSが購入者ごとの使用量の記録を、AWS Marketplaceへ送るAPIです。1回のリクエストで送れるのは1製品分で、記録は最大25件、リクエストの大きさは1MB未満です。（BatchMeterUsage API）登録、権利確認、契約の通知を含む連携機能の全体像は、AWS MarketplaceのSaaS連携に必要な実装で整理しています。

2026年6月1日以降に作る新規のSaaS製品では、購入者の識別にCustomerAWSAccountIdを、契約の識別にLicenseArnを使います。新規の製品の連携機能では、CustomerIdentifierは使えず、ProductCodeもリクエスト単位では渡しません。LicenseArnが、製品と個別の契約の両方を特定するからです。（BatchMeterUsage API）両方の値は、購入者が登録ページに来たときにResolveCustomerの応答で受け取れるため、そこで保存します。（SaaS製品のコード例）

1件の記録に入れる項目は、次のとおりです。（UsageRecord）

Timestampには、どの時刻の使用量として報告するかを入れます。24時間前まで遡って送れますが、利用開始より前の時刻にならないようにします。（UsageRecord）毎時の記録では、本記事の提案として、その時間の開始時刻（3時台なら03:00）に統一します。公式のコード例にも、分以下を0にした時刻をTimestampに入れた例があります。（コード例）送信した時刻を入れると、3時台の使用量が4時台の記録になり、重複排除の単位もずれます。契約の開始がその時間の途中なら、開始時刻以降の値にします。

呼び出しの形は、公式のコード例に応答の確認を足すと、次のようになります。このコード例は、実行して動作を検証したものではありません。

import boto3

client = boto3.client("meteringmarketplace")

def send(records):
    # records は最大25件。リクエストに ProductCode は含めない
    response = client.batch_meter_usage(UsageRecords=records)

    # 記録ごとの結果（Success / CustomerNotSubscribed / DuplicateRecord）
    for result in response["Results"]:
        print(result["Status"], result.get("MeteringRecordId"))

    # サービス側のエラーで処理されなかった記録。同じ内容で再送する
    return response["UnprocessedRecords"]

複数契約に対応した製品では、メータリングは契約単位で動きます。同じ購入者に有効な契約が複数あっても、使用量は契約ごとに追跡され、別々に請求されます。（使用量メータリングの設定）そのため、SaaSの側にも、使用量をどの契約の分として数えるかを決める仕組みが要ります。契約とテナントの対応づけはAWS Marketplaceの契約をSaaSテナントに紐付けるには？で、新規要件の全体像はAWS MarketplaceのConcurrent Agreementsとは？で扱っています。

1時間分の数量を確定してから送る

では、数量はいつ確定すればよいのでしょうか。AWSの重複排除と訂正の扱いが、その答えを制約します。

複数契約に対応した製品（新規の製品）では、重複排除の単位は、ライセンス、購入者、時間、ディメンションの組です。対応していない製品では、製品、購入者、時間、ディメンションの組になります。（使用量メータリングの設定）どちらの場合も、同じ組で数量を変えて再送すると、最初の数量が請求されます。同じ組を別のリクエストで送っても、記録は合算されません。（使用量メータリングの設定）一度報告した数量は、0であっても訂正できないため、公式ガイドは前の1時間分を報告するよう勧めています。（使用量メータリングの設定）

つまり、遅れて届く使用量のイベントを見越して、1時間を締める時刻を決める必要があります。公式のログ分析の例では、毎時10分に、前の1時間分の使用量を読み出してバッチを作り、送信しています。（使用量メータリングの設定）締める時刻は、自社のイベントがどれだけ遅れて届くかで決めます。遅らせすぎると、24時間の送信期限との間に余裕がなくなります。

数量の扱いには、ほかに二つ決めることがあります。

• 小数の単位：QuantityはAPI上で整数のため、GB数などの小数を整数にする規則（切り上げ、切り捨て、四捨五入）を、料金表と合わせて決めます
• 使用量がない時間帯：数量0の記録を毎時間送ることが、強く推奨されています。（SaaS Subscriptionの連携）

0の記録は、自社側でも役に立ちます。本記事の提案として、0の記録も含めて毎時間の記録を必ず作ります。ある時間の記録がないこと自体が、送信漏れの目印になるからです。

二重計上と数量の食い違いが起きる経路

同じ内容のリクエストは重複排除されるため、そのまま再送しても二重には請求されません。（BatchMeterUsage API）請求がずれる経路は、別のところにあります。

一つめは、旧方式から新方式への移行です。同じ顧客について、同じ時間にProductCodeとLicenseArnの両方で記録を送ると、二重請求になります。移行するときは、LicenseArnでの送信を始める前に、ProductCodeでの送信を止めます。（BatchMeterUsage API）移行ガイドによると、移行の途中は両方式のリクエストが同時に動作します。使用量の報告を1時間に1回とする制限は、方式ごとに別々に適用されるため、同じ時間に意図せず二重に報告してしまう恐れがあります。既存の製品は自動では移行されず、販売者がオプトインを申請して初めて新方式になります。（Concurrent Agreements移行ガイド）

二つめは、数量を変えた再送です。二重にはなりませんが、AWSが保持する数量と自社の数量が食い違います。同じ顧客、ディメンション、時刻で数量が異なる記録は、応答にDuplicateRecordの状態で返り、採用されません。（UsageRecordResult）APIでは訂正できないため、最初の送信が誤っていれば、その数量が請求の基準になります。

三つめは、数量の決め直しです。再試行のたびに集計を実行し直す実装では、遅れて届いたイベントの分だけ、再送の数量が最初の送信から変わってしまいます。本記事が提案する対策は単純です。数量は1時間分を一度だけ確定し、以後の再送では、確定した値をそのまま使います。同じ記録を何度送っても内容が変わらないため、AWSの冪等な再送の性質をそのまま活かせます。

送信漏れが起きる経路

送信漏れの原因は、AWS側の受付条件と、自社側の送信処理の両方にあります。

一つめは、送信期限です。使用量の発生から24時間以上たった記録は受け付けられません。さらに、前月分は、24時間の期限の内であっても、翌月1日の06:00 UTC（日本時間の15:00）を過ぎると受け付けられません。たとえば月末の23時台の分は、23:00の7時間後にあたる06:00 UTCが期限です。期限を過ぎると、TimestampOutOfBoundsExceptionのエラーになります。（BatchMeterUsage API）しかも、範囲外の記録が1件でもあると、バッチ全体が処理されません。送信前に記録の古さを確認し、期限切れの記録をバッチから外す処理が要ります。

使用量メータリングの設定のガイドも、購読中の購入者については、24時間前までのTimestampで送れるとしています。（使用量メータリングの設定）3時台の分を04:10に送り、04:15以降に再送する本記事の設計は、この期限の内に収まります。

二つめは、購入者に有効な契約がない場合です。CustomerNotSubscribedは、識別子が無効、購入者に有効な契約がない、アカウントが停止している、のいずれかで返ります。公式の説明は、旧方式の購入者の識別子（CustomerIdentifier）を前提にしており、その購入者への以後の記録は、購読が結ばれるまで失敗し続けるとしています。（UsageRecordResult）複数契約に対応した製品では、メータリングが契約単位で動くため、本記事の提案として、止めるのはエラーになったLicenseArnの送信だけにし、同じ購入者の他の有効なライセンスへの送信は続けます。同じ購入者の別のLicenseArnでの送信が受け付けられるかは、公開前のテストで確かめます。

新規の製品で使用量の記録を送り始める契機は、Amazon EventBridgeのLicense Updatedイベントの受信です。SaaS製品への購入者の登録のガイドは、このイベントを受け取った時点で購入者のアカウントがメータリングを受け付ける状態になり、それより前に送った記録は計上されないとしています。同じガイドは、License Updatedを受け取るまで、製品の利用を有効にしないことも求めています。（SaaS製品への購入者の登録）ResolveCustomerで購入者を特定した直後に、最初の記録を送るわけにはいきません。

三つめは、応答の見落としです。呼び出しが成功するとHTTP 200が返りますが、記録ごとの結果は応答のResultsに入ります。Resultsには、採用された記録と、無効だった記録の両方が含まれます。（BatchMeterUsage API）例外なく終わった呼び出しでも、Resultsを確認しなければ、個々の記録が採用されたかはわかりません。

四つめは、送信ジョブの停止です。使用量を毎時間送らない運用では、障害が起きたときに記録の遅れが大きくなります。契約の期間が終わったあとに障害が復旧すると、未報告の使用量が残る可能性もあります。（使用量メータリングの設定）備えとして、未送信の記録がどれだけ古くなったら通知するかを、24時間の期限から逆算して決めておきます。本記事の提案として、期限の半分（12時間）を超えたら通知する基準を設定します。月末の前月分は、24時間ではなく、06:00 UTCまでの残りを基準にします。

応答の読み方と再送の方針

応答と例外のうち、公式が扱いを明記しているのは、UnprocessedRecordsの再試行、InternalServiceErrorExceptionの再試行、無効な記録を直してからの再送、範囲外の記録を除いた再送の4つです。（BatchMeterUsage API）「提案する扱い」の列は、それ以外も含めた本記事の提案です。

「公式の説明」の列は、BatchMeterUsage APIとUsageRecordResultにもとづきます。再送では、記録の中身を変えません。直す必要があるエラーでは、直した内容が新しい確定値になります。

契約が終わるときの最終送信

購入者が契約を終えると、最後の使用量を送れるのは1時間だけです。Amazon EventBridgeのガイドは、License Deprovisionedイベントがその1時間の始まりを示すとしています。1時間が過ぎると、権利は完全に取り消され、BatchMeterUsageは使用量を拒否し、その分は請求できません。（Amazon EventBridgeによるSaaSイベント管理）ところが、SaaS Subscriptionの料金のガイドは、License Deprovisionedではなく購入契約の終了イベント（Purchase Agreement Ended）を受けた時点から1時間を数え、その1時間のあとにLicense Deprovisionedを受け取ると書いています。（SaaSサブスクリプションの料金）なお、2026年10月5日時点では、Amazon Simple Notification Service（Amazon SNS）の通知を前提にした記述の中には、起点をentitlement-updated通知や購入者の解約（unsubscribe-pending）とする箇所も残っています。（SaaS契約の料金、使用量メータリングの設定）公式の記述で起点が一致していないため、本記事の提案として、最終送信はPurchase Agreement EndedとLicense Deprovisionedのうち先に届いたイベントで始めます。本記事では、このイベントを「終了イベント」と呼びます。実際に届くイベントの順序と時刻は、テストで確かめてから、起点を決め直します。複数契約に対応した製品では、この1時間は製品ではなく契約ごとに数えます。複数ある契約のうち一つが解約されても、残りの契約への送信は続けられます。（使用量メータリングの設定）

最終送信の1時間は、通常の記録の24時間の期限とは別の制約です。契約が終わったあとは、発生から24時間以内の記録でも、1時間を過ぎれば受け付けられません。

契約は、1時間の途中で終わることもあります。終了イベントを受けた時刻が14時20分なら、1時間の猶予は15時20分までです。ただし、公式のドキュメントは、猶予の1時間を、未報告の使用量を集めて報告する期間として説明しています。（Amazon EventBridgeによるSaaSイベント管理）一方、BatchMeterUsageのInvalidLicenseExceptionは、使用量がライセンスの有効期間内にあることを条件にしています。（BatchMeterUsage API）この二つから、終了後に新しく発生した使用量が、猶予のあいだなら課金できるとは読み取れません。

本記事の提案では、終了イベントを受けた14時20分を権利の終了時点として扱い、14時台の使用量をその時点までの数量で確定して送ります。重複排除はライセンス、購入者、時間、ディメンションの組で行われるため、14:20から14:59の使用量を、あとから同じ14時台に足すことはできません。数量を変えて送れば、DuplicateRecordになります。SaaS Subscriptionの料金のガイドは、利用をどう止めるかを販売者が決めるものとしています。（SaaSサブスクリプションの料金）確定のあとに生まれる使用量をどう扱うかは、先に決めておきます。

本記事の提案として、終了イベントを受けた時点で、その契約の利用と計測を止めます。計測と同時に利用も止めるため、確定のあとに請求できない使用量は生まれません。

猶予のあいだも利用を続けさせる場合は、終了後に生まれた使用量にどのTimestampを付ければ受け付けられ、請求に載るのかが、公式のドキュメントからは確認できません。この方式は、実測で確かめるまで採りません。確かめるときは、終了後の時刻を含む記録を送り、受け付けられるか、InvalidLicenseExceptionで拒否されるか、請求に載るかを記録します。

終了イベントを受けた時点で、その契約の未送信分は、通常のジョブより優先して送ります。解約や返金の手続きとSaaSの権限制御は、AWS Marketplaceの解約と返金の対応で扱っています。

送信記録を自社で持つ

送った内容を、AWS側で時間単位に確かめる手段は、限られています。Daily Usageデータフィードは、24時間ごとに更新され、使用量は日単位に集計されています。日付だけで時刻を含まず、使用量の列は小数2桁です。agreement_idは、空だったり、請求の明細と一致しなかったりする場合があります。end_user_account_idとpayer_account_idは、販売者ごとにソルトを加えたハッシュで、AWSアカウントIDそのものではありません。（Daily Usageデータフィード）AWS CloudTrailでは、送ったAPI呼び出しの内容を確認できます。（使用量メータリングの設定）時間単位の数量と応答の結果を、照合しやすい形で残せるのは、送った側です。

そこで、本記事の提案として、送信の台帳を自社のデータベースに作ります。台帳の1行は、AWSの重複排除の単位と同じ、ライセンス、購入者、時間、ディメンションで一意にします。

この台帳があれば、三つの確認ができます。

• 欠けた時間の検出：有効な契約とディメンションの組ごとに、直前までの毎時間の行があるかを確認します。0の記録も行にするため、行がないことが、そのまま漏れを示します
• 滞留の検出：送信待ちの行が、決めた古さを超えたら通知します。月末は、翌月1日の06:00 UTCの前に、前月分の未送信がないかを確認します
• 日次の照合：台帳の数量を日、ディメンション、製品の単位で合計し、Daily Usageデータフィードの日付、ディメンション、使用量と突き合わせます。フィードは日次の更新なので、前日以前の分を対象にします。購入者の単位で照合するなら、フィードの購入者の列がハッシュのため、Accountフィードとの結合が要ります

購入者の単位の照合、差が出たときの見方、売上や請求との違いは、AWS Marketplaceの売上と利用量のレポートで整理しています。

公開前のテスト

公開の前には、AWS Marketplace Operationsチームが、SaaSがメータリングの記録を送れることを確認します。通常は、模擬の登録を行い、記録が届いたことを確かめる流れです。（使用量メータリングの設定）自社のテストは、自社のアカウントで製品を購入して行い、購入時の請求を抑える価格の一時的な引き下げは、AWS Marketplace Seller Operationsに問い合わせます。（SaaS Subscriptionの連携）

AWS Marketplace Seller Operationsが確認するのは、記録が届くかどうかです。本記事で挙げた二重計上と送信漏れの経路を確かめるため、本記事の提案として、次のテストを自社で追加します。

• 同じ時間枠の記録を2回送り、台帳の数量が変わらないことを確かめ、2回目の応答のStatusが何になるかを記録すること
• 3時台の記録を、Timestamp 03:00のまま04:15以降に再送しても受け付けられること
• License Updatedを受信した直後に送った記録が、計上されること
• 契約の開始と同じ時間の記録が、開始より前のTimestampとして拒否されないこと
• 期限切れの記録を混ぜたバッチで、期限切れだけが外され、残りが送られること
• 契約を終了したとき、Purchase Agreement EndedとLicense Deprovisionedが届く順序と時刻、各時点でBatchMeterUsageが受け付けられるかを記録すること
• 終了イベント（Purchase Agreement EndedかLicense Deprovisionedの早いほう）を受けたとき、その契約の利用と計測が止まり、終了時点までの最終分が送られること
• 猶予のあいだも利用を続けさせる場合に限り、終了後の時刻を含む記録が、受け付けられるか、InvalidLicenseExceptionで拒否されるかを、請求への反映まで含めて記録すること
• 締めたあとに届いた使用量が、確定した数量を書き換えず、別に記録されること
• 複数の契約で、使用量が別々のLicenseArnで送られること
• 1つのLicenseArnがCustomerNotSubscribedになったとき、同じ購入者の他のLicenseArnの記録が受け付けられること
• 月末の境界で、前月分と翌月分のTimestampが取り違えられないこと

審査全体で確認される項目は、AWS MarketplaceのSaaS審査で確認することにまとめています。

AWS公式のメータリング支援AIの使いどころ

2026年9月30日、AWSは、従量課金（Pay-As-You-Go、PAYG）のSaaS、つまりSaaS Subscriptionのメータリング連携機能を構築して検証するための、Skills（スキル）を発表しました。AWS MCP Serverを通じて、Amazon Q DeveloperやKiroなど、Model Context Protocol（MCP）に対応したAIコーディングアシスタントから使えます。製品の種類、料金モデル、ディメンションを聞き取り、適したAPIを提案し、ResolveCustomer、BatchMeterUsage、Amazon EventBridgeを使う構成のコードとAWS CloudFormationスタックを生成します。ディメンションを製品の設定と照合し、実際のテストで連携機能の動作を確認します。Concurrent Agreementsにも対応し、既存の販売者がメータリングの記録を調べ、デバッグするのも助けます。（AWSの発表）発表が対象とするのはPAYGのSaaSで、SaaS Contract with Consumptionの従量部分にも使えるかは、発表からは確認できません。

メータリングのガイドも、このSkillsを案内したうえで、メータリングの誤りが請求に影響するため、生成されたコードは本番の前に確認するよう注意しています。（使用量メータリングの設定）生成されたコードを確認するときは、1時間分の数量の確定時刻、送信の台帳、契約終了時の最終送信の三つの観点で読み直すと、足りない処理を見つけやすくなります。Deshimaとの比較は、AWS公式のメータリング支援AIで何ができる？で扱っています。

3時台の使用量が送られるまで

UTCの3時台の使用量は、次の順で送られます。

03:00 から 03:59   使用量のイベントが蓄積される
04:10              3時台を締める。ライセンスとディメンションごとに数量を確定し、
                   Timestampを03:00として台帳に送信待ちで書く（使用量がなければ0）
04:10              25件ずつBatchMeterUsageに送り、Resultsの結果を台帳に反映する
04:15 以降         UnprocessedRecordsや一時的なエラーは、台帳の数量のまま再送する
終了イベントを受信 Purchase Agreement EndedかLicense Deprovisionedの早いほうを受けたら、
                   その契約の利用と計測を止め、終了時点までの使用量を確定して、未送信分を最優先で送る
翌日以降           台帳とDaily Usageデータフィードを照合する

冒頭で挙げた、確定前に送ってしまう失敗は、この流れでは起きません。数量は04:10の確定のときに一度だけ決まり、以後の再送でも変わりません。遅れて届いたイベントが、あとから数量を書き換えることもありません。

ただし、これで防げるのは、数量の食い違いと二重計上です。締めたあとに届いた使用量は、同じ時間枠に送り直しても合算されず、数量を変えればDuplicateRecordになるため、請求漏れとして残ります。この使用量は別に記録して調査し、送信済みの数量の上書きでは処理しません。返金、調整、未請求のどれで扱うかは、あらかじめ決めておきます。

顧客への使用量の請求と、AWSへの収益寄与の計測は別

本記事で扱ったBatchMeterUsageは、顧客に使用量を請求するためのAPIです。名前が似ているため混同しやすいのですが、Partner Revenue Measurement（PRM）のAWS Marketplace Metering方式は、これとは別の仕組みです。PRMが測るのは、自社の製品が牽引したAWSサービスの消費にもとづく収益寄与で、その自動計測の対象はAmazon Machine Image（AMI）製品とMachine Learning（ML）製品です。2026年10月29日時点の公式ガイドでは、SaaSはこの自動計測の対象として記載されていません。PRMが何を測る仕組みかはAWSのPartner Revenue Measurement（PRM）とは？で、SaaSで採用する計測方式はAWS PRMの実装方法で扱っています。

実装を始めるときの確認先

SaaS Subscription（PAYG）の実装に進むときは、AWS公式の次の二つを確認します。メータリング用Skillsの仕様は、aws-marketplace-meteringにあります。PAYGの連携の手順は、SaaS Subscriptionの連携にあります。

2026年10月5日時点で、DeshimaはSaaS Contract型のみに対応しており、本記事で扱うSaaS Subscriptionの従量課金（メータリング）とChannel Partner Private Offer（CPPO）は対象外です。従量課金を含む製品では、本記事のように自社で実装することになります。

SaaS Contract型の製品もお持ちであれば、その掲載準備にはDeshimaをご利用いただけます。Deshimaの利用料は、初期費用と月額費用がどちらも0円で、費用が発生するのは製品が売れたときの販売手数料のみです。料率は個別にご提案しており、考え方は料金のセクションに記載しています。AWS Marketplaceの販売手数料、自社側の実装と運用の工数、必要なAWSリソースの費用は、別にかかります。Deshimaは更新が多いため、最新の機能と対応範囲は、無料のアカウントを作成したうえで、プロダクト内のドキュメントでご確認ください。