9 月 24 日午前 10 時（東部標準時間）に、Google 広告と測定のコミュニティサーバーの Discord と YouTube でライブ配信を行います。ここでは、Google Ads API の v25.2 で追加された新機能について説明します。

Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

API の制限と割り当て

Google Ads API では、単一の変更リクエストで送信できるオペレーションの数など、API オペレーションに上限が適用されます。次の表に、注意すべき重要な上限と割り当てをまとめます。

リクエストの種類、制限、エラーコード
テストアクセスレベルのオペレーション	テストアカウントに対する 1 日あたり 15,000 件の API オペレーション	`RESOURCE_EXHAUSTED`
Explorer アクセスレベルのオペレーション	本番環境アカウントに対する 1 日あたり 2,880 件の API オペレーションテストアカウントに対する 1 日あたり 15,000 件の API オペレーション	`RESOURCE_EXHAUSTED`
ベーシックアクセスレベルのオペレーション	テストアカウントと本番環境アカウントの両方に対して 1 日あたり 15,000 件の API オペレーション	`RESOURCE_EXHAUSTED`
標準権限でのオペレーション	テストアカウントと本番環境アカウントの両方に対して、1 日あたりの API オペレーション数が無制限	該当なし
変更リクエスト	リクエストあたりの変更オペレーション数: 10,000	`TOO_MANY_MUTATE_OPERATIONS`
プランニングサービスリクエスト	1 QPS	`RESOURCE_EXHAUSTED`
Conversion Upload Service のリクエスト	2,000 コンバージョン/リクエスト	`TOO_MANY_CONVERSIONS_IN_REQUEST`
Billing and Account Budget Service のリクエスト	変更リクエストごとに 1 つのオペレーション	`TOO_MANY_MUTATE_OPERATIONS`

1 日あたりの API オペレーション制限

1 日あたりの API 使用量の上限は、Google Cloud プロジェクトによって実行された API オペレーションの数に基づいています。API オペレーションは、Search リクエストと SearchStream リクエスト、個々のミューテートオペレーション、その他のサービスリクエストの合計です。1 日あたりの API オペレーション数の上限は、Google Cloud プロジェクトの API アクセスレベルによって異なります。アクセス権と使用許諾ガイドには、アクセス権ごとの API オペレーションの制限が記載されています。

これらの上限に違反するリクエストは、RESOURCE_EXHAUSTED というエラーで拒否されます。

gRPC の制限

すべての Google Ads API クライアントライブラリは、リクエストとレスポンスを生成するために gRPC を使用します。デフォルトでは、gRPC のメッセージサイズは 4 MB ですが、効率を高めるために、クライアントライブラリでは最大メッセージサイズが 64 MB に設定されています。

回答はこの上限を超えてはなりません。たとえば、多くのフィールドを含む検索リクエストでは、サイズが 64 MB を超えるレスポンスが生成されることがあります。この上限を超えないようにするには、選択するフィールドの数を減らすか、ストリーミングを使用します。mutate の場合は、リクエストごとに送信するオペレーションを少なくします。

この制限に違反するリクエストは、GoogleAdsError を生成しませんが、RESOURCE_EXHAUSTED（gRPC コード 8 / HTTP 429）エラーを生成します。gRPC エラーコードとメッセージのリストをご覧ください。

mutate リクエスト

mutate リクエストは、ユーザーの 1 日あたりのオペレーション割り当てにカウントされるだけでなく、1 リクエストあたり 10,000 個を超える mutate オペレーションを含むことはできません。この制限に違反するリクエストは、TOO_MANY_MUTATE_OPERATIONS というエラーで拒否されます。

特定のサービスとリクエストタイプに関する追加の上限と考慮事項については、以下をご覧ください。

リクエストを検索

Search リクエストまたは SearchStream リクエストは、ユーザーの 1 日あたりのオペレーション割り当てに対して 1 つのオペレーションとしてカウントされます。SearchStream リクエスト 1 件は、バッチの数に関係なく 1 件の API オペレーションとしてカウントされます。

ページ分けリクエスト

ページネーションされたリクエスト（有効な next_page_token を含むリクエストなど）は、ユーザーの 1 日のオペレーション割り当てにカウントされません。ただし、期限切れまたは無効なページトークンを含むページネーションリクエストは例外を生成し、1 日あたりのオペレーション割り当てにカウントされます。

