価格と契約
AWS MarketplaceのExpress Private Offersとは？条件付き見積もりを自動化する仕組み
公開日:
この記事の要点
Express Private Offersは、販売者があらかじめ登録した料金表（rate card）と適格基準にもとづき、AWS MarketplaceがPrivate Offer（プライベートオファー）を自動で生成する機能です。対象はSaaS ContractとSaaS Contract with Consumptionで、利用にはRequest Private Offerのボタン機能のオンボーディングが必要です。料金表は数量、Total Contract Value（TCV）、買い手の属性の三つの型で、割引とTCVの上限も設定します。基準外の案件は営業が対応します。
個別見積もりの依頼が、毎週のように営業に届いているとします。中身を見ると、ユーザー数と契約期間が違うだけで、割引の考え方はほとんど同じです。こうした標準的な案件まで、営業が一件ずつPrivate Offer（プライベートオファー）を作成する必要があるのでしょうか。
AWS Marketplaceは、この負担を減らす機能としてExpress Private Offersを用意しています。販売者が料金表（rate card）と適格基準をあらかじめ登録しておくと、条件に合う買い手には、Private Offerが自動で生成されます。条件に合わない案件は、営業が対応するフローに送られます。（Express private offers）
本記事では、この仕組みで何を自動にし、何を営業に残すかを決めるための、条件の設計を扱います。通常のPrivate Offerの発行手順は、AWS MarketplaceのPrivate Offerとは？に戻します。
本記事の内容は、2026年10月28日に確認したAWSの公式ドキュメントにもとづきます。仕様は変わることがあるため、判断の前には各出典で最新の内容を確認してください。
通常のPrivate Offer、Express Private Offers、自動更新の違い
名前の似た三つの仕組みは、誰が発行のきっかけを作るかと、価格が何で決まるかが異なります。2026年10月28日時点の公式ドキュメントから、違いを整理すると次のとおりです。
| 観点 | 通常のPrivate Offer | Express Private Offers | 自動更新 |
|---|---|---|---|
| 発行のきっかけを作る人 | 販売者。交渉のあとに、AWS Partner Centralでオファーを作成する | 買い手。製品ページの「Get Express Private Offer」ボタンから依頼する | AWS Marketplace。契約の終了日に、更新オファーを生成する |
| 価格の決まり方 | 販売者と買い手が交渉した個別の価格 | 販売者が事前に登録した料金表と適格基準 | 元のオファーに付けた更新条件（据え置き、固定率の値上げ、範囲を決めた値上げ） |
| 対象の料金モデル | AMI、コンテナ、専門サービス、機械学習、SaaSなどの製品種別 | SaaS ContractとSaaS Contract with Consumption | 契約料金（contract pricing）のオファー |
| 営業の関与 | 条件の交渉から発行まで、営業が担う | 基準を満たす案件では不要。基準外の案件だけ営業が対応する | 原則として不要。範囲を決めた値上げでは、更新ごとに率の確定が必要 |
| 買い手が受け取る場面 | 販売者が送るURLや、製品ページのバナーなど | 依頼の直後に、条件を満たせばオファーが生成される | 更新の終了日に、買い手の代わりに承諾される（買い手が止めない限り） |
表の出典は、通常のPrivate Offerの欄がPrivate Offerの概要、対応する製品種別、Private Offerの作成です。Express Private Offersの欄は、Express private offersと動作の流れ、自動更新の欄は、Private Offerの概要と自動生成されるPrivate Offerです。
つまり、通常のPrivate Offerは「交渉した結果を、販売者が発行する」仕組みです。Express Private Offersは「事前に決めた条件を、買い手が選んで、自動で発行される」仕組みです。自動更新は、すでにある契約の「次の期間」を、事前に決めた更新条件で続ける仕組みです。三つは目的が違うため、置き換え合うものではなく、案件の段階に応じて使い分けます。
なお、自動更新の更新条件の設計は、AWS MarketplaceのPrivate Offer自動更新で扱っています。AWS Partner Centralの「Auto-generated private offers」タブには、更新のオファーと、Express Private Offersのオファーが表示されます。Express Private Offersのオファーは、条件を満たした買い手が、販売者の公開した料金表から自分でオファーを作ったときに生成されると、公式ドキュメントは説明しています。（自動生成されるPrivate Offer）
対象となる料金モデルと、Request Private Offerの準備
対象は、SaaS ContractとSaaS Contract with Consumption
Express Private Offersの対象は、SaaS Contract（SaaS契約。契約期間と購入する権利をあらかじめ定め、前払いまたは支払スケジュールで請求する料金モデル）と、SaaS Contract with Consumption（従量制料金によるSaaS契約。契約の料金に加えて超過分を従量で請求する料金モデル）の製品です。（Express private offers）製品種別の一覧にも、Express Private OffersがSaaSの契約型の製品で使えると書かれています。（対応する製品種別）
SaaS Subscription（SaaSサブスクリプション。時間単位の使用量に応じて請求する従量課金の料金モデル）は、確認した公式ドキュメントでは、対象として挙がっていません。そのため、SaaS Subscriptionだけで出品している製品でも使える、と考えてしまうのは避けてください。自社の製品が対象になるかは、AWS Partner Centralの設定画面で確かめます。
SaaS Contract with Consumptionには、制約が一つあります。契約料金のうち、従量の部分は、料金表では割引できず、公開価格のままです。（Express Private Offerの設定）
利用するために、販売者が整えるべきこと
公式ドキュメントが挙げる前提は、次のとおりです。（Express Private Offerの設定）
- 有効なSaaS ContractまたはSaaS Contract with Consumptionの掲載があること
- Request Private Offerのボタン機能のオンボーディングを完了していること
- 料金設定に必要な権限があること
権限には、AWSMarketplaceFullAccessかAWSMarketplaceSellerFullAccessのマネージドポリシーを使えます。設定画面には、AWS Partner Centralの「Private offers」タブか「Products」タブから入ります。（Express Private Offerの設定）
二つ目の、Request Private Offerのオンボーディングについて補足します。Express Private Offersの文書は、オンボーディングが必要だと述べていますが、その内容は説明していません。Request Private Offerのボタン機能の前提は、Private Offerの作成のガイドが、次のように説明しています。（Private Offerの作成）
- APN Customer Engagements Program（ACE）に所属していること
- AWS Partner CentralとAWS Marketplaceのアカウントをリンクしていること
- 製品で、Private Offerの依頼を有効にしていること
ACEの登録後は、ステータスが2週間ごとに更新され、更新が済むまでボタンは表示されません。ボタン機能の準備には時間がかかり得るため、Express Private Offersの設計に入る前に、早めに確認しておくのが安全です。ボタンの設定と、届いた依頼の受け取り方は、AWS Marketplaceで見つけてもらうには？で整理しています。
料金表に使うカスタムディメンション
料金表の基準は、製品の料金ディメンション（購入者に請求する計量単位）です。公開価格のディメンションとは別に、Private Offer専用のカスタムディメンションを作ることもできます。公式ドキュメントによると、カスタムディメンションはPrivate Offerの作成画面からしか作れません。製品の掲載画面では、すべてのディメンションが公開価格と結び付くため、公開から見えてしまうからです。（カスタムディメンションの作成）
作り方は、ドラフトのPrivate Offerを作成して、その中でカスタムディメンションを定義し、保存して終了します。オファーを公開する必要はありません。処理には通常5分から15分かかり、「Request log」タブで「Succeeded」になれば使えるようになります。（カスタムディメンションの作成）
料金ディメンションそのものの設計は、AWS Marketplaceの料金ディメンションとは？に戻します。
依頼からオファーが生成されるまでの流れ
公式ドキュメントは、仕組みを三つの段階で説明しています。（動作の流れ）
- 料金表の設定：販売者が、基本の価格、ディメンションの説明、契約期間の上限、End User License Agreement（EULA）の要件、オファーの有効期限、割引の方式を登録します。ディメンションの説明は、買い手が選ぶ際の手がかりになるため、250文字以上が求められます。
- 買い手の依頼：買い手が、製品ページの「Get Express Private Offer」ボタンを押します。AIエージェントが、販売者の基準と買い手の要望を照合しながら、質問を進めます。エージェントは、販売者の設定した範囲の中で動きます。
- オファーの生成と振り分け：買い手が選んだディメンション、契約額、属性に関する回答を、販売者の基準と照らします。条件を満たせば、割引を反映したPrivate Offerがすぐに生成されます。条件を満たさなければ、営業が対応するフローに送られます。
生成されたオファーは、名前に「express private offer」と付き、通常のPrivate Offerと同じ通知と管理の流れに従います。（動作の流れ、Express Private Offerの受け取りと識別）
数量、契約額、買い手の属性を使う料金表の考え方
料金表には、三つの型があります。単独でも、決められた組み合わせでも使えます。（Express Private Offerの設定）
| 料金表の型 | 割引の根拠 | 設定する内容 |
|---|---|---|
| ディメンション型 | ディメンションごとの数量 | 数量の階層ごとに、最小の数量と割引率を決める |
| Total Contract Value（TCV）型 | 契約全体の金額 | 金額の階層ごとに、最小の金額と割引率を決める |
| 買い手の属性型 | 買い手が回答する属性 | 販売者が自然言語で条件を書き、AWSが質問票に変換する（最大5つの条件） |
ディメンション型は、数量の階層で割り引く
ディメンション型では、ディメンションごとに数量の階層を作り、階層に最小の数量と割引率を設定します。階層の外にある数量には、割引が付きません。AWSの例では、1,000単位で5%、10,000単位で15%の階層を設定すると、500単位の購入は割引なし、5,000単位の購入は5%の階層になります。（Express Private Offerの設定）
階層の外にある数量は、販売者が設定しなくても、割引0%として扱われます。最下位の階層より少ない数量と、最上位の階層を超える数量の両方が、これにあたります。ただし、最上位の階層を超える数量が割引0%になるのは、契約額が、全体の設定であるTCVの上限を下回っている場合です。（Express Private Offerの設定）TCVの上限を超えた契約は、割引0%のオファーにはならず、営業が対応するフローに送られます。そのため、最上位の階層より多い数量を、割引0%のまま自動で通すのか、営業に送るのかは、階層の設計ではなく、TCVの上限で決まります。
TCV型は、契約全体の金額で割り引く
TCV型では、契約全体の金額が大きいほど、割引率が上がる階層を作ります。複数の階層を満たす場合は、最も高い割引の階層だけが適用されます。最小の金額に届かない契約も、階層の最大の金額を超える契約も、割引なしです。（Express Private Offerの設定）
契約額が、全体の設定であるTCVの上限を超えた場合は、扱いが異なります。割引0%のオファーにはならず、営業が対応するフローに送られます。（Express Private Offerの設定）
買い手の属性型は、質問票で割引の対象を絞る
買い手の属性型は、最も柔軟な型です。販売者は、どのような買い手に割引を出したいかを、自然言語で書きます。システムは、その内容を、買い手向けの質問票に変換します。条件は最大5つまで設定でき、割引を与える条件にも、オファーの対象から外す条件にも使えます。公式ドキュメントは、業種に応じて追加の割引を出す例や、企業の規模でオファーの対象を絞る例を挙げています。（Express Private Offerの設定）
ただし、AWSは買い手が入力した回答を検証しません。（Express Private Offerの設定）買い手の属性は、割引の対象を絞る目安にはなりますが、事実の確認ではありません。このため、属性だけで大きな割引を決める設計は避け、次の節で説明する割引の上限と組み合わせて使います。
複雑なディメンションの条件を、買い手の属性型で表す場合は、自然言語の指示を非常に具体的に書く必要があると、公式ドキュメントは注意しています。また、保護される特性にもとづく差別は禁止されており、他のオファーの設定と矛盾してはなりません。（Express Private Offerの設定）
組み合わせと、割引の計算
組み合わせには、決まりがあります。（Express Private Offerの設定）
- ディメンション型とTCV型は、どちらか一方を、買い手の属性型と組み合わせられます
- ディメンション型とTCV型は、同時には使えません。割引の考え方が根本的に違い、矛盾が生じ得るためです
複数の割引が適用される場合は、足し算ではなく、掛け算で計算されます。AWSの例では、TCV型で10%、買い手の属性型で5%の割引に該当すると、0.9 × 0.95 = 0.855となり、割引は15%ではなく14.5%になります。（Express Private Offerの設定）
次の架空の例で、設計の確認をしてみます（金額、条件、割引率はすべて架空の例です）。
| 条件（架空） | 設定 |
|---|---|
| TCV型の階層 | 5万ドル以上で5%、10万ドル以上で10% |
| 買い手の属性型 | 創業から5年以内の企業は、追加で5% |
| 全体のTCVの上限 | 30万ドル |
| 全体の最大割引 | 15% |
この設定で、公開価格12万ドル分を契約する、創業3年の企業が依頼したとします。TCV型で10%、買い手の属性型で5%に該当するため、掛け算で割引は14.5%となり、12万ドルが10万2,600ドルになります。14.5%は最大割引の15%以内なので、そのまま生成されます。公開価格35万ドル分の契約を依頼した企業は、TCVの上限30万ドルを超えるため、営業が対応するフローに送られます。公開価格3万ドル分の契約なら、TCV型の最小の金額に届かず、買い手の属性型の割引だけが付きます。
割引の上限と、営業へ引き継ぐ条件を決める
全体の歯止めは、二つ
料金表の型に関わらず、すべての料金表に効く、全体の設定が二つあります。（Express Private Offerの設定）
- TCVの上限：自動でオファーを出す契約額の上限です。超えた案件は、営業が対応します
- 最大割引：どの料金表の組み合わせでも、合計の割引がこの値を超えないようにする上限です
最大割引を0%にすると、割引を出さない設定にもできます。自動化の目的が、割引の標準化なのか、営業の作業の削減なのかを、先に決めておくとよいでしょう。
この二つは、買い手の属性型の弱点を補う設定でもあります。買い手の回答が自己申告であっても、最大割引が決まっていれば、設計上の損失は一定の範囲に収まります。これは公式ドキュメントの記述ではなく、本記事の設計上の提案です。
営業に引き継ぐ条件
営業が対応するフローに送られるのは、公式ドキュメントが挙げる次の場合です。（動作の流れ）
- 契約額が、全体のTCVの上限を超える場合
- 買い手が、買い手の属性型で設定した条件を満たさない場合
この振り分けにより、複雑な案件や高額な案件には営業が対応し、標準的な案件だけが自動で処理されます。（動作の流れ）
一方で、公式ドキュメントに書かれていない点もあります。
- 営業が対応するフローに送られた案件が、AWS Partner Centralのどの画面に、どの形式で届くのか
- 契約期間の上限を超える期間を、買い手が希望した場合の扱い（期間にもとづく割引は、初期のリリースでは未対応と書かれています）
特に、営業に送られた案件の届き方は、体制づくりに直結します。Request Private Offerのボタンから届いた依頼は、AWS Partner Centralに招待として届くと、公式ガイドが説明しています。（Private Offerの作成）ただし、Express Private Offersで基準外になった案件が、同じ経路で届くとは、公式ドキュメントに記載がありません。設定画面と、AWSの担当者への確認で、届き方を確かめてから、営業の担当者を決めてください。
案件の分け方を決める手順
自動にする案件と、営業に回す案件を、次の順で決めます（運用上の提案です）。
- 自動にしてよい案件の上限を決める：過去の案件の契約額を並べ、通常は営業の判断が不要だった範囲を、TCVの上限にします
- 割引の最大値を決める：過去に出した割引のうち、承認なしに出せた範囲を、最大割引にします
- 割引の根拠を選ぶ：数量の違いで割り引くなら、ディメンション型です。契約額の大きさで割り引くなら、TCV型です。この二つは同時に使えません
- 買い手の属性を使うかを決める：業種や規模で割引や対象を分けたい場合に、買い手の属性型を加えます。自己申告であることを前提に、最大割引で受け止められる範囲に収めます
- ディメンションの説明を書く：買い手が選ぶ手がかりになるため、250文字以上で、単位と用途を具体的に書きます
- 想定する案件を一覧にして確かめる：数量、契約額、回答の組み合わせごとに、期待する割引と、自動か営業かの振り分けを書き出し、設定と照らします
通常のPrivate Offerに残すべき案件は、料金表で表せない条件が必要な案件です。たとえば、期間にもとづく割引や、独自の契約条件の交渉が必要な案件は、公式ドキュメントが挙げる範囲では、料金表で扱えません。こうした案件の発行手順は、AWS MarketplaceのPrivate Offerとは？に戻ります。
公開前に確認すること
読者が次に取る行動を、順にまとめます。
- 自社の製品が、SaaS ContractかSaaS Contract with Consumptionであることを確認する
- ACEへの所属と、AWS Partner CentralとAWS Marketplaceのアカウントのリンクが済んでいるかを確認する
- Request Private Offerのボタン機能のオンボーディングが完了しているかを確認する
- 料金表に使うディメンションを決め、必要ならカスタムディメンションを作る
- TCVの上限と最大割引を、過去の案件から決める
- 料金表の型（ディメンション型かTCV型か、買い手の属性型を加えるか）を選ぶ
- 営業に送られた案件を、誰が、どの画面で受け取るかを確認する
価格表そのものの見直しが必要な場合は、AWS MarketplaceのSaaS料金モデルの整理から始めてください。料金表で決めた契約額を、何回に分けて請求するかは別の設定です。その組み方は、AWS Marketplaceの分割払いとNet payment termsで扱います。
Deshimaで扱える範囲
Express Private Offersは、料金表と適格基準を設定し、買い手の依頼から自動でオファーを生成する、AWS Marketplaceの機能です。Deshimaの見積自動生成機能ではありません。Express Private OffersへのDeshimaの対応は、2026年10月28日時点で確認できていないため、対応の可否は個別にご相談ください。
自動見積もりの前提になるのは、SaaSの掲載と、購入後の連携の準備です。Express Private Offersの対象は、有効なSaaS ContractまたはSaaS Contract with Consumptionの掲載で、まず掲載が済んでいる必要があります。（Express Private Offerの設定）掲載の手順は、AWS MarketplaceにSaaSを出品する方法で、七つの工程に分けて整理しています。
購入後の連携では、Deshimaは、購入者と契約の情報の取得と同期、利用申請フォーム、Amazon EventBridgeへのイベント発行を担います。自社SaaSでは、そのイベントを既存のユーザーやテナントに結び付け、契約に応じた機能、数量、利用可否を反映する処理を実装します。具体的な分担は、導入する構成に応じてご確認ください。
2026年10月28日時点のDeshimaの対応範囲は、SaaS Contract型のみで、従量課金（メータリング）とChannel Partner Private Offer（CPPO）は対象外です。Concurrent Agreementsには対応済みです。Express Private Offersの対象にはSaaS Contract with Consumptionが含まれますが、Deshimaが対応する料金モデルはSaaS Contract型のみです。
Deshimaの利用料は、初期費用と月額費用がどちらも0円で、費用が発生するのは製品が売れたときの販売手数料のみです。料率は個別にご提案します。対応範囲はトップページのFAQに、料金の考え方は料金のセクションに記載しています。
Deshimaは更新が多いため、最新の機能と対応範囲は、無料のアカウントを作成したうえで、プロダクト内のドキュメントでご確認ください。