2026.05.07

コンバージョンAPIとは?これまでの経緯と活用すべき理由

コンバージョンAPI(CAPI)って知っていますか?

「拡張コンバージョンのこと?」
「なんだか難しそうでよくわからない……」

そう思っているなら、かなり損をしているかもしれません。

実は今、広告の裏側では
売れているのに、売れていないことにされている(=コンバージョンしているのにカウントされていない)」ということが頻繁に起きています。

近年プライバシーのルールが厳しくなり、
これまで当たり前だった「だれが・いつ・どこで・何を買ったか」というトラッキング(追跡)ができなくなりつつあります。
これにより、広告のAIは「目隠し」をされたような状態になり、大なり小なりパフォーマンスがどんどん下がっています。

これを解決するのがコンバージョンAPIです。

消えていた購入データを復活させ、広告のAIの「賢さ」を取り戻すための、いわば広告の修復キットみたいなものです。

今回はコンバージョンAPIの設定ではなく、コンバージョンAPIが登場した背景や、拡張コンバージョンなどの周辺知識、導入するメリットなどについて解説したいと思います。

※ 「コンバージョンAPI」という名前について
厳密にはMetaの製品名(Conversions API)で、Googleには全く同じ名前の単一製品があるわけではありません。Google側では「Google Ads API経由の送信」などがこれに相当しますが、実務では媒体を問わず”ブラウザを介さずサーバーから送る仕組み”全般をまとめて「コンバージョンAPI」と呼ぶことが多くなっています。本記事でもこの広い意味で「コンバージョンAPI」という言葉を使います。

iPhoneユーザーの半分以上が消えてしまう?

これまでは、ユーザーがサイトをまたいでも「同じ人」だと認識できていました。

そのため、「10時に広告をクリックしたAさんが、20時に自分のサイトで商品を買った」という足跡が正確にわかったんです。

しかし今は、プライバシーを守るためにブラウザがその「足跡」を消してしまいます。

その結果、「売上は上がっているのに、どの広告が効いたのかさっぱりわからない」ということが起こり、広告媒体側のAIも「いつ誰に広告配信すればよいのかわからない…」という事態が起こっています。

消えたデータをつなぎ直す「2つの軸」

消えかけたデータの「点」を「線」でつなぎ直す対策は、よく「拡張コンバージョン」「カスタマーマッチ」「コンバージョンAPI」などの言葉でまとめて語られますが、これらは横並びの選択肢ではありません。実は次の2つの軸に分かれます。

① 「何を送るか」の軸 = クッキーの代わりに何でユーザーを特定するか
拡張コンバージョン、詳細マッチング(Meta)、カスタマーマッチなどがここに属します。ハッシュ化したメールアドレスなどを送ることで、クッキーがなくてもユーザーを紐付けようとする仕組みです。

② 「どこから送るか」の軸 = ブラウザ経由か、サーバー経由か
サーバーサイド送信(通称「コンバージョンAPI」と呼ばれているもの)がここに属します。ブラウザを介さず自社サーバーから直接媒体に送るアプローチです。

この2つは対立するものではなく、組み合わせて使うものです。「拡張コンバージョンの情報をサーバーサイドで送る(これがいわゆるコンバージョンAPI)」という構成が、現時点でのベストプラクティスになります。

なぜこの2軸が必要になったのか、これまでの経緯をたどるとよくわかります。

かつての神:サードパーティクッキー

以前は広告データのトラッキングに「サードパーティクッキー」というものが使われていました。

サードパーティクッキーとは、ユーザーが訪問したWebサイトとは別のドメインから発行されるクッキーです。

これを使うと冒頭で紹介したように、「だれが・いつ・どこで・何を買ったか」という追跡が簡単にできる、まさに神のような存在でした。

しかし、ユーザーの知らないところで個人の行動が筒抜けになる仕組みは、当然プライバシーの観点で問題視されるようになります。

GDPR※1をはじめとする各国の規制強化、Appleが2017年にSafariへ導入したITP(Intelligent Tracking Prevention)※2、それに追随するFirefox※3やBrave……という流れが一気に加速。GoogleもChromeでの段階的廃止を一時は表明し、業界全体が「脱サードパーティクッキー」へと舵を切ることになります。

 

※1 GDPR(ジーディーピーアール)
「本人の許可なく個人データを勝手に使うな!」という、ヨーロッパ生まれの超厳しいプライバシー保護ルール。これがきっかけで、世界中のネット広告の仕組みがガラリと変わることになりました。

※2 ITP(アイティーピー)
AppleがSafariに搭載した「ユーザー追跡お断り機能」。こいつが、今回の「24時間でクッキー(足跡)を消してしまう」犯人です。マーケターにとっては、計測を邪魔する「最強のガードマン」のような存在です。

