割り当て

このドキュメントでは、Merchant API に適用される割り当てについて説明します。

Merchant API は、すべてのユーザーに安定した公平な環境を提供するために割り当てを使用します。割り当てにより、単一の API ユーザーがシステムに過剰な負荷をかけることを防ぎ、高いパフォーマンスを確保します。これらの割り当てを理解することは、Google で商品データを管理し、ビジネスを拡大するうえで重要です。

一般的なコンセプト

Merchant API の割り当ては、割り当てグループを通じて管理されます。

API メソッドは割り当てグループにマッピングされます。このマッピングの構造は次のようになります。

  • グループごとの単一メソッド: 一部の割り当てグループは、単一の API メソッドに適用されます。たとえば、リスティング データソースのメソッド accounts.dataSources.list には、専用の割り当てグループがあります。
  • グループあたりの複数のメソッド（バンドル）: 関連するメソッドは、1 つの割り当てグループにバンドルされることがよくあります。そのグループ内のすべてのメソッドは、同じ 1 日あたりの上限と 1 分あたりの上限を共有します。一般的な例としては次のようなものがあります。
    • merchant-accounts-read-methods など、関連するメソッドとリソースのすべての読み取りオペレーションをグループ化します。
    • merchant-accounts-write-methods などの関連するメソッドとリソースのすべての書き込みオペレーションをグループ化します。

各メソッド呼び出しは、タイプに関係なく 1 回カウントされます。250 個のアイテムの list リクエストは、250 個の get リクエストではなく、1 回としてカウントされます。

組み込みの HTTP バッチ処理は割り当てに影響しません。リクエストのバッチ内の各単一リクエストは、割り当てに対して 1 つとしてカウントされます。たとえば、500 個の insert リクエストを含むバッチ リクエストは、500 個の個別の insert メソッド リクエストとして課金されます。

専用リージョン バッチ処理の例外: 専用リージョン バッチ処理メソッド（batchCreate、batchUpdate、batchDelete）は、ペイロードに含まれるリージョン オペレーションの数に関係なく、merchant_regions 割り当てグループに対して 1 回の API 呼び出しとしてカウントされます。

統合を効果的に管理するには、使用する各 API メソッドに関連付けられている特定の割り当てグループを確認する必要があります。これらの詳細は、割り当てリスト メソッドで確認できます。詳細については、モニタリングと可視性をご覧ください。

ポリシーの更新

Merchant API では、更新に関して次のポリシーが適用されます。

  • デフォルトでは、1 日に 2 回まで商品を更新できます。1 分あたりの割り当てに準拠するため、通話は 1 日を通して均等に分散する必要があります。
  • デフォルトでは、サブアカウントを更新できるのは 1 日に 2 回までです。サブアカウントの 1 日あたりの更新割り当ては、許可されているサブアカウントの合計数に基づく集計上限です。
  • デフォルトでは、サブアカウントのデータソース メソッド（list や create など）は、サブアカウントごとに 1 日 2 回までしか呼び出すことができません。

レートに基づく割り当て

各割り当てグループには、次の 2 種類の上限（と 1 日の使用量）があります。

  • 1 日の上限（quotaLimit）: 1 日あたりに許可されるリクエストの最大数。1 日の割り当て上限は、UTC の正午 12 時にリセットされます。
  • 1 分あたりの上限（quotaMinuteLimit）: 1 分あたりに許可されるリクエストの最大数。リクエストのレートを制御します。1 分あたりの割り当て上限では、ローリング ウィンドウが使用されます。このウィンドウでは、メソッドとリソースに対する最初の API 呼び出しが行われた時点から適用期間が開始されます。たとえば、午前 10 時 1 分 30 秒に呼び出しを行うと、そのメソッドの 1 分あたりの割り当てウィンドウは 午前 10 時 2 分 30 秒まで実行されます。
  • 1 日の使用量（quotaUsage）: 当日にすでに実行され、1 日あたりの上限に対してカウントされたリクエストの数。このフィールドがない場合、このグループではまだ割り当てが使用されていません。

前述の 3 つのフィールド（quotaLimit、quotaMinuteLimit、quotaUsage）は、quotas.list メソッドのレスポンスで確認できます。

1 日あたりの上限と分あたりの上限は、割り当てグループによって大きく異なります。通常、商品データの読み取りなど、予想されるボリュームが大きいオペレーションやシステム コストが低いオペレーションには、より高い上限が設定されます。逆に、アカウントの変更など、より集中的な操作や機密性の高い操作には、より低い上限が設定されることがあります。

