AWS Marketplaceの契約をSaaSテナントに紐付けるには？既存ユーザーと複数契約の設計

AWS Marketplaceで購入した顧客が自社SaaSの登録URLにリダイレクトされたとき、SaaSが受け取る情報だけでは、その契約をどのテナントに渡すかを決められません。購入者のブラウザから送信されるのは一時的な登録トークンで、ResolveCustomerで引き換えると、購入者のAWSアカウントID、付与されたライセンスを表すLicenseArn、製品コード、そして購入者が承諾した契約のIDを含むメタデータが返ります。返ってくる項目のどこにも、自社のテナントやユーザーを指すものはありません。（ResolveCustomer API）

Concurrent Agreements以前のAWS Marketplaceでは、同じAWSアカウントが同じ製品に持てる有効な契約は一つだけでした。アカウントを指す識別子が、そのまま契約を指す識別子としても働いていたことになります。2026年のConcurrent Agreementsで、この前提は外れ、同じアカウントが同じSaaS製品に、別々の条件と価格の契約を複数結べるようになりました。（移行ガイド）

すでにテナントを持つ会社が2本目の契約を結んだとき、その契約は既存のテナントに加えるのでしょうか。それとも、別のテナントを作るのでしょうか。どちらが正しいかは、製品の課金の単位と、顧客の組織の作りによって変わります。

本記事の内容は、2026年10月5日に確認したAWSの公式ドキュメントと発表にもとづきます。データモデルやテナントの扱いの例は、公式ガイドの記述をもとにした設計案であり、AWSが定める仕様ではありません。

権利の取得の具体例は、SaaS Contract（SaaS契約。契約期間と購入する権利をあらかじめ定め、前払いまたは支払スケジュールで請求する料金モデル）とSaaS Contract with Consumption（従量制料金によるSaaS契約。契約の料金に加えて超過分を従量で請求する料金モデル）の製品向けで、以下ではこの二つをSaaS Contract系と呼びます。SaaS Subscription（SaaSサブスクリプション。時間単位の使用量に応じて請求する従量課金の料金モデル）の製品は、GetEntitlementsを使いません。購読の通知の状態（購読成功、解約の保留、解約成功、購読失敗。PAYG製品の連携ガイドでは、Amazon SNSの通知として説明されています）で、購読が有効かどうかを管理します。（PAYG製品の連携）

登録URLで受け取る情報と、受け取れない情報

購入者はAWS Marketplaceから、自社SaaSの登録URLへHTTP POSTでリダイレクトされ、リクエストには一時的な x-amzn-marketplace-token が含まれます。SaaSはこのトークンをResolveCustomerで引き換え、返った項目を保存します。SaaS ContractとSaaS Contract with Consumption（以下、SaaS Contract系）の製品では、続けてGetEntitlementsで購入内容を確かめます。（SaaS契約製品の連携、SaaS Contract with Consumption製品の連携）SaaS Subscriptionの製品ではGetEntitlementsを使わず、購読の通知で購読が有効かどうかを保存します。リソースを作る前に、購読成功の通知を待つことが強く勧められています。（PAYG製品の連携）登録、権利確認、契約通知を含むSaaS連携の全体像は、AWS MarketplaceのSaaS連携に必要な実装で整理しています。

引き換えで得られる項目は、次の五つです。

表の出典は、ResolveCustomer APIです。

テナントIDもユーザーIDも、ResolveCustomerの応答には含まれません。登録ページには、購入者のメールアドレスの入力欄を設けることが求められます。（SaaS製品のガイドライン）ただし、そこに入るのは購入者がその場で打ち込んだ文字列で、アドレスの持ち主であることまでは示しません。紐付けの根拠にできるのは、ログインや確認メールのように、SaaS側で購入者本人の操作を確かめられた事実です。

トークンの引き換えを先に済ませる

ログインやテナントの選択を購入者に求めるなら、トークンの引き換えはその前に終えておきます。登録トークンは、ブラウザの遷移に時間がかかったとき、購入者が再送信したとき、SaaSが長く保持したときに期限切れとなり、受け取ったらすぐ引き換えるよう求められているからです。（ResolveCustomer API）

そこで、POSTを受けた時点でResolveCustomerを呼び、得たLicenseArnとAWSアカウントIDを「未紐付けのライセンス」として保存します。購入者のセッションには、そのライセンスへの参照だけを保存します。その後のログイン、テナントの選択、新規登録は、未紐付けのライセンスを、ログインしたユーザーが自社SaaSのいずれかのテナントに紐付ける操作として設計できます。

