2026.09.18 aws

AWS Marketplaceとは？購入時のIAM権限とSaaS出品の計測API実装

AWS Marketplaceとは？購入時のIAM権限とSaaS出品の計測API実装

AWS Marketplaceで製品を購読するだけなら、画面の操作は数分で終わります。詰まるのはその前後です。誰に購読権限を渡すのか。管理アカウントで契約したライセンスをメンバーアカウントへどう配るのか。自社のSaaSを並べる側に回ったとき、従量課金をどのAPIでいつ送るのか。この記事では買う側のIAM設計とマルチアカウント運用、売る側のResolveCustomer・BatchMeterUsage・GetEntitlementsの実装を、AWS公式ドキュメントで確認した2026年9月時点の実値とPythonコードで整理しました。

まとめ｜買う側のIAM権限と売る側の計測API実装で押さえる勘所

AWS Marketplaceは、サードパーティのソフトウェア・データ・サービスをAWSアカウント経由で調達し、料金をAWSの請求書へまとめるカタログです。買い手と売り手のどちらでも使えます。

買う側で先に決めるのはIAMでした。購読の可否はAWSMarketplaceRead-only・AWSMarketplaceManageSubscriptions・AWSMarketplaceFullAccessの3つの管理ポリシーで切り分け、購読の全容を画面に出すにはlicense-manager:ListReceivedLicensesを足します。組織で買うなら、管理アカウントでプライベートオファーを受諾し、AMI製品とコンテナ製品はAWS License Managerでメンバーアカウントへ配る経路が使えました。

売る側の実装は3つのAPIに集約されます。ResolveCustomerで登録トークンを解決し、契約型ならGetEntitlements、従量課金ならBatchMeterUsageを呼ぶ。2026年6月1日以降に作る新規SaaS製品は、顧客の識別をCustomerIdentifierからCustomerAWSAccountIdとLicenseArnへ置き換える必要があり、移行の途中で両方を送ると二重課金になります。

AWS Marketplaceで買えるものと料金がAWS請求に乗る仕組み

カタログの中身と課金経路を押さえると、後のIAM設計と請求の突合が楽になります。

AMI・コンテナ・SaaS・データ製品で変わる配信方式と起動の流れ

製品の形はひとつではありません。AWS Marketplace購入者ガイドが挙げるのは、Amazon Machine Image（AMI）、CloudFormationテンプレートで配信されるもの、ISVが運用するSaaS、AWS WAF向けのWeb ACLやルールセットです。データ製品はAWS Data Exchange経由で購読します。

配信方式が違えば購読後に起きることも変わります。AMI製品は自分のアカウントでEC2インスタンスとして起動する。コンテナ製品はイメージを引いて自分のクラスタで動かすので、レジストリまわりの前提はAWS ECRのpush手順と料金と地続きです。SaaS製品は売り手の環境で動き、購読後に売り手の登録ページへ遷移してアカウントを紐づけます。この「遷移して紐づける」部分が、後半で扱うResolveCustomerの出番でした。

ソフトウェア料金とEC2などのインフラ料金が別建てになる課金の内訳

請求書の行は1本ではありません。AMI製品を時間課金で買うと、請求されるのはソフトウェアの時間料金と、それを載せているEC2インスタンス・EBSボリューム・データ転送の料金です。前者はMarketplaceの明細、後者は通常のAWS利用料として計上される。「Marketplaceで月100ドルの製品を買った」という説明だけで見積もりを作ると、インスタンス費用が抜け落ちます。

購入者ガイドが挙げる価格オプションは、無料トライアル・時間単位・月額・年額・複数年・BYOL（Bring Your Own License）の6種類で、これらがすべて1つの請求元からまとめて課金されます。BYOLは手持ちのライセンスを持ち込む形なので、Marketplace側のソフトウェア料金は発生せず、インフラ料金だけが乗る。既存のライセンス資産がある製品なら、まずBYOLの可否を売り手に確認したほうが総額は下がります。組織で一括請求していればMarketplaceの費用も管理アカウントへ集約されるため、費用の分解はAWS Organizationsの一括請求とSCP/RCPの設計と同じ枠組みで考えられました。