割り当てと階層

このセクションでは、Merchant API が割り当て使用量を追跡して適用する対象について説明します。

通常、割り当ては API リクエストを行うユーザーに基づいて課金されます。

  • スタンドアロン アカウント: API 呼び出しを認証するスタンドアロン アカウントの場合、そのリクエストはそのアカウントの割り当てにカウントされます。
    • 例: 販売者 Shoe Store A（アカウント ID: 12345）が、自身のアカウント（accounts/12345）をターゲットとする products.insert を呼び出すために、独自のサービス アカウントを使用して認証します。割り当ては Shoe Store A の割り当てプールから消費されます。
  • アドバンス アカウント: アドバンス アカウントとして認証すると、サブアカウントをターゲットにしている場合でも、アドバンス アカウントのプールから割り当てが消費されます。
    • 例: 代理店 Retail Management Account（アドバンス アカウント ID: 12345）が、サブアカウント Clothing Store B（アカウント ID: 11111）を管理しています。代理店は独自の認証情報を使用して認証し、衣料品店 B（accounts/11111）をターゲットとする products.insert を呼び出します。割り当ては、サブアカウントのプールではなく、親代理店のプール（アドバンス アカウント ID: 12345）から消費されます。
  • サブアカウント: サブアカウントの認証情報を使用して API 呼び出しが認証されると、割り当てはそのサブアカウントの個々のプールに課金されます。このアカウントは、親のアドバンス アカウントによって管理されますが、スタンドアロン アカウントと同じように動作します。
    • 例: 前と同じ設定で、衣料品店 B（アカウント ID: 11111）がサブアカウント専用に設定された認証情報を使用して認証し、自身のアカウント（accounts/11111）をターゲットとする products.insert を呼び出す場合、割り当ては衣料品店 B の個別の割り当てプールから消費され、親エージェンシーのプールはそのまま残ります。

一般的なルールの例外

割り当ての一般的なルールには、いくつかの例外があります。

  • Accounts.list: このメソッドの割り当ては、Merchant Center アカウント ID ではなく、呼び出しを行う認証済みユーザーまたはサービス アカウントに対して課金されます。割り当ての使用状況は、標準の Merchant Center API 診断ページには表示されません。アドバンス アカウントをお持ちの場合は、accounts.listSubaccounts メソッドを使用することをおすすめします。このメソッドは、アドバンス アカウントの割り当てにカウントされます。
  • 問題解決メソッド: これらのメソッドは、リクエストを認証するアカウントが異なる場合でも、問題がリクエストされているアカウントの割り当てに対して常にカウントされます。

割り当て階層

  • ショッピング比較サービス（CSS）: CSS は、商品の提案を集約し、ユーザーを販売者のウェブサイトに誘導して購入を促すウェブサイトです。API 呼び出しを行う場合、割り当ては認証対象の特定の CSS グループ、CSS ドメイン、アカウント、サブアカウントに適用されます。

    例:

    • Europe Shopping Group という名前の CSS グループ（アカウント ID: 10001）が、関連付けられている CSS ドメインを一覧表示したいと考えています。独自の認証情報で認証してこの API 呼び出しを行うと、割り当ては ヨーロッパ ショッピング グループの割り当てプールから直接消費されます。
    • CSS ドメイン TopDeals CSS（アカウント ID: 20002）が認証され、関連付けられている販売者アカウント（accounts/30003）のいずれかをターゲットとするメソッドを呼び出してラベルを割り当てます。割り当ては販売者アカウントのプールではなく、TopDeals CSS の割り当てプールから消費されます。

  • ショッピングモール: 複数の個別販売者をホストするオンライン プラットフォームです。販売者ごとに個別のサブアカウントを作成できる特別なアドバンス アカウントとして機能します。

次の図は、CSS グループ、CSS、マーケットプレイス、高度なアカウント、スタンドアロン アカウント、サブアカウントの階層を示しています。

CSS グループは包括的な認証レベルであり、その中に個々の CSS、その中のアカウント、最も個別のレベルとしてのサブアカウントが存在する可能性があります。

割り当ての自動調整

Merchant API には、特定のサービス用の自動割り当て管理システムがあります。このシステムは、使用量、商品、アカウントのサイズに基づいて、成長中の販売者の割り当て上限を調整します。Merchant API は、これらの割り当てを毎日再計算します。

割り当ての自動調整に含まれる割り当てグループは次のとおりです。