ただし、登録の時点でLicenseArnが必ず手に入るとは限りません。開始日を将来に設定した契約では、LicenseArnが契約の開始日に生成されると、移行ガイドにあります。（移行ガイド）登録時にResolveCustomerがこの場合に何を返すかは、2026年10月5日時点のResolveCustomer APIのリファレンスと移行ガイドには記載がありません。そこで、LicenseArnが得られない場合の扱いを決めておきます。たとえば、仮登録には固有の登録IDを付け、AWSアカウントIDは検索と照合に使う形が考えられます。同じ購入者が複数の契約を持てるため、アカウントIDだけを仮登録の一意キーにすると、別々の契約のレコードが衝突するからです。仮登録には、Purchase Agreement Createdで届く契約IDも記録しておきます。のちに届くLicense Updatedの agreement.id がその契約IDと一致したら、license.arn を仮登録に書き込んで確定します。同じアカウントに開始前の契約が複数あり、仮登録がどの契約のものか一つに決まらないときは、購入者に確認する経路を残します。これはAWSが指定する構造ではなく、本記事の設計案です。

テナント、AWSアカウント、ライセンスを別々に持つ

紐付けには、性質の違う三つの対象が登場します。

• AWSアカウント：購入者のアカウントです。1アカウントが、同じ製品の複数の契約を持てます。
• ライセンス：契約によって付与される、利用の権利です。契約が異なれば、別のLicenseArnになります。
• テナント：自社SaaSの中での、顧客の単位です。AWSは関与しません。

購入者から、ライセンスを別のAWSアカウントに共有したいと相談されることがあります。AWS側での共有の可否と、SaaS内のテナント・ユーザー管理との違いは、AWS MarketplaceのSaaSライセンスは別アカウントに共有できる？で扱います。

なお、請求の宛先がさらに別の企業になることもあります。購入者が請求代行を利用している場合に、支払いの主体とSaaSを実際に使う企業をどう分けて持つかは、AWS Billing Transferとは？で扱います。

AWSの移行ガイドは、CustomerIdentifierやProductCodeを軸にした既存の主キーを、LicenseArnに置き換えるよう勧めています。複数のライセンスを持ち得る顧客ではなく、特定の購入ライセンスに使用量を帰属させるほうが、プロビジョニングと課金が単純になるためです。（移行ガイド）この考え方をテナントとの対応に広げると、自社のデータベースに用意すべきテーブルは次の形になります。

licenses
  registration_id           主キー。自社で付ける固有の登録ID
  license_arn               生成後は一意。開始日が未来の契約では、生成されるまで空
  agreement_id              契約のID。一意キーにはしない
  customer_aws_account_id   購入者のAWSアカウントID
  tenant_id                 紐付けが済むまでは空
  claimed_by_user_id        紐付けを確定したSaaS側のユーザー
  status                    未紐付け / 有効 / 終了
  entitlements              GetEntitlementsの結果（ディメンションごとの数量と期限）。SaaS Contract系のみ。SaaS Subscriptionでは使わず、空

tenant_idを空にできる欄が、「未紐付けのライセンス」を受ける場所になります。テナントとライセンスは一対多で、AWSアカウントとライセンスも一対多です。契約とライセンスも一対一とは限りません。Agreements data feed（データフィード）では、契約に対応するライセンスIDが配列として定義されているからです。（Agreements data feed）そのため契約のIDは、一意キーにはせず、終了のイベントからライセンスを探すための参照として保存します。

購入者の状態別に見る紐付けの流れ

登録URLにアクセスした購入者が、自社SaaSに対してどの状態にいるかで、紐付けの手順は分かれます。

初めて購入する新規顧客

引き換えと保存を終えたあと、登録フォームで購入者にテナントとユーザーを作ってもらい、ライセンスのtenant_idを埋めます。AWS Marketplaceのガイドラインは、購入後に顧客がSaaS内でアカウントを作ってWebコンソールにログインできることを求めています。すぐにログインできない場合は、ログインできる時期を具体的に案内し、アカウントができたら確認の通知を送ります。（SaaS製品のガイドライン）

既存のSaaSユーザーが購入する

無料プランやトライアルですでに自社SaaSを使っている会社が、有料の契約をAWS Marketplaceで結ぶ場合です。ガイドラインは、すでにSaaSのアカウントを持つ顧客が、fulfillment landing page（フルフィルメントのランディングページ）からログインできることを求めています。（SaaS製品のガイドライン）

