AWS PRMの実装方法｜aws-apn-idタグ・User Agent・Marketplace Meteringを比較

Partner Revenue Measurement（PRM）の実装は、「リソースにタグを付けるか、User Agentを設定すれば終わり」と見積もられがちです。手を動かす量は、たしかにその程度です。ところが、どの方式を選べるかは、製品の種類、AWSアカウントの構成、使っているAWSサービス、顧客が許可するタグの運用で決まります。さらに、$ を1文字落とす、Product Codeの代わりに別のIDを入れる、タグキーに別のAWSアカウントIDを書く、といった小さな間違いで、計測が始まりません。

PRMの位置づけと2027年の資金支援との関係は、AWS PRM（Partner Revenue Measurement）とは？で扱っています。本記事は、その実装を担当するSaaSの開発者、インフラ担当、技術責任者に向けて、方式の選び方、設定値、顧客との調整、設定後の確認を整理します。2026年10月29日に確認したAWSの公式ドキュメントと発表にもとづきます。

実装の前に製品・アカウント・対象サービスを確認する

前提条件は、3方式に共通しています。（前提条件）一つめは、AWS Partner CentralとAWSアカウントのリンクです。リンクしたAWSアカウントは、AWS Partner CentralにおけるAWS Partner Network（APN）の活動の primary account（主アカウント）になります。AWSは、このアカウントを、PRMのコンプライアンスを判定してAPNの資金支援の適格性を確認する際に使うと説明しています。このアカウントには、年次のAPNメンバーシップ費用も請求されます。AWS Marketplaceのアカウントが複数ある場合、AWSは、グローバル事業を代表する新しいAWSアカウントを作成してリンクし、各AWS Marketplaceアカウントを Subsidiary Account Connections（子会社アカウントの接続）で主アカウントに接続することを推奨しています。タグキーに入る12桁のアカウントIDは、このリンクしたAWSアカウントのIDです。

二つめは、AWS Marketplaceへの製品の掲載です。SaaS、Amazon Machine Image（AMI）、Machine Learning（ML）、Professional Servicesのいずれの製品にも掲載ガイドがあります。三つめは、PRMの対象になるAWSサービスを1つ以上使う製品であることです。四つめは、AWS Cost Explorerが有効になっていることです。有効になっているか見落としやすいため、実装の最初に確認します。

実装に使う識別子は、AWS Marketplace Management PortalのProductsから製品を選び、Product Summaryの項目で確認できるProduct Code（製品コード）です。形式は 5ugbbrmu7ud3u5hsipfzug61p のような英数字で、公式ガイドは、すべての実装方式でProduct Codeが必要だと説明しています。（Product Codeの取得）Product Codeは、Product IDや、掲載に付くUniversally Unique Identifier（UUID）とは別のものです。公式のトラブルシューティングも、Product Codeの不一致の原因として、Product IDやUUIDを使っていることを挙げています。（トラブルシューティング）なお、案件単位の識別子であるRevenue Attribution IDのAPIが求める ProductIdentifier は、25文字のMarketplace product IDで、これも別の文脈の値です。その扱いは、PRMの計測結果を確認し、案件に紐付ける方法で説明しています。

計測の対象は本番のワークロードです。開発、テスト、ステージングの環境は、実装の検証に使えます。（リソースタグの実装）また、2026年10月29日時点では、PRMはコマーシャルリージョンのみが対象で、ソブリンや政府向けのクラウドのリージョンは今後の拡大予定として案内されています。（顧客向けFAQ）

□ AWS Partner CentralにリンクしたAWSアカウントの12桁のIDを確認した

□ AWS Marketplace Management Portalで、製品のProduct Codeを確認した

□ AWS Cost Explorerを有効にした

□ 製品が使うAWSサービスが、選ぶ方式の対象一覧に含まれていることを確認した

3方式の比較と、SaaSで自動計測を前提にしない理由

