AWS MarketplaceにSaaSを出品する方法｜登録、連携、審査、公開の全工程

AWS MarketplaceへのSaaSの出品は、商品ページを作って申請すれば終わる作業ではありません。購入した顧客が自社のSaaSにたどり着き、契約したとおりに使えるところまで作り込んで、はじめて審査に進めます。

工程は七つに分かれ、前の工程が終わらないと次に進めない箇所が二つあります。

本記事は、日本の企業が新規にSaaSを出品する場合を対象に、2026年10月5日に確認したAWSの公式ドキュメントと発表にもとづいて工程を整理します。料金や要件は更新されるため、判断の前には各出典で最新の内容を確認してください。

七つの工程と、待ち合わせが生じる箇所

出品の工程を順に並べると、次のようになります。

1. 掲載できるかの確認
2. 販売者登録
3. 料金モデルと契約条件の設計
4. 製品の作成（限定公開）
5. 自社SaaS側の連携の実装
6. 限定公開でのテスト
7. 公開の申請と審査

工程は、一直線には進みません。一つめの待ち合わせは、有料の製品では、送金設定で米ドルを関連付けるまで製品を作成できない点です。送金設定のページは、米ドルを関連付けないと製品の掲載とオファーの作成ができなくなると明記しています。（送金設定）送金設定では登録済みの銀行口座を選び、銀行口座は税務情報を済ませてからでないと進められません。（送金設定、銀行口座情報の登録）そのため、有料の製品は、販売者登録の後半にあたる送金設定まで終えてから作ることになります。無料の製品だけなら、この待ち合わせは生じません。

二つめは、連携機能の最後の動作確認が、製品の作成後でなければ進まない点です。製品コードとAmazon EventBridgeの設定は、限定公開の製品ができたあとに、製品の概要ページで受け取る仕組みだからです。（SaaS製品の作成）実装そのものは設計が決まった時点から始められますが、実際の購入を通した確認は、この受け取りのあとになります。

掲載できるかを確認する

日本は、有料の製品を販売できる国と地域に含まれます。販売者は、対象の国と地域で設立された法人などであることが条件です。有料の製品には、税務情報と、米ドルを受け取れる対象地域の銀行口座が求められます。（販売者の資格要件）資格要件のページは口座の検証も挙げていますが、手順のページでは、Europe, the Middle East, and Africa（EMEA）のAWSの請求主体と韓国の請求主体から受け取る場合の手続きとして説明されています。（販売者の資格要件、口座の検証）無料の製品だけを提供する場合、公式の登録手順で必須とされるのは、公開プロフィールの作成までです。（登録と公開プロフィール）ただし、日本で登録された販売者に求められる割賦販売法に基づく確認は、買い手の所在地にかかわらず必要と案内されており、無料の製品だけの場合に免除されるとは書かれていません。（本人確認）無料の製品だけで始める場合の扱いは、登録の前にAWSへ確認してください。

自社SaaSの稼働場所も確認します。2025年5月1日適用のガイドラインでは、AWS上で完結しない構成のSaaSも、掲載できます。（SaaS製品のガイドライン）ただし、検索結果や商品ページで「Deployed on AWS」の表示を受けるには、アプリケーションとコントロールプレーンの両方がAWS上で動く必要があり、構成図の提出も求められます。（SaaS製品のガイドライン）掲載の可否と表示の条件は別の問題であり、詳しくは掲載条件の解説で扱っています。

販売者登録で揃えるべきもの

販売者登録は、公式ガイドの上で次の六つの手続きに分かれます。

六つの手続きの出典は、登録と公開プロフィール、税務情報の登録、銀行口座情報の登録、送金設定、本人確認、口座の検証です。

銀行口座の手続きは、税務情報を済ませてからでないと進められません。（銀行口座情報の登録）日本の販売者の場合は、本人確認も、AWS Billingコンソールの「Tax settings」を済ませてからでないと進められません。

