Google Ads API、開発者トークンからCloudプロジェクトへ移行。既存連携で確認したいこと

Google Ads APIの利用権限を管理する単位が変わりました。Googleは2026年9月9日、開発者トークンを廃止し、APIのアクセスレベルをGoogle Cloudプロジェクトに移行しました。公式FAQで、この変更がすでに実施済みであることを確認できます。Google公式FAQ

既存の連携が直ちに止まる変更ではありません。一方、Googleから開発者に送られた通知では、開発者トークンの送信をやめるコード修正と、連絡を受け取る担当者の確認が求められています。

自社でレポート取得や入稿を自動化している場合は、利用中のCloudプロジェクトと実装を確認しておきたい変更です。

この記事の要約

• APIアクセスレベルの管理先が、開発者トークンからGoogle Cloudプロジェクトに変わりました。
• 既存コードは当面そのまま動きますが、対応ライブラリへ更新し、開発者トークンの送信を外す準備が必要です。
• プロジェクトのアクセスレベル、OAuth認証情報の所属先、通知を受け取る担当者を確認します。

何が変わったのか

開発者向け通知の内容を整理すると、主な変更は次のとおりです。

出典：Googleから開発者に送付された移行通知メール（本記事作成時に提供を受けたもの）。個別の顧客ID・プロジェクト番号は省略しています。

ここで確認したいのが、どのCloudプロジェクトの権限が使われるかです。公式FAQによると、ユーザー認証ではOAuthクライアントID・シークレットを所有するプロジェクト、サービスアカウント認証ではサービスアカウントを所有するプロジェクトが基準になります。Google公式FAQ

実務では、処理を動かしているサーバーの所属だけで判断せず、実際に使う認証情報の作成元まで確認すると取り違えを防げます。

「移行済み」と「コード修正の期限」を分けて考える

通知メールでは、既存コードは変更なしで引き続き動作すると案内されています。ただし、将来も開発者トークンを送り続けられるわけではありません。

公開FAQは、トークンを受け付けなくなる時期を「将来のメジャーバージョン」と表現しています。2027年前半という予定は通知メールに基づくもので、今回確認した資料では具体的な日付・対象バージョン番号までは示されていません。Google公式FAQ

「2027年になったらすべての既存連携が一斉停止する」とは読み取れません。利用するAPIバージョンの更新計画に、トークン送信の削除を組み込むのが現実的です。

自動移行されていないプロジェクトに注意

公式FAQによると、自動移行の対象は、直近90日間に承認済み開発者トークンと組み合わせてAPIを利用したCloudプロジェクトです。複数のプロジェクトを使っていた場合は、それぞれにアクセスレベルが引き継がれます。

一方、新しいプロジェクトに古い承認済みトークンを設定しても、そのトークンで本番アクセスを得ることはできません。対象プロジェクトから必要なアクセスレベルを申請します。Google公式FAQ

このため、確認対象には日常的に稼働する本番連携だけでなく、しばらく止めていたツールや、新しく作る検証環境も含めることを勧めます。たとえば「以前承認されたトークンがあるから、新しい環境でもすぐ本番データを取得できる」と考えると、セットアップでつまずく可能性があります。

開発者トークンが不要になっても、OAuth認証は必要

APIアクセスレベルと、広告アカウントへのアクセス権限は別の確認事項です。Google Ads APIはOAuth 2.0で認証・認可を行い、認証するユーザーやサービスアカウントには、対象の広告アカウントへアクセスできる権限が必要です。Google公式：OAuth 2.0

コード修正では、削除対象を開発者トークンの設定・送信部分として整理します。OAuthクライアント情報、リフレッシュトークンなどの認証設定や、必要なアカウント指定まで一括で削除しないようにします。

また、Cloudプロジェクトのオーナーになっただけで、任意のGoogle広告アカウントを操作できるようになるわけではありません。Cloud側の管理担当者と、広告アカウント側の権限を管理する担当者を分けて把握しておくと、問題発生時に確認先が明確になります。

ライブラリを更新してから、トークン送信を外す

Pythonクライアントライブラリの変更履歴では、バージョン32.0.0で、設定に開発者トークンが存在するかを確認する検証処理が削除されています。同時に、use_cloud_org_for_api_access設定も削除されています。公式Pythonライブラリの変更履歴

そのため、古い実装からトークンの値だけを消す前に、使っているライブラリの対応状況を確認します。Python以外の言語も、それぞれの変更履歴で確認が必要です。Pythonライブラリの「32.0.0」は、Google Ads API本体のバージョン番号ではありません。

実装担当者には、次の順序で対応を依頼すると進めやすくなります。

1. 利用中のAPIバージョン、ライブラリ、認証情報の所属プロジェクトを整理する。
2. 依存関係を確認して対応ライブラリへ更新する。
3. 設定ファイル・環境変数・独自コードにある開発者トークンの読み込みと送信処理を外す。
4. 少量の読み取りリクエストで、想定した広告アカウントのデータを取得できるか確認する。
5. 定期実行にも変更を反映し、通常のレポート取得や連携処理が成功するか確認する。

この手順は移行作業の進め方としての提案です。外部サービスを使っている場合は、サービス提供元に対応状況と利用者側の作業有無を確認します。

Basicなどのアクセスレベルや利用上限は残る

管理単位がCloudプロジェクトに変わっても、アクセスレベルによる制限はあります。現在の公式資料には、Test、Explorer、Basic、Standardの4段階が示されています。

「1日」は直近24時間の移動期間で判定されます。また、Explorerではキーワードプランニングなど利用できない機能があり、回数だけで適切なレベルを選べるわけではありません。Google公式：アクセスレベルと許可される用途

新規にBasicアクセスを申請する場合は、Cloudプロジェクトのブランド確認が前提です。新しいツールの構築時は、必要な機能と申請手続きを先に確認しておくと、実装後に利用条件が不足する事態を避けやすくなります。Google公式：Basicアクセスの申請

最初に確認するのは、権限・実装・連絡先の3点

通知を受け取ったら、まずCloud Consoleで対象プロジェクトのGoogle Ads API概要ページを開き、通知どおりのアクセスレベルになっているか確認します。次に、実装担当者へライブラリ更新とトークン送信削除を依頼します。

連絡先の確認も必要です。通知メールでは、APIセンター廃止後の管理・コンプライアンス連絡はCloudプロジェクトのオーナーとエディターにのみ送られると案内されています。現在のIAM設定と、通知を受け取った人が対応担当者へ共有できる体制を確認しておきます。役割の変更は、プロジェクトの管理責任者と調整します。

レポート取得、コンバージョン連携、API入稿などを複数のツールで行っている場合は、「ツール名・認証情報の所属プロジェクト・アクセスレベル・保守担当者」を一覧にして確認すると、対応漏れを見つけやすくなります。

公式情報の確認日：2026年9月14日。将来の日程は予定であり、変更される場合があります。