※3 Firefox(ファイアフォックス) / Brave(ブレイブ)
Safariと同じく、プライバシー保護を売りにしているブラウザ。標準で広告や追跡をガチガチにブロックする機能がついている、いわば「計測泣かせの忍者ブラウザ」たちです。

 

代わりの対策:ファーストパーティクッキー

サードパーティクッキーが禁止されると、各広告媒体は「自社のドメインから発行したクッキー」として計測を継続しようとしました。

これがファーストパーティクッキーと呼ばれるものです。

しかし、これだけでは「サイトをまたいだ追跡」ができず、精度が落ちてしまいます。

カスタマーマッチ

そこで、メールアドレスなどの情報を「ハッシュ化(≒暗号化のようなもの)」して媒体に送ることで、ユーザーを特定する「カスタマーマッチ」という手法が広がりました。

これにより、「この人には広告を出す」「買った人には出さない」というターゲティングがしやすくなります。

さらなる規制:Safariの24時間制限

しかし、Apple(Safari)はさらに厳しくなりました。

JavaScript(GTMなど)で発行されたファーストパーティクッキーを「追跡用だ!」と見抜き、24時間経つと強制的に無効化するようにしたのです。

昨日広告を見た人が今日買っても、もう「別人」扱いです…

 

拡張コンバージョン / 詳細マッチング

Googleはこの欠損を補うため「拡張コンバージョン」を投入しました。

Metaでは同様の機能が「詳細マッチング」と呼ばれています。

カスタマーマッチと同様に、メールアドレスなどを送信することで、Googleアカウントなどの情報と紐付け、クッキーがなくても計測できる確率を高める仕組みです。

カスタマーマッチが『誰に配信するか』を決めるための名簿作りなのに対し、拡張コンバージョンは『どの広告で売れたか』を特定するための答え合わせです。

ここまでがすべて軸①(何を送るか)の話です。クッキーの代わりに別の手がかり(ハッシュ化メアド等)を送る、というアプローチで、ブラウザから送るのが基本になります。ただし「ブラウザから送る」という前提自体が、次の問題で崩れます。

最後の大敵:アドブロック

ブラウザの設定や「アドブロック」などのツールによって、広告タグの動作そのものが止められてしまうケースも増えています。
こうなると、いくら拡張コンバージョンを仕込んでいても、そもそも”ブラウザから送信する”という前提が崩れるため、データが届きません。

サーバーサイド送信(=コンバージョンAPI)

ここで視点が切り替わります。これまでは「何を送るか」の話でしたが、ここからは「データをどこから送るか」という”経路”の話です

ブラウザを介さず自社サーバーから直接媒体に送る——これがサーバーサイド送信で、媒体を問わず慣用的に「コンバージョンAPI」と呼ばれている仕組みです(Metaの正式名はConversions API、Googleでは「Google Ads API経由の送信」などがこれに相当)。

こうすることで、ブラウザのクッキー制限やアドブロックの影響を受けにくくなり、計測データを安定して媒体に届けることができるのです。

さらに、軸①の拡張コンバージョンをこのサーバー経由で送ることで、”中身”と”経路”の両方を強化できる、というのが今のベストプラクティスです。

 

どうやって導入する?

「よし、コンバージョンAPIをやろう!」と思っても、サイトの作り(プラットフォーム)や予算によって選択肢の幅が異なります。

たとえば、ShopifyやWordPressなどのメジャーなプラットフォームを使っているなら、標準機能や専用のプラグインを使って、比較的かんたんに導入できる場合があります。

一方で、独自にカスタマイズされたサイトや、特定のカートシステムを使っている場合は、エンジニアの手で「専用のサーバー(sGTM)」※を構築するのが最も確実な方法になります。

「スピード重視!難しい設定は丸投げしたい!」なら
⇒ プラットフォーム標準機能や、公式プラグイン、外部のマネージドサービスを利用しましょう。導入が早く、運用保守の手間もかかりません。

「自由にコントロールしたい!」なら
⇒ 自前(sGTM:サーバーサイドGTM)で構築しましょう。エンジニアの手が必要ですが、長期的なコスト効率とデータの自由度は抜群です。

※ sGTM(サーバーサイドGTM)
これまでユーザーのブラウザ上で動いていた「タグマネージャー」を、自分たちのクラウドサーバー(専用の箱)の中に引っ越しさせたもの。計測データを安全に広告媒体へ届けるための「専用の中継基地」だと思ってください。
なお、sGTMは「サーバーサイド送信を実現するための器(インフラ)」であって、コンバージョンAPIそのものではありません。sGTMはあくまで土台で、その上で各媒体のサーバーサイド送信の仕組み(MetaのConversions APIなど)を動かす、という関係です。

まとめ

広告運用のAI化がどんどん進んでおり、AIに「良質なデータ」を送信できているかがより大切なフェーズになっています。

コンバージョンAPIを活用し、より良いマーケティング活動をしていきましょう。

仲野 直也のアバター

仲野 直也

Webエンジニア。趣味は釣り。