ページネーションの詳細については、結果のページ分割をご覧ください。

その他の種類のリクエスト

Mutate、Search、SearchStream リクエスト以外のリクエストは、ユーザーの 1 日あたりのオペレーション割り当てに対して 1 つのオペレーションとしてカウントされます。

このようなリクエストの例をいくつか示します。

API 例外を返すリクエスト

GoogleAdsFailure で拒否されたリクエストは、ユーザーの 1 日あたりのオペレーション割り当てにカウントされます。

失敗しても GoogleAdsFailure を返さないリクエスト（ネットワークレベルのエラーなど）は、サービスに到達しないため、ユーザーの 1 日あたりのオペレーション割り当てにカウントされません。たとえば、ネットワーク接続の障害などです。

キーワードプランニングサービス

以下のキーワードプランニングサービスメソッドは複雑で費用がかさむため、他のタイプのリクエストとは別の制限を受けます。

CID ごとに 1 秒あたり 1 件のリクエストに制限されます。
これらの制限に違反するリクエストは、RESOURCE_EXHAUSTED というエラーで拒否されます。
1 QPS は、60 秒あたり 60 件のリクエストとして計算されます。
CID あたり 1 秒あたり 2 件のリクエストに制限されます。
- KeywordPlanIdeaService.GenerateAdGroupThemes

キーワードプランを作成する際は、これらの上限に留意してください。

キーワードプランオブジェクト	最大数
`KeywordPlan` / アカウント	10,000
`KeywordPlan` あたり `KeywordPlanAdGroup`	200
`KeywordPlan` あたり `KeywordPlanAdGroupKeyword`	10,000
`KeywordPlan` あたり `KeywordPlanCampaignKeyword` 個（除外キーワード）	1,000
`KeywordPlan` あたり `KeywordPlanCampaign`	1

オーディエンス分析サービス

AudienceInsightsService 内の次のメソッドには、特定の割り当て上限が適用されます。

CID あたり 1 日あたり約 200 件のリクエストに制限されます。
- AudienceInsightsService.GenerateAudienceCompositionInsights
- AudienceInsightsService.GenerateSuggestedTargetingInsights
Google Cloud プロジェクトごとに 1 秒あたり 2 リクエストに制限されます。
- AudienceInsightsService.GenerateTargetingSuggestionMetrics

コンバージョンアップロードサービス

リクエストあたりの通話コンバージョンまたはクリックコンバージョンは 2,000 件まで:
- ConversionUploadService.UploadCallConversions
- ConversionUploadService.UploadClickConversions
これらの上限に違反するリクエストは、TOO_MANY_CONVERSIONS_IN_REQUEST というエラーで拒否されます。

コンバージョンの調整アップロードサービス

リクエストあたりのコンバージョン調整は 2,000 件まで:
- ConversionAdjustmentUploadService.UploadConversionAdjustments
これらの上限に違反するリクエストは、TOO_MANY_ADJUSTMENTS_IN_REQUEST というエラーで拒否されます。

コンバージョン値のルール

アカウントごとに設定できるコンバージョン値のルールは 100,000 個までです。

この上限に違反するリクエストは、ResourceCountLimitExceededError.ACCOUNT_LIMIT エラーで拒否されます。

アカウントに attachment_type が CUSTOMER の ConversionValueRuleSet がすでに存在する場合は、新しいコンバージョン値のルールをそのセットに追加して有効にする必要があります。このようなコンバージョン値のルールセットが存在しない場合は、ルールセットを作成するの説明に沿って、ルールセットを作成し、コンバージョン値のルールを追加する必要があります。

お支払いとアカウント予算サービス

mutate リクエストは、毎月の請求書発行が設定されたアカウントに対してのみ行うことができます。

この制限に違反するリクエストは、MUTATE_NOT_ALLOWED というエラーで拒否されます。
変更リクエストで許可されるオペレーションは 1 つのみです。

この制限に違反するリクエストは、TOO_MANY_MUTATE_OPERATIONS というエラーで拒否されます。
同じアカウントのアカウントの予算（AccountBudget または AccountBudgetProposal）を変更する場合は、少なくとも 12 時間待つ必要があります。12 時間が経過する前に変更を加えると、Google 広告のアカウント担当者しか解決できない回復不能なエラーが発生する可能性があります。

お客様のアカウントへの招待