方式を選ぶ入口は、アーキテクチャパターンです。AWSの開始手順は、製品が使うAWSサービス、AWS Marketplaceに掲載している製品の種類（SaaS、AMI、ML、Professional Servicesのいずれか）、アーキテクチャパターンの3点を、方式選びの材料に挙げています。（開始手順）アーキテクチャパターンは、構成要素がどのAWSアカウントにあるかで、次の3つに分かれます。

論点の列は、公式ガイドの記述をもとにした本記事の整理です。自社のどの構成要素がどのアカウントのどのリソースを使うかは、構成図で書き出してから判断します。

3方式の違いは、次のとおりです。（開始手順）

SaaSで自動計測を前提にしない理由

AWS Marketplace Meteringは、追加のタグ付けやUser Agentの実装を必要としない方式です。AMIは、掲載時に割り当てられるProduct Codeが、そのAMIから起動したすべてのAmazon EC2インスタンスにインスタンスメタデータとして自動で付き、PRMがそのProduct CodeでAmazon EC2の使用量を計測します。MLは、製品が作成したAmazon SageMaker AIリソースの顧客の使用量を、自動で製品に帰属させます。ただし、顧客がAWS Marketplace経由で購入して使うことが条件です。（AWS Marketplace Metering方式）

2026年10月29日時点で、この方式の対象としてSaaSは記載されていません。名前が似ているため混同しやすいのですが、SaaSのBatchMeterUsageは、顧客への従量課金のために使用量をAWS Marketplaceへ送るAPIで、PRMの計測方式ではありません。そのため、SaaS Contract（SaaS契約。契約期間と購入する権利をあらかじめ定め、前払いまたは支払スケジュールで請求する料金モデル）の製品でも、自動計測を前提に見積もらず、Resource TaggingかUser Agent Stringを実装する前提で見積もります。BatchMeterUsageの実装は、AWS Marketplaceのメータリング実装で、SaaS連携の全体像はAWS MarketplaceのSaaS連携に必要な実装で扱っています。

AMI製品でAmazon EC2以外のAWSサービスも使う場合と、ML製品でAmazon SageMaker AI以外のAWSサービスも使う場合は、AWSがUser Agent Stringの併用を推奨しています。（User Agent String）自動計測の対象範囲の外にある消費を、別の方式で補う考え方です。

方式を選ぶ流れを、構成と条件から整理すると次のようになります。本記事の整理であり、AWSが定めた選択手順ではありません。

製品はAMIまたはMLか
  はい   -> AWS Marketplace Metering。AMIでAmazon EC2以外、MLでAmazon SageMaker AI以外も
            使うなら、User Agent Stringの併用をAWSが推奨
  いいえ（SaaSなど）
    -> 使うAWSサービスが、Resource Taggingの対象一覧に入っているか
         はい   -> 顧客のアカウントにタグを付けてよいか（許可、タグポリシー、IaC）
                     はい     -> Resource Tagging
                     合わない -> User Agent String
         いいえ -> User Agent Stringの対象一覧と、対象のAPI操作を確認

対象サービスは方式ごとに別の一覧

すべてのAWS請求額が計測されるわけではありません。対象のAWSサービスは、方式ごとに別の一覧で公開されています。たとえば、Amazon SageMaker AIはResource Taggingの一覧にあり、User Agent Stringの一覧にはありません。Amazon API GatewayとAmazon Athenaは両方にあります。Resource Taggingの一覧には、Amazon S3はストレージ費用のみ、Amazon EKSはAWS Fargateを除く、Amazon CloudWatchはLogsのみといった、サービス内の制限も付いています。（Resource Taggingの対象サービス）User Agent Stringの対象サービスは、2026年8月31日に24サービスから119サービスに拡大されました。（ドキュメント履歴）

対象外のサービスで捕捉された一部の支出は、集約されて表示されます。Resource Taggingでは「Other」、User Agent Stringでは「Misc」です。（Resource Taggingの対象サービス、User Agent Stringの対象サービスとAPI）対象外のサービスの支出が全額計測されるわけではないため、OtherやMiscの金額を、対象外サービスの支出の総額として読むことはできません。個別のサービスは、一覧が更新されるため、本記事では網羅せず、公式の一覧で確認する前提にします。

