技術連携と運用
AWS Marketplaceの売上、利用量レポート｜日次データとメータリング履歴の違い
公開日: 更新日:
この記事の要点
AWS Marketplaceの販売者が確認できる売上と利用量のデータは、自社の送信記録、日次の利用量と見積収益（Daily Usage）、請求済みの金額、入金の四段階に分かれます。Daily Usageは日次の集計であり、時間単位の送信履歴そのものではありません。見積収益は月末の請求確定まで見積であり、確定額はBilled revenueダッシュボードで確認します。購入者側のAWS Cost and Usage Report（CUR）は、販売者の送信履歴の代わりにはなりません。
請求額と自社の利用量集計が合わないとき、最初にどこを疑えばよいでしょうか。アプリの集計ロジックか、AWSの計算か、それとも送信の漏れか。疑う前に、並べている二つの数字が同じ種類のデータなのかを確かめます。
AWS Marketplaceの販売者が確認できる数字は、四つの段階に分かれています。自社が送った使用量の記録、AWSが日次で集計した利用量と見積収益、請求済みの金額、そして入金です。段階ごとに更新の頻度も確定の度合いも違い、日次の利用量データ（Daily Usage）は、送信した記録の時間別の履歴ではなく、見積収益を含む日次の集計になっています。（Daily Usageデータフィード）
本記事の内容は、2026年10月5日に確認したAWSの公式ガイドにもとづきます。画面名や更新のタイミングは変わることがあるため、運用に組み込む前に各出典で最新の内容をご確認ください。
売上と利用量のデータの四段階
| 段階 | 示すもの | 粒度と更新 | 主な確認先 |
|---|---|---|---|
| 自社の送信記録 | 自社のSaaSがAWSに送った使用量 | 公式は時間単位での送信を推奨 | 自社のログ、AWS CloudTrail |
| Daily Usage | 日ごとの利用量と見積収益 | 日次の集計。24時間ごとに更新 | Daily Usageデータフィード、Usageダッシュボード |
| 請求 | 購入者に請求された金額 | SaaS Contractは承諾時などに請求。従量は翌月の2日か3日。米ドル以外のPrivate Offerの従量は起算日ごとの請求書（anniversary invoices） | Billed revenueダッシュボード、Billing eventデータフィード |
| 入金 | 販売者の口座に支払われた金額 | ダッシュボードは北米の営業日に更新 | Collections and disbursementsダッシュボード、Billing eventデータフィード |
（出典：メータリングの設定、Daily Usageデータフィード、Billed revenueダッシュボード、Collections and disbursementsダッシュボード、複数通貨のPrivate Offerの支払い（購入者ガイド））
データの届け方にも二通りあります。一つはダッシュボードで、販売者向けのInsightsから確認します。もう一つはデータフィードで、販売者が用意した暗号化済みのAmazon S3バケットにCSVファイルが配信されます。（販売者向けダッシュボード、データフィードの構造）
自社の送信記録に残るものと、変えられないもの
従量課金のSaaSでは、自社のアプリケーションが使用量をAWSに送り、AWSはその記録と、製品の作成時に登録した単価から顧客の請求額を計算します。公式ガイドは、全顧客の使用量を時間単位で、一回につき最大25件のバッチで送るよう推奨しています。（メータリングの設定）
照合の土台になるのは、送信の仕組みに備わる四つの性質です。
- 修正できない：あるディメンションの使用量を報告したあとは、0を含めて記録を修正できません。（メータリングの設定）
- 時間単位で重複が排除される：同じ顧客、同じディメンション、同じ時間への再送は、数量を変えても最初の数量が請求されます。Concurrent Agreementsに対応した製品では、契約（ライセンス）、顧客、時間、ディメンションの組で判定されます。同じ時間への複数のリクエストが合算されることはありません。（メータリングの設定）
- 期限がある：事象から24時間以上たった記録は受け付けられません。月をまたぐ分は、翌月1日の06:00 UTCまでに送る必要があります。範囲外の記録が一件でも混ざると、そのバッチ全体が処理されません。（BatchMeterUsage）SaaS Subscription（SaaSサブスクリプション。時間単位の使用量に応じて請求する従量課金の料金モデル）では、購入者が解約すると、最終の記録を送れる猶予が1時間だけ与えられ、その後の記録は受け付けられません。（メータリングの設定）1時間の起点は、旧方式のAmazon Simple Notification Service（Amazon SNS）では解約通知（
unsubscribe-pending）の受信です。（SaaSのAmazon SNS通知）新方式のAmazon EventBridgeでは、License Deprovisioned - Manufacturerイベントの受信です。（Amazon EventBridgeでのSaaS購読イベント）SaaS Contract with Consumption（従量制料金によるSaaS契約。契約の料金に加えて超過分を従量で請求する料金モデル）では、購入者は契約期間中に解約できません。ただし、自動更新しない契約が終わるときに同じ通知が届き、同じ1時間の期限がかかります。（メータリングの設定、Amazon EventBridgeでのSaaS購読イベント）Concurrent Agreementsに対応した製品では、この1時間の期限は製品ではなく契約ごとにかかります。解約された契約の使用量だけが期限の対象で、残る有効な契約には送り続けられます。（メータリングの設定） - 処理されなかった記録や、受理されなかった記録が返る：AWS側のエラーで処理されなかった記録は、応答の
UnprocessedRecordsに含まれて返され、同じ内容で再試行できます。（BatchMeterUsage）Resultsの各記録にもStatusがあり、CustomerNotSubscribedやDuplicateRecordの記録は請求されません。（UsageRecordResult）CustomerNotSubscribedは、顧客識別子が無効、有効な契約がない、顧客のAWSアカウントが停止中、のいずれかのときに返ります。（UsageRecordResult）
では、送ったつもりの記録がAWSに届いたかどうかは、どこで確かめるのでしょうか。公式ガイドが挙げているのはAWS CloudTrailです。送信した記録が正確かどうかを検証でき、継続的な監査にも使えると説明されています。AWSは記録を受け取って初めて請求できるため、記録が正しく送られ、受け取られたことの確認は販売者の責任とされています。（メータリングの設定）
AWS CloudTrailのほかに、自社側にも原本を残しておく設計をお勧めします。送信前の集計値、バッチごとの送信結果、再送の有無を保存しておくと、あとでDaily Usageと突き合わせる原本になります。これは公式の要件ではなく、照合を成り立たせるための設計上の提案です。なお、送信の実装そのものは、AWS Marketplaceのメータリング実装で扱っています。
Daily Usageが示すものと、示さないもの
Daily Usageは、顧客の製品利用に関する日次のデータで、利用量と見積収益、単価を含みます。24時間ごとに更新され、データフィードとして販売者のAmazon S3バケットに配信されます。（Daily Usageデータフィード）
| 列 | 内容 |
|---|---|
usage_date | 顧客の利用日。利用量は日ごとに集計されるため、時刻は含まれない |
dimension_key | オファーの公開時に販売者が設定したディメンションのキー |
usage_quantity | 利用量。小数点以下2桁まで |
usage_rate_per_unit_in_pricing_currency | 単位あたりの単価。小数点以下6桁まで |
estimated_revenue_in_pricing_currency | 利用量と単価から計算された見積収益 |
agreement_id | 契約の識別子。agmnt-で始まる |
offer_id | 購入者が承諾したオファーの識別子 |
（出典：Daily Usageデータフィード）
公式ガイドの例では、利用量が24.00、単価が0.500000、見積収益が12.00（USD）の行があります。利用量に単価を掛けると見積収益になる関係は、数量の突合の次に金額を検算するときに使えます。
利用量は一日分にまとまっているため、自社が一時間ごとに送った内容をこのデータから復元することはできません。また、見積収益はあくまで見積です。Usageダッシュボードの説明は、収益は月末の請求確定まで見積として扱うこと、確定した請求の情報はBilled revenueダッシュボードで確認することを案内しています。（Usageダッシュボード）
見積であること以外にも、読み違えやすい点が四つあります。
- 使用量が上流のデータから届くまでに数日かかることがあり、Usageダッシュボードには、利用日（Usage date）と反映日（Usage reported date）の両方が表示されます。ダッシュボードの対象は直近6か月です。（Usageダッシュボード）
- 円など米ドル以外のPrivate Offer（プライベートオファー）でも、Usageダッシュボードの金額は米ドルで表示されます。実際の請求と入金は元の通貨で行われるため、財務の照合には請求書を使うよう案内されています。（Usageダッシュボード）日本円のPrivate Offerの条件は、AWS Marketplaceで日本円のPrivate Offerは作れる？に整理しています。
- 再販のオファーの利用状況を独立系ソフトウェアベンダー（ISV）の立場で確認するときは、見積収益に収益分配の割合を掛ける必要があります。（Daily Usageデータフィード）
agreement_idは、ときどき空になったり、請求書の明細と一致しなかったりします。アカウントの識別子（end_user_account_idとpayer_account_id）は、販売者ごとのソルト付きハッシュ値であり、生のAWSアカウントIDではありません。Accountデータフィードと結合して使います。（Daily Usageデータフィード）
見積収益から請求、入金まで
Daily Usageの見積収益が確定額になるのは、請求の段階です。請求の確認先はBilled revenueダッシュボードで、AWSが購入者に請求したすべての売上が反映されます。画面には、総収益、返金、手数料、再販の場合の卸原価、販売者の純収益が表示されます。（Billed revenueダッシュボード）
請求のタイミングは三通りです。オファーの承諾時に請求する前払い、flexible payment scheduler（フレキシブルペイメントスケジューラ）で作ったPrivate Offerの支払いスケジュール、そして従量の使用量に対する翌月の2日と3日の請求です。請求日と、購入者の支払期限であるNet payment termsの違いは、AWS Marketplaceの分割払いとNet payment termsで扱います。ただし、米ドル以外のPrivate Offerの従量課金は、米ドル建ての他の従量課金製品とは別の、契約の起算日（anniversary）ごとの請求書（anniversary invoices）に載ります。この場合の請求日は、翌月の2日と3日とは限りません。実際の請求日は、Billed revenueダッシュボードのInvoice dateで確かめます。（複数通貨のPrivate Offerの支払い（購入者ガイド））Billed revenueダッシュボードは毎日UTCの0時に更新され、明細は請求の24時間後に表示されます。上流のデータが遅れると、反映に1日か2日かかることもあります。（Billed revenueダッシュボード）
なお、自社が購入者としてAWSの請求代行を利用している場合は、購入の請求先と販売の手数料の請求先が分かれます。その扱いは、AWS Billing Transferとは？で扱います。
入金の段階では、Collections and disbursementsダッシュボードを使います。販売者の口座に支払われた資金と、一部入金や失敗を含む請求の一覧が表示されます。入金済みの請求は、口座への入金を受け取ってから1日以内にダッシュボードに表示される想定です。ただし、更新されるのは北米の営業日だけです。未入金の請求は表示されないため、その確認にはBilled revenueダッシュボードを使います。Disbursement statusには、Disbursed、Partially disbursed、Failed、Not disbursedがあります。（Collections and disbursementsダッシュボード）返金は、Collections and disbursementsダッシュボードでは負の金額で表示されます。返金の手続きと、SaaS側の権限の扱いは、AWS Marketplaceの解約と返金対応で扱っています。
請求から入金までを一件ずつ追いたいときは、Billing eventデータフィードが使えます。請求書を発行したとき（INVOICED）、AWSが購入者から回収したとき（COLLECTED）、販売者に支払ったとき（DISBURSED）といった動きが、行として残ります。取引の種類（transaction_type）は、金額の中身を分けています。
transaction_type | 金額の意味 |
|---|---|
SELLER_REV_SHARE | 販売者が購入者との契約で設定した価格。正の金額 |
SELLER_TAX_SHARE | 販売者が納める税のために上乗せされた金額。正の金額 |
AWS_REV_SHARE | AWSに支払う手数料（listing fee）。負の金額 |
AWS_TAX_SHARE | AWSが回収して代わりに納める税。販売者の残高には影響せず、入金もされない |
{transaction_type}_REFUND | 購入者が要求した返金額 |
DISBURSEMENT | 販売者への入金。DISBURSEDの行で、残高に影響する場合 |
（出典：Billing eventデータフィード）
取引の種類ごとに金額が分かれているとおり、請求額と入金額のあいだには、手数料、税、返金による差が生じます。なお、手数料の率はAWS Marketplaceの手数料はいくら？で比べています。Billing eventデータフィードには、銀行が割り当てたトレースID（bank_trace_id）も記録されます。入金の取引では、bank_trace_idで銀行の明細と突き合わせられます。Billing eventデータフィードの各行は、Billed revenueダッシュボードの取引とも、transaction_reference_idで対応づけられます。（Billing eventデータフィード）入金先の口座と通貨の設定は、AWS Marketplaceの売上受取設定に分けてあります。
数字が合わないときの照合手順
合わない数字は、上流の段階から順に確かめます。四つの段階を一つずつ照合すれば、差が生まれた場所を絞り込めます。
- 日付の区切り方を揃えます。データフィードのCSVは日時をUTCで出力するため、自社の日次集計を日本時間で区切っていると、日付の境界で差が出ることがあります。（データフィードの構造）
- 契約ごとに分けます。Concurrent Agreementsでは、使用量は契約（LicenseArn）ごとに記録されます。Agreementsデータフィードの
license_idsで、agreement_idとLicenseArnを対応づけられます。（移行ガイド、Agreementsデータフィード）ただし、Daily Usageのagreement_idが空の行や、請求書の明細と一致しない行は、この対応づけができません。対応が確定しない行は、推測で一つのLicenseArnに割り当てません。 - 数量を突き合わせます。比べる単位は行ではなく、顧客、製品、ディメンション、日付、通貨の組です。Daily Usageの顧客は
end_user_account_id（ソルト付きハッシュ）で示されるため、Accountデータフィードと結合し、自社の顧客と対応づけてから比べます。組に含まれるすべての行の対応が確定していれば、自社の送信記録を契約ごとに合計し、契約単位でDaily Usageのusage_quantityと比べます。対応が確定しない行を一つでも含む組は、契約を区別せず、その組のDaily Usageの行と自社の送信記録をそれぞれ合計して比べ、差は未解決の差異として残します。 - 金額を検算します。
usage_quantityに単価を掛け、見積収益と一致することを確かめます。 - 請求を確かめます。従量課金は翌月の2日か3日以降に、Billed revenueダッシュボードで確定額を確認します。ただし、米ドル以外のPrivate Offerの従量課金は起算日ごとの請求書に載り、請求日が異なることがあります。その場合は、ダッシュボードのInvoice dateで請求の日付を確かめます。
- 入金を確かめます。Billing eventデータフィードのDISBURSEDの行と、銀行の明細を
bank_trace_idで照合します。
契約（LicenseArn）と契約の識別子（agreement_id）は別のものです。公式の移行ガイドによると、agreement IDは当事者間の商取引上の取り決めを表し、LicenseArnはソフトウェアを使う権利そのものを表します。将来の日付で始まる契約では、LicenseArnは契約の開始日に生成されるため、agreement IDが作られた時点より数か月あとになることがあります。（移行ガイド）なお、契約とSaaSテナントの対応づけは、AWS Marketplaceの契約をSaaSテナントに紐付けるには？の設計に関わります。
手順を一つずつ確認しても差が残るときは、症状から原因を調べます。
| 症状 | 考えられる原因 | 確認する場所 |
|---|---|---|
| Daily Usageの数量が自社の集計より少ない | 送信の漏れ。24時間の期限や月末の締め切りを過ぎた。解約、または自動更新しない契約の終了から1時間の期限（旧方式のAmazon SNSではunsubscribe-pending、新方式のAmazon EventBridgeではLicense Deprovisioned - Manufacturerの受信から）を過ぎた。Concurrent Agreementsに対応した製品では、期限は契約ごとにかかる。範囲外の記録でバッチ全体が処理されなかった。UnprocessedRecordsを再送していない。ResultsのStatusがSuccess以外で、受理されていない | 自社の送信結果、ResultsのStatus、AWS CloudTrail、BatchMeterUsageのエラー |
| 訂正したはずの数量が反映されていない | 同じ時間とディメンションへの再送は、数量を変えても最初の数量が請求される | 自社の送信順の記録、DuplicateRecordの応答 |
| Daily Usageの数量が自社の集計より多い | 移行中に、旧識別子（ProductCode）と新識別子（LicenseArn）の両方で、同じ時間に送った。公式に、重複請求になると明記されている | 送信コードの識別子、移行の手順 |
| 数量は合うが日付が一日ずれる | 日付の区切り方の違い。利用日と反映日の違い | usage_dateとUsage reported date |
| 見積収益と請求額が違う | 見積は月末まで確定しない。再販の場合は収益分配が未反映。米ドル以外のオファーは米ドル表示 | Billed revenueダッシュボード、請求書 |
agreement_idが空、または請求書と合わない | Daily Usageでは、agreement_idが空になったり、請求書の明細と一致しなかったりすることがあると公式に記載されている | offer_id、dimension_key、日付で絞る。確定できない行を含む組は、顧客、製品、ディメンション、日付、通貨の単位で、自社の送信記録も同じ単位に集約して照合し、差は未解決の差異として残す。推測で一つのLicenseArnに割り当てない |
| 請求額より入金額が少ない | 手数料、税、返金の差引。入金前の請求 | Billing eventデータフィードのtransaction_type、Disbursement status |
（出典：BatchMeterUsage、UsageRecordResult、メータリングの設定、Daily Usageデータフィード、Usageダッシュボード）
料金モデル別の確認先
従量課金の利用量を扱うのは、Daily UsageとUsageダッシュボードです。このうちUsageダッシュボードの対象は、SaaSやサーバーの従量課金の製品を使う顧客です。（Usageダッシュボード）そのため、すべての販売者が利用量のデータを確認する必要があるわけではありません。
| 料金モデル | 売上の確認先 | 利用量の確認先 |
|---|---|---|
| SaaS Contract | Billed revenue、Collections and disbursements | なし。SaaS Contractはメータリング記録を送らない |
| SaaS Subscription | Billed revenue、Collections and disbursements | 送信記録、Daily Usage、Usageダッシュボード |
| SaaS Contract with Consumption | Billed revenue、Collections and disbursements | 契約の権利を超えた分を、送信記録、Daily Usageで確認 |
（出典：メータリングの設定、SaaS契約。SaaS Contract with Consumption（従量制料金によるSaaS契約。契約の料金に加えて超過分を従量で請求する料金モデル）では、契約の権利を超えた分だけをメータリングします）
SaaS Contract（SaaS契約。契約期間と購入する権利をあらかじめ定め、前払いまたは支払スケジュールで請求する料金モデル）型の製品の契約や更新の動きは、Agreements and renewalsダッシュボードでも確認できます。このダッシュボードは、契約の締結から24時間以内の情報を提供します。（販売者向けダッシュボード）料金モデルの選び方は、AWS MarketplaceのSaaS料金モデルで比べています。
ダッシュボードとデータフィードの準備
ダッシュボードは、販売者のシステム管理者がInsightsからすぐに確認できます。それ以外の社員が閲覧できるようにするには、管理者がAWS IAMポリシーでダッシュボードごとにアクセスを許可します。（販売者向けダッシュボード）
一方、データフィードは、設定に一手間かかります。公式ガイドは、SQLとExtract, Transform, Load（ETL）の経験があるビジネスインテリジェンス（BI）担当かデータエンジニアを割り当てるよう案内しています。販売者アカウントのIDでAmazon S3バケットとデータフィードの購読を設定し、そのデータを自社のデータウェアハウスに取り込みます。（データフィードへのアクセス）データフィードは、前日の24時間分を毎日UTCの0時に配信し、当月のCSVファイルに追記します。（データフィードの概要、データフィードの構造）
購入者側のAWS Cost and Usage Report（CUR）と販売者の記録
販売者が送信した使用量は、購入者のAWS Billing and Cost Managementコンソールに、ディメンションごとの行として表示されます。購入者が有効にしていれば、CURにも単位あたりの単価まで表示されます。コンソールもCURも、リアルタイムでは更新されません。（メータリングの設定）
購入者のコンソールとCURで確認できるのは、購入者のアカウントに記録された使用量と請求です。販売者が自社のアプリケーションから送信した原本ではないため、送信履歴の確認には使いません。また、2026年10月5日時点では、CURは米ドルでの価格だけを報告します。（Usageダッシュボード）
自社の売上と、AWSへの収益寄与は別の系統
本記事で整理した四段階は、いずれも自社の販売と入金に関わる数字です。これとは別に、自社の製品が牽引したAWSサービスの消費を示すPartner Revenue Measurement（PRM）のAttributed Revenue（帰属収益）があり、こちらは自社の売上でも受取額でもありません。更新の時期も違い、前月分が月末から17日後にAWS Partner Centralのダッシュボードで確認できるようになります。二つを混ぜずに説明するための見方は、PRMの計測結果の確認と案件への紐付けで整理しています。
合わないときに先に確かめること
請求額と自社の集計が合わないとき、先に確かめるのは、二つの数字が四段階のどこに属するかです。段階を揃えて一つずつ照合すれば、差の出どころは送信か、集計か、請求か、入金かに絞れます。
Deshimaの対応範囲
2026年10月5日時点では、DeshimaはSaaS Contract型のみに対応しており、従量課金（メータリング）は対象外です。そのため、本記事で扱った使用量の送信、Daily Usageの照合といった作業は、Deshimaの提供範囲に含まれません。
Deshimaが提供している仕組みのうち、本記事に近いのは、明細とテナントの突合を支える部分です。購入者がAWSアカウントを再販業者（リセラー）から発行してもらっている場合、明細に記載されるアカウント保有者はリセラーになり、エンド顧客はアプリケーション側でしか判別できません。これは、Deshimaを提供する私たち株式会社アンチパターンが、自社SaaSの運用で確認した課題です。AWS Marketplace上の再販の仕組みであるChannel Partner Private Offer（CPPO）とは別の話で、CPPOはDeshimaの対象外です。Deshimaは、エンド顧客の情報、AWSアカウントID、アカウント保有者の情報を紐づけて保持する仕組みを提供しています。2026年10月5日時点で提供している機能は、掲載タスク一覧、日本語の掲載ガイド、AWSリソースの自動設定、利用申請フォームの四つです。売上と入金のレポートや管理の機能は、その時点の提供範囲に含まれていません。
Concurrent Agreementsには対応済みです。Deshimaの利用料は、初期費用と月額費用がどちらも0円で、費用が発生するのは製品が売れたときの販売手数料のみです。料率は個別にご提案しており、AWS Marketplace自体の手数料とは別になります。対応範囲はトップページのFAQに、料金の考え方は料金のセクションに記載しています。Deshimaは更新が多いため、最新の機能と対応範囲は、無料のアカウントを作成したうえで、プロダクト内のドキュメントでご確認ください。