AWS JAPAN APN ブログ

SaaS 製品を AWS Marketplace Concurrent Agreements にアップグレードするための完全ガイド

本記事は、AWS で Technical Account Manager を務める Tanvi Upadhyay、Partner Solutions Architect を務める Philipp Sacha による「Complete guide to upgrading your SaaS product to AWS Marketplace Concurrent Agreements」を翻訳したものです。

2026 年 7 月 24 日更新: 本ブログは、既存顧客の LicenseArn をバックフィルするために販売者が実行できる手順を反映するため、「既存顧客に対する LicenseArn のバックフィル」セクションを更新しました。

2026 年 6 月 12 日更新: 本ブログは、2026 年 6 月 1 日より前に作成された SaaS 製品で Concurrent Agreements を有効化するために販売者が現在利用できる手順を反映するため、オプトイン手順のセクションを更新しました。

AWS Marketplace は、SaaS 製品およびプロフェッショナルサービス製品向けに Concurrent Agreements (同時契約) をサポートするようになりました。これにより、単一の Amazon Web Services (AWS) アカウント内で同一製品に対する複数のアクティブな購入が可能になります。2026 年 6 月 1 日以降、AWS Marketplace ではすべての新規 SaaS (Software as a Service) 製品に対し、更新された統合要件のサポートが必須となります。

本ガイドでは、Concurrent Agreements を実装するための技術的な移行手順を解説します。Amazon Simple Notification Service (Amazon SNS) から Amazon EventBridge への移行、API の更新、そして SaaS 統合内で複数のライセンスを管理するためのベストプラクティスを取り上げます。

販売者に該当する内容は以下のとおりです。

  • 2026 年 6 月 1 日以降に作成された新規リスティング – 製品では Concurrent Agreements がデフォルトで有効になります。
  • 2026 年 6 月 1 日より前に作成された既存リスティング – 既存製品では Concurrent Agreements はオプトイン方式です。後述のオプトイン手順のガイドで統合手順を説明します。

既存のリスティングで Concurrent Agreements にオプトインすることも、新たに有効化されたリスティング上に構築することもできます。いずれの場合も、顧客ごとに複数のアクティブな契約を処理できるよう統合を更新する必要があります。本ガイドで説明する API の変更、イベントスキーマの更新、およびライセンス管理ロジックは、どちらのケースにも適用されます。

オプトインする代わりに、Concurrent Agreements が有効な新しいリスティングを作成し、レガシーのリスティングを制限して、契約の更新に合わせて顧客の移行を進めるという移行アプローチもあります。レガシーのリスティングに手を加えたくない場合には、これが良い選択肢となり得ます。既存の統合をその場で更新するのではなく、顧客を段階的に移行できます。

Concurrent Agreements を利用するビジネス上の意義

これまでは、1 アカウントにつき 1 契約という制限があったため、販売者は契約ベースのオファー、製品リスティングの重複作成、キャンセルと再発行のプロセスといった回避策を使わざるを得ませんでした。

Concurrent Agreements により、購入者は単一の AWS アカウント内で同一製品に対して複数のオファーを、それぞれ独立した条件と価格で受け入れられるようになります。

これにより、次のことをサポートできるようになります。

  • 柔軟な調達 – 1 つの AWS アカウントで同一の SaaS 製品に対する複数の独立した契約が可能になり、製品ごとの 1 契約制限が撤廃されます。
  • 独立した契約条件 – 異なるビジネスユニットがそれぞれ独自に交渉した契約で個別に購入する、マルチチーム調達が可能になります。
  • シームレスな拡張 – 既存の契約を妨げたり、財務・調達部門の承認プロセスを経たりすることなく、新規プロジェクトやキャパシティの追加が可能になります。

何が変わるのか: LicenseArn と新しいアーキテクチャ

AWS Marketplace は、主要な API 全体にわたって新しいパラメータ LicenseArn を導入します。従来は、製品 ID と顧客識別子を使用してサブスクリプションを識別していました。製品ごとに複数のアクティブな契約が存在するようになると、各契約に対して一意の識別子が必要になります。

LicenseArn は、顧客が AWS Marketplace を通じて製品を購入した際に受け取る各ソフトウェアライセンスを一意に識別します。

LicenseArn が重要な理由:

  • 同一製品に対する複数のアクティブなライセンスを区別できます。
  • 特定のレートカードに対する使用量を追跡できます。
  • 正しい契約への正確な使用量の紐付けが可能になります。

契約 ID (Agreement ID) と LicenseArn の主な違い:

  • 契約 ID は、当事者間の商業上または法律上の取り決めを表します。
  • LicenseArn は、ソフトウェアを使用する実際の認可または権利を表します。

