AWS MarketplaceのSaaS審査で確認すること｜購入、契約同期、複数契約のテスト

限定公開の製品を自社のAWSアカウントで購入し、登録ページに遷移して、テナントが作られたとします。この時点で公開申請に進むのは、早計です。一度の購入で確かめられたのは、公式のテスト手順のうち、購入から登録までの前半にすぎません。（SaaS Contractの連携）

後半には、解約などの購読の変化への対応が残っています。SaaS ContractとSaaS Contract with Consumptionの製品では、権利が確認できない顧客の扱いも加わります。従量課金を含む製品では、使用量の送信も加わります。契約の増量や更新と、2026年6月1日以降の新規SaaSで設計に含める同じAWSアカウントの二つ目の契約は、テスト手順に項目がありません。手順に項目がない確認は、自社で決めて補うことになります。

本記事の内容は、2026年10月5日に確認したAWSの公式ドキュメントと発表にもとづきます。公式ガイドの各ページは更新の時期が揃っておらず、旧方式の記述が残る箇所があります。公式ガイドに根拠がなく、仕様から導いた確認項目には、そのつど「本記事の提案」と添えます。

AWSが確認すると書かれている範囲

審査は、二つの確認に分かれます。

• 掲載基準の審査：提出された製品とメタデータが、現行のガイドラインに照らして審査され、公開後も継続的に確認されます。（SaaS製品のガイドライン）
• 連携機能の動作確認：自社でのテストを終えてAWS Marketplace Operationsチームに知らせると、チームが動作を確かめます。（SaaS Contractの連携）

動作確認の中身は、料金モデルで変わります。SaaS Contract（SaaS契約。契約期間と購入する権利をあらかじめ定め、前払いまたは支払スケジュールで請求する料金モデル）では、GetEntitlementsの呼び出しの成功と、新しい顧客の受け入れが確かめられます。（SaaS Contractの連携）SaaS Contract with Consumption（従量制料金によるSaaS契約。契約の料金に加えて超過分を従量で請求する料金モデル）では、これにBatchMeterUsageによる使用量の送信が加わります。（SaaS Contract with Consumptionの連携）SaaS Subscription（SaaSサブスクリプション。時間単位の使用量に応じて請求する従量課金の料金モデル）では、BatchMeterUsageによる使用量の送信が確かめられます。（SaaS Subscriptionの連携）

掲載基準は、これらのAPIを、販売者として登録し公開申請を行ったAWSアカウントから呼び出せることも求めています。（SaaS製品のガイドライン）

公式のテスト手順には、販売者が自分で確かめる項目として、購読の変化への対応が入っています。SaaS ContractとSaaS Contract with Consumptionの手順には、権利が返らないときの扱いも入っています。（SaaS Contractの連携、SaaS Contract with Consumptionの連携）購読の変化では、解約、購読の成功、購読の失敗の三つの場面で、アプリケーションが正しく動くかを確かめます。（SaaS Contractの連携、SaaS Contract with Consumptionの連携、SaaS Subscriptionの連携）解約は手順に入っていますが、契約の増量や更新、置き換えの個別の確認と、同じAWSアカウントの二つ目の契約は、手順に項目がありません。これらの確認は、公開後に顧客の契約が増えたり変わったりしたときのために、自社で補います。

テストは、許可リストに登録した自社のアカウントで、実際に購入して行います。限定公開の製品は、テストの費用を抑えるため、引き下げた価格のままにしておくことが求められ、公開を申請するときに実際の価格を伝えます。（SaaS製品の作成）許可するテスト用アカウントを増やしたいときは、AWS Marketplace Seller Operationsチームに連絡する案内です。（SaaS Subscriptionの連携）2026年10月5日時点のSaaS Contract、SaaS Contract with Consumption、SaaS Subscriptionの連携ページ、SaaS製品の作成ページ、掲載基準には、テスト用アカウントの数を要件として定める記載がありません。目安は、同時に保持したい契約の状態と未購入の状態を、いくつ並べて確かめるかです。購入してから解約するように状態を移せば、一つのアカウントで複数の状態を試すこともできます。

確認すべき七つの場面

七つの場面の多くは、料金モデルを問わず必要です。新規購入の場面のうち、GetEntitlementsによる権利の確認は、SaaS ContractとSaaS Contract with Consumptionの製品に限られます。「権利が確認できないとき」の場面はSaaS Contract型の製品と、SaaS Contract with Consumption型の製品、「使用量の送信」の場面は従量課金を含む製品に限られ、「追加契約」の場面は2026年6月1日以降の新規SaaSと、オプトインした既存の製品が対象です。

