AWS Marketplaceの料金ディメンションとは？ユーザー数、API回数、段階料金の設計

自社の料金表をAWS Marketplaceに登録しようとすると、最初に決めるのは、料金表の一行をAWSの側では何として登録するのか、という点ではないでしょうか。その答えが料金ディメンションです。購入者が課金される際の基本の計量単位で、公式ガイドは、ユーザー数、スキャンしたホスト数、取り込んだログのGB数を例に挙げています。（SaaS契約の料金）

ユーザー数とAPI回数は、どちらもディメンションとして登録します。ところが、数量を決める人も、SaaSが呼び出すAPIも違います。使うほど単価が下がる段階料金に至っては、確認できた公式ドキュメントでは、ディメンションの設定として説明されていません。

本記事の内容は、2026年10月5日に確認したAWSの公式ドキュメントにもとづきます。料金や要件は変わることがあるため、判断の前には各出典で最新の内容をご確認ください。

料金ディメンションは何を決めるのか

ディメンションごとに、API名、購入者向けの表示名と説明、一単位あたりの価格を決めます。表示名、説明、価格は購入者に表示され、API名は、AWS Marketplaceとのやり取りで「どのディメンションか」を指すために使います。具体的には、購入された内容を取得する権利確認のAPIと、使用量を送るメータリングのAPIの二つです。（SaaS契約の料金）

表の出典は、SaaS Contractの項目がSaaS契約の料金、SaaS Subscriptionの単価がSaaSサブスクリプションの料金、変更の可否がSaaS製品の設定です。文字数の上限は、これらのガイドに書かれた値です。ディメンションの数にも上限があり、一製品あたり最大200個と書かれています。（SaaSサブスクリプションの料金）帯ごとにディメンションを分ける設計では、この上限の範囲に収まるかも確認します。現行の上限は、登録画面で確認する必要があります。

ユーザー数とAPI回数で、ディメンションの働きはどう違うのか

料金表の上では、ユーザー数の課金もAPI回数の課金も同じ一行に見えます。AWS Marketplaceの側では、その数量を誰が決めるのかが違います。

契約で数量を買うディメンション

SaaS Contractでは、購入者が契約のときに、ディメンションごとの数量を選びます。契約が結ばれたあと、SaaSはメータリングの記録を送らず、権利確認のAPIで購入内容を確認します。（SaaS契約の料金）このAPI（GetEntitlements）の応答には、ディメンション名、値、失効日が含まれます。値には、整数、小数、真偽値、文字列の型があります。（GetEntitlements）

ただし、購入された数量を超える招待や利用を止める処理は、SaaSの側で実装します。GetEntitlementsが権利なしや数量不足を返したときにアクセスをどう扱うかは、ガイドでも販売者が決める事項とされています。（SaaS Contract with Consumptionの連携）

席数の変更には制約があります。契約の途中で購入者が行えるのは、数量や権利を増やすアップグレードで、期間を長くする変更は除かれます。契約の大きさを減らせるのは更新のときで、更新を取りやめることもできます。（SaaS契約の料金）そのため、席数が頻繁に増減する顧客に年単位の契約だけを用意すると、期間の途中で減らせないという事情が、購入のしにくさに繋がり得ます。

SaaS Contractの無料トライアルでは、ディメンションごとに数量の上限を設けられます。（SaaS無料トライアル）

使った分を送るディメンション

SaaS Subscriptionでは、数量を測るのは販売者のSaaSです。ガイドは、課金の対象をすべて一時間ごとに測定して報告するよう求めています。使用量は月単位で集計され、月単位で請求されます。AWS Marketplaceが顧客に請求できるかどうかは販売者からの記録が届くかどうかに依存し、記録が確実に届くようにする責任は販売者にある、とも書かれています。（SaaSサブスクリプションの料金）

SaaS Contract with Consumptionの場合

SaaS Contract with Consumption（従量制料金によるSaaS契約。契約の料金に加えて超過分を従量で請求する料金モデル）では、契約の各ディメンションについて、契約を超えた分を従量で支払う設定ができます。契約価格を設定せず、従量でだけ課金するディメンションを追加することもできます。（SaaS契約の料金）この場合、SaaSが呼び出すAPIは、権利確認のGetEntitlementsと、使用量を送るBatchMeterUsageの両方です。（SaaS製品のガイドライン）

SaaS ContractとSaaS Subscriptionをどう使い分けるかは、AWS MarketplaceのSaaS料金モデルで比べています。

単位と単価はどう決めるのか

