AWS PRMの計測結果を確認するには？ダッシュボード・反映されない原因・案件への紐付け

Partner Revenue Measurement（PRM）を実装したあと、計測が有効になっているかを、どこで確かめればよいでしょうか。ダッシュボードを開くとAttributed Revenueがゼロで、設定の失敗なのか、集計を待つべき状態なのか、判断できない場面があります。この判断は、時間軸を分けると整理できます。

PRMは、AWS Marketplaceに掲載した製品が牽引したAWSの消費を、パートナーの帰属収益として計測する仕組みです。実装後は、Attributed Revenue Dashboard（帰属収益ダッシュボード）で、製品別・AWSサービス別・請求期間別の収益への影響を確認します。（PRMとは）

ここで混同しやすいのが、次の二つです。

• PRMが有効になっているかの確認：製品が計測の対象として現れたかどうか。Onboarding Status（オンボーディング状況）で見ます。
• 前月分の収益集計：月ごとに処理され、前月分が月末から17日後に利用可能になるAttributed Revenue（帰属収益）。

この二つは、別の状態であり、別の時間軸です。本記事では、ダッシュボードの見方、反映されないときの確認順、そして製品単位の計測結果を営業案件に対応付けるRevenue Attribution IDまでを扱います。

本記事の内容は、2026年10月29日に確認したAWSの公式ガイドにもとづきます。画面名や提供の時期は変わることがあるため、運用に組み込む前に各出典で最新の内容をご確認ください。PRMとは何か、2027年の資金支援との関係はPRMの概要と2027年の資金支援との関係で、実装方式の比較と設定はPRMの実装方式の比較と設定で整理しています。

Attributed Revenue Dashboardで確認できるもの

Attributed Revenue Dashboardは、AWS Partner Central（AWSコンソール）のPartner Analytics配下にあります。（Attributed Revenue Dashboard）画面は、主要な三つの指標、絞り込みのフィルター、二つのグラフ、二つのテーブルで構成されています。

（出典：Attributed Revenue Dashboard）

ダッシュボードを使うには、二つの前提条件があります。一つは、AWSコンソールの新しいAWS Partner Centralへ移行していることです。もう一つは、Resource Tagging（リソースタグ付け）かUser Agent String（ユーザーエージェント文字列）のいずれかを実装しているか、Amazon Machine Image（AMI）またはMachine Learning（ML）の製品をAWS Marketplaceに掲載していて、自動のAWS Marketplace Meteringで計測されることです。複数の子会社アカウントをAWS Partner Centralに接続しているパートナーは、接続したすべてのアカウントを合算した一つのビューで確認します。（Attributed Revenue Dashboard）

なお、ダッシュボードで見られるのは、製品とAWSサービスの単位に集計された収益です。公式の顧客向けFAQは、パートナーに渡るのは全顧客を通じた集計値のみで、個々の顧客に固有のPRMデータはパートナーに共有されないと明記しています。（顧客向けFAQ）フィルターにAWS Account IDが含まれていても、ダッシュボードを顧客ごとの請求明細の代わりと考えてはいけません。顧客単位の情報が必要な場面では、自社で案件に入力する情報や、自社が購入時に受け取った契約の情報を使います。

Products Measured・AWS Services Measured・Total Attributed Revenueの見方

主要な三つの指標は、次の定義で表示されます。

（出典：Attributed Revenue Dashboard）

Total Attributed Revenueは、AWS Marketplaceの売上ではありません。PRMが測るのは、パートナーの製品が牽引した、AWSのサービスの消費です。（PRMとは）自社の売上や入金は、AWS Marketplaceの販売者向けレポートで確認します。この区別は、AWS Marketplaceの売上、利用量レポートで整理した四段階のデータ（送信記録、Daily Usage、請求、入金）と、PRMの帰属収益が別の系統であることを意味します。事業レビューで数字を並べるときは、自社の売上とAWSへの寄与を、別の指標として扱ってください。

AWS Service別のグラフを読むときは、対象サービスの範囲にも注意が必要です。Resource Taggingでは、対象外のサービスで捕捉された一部の支出がOtherに、User Agent方式ではMiscに集約されると、公式ガイドは説明しています。（Resource Taggingの対象サービス、User Agent方式の対象サービス）二つの方式では対象サービスの一覧が一致しません。そのため、自社が採用した方式の一覧を、方式ごとに確認します。