割賦販売法に基づく確認は、買い手の所在地にかかわらず必要で、AWS Partner Centralの「Settings」から進めます。「Know Your Customer (KYC)」タブを開き、「Japan Know Your Customer (KYC)」の「Start verification」から自分で手続きします。事業者登録番号と住所は、AWS Billingコンソールの「Tax settings」から自動で入力されます。そのため、税登録が未完了のあいだは、確認のフォームが使えません。（本人確認）確認の対象は事業者情報と法定代表者の本人確認です。提出後の状態は、Not started（未着手）、Under review（審査中）、Verified（確認済み）、Action required（要対応）、Failed（失敗）の五つで示されます。通知はAWSアカウントのルートメールアドレスと登録したメールアドレスに届きます。（本人確認）

このほかに、買い手の地域に基づくKYCがあります。EMEAの請求主体を通じた取引と受け取り、韓国の請求主体からの受け取り、そして英国の銀行口座を使う場合に必要になる別の手続きで、該当する場合にだけ求められます。（販売者の資格要件、本人確認）

日本の消費税の扱いも、登録の段階で知っておく必要があります。日本の販売者が日本のAWSアカウントに販売する場合、2025年4月1日以降は、AWS Japanが10%の消費税を徴収して適格請求書を発行し、徴収した消費税を販売者に支払います。販売者は、法人番号と消費税の登録番号をAWS Marketplace Management Portalに入力し、納税します。（税務情報の登録）取引の形態によって扱いが分かれます。自社の取引への適用は、税理士など税務の担当者に確認してください。

登録の各手続きの詳細は、セラー登録、本人確認、売上受取設定の記事に分けています。

料金モデルと契約条件を、製品を作る前に決める

SaaSの料金モデルは四つあり、すべて無料トライアルに対応しています。（SaaSの料金モデル）

• SaaS Subscription（SaaSサブスクリプション。時間単位の使用量に応じて請求する従量課金の料金モデル）
• SaaS Contract（SaaS契約。契約期間と購入する権利をあらかじめ定め、前払いまたは支払スケジュールで請求する料金モデル）：契約を超えた分の請求もできる
• SaaS Contract with Consumption（従量制料金によるSaaS契約。契約の料金に加えて超過分を従量で請求する料金モデル）
• SaaS Free（SaaS無料。すべての料金ディメンションを0ドルにする料金モデル）

自社の課金方式がどのモデルに当たるかを、まず確かめてください。製品の作成より先に決める必要があるのは、料金モデルをあとから変えられないからです。製品を作成して限定公開にしたあとは、料金モデルを変更できません。（SaaSの料金モデル）料金ディメンションのAPI識別子と単位も、作成後は変更できません。（SaaS製品の設定）公式ガイドは、料金モデルの選び間違いが数週間の遅れに繋がり得ること、製品の設定の多くが作成後に変えられず、作り直しになる場合があることを注意しています。（SaaS製品の計画）

価格そのものは、変更を申請できます。ただし、いずれかの料金ディメンションを値上げすると、その後少なくとも90日は価格の更新を申請できません。（SaaS製品の設定）料金モデルを比較する観点は、SaaS料金モデルの記事にまとめています。

契約条件では、利用許諾契約であるEnd User License Agreement（EULA）を決めます。Standard Contract for AWS Marketplace（SCMP）か独自のEULAを選ぶことができ、独自のEULAでは、誰でも読めるAmazon Simple Storage Service（Amazon S3）のURLでの提供が求められます。（SaaS製品の設定）

製品を作成し、限定公開にする

製品は、AWS Partner CentralのBuildタブからSaaSを選んで作成します。（製品の提出）作成の前に、次の素材を集めておきます。（SaaS製品の作成）

• 製品ロゴ：一般に公開されたAmazon S3のURL
• EULA：PDFで、Amazon S3から読めるURL
• 登録URL：購入後に顧客を遷移させる自社のURL
• 製品のメタデータ：説明文など
• サポート情報：メールアドレスと、サポート窓口のURL

