AWS MarketplaceのSaaS連携に必要な実装｜登録、権利確認、契約通知、課金

AWS MarketplaceのSaaS連携を見積もるとき、「ResolveCustomer、GetEntitlements、BatchMeterUsageを呼ぶだけ」と書いてしまいたくなります。中心になるAWSのAPIは、たしかにその程度です。ところが、作業量を決めるのはAPIの本数ではなく、呼び出しの前後でSaaS側が受け持つ処理です。

SaaS連携に必要な部品は、購入後の登録ページ、顧客の特定、契約内容の確認、契約変更の通知の処理、使用量の送信、そしてSaaS側の権限制御です。このうち何を作るかは、料金モデルで決まります。対象は日本のSaaS販売者の新規出品で、2026年10月5日に確認したAWSの公式ドキュメントと発表にもとづきます。

SaaS連携の部品と、AWS側とSaaS側の分担

購入者がAWS MarketplaceでSaaSを購入すると、購入者のブラウザは、製品作成時に登録した登録URLへHTTP POSTで送られます。リクエストには、一時的なトークン（x-amzn-marketplace-token）が付いています。（SaaSの顧客オンボーディング）

購入者が購入する
  -> 登録URLへPOST（x-amzn-marketplace-token）
  -> ResolveCustomer：トークンを CustomerAWSAccountId と LicenseArn に変換
  -> GetEntitlements：契約内容を確認（SaaS Contract、SaaS Contract with Consumption）
  -> 顧客と契約の識別子を保存し、初回の利用画面を表示

購入後は、次の二つが続く
  Amazon EventBridge：契約の作成、変更、終了とライセンスの更新を受信
    License Updated を受けたら、SaaS Contract と SaaS Contract with Consumption は GetEntitlements で権利を確認する
    SaaS Subscription は GetEntitlements を使わず、購読の状態にもとづいて利用可否を決める
  BatchMeterUsage：使用量を送信（SaaS Subscription、SaaS Contract with Consumption）

フローに現れる呼び出しと通知は、AWSが用意した受け口です。一方、契約内容に応じた機能と数量の制限や、終了時のアクセス停止は、AWSのAPIにはなく、SaaS自身が実装する処理です。

料金モデルで必要なAPIが決まる

SaaS製品が呼ぶべきAPIは、料金モデルで決まります。SaaS製品の料金モデルは、SaaS Contract（SaaS契約。契約期間と購入する権利をあらかじめ定め、前払いまたは支払スケジュールで請求する料金モデル）、SaaS Contract with Consumption（従量制料金によるSaaS契約。契約の料金に加えて超過分を従量で請求する料金モデル）、SaaS Subscription（SaaSサブスクリプション。時間単位の使用量に応じて請求する従量課金の料金モデル）の三つです。作る部品は、料金モデルごとに次のように分かれます。（SaaS製品のガイドライン、契約製品の連携、契約と従量の連携、従量課金製品の連携、SaaSの顧客オンボーディング）

2026年10月5日時点の掲載基準が料金モデルごとに挙げるAPIは、SaaS Contract、SaaS Contract with Consumption、SaaS Subscriptionの三つについてだけで、SaaS Free（SaaS無料。すべての料金ディメンションを0ドルにする料金モデル）は挙がっていません。（SaaS製品のガイドライン）AWSの連携ガイドは、SaaS Subscription型の製品ではGetEntitlements APIを使わないと明記しています。（従量課金製品の連携）料金モデルは、製品を作成して限定公開（limited）にした後は変更できないため、実装の見積もりは料金モデルを決めてから始めることになります。（SaaSの料金モデル）各モデルの比較は、AWS MarketplaceのSaaS料金モデルで扱っています。

これらのAPIは、販売者として登録し、公開申請を出したAWSアカウントから呼ぶ必要があります。（SaaS製品のガイドライン、ResolveCustomer API）

購入後の登録ページで顧客を特定する

トークンをResolveCustomerで変換する

登録ページは、POSTで届いたトークンをResolveCustomerに渡します。契約がすぐに始まる通常の購入では、応答にCustomerAWSAccountId、LicenseArn、ProductCodeが含まれ、新しく実装する連携機能では従来のCustomerIdentifierは設定されません。CustomerAWSAccountIdとLicenseArnは、以降のAPI呼び出しで使うため、保存するよう求められています。（ResolveCustomer API）