最初に迷うのは単位です。単位のカテゴリは、帯域（GBps、MBps）、データ量（GB、MB、TB）、ホスト（時間）、リクエスト、ユーザー（時間）、汎用のUnitsから選びます。（SaaS契約の料金）このカテゴリは購入者向けのAWS Marketplaceの画面に表示されます。（SaaSサブスクリプションの料金）

使用量として送る数量は整数で、0から2,147,483,647までです。（UsageRecord）一単位を1回にするか1,000回にするかで、端数の扱いが変わります。1,000回を一単位にすると、1,000回に満たない端数をどの時間に計上するかを、販売者が決めることになります。単価の桁にも制約があり、契約価格は小数点以下3桁まで、SaaS Subscriptionの単価は8桁までです。（SaaS契約の料金、SaaSサブスクリプションの料金）1回あたり0.0005ドルのような単価を契約価格として設定したいなら、一単位を1,000回にするなど、単位の取り方で桁を合わせます。

ユーザー数を従量で課金すると、単位はユーザーの時間になります。公式ガイドの説明文の例にも、管理者あたりの時間があります。（SaaSサブスクリプションの料金）月額30ドルのユーザー課金を時間単価にするなら、30ドルを720時間で割った約0.0416667ドルです。ただし31日の月は744時間なので、同じ単価でも請求額は31ドルになります。月の長さで請求額が動くことを、料金表の説明にどう書くかまで決めておく必要があります。

SaaS Contractの価格は期間ごとに設定します。1か月、1年、2年、3年から選んだ期間は、すべてのディメンションで揃えなければなりません。12か月の価格は月額ではなく、12か月分の一括の価格です。たとえば、管理者ユーザーのディメンションに年額を設定したなら、閲覧ユーザーのディメンションにも年額が必要になります。（SaaS契約の料金）

通貨にも条件があります。Public Offer（パブリックオファー）は、USD建てでしか作成できません。（Private Offerの作成）日本円で料金表を設定している会社は、Public Offerでは、USDの単価に換算して登録することになります。一方、Private Offer（プライベートオファー）は、SaaS Contract、SaaS Contract with Consumption、SaaS Subscriptionのいずれでも、USD以外の通貨（EUR、GBP、AUD、JPY。INRはインドの販売者のみ）で作成できます。通貨ごとに、送金方法の設定が前提になります。（Private Offerの多通貨設定）Private Offerの通貨の扱いは、AWS Marketplaceで日本円のPrivate Offerは作れる？で整理しています。

作成後に変えられるものと、変えられないもの

表の出典は、API名と単位がSaaS製品の設定、料金モデルがSaaSの料金モデルです。

単価の変更は、変更リクエストで申請します。値上げをすると、その後少なくとも90日は、価格の更新を申請できません。値下げと値上げを同時に行うときは、値下げを先に更新します。（SaaS製品の設定）

ディメンションの追加は、製品に選んだ料金モデルの範囲でだけ行えます。SaaS Free（SaaS無料。すべての料金ディメンションを0ドルにする料金モデル）以外の料金モデルのlimited製品に追加したディメンションの価格は0.01ドルに設定され、公開の準備ができた時点で更新します。ディメンションの削除に当たる制限は、AWS Marketplace Seller Operationsチームへの問い合わせが必要で、常に可能とは限らないと書かれています。（SaaS製品の設定）

段階料金はAWS Marketplaceでどう表すのか

使うほど単価が下がる料金表は、そのまま登録できるのでしょうか。2026年10月5日時点で確認できた範囲では、できるという記載は見つかりません。

SaaS Contractのガイドが説明するのは、期間ごとにディメンションの単価を一つ設定する形です。SaaS Subscriptionのガイドでも、ディメンションの単価（レート）は一つです。（SaaS契約の料金、SaaSサブスクリプションの料金）一つのディメンションに数量の帯ごとの単価を設定し、AWSが帯をまたぐ計算を自動で行う、という説明は、確認したドキュメントにありませんでした。したがって、任意の段階料金をAWSが計算してくれるとは考えず、販売者の側で表し方を決める前提で設計します。

SaaS Contractには「階層」という選択肢がありますが、これは単価の帯ではありません。機能、サービス、利用量の組み合わせが異なる複数の階層から、購入者が一つを選ぶ形です。（SaaS契約の料金）公式ガイドのログ監視製品の例には、監視するホスト数とコンテナ数を組み合わせたBasic、Standard、Proの三つを月額と年額で用意し、超過分のホストとコンテナを時間単位の従量で請求する表があります。この表は、階層の形に当たる例です。（SaaS契約の料金）

累進型と全量適用型で、請求額はどう変わるのか