作成した製品は、限定公開（Limited）の状態で公開されます。連携機能の実装とテストのための状態で、許可リストに登録したAWSアカウントが製品を閲覧できます。（SaaS製品の設定）テストで高額な請求が起きないよう、製品は引き下げた価格のまま保たれ、実際の価格は公開を申請する時点で尋ねられます。（SaaS製品の作成）

製品の作成や変更の処理状況は、AWS Partner Centralの依頼一覧（Requestsタブ）で確認します。SaaS製品の変更依頼は、Under review、Preparing changes、Applying changesの順に処理され、Succeededで反映されるか、Failedで終わります。（SaaS製品の設定）Failedのときは、依頼を開いてエラーコードを確認し、内容を直して依頼を出し直します。（SaaS製品の設定）Buildタブの依頼全般については、AWSから追加の情報を求められると「Action Required」になり、下書きのまま六か月が過ぎた依頼は期限切れになります。（製品の提出）

商品ページの文章は、AWS Partner Assistantの掲載支援を使うと、WebサイトのURLや資料から下書きを作れます。下書きの内容を確認して貼り付け、公開するかどうかを決めるのは販売者で、自動では公開されません。掲載支援で作った製品も、手作業で作った製品と同じ審査を受けます。（AIによる製品掲載支援）入力する項目と準備の観点は、商品ページ作成のチェックリストで扱っています。

自社SaaS側に必要な連携機能

購入した顧客が最初に遷移する先は、自社SaaSの登録ページです。顧客が購入すると、登録URLへ、一時トークン付きのHTTP POSTでリダイレクトされます。（SaaS Contractの連携）

SaaS Contract型の場合、購入から初回の利用までは次の流れです。

購入者がAWS Marketplaceで契約する
 → 自社の登録URLへ、一時トークン（x-amzn-marketplace-token）付きでリダイレクトされる
 → ResolveCustomerで、トークンを顧客と契約の識別子に変換する
 → GetEntitlementsで、契約の内容（権利）を確認する
 → 識別子を保存し、初回の利用体験（アカウントの作成またはログイン）を提供する

ResolveCustomerは、CustomerIdentifier、CustomerAWSAccountId、LicenseArn、ProductCodeを返します。新しく実装する連携機能では、CustomerIdentifierは設定されず、CustomerAWSAccountIdとLicenseArnで顧客を識別します。（SaaS Subscriptionの連携）ResolveCustomerのあとに呼び出すGetEntitlementsやBatchMeterUsageといったAPIは、料金モデルによって変わります。（SaaS製品のガイドライン）

SaaS Subscriptionの製品は、GetEntitlementsを使いません。（SaaS Subscriptionの連携）

契約や購読の変更と終了は、Amazon EventBridgeのイベントで届きます。契約の権利が変わったときの「License Updated」では、SaaS ContractとSaaS Contract with Consumptionの製品が、GetEntitlementsを呼び出して最新の状態を確認します。契約が終わったときの「Purchase Agreement Ended」は、顧客の権利を取り消し始める合図です。（Amazon EventBridgeによるSaaSイベント管理）

SaaS側には、APIとイベントの扱いとは別に、掲載基準で次の条件が定められています。（SaaS製品のガイドライン）

• 請求は、AWS Marketplaceに設定した料金ディメンションだけで行う。クレジットカードや銀行口座の情報は、顧客から集められない
• 登録ページに、購入者のメールアドレスの入力欄を設ける
• 購入後に、顧客がSaaS内でアカウントを作れる。既存のアカウントを持つ顧客は、ログインできる
• 顧客が、SaaS内で契約や利用の状況を確認できる
• サポートの連絡先が、遷移先のページに示されている