開始日が将来の契約では、LicenseArnは契約の開始日に生成され、契約IDが作られてから数か月後になることがあります。（Concurrent Agreements移行ガイド）その契約では、ResolveCustomerの応答にLicenseArnがどう現れるかが、APIリファレンスに書かれていないため、確認が必要です。LicenseArnが発行されるまでは、アカウントの有効化とメータリングを保留する設計にしておくと、LicenseArnのない状態で使用量を送ることがありません。これは公式の記述ではなく、本記事の提案です。

トークンは、受け取った直後に処理する必要があります。期限切れの原因として、リダイレクトに時間がかかった場合、購入者が再送信した場合、アプリケーションがトークンを保持し続けた場合が挙げられています。（ResolveCustomer API）有効期間について、2026年10月5日時点のオンボーディングのページには、4時間とする記述と約1時間とする記述の両方があります。（SaaSの顧客オンボーディング）どちらの数字も前提にせず、リクエストを受けた処理の中で、その場で解決する実装にしておくのが堅実です。

解決したAWSアカウントIDは、AWSから直接返された値か、自社のシステムが署名した値だけを信頼します。公式ガイドは、登録が完了するまで、ブラウザのセッションに署名付きの属性として保持する方法を推奨しています。（SaaSの顧客オンボーディング）そのため、書き換えられるフォームの隠しフィールドに値を格納して受け渡す実装は、避けることになります。

登録ページと購入後の体験の条件

登録ページと購入後の体験には、掲載基準として次の条件があります。（SaaS製品のガイドライン）

• 登録ページに、購入者のメールアドレスの入力欄を設ける。複数の言語を使う場合は、英語表示も用意する
• フルフィルメントのランディングページ（購入後に遷移するページ）に、サポートの連絡先を示す
• クレジットカードや銀行口座の情報は集めない。請求は、AWS Marketplaceに設定したディメンションだけで行う
• 購入後に、顧客がSaaS内でアカウントを作り、Webコンソールにアクセスできるようにする。すぐにアクセスできない場合は、アクセスできる時期を案内し、作成後は確認の通知を送る
• すでにアカウントを作成済みの顧客がログインでき、契約や利用の状況をSaaS内で確認できるようにする

GetEntitlementsで契約内容を確認する

SaaS ContractとSaaS Contract with Consumptionでは、顧客が何をどれだけ買ったかを、SaaSがAWSに問い合わせて確かめます。この問い合わせがGetEntitlementsです。AWS Marketplace Entitlement Serviceは、米国東部（バージニア北部）リージョンだけで利用できます。（AWS Marketplace Entitlement Serviceでの権利確認）

リクエストではProductCodeが必須で、CUSTOMER_AWS_ACCOUNT_IDやLICENSE_ARNで絞り込めます。応答はページ単位で返り、結果が空でもNextTokenが付く場合があるため、NextTokenがあれば続きを取得します。（GetEntitlements API）

応答の各権利には、ディメンション、値、有効期限（ExpirationDate）、LicenseArnが入ります。（GetEntitlements API）ExpirationDateは、権利が有効である最短の期間で、自動更新の顧客では更新日が入ります。（AWS Marketplace Entitlement Serviceでの権利確認）

呼び出す場面は、オンボーディングの時点だけではありません。公式ガイドは、顧客が新しいユーザーを追加しようとしたときに、契約の数量に空きがあるかをGetEntitlementsで確かめる例を挙げています。（AWS Marketplace Entitlement Serviceでの権利確認）公式ガイドは、顧客からのリクエストを次の三つの場合に分け、それぞれに対応するよう求めています。（契約製品の連携）

• 自社のシステムに顧客IDがない：まだ購入していないため、購入方法を案内する
• 顧客IDがあり、適切な権利が返る：リクエストに応える
• 顧客IDはあるが、権利が返らないか、数量が足りない：アクセスと体験の扱いを、自社で決める

権利が返らない場合や数量が足りない場合の扱いは、AWSは定めていません。権利が足りないとき、機能を止めるのか、読み取りだけ許すのか、猶予を設けるのかは、製品の設計に属する判断です。

Amazon EventBridgeで契約の変更を受け取る