製品サービス

  • products リソースと productInputs リソースに関連するメソッドのすべての割り当てグループ。
  • 通常、1 日の通話割り当ては、販売者が保有するオファー割り当ての 2 倍に設定されます。これは、販売者が 1 日に 2 回まで各商品を更新する必要があることを想定しています。
  • 個々の商品は 2 回以上更新できますが、1 日の API 呼び出しの合計数が 1 日の呼び出し割り当ての合計を超えることはできません。

アカウント サービス

  • Merchant API のさまざまな粒度の細かいアカウント関連リソースに関連するメソッドの割り当てグループ。
  • 1 日あたりの呼び出し割り当ては、そのアカウントで許可されるサブアカウントの最大数に設定されます。これにより、サブアカウントごとに 1 日あたり最大 2 回の読み取り呼び出しが可能になります。

データソース サービス

  • アドバンス アカウントがサブアカウントに対して実行する、Merchant API のデータソース関連リソース（list や create など）に関連するメソッドのすべての割り当てグループ。
  • 1 日の呼び出し割り当ては通常、アドバンス アカウントのサブアカウント数の 2 倍に設定されます。これは、販売者が各サブアカウントのデータソースを 1 日に 2 回まで更新できることを前提としています。

自動割り当て調整が行われるのは、前述のサービスのみです。他のサービスにはデフォルトの割り当てがあり、増加は手動でリクエストする必要があります。詳細については、割り当ての増加プロセス セクションをご覧ください。

割り当てを超過した場合

割り当てを超えると、API レスポンスと Merchant Center アカウントの診断ページにエラーが表示されます。

  • 1 分あたり: quota/request_rate_too_high
{
    "error": {
        "code": 429,
        "message": "Quota per minute exceeded. Please distribute your requests over a longer time period. For more information check https://developers.google.com/merchant/api/guides/quotas-limits",
        "status": "RESOURCE_EXHAUSTED",
        "details": [
            {
                "@type": "type.googleapis.com/google.rpc.ErrorInfo",
                "reason": "quotaExceeded",
                "domain": "merchantapi.googleapis.com",
                "metadata": {
                    "HELP_CENTER_LINK": "https://developers.google.com/merchant/api/guides/quotas-limits",
                    "REASON": "QUOTA_REQUEST_RATE_TOO_HIGH"
                }
            }
        ]
    }
}
  • 1 日あたり: quota/daily_limit_exceeded
{
    "error": {
        "code": 429,
        "message": "Daily request quota exceeded. Please reduce number of requests. For more information check https://developers.google.com/merchant/api/guides/quotas-limits",
        "status": "RESOURCE_EXHAUSTED",
        "details": [
            {
                "@type": "type.googleapis.com/google.rpc.ErrorInfo",
                "reason": "quotaExceeded",
                "domain": "merchantapi.googleapis.com",
                "metadata": {
                    "HELP_CENTER_LINK": "https://developers.google.com/merchant/api/guides/quotas-limits",
                    "REASON": "QUOTA_TOO_MANY_REQUESTS"
                }
            }
        ]
    }
}

次のエラーは Merchant Center の上限であり、Merchant API の割り当てとは関係ありません。商品アイテム、フィード、サブアカウントの追加割り当てをリクエストしてみてください。

  • too_many_items: 販売者の割り当てを超過しました
  • too_many_subaccounts: サブアカウントの最大数に達しました

モニタリングと可視性

アカウントの現在の呼び出し割り当てと使用量を確認するには、アカウントの名前を指定して quotas.list を呼び出します。

POST https://merchantapi.googleapis.com/quota/v1/accounts/{ACCOUNT_ID}/quotas
Content-Type: application/json
Authorization: Bearer {ACCESS_TOKEN}

次のように置き換えます。

  • ACCOUNT_ID: Merchant Center ID
  • ACCESS_TOKEN: API 呼び出しを行うための認証トークン

リクエストが成功すると、API は、割り当てグループのリソース name、さまざまな割り当て、グループ割り当てが適用されるメソッドを含む quotaGroups リソースのリストを返します。

