アドサプリ ブログ

拡張コンバージョン2026年仕様変更まとめ|統合とAPI移行の対応手順

作成者: アドサプリ運営チーム|Jul 23, 2026, 1:52:09 PM
HOMEブログ / 拡張コンバージョンの2026年仕様変更まとめ。ウェブ/リード統合とData Manager API移行の対応手順
拡張コンバージョン効果測定

拡張コンバージョンの2026年仕様変更まとめ。ウェブ/リード統合とData Manager API移行の対応手順

アドサプリ運営チーム2026.07.23

拡張コンバージョンとは、メールアドレスや電話番号など自社サイトで得た顧客データをハッシュ化(暗号化に近い不可逆変換)してGoogleに送り、Cookie規制などで欠けがちなコンバージョン計測を補う仕組みです。その拡張コンバージョンの設定仕様が、2026年4月から6月にかけて大きく変わりました。「管理画面を開いたら『ウェブ向け』『リード向け』の選択肢が見当たらない」「CRM連携のアップロードが今後どうなるのか分からない」。そんな戸惑いの声を、この春以降よく耳にします。

結論から言うと、変更の柱は2つです。1つ目は、これまで別々だった「ウェブ向け」と「リード向け」の設定が単一のオン/オフに統合されたこと。2つ目は、API経由のオフラインコンバージョンやリード向け拡張コンバージョンのアップロード先が、Google Ads APIからData Manager APIへ移行し、2026年6月15日で新規受付の線引きがされたことです。既存の設定は多くの場合そのまま引き継がれますが、「自動だから何もしなくていい」とは言い切れない確認ポイントがいくつかあります。本記事では、2026年7月時点の公式情報をもとに、変更内容と対応手順を設定仕様の面から整理します。

この記事の要点

  • 2026年4月以降、ウェブ向け/リード向けの拡張コンバージョンは単一のオン/オフ設定に統合されつつあります
  • タグ・Data Manager・API接続の複数ソースから同時にデータを受け入れ、Google側で照合する方式に変わりました
  • 2026年6月15日以降、Google Ads APIでの新規のオフラインコンバージョンインポート(リード向け拡張コンバージョン含む)は受付停止と発表され、移行先はData Manager APIです
  • 既存設定は多くの場合自動移行ですが、「規約への同意状況」と「API連携を誰が担っているか」の2点は自社での確認が必要です

1. 拡張コンバージョンとは:スマート入札の学習精度を支える「土台」

まず前提の整理です。拡張コンバージョンは、コンバージョン発生時にユーザーが入力したメールアドレスなどをSHA-256でハッシュ化してGoogleに送信し、Googleアカウントのログイン情報と照合することで、Cookieだけでは追い切れなかったコンバージョンを計測に反映する仕組みです。SafariのITPをはじめとするブラウザ側の制限で、従来の計測は「本当はあったコンバージョンの取りこぼし」が増えていると言われます。その欠けを補うのが拡張コンバージョンの役割です。

これまでは2つの製品に分かれていました。「ウェブ向け」は購入や申し込みなどサイト上で完結するコンバージョンの計測精度を補うもの。「リード向け」はフォーム送信後にオフラインで成約したリードを、メールアドレスをキーに広告クリックへ紐付けるものです。

重要なのは、これが単なる「計測の正確さ」の話にとどまらない点です。目標コンバージョン単価(tCPA)や目標広告費用対効果(tROAS)といったスマート入札は、アカウントに蓄積されたコンバージョンデータを学習材料にします。学習データが2割欠けたまま自動入札を回すのは、視力の落ちた目で運転するようなものです。派手な入札調整やクリエイティブ改善の前に、まずこの土台が整っているか――というのが実務での位置づけだと考えています。実際、Googleの公式ヘルプでも、ウェブ向けの拡張コンバージョンによって計測されるコンバージョンが増えた事例が紹介されており、計測の底上げは入札の判断材料の底上げに直結します。スマート入札の学習の仕組みはtCPAの学習期間の記事でも詳しく扱っています。

2. 変更点①:「ウェブ向け」「リード向け」が単一設定に統合(2026年4月〜)