CustomerUserAccessInvitationService を使用して、既存のクライアントアカウントに新しいユーザーを招待できます。この機能は他のユーザーに招待メールを送信するため、悪用される可能性があります。そのため、動作には次のような制限があります。

ユーザーは、同じクライアントアカウントに対して複数の保留中の招待状を受け取ることはできません。保留中の招待状がすでに存在するユーザーに招待状を送信するリクエストが後続で送信された場合、EMAIL_ADDRESS_ALREADY_HAS_PENDING_INVITATION エラーが返されます。
クライアントアカウントで保留中の招待状は、一度に 70 個までです。この値を超えるリクエストが送信されると、PENDING_INVITATIONS_LIMIT_EXCEEDED というエラーが返されます。

ユーザーデータ

ユーザーデータは UserDataService と OfflineUserDataJobService で管理されます。

create オペレーションまたは remove オペレーションの各 UserData オブジェクトは、1 人のエンドユーザーに関連付けられます。1 つの UserData オブジェクト内の user_identifiers フィールドは、最大 20 個の識別子に制限されます。1 つの UserData オブジェクトでこの上限を超えると、OfflineUserDataJobError.TOO_MANY_USER_IDENTIFIERS エラーまたは UserDataError.TOO_MANY_USER_IDENTIFIERS エラーが発生します。

20 個を超える識別子を持つユーザーを処理する

アップロードする必要がある識別子が 1 人のエンドユーザーに 20 個以上ある場合は、これらの識別子を複数の UserData オブジェクトに分散する必要があります。Google がこれらの識別子をすべて同じエンドユーザーに関連付けられるようにするには、そのユーザーの各 UserData オブジェクトに、同じ hashed_email、hashed_phone_number、third_party_user_id などの共通の user_identifier を 1 つ以上含める必要があります。Google は、これらの共有 ID を使用して、個別の UserData オペレーションの情報を正しいエンドユーザープロファイルにリンクして統合します。

ハッシュ化されたメールアドレスや電話番号などの個人情報に依存している場合は、リンクの失敗を防ぐため、Google Ads API の要件（SHA-256、小文字、空白なし）に従って正規化およびハッシュ化されていることを確認してください。

たとえば、ユーザーが 30 個のメールアドレスを持っている場合、共通の third_party_user_id を共有する 2 つの UserData オブジェクトを送信できます（最初のオブジェクトに thirdPartyUserId とメールアドレス 1 ～ 19 を含めて 20 個の識別子の制限内に収め、2 番目のオブジェクトに thirdPartyUserId とメールアドレス 20 ～ 30 を含めます）。

{
  "userIdentifiers": [
    { "thirdPartyUserId": "user123" },
    { "hashedEmail": "SHA256_OF_EMAIL_1" },
    // Hashed emails 2 through 18 are omitted here.
    { "hashedEmail": "SHA256_OF_EMAIL_19" }
  ]
}

{
  "userIdentifiers": [
    { "thirdPartyUserId": "user123" },
    { "hashedEmail": "SHA256_OF_EMAIL_20" },
    // Hashed emails 21 through 29 are omitted here.
    { "hashedEmail": "SHA256_OF_EMAIL_30" }
  ]
}

単一の AddOfflineUserDataJobOperationsRequest 内のすべてのオペレーションにおける user_identifiers の合計上限は 100,000 です（OfflineUserDataJob は複数の AddOfflineUserDataJobOperationsRequest 呼び出しを受け入れることができます。推奨される上限はジョブあたり 1,000,000 オペレーションです）。UploadUserDataRequest（UserDataService.UploadUserData）を使用する同期アップロードの場合、各リクエストは最大 10 個のオペレーションと、リクエスト全体で 100 個の user_identifiers に制限されます。

その他の種類の制限

リクエストに含まれるアイテムが多すぎる繰り返しフィールド（例: オペレーションのリスト）では、REQUEST_SIZE_LIMIT_EXCEEDED エラーが発生する可能性があります。このエラーメッセージは、他の問題が原因で表示されることもあります。

この制限に達し、繰り返しフィールドを使用するリクエストを行っている場合は、複数の mutate リクエストにオペレーションのリストを分割して、繰り返しフィールドのアイテム数を減らしてみてください。

GAQL クエリを作成する場合、IN 句内のアイテムの最大数は 20,000 個です。この上限を超えると、FILTER_HAS_TOO_MANY_VALUES エラーが返されます。

概要

システム制限