2026年のGoogle Ads APIアクセス：Cloudプロジェクトがデベロッパートークンに代わる

2026年9月9日以降、Google Ads APIへのアクセスはデベロッパートークンではなくGoogle Cloudプロジェクト単位で付与されています。何が変わったのか、現在のアクセス設定の手順、そして2026年6月のセットアップガイドのうち今も有効な部分を整理します。

2026年9月9日に変わったこと

2026年6月のGoogle Ads APIセットアップ・認証・読み取りと書き込み操作に関するガイドは、デベロッパートークンを前提に構成していました。マネージャーアカウントのAPI Centerでトークンを取得し、そこでBasicアクセスを申請し、すべての呼び出しでトークンを送信する、という流れです。3か月後、その前提が変わりました。Googleの公式ドキュメントは現在、次のように明記しています。「Developer tokens were sunset on September 9, 2026.」

アクセスに関する判断そのものがなくなったわけではなく、移動しました。APIアクセスレベルは、OAuth認証情報の生成に使用したGoogle Cloudプロジェクトによって決まるようになり、既存のアクセスは自動的にCloudプロジェクトへ移行されました。申請はAPI Centerでは行えません。Googleは開発者に対し、API Centerでデベロッパートークンを申請しないよう求めており、代わりにGoogle Cloud ConsoleのGoogle Ads API Overviewページからアクセスを申請する必要があります。API Centerで保留中だったBasicの申請は終了しており、Cloud Consoleから再提出する必要があります。

6月のガイドは公開当時のまま残し、冒頭に日付入りの注記を付けています。本稿では現在の相違点を扱い、従来の内容が今も当てはまる箇所では当該ガイドに戻ってご案内します。

アクセスレベルはCloudプロジェクトに紐づく

アクセスレベル自体は従来どおりですが、1つ追加があります。以下の上限は、2026年10月時点のGoogleのアクセスレベルに関するドキュメントに基づきます。

アクセスレベル	本番アカウント	1日あたりの操作数
Test	不可（テストアカウントのみ）	15,000
Explorer	可	本番アカウントに対して2,880
Basic	可	15,000
Standard	可	全体の上限なし（個別のサービスには上限が残る場合あり）

実務上の入り口はExplorerです。Googleによると、Cloud Consoleからの申請は自動的に審査され、多くの場合Explorerアクセスへ引き上げられます。社内レポートや自社アカウントでの小規模な自動化には十分です。BasicとStandardは引き続き審査が必要で、どちらも新たにGoogle Cloudプロジェクトのブランド確認が前提条件になりました。Standardにはさらに手動の監査が加わります。

問題は、技術面の設定がすでに動いていると、ブランド確認を見落としやすい点です。Explorerアクセスで動くスクリプトは、1日の上限に達するまでは正常に動作します。ブランド確認は、利用量が増えてからではなく、増える前に計画してください。

現在のアクセス設定手順

アクセスの判断がCloudプロジェクトという1か所に集約されたため、手順は以前より短くなりました。

Google Cloudプロジェクトを作成するか、Google Ads連携を所有するプロジェクトを選択します。これに課金設定は必要ありません。
プロジェクトのAPIライブラリでGoogle Ads APIを有効にします。
同じプロジェクト内で認証情報を作成します。ユーザーベースのアクセスにはOAuthクライアント、サービスアカウントにはJSONキーを使用します。
Cloud ConsoleのGoogle Ads API Overviewページでアクセスを申請し、BasicまたはStandardアクセスが必要な場合はブランド確認を完了します。

ここで重要なのはステップ3です。アクセスはOAuth認証情報を発行したプロジェクトに従うため、無関係な別プロジェクトの認証情報は、申請したアクセスレベルを引き継ぎません。長年にわたり別々のプロジェクトにテスト用クライアントを作成してきたチームは、本番アクセスに頼る前に統合しておくべきです。

6月のガイドにあるOAuthの詳細（adwordsスコープ、リフレッシュトークンを得るためのオフラインアクセス、リフレッシュトークンが機能しなくなる理由）は変わらず、そのまま有効です。

