何が起きたか:Google Ads APIの新規リフレッシュトークン発行にパスキー認証が必須に
Search Engine Landの記事「Google makes passkeys mandatory for Google Ads API users(Googleが Google Ads API利用者にパスキーを必須化)」によると、Googleはセキュリティ強化の取り組みの一環として、Google Ads API経由で新規のOAuth 2.0リフレッシュトークンを生成する際に、パスキーによる認証を義務化します。記事はAnu Adegbola氏の署名で2026年7月27日に公開されています。
対象となるのは「新規に」発行されるリフレッシュトークンであり、記事はこの変更をGoogleの広範なセキュリティ強化施策の一部と位置づけています。認証手段そのものを刷新する変更であるため、Google Ads APIを使って自動化・外部ツール連携を行っている開発者・代理店・SaaS事業者にとっては、認証まわりの実装や利用者向け案内の見直しが必要になります。
適用開始日と対象範囲:2026年8月5日から段階展開、対象ツールはGoogle Ads Editor・スクリプト・BigQuery Data Transfer Service・Looker Studio
記事によれば、今回のパスキー義務化は「2026年8月5日に開始し、その後数週間かけて全ユーザーに展開される(“The rollout begins on 5th August and will expand to all users over the following weeks.”)」とされています。8月5日時点で一斉に全ユーザーへ適用されるのではなく、段階的なロールアウトである点がポイントです。
影響が及ぶ範囲として記事が挙げているのは、Google Ads Editor、Google Ads Scripts、BigQuery Data Transfer Service、Looker Studioの4つです。いずれもGoogle Ads APIの認証情報(OAuth 2.0リフレッシュトークン)を利用してデータ取得や自動操作を行うツール・サービスであり、これらを介して新規に認証を行う開発者・代理店・SaaS事業者が主な対象になります。
具体的に何が変わるか:パスワード・SMS・TOTPに代わりパスキーでの認証が必須に
8月以降、新規にOAuth 2.0リフレッシュトークンを生成するユーザーは、パスワードのみによる認証や、SMSコード・TOTP(Time-based One-Time Password、時間ベースのワンタイムパスワード)といった従来型の二要素認証ではなく、パスキーを使って認証する必要があります。パスキーを持っていないユーザーは、認証の過程でパスキーの新規作成を求められます。
一方で、すでに発行済みの既存のOAuthリフレッシュトークンについては、再認証(reauthorization)を求められることなく、そのまま利用を継続できるとされています。既存の連携をすぐに止める必要はなく、影響が及ぶのはあくまで「これから新規に発行されるトークン」という位置づけです。
もう1点、実務上見落としやすい仕様として、新しく作成されたパスキーには、完全な信頼状態(full trust status)に達するまでに最大7日間のセキュリティ上の遅延が生じうる点が記事に明記されています。新規にパスキーを作成した直後にただちに全面的な信頼状態になるとは限らず、この猶予期間を見込んだ運用設計が必要になります。
対象外となるケース:サービスアカウントを使った自動化ワークフローは影響なし
記事は、今回の変更が影響しないケースについても明記しています。自動化ワークフローで使われるサービスアカウント(service account)ベースのアプリケーションは、今回のパスキー義務化の対象外(unaffected)とされています。ユーザー個人の認証情報に紐づく形で新規トークンを発行する運用のみが対象であり、サービスアカウント経由で完結している既存の自動連携については、この変更による直接的な影響はないと読み取れます。
背景:Googleが進めるパスワードレス認証(パスキー)への移行の流れ
記事はこの変更を「セキュリティ強化の取り組みの一環(as part of its security enhancement initiative)」と説明しており、Google Ads APIという特定のAPIだけを対象にした単発の仕様変更というより、より広い文脈にあるセキュリティ方針の一部という位置づけがうかがえます。パスワードやSMSコード・TOTPによる二要素認証は、フィッシングやSIMスワップといった手口で突破されるリスクが指摘されてきた認証方式であり、こうした弱点を持たない公開鍵暗号ベースのパスキーへの移行は、Googleがコンシューマー向けアカウントなどでも進めてきた方向性と軌を一にするものとみられます。ただし、この記事自体には過去の経緯や他サービスへの適用実績についての詳細な記述はなく、あくまでGoogle Ads APIにおける今回の発表内容が報道の中核です。
実務への影響:広告運用・API連携の開発者が今すぐ確認すべきこと
この変更の影響を直接受けるのは、Google Ads APIを使って顧客の広告アカウントに接続するツールやサービスを提供している開発者・代理店・SaaS事業者です。特に、新規顧客のオンボーディング時に新しいOAuthリフレッシュトークンを発行するフローを持っている場合、8月5日以降はその過程でパスキーの作成を求められる可能性があり、案内文言やサポート対応の準備が必要になります。
また、新規に作成したパスキーには最大7日間の信頼確立期間がある点も、オンボーディングのスケジュールに影響しえます。導入直後にすぐフル機能でAPI連携を使いたいという顧客がいる場合、この猶予期間を踏まえたスケジュール調整や事前案内をしておかないと、想定外の遅延として問い合わせにつながる可能性があります。一方で、既存のリフレッシュトークンを使い続けているだけの連携や、サービスアカウントで完結している自動化ワークフローについては、記事の内容を見る限り緊急の対応は不要です。
今日からできる確認手順
まず、自社または自社が提供するツールがGoogle Ads API・Google Ads Editor・Google Ads Scripts・BigQuery Data Transfer Service・Looker Studioのいずれかを通じて、ユーザー個人の認証情報に紐づくOAuth 2.0リフレッシュトークンを新規発行するフローを持っているかどうかを棚卸しします。該当するフローがあれば、それが8月5日以降にパスキー認証を求める対象になることを前提に、社内の対応手順を確認します。
次に、新規にAPI連携を行う予定の顧客・利用者がいる場合は、8月を待たずに事前にパスキーを作成しておくよう案内します。記事もGoogleの推奨として、8月より前にパスキーを作成しておくことで、実際にアクセスが必要になった際の認証遅延を避けられるとしています。
あわせて、新規パスキー作成後に最大7日間の信頼確立期間が生じうることを、オンボーディング案内やサポート対応のFAQに反映しておきます。最後に、自社の連携がサービスアカウント方式で完結しているか、ユーザー個人の認証情報に依存しているかを改めて確認し、後者の場合は認証UI・エラーハンドリングがパスキーでの認証プロンプトに対応できているかをテストしておくとよいでしょう。
所感
Scale Basics編集部としては、今回の発表で実務上もっとも見落としやすいのは、義務化そのものよりも「新規作成したパスキーが最大7日間、完全には信頼されない」という猶予期間の存在だと考えています。既存トークンは再認証不要で継続利用できるため一見影響は限定的に見えますが、新規オンボーディングを日常的に行っている代理店やSaaS事業者にとっては、この7日間がそのままリードタイムの延伸につながりかねません。
対応の優先順位としては、まず自社のどのフローが「新規リフレッシュトークンの発行」に該当するのかを特定すること、次に対象となる顧客・利用者に対して8月5日より前からパスキー作成を促す案内を始めることの2点が現実的です。記事にはGoogle Ads API以外のサービスへの適用状況や、対象アカウントの範囲(個人アカウントか組織アカウントかなど)についての詳細な記載はないため、自社の具体的な運用に照らして不明な点があれば、Google Ads APIの公式アナウンスを合わせて確認することをおすすめします。
まとめ
・Googleは、Google Ads API経由で新規のOAuth 2.0リフレッシュトークンを生成する際に、パスキー認証を義務化すると発表した
・適用開始は2026年8月5日で、その後数週間かけて全ユーザーに段階的に展開される
・対象ツールはGoogle Ads Editor、Google Ads Scripts、BigQuery Data Transfer Service、Looker Studioの4つ
・パスキーを持たないユーザーは認証時に新規作成を求められ、作成直後のパスキーには最大7日間の信頼確立の猶予期間が生じうる
・既存のOAuthリフレッシュトークンは再認証不要で継続利用でき、サービスアカウントを使った自動化ワークフローも今回の変更の対象外
よくある質問
Q1: 今回のパスキー義務化はいつから始まりますか?
Search Engine Landの記事によれば、2026年8月5日にロールアウトが始まり、その後数週間かけて全ユーザーへ段階的に展開されるとされています。8月5日時点で全ユーザーに一斉適用されるわけではありません。
Q2: どのツール・サービスが今回の変更の対象になりますか?
記事が対象として挙げているのは、Google Ads Editor、Google Ads Scripts、BigQuery Data Transfer Service、Looker Studioの4つです。これらを通じてGoogle Ads APIの新規OAuth 2.0リフレッシュトークンを発行する開発者・代理店・SaaS事業者が主な影響対象になります。なお、サービスアカウントを使った自動化ワークフローは対象外です。
Q3: 既存のOAuthリフレッシュトークンや、すでに連携済みのアカウントはどうなりますか?
記事によれば、既存のOAuthリフレッシュトークンは再認証を求められることなく、そのまま利用を継続できます。影響を受けるのは、8月5日以降に新規発行されるリフレッシュトークンのみです。ただし新規に作成したパスキーには最大7日間の信頼確立の猶予期間が生じうるため、これから新規に認証を行う予定がある場合は、事前にパスキーを作成しておくことが推奨されています。
出典:Google makes passkeys mandatory for Google Ads API users(Search Engine Land、Anu Adegbola氏、2026年7月27日)https://searchengineland.com/google-makes-passkeys-mandatory-for-google-ads-api-users-483617
参考:Passkey authentication requirement for the Google Ads API(Google Ads Developers Blog、2026年7月27日)https://ads-developers.googleblog.com/2026/07/passkey-authentication-requirement-for.html