Resource Taggingのキーと値を設定する

Resource Taggingは、寄与するAWSリソースに、製品を識別するタグを付ける方式です。タグのキーと値は、次の形式で設定します。（リソースタグの実装）

12桁のアカウントIDは、AWS Partner Centralのホーム画面の右上に表示されます。AWS Partner Centralのダッシュボードにある Partner Revenue Measurement agent で、自社の掲載に対する正しいタグキーと値を調べる方法もあります。

AWS CLIでの設定例は、公式ガイドに次の形式で記載されています。次のコマンドは、公式ガイドに記載された形式の引用です。

aws ec2 create-tags --resources i-1234567890abcdef0 \
  --tags Key=aws-apn-id-012345678901,Value=pc:5ugbbrmu7ud3u5hsipfzug61p

従来のキー aws-apn-id は、引き続き有効です。このキーで付与済みのリソースに、変更は要りません。一方、AWSは、単独のパートナーの場合も含め、今後の設定にはアカウントID付きのキーを使うよう案内しています。どちらのキーによる収益も、ダッシュボードでは同じ「Resource Tagging」方式として表示されます。（リソースタグの実装）

設定するときは、次の点を確認します。

• キーのアカウントIDが、AWS Partner Centralにリンクしたアカウントのものであること
• 値が pc: で始まり、Product CodeがAWS Marketplaceの掲載と一致していること
• タグを付けるリソースが、対象サービスのものであること
• リソースが、実際にAWSサービスを消費して課金が発生していること

最後の点は見落としやすい条件です。AWS IAMのような無料のAWSサービスのリソースにタグを付けても、収益の帰属は生まれません。（トラブルシューティング）

タグを付けたあとは、タグが外されるか、リソースが終了するまで、AWSはその製品に収益を帰属させ続けます。アカウントにアクセスできる利用者は、顧客もパートナーも、タグを削除できます。（リソースタグの実装）そのため、顧客側の運用でタグが外れ得ることを、顧客との調整の場で共有しておくと、計測が途切れる原因を追いやすくなります。

複数のパートナーが貢献するリソースの扱い

2026年9月30日、AWSは、アカウントID付きのタグキーによる複数パートナーへの帰属を、全コマーシャルリージョンで提供開始しました。（AWSの発表）従来のキー aws-apn-id は、1つのキーなので、リソースごとに1つの値しか持てません。アカウントID付きのキーは、パートナーごとに別のキーになるため、同じリソースに複数のパートナーが独立してタグを付けられます。（ドキュメント履歴）

実装手順で注意するのは、他社のタグへの手の入れ方です。同じリソースを複数のパートナーがタグ付けした場合、タグを付けた各パートナーが収益の帰属を受けます。各パートナーが自分固有のキーを使うので、他社のタグを削除する必要はなく、削除して自社のタグに置き換える手順にもしません。（リソースタグの実装）

ただし、上限が2つあります。一つは、1リソースあたり10パートナーです。11社以上が同じリソースにタグを付けた場合、上限を超えたパートナーは帰属を受けられません。もう一つは、1リソースに付けられるタグの数です。顧客向けFAQによると、パートナーのタグは、顧客が使える50個のユーザー定義タグの枠のうち、それぞれ1つを消費します。（顧客向けFAQ）そのため、顧客のリソースにすでに多くのタグが付いている場合は、枠に余裕があるか、顧客に確認してから設定します。

User AgentをAWS SDK・環境変数で設定する

User Agent Stringは、自社のソリューションが行うAWS APIまたはAWS Command Line Interface（AWS CLI）の呼び出しに、識別子を付ける方式です。AWS SDKやツールの設定で、その識別子を付与できます。Resource Taggingと違い、顧客のリソースにタグを付ける必要がありません。その代わり、呼び出しのたびに、次の形式の文字列が送られる必要があります。（User Agent String）

APN_1.1/pc_<YOUR-PRODUCT-CODE>$