Onboarding Statusと月次のAttributed Revenueを分けて確認する

Onboarding Statusのテーブルには、Product Name、PRM Capability、Statusが並びます。PRM Capabilityは、Resource Tagging、User Agent string、AWS Marketplace Meteringのいずれかです。Statusは、その機能が実際に収益を計測しているかどうかを示します。（Attributed Revenue Dashboard）一方、Attributed Revenueのテーブルとグラフは、請求月ごとの金額です。

この二つは、見ているものも、時期も違います。時期については、Foundational Technical Review（FTR）の申請ガイドとダッシュボードのガイドに、別々の記述があります。FTRは、AWS Marketplaceに掲載したソフトウェアのソリューションが、セキュリティ・信頼性・運用の基準を満たすかをAWSが検証する仕組みです。（FTRの申請ガイド）

（出典：FTRの申請ガイド、Attributed Revenue Dashboard）

FTRの申請ガイドは、PRMを有効にしてから計測データが現れるまで最大7日かかると説明しています。そして、製品がAttributed Revenue Dashboardにオンボーディング済みの製品として現れた時点で、PRMに関するチェックが完了します。この記載は、FTRの申請経路に含まれる前提条件の一つです。（FTRの申請ガイド）すべてのAWS Marketplace掲載に共通する条件ではありません。なお、この7日は、FTRの申請ガイドに記載された、計測データが現れるまでの上限の目安です。

一方、ダッシュボードのガイドは、帰属収益のデータが月次で処理され、前月分が月末から17日後に利用可能になると説明しています。（Attributed Revenue Dashboard）月末が31日でも30日でも、月が終わってから17日目、つまり翌月17日前後が、前月分の確認時期の目安です。

したがって、設定の直後にAttributed Revenueがゼロでも、それだけでは失敗とは言えません。まずOnboarding Statusで、製品が現れているかを確認します。製品が現れていれば、有効化は確認できており、金額は月次の処理を待つ段階です。製品が現れていなければ、設定の側を調べます。どちらの状態なのかを判断してから、次の確認順に進みます。

PRMを有効にする
   ↓  最大7日（FTRの申請ガイドの記載）
Onboarding Statusに製品が現れる（有効化の確認）
   ↓  月が終わる
月末から17日後に、前月分のAttributed Revenueが利用可能になる（収益の集計）

7日と17日は、別々のガイドに書かれた別々の時期です。二つを足した日数が保証されているわけではないため、実際の状況はダッシュボードで確認してください。

データが反映されないときの確認順

反映されない症状は、四つに分けて確認すると原因を絞り込めます。

（出典：PRMのトラブルシューティング、Attributed Revenue Dashboard）

製品の計測が有効にならないとき

最初に確認するのは、実装の前提です。AWS Partner CentralにAWSアカウントをリンクしていること、AWS Cost Explorerが有効であること、AWS Marketplaceに製品が掲載されていることが前提条件です。（Resource Taggingの前提条件）そのうえで、Resource Taggingなら、次の点が公式のトラブルシューティングの確認項目です。

• タグキーが aws-apn-id-{{partner-central-aws-account-id}}（または旧来の aws-apn-id）の形式になっているか
• Partner CentralにリンクしたAWSアカウントIDが正しいか
• タグの値が pc:product-code の形式か
• Product CodeがAWS Marketplaceの掲載と一致しているか

User Agent方式では、APN_1.1/pc_<YOUR-PRODUCT-CODE>$ の形式と完全に一致しているかを確認します。形式の誤りとして、公式のトラブルシューティングには、終端の $ が省略された、またはシェルに処理されて剥がされた例、接頭辞の誤り、Product CodeではなくProduct IDやUUIDを使った例が挙がっています。（PRMのトラブルシューティング）Product Codeは、AWS Marketplace Management Portalで製品を選び、Product Summaryから取得します。これらの設定値と手順は、PRMの実装方式の比較と設定で整理しています。

有効なのに収益が表示されないとき

Onboarding Statusに製品が現れているのに金額が出ないときは、まず、見ている請求月が集計の提供時期を過ぎているかを確認します。前月分は月末から17日後に利用可能になるため、その前であれば、設定の不足とは区別できます。

提供時期を過ぎていても金額が出ないときは、次の点を順に確認します。