新規購入

顧客が購入すると、自社の登録URLへ、一時トークン（x-amzn-marketplace-token）を付けたHTTP POSTでリダイレクトされます。自社のSaaSは、トークンをResolveCustomerで顧客と契約の識別子に変換し、識別子を保存して、初回の利用体験を見せます。（SaaS Contractの連携、SaaS Contract with Consumptionの連携、SaaS Subscriptionの連携）SaaS ContractとSaaS Contract with Consumptionの製品では、識別子を保存する前に、GetEntitlementsで購入内容と数量を確かめます。（SaaS Contractの連携、SaaS Contract with Consumptionの連携）SaaS Subscriptionの製品はGetEntitlementsを使わず、購読の成功の通知（旧方式のAmazon SNSではsubscribe-success。新方式での読み替えは「使用量の送信」の節に書いています）を受けてから使用量を送り始めます。（SaaS Subscriptionの連携）ResolveCustomerはCustomerIdentifier、CustomerAWSAccountId、LicenseArn、ProductCodeを返しますが、新しく連携機能を実装する製品ではCustomerIdentifierが設定されないため、CustomerAWSAccountIdとLicenseArnで顧客を識別します。（SaaS Subscriptionの連携）

掲載基準が求める条件は、次のとおりです。（SaaS製品のガイドライン）

• 登録ページに、購入者のメールアドレスの入力欄がある。複数の言語を使う場合は、英語の表示も用意する
• 購入後に、顧客がSaaS内でアカウントを作り、Webコンソールにアクセスできる。すぐにアクセスできない場合は、いつアクセスできるかの案内を示す
• アカウントを作ったあとに、作成の確認と次の手順を知らせる通知が、顧客に届く
• 顧客が、SaaS内で契約や利用の状況を確認できる
• サポートの連絡先が、遷移先のページに示されている
• 請求は料金ディメンションだけで行い、クレジットカードや銀行口座の情報を集める画面がない

テストでは、これらを購入した直後の画面から順に確かめ、保存した識別子が、あとの呼び出しで使えることまで確認します。料金モデルごとに、購入後に確かめる呼び出しが異なります。

• SaaS Contract：GetEntitlementsが成功し、返った権利と数量を製品が正しく扱う
• SaaS Contract with Consumption：これに加えて、BatchMeterUsageで契約を超えた分の使用量を送れる
• SaaS Subscription：購読の成功の通知（旧方式のAmazon SNSではsubscribe-success）を受けたあとに、BatchMeterUsageで使用量を送れる。GetEntitlementsは使わない

あわせて、GetEntitlements（SaaS ContractとSaaS Contract with Consumption）とBatchMeterUsage（従量課金を含む製品）の呼び出し元が、販売者として登録したアカウントの認証情報になっていることを確かめます。別のアカウントの認証情報で呼び出していると、掲載基準の条件を満たしません。（SaaS製品のガイドライン）

登録ページの再読み込みなどで同じ処理が二重に実行されたとき、顧客が二重に作られないかも、確認しておくと確実です。これは本記事の提案です。なお、登録、権利確認、契約通知、課金の実装の全体は、SaaS連携に必要な実装で整理しています。

既存ユーザー

掲載基準は、SaaSにすでにアカウントを持つ顧客が、遷移先のページからログインできることを求めています。（SaaS製品のガイドライン）購入のテストは、SaaSにまだ何もないアカウントから始める形になりやすく、この経路は意識して用意しないと確かめられません。

既存ユーザーのテストでは、次を試します。

• 購入する前に、SaaS側にユーザーを作っておき、購入後の登録ページから、そのユーザーでログインできる
• ログインしたユーザーの組織に、購入した契約が結びつき、新しい組織が重複して作られない

組織に契約が結びつくかどうかの確認は、本記事の提案です。AWSアカウントと自社の組織の対応づけは、契約の識別子の保持の仕方で決まります。なお、その設計は、契約をSaaSテナントに紐付けるにはで扱っています。

権利が確認できないとき

SaaS Contract型の製品では、顧客がサービスを使うたびに、次の三つの状態のどれかになります。（SaaS Contractの連携）