終端の $ は、必須の終端記号です。省かないよう、注意が要ります。公式のトラブルシューティングは、$ が省略された、またはシェルによってエスケープされたことで、形式が崩れる事例を挙げ、シングルクォートなどで $ で終わるようにする対処を示しています。（トラブルシューティング）

帰属には、もう一つ条件があります。製品は、リソースのAmazon Resource Name（ARN）に対して、月に1回以上のAPI操作を行う必要があります。その月にAPI操作がなかったリソースは、その月の収益の帰属に寄与しません。（User Agent String）

AWS SDKで設定する方法

AWS SDKで設定するには、Application IDとして、この文字列を指定します。既存のApplication IDがある場合は、スペース区切りで追記します。公式ガイドに記載された形式は、次のとおりです。（SDKのUser Agent自動設定）

EXISTING_APP_ID APN_1.1/pc_5ugbbrmu7ud3u5hsipfzug61p$

共有設定ファイル ~/.aws/config では、sdk_ua_app_id に指定します。

[default]
sdk_ua_app_id=APN_1.1/pc_5ugbbrmu7ud3u5hsipfzug61p$

環境変数 AWS_SDK_UA_APP_ID には、次のように指定します。

# Linux / macOS
export AWS_SDK_UA_APP_ID=APN_1.1/pc_5ugbbrmu7ud3u5hsipfzug61p$

:: Windows
setx AWS_SDK_UA_APP_ID APN_1.1/pc_5ugbbrmu7ud3u5hsipfzug61p$

プログラムの中で設定する場合の記載は、次のとおりです。

import os
os.environ['AWS_SDK_UA_APP_ID'] = 'APN_1.1/pc_5ugbbrmu7ud3u5hsipfzug61p$'

process.env.AWS_SDK_UA_APP_ID = 'APN_1.1/pc_5ugbbrmu7ud3u5hsipfzug61p$';

Java Virtual Machine（JVM）上では、システムプロパティで指定します。AWS SDK for Java 2.xのプロパティ名は sdk.ua.appId です。

-Dsdk.ua.appId="APN_1.1/pc_5ugbbrmu7ud3u5hsipfzug61p$"

AWS SDK for Kotlinは、同じJVM上でもプロパティ名が異なり、aws.userAgentAppId です。

-Daws.userAgentAppId="APN_1.1/pc_5ugbbrmu7ud3u5hsipfzug61p$"

PRMのガイドは、JavaとKotlinをまとめて sdk.ua.appId と記載しています。（SDKのUser Agent自動設定）一方、AWS SDKの共通リファレンスは、Kotlinのプロパティ名を aws.userAgentAppId としています。（Application ID）二つの資料で記載が食い違うため、Kotlinで設定するときは、後者の名前も試したうえで、送信される値をAWS CloudTrailで確認してください。

Application IDの設定方法は、ほとんどのAWS SDKとツールが対応しています。自社で使う言語、SDK、ツールが対応しているかは、AWSの対応一覧で確認します。ここまでに挙げた設定値は、いずれも公式ガイドに記載された形式の引用です。ただし、指定した文字列が、そのままUser Agentとして送信されるとはかぎりません。

指定した文字列がそのまま送信されるとはかぎらない

Application IDには、許容文字の制限があります。公式の仕様では、最大50文字で、英数字と ! # $ % & ' * + - . ^ _ ` | ~ が許可されています。（Application ID）PRMが求める APN_1.1/pc_<Product Code>$ に含まれる / は、この一覧にありません。その影響で、AWS SDKの実装によっては、/ が別の文字に置き換えられます。

AWS SDK for Python（Boto3）が使うbotocore 1.40.53で、2026年10月29日に文字列の生成だけを確認した結果は、次のとおりです。AWS_SDK_UA_APP_ID に APN_1.1/pc_5ugbbrmu7ud3u5hsipfzug61p$ を指定すると、生成されるUser Agentは app/APN_1.1-pc_5ugbbrmu7ud3u5hsipfzug61p$ となり、区切りの / が - に変わりました。同じ文字列を botocore.config.Config の user_agent_extra に指定した場合は、文字列がそのまま保持されました。