1. 対象のサービスか：自社の製品が使っているAWSサービスが、採用した方式の対象一覧に含まれているか。対象外のサービスで捕捉された一部の支出は、Resource TaggingではOther、User Agent方式ではMiscに集約されます。対象外のサービスの支出が全額計測されるわけではないため、OtherやMiscの金額を、対象外サービスの支出の総額として読むことはできません。
2. 実際に課金が発生する消費か：リソースが実際にAWSサービスを消費して課金されているか。AWS IAMのような無料のサービスは、タグを付けても帰属が生まれません。（PRMのトラブルシューティング）
3. 月ごとのAPI操作があるか：User Agent方式では、リソースに対するAPI操作が月に1回以上必要です。その月に操作がないリソースは、その月の帰属に寄与しません。（User Agent方式）
4. コントロールプレーンのAPIか：User Agent方式の対象は、管理（コントロールプレーン）のAPIのみで、データプレーンの操作は対象外です。（User Agent方式の対象サービス）
5. AWS Marketplace Meteringの場合：帰属が出ない主な原因は、顧客がAWS Marketplace経由で購入・利用していないことです。（AWS Marketplace Metering方式）

User Agentが見つからないとき

User Agent方式では、実際に送信されている値を、AWS CloudTrailのログで確認します。公式のトラブルシューティングには、次の確認手順が記載されています。

1. 1つのサービスクライアントだけでなく、正しいAWS SDKのクライアントの設定に適用されているか
2. 終端の $ がシェルやランタイムに剥がされていないか
3. AWS CloudTrailが有効で、該当のリージョンで該当のAPIを記録しているか
4. AWS CloudTrailのイベントの userAgent フィールドに、文字列が入っているか

AWS CloudTrailのログからの確認には、公式ガイドに次のコマンドの例が記載されています。

aws logs filter-log-events \
  --log-group-name CloudTrail/YourLogGroup \
  --filter-pattern "APN_1.1" \
  --start-time 1640995200000

これは公式ガイドに記載された形式の例です。ロググループ名と開始時刻は、自社の環境に合わせて置き換えてください。実際に送信される値は、使用しているAWS SDKのバージョンによって変わり得るため、自社の環境のAWS CloudTrailで確かめます。（PRMのトラブルシューティング、User Agentの自動設定）

AWSに計測の判定を問い合わせるとき

自社で確認しても原因が分からないときは、AWSのパートナー担当、またはAWS Partner Network（APN）のサポート窓口であるAPN Supportに問い合わせます。計測が有効かどうかの判定は、AWS側の確認事項であり、Deshimaでは代行できません。公式の検証の依頼では、AWSアカウントID、リージョン、Product Code、サンプルのリソースARNを伝え、タグのスクリーンショットかAWS CloudTrailのログの抜粋と、テストを実施した時刻を添えます。回答までには、3〜5営業日かかります。AWS Marketplace Meteringで問題がある場合は、AWSアカウントID、Product Code、製品タイプ、事象と期待する動作を添えて、APN Supportにチケットを起票します。（PRMのトラブルシューティング）

製品の合計を案件に対応付けたいとき

製品単位の計測結果を営業案件に対応付けたい場合は、確認の対象がダッシュボードの外に広がります。Revenue Attribution ID、対象のOfferまたはOpportunity、請求月、必要な配分の情報を揃えます。この仕組みは、次の節で説明します。

Revenue Attribution IDとは何か、製品単位のPRMと何が違うか

製品の合計は確認できても、その収益が、どの営業案件に由来するのかは、ダッシュボードの製品別・AWSサービス別の集計だけでは分かりません。案件との対応付けに使うのが、Revenue Attribution ID（収益帰属ID）です。

公式のガイドは、Revenue Attribution IDを案件単位の識別子と説明しています。AWS Marketplaceの製品収益を、特定のAWS Marketplace Offer（オファー）や、AWS Partner CentralのOpportunity（案件）に対応付けます。IDは ra- で始まり、例として ra-aabbccddee001 のような形式です。（Revenue Attribution IDと案件の対応付け）

製品単位のPRMの上に載る仕組み

Revenue Attribution IDは、製品単位のPRMの実装の上に載る仕組みです。PRMが製品の帰属収益の合計を捉え、Revenue Attribution IDが、指定した月別のコスト配分率に従って、その収益を個別の案件に割り当てます。（Revenue Attribution IDと案件の対応付け）