認証と設定

デベロッパートークンは、実質的に任意になりました。Googleによれば、リクエストヘッダーへの送信は続けられますが、サーバーはこれを無視し、将来のAPIメジャーバージョンでは拒否される見込みです。公式Pythonライブラリのバージョン32.0.0では、設定にトークンを必須とするチェックが削除されました。

ユーザーベースOAuth向けの最小限の google-ads.yaml は次のようになります。

client_id: YOUR_CLIENT_ID.apps.googleusercontent.com
client_secret: YOUR_CLIENT_SECRET
refresh_token: YOUR_REFRESH_TOKEN
login_customer_id: "1234567890"
use_proto_plus: true

サービスアカウントの場合は、3つのOAuthキーの代わりに json_key_file_path を使用し、必要に応じて impersonated_email と組み合わせます。すべてのキーは、GOOGLE_ADS_ プレフィックスを付けた環境変数としても設定できます（例：GOOGLE_ADS_JSON_KEY_FILE_PATH）。設定ファイルがバックアップやリポジトリに紛れ込みやすいサーバーでは、こちらが賢明な選択です。

login_customer_id の意味は従来と変わりません。マネージャーアカウント経由でクライアントアカウントにアクセスする場合、そのマネージャーアカウントを指定します（数字のみ、ハイフンなし）。指定しないと、こうした呼び出しは USER_PERMISSION_DENIED で失敗します。

バージョンとPythonライブラリ

バージョンの固定は、通常考えられている以上に注意が必要です。6月のガイドでは version="v22" を使用していましたが、このバージョンはすでに利用できません。google-adsのPythonライブラリのリリース33.0.0でv21とv22が削除されたためです。2026年10月時点の最新APIバージョンはv26（2026年10月14日リリース）で、ライブラリ34.0.0がこれに対応しています。

from google.ads.googleads.client import GoogleAdsClient

client = GoogleAdsClient.load_from_storage("google-ads.yaml", version="v26")

バージョンを明示的に固定することは、今も適切な既定の対応です。実際には、固定していないクライアントは次回のライブラリ更新時に挙動が静かに変わります。Googleは公表されたスケジュールに沿ってAPIバージョンを廃止するため、固定しておけば、少なくともその廃止が不意の出来事ではなく計画的な変更になります。

EUの政治広告に関する宣言

既存の多くの連携に影響した要件があります。Campaign リソースの contains_eu_political_advertising フィールドです。v26より前のAPIバージョンでは、すべての新規キャンペーンでこれを宣言する必要があります。2026年4月1日以降、アカウントに未宣言のキャンペーンが残っている場合、mutate呼び出しは EU_POLITICAL_ADVERTISING_DECLARATION_REQUIRED で失敗します。バージョン26ではこれが緩和され、EUを積極的にターゲットとしないキャンペーンでは任意になります。

明示的に宣言するのは1行で済み、キャンペーン作成コードをバージョン間で有効に保てます。

campaign.contains_eu_political_advertising = (
    client.enums.EuPoliticalAdvertisingStatusEnum.DOES_NOT_CONTAIN_EU_POLITICAL_ADVERTISING
)

6月のガイドから引き継がれる内容

従来の解説の大部分はAPIへの接続ではなくAPIの扱い方に関するもので、この部分は今も通用します。GAQLの読み取りクエリ、書き込み操作を安全にテストするための validate_only パターン、update_mask の明示的な扱い、マネージャーアカウント・Cloudプロジェクト・対象アカウントの分離は、記載どおりに適用できます。適用できなくなったのはアクセス経路、つまりAPI Center、デベロッパートークンの申請、トークンを前提としたアーキテクチャ図です。

社内スクリプトであれクライアント向けツールであれ、優れた連携は、アクセスを明確に名前の付いた1つのCloudプロジェクトが所有する設定として扱います。これは2026年9月以前から妥当な運用でしたが、現在ではGoogleによるアクセスの定義そのものになっています。