公開価格はUSD建て・値上げは90日通知という価格改定のルール

通貨の扱いには段差があります。AWS Marketplaceの料金ドキュメントによれば、公開リスティングの価格は米ドル建てです。日本円・ユーロ・英ポンド・豪ドル、そしてインドの売り手に限ってインドルピーが選べるのはプライベートオファーのときだけと明記されています。為替変動を避けて円建てで固定したいなら、公開価格での購読ではなく売り手との個別交渉が必要でした。

値上げのタイミングも決まっています。公開オファーの既存購読者に対して、値下げは即時に反映される。一方の値上げは通知から90日が経過した翌月の1日に発効し、公式ドキュメントは3月16日に通知した場合の新価格適用日を7月1日と例示しています。突然の値上げで当月の費用が跳ねることはない、という保証として読めました。

購入側で決めるIAM権限とOrganizations配下のライセンス共有設計

調達の統制は、誰が購読ボタンを押せるかを決めることから始まります。

AWSMarketplaceRead-onlyなど3つの管理ポリシーの使い分け

購入者向けのアクセス制御ドキュメントは、ロールに付ける管理ポリシーを3段階で提示しています。閲覧だけならAWSMarketplaceRead-only、購読と解約まで許すならAWSMarketplaceManageSubscriptions、完全な制御を渡すならAWSMarketplaceFullAccess。プライベートマーケットプレイス用にAWSPrivateMarketplaceRequestsとAWSPrivateMarketplaceAdminFullAccessも別にあります。

中身を見ると設計の意図が読めました。AWSMarketplaceManageSubscriptionsのポリシードキュメントは2026年9月時点でv9（2026年5月7日更新）。aws-marketplace:SubscribeとUnsubscribeのほか、AcceptAgreementPaymentRequestのような支払い要求の承諾まで含みます。購読の管理を渡すと支払い要求の受諾まで渡る、という理解で権限レビューに臨んでください。最小権限で組むなら、インラインポリシーで必要なアクションだけを切り出します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "MarketplaceSubscribeOnly",
      "Effect": "Allow",
      "Action": [
        "aws-marketplace:ViewSubscriptions",
        "aws-marketplace:Subscribe",
        "aws-marketplace:Unsubscribe"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ShowFullSubscriptionDetails",
      "Effect": "Allow",
      "Action": [
        "license-manager:ListReceivedLicenses"
      ],
      "Resource": "*"
    }
  ]
}

2つ目のステートメントを省くと画面の表示が欠けます。購入者ガイドは、購読の詳細をすべて見せるにはlicense-manager:ListReceivedLicensesの追加を指示している。「購読できるのに一覧に出ない」という問い合わせは、たいていここが原因でした。

管理アカウントで受けた契約をメンバーアカウントへ配る2つの経路

組織で買った1本の契約を実際に使うアカウントへ届ける道は2つあります。プライベートオファーのドキュメントによれば、管理アカウントで受諾したオファーは組織内の全メンバーアカウントと共有できる。もうひとつがAWS License Manager経由の共有で、対象はAMI製品とコンテナ製品です。

順序で結果が変わる点に注意してください。すでにその製品を購読していたメンバーアカウントは、新しいプライベートオファーを自分で受諾しない限り交渉後の価格が適用されません。購読していなかったアカウントは、製品をデプロイするために受諾が要る。「管理アカウントで安く買ったのに支社のアカウントだけ公開価格で課金され続けていた」という事故は、この漏れで起きます。年間サブスクリプションは一括請求の下で連結された全アカウントに共有されます。アカウント構成そのものはAWS Control Towerのランディングゾーンと導入判断の領域なので、調達ルールはOU設計と同じ場で決めておくと破綻しません。

プライベートオファーの宛先25アカウント上限と期限切れ後の扱い