新規に出品するSaaSには、もう一つの前提があります。2026年2月26日のAWSの発表によれば、同じAWSアカウントが同じ製品に複数の契約を結べるConcurrent Agreementsへの対応は、2026年6月1日から新規のSaaSで必須になりました。既存の製品は、Concurrent Agreementsに対応した連携機能の実装を終えていれば、任意でオプトインできます。（Concurrent Agreementsの発表）移行ガイド（2026年6月8日公開、9月11日更新）によれば、新規のリスティングでは自動的に有効になり、通知はAmazon Simple Notification Service（Amazon SNS）ではなくAmazon EventBridgeで受け、顧客の識別はLicenseArnとCustomerAWSAccountIdで行います。Concurrent Agreementsが有効な製品では、BatchMeterUsageでProductCodeがサポートされず、LicenseArnが必須になります。（Concurrent Agreements移行ガイド）そのため、1アカウントにつき1契約という前提では、連携機能を設計できません。実装の全体はSaaS連携に必要な実装に、新仕様の要点はConcurrent Agreementsの解説に分けています。

限定公開でテストする

テストは、許可リストに登録した自社のアカウントから、実際に契約して進めます。（SaaS Contractの連携）確認する項目のうち、次の四つは、SaaS Contract、SaaS Subscription、SaaS Contract with Consumptionに共通です。（SaaS Contractの連携、SaaS Subscriptionの連携、SaaS Contract with Consumptionの連携）

1. 契約または購読したアカウントが、登録URLにトークン付きのPOSTでリダイレクトされる。
2. 顧客の識別子を保存する。
3. そのアカウントを、自社のアプリケーションに登録できる。
4. 契約や購読の成立、失敗、解約といった変更を、正しく処理する。

確認を終えたらAWS Marketplace Seller Operationsチームに知らせ、チームが最後に確かめます。共通の四つに加えて確認する内容と、チームが確かめる内容は、料金モデルごとに異なります。（SaaS Contractの連携、SaaS Subscriptionの連携、SaaS Contract with Consumptionの連携）

新方式では同じアカウントが複数の契約を結べるため、同じAWSアカウントから二つめの契約を結び、契約ごとに権利が区別されるかも確かめておくことをおすすめします。これは公式ガイドの項目ではなく、複数契約の仕様から導いた本記事の提案です。

テストで結んだ契約は、公開に切り替える前に取り消します。公式ガイドは、SaaS Subscription型の契約は購入者の手順で解約し、SaaS Contract型の契約はAWS Marketplace Seller Operationsチームへの連絡で取り消すと案内しています。（SaaS製品の作成）SaaS Contractの連携のページでは、返金申請フォームによる取り消しも案内されています。（SaaS Contractの連携）取り消しを実施する際は、最新の手順を確認してください。取り消しと返金の扱いは、解約と返金の対応にまとめています。確認項目の全体は、SaaS審査で確認することにまとめています。

公開を申請し、審査を受ける

テストが済んだら、製品の変更依頼で「Update visibility」を選び、公開を申請します。申請の際に実際の価格を入力し、その価格はAWS Marketplace Seller Operationsチームが公開を承認したあとに適用されます。（SaaS製品の設定）

提出された製品とメタデータは、提出の時点で現行のガイドラインに照らして審査されます。公開後も、ガイドラインへの適合は継続的に確認されます。適合しなくなった場合は、更新を求められ、解消するまで新規の購読者に提供できなくなることがあります。（SaaS製品のガイドライン）SaaS側に求められる連携機能の条件に加えて、次のようなセキュリティの条件も審査の対象です。（SaaS製品のガイドライン）

• 顧客のデータを、転送時と保存時の両方で暗号化する
• 顧客ごとにデータと環境を分離し、データへのアクセスを許可する前に、顧客を認証する
• 顧客のデータを扱う場合、セキュリティに関する監査ログを少なくとも1年間保持する

審査の日数は、固定値では見積もれません。公式ガイドは、公開への切り替えを手作業の確認で行い、誤りが見つかれば長引くと説明しています。（SaaS製品の作成）依頼は複数回のやり取りを要することがあるとも書かれています。（製品の提出）公式ガイドにも所要期間の目安の記載はありますが、提出全体の所要期間と公開への切り替えのように、ページごとに数えている工程が違います。どの工程の目安かを確かめたうえで、審査の期間がやり取りの回数でも延びることを見込み、社内の計画では余裕を持たせ、申請の時点で最新の案内を確認してください。