契約は購入後も変わり、SaaSはその更新、変更、終了をAWSからの通知で知ります。この通知は、これまでAmazon SNSで届いていましたが、AWSはSaaS製品の通知をAmazon EventBridgeへ置き換えています。2026年6月1日以降の新規SaaS製品では、Concurrent Agreementsへの対応が必須で、販売者は通知をAmazon EventBridgeへ切り替え、料金モデルに応じて、権利確認と従量のAPIを更新する必要があります。（AWSの発表）連携ガイドの注記は、Amazon SNSによる通知を使えるかどうかを、セラーアカウントの登録日で切り分けています。2026年7月15日より後にセラーアカウントを登録した販売者は、Amazon EventBridgeでイベントを受け取ります。同日以前に登録した販売者は、引き続きAmazon SNSを使えます。（契約製品の連携）これから販売者登録を行う場合は、製品の新旧にかかわらず、Amazon EventBridgeを前提に設計することになります。既存の製品でも、統合の作業を終えた販売者は、Concurrent Agreementsをオプトインで有効にできます。（AWSの発表）新方式の要件と移行の判断は、AWS MarketplaceのConcurrent Agreementsとは？にまとめています。

受け取るイベントと、SaaSの対応

SaaS向けの主なイベントは、次のとおりです。（Amazon EventBridgeによるSaaSイベント管理）

Purchase Agreementの作成、変更、終了のイベントには、受け取る立場に応じて「- Manufacturer」版と「- Proposer」版があります。License UpdatedとLicense Deprovisioned、勧告のイベント（IssuedとResolved）は、製造元（Manufacturer）だけに届きます。（Amazon EventBridgeによるSaaSイベント管理）勧告が解決するとAdvisory Resolvedが届き、アクセスを変更していた場合は、販売者の判断で元に戻せます。（Amazon EventBridgeによるSaaSイベント管理）

ガイドごとに、強調する点が少し異なります。契約製品の連携ガイドは、対応が必須の通知としてLicense Updatedだけを挙げ、GetEntitlementsで新しい状態を確認するよう求めています。（契約製品の連携）従量課金製品の連携ガイドは、SaaS Subscriptionの製品ではGetEntitlementsを使わないとし、購読の通知から保存した顧客の最新の状態で、利用の可否を判断するよう求めています。（従量課金製品の連携）一方、Amazon EventBridgeのガイドは、契約の終了を権利の取り消しの起点、License Deprovisionedを最終使用量の報告の起点としています。そのため、実装では、これらのガイドの内容を満たすように、License Updated、Purchase Agreement Ended、License Deprovisionedの三つを処理することになります。

ルールの組み立て

イベントは、販売者アカウントのデフォルトのイベントバスに届きます。ルールのイベントパターンでは、イベントのソースにAWS servicesを選び、AWSサービスとしてAWS Marketplace Agreements and Licensesを選びます。パターンのsourceはaws.agreement-marketplaceで、detail-typeでイベントの種類を絞ります。（Amazon EventBridgeによるSaaSイベント管理）移行ガイドは、ルールを米国東部（バージニア北部）リージョンに作るよう求めています。（Concurrent Agreements移行ガイド）ターゲットには、Amazon Simple Queue Service（Amazon SQS）のキューが推奨されています。（契約製品の連携）

見落としやすいのは、Purchase Agreementの通知が、販売者の立場によって種類の違うイベントとして届く点です。SaaS製品をPublic Offer（パブリックオファー）かPrivate Offer（プライベートオファー）で直接販売する場合、販売者は製品の製造元であり、オファーの提案者でもあるため、重複を避けて提案者向け（Proposer）のイベントだけが届きます。チャネルパートナーが再販する場合は、製造元（Manufacturer）として受け取ります。（Amazon EventBridgeによるSaaSイベント管理）そのため、Purchase Agreementのイベントについては、パターンをManufacturer向けとProposer向けの両方に一致する形にしておくと、販売形態が増えても取りこぼしません。

アクセスを開く時期

オンボーディングのガイドは、License Updatedのイベントを受信するまで、購読を有効にしないよう求めています。SaaS SubscriptionとSaaS Contract with Consumptionの顧客も、このイベントを受信してからメータリングを始められる状態になり、それより前に送信した使用量記録は計上されません。（SaaSの顧客オンボーディング）購入直後に画面を開く処理と、権利が確定してからアカウントを有効にする処理は、別のタイミングで動くことになります。