• 顧客IDが自社にない。購入していないので、購入の方法を案内する
• 顧客IDがあり、GetEntitlementsが適切な権利を返す。リクエストに応える
• 顧客IDはあるが、GetEntitlementsが権利を返さない、または数量が足りない。アクセスと画面の扱いを、自社で決める

公式のテスト手順は、権利が返らないときに、権利のないユーザーのアクセスと画面を正しく扱えることを、確認項目に挙げています。（SaaS Contractの連携）顧客IDが自社にない状態は未購入のアカウントで、権利が適切に返る状態は購入したアカウントで試せます。権利が返らない状態は、後述の契約の終了の確認とまとめて行えます。数量が足りない状態は、数量で利用を制限する製品なら、購入した数量を超える利用で試せます。

SaaS Subscription型の製品は、GetEntitlementsを使いません。（SaaS Subscriptionの連携）この場面は、SaaS ContractとSaaS Contract with Consumptionの製品が対象です。

追加契約

同じAWSアカウントが同じSaaS製品に複数の契約を結べるConcurrent Agreementsは、2026年2月26日に発表されました。2026年6月1日以降、新規のSaaS製品では対応が必須とされています。（AWSの発表）移行ガイドによれば、6月1日以降に作られた新規のSaaS製品では自動的に有効になり、Amazon EventBridgeの利用と、LicenseArnおよびCustomerAWSAccountIdの採用が必要になります。LicenseArnは、個々のライセンス（契約）を一意に識別します。既存の製品が有効にするには、オプトインの申請が要ります。（移行ガイド）

公式のテスト手順にも移行ガイドにも、複数契約の確認項目は載っていません。契約が複数になると、契約ごとの識別子で記録、権利の確認、使用量の送信を区別することになります。GetEntitlementsは、LICENSE_ARNで絞り込んで呼び出せます。（移行ガイド）次の四つは、複数契約の仕様から導いた本記事の提案です。

• 同じAWSアカウントから二つ目の契約を結び、LicenseArnが二つ保存される。一つ目の契約の記録が、上書きされない
• GetEntitlementsを使う製品では、契約ごとの権利が区別して取得でき、画面でも契約ごとに示せる
• 一方の契約を変更または終了しても、もう一方の契約の権限が残る
• 従量課金を含む製品では、使用量が、どちらの契約のものかを指定して送れる

もう一方の契約の権限が残ることの確認には、注意が要ります。というのも、従来の実装は、契約の終了を、アカウント単位の権限の停止と同じものとして扱えたため、その前提が残っていると、二つ目の契約が終わったときに、一つ目の契約の権限まで停止してしまうことがあるからです。

二つ目の契約を結ばせる手順が、同じ製品をPublic Offer（パブリックオファー）で再び購入することなのか、Private Offer（プライベートオファー）を承諾することなのかは、2026年10月5日時点の連携ページ、移行ガイド、AWSの発表に書かれていません。テストの前に、AWS Marketplace Seller Operationsチームへ確認する事項です。なお、新仕様の全体はConcurrent Agreementsの解説で整理しています。

契約の変更

SaaS Contractでは、顧客は契約を、より高い価値のものへ引き上げられます。引き上げの対象は、数量や権利の増加で、期間の延長は含みません。既存の契約には按分のクレジットが付きます。顧客は契約を小さくできず、小さくするのは更新のときか、更新を取り消すときだけです。（SaaS契約の料金）SaaS Contractでは、顧客が自動更新に同意することもできます。（SaaS契約の料金）

これらの変化は、Amazon EventBridgeのイベントで届きます。（Amazon EventBridgeによるSaaSイベント管理）イベントを受けて自社の契約の記録を合わせる処理を、本記事では契約の同期と呼びます。

契約の更新と置き換えも、Purchase Agreement Createdで届きます。（Amazon EventBridgeによるSaaSイベント管理）そのため、新規購入と同じ処理で扱うと、更新や置き換えのたびに顧客や契約が重複して作られかねません。

購読の変化について公式のテスト手順が求めるのは、解約、購読の成功、購読の失敗への対応で、増量、更新、数量の減少を個別に確かめる項目はありません。（SaaS Contractの連携）次の三つは、イベントの定義と契約の仕様から導いた本記事の提案です。

• GetEntitlementsを使う製品では、契約の増量のあとで、License Updatedを受けて権利が更新され、増えた数量が使える
• 更新や置き換えのあとで、新しい契約が既存の顧客に結びつき、重複して登録されない
• 更新のときに数量が減った場合、減った状態が反映される