import boto3
from botocore.config import Config

config = Config(user_agent_extra='APN_1.1/pc_5ugbbrmu7ud3u5hsipfzug61p$')
client = boto3.client('ec2', config=config)

PRMの公式ガイドは、検証の手順として、AWS CloudTrailで APN_1.1/pc_<Product Code>$ の形式と完全に一致することを確認するよう求めています。（SDKのUser Agent自動設定）その影響で、形式が変換される設定方法では、この確認を通りません。変換された文字列でAWSが帰属を認めるかどうかは、AWS側の判定によるため、確認していません。形式どおりの文字列が送信される設定方法を選んだうえで、APN Supportに検証を依頼してください。

既存のApplication IDがある場合に、スペース区切りで追記する方法は、公式ガイドが案内しています。ただし、Application IDの最大長は50文字で、PRMの文字列だけで37文字を使います。既存の値と合わせて50文字を超えないかも、あわせて確認してください。

実際に送信されるUser Agentの値は、自社が使う言語とAWS SDKのバージョンによって変わります。どの設定方法を選ぶ場合も、AWS CloudTrailの userAgent フィールドで、必ず確認してください。

設定する範囲を絞る

公式ガイドは、次の警告を掲げています。自社のソリューションが直接行う、通常のAWS API／AWS CLIの呼び出しにだけ、User Agent Stringを設定します。ソリューションと無関係な、顧客が開始した呼び出しには設定しません。（SDKのUser Agent自動設定）

環境変数と共有設定ファイルは、その設定が効く範囲の呼び出し全体に及びます。環境変数はそのプロセスのAWS SDKの呼び出し全体に、[default] の設定はそのプロファイルを使う呼び出し全体に効きます。そのため、ソリューションの処理と無関係な処理が同じプロセスやプロファイルで動いていないかを、設定する前に確認します。反対に、1つのサービスクライアントだけに設定して、他のクライアントを取りこぼす場合もあります。公式のトラブルシューティングも、正しいAWS SDKクライアントの設定に適用されているかを確認項目に挙げています。

IaCのツールごとに、User Agent Stringを使えるかが分かれる

AWS CloudFormationとAWS Cloud Development Kit（AWS CDK）は、User Agent Stringに対応していません。AWS CloudFormationがリソースを作るときは、自身のサービスプリンシパルでAWS APIを呼び出すため、その呼び出しのUser Agentを自社で制御できません。AWS SDKにApplication IDを設定しても、この呼び出しには伝わりません。その影響で、公式ガイドは、AWS CloudFormationでデプロイするリソースにはResource Taggingを使うよう案内しています。例外は、テンプレートに含めるLambda-backed Custom Resources（AWS Lambdaで実装するカスタムリソース）です。その関数コードからの呼び出しには、AWS SDKでUser Agent Stringを設定できます。（User Agentの実装）

Terraformは、provider_meta の user_agent 引数でUser Agent Stringを設定できます。対応するバージョンは、AWSプロバイダーが6.27.0以降、AWSCCプロバイダーが1.67.0以降です。この設定は宣言したモジュールだけに効くため、複数のパートナーのモジュールが同じ構成にあっても、帰属が混ざりません。（User Agentの実装）

方式を選ぶときは、対象のAWSサービスだけでなく、リソースを作るツールも確認してください。

対象のコントロールプレーンAPIとAWS CloudTrailで設定を確認する

User Agent Stringの対象は、管理またはコントロールプレーン（control plane）のAPI呼び出しです。AWSリソースを作成、参照、変更、削除する呼び出しがこれにあたります。データプレーン（data plane）の操作は、AWS APIやAWS CLIを使う場合でも対象外です。（User Agent方式の対象サービスとAPI）一般に、Amazon S3のバケットを作成する操作は管理の操作、オブジェクトを読み書きする操作はデータの操作です。ただし、自社の呼び出しが対象かどうかは、サービスごとの対象APIアクションとリージョンを載せた公式の一覧で確認します。この一覧は、CSVでダウンロードできます。