段階料金には、少なくとも二つの計算方式があります。超過した分にだけ低い単価を適用する累進型と、到達した帯の単価を使用量の全量に適用する全量適用型です。次の計算は、説明のための仮の数値で、AWSの例ではありません。単価は、1回から10,000回までが0.010ドル、10,001回から100,000回までが0.008ドル、100,001回以上が0.005ドルとします。

全量適用型では、10,001回の請求額が10,000回よりも下がり、100,001回では100,000回より約300ドル下がります。使うほど請求額が下がるこの逆転は、全量適用型の料金表そのものの性質です。累進型のつもりで設計して全量適用型の計算を適用すると、意図しない逆転が請求に出ます。帯1を「10,000回以下」と定義すれば10,000回は帯1に入って100.00ドルですが、「10,000回未満」と定義すれば帯2に入り、全量適用型では80.00ドルになります。境界の値をどちらの帯に入れるかも含め、方式は登録の前に料金表の側で決めておきます。

階層として売る

公式ドキュメントで確認できる仕組みのうち、段階に近い形で料金を分けられるのは階層です。AWSは階層を、機能、サービス、利用量を組み合わせたパッケージとして説明しており、使用量に応じた単価の帯として案内しているわけではありません。段階が「機能や利用量のまとまり」であれば、各まとまりを階層にし、含まれる数量を超えた分を従量で請求します。たとえば、API呼び出しを月10,000回含むプランと100,000回含むプランを階層として用意し、超過分は従量にします。ただし、これは累進型の割引を再現するものではありません。階層に含まれる範囲の使用量は計上せず、超える分だけを従量の記録として送ります。使用量がない時間も、0の記録を毎時間送ることが推奨されています。（SaaS Contract with Consumptionの連携）

帯ごとにディメンションを分ける

帯ごとにディメンションを作り、SaaSが使用量を帯に振り分けて送る設計も考えられます。たとえば、1回から10,000回までを帯1、10,001回から100,000回までを帯2のディメンションにします。API呼び出しの累計をSaaSが保持し、累計が9,800回の時点で500回の使用があれば、その時間の記録は、帯1に200回、帯2に300回として二つに分けて送ります。

この方法を、段階料金の手段としてAWSが案内している記載は、確認できていません。ディメンションは実際のソフトウェアに関するものでなければならず、請求は掲載したディメンションだけで行う、という条件があります。（SaaS製品のガイドライン）この設計が認められるかを、登録前にAWS Marketplace Seller Operationsチームへ確認することが前提です。

実装上の注意点もあります。購入者には、帯ごとのディメンションの表示名、説明、価格がそのまま表示されます。（SaaS契約の料金）帯の境界は累計で決まる一方、送信は一時間単位なので、SaaSが累計を保持し続ける必要があります。再送で同じ使用量を二重に加算すると、本来より早く次の帯に入り、請求がずれます。

累計は、顧客全体ではなく、契約（LicenseArn）ごとに、月などの集計期間で区切って管理します。同じ顧客でも契約ごとに料金条件が異なり得るため、顧客全体で合算すると、別の契約に誤った帯の単価を適用するおそれがあるからです。複数の契約を合算するのは、合意した料金条件がそう定めているときに限ります。

集計期間の「月」を、暦月で区切るのか、契約の起算日から一か月ずつ区切るのか、また、どのタイムゾーン（UTCなど）の日付で区切るのかも、料金設計として明示します。USD以外の通貨で作るPrivate Offerでは、SaaS Contract with Consumptionの超過分とSaaS Subscriptionの従量料金が、USD建ての製品とは別の請求書（anniversary invoices）に載ります。（Private Offerの通貨ごとの請求（購入者ガイド））この請求書の区切り方は、確認した購入者ガイドに書かれておらず、暦月で区切られるとは限りません。累計の区切りがAWS側の請求の区切りと合っているかは、登録前に確認が必要です。

ここで示した振り分けは、超過した分にだけ次の帯の単価を適用する累進型の計算です。到達した帯の単価を全量に適用する方式は、集計期間の終わりに単価が確定してから送信済みの数量を送り直して上書きする、という形では実装できません。一度送った記録は、数量を変えて送り直しても最初の数量が請求され、訂正できないためです。（使用量メータリングの設定）送信期限と重複排除の制約の下で、全量適用型を一時間単位の送信で表す方法は、確認したドキュメントには見当たりません。