二つの使い方

Revenue Attribution IDには、二つの使い方があります。

1. 既存の製品単位の実装への上乗せ：Revenue Attribution IDを作り、対象のAWS Marketplace OfferやOpportunityを関連付けます。すでに計測されている製品の収益が、その案件に対応付けられます。この場合、既存のリソースタグやUser Agentの変更は不要です。
2. 単独の識別子としての利用：リソースタグの値に aws-apn-id = <RA ID>、またはUser Agentに APN_1.1/pc_<RA ID>$ を直接使い、最初から案件単位でAWSの消費を帰属させます。

（出典：Revenue Attribution IDと案件の対応付け）

PRMの実装方式の比較と設定で扱ったのは、通常のProduct Codeを使う方式です。Revenue Attribution IDを、タグやUser Agentの値に直接使う二つ目の方法は、そこでは扱っていません。案件単位で最初から帰属させたいのか、製品単位で計測した合計を後から案件に割り振りたいのかで、選ぶ方法が変わります。

Product Codeとの違い

似た名前の識別子が複数あるため、整理しておきます。

（出典：Product Codeの取得、Revenue Attribution IDと案件の対応付け、PRMのトラブルシューティング）

Product Codeの代わりにProduct IDやUUIDを使うことは、Product Codeの不一致の原因として、公式のトラブルシューティングに挙がっています。Revenue Attribution IDのAPIは、レスポンスの中でProduct Codeを解決して返します。

共有基盤のSaaSでOffer・ACE案件と月別配分を管理する

多くのSaaSは、複数の顧客（テナント）が同じAWSの基盤を共有しています。この場合、共有基盤で計測されたAWSの消費は、製品単位の合計としてしか捉えられません。その合計を、顧客ごとのOfferやAPN Customer Engagements（ACE）の案件に対応付けるには、月ごとの配分を決めて登録する必要があります。ACEは、AWSと安全に案件を共有して共同で営業するための枠組みです。（AWS Marketplace掲載後の共同販売）

登録の流れ

登録は、AWS Partner CentralコンソールのSellメニューにある、Revenue attributionから行います。手順は三つです。

1. AWS Marketplaceの製品を選びます。子会社のアカウントの製品は、Marketplace product IDを手入力します。複数の製品が同じAWSリソースを共有している場合は、製品を選ばずに進めることもできます。その場合は、Revenue Attribution IDで計測されたすべての消費が対象になります。
2. OfferまたはOpportunityを関連付け、月ごとの配分率を入力します。
3. 内容を確認して送信します。

同じ操作は、APIでも行えます。たとえば、CreateRevenueAttribution、StartRevenueAttributionAllocationsTask（非同期で、1タスクあたり最大250件の作成と更新）などのAPIが用意されています。毎月の配分を登録する作業が多い場合は、APIによる自動化を検討します。（Revenue Attribution IDと案件の対応付け、Revenue Attribution IDの作成と月別配分）

エントリの項目

月別の配分は、エントリとして登録します。1件のエントリが、OfferまたはOpportunityと、Billing Month（請求月）の組み合わせ1つに対する配分率です。

（出典：Revenue Attribution IDの作成と月別配分）

Cost Allocation %は、マルチテナントSaaSで必須です。また、同じ請求月に2件以上の案件の関連付けが同時に有効な場合にも必須です。複数の月にまたがる案件は、月ごとに1件のエントリを追加します。

説明のための例

共有基盤で計測されたAWSの消費のうち、対象の月に、案件Aへ60%、案件Bへ40%を配分するケースを考えます。

この例は、仕組みを説明するための仮定です。SaaSの販売額の比率を、そのままコスト配分率に使うことを推奨するものではありません。実際の配分の根拠、必要な顧客のAWSアカウント情報、案件の状態は、自社の構成とAWSの要件に従って決めてください。

配分のルールと編集の期限

配分には、次のルールがあります。

• 同じRevenue Attribution IDの、同じ請求月のCost Allocation %の合計は、100%を超えられません。超えると、非同期の業務検証で、そのエントリが却下されます。
• 当月と将来の月のエントリは、いつでも追加・更新できます。当月・将来の月の更新は、次の月次請求サイクルから適用されます。
• 前月のエントリは、当月7日まで更新できます。この猶予は、AWS Cost Explorerで実際の使用量を確認してから、前月分の配分を確定するためのものです。
• 7日を過ぎると、前月分の帰属は変更できません。過去の月の帰属は、遡って再計算されません。