ログインできるだけでは、紐付けの設計は終わりません。ログインで確かめられるのはそのユーザーが誰かまでで、そのテナントに契約を付けてよいかは別の確認だからです。既存のテナントに付けるときは、ログインしたユーザーがそのテナントの管理権限を持つことを確かめます。誰でも付けられるなら、有料の権利が意図しないテナントに付く余地が生じます。メールアドレスの一致だけで自動的に紐付ける実装も避けます。入力されたアドレスは、購入者がその場で打ち込んだ文字列にすぎず、持ち主であることを示さないからです。打ち間違えたアドレスや他社の担当者のアドレスが入力されると、契約が別の会社のテナントに付いてしまいます。複数のテナントに所属するユーザーなら、どのテナントに付けるかを選ぶ画面も要ります。

同じAWSアカウントが追加で購入する

同じAWSアカウントが同じ製品を追加で購入する場面は、Concurrent Agreementsによって新しく生じたものです。同じアカウントからの購入なので、ResolveCustomerが返すCustomerAWSAccountIdは1本目と同じで、LicenseArnだけが新しくなります。自社のlicensesテーブルでこのアカウントIDを検索すれば、すでに紐付いているテナントが見つかり、そこに加えるか、別のテナントを作るかを決めることになります。

AWSの移行ガイドは、複数のライセンスを扱う方式として三つを挙げています。（移行ガイド）

どの方式でも、購入者に聞かずに自動で一つのテナントへまとめる運用は避けたいところです。AWSの発表は複数契約の利点として、一つのアカウントの複数の部門が、それぞれ独立して調達できることを挙げています。（AWSの発表）このため、別の部門が別の目的で結んだ契約は、既存のテナントに足されることを望まないかもしれません。

一つのテナントにまとめる方式では、契約ごとの権利をどう合算するかも決めます。SaaS Contractには、購入者がディメンションごとに数量を選ぶ型と、複数の段階から一つを選ぶ型があります。（SaaS契約の料金）ユーザー数のような数量は足し合わせられますが、段階型の契約が二つあるときは足せません。上位の段階を採るのか、別のテナントに分けるのかは、製品の仕様として決めます。権利はライセンスごとに保存し、テナントの有効な権利は付いているライセンスから計算する形にしておけば、合算の規則を変えても、保存したデータを作り直さずに済みます。

別のAWSアカウントから購入する同じ会社

同じ会社が複数のAWSアカウントを使い分けていると、CustomerAWSAccountIdは既存の紐付けと一致せず、licensesテーブルを検索しても既存のテナントは見つかりません。アカウントIDの一致は紐付けの候補を絞る手がかりであって、同じ会社の証明ではなく、不一致も別の会社の証明にはなりません。そのため、アカウントIDが未知でも、ログインした購入者が既存のテナントを選べる経路を残します。

契約が変わったり終わったりしたとき

契約を承諾した時点と、利用権が有効になる時点がずれることもあります。利用開始日を将来に置いた契約の扱いは、AWS MarketplaceのFuture Dated Agreementsとは？で扱います。

2本の契約のうち1本が終わったとき、テナントを停止してよいのでしょうか。一つのテナントに複数のライセンスを付ける方式であれば、停止してよいのは、そのテナントに付いた有効なライセンスがなくなったときだけです。有効なライセンスが残っていても、テナントの権利を付いているライセンスから計算する設計なら、1本が終わればその計算の結果が変わります。終わったライセンスにだけ含まれていた機能や数量は、残った有効なライセンスの権利で再計算し、減らします。契約の変更や終了は、Amazon EventBridgeのイベントで届きます。（Amazon EventBridgeによるSaaSイベント管理）次の表でGetEntitlementsを呼ぶ反映は、SaaS Contract系の製品の場合です。SaaS Subscriptionの製品はGetEntitlementsを使わず、購読の通知の状態（PAYG製品の連携ガイドでは、Amazon SNSの通知として説明されています）で管理します。Amazon EventBridgeによるSaaSイベント管理のガイドは、購読の変更と契約の権利の変更の両方でイベントを送るとしており、License Deprovisionedでは、従量課金の部分を持つ製品向けの最終使用量の枠も説明しています。（Amazon EventBridgeによるSaaSイベント管理）ただし、SaaS Subscriptionの製品がLicense Updatedを受けたとき、GetEntitlementsを使わずに何で権利を確かめるかは、2026年10月5日時点のこのガイドとPAYG製品の連携ガイドには記載がなく、確認が必要です。

表の出典は、Amazon EventBridgeによるSaaSイベント管理と、Amazon EventBridgeイベントです。SaaS Contract型の製品でAWSが対応を必須としているのは、License Updatedのイベントです。受けたらGetEntitlementsを呼び、新しい状態で顧客のデータを更新します。（SaaS契約製品の連携）SaaS Contract with Consumptionの連携ガイドも、権利の変更の通知を受けたらGetEntitlementsを呼ぶよう求めています。ただし、2026年10月5日時点のそのガイドは通知をAmazon SNSの entitlement-updated として書いており、Amazon EventBridgeのLicense Updatedとの対応は記載がありません。（SaaS Contract with Consumption製品の連携）

