販路拡大とサービス選定
AWSのPartner Revenue Measurement（PRM）とは？仕組みと2027年のパートナー支援への影響
公開日:
この記事の要点
Partner Revenue Measurement（PRM）は、AWSが、パートナーの製品が牽引したAWSサービスの消費を計測し、製品別・AWSサービス別・請求期間別の収益寄与（Attributed Revenue）として示す仕組みです。自社のSaaS売上やAWS Marketplaceの取引額とは別の数値で、パートナーの売上や受取額ではありません。AWSのパートナー向けブログによると、2027年からPRMのAttributed Revenueはパートナー向け資金支援の判定に使われ、新しい要件は2027年を通じてプログラムごとに展開されます。ただし、対象のプログラムやしきい値は、2026年10月29日時点のブログには書かれていません。AWS Marketplaceへの掲載だけでは計測は完了しないため、アカウントのリンク、AWS Cost Explorerの有効化、計測方式の選択と担当部署の決定を先に進めます。
AWSのパートナー向けに「PRM」という言葉が出てきたとき、顧客管理の文脈で使われるPartner Relationship Managementを思い浮かべる方もいるかもしれません。この記事で扱うのは、AWSが提供するPartner Revenue Measurement（PRM）です。パートナーの製品が牽引したAWSサービスの消費を計測し、収益寄与として示す仕組みです。（PRMとは）
2026年9月30日に公開されたAWSのパートナー向けブログは、2027年からこの数値がパートナー向けの資金支援の判定に使われると説明しています。（AWSパートナー向けブログ）そのため、SaaS事業責任者やAWSアライアンス担当は、「自社の売上管理と何が違うのか」「何を準備すればよいのか」を、早めに判断する必要があります。
この記事は、PRMの入口として、何を測る仕組みで、なぜ今準備するのかを整理します。内容は、2026年10月29日に確認したAWSの公式ドキュメントとブログにもとづきます。計測方式の実装はPRMの実装方式の比較と設定で、計測結果の確認と案件への紐付けはPRMの計測結果の確認と案件への紐付けで扱います。
PRMとは何を測る仕組みか
PRMは、パートナーが収益寄与を測り、自社の貢献を示し、AWSとの協業の機会を広げるための機能群です。AWSの説明によると、パートナーと顧客の双方のAWSアカウントにわたる、実際のAWSサービスの消費にもとづいて、パートナーの貢献を可視化します。（PRMとは）
測る対象は、パートナーの販売額ではありません。パートナーの製品が動かしているAWSリソースと、そのリソースが消費したAWSサービスの使用額です。実装後は、Attributed Revenue Dashboardで、製品別、AWSサービス別、請求期間別に収益寄与を確認できます。（PRMとは）
PRMのガイドが公開されたのは2026年1月29日で、当初の方式はResource Tagging（リソースタグ付け）だけでした。2026年4月2日に、User Agent String（ユーザーエージェント文字列）とAWS Marketplace Meteringが方式として加わり、ガイドは方式別の構成に改められました。（ドキュメント履歴）その後も、対象サービスの追加や、複数のパートナーが同じリソースを計測できる仕組みの追加が続いており、仕様は更新の途上にあります。
PRMは、顧客の環境に影響を与えない仕組みとしても説明されています。AWSの顧客向けFAQによると、顧客の環境にインストールするソフトウェアはなく、性能への影響や請求の構造の変更もありません。パートナーに渡るのは、全顧客を合算した、集計済みの収益寄与の数値だけです。個々の顧客に固有のPRMのデータは、パートナーに共有されません。（顧客向けFAQ）顧客の環境にタグを付ける方式を使う場面では、この説明を顧客への案内に活用できます。
なお、PRMは、2026年10月29日時点では、コマーシャルリージョンのみが対象です。ソブリンクラウドや政府向けのリージョンへの拡大は、今後の予定として案内されています。（顧客向けFAQ）
自社の売上・AWS Marketplaceの取引額・AWSへの寄与の違い
「売上」と名前の付く数値が複数あるため、PRMのAttributed Revenueを自社の売上と取り違えてしまうかもしれません。PRMのAttributed Revenueは、自社製品に帰属するAWSサービスの消費にもとづく収益寄与で、自社の売上や受取額ではありません。AWSの消費を測る数値なので、顧客に請求した金額とは、測っている対象が違います。
APN Customer Engagements（ACE）は、AWSと安全に案件を共有して、共同で営業するための枠組みです。四つの数値の違いは、次のとおりです。
| 項目 | 何を表すか | 主な用途 |
|---|---|---|
| SaaS売上 | 顧客に提供する自社サービスの販売額 | 自社事業の売上管理 |
| AWS Marketplaceの販売レポート | AWS Marketplaceでの取引・請求・送金など | 販売と入金の把握 |
| PRMのAttributed Revenue | 自社製品に帰属するAWSサービス消費に基づく収益寄与 | AWSとの協業やPRMの評価・運用 |
| ACE案件 | AWSと共有する営業案件 | 共同販売の案件運用 |
AWS Marketplaceの販売レポートの見方は販売レポートの記事で、共同販売の案件運用は共同販売の記事で扱っています。
この四つは、更新の時期も違います。AWS Marketplaceの販売レポートは取引や請求にもとづき、ACEの案件は営業の進行に合わせて更新します。一方、PRMのAttributed Revenueは月次で処理され、前月分が月末から17日後に提供されます。（Attributed Revenue Dashboardの仕様）そのため、PRMの数値は、当月の状況を確認する用途には使えません。
PRMの数値には、もう一つ注意点があります。同じAWSリソースに複数のパートナーがタグを付けた場合は、タグを付けたそれぞれのパートナーに収益寄与が帰属されます。（Resource Taggingの実装）したがって、各社に帰属した数値を合算しても、AWSの総売上として読むことはできません。Attributed Revenueは、自社製品がAWSの消費にどれだけ寄与しているかを示す指標として扱います。
AWSが説明する2027年の資金支援との関係
PRMを今から準備する理由は、AWSのパートナー向けブログにあります。ブログによると、2027年から、PRMのAttributed Revenueが、AWSのパートナー向け資金支援の判定に使われます。新しい要件は、2027年を通じて、プログラムごとに展開されると説明されています。（AWSパートナー向けブログ）
ブログが述べているのは、ここまでです。その影響で、2026年10月29日時点のブログには、どのプログラムや特典が対象なのか、適格性のしきい値がいくらなのかは書かれていません。一律の期日や支援額も示されておらず、PRMを実装すれば資金支援を受けられるという説明でもありません。各プログラムの要件は、2027年を通じて順次示される予定のため、AWSの案内で確認する必要があります。
ブログは、準備の進め方として、最も利用されている製品や、サービスデリバリーの案件から、PRMの適用範囲を広げることを勧めています。始めるために必要なものとして、次の三つが挙げられています。（AWSパートナー向けブログ）
- 公開済みのAWS Marketplaceの掲載
- AWSアカウントとAWS Partner Centralアカウントのリンク
- 3つの計測方式のうち、1つ以上の実装
PRMの準備が、すでに別の手続きの前提条件になっている例もあります。Foundational Technical Review（FTR）の申請経路のうち、SOC 2 Type IIレポートまたはAWS Well-Architected Frameworkレビューのレポートを提出する経路では、前提条件の一つに、AWS Marketplace製品でPRMが有効になっていることが含まれます。この条件は、製品がAttributed Revenue Dashboardに計測済みの製品として表示されたときに満たされ、PRMを有効にしてから計測データが表示されるまでに、最大7日かかることがあります。（FTRの申請）これは、この申請経路の前提条件であり、AWS Marketplaceに掲載するすべての製品に共通する必須条件ではありません。ただし、PRMの設定が他の手続きの待ち時間を左右し得ることを示す例として、準備の時期を決めるときの参考になります。
共同販売への影響は、AWS Marketplace掲載後の共同販売で整理した、ACEやISV Accelerateの条件と併せて確認します。掲載そのものの利点と負担は、AWS Marketplaceに出品するメリットと注意点にまとめています。
自社アカウントで動かすSaaSと、顧客環境に入る製品で異なる計測対象
PRMが測るのは、製品が動かすAWSリソースの消費なので、そのリソースがどのAWSアカウントにあるかで、計測の考え方が変わります。AWSの公式ガイドは、製品のアーキテクチャを、次の三つのパターンで整理しています。（開始手順）
| パターン | 構成 | 典型的な製品 |
|---|---|---|
| Pattern #1 Partner Account | すべての構成要素が、パートナーのAWSアカウントとAmazon Virtual Private Cloud（Amazon VPC）内にある | 自社のAWSアカウントでSaaSを運用する場合 |
| Pattern #2 Customer Account | すべての構成要素が、顧客のAWSアカウントとAmazon VPC内にある | 顧客の環境にデプロイして使う製品 |
| Pattern #3 Hybrid | 構成要素が、両方のアカウントに分かれている | 顧客環境のエージェントと、自社の管理基盤を組み合わせる製品 |
三つのパターンは公式ガイドの分類で、典型的な製品として挙げたものは、この分類を製品に当てはめた例です。
自社のAWSアカウントでSaaSを運用する場合は、計測の対象が自社のアカウントのリソースになります。この場合、顧客のアカウントに手を入れる必要がないため、タグの付与や、アプリケーションのAWS API呼び出しの設定は、自社の管理の範囲で進められます。複数の顧客が同じ基盤を共有するマルチテナントSaaSでは、顧客ごとの収益寄与を案件に対応付ける段階で、Revenue Attribution IDの設定が関わります。この設定は、計測結果の確認と案件への紐付けで扱います。
顧客の環境に入る製品では、計測の対象が顧客のアカウントのリソースを含みます。その場合は、顧客との調整が必要になります。顧客向けFAQには、次の点が記載されています。（顧客向けFAQ）
- パートナーがタグを付けられるのは、顧客が明示的に付与したAWS IAMの権限の範囲内だけで、顧客はその権限をいつでも取り消せる
- PRMは、顧客のアカウント、リソース、アプリケーションのコードへのアクセスをAWSやパートナーに与えない
- タグは、1つのリソースに最大10パートナー分を付けられ、それぞれが顧客のユーザー定義タグの50個の枠のうち1つを使う
- AWS Organizationsのタグポリシーを使っている顧客は、タグキーを許可する更新を一度行う必要がある
- タグが環境に合わない顧客には、タグを必要としないUser Agent String方式を依頼できる
タグは、顧客や権限を持つ利用者が削除するか、リソースが終了するまで残り、削除すると収益寄与は止まります。顧客の環境を計測対象に含める場合は、導入時の説明に加えて、タグが消された場合にどう検知して再付与するかも、運用の取り決めに含めておく必要があります。
製品の掲載、AWS Partner Centralとのアカウント連携、対象AWSサービスを確認する
計測方式を選ぶ前に、前提条件を満たしているかを確認します。公式ガイドが挙げる前提条件は、次のとおりです。（前提条件）
- AWS Partner CentralとAWSアカウントがリンクされている
- 製品がAWS Marketplaceに掲載されている
- 製品が、対象のAWSサービスを1つ以上使っている
- AWS Cost Explorerが有効になっている
AWS Partner CentralとのAWSアカウントのリンクでは、リンクしたAWSアカウントが、AWS Partner CentralでのAWS Partner Network（APN）の活動のprimary account（主アカウント）になります。このアカウントは、AWS Partner Network（APN）の資金支援の適格性におけるPRMコンプライアンスの判定にも使われます。つまり、PRMの計測結果が資金支援の判定に使われる場合、判定の単位になるのは、リンクしたAWSアカウントです。また、このアカウントには、年次のAPNメンバーシップ費用も請求されます。AWS Marketplaceのアカウントが複数ある場合、AWSは、グローバル事業を代表する新しいAWSアカウントを作成してリンクし、各AWS MarketplaceアカウントをSubsidiary Account Connections（子会社アカウントの接続）でprimary accountに接続することを推奨しています。（前提条件）判定のアカウントと請求先が、どのAWSアカウントになるかに関わるため、PRMの実装より前に、リンクするアカウントを社内で決めておきます。
AWS Cost Explorerの有効化は、見落としやすい項目です。公式ガイドは、前提条件として、AWS Cost Explorerが有効であることを確認するよう記載しています。（前提条件）自社のAWS組織で、AWS Cost Explorerを誰が管理しているかを、事前に確認してください。
対象のAWSサービスの確認も、前提条件に含まれます。Resource Taggingの対象には、Amazon EC2、Amazon RDS、Amazon S3、AWS Lambda、Amazon ECS、Amazon DynamoDB、Amazon SageMaker AIなど、多数のAWSサービスが含まれます。ただし、Amazon S3はストレージ費用のみでリクエストは除かれるなど、サービスごとに対象の範囲が限られています。（Resource Taggingの対象サービス）User Agent Stringの対象は、2026年8月31日の更新で24から119のAWSサービスに拡大され、管理（コントロールプレーン）のAPI呼び出しだけが対象で、データプレーンの操作は対象外です。（User Agent Stringの対象サービス）二つの方式で、対象のAWSサービスの一覧は一致しないため、採用する方式ごとに、自社の製品が使うAWSサービスが対象に含まれるかを確認します。対象外のサービスの一部の支出は、Resource Taggingでは「Other」、User Agent Stringでは「Misc」に集約されます。
さらに、AWS Marketplaceに登録した製品のProduct Code（製品コード）が、すべての方式で必要です。Product Codeは、AWS Marketplace Management Portalの製品の概要から確認でき、Product ID（製品ID）とは別の値です。（Product Codeの取得）取得の手順と取り違えの防ぎ方は、実装方式の比較と設定で扱います。
計測結果を確認するAttributed Revenue Dashboardを使うには、AWSコンソール上の新しいAWS Partner Centralへ移行していることも前提です。（Attributed Revenue Dashboardの仕様）
3つの計測方式を選び、担当部署を決める
PRMの計測方式は三つあります。（開始手順）
| 方式 | 内容 | 主な対象・留意点 |
|---|---|---|
| AWS Marketplace Metering | 追加の設定なしで収益寄与を帰属させる、自動の方式 | Amazon Machine Image（AMI）製品とMachine Learning（ML）製品が対象。顧客がAWS Marketplace経由で購入して使うことが前提 |
| Resource Tagging | AWSリソースに、Product Codeを含むタグを付ける | タグは、削除されるかリソースが終了するまで有効。Infrastructure as Code（IaC）で管理するリソースは、IaCのツールでタグを付ける |
| User Agent String | AWS APIやCLIの通常の呼び出しに、決まった形式の文字列を含める | 管理（コントロールプレーン）のAPIが対象で、データプレーンは対象外。リソースへのAPI操作が月に1回以上必要 |
AWS Marketplace Meteringは、AMI製品とML製品を対象とした、追加の入力が要らない方式です。SaaSは、この方式の対象として記載されていません。SaaSのBatchMeterUsageは、顧客に従量課金を請求するためのAPIで、PRMの自動計測とは別のものです。（AWS Marketplace Metering方式）SaaS製品がPRMに対応するときは、Resource TaggingとUser Agent Stringのどちらか、または両方を実装します。SaaS Contract（SaaS契約。契約期間と購入する権利をあらかじめ定め、前払いまたは支払スケジュールで請求する料金モデル）のように従量課金のAPIを使わない製品でも、PRMの方式の選択は必要です。従量課金（メータリング）の実装は、SaaSのメータリングで扱っています。
方式の選択は、公式ガイドが示す三つの観点で絞り込めます。（開始手順）
- 製品が使うAWSサービスが、方式ごとの対象に含まれるか
- AWS Marketplaceに、SaaS、AMI、ML、Professional Servicesのどれを掲載しているか
- 製品が、Pattern #1、#2、#3のどれに当たるか
方式を選んだら、担当部署を決めます。方式ごとに、変更が必要な場所が違うためです。次の表は、AWSが定めた役割分担ではなく、方式ごとの作業内容から割り出した担当部署の例です。
| 作業 | 担当部署の例 |
|---|---|
| AWS Partner CentralとAWSアカウントのリンク、AWS Cost Explorerの有効化 | アライアンス担当と、AWSアカウントの管理者 |
| Resource Taggingの実装 | インフラ担当（AWS CloudFormation、Terraform、AWS Cloud Development Kit（AWS CDK）などのIaCを管理する担当） |
| User Agent Stringの実装 | アプリケーションの開発担当（AWS SDKの設定を管理する担当） |
| Product Codeの確認、掲載内容との整合 | AWS Marketplaceの掲載を管理する担当 |
| 顧客環境へのタグ付けの合意 | 顧客対応の担当（カスタマーサクセスや導入支援） |
計測を始める製品の順番は、ブログの推奨に沿って、最も利用されている製品や、サービスデリバリーの案件から決めます。複数の製品を掲載している場合は、全製品を一度に実装するのではなく、順に適用範囲を広げます。
実装の詳細は、PRMの実装方式の比較と設定で扱います。タグキーの形式、User Agentの設定値、検証の手順は、そちらの記事をご確認ください。
今着手する準備のチェックリスト
PRMの準備は、AWS Marketplaceへの掲載の有無によって、最初の一手が変わります。
まだ掲載していないSaaS企業
PRMの前提条件には、AWS Marketplaceへの製品の掲載が含まれます。そのため、未掲載のSaaS企業は、PRMに向けた製品とAWSアカウントの準備から始めます。掲載の手順はAWS MarketplaceにSaaSを出品する方法にまとめています。
□ 掲載する製品と、料金モデルを決める
□ 販売者登録と、AWS Partner CentralとのAWSアカウントのリンク先を決める
□ 製品が使うAWSサービスと、製品のアーキテクチャ（Pattern #1、#2、#3）を整理する
□ 採用候補の計測方式で、対象のAWSサービスに自社の製品が含まれるかを確認する
□ AWS Cost Explorerの有効化を、AWSアカウントの管理者に依頼する
すでに掲載している企業、AWSとの協業を検討している企業
掲載済みの製品は、最も利用されている製品から、計測の準備を始めます。
□ AWS Partner Centralにリンクしているアカウントが、PRMコンプライアンスの判定アカウントとして適切かを確認する
□ AWS Marketplace Management Portalで、製品ごとのProduct Codeを確認する
□ 計測する製品の優先順位を決める
□ 製品ごとに計測方式を選び、担当部署を決める
□ 顧客環境にタグを付ける場合は、顧客への説明と合意の手順を決める
□ 新しいAWS Partner Centralへの移行状況を確認する
□ AWSの資金支援の案内を、2027年を通じて定期的に確認する担当者を決める
準備の相談先とDeshimaの対応範囲
PRMの実装は、AWSアカウント、AWSリソース、アプリケーションのコードに関わる作業で、自社で進めます。Deshimaは、PRMのタグ付けの自動化、SDKのUser Agentの設定、Revenue Attribution IDの登録と配分、ダッシュボードの運用を、機能として提供していません。PRMの実装の代行も、お約束していません。
掲載前の準備では、Deshimaの無料アカウントで、掲載に必要なタスクの一覧と日本語の掲載ガイドを確認できます。Deshimaが対応しているのは、SaaS Contract型の製品の掲載準備と、購入者・契約情報の取得と同期、利用申請フォーム、Amazon EventBridgeへのイベント発行です。従量課金（メータリング）とChannel Partner Private Offer（CPPO）は対象外です。Deshimaの利用料は、初期費用と月額費用が0円で、費用が発生するのは製品が売れたときの販売手数料のみです。料率は個別にご提案しています。対応範囲はトップページのFAQに、料金の考え方は料金のセクションに記載しています。
すでに掲載している企業が、AWSとの協業の方針を整理したい場合は、有償オプションのプロフェッショナルサービスがあります。支援の範囲は、AWS Marketplace掲載方針の設計と、AWSとのCo-Sellのアドバイザリーです。PRMを含むAWSとの協業の進め方は、掲載方針や共同販売の計画と併せて、まずお問い合わせからご相談ください。
Deshimaは更新が多いため、最新の機能と対応範囲は、無料のアカウントを作成したうえで、プロダクト内のドキュメントでご確認ください。