（出典：Revenue Attribution IDの作成と月別配分）

ここで、時間軸を見直す必要があります。ダッシュボードで前月分の集計が利用可能になるのは月末から17日後で、前月分の配分を更新できる期限（当月7日）より後です。そのため、配分を確定する時点では、ダッシュボードの前月分を見られません。公式ガイドが期限までの確認先として挙げているのは、AWS Cost Explorerです。月ごとの担当と締めの日を、あらかじめ決めておく必要があるのは、このためです。

自社側で保持しておく情報

AWSに入力する配分の根拠は、自社側のデータから作ります。共有基盤で案件別の配分を設計するときは、少なくとも、次の対応を自社で追えるようにしておきます。

これらは、AWSが指定する構造ではなく、本記事の設計案です。テナントと契約の対応の持ち方は、AWS Marketplaceの契約をSaaSテナントに紐付けるには？で整理しています。同じAWSアカウントが複数の契約を結べる場合の扱いも、そちらで説明しています。

AWSとの事業レビューで説明する指標と運用の担当

AWSとの事業レビューで説明する指標は、次の三つの層に分けると整理しやすくなります。

自社の売上や入金は、これらとは別に、AWS Marketplaceの販売者向けレポートで確認します。二つを混ぜずに説明するための考え方は、AWS Marketplaceの売上、利用量レポートにあります。AWSと案件を共有して進める共同販売の枠組みは、AWS Marketplace掲載後の共同販売で整理しています。

運用では、次の三つの役割に分けて、担当を決めておきます。

月ごとの流れは、次のようになります。

PRMの値は、2027年から、AWS Partnerの資金支援の特典を判定するために使われると、AWSのブログ（2026年9月30日公開）は説明しています。（新しいAttributed Revenue Dashboardの紹介）対象のプログラムや適格性の基準は、そのブログには記載がありません。詳細は、PRMの概要と2027年の資金支援との関係で整理しています。PRMの値が増えれば資金支援額も自動的に増える、と読むことはできません。計測の状態や資金支援との関係で、AWS側の判定が必要な点は、AWSのパートナー担当にご確認ください。

計測したデータを共同販売に活用する方針を整理する

計測したデータを、AWSとの共同販売や事業レビューにどう活用するかは、PRMの設定とは別の検討事項です。有償オプションのプロフェッショナルサービスでは、AWS Marketplace掲載方針の設計と、AWSとのCo-Sellのアドバイザリーを提供しています。計測結果をどの案件の説明に使うか、AWSの営業とどう連携するかといった方針の整理を、ご相談いただけます。内容と期間に応じて、個別にお見積りします。なお、PRMの実装の代行や、計測が有効かどうかの判定の代行は、提供の範囲に含まれません。

Deshimaの対応範囲

Deshimaは、SaaS Contract（SaaS契約。契約期間と購入する権利をあらかじめ定め、前払いまたは支払スケジュールで請求する料金モデル）型の製品について、AWS Marketplaceへの掲載準備、購入者と契約の情報の取得と同期、利用申請フォーム、Amazon EventBridgeへのイベント発行を担います。従量課金（メータリング）とChannel Partner Private Offer（CPPO）は対象外です。Concurrent Agreementsには対応済みです。

本記事で扱った、PRMのタグ付けやUser Agentの設定、Revenue Attribution IDの登録と月別の配分、Attributed Revenue Dashboardの運用は、Deshimaの機能には含まれません。Deshimaが取得して同期する購入者と契約の情報は、自社側で、テナントと契約の対応を持つときの入力として使えます。その対応を案件の配分にどう使うかは、自社の側で設計します。

Deshimaの利用料は、初期費用と月額費用がどちらも0円で、費用が発生するのは製品が売れたときの販売手数料のみです。料率は個別にご提案しています。対応範囲はトップページのFAQに、料金の考え方は料金のセクションに記載しています。

Deshimaは更新が多いため、最新の機能と対応範囲は、無料のアカウントを作成したうえで、プロダクト内のドキュメントでご確認ください。