イベントの例を確認すると、ライセンスのイベントには license.arn と agreement.id が含まれます。一方、契約の終了イベントの例にあるのは agreement.id と acceptor.accountId などで、ライセンスの項目はありません。（Amazon EventBridgeイベント）このため、License Updatedで届いた agreement.id と license.arn の組をlicensesテーブルに保存し、終了のイベントが届いたとき、契約IDから停止すべきライセンスを探せるようにします。これに対し、License Deprovisionedの例には license.arn が含まれるため、このイベントでは、ライセンスを直接指して終了にできます。イベントの到着順や重複の扱いは、2026年10月5日時点のAmazon EventBridgeによるSaaSイベント管理のガイドには記載がありません。したがって、同じイベントが2度届いても、順序が入れ替わっても、結果が変わらない処理にしておきます。

SaaS Contract系では、権利の中身は、イベントではなくGetEntitlementsで確かめます。ProductCodeは必須で、LICENSE_ARNやCUSTOMER_AWS_ACCOUNT_IDで絞り込めます。一度に返る件数は最大25件で、続きはNextTokenで取得し、空の結果にもNextTokenが付くことがあるため、空だからといって取得を打ち切るわけにはいきません。（GetEntitlements API）

自動更新では新しい契約が作られ、Purchase Agreement Createdのイベントに intent=RENEW と前の契約のIDが入ります。（Amazon EventBridgeイベント）Agreements data feedにも、更新によって新しい契約に移った旧契約を表す、Renewedという状態があります。（Agreements data feed）ところが、更新後のライセンスが前のLicenseArnを引き継ぐのかどうかは、2026年10月5日時点の移行ガイドとAgreements data feedのガイドには記載がありません。旧契約がRenewedになるとき、Purchase Agreement Endedのイベントが届くのかどうかについても、これらの資料には記載がありません。

引き継がれないなら、更新のたびに「未紐付けのライセンス」が生まれ、テナントが権利を失ったように見えるおそれがあります。引き継がれるなら、旧契約のEndedを受けて権利を取り消す設計は、更新後も有効な権利を停止してしまいます。Endedの処理でGetEntitlementsを呼ぶのは、後者に備えるためです。どちらになるかは、実際に契約を更新して確かめる項目になります。解約や返金に伴う権限制御は、AWS Marketplaceの解約と返金対応で整理しています。

既存の顧客データにLicenseArnを加える

すでにCustomerIdentifierで顧客を管理している既存の製品は、自動では移行されません。有効にしたい場合は、公式の問い合わせフォームで申請するオプトインの扱いです。（移行ガイド）

Concurrent Agreementsは2026年2月に提供が始まり、2026年6月1日以降に作成する新規のSaaS製品では、対応が必須となり、既定で有効になります。（AWSの発表、移行ガイド）

オプトインする製品では、顧客の既存レコードにLicenseArnを加える作業が要ります。移行ガイドの7月24日の更新は、取得方法を二つ示しています。（移行ガイド）

• Agreements data feedとAgreements and Renewalsダッシュボードで、License IDsを確認する
• SaaS Contract系の価格設定なら、GetEntitlementsをCUSTOMER_AWS_ACCOUNT_IDで絞り込んで取得する（SaaS Subscriptionはdata feedかダッシュボードを使う）

GetEntitlementsでは、CustomerIdentifierとCustomerAWSAccountIdを同じリクエストで併用できません。移行中のSaaS連携の実装には、Account data feedでCustomerIdentifierとCustomerAWSAccountIdを、Agreements data feedでCustomerAWSAccountIdとLicenseArnを対応づけるよう案内されています。（GetEntitlements API）Agreements data feedは24時間ごとに更新されるため、移行の直前の購入は、反映が遅れる可能性があります。（Agreements data feed）

オプトインの前は、同時に有効な契約が1アカウントに一つでした。ただし、更新済みや終了済みの契約まで含めた履歴には、複数のライセンスがあり得ます。そのため、GetEntitlementsやdata feedで取得したLicenseArnを、そのまま既存のテナントに対応づけるわけにはいきません。既存の顧客ID（CustomerIdentifier）ごとに、取得したライセンスを稼働中、将来開始、終了済みに分けて照合し、稼働中のライセンスをテナントに付けます。将来開始の契約は、開始日にLicense Updatedが届いた時点でその顧客のテナントに付け、終了済みのライセンスは終了として記録します。オプトインの後は、同じアカウントから2本目の購入が届き得ます。したがって、付け先を選ぶ画面は、オプトインより先に用意しておきます。申請の手順はAWS MarketplaceのConcurrent Agreementsとは？で、使用量の送信側の変更はAWS Marketplaceのメータリング実装で整理しています。