1つ目の変更は設定の統合です。Google広告の公式ヘルプによると、2026年4月以降、拡張コンバージョンはウェブサイトのタグ(GoogleタグまたはGoogleタグマネージャー)、Data Manager、API接続という複数のソースから同時にユーザー提供データを受け入れる方式に変わりました。従来のように「実装方法を1つ選ぶ」必要はなくなり、複数ルートから届いたデータをGoogle側が内部で照合します。6月にはウェブ向け/リード向けという製品の区別自体が管理画面上でも一本化された、と報じられています。

なぜ統合されたのか。背景には、実装方法ごとの「縦割り」が広告主の設定ミスや取りこぼしを生んでいた事情があると見られます。たとえば、ウェブ向けはタグで設定済みなのにリード向けは未設定、あるいはタグとAPIで送信データが食い違う、といった状態です。複数ソースを同時に受け入れてGoogle側で照合する方式なら、こうした食い違いはシステム側で吸収されます。広告主にとっては設定の分岐が減り、その分「データの中身が正しいか」に集中できる変更と言えます。

広告主側の扱いは、立場によって異なります。

すでに拡張コンバージョンを使っている場合

顧客データに関するGoogleのデータ処理規約に同意済みであれば、多くの場合、自動的に新しい統合設定へ移行されると案内されています。設定作業のやり直しは基本的に不要です。ただし後述の通り、「オンになっていること」と「データが実際に届いていること」は別問題なので、移行後の送信状況は確認しておきたいところです。

これから設定する場合

管理画面の「目標」メニューから「設定」を開き、顧客データの利用に関するパネルで拡張コンバージョンを有効化し、データ処理規約に同意する流れです。アカウント単位でまとめて有効化する方法と、コンバージョンアクション単位で個別に設定する方法があります。特定のコンバージョンアクションだけ除外したい場合は、アクション単位でオプトアウトできる仕様です。

3. 変更点②:Data Manager APIへの一本化と「2026年6月15日」の線引き

2つ目の変更は、開発者・システム連携側に関わるものです。Googleは2025年12月にData Manager APIの提供を開始しました。Google広告・Googleマーケティングプラットフォーム・Googleアナリティクスをまたぐ統一スキーマで顧客データやコンバージョンデータを送信できる、新しい受け口です。

そして2026年5月15日、Google Ads開発者ブログで次の発表がありました。2026年6月15日以降、Google Ads APIはオフラインコンバージョンインポート(リード向け拡張コンバージョンを含む)の新規利用を受け付けない、という内容です。具体的には、2025年12月〜2026年5月の間に利用実績のない開発者トークンからConversionUploadServiceのアップロードを行うと、許可リスト外を示すエラーが返る仕様になりました。

ポイントは「新規」と「既存」の扱いの違いです。すでに利用実績のある連携は当面継続できるとされていますが、恒久的に約束された位置づけではなく、GoogleはData Manager APIへの移行を推奨しています。なお、この流れは単発ではなく、2026年4月1日にはカスタマーマッチのリストアップロードもGoogle Ads API経由の受付を終了しており、顧客データ系のアップロードをData Manager APIへ寄せていく一連の移行と見られています。

紛らわしいのですが、「データマネージャー」には2つの顔があります。1つは管理画面上のデータマネージャーで、CRMやスプレッドシートなどのデータソースを画面操作で接続できる機能。もう1つが今回の移行先であるData Manager APIで、システム間連携のための開発者向けの受け口です。開発リソースがない場合でも、管理画面のデータマネージャーやコネクタ経由で接続できるケースがあるため、「API移行=開発が要る」と決めつける前に選択肢を確認する価値があります。

影響を受けやすいのは、次のようなケースです。

  • CRM(Salesforce、HubSpot、kintoneなど)からオフラインコンバージョンを自動アップロードしている
  • 代理店やベンダーの自社ツールがGoogle Ads API経由でリード向け拡張コンバージョンを送信している
  • 社内で開発したスクリプトが定期的にコンバージョンデータを上げている

逆に、タグだけで完結しているウェブ向けの設定や、管理画面から手動でアップロードしている場合は、今回のAPI移行の直接の影響は小さいと考えられます。まずは「自社のコンバージョンデータを、誰が・どの経路でGoogleに送っているか」の棚卸しが出発点です。

4. 自社アカウントで確認したい設定チェックリスト

(1)管理画面:設定と規約同意の状態