注: 将来の開始日が設定された契約の場合、LicenseArn は契約開始日に生成されます。これは契約 ID が作成されてから数か月後になる可能性があります。

SaaS 製品を Concurrent Agreements 対応にアップグレードすると、次の変更が発生します。

  • 新しい LicenseArn パラメータ – 新しい契約ごとに一意のライセンス識別子が付与されます。
  • EventBridge への移行 – サブスクリプション通知を Amazon SNS から Amazon EventBridge へ移行します。 (SNS は LicenseArn をサポートしていません)
  • API の更新 – 3 つのコア API は LicenseArn をサポートします。
  • CustomerIdentifier の廃止 – 2026年6月1日以降、新規 SaaS 製品では CustomerIdentifier の代わりに CustomerAWSAccountId を使用する必要があります。

サポート対象の製品タイプ

  • プロフェッショナルサービスは、すべてのリスティングで自動的に有効化されます。お客様側での対応は不要です。
  • 2026 年 6 月 1 日以降に作成された新規リスティングでは、Concurrent Agreements がデフォルトで有効になります。

2026 年 6 月 1 日より前に作成された既存の SaaS リスティングでは、Concurrent Agreements は自動的には有効化されません。これらの製品で Concurrent Agreements の利用を希望する販売者は、以下の手順でオプトインできます。

オプトイン手順:

1. Contact Us フォームに移動し、次のように選択します。

  • Primary email address (主要メールアドレス) : 希望する連絡先メールアドレスを入力します。
  • Which AWS Marketplace Catalog are you inquiring about? (どの AWS Marketplace カタログについての問い合わせですか?) : Commercial Marketplace を選択します。
  • What do you need help with? Pick a category that best applies (どのようなサポートが必要ですか?最も当てはまるカテゴリを選択してください) : Product Configuration / Integration を選択します。
  • Select a subcategory (サブカテゴリの選択) : Concurrent Agreements Support を選択します。

2. Provide more details about your request (リクエストの詳細を記入) 欄に、以下のテンプレートをコピーして貼り付け、必要な情報を記入します。

Hello,

I have an existing AWS Marketplace SaaS product with active subscribers and would like to discuss enabling Concurrent Agreements.

Seller Account ID: [Your seller account ID]
Product ID: [Your product ID]
Number of active agreements: [Number]

I am unable to create a new listing because:
[Explain the specific circumstances that prevent you from creating a new listing and migrating customers]

Thank you.

3. Message support (サポートにメッセージを送信) を選択してリクエストを送信します。

新規リスティングの場合

2026 年 6 月 1 日以降に新規の SaaS リスティングを作成する場合、Concurrent Agreements はデフォルトで有効になります。次のアプローチに従い、統合をゼロから構築してください。

  • サブスクリプション通知には Amazon EventBridge を使用します。 (Amazon SNS ではありません)
  • 最初から LicenseArn と CustomerAWSAccountId を主要な識別子として使用します。
  • LicenseArn をプライマリキーとしてデータスキーマを設計します。
  • ローンチ前にテナントプロビジョニング戦略を選択します。

既存リスティングの統合ロードマップ

既存のリスティングをお持ちの場合、以下のハイレベルなステップを完了することで Concurrent Agreements にオプトインできます。

  1. Amazon SNS から Amazon EventBridge への移行
  2. LicenseArn をサポートするための API 統合の更新
  3. データベーススキーマの更新
  4. 登録エクスペリエンスの設計

以降のセクションでこれらのステップを解説します。

Amazon SNS から Amazon EventBridge への移行

AWS Marketplace SaaS 製品向けの Amazon SNS 通知は Amazon EventBridge 通知に置き換えられるため、サブスクリプション通知を Amazon SNS から Amazon EventBridge に移行する必要があります。SNS は LicenseArn パラメータを送信しないため、同時に存在するサブスクリプションを区別することが困難です。一方、EventBridge は LicenseArn を含み、改善されたイベント処理機能を備えています。詳細は Amazon SNS notifications for SaaS products を参照してください。

Amazon SNS から Amazon EventBridge に通知を移行する前に、次の前提条件を完了する必要があります。

  1. 米国東部 (バージニア北部) – us-east-1 リージョンで、関連するイベントタイプに対する EventBridge ルールを作成します。
  2. Amazon Simple Queue Service (Amazon SQS) キューや AWS Lambda などのターゲットをセットアップします。
  3. 新しいイベントパターンを処理できるようイベントハンドラーを更新します。