設定の確認は、AWS CloudTrailのログで行います。公式の手順は、次の流れです。（SDKのUser Agent自動設定）

1. テストのAPI呼び出しを行う
2. AWS CloudTrailのログの userAgent フィールドに、設定した文字列が出ているか確認する
3. 形式が APN_1.1/pc_<YOUR-PRODUCT-CODE>$ と完全に一致しているか確認する

公式のトラブルシューティングには、AWS CloudTrailのログを検索するコマンドとして、次の形式が記載されています。（トラブルシューティング）

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

--log-group-name には、AWS CloudTrailのログを保存しているロググループの名前を指定します。--start-time は、ミリ秒単位のエポック時間です。テストを行った時刻に合わせて、値を変えます。

文字列が出ない場合は、次の事象と対処を、公式の表に沿って確認します。（トラブルシューティング）

あわせて、AWS CloudTrailが有効で、該当のリージョンで該当のAPIを記録しているかも確認します。AWS CloudTrailのログは、顧客にとっても、パートナーのソリューションが行った操作の監査証跡になります。（顧客向けFAQ）

顧客への説明、権限、タグポリシー、IaCとの整合を確認する

Resource Taggingで顧客のアカウントのリソースにタグを付ける場合は、実装する前に顧客との調整が要ります。User Agent Stringでも、顧客のアカウントでソリューションが呼び出しを行う場合は、顧客への説明が必要です。AWSの顧客向けFAQに沿って、説明する点を整理します。（顧客向けFAQ）

顧客への影響。 PRMは、顧客のインフラ、セキュリティ、請求の構造に影響しません。インストールするソフトウェアはなく、性能のオーバーヘッドも、ワークロードの動作の変更もありません。AWSやパートナーに、顧客のアカウント、リソース、アプリケーションコードへのアクセスを新しく付与することもありません。

収集されるデータと共有の範囲。 AWSが収集するのは、AWS MarketplaceのProduct Codeとリソースタグ、ARN、API操作、ARN単位の使用額、サービスの種類、API操作またはタグ作成の日時、AWSリソースをホストするAWSアカウントのIDです。パートナーには、顧客ごとのデータは共有されず、全顧客を合計した、帰属収益の指標だけが渡ります。

権限。 パートナーがタグを付けられるのは、顧客が明示的に付与したAWS IAMの権限の範囲に限られ、顧客はいつでも取り消せます。PRMが、新しいアカウントのアクセス権を自動で付与するわけではありません。権限が得られない顧客には、タグの追加を前提にしない形を提案する必要があります。

タグポリシーと環境への適合。 顧客がAWS Organizationsのタグポリシーを使っている場合、タグキーを許可する一度きりの更新が必要です。タグが顧客の環境に合わないなら、顧客のアカウントにタグを必要としないUser Agent Stringを依頼できます。複数パートナーの節で触れた、10パートナーと50タグの上限も、この調整の対象です。

Infrastructure as Code（IaC）との整合。 リソースが、AWS CloudFormation、Terraform、AWS Cloud Development Kitなどで管理されている場合、コンソールやAWS CLIでタグを付けると、次のIaCの実行でドリフト（構成のずれ）が検出されます。IaCで管理されているリソースには、必ずIaCのツールを通じてタグを付けます。（リソースタグの実装）顧客のIaCのリポジトリにタグの追加を反映してもらうのか、ソリューションがデプロイするIaCに含めるのかは、顧客との調整事項です。

顧客と確認する内容は、次のとおりです。

□ タグを付けるAWS IAMの権限を、顧客が付与している

□ 顧客がAWS Organizationsのタグポリシーを使っている場合、タグキーの許可が済んでいる

□ 対象のリソースに、50個のタグの上限と10パートナーの上限に収まる余裕がある

□ IaCで管理されたリソースには、IaC側でタグを反映する運用になっている

□ タグを付けるリージョンが、コマーシャルリージョンである