公開したあとも、自社SaaSは、新しい顧客に対して、テストで確認したときと同じように連携機能で応答し続ける必要があります。（SaaS Contractの連携）

掲載したあとに前提条件となるもの

掲載そのものが、別の仕組みの前提条件になる場合があります。Partner Revenue Measurement（PRM）は、自社の製品が牽引したAWSサービスの消費を収益寄与として計測する仕組みで、公式ガイドは、AWS Marketplaceへの製品の掲載を前提条件の一つに挙げています。掲載の計画を立てる段階で、その先に何が必要になるかを知っておくと、アカウントの構成を決め直す手戻りを避けられます。詳しくはAWSのPartner Revenue Measurement（PRM）とは？をご確認ください。

着手の順序

日本の企業が先に確かめておきたいのは、AWS Billingコンソールの「Tax settings」です。本人確認のフォームが、ここに入力された事業者登録番号と住所を使うためです。登録と公開プロフィールを済ませたら、「Tax settings」を確認し、公式ガイドの順に、税務インタビュー、銀行口座、送金設定、本人確認へ進みます。

登録の手続きを待つあいだに、料金モデルと料金ディメンション、EULAの種類を決め、製品の作成の節に挙げた素材を集めます。連携機能の設計も、この時点で始められます。

自社で進めるか、支援を使うか

七工程のうち、登録と製品の作成は設定と書類の作業で、連携の実装は開発の作業です。連携の実装に、自社の開発の時間をどこまで充てられるかが、進め方を分けます。

Deshimaは、AWS Marketplaceへの掲載を支援するSaaSです。2026年10月5日時点では、掲載に必要な主要タスクの一覧と、各ステップの日本語の掲載ガイド、セラーアカウントを連携するとAWS IAMロールとAmazon EventBridgeのルールが自動で作られる機能、購入後の利用申請フォームを提供しています。Deshimaは、購入者と契約の情報の取得と同期、利用申請フォーム、Amazon EventBridgeへのイベント発行を担います。自社SaaSでは、そのイベントを既存のユーザーやテナントに結び付け、契約に応じた機能、数量、利用可否を反映する処理を実装します。具体的な分担は、導入する構成に応じてご確認ください。なお、AWSの販売者登録と、Deshimaのアカウント作成は、別の手続きです。

2026年10月5日時点の対応範囲は、Concurrent Agreementsに対応したSaaS Contract型のみで、従量課金（メータリング）とChannel Partner Private Offer（CPPO）は対象外です。従量課金を含む製品の連携機能は、別の方法で用意することになります。AWS Marketplaceにおける従量課金の仕組みとの連携については、AWSが2026年9月30日に、従量課金（メータリング）の連携を構築して検証するAWS Marketplace metering agent skill（メータリング用のエージェントスキル）の一般提供を発表しています。このスキルはAWS MCP Serverを通じて提供され、Amazon Q DeveloperやKiroなど、Model Context Protocol（MCP）に対応したアシスタントからプラグインを追加せずに利用できます。（AWSの発表）

Deshimaの利用料は、初期費用と月額費用が0円で、費用が発生するのは製品が売れたときの販売手数料のみです。料率は個別にご提案します。AWS Marketplaceの販売手数料、自社側の実装と運用の工数、必要なAWSリソースの費用は別にかかります。詳しくは、料金とよくある質問をご覧ください。

SaaS Contract型で出品する場合は、無料のアカウントを作成し、掲載タスク一覧と連携手順を確認してください。Deshimaは更新が多いため、最新の機能と対応範囲は、プロダクト内のドキュメントでご確認ください。自社で作る場合と支援を使う場合の作業の違いは、自社で進めるかDeshimaを使うかの比較で扱っています。