サブスクリプション通知を Amazon SNS から Amazon EventBridge に移行するには、AWS Marketplace Seller Guide の「Managing SaaS subscription events with Amazon EventBridge」の手順に従ってください。

EventBridge を設定する際、ルールは AWS Marketplace が SaaS 製品向けに送信する以下のイベントタイプを処理する必要があります。

  • Purchase agreement created (購入契約の作成) – 新しい契約が成立したときに、製造者または提案者に送信されるイベントです。
  • Purchase agreement ended (購入契約の終了) – 契約が満了したときに、製造者または提案者に送信されるイベントです。最終的な使用量送信のために 1 時間のウィンドウが提供されます。
  • License updated (ライセンスの更新) – エンタイトルメントが変更されたときに、製造者に送信されるイベントです。
  • License deprovisioned (ライセンスのデプロビジョニング) – エンタイトルメントが完全に取り消されたときに、製造者に送信されるイベントです。

LicenseArn をサポートするための API 統合の更新

3 つのコア API、ResolveCustomerGetEntitlementsBatchMeterUsage が LicenseArn をサポートするようになりました。

1. ResolveCustomer API は、購入者の AWS アカウント ID と製品コードに加えて、LicenseArn を返すようになりました。以降の API リクエストで使用するために LicenseArn を取得・保存できるよう、統合を更新する必要があります。

レスポンスには以下のフィールドが含まれます。

{
 "CustomerIdentifier": "string",
 "ProductCode": "string",
 "CustomerAWSAccountId": "string",
 "LicenseArn": "string"
}

2. GetEntitlements API は、フィルターオプションとして LICENSE_ARN を受け付けるようになり、すべてのレスポンスに LicenseArn が含まれるようになりました。LicenseArn フィルターを使用して特定の契約のエンタイトルメントを取得し、返された LicenseArn を使用してエンタイトルメントを内部のライセンスキーにマッピングする必要があります。
リクエストで LICENSE_ARN フィルターを使用します。

"LICENSE_ARN": ["string"]

API が返す各エンタイトルメントオブジェクトには以下が含まれます。

"LicenseArn": "string"

3. BatchMeterUsage API は、オプトイン済み製品の使用量レコードにおいて LicenseArn を必須とするようになりました。すべての使用量レコードに LicenseArn を含め、ライセンスごとに使用量を個別に追跡・報告する必要があります。

各 UsageRecord に LicenseArn を追加します。

"LicenseArn": "string"

注: オプトイン済み製品では LicenseArn が必須となり、ProductCode はサポートされません。

データベーススキーマの更新

LicenseArn をプライマリ識別子とするようにデータスキーマを再設計してください。このアプローチでは、複数のライセンスを保有する可能性のある顧客ではなく、特定の購入ライセンスに使用量を帰属させることで、プロビジョニングと課金が簡素化されます。スキーマを更新するには、CustomerIdentifier や ProductCode に基づく既存のプライマリキーを LicenseArn に置き換え、データベーステーブルとアプリケーションロジックを LicenseArn でレコードをクエリ・保存するように更新します。

登録エクスペリエンスの設計

アプリケーションで Concurrent Agreements をどのように扱うかを決定する際は、次の設計上の問いを検討する必要があります。

  • 顧客は手動でライセンスをアプリケーションのユーザーアカウントに関連付けるのか、それともライセンスは自動的に適用されるのか?
  • 顧客はアプリケーションの利用中にライセンスを切り替えられるようにするのか?
  • 使用量を報告する際、メータリングサービスはどのように正しい LicenseArn (レートカード) を選択するのか?

検討可能なテナントプロビジョニング戦略は 3 つあります。

  1. 個別テナント – ライセンスまたは購入ごとに個別のテナントを作成します。部門ごとの分離を必要とする組織に適しています。
  2. 統合テナント – 複数のライセンスを単一のテナントにマッピングします。課金を一元化している組織に適しています。
  3. 購入者の選択 – 購入者に最大限の柔軟性を提供するため、希望するアプローチを購入者自身に選択させることもできます。

使用量メータリングの移行

2026 年 6 月 1 日以降、新規 SaaS 製品では CustomerAWSAccountId (CustomerIdentifier の代わり) と LicenseArn (ProductCode の代わり) を使用する必要があります。

使用量メータリングの変更点

従量課金ベースの製品では、BatchMeterUsage リクエストに LicenseArn を含めることで、顧客が複数のアクティブなサブスクリプションを保有している場合でも使用量を正しく紐付けることができます。