なお、SaaS Contract with Consumptionの連携ページには、Amazon Simple Notification Service（Amazon SNS）のトピックで通知を受ける旧方式の説明が残っています。（SaaS Contract with Consumptionの連携）2026年6月1日以降の新規製品では、移行ガイドがAmazon EventBridgeを必須の要素に挙げているため、確認はAmazon EventBridgeのイベントで行います。（移行ガイド）

契約の終了

契約が期限切れ、取消、終了になると、Purchase Agreement Endedが届き、自社のSaaSは顧客の権利の取り消しを始めます。従量課金を含む製品で、最後の使用量を報告する1時間の枠が始まるのは、権利の終了を知らせるLicense Deprovisionedの受信からです。このイベントの受信から1時間を過ぎると、BatchMeterUsageが使用量を拒否し、請求できなくなります。（Amazon EventBridgeによるSaaSイベント管理）旧方式のAmazon SNSでは、unsubscribe-pendingの通知を受けたら最後の使用量を送ると説明されています。（SaaS Subscriptionの連携）

解約が進んでいる間は、製品内で、その旨を顧客に知らせます。顧客が製品内で解約したいと示した場合は、AWS Marketplaceへ案内します。（SaaS契約の料金）顧客データは、End User License Agreement（EULA）で定めた期間内に、必要がなくなったとき、または顧客の求めに応じて削除します。（SaaS製品のガイドライン）

契約の終了の場面では、次の四つを確かめます。権限の停止と画面の切り替えの確認は、公式のテスト手順が挙げる解約の処理にあたります。（SaaS Contractの連携）顧客データの扱い、未送信の使用量の送信、拒否された使用量の扱いの確認は、イベントの定義と掲載基準から導いた本記事の提案です。

• 契約の終了で、権限が停止され、画面が適切に切り替わる
• 停止の範囲と、顧客データの保持と削除が、自社の保持方針とEULAに沿う
• 従量課金を含む製品では、License Deprovisionedの受信から1時間以内に、未送信の使用量を送れる
• 1時間を過ぎて送信が拒否されたとき、その使用量の扱いが決まっている

返金と取消の手続きは、解約と返金への対応で扱います。

使用量の送信

SaaS Contractの製品では、アプリケーションが使用量を送ることはなく、権利の確認だけを行います。SaaS Contract with Consumptionでは、契約を超えた分の使用量をAWS Marketplace Metering Serviceに送ります。（SaaS契約の料金）この場面は、SaaS SubscriptionとSaaS Contract with Consumptionの製品が対象です。

使用量は、BatchMeterUsageで送ります。公式のAPIリファレンスが定める、確認すべき条件は次のとおりです。（BatchMeterUsage）

• 1回のリクエストで送れる記録は25件まで、リクエストの大きさは1MB未満
• イベントから24時間以上たった記録は受け付けられない。請求月の末は、翌月1日の06:00 UTCまで、前の月の記録を受け付ける猶予がある
• 範囲外のタイムスタンプが一件でもあると、バッチ全体が処理されず、TimestampOutOfBoundsExceptionが返る。範囲外の記録を除いて、再び送る必要がある
• 処理されなかった記録はUnprocessedRecordsで返り、同じリクエストは冪等で、同じ記録または一部の記録で再送できる

新方式の製品では、ProductCodeをリクエストに含めず、各記録にLicenseArnを指定します。同じ顧客に、ProductCodeとLicenseArnの両方で、同じ1時間のうちに送ると、請求が二重になります。旧方式から移行するときは、LicenseArnで送り始める前に、ProductCodeでの送信をやめます。（BatchMeterUsage）

使用量は、1時間ごとに送ることが求められています。同じ1時間の送信は重複が除かれ、毎時の記録は累積であると、公式ガイドは書いています。（SaaS Contract with Consumptionの連携、SaaS Subscriptionの連携）「累積」の一語は、同じ1時間への複数の送信を加算するとも読めます。しかし、公式ガイドは、重複の除去を製品（Concurrent Agreements対応製品ではライセンス）、顧客、時間、ディメンションの単位で行うとしています。同じ顧客、ディメンション、時間への複数の送信は加算されず、数量を変えて送り直しても最初の数量が請求されます。（SaaSの使用量の計測）前の1時間分の使用量を報告することが、ベストプラクティスとされています。（SaaSの使用量の計測）使用量がない時間も0で送ることが、強く推奨されています。（SaaS Contract with Consumptionの連携、SaaS Subscriptionの連携）SaaS Subscriptionの連携ページは、購読成功の通知を受ける前に送った使用量は計測されないため、通知を待ってからリソースを起動するよう強く勧めています。（SaaS Subscriptionの連携）このページはAmazon SNSの通知で説明していますが、新方式について、SaaS顧客の登録処理のページは、Amazon EventBridgeのLicense Updatedのイベントを受けてから計測の準備が整い、それより前に送った記録は計測されないとしています。（SaaS顧客の登録処理）