License Updatedを受けたあとの処理は、料金モデルで分かれます。SaaS ContractとSaaS Contract with Consumptionでは、GetEntitlementsを呼んで新しい状態を読み直し、その結果に合わせて提供内容を変えます。（契約製品の連携）SaaS Subscriptionでは、GetEntitlementsを使いません。通知から保存した購読の状態で利用の可否を決め、License Updatedを受けてからメータリングを始めます。（従量課金製品の連携、SaaSの顧客オンボーディング）

GetEntitlementsを使うモデルでは、イベントを状態そのものではなく再取得のきっかけとして使うと、同じ通知が複数回届いても結果が同じ状態に収束します。これは公式の記述ではなく、本記事の提案です。

BatchMeterUsageで使用量を送る

SaaS SubscriptionとSaaS Contract with Consumptionでは、SaaSが使用量をAWS Marketplaceへ送り、AWSがそれをもとに購入者へ請求します。この送信がBatchMeterUsageで、顧客が使い始めたら、使用量の記録を毎時送信する必要があります。同じ時間帯の記録は重複が排除され、使用量がなかった時間帯も、0を送信することが推奨されています。（従量課金製品の連携）

BatchMeterUsageの制約は、送信処理の設計に直接影響します。（BatchMeterUsage API）

従来のProductCodeと、新しいLicenseArnの両方で、同じ顧客の使用量を同じ時間帯に送信すると、二重に請求されます。従来の方式から移る場合は、LicenseArnでの送信を始める前に、ProductCodeでの送信を停止します。（BatchMeterUsage API）

契約が終わるときの最終報告は、License Deprovisionedを受信してから1時間以内に行います。（Amazon EventBridgeによるSaaSイベント管理）使用量の集計、ライセンスごとの送信、再送、送信記録の保存は、AWS Marketplaceのメータリング実装で扱っています。

2026年9月30日、AWSは、AWS Marketplaceにおける従量課金の仕組みとの連携を実装し、検証するための、メータリングのSkills（スキル）について、Model Context Protocol（MCP）に対応するAWS MCP Server経由での一般提供を始めたと発表しました。対象は、ResolveCustomer、BatchMeterUsage、Concurrent Agreements、Amazon EventBridgeによる購読イベントです。（AWSの発表）

SaaS側に残る権限制御と識別子の設計

ここまでの部品は、AWSの定めた形に合わせて作ります。一方、受け取った契約情報で顧客のテナントに何を許すかは、SaaSが決めます。

まず、契約を識別するキーです。Concurrent Agreementsの移行ガイドは、データベースの主キーを、CustomerIdentifierやProductCodeからLicenseArnへ置き換えるよう勧めています。使用量を、顧客ではなく特定の購入ライセンスに結び付けられるからです。（Concurrent Agreements移行ガイド）一つのAWSアカウントが、同じ製品に複数の契約を結べるようになったため、アカウントIDだけでは契約を一つに特定できません。ただし、登録ページの節で見たように、開始日が将来の契約では契約の開始日までLicenseArnが生成されないため、その間は主キーに使えません。（Concurrent Agreements移行ガイド）その間の扱いは、アカウントの有効化とメータリングを保留する設計と合わせて、製品ごとに決めておく必要があります。これは公式の記述ではなく、本記事の提案です。

次に、契約とテナントの対応です。同じ移行ガイドは、ライセンスごとにテナントを分ける、複数のライセンスを一つのテナントにまとめる、購入者に選ばせる、という三つの方針を挙げています。（Concurrent Agreements移行ガイド）2026年10月5日時点でも、オンボーディングのガイドには、アカウントIDの重複がないことを確認するよう求める記述が残っていますが、複数の契約では同じAWSアカウントIDに複数のライセンスが付くため、テナントの設計は製品ごとの判断になります。（SaaSの顧客オンボーディング）既存ユーザーが追加で購入した場合や、複数契約の誤った紐付けを防ぐ設計は、AWS Marketplaceの契約をSaaSテナントに紐付けるには？で扱っています。