全量適用型の割引を示したいときの選択肢は、Private Offerでの個別価格です。ただし、Private Offerで合意できるのは顧客ごとの単価です。Private Offerにすれば、使用量が帯に達したときに単価が切り替わる、あるいは全量への割引が自動で計算される、という記載は、確認できた範囲では見当たりません。割引後の単価を、その顧客の見込みの使用量に合わせて合意することになるため、実際の使用量が見込みから外れても、単価は自動では変わりません。

Private Offerで個別に出す

公開価格は一つの単価に保ち、数量の大きい顧客には、個別の価格をPrivate Offerで提案する方法もあります。Private Offerは、交渉した条件での購入で、独自の価格プランやEnd User License Agreement（EULA）を含められます。（Private Offerの作成）Public Offerの表示を複雑にせずに済みますが、顧客ごとに商談とオファーの作成が必要になります。流れと条件は、AWS MarketplaceのPrivate Offerとは？で解説しています。

選び方の目安は、段階の意味にあります。段階が機能のまとまりなら階層です。使用量への割引で、対象が少数の大口顧客に限られ、顧客ごとに単価を合意できるなら、Private Offerです。多数の顧客に公開価格で累進型の使用量割引を示したいときだけ、ディメンションの分割を検討することになります。

数量の計算はどこまでが販売者の責任なのか

使った分の請求額を最終的に決めるのは、SaaSが送る数量です。一方、AWS Marketplaceが扱うのは、契約で購入された数量と失効日、そして受け取った使用量の記録にもとづく請求までです。

販売者が決めるのは、次の点です。

• 何を一単位と数えるか：成功した呼び出しだけを数えるのか、失敗や再試行を含めるのかを決め、料金表と一致させる必要があります
• 一時間分の集計：公式のサンプルコードは、顧客ごとに一時間分の使用量を集計し、その合計を数量にする前提のため、顧客ごと（Concurrent Agreementsに対応する製品では契約〔LicenseArn〕ごと）に一時間単位で集計しておきます（コード例）
• ディメンション名：定義したディメンションと一致しない名前を送るとエラーになるため、定義どおりの名前で送る必要があります（BatchMeterUsage）

送信の期限、再送、複数契約の識別子の扱いは、AWS Marketplaceのメータリング実装とAWS MarketplaceのConcurrent Agreementsとは？で扱っています。送った数量とAWS側の記録の違いはAWS Marketplaceの売上と利用量のレポートで扱っています。SaaSとAWS Marketplaceの連携機能の全体像は、AWS MarketplaceのSaaS連携に必要な実装から確認できます。

料金表をディメンションに写す例

管理者ユーザーと閲覧ユーザーの利用枠を契約で売り、契約に含まれるAPI呼び出しを超えた分を従量で請求するSaaSを想定します。架空の料金表です。

API名の例は、SaaS Contractの上限の15文字に収まります。

公開の前に、次の条件を確認します。（SaaS製品のガイドライン）

• 少なくとも一つのディメンションの価格を0ドルより大きくする必要があります（すべてが0ドルだと、製品は自動的にSaaS Freeに変わります）
• 公開製品では、購入者がどのディメンションも購読できる必要があります。Private Offer限定のディメンションは作れません
• 請求は掲載したディメンションだけで行う必要があり、購入者のクレジットカードや銀行口座の情報は集められません

ここで決めたディメンションと数量は、個別見積もりを自動で発行する場合の条件にも使えます。数量や契約額を条件にした料金表の設計は、AWS MarketplaceのExpress Private Offersとは？で扱います。

Deshimaで対応できる範囲

料金ディメンションは、API名と単位が作成後に変えられないため、掲載の準備のなかでも早めに確定する項目です。掲載の準備を始める段階であれば、AWS Marketplaceへの掲載を支援するDeshimaで、掲載に必要なタスクの一覧と日本語の掲載ガイドを確認できます。

対応範囲は限られています。2026年10月5日時点では、DeshimaはSaaS Contract型のみに対応し、本記事のAPI回数のような従量課金（メータリング）と、Channel Partner Private Offer（CPPO）は対象外です。Concurrent Agreementsには対応済みです。SaaS Contract型の購入では、購入者情報と契約情報の同期が自動処理の対象です。ディメンションの設計そのものは、本記事のとおり販売者が決める内容です。Deshimaは更新が多いため、最新の機能と対応範囲は、無料のアカウントを作成したうえで、プロダクト内のドキュメントでご確認ください。

Deshimaの利用料は、初期費用と月額費用がどちらも0円で、費用が発生するのは製品が売れたときの販売手数料のみです。料率は個別にご提案しており、AWS Marketplace自体の手数料とは別になります。対応範囲はトップページのFAQで、Deshimaの料金は料金のセクションで確認できます。