BatchMeterUsageのResultsには、AWSが受理した記録と、無効と判定された記録の両方が含まれます。（BatchMeterUsage）記録ごとのStatusは、Success、CustomerNotSubscribed、DuplicateRecordのいずれかで、Success以外の記録は受理されていません。（UsageRecordResult）Resultsに含まれて返ることは、受理を意味しません。

リファレンスは無効な記録を修正して再送するよう定めていますが、数量を直して再送すれば訂正できるとは限りません。再送の扱いは、返ってきた結果ごとに分けます。

• UnprocessedRecordsと一時的なエラー：AWS側のエラーで処理されなかった記録は、同じ内容で再送します。InternalServiceErrorExceptionも、リクエストを再試行するよう案内されています。（BatchMeterUsage）
• DuplicateRecord：同じ顧客、ディメンション、時刻で数量だけが異なる記録が、先に受理されている状態です。Concurrent Agreementsに対応する製品では、契約（LicenseArn）ごとに判定されます。数量を直して再送しても、先に受理された数量が残り、請求は訂正されません。再送を止め、最初に受理された数量を自社の台帳と照合します。（UsageRecordResult、SaaSの使用量の計測）
• CustomerNotSubscribed：原因は、顧客の識別子が無効、有効な契約や購読がない、AWSアカウントが停止された、のいずれかです。契約の状態を確認します。（UsageRecordResult）

公式ガイドは、0を含め、一度報告した使用量の記録は修正できないとしています。（SaaSの使用量の計測）誤って受理された数量の請求を、返金など別の手段で調整できるかは、AWS Marketplace Seller Operationsチームへの確認が必要です。

公式のテスト手順が求めるのは、BatchMeterUsageで使用量の記録を送ることと、SaaS Subscriptionの製品では、購読成功の通知を受けてから計測を始めることです。（SaaS Contract with Consumptionの連携、SaaS Subscriptionの連携）これに加えて、APIリファレンスの条件から導いた次の項目を、本記事は提案します。

• 購入して購読が成立したあとの使用量について、Resultsの各記録のStatusがSuccessになっている
• UnprocessedRecordsが返ったとき、同じ記録を再送しても、二重に計上されない
• DuplicateRecordが返ったとき、数量を変えた再送をせず、最初に受理された数量を台帳と照合する処理が実行される
• CustomerNotSubscribedが返ったとき、契約の状態を確認する処理が実行される
• 同じ契約（LicenseArn）、顧客、ディメンション、時間枠に、数量を変えて二度送っていない
• 範囲外のタイムスタンプを含むバッチが拒否されたとき、除いて送り直す処理が実行される
• 旧方式のProductCodeで、同時に送っていない

SaaS Contract with Consumptionの製品でも、License Updatedのイベントを受ける前の使用量を送っていないかを確かめておくと確実で、これは本記事の提案です。前述のSaaS顧客の登録処理のページは、SaaS SubscriptionとSaaS Contractの両方を対象にしています。（SaaS顧客の登録処理）

実装の詳細は、メータリングの実装で扱います。

日程の見積もり

日程を見積もろうとすると、公式ガイドに二つの日数が見つかります。

製品提出のページは、リクエスト全体の時間が、通常は2〜4週かかり、複雑な製品は、複数回のやり取りや調整で長引くと書いています。予定しているイベントやリリースがある場合は、完了した製品リクエストを、少なくとも45日前までに求めています。Amazon Machine Image（AMI）製品では、AMIも含みます。（製品の提出）SaaS製品の作成のページは、AWS Marketplace Seller Operationsが手作業で確認し、公開への更新に7〜10営業日かかり、誤りが見つかればさらに長引くと書いています。（SaaS製品の作成）2〜4週は製品の提出全体、7〜10営業日は公開への切り替えという、指す工程の違う日数です。ただし、7〜10営業日が2〜4週の内数なのか別枠なのかは、どちらのページからも読み取れません。製品提出のページは、日数を目安（guidance）として示しています。Deshimaを提供する私たち株式会社アンチパターンが、自社のSaaSを掲載した経験でも、審査にかかる期間にはばらつきがありました。公式の目安を上限とみなさず、余裕を持ったスケジュールを組むことを推奨します。