使用量ベースの課金製品では、AWS Marketplace は契約終了後、最終的な使用量レコードを送信するためにおよそ 1 時間のウィンドウを提供します。

  • ウィンドウの開始 – 契約満了時に Purchase Agreement Ended イベントが送信されます。
  • ウィンドウの終了 – エンタイトルメントが完全に取り消されると License Deprovisioned イベントが送信されます。 (以降、使用量の報告は受け付けられません)

Purchase Agreement Ended イベントには LicenseArn が含まれません。BatchMeterUsage には LicenseArn が必要なため、サブスクリプションのライフサイクル全体を通じて LicenseArn とアクティブな契約 ID の正確なマッピングを維持してください。このマッピングは、両方の識別子を含む License Updated イベントから取得できます。

課金に関する重要な考慮事項

移行期間中は、LicenseArn ベースとレガシーの ProductCode ベースの BatchMeterUsage リクエストの両方が同時に機能します。1 時間あたり 1 回のレート制限はそれぞれの方式に独立して適用されるため、誤って 1 時間に 2 回使用量を報告してしまう可能性があります。本番環境で LicenseArn ベースの統合を有効化する際は十分に注意してください。

AWS SDK の必要な更新

Concurrent Agreements を完全にサポートするには、統合が LicenseArn をサポートする最新の AWS Marketplace SDK を使用していることを確認してください。

LicenseArn の SDK サポート

LicenseArn パラメータは、現在公開されている AWS SDK ですでにサポートされています。AWS Marketplace Metering および Entitlement サービス向けに、AWS SDK for JavaScript v3@aws-sdk/client-marketplace-metering および @aws-sdk/client-marketplace-entitlement-service)と AWS SDK for Python (Boto3) の最新バージョンを使用できます。

これらの SDK は、ResolveCustomerGetEntitlementsBatchMeterUsage API における LicenseArn サポートをすでに備えています。

SDK 更新の要件

LicenseArn パラメータを使用するために実行する手順は以下のとおりです。

  1. LicenseArn パラメータのサポートを利用するために、SDK を最新バージョンに更新します。
  2. API レスポンスに含まれる新しい LicenseArn フィールドを処理できるようにコードを更新します。
  3. 必要な箇所で LicenseArn を含むようにリクエスト構造を更新します。

既存顧客に対する LicenseArn のバックフィル

使用量やエンタイトルメントの呼び出しを LicenseArn でルーティングできるようにする前に、既存の顧客を対応する LicenseArn 値にマッピングしてください。既存のすべての契約の LicenseArn は、Agreements データフィードと、Agreements and Renewals ダッシュボードの License IDs で確認できます。ダッシュボードでは、データを CSV または Excel 形式でエクスポートして、プログラムから利用できます。

さらに、契約ベースの価格設定 (契約のみ、または従量課金付き契約) の場合は、GetEntitlements API で CUSTOMER_AWS_ACCOUNT_ID フィルターを使用して LicenseArn 値を直接取得できます。

まとめ

新規販売者にとって、これらの要件は最初から組み込まれています。既存の販売者にとっては、API と SDK の更新、データスキーマの再設計、カスタマーエクスペリエンスの更新を伴う移行が必要になります。この移行を完了することで、サービスの継続性を維持しながら、強化されたライセンス管理機能を活用できる体制が整います。

2026 年 6 月 1 日以降に作成されるすべての SaaS 製品では、Concurrent Agreements が有効になります。この日付より前に製品で Concurrent Agreements の有効化を計画している場合や、この変更について懸念がある場合は、Managing Concurrent Agreements enrollment ワークショップを参照してください。

リソース

本ブログの翻訳はPartner SA 前田が担当しました。原文はこちらです。

著者について

Tanvi Upadhyay

Tanvi は Amazon Web Services (AWS) のテクニカルアカウントマネージャーで、自動車・製造業界のエンタープライズのお客様と連携し、AWS 環境の最適化とビジネス目標の達成を支援しています。現在の役職に就く前は、Linux チームの AWS クラウドサポートエンジニアとして、お客様の複雑な技術的課題のトラブルシューティングと解決を支援していました。

Philipp Sacha

Philipp は Amazon Web Services (AWS) のパートナーソリューションアーキテクトです。この役割で、パートナーが AWS 上で製品を開発し、それらの製品を AWS Marketplace に展開することを支援しています。Philipp は IT インフラストラクチャのバックグラウンドを持ち、2015年に AWS に入社しました。AWS 入社以前は、主に IT インフラストラクチャ領域で、プロジェクトマネージャー、IP インフラストラクチャ責任者、リードアーキテクトといった複数の役割を務めていました。

前田 賢介(Maeda Kensuke)

前田 賢介(Maeda Kensuke)

シニアパートナーソリューションアーキテクト アマゾン ウェブ サービス ジャパン合同会社