プライベートオファーは、売り手が指定したAWSアカウントにだけ提示される非公開の価格とEULAです。宛先は1件のオファーにつき最大25アカウントまで。受諾した時点で、それは売り手と買い手の間の合意（agreement／contract／subscription）になります。期限が切れたオファーは受諾できず、復活させる方法もありません。売り手へ延長か再発行を依頼することになり、四半期末の駆け込みで期限を過ぎると交渉のやり直しです。更新や上位プランへの切り替えも同じ受諾フローで進みますが、新しい合意が成立した瞬間に前の合意の残りの支払いスケジュールは取り消され、新条件へ置き換わります。分割払いの残額の扱いは受諾前に文面で確認しておく項目でした。

SaaS製品を出品する側のResolveCustomerと計測APIの実装手順

ここからは売り手側です。自社SaaSを載せる場合、課金の正しさはAPIの呼び方で決まります。

登録トークンをresolve_customerで解決するサインアップ処理

購読した買い手は、AWS側から売り手の登録ページへPOSTでリダイレクトされます。本文にはx-amzn-marketplace-tokenが入っており、これをResolveCustomerへ渡すと、顧客のAWSアカウントIDとライセンスARN、製品コードが返る。公式のコード例はboto3で次の形でした。

import boto3
import urllib.parse as urlparse

formFields = urlparse.parse_qs(postBody)
regToken = formFields['x-amzn-marketplace-token'][0]

if (regToken):
    marketplaceClient = boto3.client('meteringmarketplace')
    customerData = marketplaceClient.resolve_customer(RegistrationToken=regToken)
    productCode = customerData['ProductCode']
    customerAWSAccountId = customerData['CustomerAWSAccountId']
    licenseARN = customerData['LicenseArn']
    # 取得した識別子は自社DBへ保存し、以降の計測呼び出しで使う

実装の落とし穴は呼び出し元と時間です。APIはSaaS製品を公開したアカウントから呼ばないとトークンを解決できません。トークンの寿命も短く、リダイレクトに時間がかかった場合、トークンが再送された場合、処理を遅らせた場合にExpiredTokenExceptionが返ります。POSTを受けたらその場で引き換える設計以外は事故のもとでした。返ってきたCustomerAWSAccountIdとLicenseArnは必ず保存してください。

batch_meter_usageの25件・1MB制限と1時間単位の集計設計

従量課金（flexible consumption pricing）の使用量はBatchMeterUsageで送ります。1回のリクエストで処理できるのは25件のUsageRecordsまで、サイズは1MB未満。1リクエストは1製品ぶんなので、複数製品なら呼び出しを分けます。

import boto3
from datetime import datetime, timezone

usageRecord = [{
    'LicenseArn': 'arn:aws:license-manager::123456789012:license:l-exampleLicense12345',
    'CustomerAWSAccountId': '111122223333',
    'Dimension': 'api_calls',
    'Quantity': 10000,
    'Timestamp': datetime.now(timezone.utc).replace(minute=0, second=0, microsecond=0)
}]

marketplaceClient = boto3.client('meteringmarketplace')
response = marketplaceClient.batch_meter_usage(UsageRecords=usageRecord)

for r in response['Results']:
    # Status は Success, CustomerNotSubscribed, DuplicateRecord のいずれか
    print(r['MeteringRecordId'], r['Status'])

# UnprocessedRecords はサービス側エラーなので、そのまま再送する
retry = response['UnprocessedRecords']

送信のタイミングにも期限があります。イベントから24時間以上が経過したレコードは受け付けられません。請求サイクルの切れ目には6時間の猶予があり、前月ぶんは翌月1日の06:00 UTCまで受け取ってもらえる。3月31日の使用量を4月1日の05:00 UTCに送るのは間に合い、06:00 UTCを過ぎると24時間以内でもTimestampOutOfBoundsExceptionで弾かれます。バッチのうち1件でも範囲外なら全体が処理されないため、送信前にタイムスタンプを検証してください。タグで按分するUsageAllocationsはタグ5個まで、按分した数量の合計がQuantityと一致しないとInvalidUsageAllocationsExceptionになります。

契約型製品でGetEntitlementsを使って権利を確認する実装

契約型（SaaS contract）と契約＋従量の製品では、顧客が今どの枠をどれだけ持つかをGetEntitlementsで取得します。フィルタのキーはCUSTOMER_AWS_ACCOUNT_ID・LICENSE_ARN・CUSTOMER_IDENTIFIER・DIMENSIONの4種類で、うち顧客識別の2つは同時指定できません。