公開前に確認すべき紐付けのシナリオ

公開前には、販売者が許可リストのアカウントで自社製品と契約し、リダイレクトの受け取り、顧客IDの保存、権利の扱いを確かめます。そのあとAWS Marketplace Operationsチームが、GetEntitlementsの呼び出しと新規顧客のオンボーディングを確認します。（SaaS契約製品の連携）AWS側の確認の観点は、AWS MarketplaceのSaaS審査で確認することにまとめています。複数契約の紐付けについては、これに加えて、次のシナリオを自社で確かめておきます。公式の必須項目ではなく、本記事の設計案から導いた確認項目です。

• 同じ購入者が登録URLに2度アクセスしても、同じライセンスのレコードが二つできない
• 既存ユーザーは、ログインしなければ契約を付けられず、権限のないメンバーは付けられない
• 同じAWSアカウントの2本目の購入で、1本目の契約が上書きされない
• 2本のうち1本を終了させても、残る1本の権利でテナントが使える
• 終了させた1本にだけ含まれていた機能と数量が、残る1本の権利で再計算されて減る
• 権利の変更後、変更されたライセンスの数量だけが変わる
• 更新後のLicenseArnの扱いを確かめ、その結果に合わせて引き継ぎの規則を決める
• 更新で旧契約が終わったとき、更新後も有効な権利を停止しない
• 開始日が未来の契約で、LicenseArnが得られない段階でも、登録のレコードが作れて、あとから埋められる
• 同じAWSアカウントに開始日が未来の契約が複数あっても、仮登録のレコードが衝突しない

購入者が登録URLに戻ってきたとき、AWSが渡すのはアカウントとライセンスまでです。そのライセンスが誰のテナントのものかは、ログインした購入者の操作と、自社のlicensesテーブルに残した対応で決まります。2本目の購入が届いたときに、licensesテーブルからこの会社の既存のテナントが見つかり、付け先を尋ねる画面が開くようにしておきます。そこまで実装できていれば、契約が別のテナントに渡る誤りは、設計の側で減らせます。

案件ごとの配分を扱うときに必要になる情報

本記事で設計したlicensesテーブルの対応は、SaaS内の利用権の管理のためのものです。加えて、複数のテナントが同じAWSの基盤を共有している製品では、その基盤で計測されたAWSの消費を、顧客ごとの案件に月別の割合で配分する場面があります。Partner Revenue MeasurementのRevenue Attribution IDがその仕組みで、配分の入力には、購入者のAWSアカウントIDや、どのテナントの消費をどの案件に含めるかの判断が要ります。本記事で持つことにした対応は、その判断の材料にもなります。配分の設計はPRMの計測結果の確認と案件への紐付けで扱っています。

Deshimaで扱える範囲

購入後の登録フォームと、購入者情報と契約情報の同期を自社で作らずに済ませたい場合は、AWS Marketplaceへの掲載を支援するDeshimaの利用申請フォームが選択肢になります。Deshimaは、購入者と契約の情報の取得と同期、利用申請フォーム、Amazon EventBridgeへのイベント発行を担います。自社SaaSでは、そのイベントを既存のユーザーやテナントに結び付け、契約に応じた機能、数量、利用可否を反映する処理を実装します。本記事で設計した、licensesテーブルへの対応付けや付け先の選択、権利の再計算は、この自社側の処理にあたります。具体的な分担は、導入する構成に応じてご確認ください。

私たちアンチパターンの運用では、明細から分かるのがAWSアカウントIDとアカウント保有者の情報だけで、リセラーが発行したアカウントでは保有者がリセラーになる、という課題が見つかりました。Deshimaは、エンド顧客の情報、AWSアカウントID、保有者の情報を紐づけて保持する仕組みを提供しています。

一方、既存ユーザーのログインとの突き合わせや、複数の契約をどのテナントに割り当てるかの方針を、フォームでどこまで扱えるかについては、導入前に個別にご相談ください。

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

2026年10月5日時点の対応範囲は、SaaS Contract型のみで、従量課金（メータリング）とChannel Partner Private Offer（CPPO）は対象外、Concurrent Agreementsには対応済みです。対応範囲はトップページのFAQに、料金の考え方は料金のセクションに記載しています。

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