「目標」→「設定」から、拡張コンバージョンが有効になっているか、データ処理規約への同意が済んでいるかを確認します。統合後は設定画面の見た目が変わっているため、「以前オンにしたはず」の記憶ではなく現物を見るのが確実です。診断ステータス(送信されたデータの状況)もあわせて確認しましょう。

(2)タグ側:データが実際に取れているか

拡張コンバージョンは、コンバージョンページでメールアドレス等を取得できて初めて機能します。フォーム改修でCSSセレクタや変数名が変わり、タグが空データを送り続けていた、という事例は珍しくありません。GTMのプレビューやタグ診断で、実際にハッシュ化データが送信されているかを見ます。

(3)API連携:移行の主体を明確にする

CRMや計測ツール経由でアップロードしている場合は、そのベンダーにData Manager API対応の予定を確認します。自社開発のスクリプトなら、開発担当と移行スケジュールを握る必要があります。「どこかが対応してくれているはず」が一番危険で、連携の持ち主が曖昧なアカウントほど、こうした仕様変更で計測が静かに止まります。アカウント全体の点検手順はアカウント診断のやり方も参考にしてください。

なお、リード向けの拡張コンバージョンは「設定が正しいか」と同じくらい「どのリードにどんな価値を渡すか」の設計が成果を左右します。この価値設計の話はオフラインコンバージョンで作るリードの質の記事で詳しく扱っているので、本記事とセットでどうぞ。

5. 実際にあった、もったいない例

あるBtoB企業(広告月予算約200万円)は、数年前に開発会社へ依頼して、CRMからGoogle Ads API経由でリード向け拡張コンバージョンを送る仕組みを作っていました。商談化したリードだけをコンバージョンとして返す、教科書通りの良い構成です。ところが担当者の交代を経て、この連携の「持ち主」が社内で誰なのか分からなくなっていました。開発会社との保守契約はすでに終了。2026年6月の仕様変更のニュースを見た新しい担当者が慌てて調査し、既存連携として当面は動き続けるものの、Data Manager APIへの移行を誰も計画していないことが判明した、という状況でした。

もう1つ多いのが、統合で設定自体は自動移行されたものの、タグ側でメールアドレスが取得できておらず、送信率が低いまま放置されているケースです。管理画面上は「有効」と表示されるため、一見問題なく見えます。しかし中身のデータが届いていなければ、スマート入札の学習材料は増えません。「オンになっている」と「機能している」は別物で、月に一度は診断ステータスまで見る習慣が、こうした静かな機能不全を防ぐと言われます。

※ 自分のアカウントの場合はどうか気になる方へ ― 実際の診断レポートのサンプル(無料)を用意しています。

よくある質問

Q. 既存の拡張コンバージョン設定は、何もしないと止まってしまいますか?

A. 多くの場合、止まりません。データ処理規約に同意済みの既存設定は自動的に統合後の仕組みへ移行されると案内されており、タグ経由の運用であれば基本的にそのまま動きます。ただし、Google Ads API経由でオフラインコンバージョンやリード向け拡張コンバージョンを送っている場合は、既存連携でも将来的にData Manager APIへの移行が求められる見込みのため、連携を管理しているベンダーや開発担当に対応予定を確認しておくことをおすすめします。

Q. Data Manager APIへの移行には自社開発が必要ですか?

A. ケースによります。CRMや計測ツールなど外部サービス経由でアップロードしている場合は、サービス提供側が対応するのが一般的なので、まずベンダーに確認してください。自社開発スクリプトで送信している場合は、Data Manager APIへの改修が必要になります。一方、管理画面からの手動アップロードやタグのみで完結している運用であれば、開発を伴う対応は不要な場合が多いと考えられます。

この記事の執筆者:アドサプリ運営チーム(運営:ライムクロス株式会社)。現役の広告運用者が、Google広告・リスティング広告の実務で得た知見をもとに執筆しています。

無料サンプル

実際の診断カルテ(サンプルPDF・一部抜粋)をその場でダウンロードいただけます。

サンプルPDFをもらう
無料サンプル

実際のカルテ(サンプル)をその場でダウンロード

ご入力後、その場でサンプル(PDF・一部抜粋)をダウンロードできます。まず中身を見たい方向けです。