import boto3

client = boto3.client('marketplace-entitlement', region_name='us-east-1')

res = client.get_entitlements(
    ProductCode='yourProductCode',
    Filter={'CUSTOMER_AWS_ACCOUNT_ID': ['111122223333']},
    MaxResults=25
)

for e in res['Entitlements']:
    # Dimension ごとの数量と失効日を突き合わせて機能を解放する
    print(e['Dimension'], e['Value'], e['ExpirationDate'])

MaxResultsの有効範囲は1〜25。返るEntitlementsが空でもNextTokenが付いてくることがあり、その場合は続けて取得します。「0件だったので購読なしと判定する」実装は、ページングの途中で権利を見落とす。ValueはBooleanValue・DoubleValue・IntegerValue・StringValueのいずれかで返るため、ディメンション設計の時点でどの型を使うか決めておいてください。

2026年6月のConcurrent Agreements対応で必要になるコード改修

既存の日本語解説と最も食い違う部分です。顧客の識別方法が変わりました。

ProductCodeとLicenseArnの同時送信で起きる二重課金の回避手順

AWS MarketplaceはConcurrent Agreements（1つのAWSアカウントが同じ製品で複数の契約を持てる仕組み）の提供を進めています。BatchMeterUsageのAPIリファレンスには、2026年6月1日以降の新規SaaS製品がこの機能に対応するためCustomerIdentifierの代わりにCustomerAWSAccountIdを、ProductCodeの代わりにLicenseArnを使う必要があると明記されている。既存の統合はそのまま動き続けます。

危ないのは切り替えの過渡期でした。公式ドキュメントは、同じ顧客に対して同じ1時間のうちにProductCodeとLicenseArnの両方で計測レコードを送ると二重に請求されると警告しています。したがって手順は一方通行です。まずLicenseArnベースの送信を実装して検証し、リクエストレベルのProductCodeの送信を止め、そのうえでLicenseArnの送信を開始する。安全のため両方を並走させる設計は、この領域では逆に事故を生みます。新規統合ではResolveCustomerの応答にCustomerIdentifierが入らないため、この値を主キーにしているSaaSはスキーマから手を入れる話になります。

既存の顧客識別子をAccount Feedsで新形式へ対応づける移行作業

すでにCustomerIdentifierで顧客を管理している場合、新旧の識別子をどう突き合わせるかが移行の山場になります。GetEntitlementsのドキュメントは、CustomerIdentifierとCustomerAWSAccountIdの対応づけにAccount Feedsを、CustomerAWSAccountIdとLicenseArnの対応づけにAgreements Feedsを使うよう案内しています。推測で紐づけず、この2つのデータフィードを正とするのが公式の道筋でした。

作業は、対応表を作る、顧客テーブルにcustomer_aws_account_idとlicense_arnの列を足す、計測処理を新形式へ切り替える、旧形式の送信を止める、の4段階です。1つのアカウントが同じ製品で複数の契約を持てる以上、「顧客1件＝契約1件」を前提にした集計ロジックは見直しが要ります。同じ顧客の使用量を契約ごとに分けるのか、合算するのか。先に決めないと、移行後に請求金額の説明ができません。

AWS Marketplace経由の調達を選ぶ条件と直接契約に戻す判断

Marketplaceを通すかどうかは、価格ではなく手続きと統制で決めます。

Marketplace経由の調達が向く3つの条件と社内稟議での使い方

Marketplace経由を選ぶ理由が立つのは、次の3つの場面です。

  • 新規ベンダーの口座開設や与信審査に時間がかかり、検証を今週始めたい。請求がAWSに集約されるため既存の取引枠で処理できる。
  • 複数のSaaSを部門ごとに契約していて支払いと解約の管理が追えていない。購読の一覧とIAMによる権限制御を1か所へ寄せられる。
  • AMI製品やコンテナ製品を組織内の複数アカウントへ配りたい。管理アカウントでの受諾とLicense Manager共有という既定の経路がある。