最後に、終了時の処理です。権利の取り消し、最終使用量の報告、顧客データの削除は、それぞれ別の処理です。掲載基準は、顧客のデータが不要になった場合や顧客から求められた場合に、End User License Agreement（EULA）で定めた期間内に削除することを求めています。（SaaS製品のガイドライン）返金と取消の運用を含む終了時の扱いは、AWS Marketplaceの解約、返金対応に詳しくまとめています。

公開前のテストと審査で確かめられること

製品は最初に限定公開（limited）で公開され、統合とテストのためだけに使える状態になります。（SaaS製品の作成）テストは、許可されたアカウント（allowed account）で契約して行います。（契約製品の連携）実装とテストが終わったら運用チームに通知すると、SaaS ContractとSaaS Contract with Consumptionの製品ではGetEntitlementsの呼び出しと新規顧客のオンボーディングが、SaaS SubscriptionとSaaS Contract with Consumptionの製品ではBatchMeterUsageによる使用量の送信も検証されます。（契約製品の連携、契約と従量の連携）チーム名は引用元によって分かれており、SaaS Contractの連携ページはAWS Marketplace Operationsチーム、契約と従量の連携ページはAWS Marketplace Seller Operationsチームと書いています。テストの手順と審査での確認項目は、AWS MarketplaceのSaaS審査で確認することで整理しています。公開までの全体の工程は、AWS MarketplaceにSaaSを出品する方法にあります。

PRMの計測方式は、この連携機能とは別に実装する

本記事で扱ってきたAPIとイベントは、購入、契約、権利、使用量を扱うものです。これとは別に、自社の製品が牽引したAWSサービスの消費をAWSへの収益寄与として計測するPartner Revenue Measurement（PRM）があり、こちらはリソースへのタグ付けか、AWS API呼び出しへのUser Agentの付与で実装します。SaaSの従量課金で使うBatchMeterUsageは顧客への請求のためのAPIで、PRMの計測方式ではありません。方式の選び方と設定値は、AWS PRMの実装方法で整理しています。

見積もりの工数が動く場所

工数を左右するのは、登録ページでの新規作成と既存アカウントへのログインの分岐、License Updatedを受信するまで有効化を保留する状態管理、権利が足りないときの扱い、契約終了時の停止とデータ削除、Purchase AgreementのManufacturer版とProposer版の両方を受信するルールです。どれも、既存のサインアップ、解約処理、テナント管理にどう組み込むかで規模が変わります。人日の数字はAWS側の仕様からは出てこないため、自社の認証とテナント管理の実装を確認したうえで、部品ごとに積み上げることになります。

SaaS Contractで出品する場合の、Deshimaの担当範囲と次の行動

これらの部品のうち、SaaS Contract型の製品について、登録から契約情報の同期までをDeshimaが提供しています。セラーアカウントを連携すると、AWS IAMロールとAmazon EventBridgeのルールが自動で作成されます。接続には、最小権限のAWS IAMロールとExternalId付きのAssumeRoleを使い、アクセスキーは預かりません。

Deshimaは、購入者と契約の情報の取得と同期、利用申請フォーム、Amazon EventBridgeへのイベント発行を担います。自社SaaSでは、そのイベントを既存のユーザーやテナントに結び付け、契約に応じた機能、数量、利用可否を反映する処理を実装します。契約内容に応じて何を許すかの方針は、権限制御の節で見たとおり、製品側で決めます。具体的な分担は、導入する構成に応じてご確認ください。

2026年10月5日時点で、DeshimaはSaaS Contract型のみに対応しています。従量課金（メータリング）と、Channel Partner Private Offer（CPPO）は対象外です。ここまでの部品でいえば、BatchMeterUsageによる使用量の送信はDeshimaの対象に入りません。Concurrent Agreementsには対応済みです。詳しい対応範囲はトップページのFAQに記載しています。

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

SaaS Contractで出品する場合の次の行動は、無料のアカウントを作成し、掲載タスク一覧と連携手順を確認することです。Deshimaは更新が多いため、最新の機能と対応範囲は、無料のアカウントを作成したうえで、プロダクト内のドキュメントでご確認ください。

自社で実装するかDeshimaを使うかの比較は、AWS Marketplace出品を自社で進めるかDeshimaを使うかで、作業と費用の観点から整理しています。