設定後はOnboarding Statusと月次データを確認する

設定が計測に反映されたかは、AWS Partner Centralの Partner Analytics にある Attributed Revenue Dashboard（帰属収益ダッシュボード）で確認します。そのうちの Onboarding Status（オンボーディング状況）のテーブルには、製品名、PRM Capability（Resource Tagging、User Agent string、AWS Marketplace Meteringのいずれか）、Status（その機能が実際に収益を計測しているか）が表示されます。（Attributed Revenue Dashboard）実装した方式がこの一覧に出て、Statusで、その機能が収益を計測していると示されているかが、最初の確認点です。

収益のデータは、月次で処理されます。前月分は、月が終わってから17日後に利用できるようになります。そのため、設定した当月のうちに金額が見えなくても、すぐに実装の失敗とは判断できません。また、AWS Partner Centralのビルダーガイドは、PRMを有効にしてから計測データが表示されるまで、最大7日かかることがあると記載しています。（AWS Partner Centralのビルダーガイド）ダッシュボードの読み方と、案件との紐付けは、PRMの計測結果を確認し、案件に紐付ける方法で扱っています。Revenue Attribution IDによる案件単位の紐付けは、製品単位のPRMの実装の上に重ねる仕組みで、既存のリソースタグやUser Agentの変更は要りません。

帰属が出ないときの確認の順序は、方式ごとに公式のトラブルシューティングに載っています。（トラブルシューティング）Resource Taggingでは、タグキーの形式、AWS Partner CentralのアカウントID、タグ値の形式、Product Codeと掲載の一致、対象サービスか、実際に課金が発生しているか、の順で確認し、AWS Tag Editorでタグが正しく適用されているかを見ます。User Agent Stringでは、形式エラーの事象と対処の表に加え、AWS CloudTrailが有効か、userAgent フィールドに文字列が入っているかを確認します。AWS Marketplace Meteringは、完全に自動の方式で、帰属が出ない主な原因は、顧客がAWS Marketplace経由で購入して使っていないことです。問題が続く場合は、AWSアカウントID、Product Code、製品の種類、事象と期待する挙動を添えて、APN Supportに連絡します。

AWSによる公式の検証が必要な場合は、AWSのパートナー管理チームまたはAPN Supportに、AWSアカウントID、リージョン、Product Code、サンプルのリソースのARN、タグのスクリーンショットまたはAWS CloudTrailのログの抜粋とテストの時刻を添えて連絡します。回答までは、3〜5営業日かかります。

PRMの前提になる、製品の掲載と購入後の連携の準備

PRMの前提には、公開されたAWS Marketplaceの掲載があります。掲載したあとは、購入した顧客を自社のSaaSに結び付ける実装が要ります。その部分は、AWS MarketplaceにSaaSを出品する方法、AWS MarketplaceのSaaS連携に必要な実装、AWS Marketplaceの契約をSaaSテナントに紐付けるには？で整理しています。

Deshimaが担うのは、SaaS Contract型の製品の掲載準備、購入者と契約の情報の取得と同期、利用申請フォーム、Amazon EventBridgeへのイベント発行です。PRMのタグ付けとUser Agentの設定は、Deshimaの機能として提供しておらず、自社で実装する範囲です。2026年10月29日時点で、DeshimaはSaaS Contract型のみに対応しており、従量課金（メータリング）とChannel Partner Private Offer（CPPO）は対象外です。Concurrent Agreementsには対応済みです。

Deshimaの利用料は、初期費用と月額費用がどちらも0円で、費用が発生するのは製品が売れたときの販売手数料のみです。料率は個別にご提案しており、考え方は料金のセクションに記載しています。PRMの実装にかかる自社側の工数と、必要なAWSリソースの費用は、これとは別にかかります。

その前提となる掲載と、購入後の連携の準備に進む場合は、無料のアカウントを作成し、掲載タスク一覧と連携手順を確認してください。Deshimaは更新が多いため、最新の機能と対応範囲も、アカウントを作成したうえで、プロダクト内のドキュメントでご確認ください。