実務でまず効くのは1番目でした。価格は直接契約と大きく変わらない例が多く、効くのは調達プロセスの短縮のほうです。稟議では「ベンダー新規登録が不要で、支払いは既存のAWS請求に乗る」という点を軸に書くと通りやすくなります。統制の面では、購読できるロールをAWSMarketplaceManageSubscriptions付きの1つに限り、他はAWSMarketplaceRead-onlyへ寄せるところから始めれば十分でした。画面で触れる範囲と自動化で触れる範囲を分ける考え方はAWSマネジメントコンソールとCLIの使い分けと同じです。

Marketplace経由を外して直接契約に戻す場面と確認する4項目

逆に、次の条件へ当てはまるならMarketplace経由は選びません。

第一に、円建てで価格を固定したい場合。公開リスティングは米ドル建てで、日本円が選べるのはプライベートオファーに限られます。売り手が個別交渉に応じないなら、為替の変動をそのまま費用で被る。第二に、契約書の条項を自社の雛形へ合わせたい場合です。公開オファーでは売り手の標準EULAを受け入れます。第三に、支払いサイトや検収条件を自社ルールに合わせたい場合。支払いはAWSの請求サイクルに従います。第四に、BYOL対応製品で既存ライセンスが手元にある場合です。持ち込めるなら、Marketplaceを通す理由はインフラ料金の一元化だけになります。

この4項目のうち2つ以上に当てはまるなら、直接契約へ戻すほうが管理は楽でした。どちらの経路でも、ライセンスの配布経路とアカウント構成、費用配賦の設計は同じ場で決める必要があります。設計から実装まで任せられる相手を探しているなら、AWS・Google Cloud・Azureのインフラ構築支援でマルチアカウント環境の設計と調達統制の実装をまとめて引き受けています。

よくある質問

購入と出品について検索で多く見られる質問に、公式ドキュメントの記述をもとに答えます。

AWS Marketplaceの利用そのものに追加料金はかかりますか？

カタログを見て購読する行為に、利用料が別途請求される仕組みはありません。支払うのは売り手が設定した製品の料金と、その製品を動かすために使ったAWSリソースの料金です。無償のソフトウェアやオープンソース製品には売り手側にもサービス手数料がかからず、AMI製品ではソフトウェア料金がゼロでもEC2インスタンスとEBSの費用が通常どおり発生します。

Marketplaceで買った製品の請求はどこに表示されますか？

AWSの請求書に、AWS Marketplaceの明細として計上されます。購入者ガイドは、詳細な請求情報を使えば製品ごとの使用量を確認でき、プライベートオファーでも使用量の種類ごとに明細行が対応すると説明しています。一括請求では管理アカウントへ集約されるため、どのアカウントの費用かを追うにはコスト配分タグの設定を先に済ませてください。

プライベートオファーの価格を日本円建てで提示してもらえますか？

可能です。公式ドキュメントは、公開リスティングが米ドル建てである一方、プライベートオファーでは米ドル・ユーロ・英ポンド・豪ドル・日本円に対応すると記載しています（インドルピーはインドの売り手のみ）。円建てにしたい場合は、売り手へプライベートオファーの発行を依頼する流れです。

BatchMeterUsageを再送したとき二重に課金されますか？

同一のリクエストは冪等に扱われるため、同じレコードやその一部を再送しても二重計上にはなりません。StatusにDuplicateRecordが返れば、その記録は既に受理済みという意味です。UnprocessedRecordsに入ったレコードはサービス側のエラーなので、そのまま再送して構いません。二重課金が起きうるのは再送ではなく、移行期にProductCodeとLicenseArnの両方で同じ1時間を送った場合でした。

新規のSaaS出品でCustomerIdentifierは使えますか？

新規の統合では使えません。BatchMeterUsageのAPIリファレンスは、2026年6月1日以降の新規SaaS製品がConcurrent Agreementsに対応するためCustomerAWSAccountIdとLicenseArnを使う必要があると記載しています。ResolveCustomerの応答でも当該フィールドは空になる。既存の統合は従来どおり動くものの、追随するなら移行計画を立てる時期でした。

関連記事

この記事に関連するサービス

資料請求

RELATED POSTS 関連記事

一覧へ戻る