通算の日数をガイドから一つに決められないのであれば、日程を、性質の違う三つの時間に分けて見積もります。

製品の依頼の状態を確認すると、待ちの一部が、自社の側にあることがわかります。（製品の提出）

• Action Required：AWS Marketplaceのチームが審査し、追加の情報を必要としている。回答するのは自社
• Approval Required：AWSが限定公開のURLを作成した。自社が確認して、承認または却下するまで公開されない

Action RequiredかApproval Requiredの状態にある間は、時間が自社の返答の速さに左右されます。

修正待ちを短くする手立ての一つは、公開申請の前に、七つの場面を先に確かめておくことです。購入が一度成功しただけで申請し、AWS Marketplace Seller Operationsの確認で連携機能の不備が見つかると、コードの修正、自社テスト、再提出と、三つの工程をやり直します。なお、出品の全工程は、AWS MarketplaceにSaaSを出品する方法に整理しています。

テスト契約の後始末と、公開後

テストで作った契約は、公開に切り替える前に取り消します。取消の手段は、ページによって書き方が異なります。SaaS製品の作成のページは、SaaS Subscriptionの契約を、購入者の手順で解約し、SaaS Contractの契約は、AWS Marketplace Seller Operationsチームに問い合わせて取り消すと案内しています。（SaaS製品の作成）SaaS Contractの連携のページは、テスト用の契約を、返金申請フォームで取り消せると書いています。（SaaS Contractの連携）

2026年3月31日には、販売者がseller portal（セラーポータル）のAgreementsページやAgreement APIsから、返金と契約の取消を申請できる機能が発表されました。取消では、承認のリンクが購入者に共有され、購入者が7日間応答しなければ自動で取り消されます。（AWSの発表）限定公開の製品のテスト契約にも使えるかは、2026年10月5日に確認したこの発表と、SaaS製品の作成、SaaS Contractの連携の各ページに記載がありません。実施の前に、AWS Marketplace Seller Operationsチームか最新のガイドで確かめてください。

公開したあとも、自社のSaaSは、新しい顧客に対して、審査で確認されたときと同じ応答を、連携機能で返し続ける必要があります。（SaaS Contractの連携）七つの場面の確認は、公開の前に一度実施して終わりにせず、連携機能のコードを変えるたびの回帰テストの項目に残しておくのが確実です。

連携機能の実装を支援に任せる場合

連携機能を自社だけで実装しない選択肢もあります。Deshimaは、AWS Marketplaceへの掲載を支援するSaaSです。Deshimaにセラーアカウントを連携すると、AWS IAMロールとAmazon EventBridgeのルールが自動で作られ、購入後の利用申請フォームも提供されます。始め方の手順に、フォームを設定して、購入後の登録フローを検証する段階を設けています。Deshimaが担う範囲は、購入者と契約の情報の取得と同期、利用申請フォーム、Amazon EventBridgeへのイベント発行です。自社のSaaSでは、そのイベントを既存のユーザーやテナントに結び付け、契約に応じた機能、数量、利用可否を反映する処理を実装します。具体的な分担は、導入する構成に応じてご確認ください。審査の結果と日程は、Deshimaを使う場合でも、AWSの確認に左右されます。

2026年10月5日時点では、対応しているのはSaaS Contract型のみです。従量課金（メータリング）とChannel Partner Private Offer（CPPO）は対象外のため、本記事の使用量の送信の確認は、Deshimaの対象に含まれません。Concurrent Agreementsには対応済みです。Deshimaの利用料は、初期費用と月額費用が0円で、費用が発生するのは製品が売れたときの販売手数料のみです。料率は個別にご提案しています。AWS Marketplaceの販売手数料、自社側の実装と運用の工数、必要なAWSリソースの費用は、別にかかります。対応範囲はトップページのFAQに、料金の考え方は料金のセクションに記載しています。

SaaS Contract型の製品で公開申請の前にテストを控えているなら、無料のアカウントで、掲載タスク一覧と連携手順を確認してください。Deshimaは更新が多いため、最新の機能と対応範囲は、プロダクト内のドキュメントでご確認ください。