{
    "quotaGroups": [
        {
            "name": "accounts/{ACCOUNT_ID}/quotas/merchant-quota-listquotagroups",
            "quotaUsage": "2",
            "quotaLimit": "1000",
            "methodDetails": [
                {
                    "method": "quotaservice.listquotagroups",
                    "version": "v1",
                    "subapi": "quota",
                    "path": "quota/v1/quotaservice.listquotagroups"
                }
            ],
            "quotaMinuteLimit": "10"
        },
        {
            "name": "accounts/{ACCOUNT_ID}/quotas/merchant-commission-group-list",
            "quotaLimit": "10000",
            "methodDetails": [
                {
                    "method": "commissiongroupservice.listcommissiongroups",
                    "version": "v1",
                    "subapi": "youtube",
                    "path": "youtube/v1/commissiongroupservice.listcommissiongroups"
                }
            ],
            "quotaMinuteLimit": "60"
        },
        {
            "name": "accounts/{ACCOUNT_ID}/quotas/merchant-merchantreviews-list",
            "quotaLimit": "20000000",
            "methodDetails": [
                {
                    "method": "merchantreviewsservice.listmerchantreviews",
                    "version": "v1",
                    "subapi": "reviews",
                    "path": "reviews/v1/merchantreviewsservice.listmerchantreviews"
                }
            ],
            "quotaMinuteLimit": "60000"
        }
    ]
}

割り当て増加プロセス

割り当ての追加をリクエストするには、サポートへのお問い合わせフォームを開き、必須の [問題/質問] フィールドで [Quota increase request]（割り当て増加リクエスト）を選択して、Merchant Center ID、ターゲット設定方法、ビジネス上の正当性など、すべての必須フィールドに入力します。

  • 自動割り当てのあるリソース（高度なアカウントの products、accounts、datasources）の場合: 新しい市場でのリリースや、トラフィックの多いショッピング シーズンなどの特別なシナリオでの一時的な引き上げのみをリクエストできます。これらのタイプのリソースの割り当ての永続的な増加は受け付けていません。
  • 自動割り当てのない他のすべてのリソースの場合: 必要に応じて割り当ての増加をリクエストします。

割り当てを定期的に確認して、実装に十分な割り当てがあることを確認し、割り当てが自動的に調整される仕組みを確認することをおすすめします。quotas.list メソッドを使用して、各 API メソッド グループの現在の日次割り当て上限、分単位の上限、現在の日次使用量を確認します。

ベスト プラクティス

これらのベスト プラクティスを実装すると、統合がスムーズに実行され、予期しない割り当てエラーを回避し、Merchant Center のリソースを効率的に使用できます。

リクエストの分散を最適化する

  • リクエストを均等に分散する: 大量のバースト リクエストを送信しないようにします。1 分あたりの割り当て上限（quotaMinuteLimit）を超えないように、1 日の API 呼び出しを 1 日を通して均等に分散します。
  • 事前対応型スロットリング: アプリケーションにクライアントサイドのレート制限（スロットリング）を実装します。過剰なトラフィックを拒否するために Google のサーバーのみに頼らないでください。リクエスト率を送信元で制御します。

グレースフル エラー処理

  • HTTP 429 を処理する: アプリケーションは、429 Too Many Requests エラー（quota/request_rate_too_high）を処理できるように準備する必要があります。
  • ジッターを使用した指数バックオフ: 失敗したリクエスト（特に 429 の後）を再試行する場合は、指数バックオフ（待ち時間を増やす）を使用し、「ジッター」（ランダムな遅延）を追加します。ジッターは、複数のクライアント インスタンスがまったく同じタイミングで再試行し、サーバーが再び過負荷になる「再試行ストーム」を防ぎます。
  • 再試行のヒントを尊重する: API レスポンスに再試行の詳細またはヘッダーが含まれている場合は、それらを使用して呼び出しを再開するタイミングを決定します。

重複する通話を最小限に抑える

  • 古い呼び出しを防ぐ（404 NOT_FOUND）: 存在しないリソースのリクエストや削除を回避します。失敗した呼び出しでも API 割り当てが消費されます。Merchant Center API 診断で NOT_FOUND エラーをモニタリングして、古い状態のトラッキングや不要なポーリングを検出します。
  • 更新前の確認: 更新リクエストを送信する前に、データが実際に変更されたかどうかを確認します。同じ値を書き込む更新の送信は避けてください。
  • キャッシュの使用: 変更されていないデータに対する get または list の呼び出しの繰り返しを避けるため、必要に応じて読み取りレスポンス（商品詳細、設定など）をローカルにキャッシュに保存します。
  • アドバンス アカウントとサブアカウント: アドバンス アカウントの場合は、通話がアドバンス アカウントの共有プールにカウントされるようにするには、アドバンス アカウント レベルで認証します。
  • listSubaccounts を使用する: アドバンス アカウントの場合は、accounts.list ではなく accounts.listSubaccounts を使用します。accounts.list 割り当ては、呼び出し元ユーザー（MC ID ではない）に課金され、標準の診断には表示されません。listSubaccounts は MCA の割り当てにカウントされます。
前へ
Overview
次へ
Merchant Center limits