Microsoft CAPI実装ガイド｜UETだけでは欠けるCVをサーバー送信で補う設計手順
Microsoft広告の管理画面に並ぶコンバージョン数が、社内のCRMや受注管理に残っている件数より明らかに少ない。この差はUETタグの設置ミスだけが原因ではなく、ブラウザ側の制限で送信そのものが届いていないケースが相当数を占めます。同じ現象はGoogle広告やMeta広告でも起きていて、各媒体はサーバーから直接イベントを送るAPIを用意することで対処してきました。Microsoft AdvertisingにもConversions API（CAPI）という同じ役割の仕組みがあり、2026年8月に公式の実装ドキュメントが公開されています。
ただし日本語の情報は追いついていません。国内で上位に表示されるコンバージョンAPIの解説記事はMeta広告を中心に書かれており、Microsoft広告については「拡張コンバージョンのみ対応」「コンバージョンAPIは非対応」と書かれたまま更新されていないものが残っています。実装を検討する担当者が最初に読む記事が古い情報のままだと、そもそも選択肢に入らないまま計測欠損を放置することになります。
この記事では、Microsoft CAPIが何を補い、何を補わないのかを欠損パターンごとに切り分けたうえで、送信するイベントの設計、重複排除の考え方、識別子の受け渡し、検証と運用までを実装の順序どおりに整理します。仕様に関する記述は、Microsoft Learnで公開されている公式ドキュメント（2026年8月更新時点）に準拠しています。
この記事の要点
- Microsoft CAPIはUETタグの置き換えではなく併用が前提で、両方から同じイベントを送りながら重複を排除する構成になる
- 重複排除はUETとCAPIで同じUETタグID・eventId・eventNameを揃えることで成立し、採番ルールを実装前に決める必要がある
- ブラウザの外で起きる商談・受注・電話といった成果も同じ接続に集約でき、オフラインCVインポートと別建てにしなくてよい
- リマーケティングを使うならクライアント側のID Syncが必須で、サーバー送信だけではオーディエンスが育たない
- 送れるイベントは直近7日以内のタイムスタンプに限られ、1リクエストあたり1,000件が上限になる
Microsoft CAPIとは、UETのイベントを自社サーバーから直接送る仕組み
Microsoft CAPI（Conversions API）とは、コンバージョンや顧客接点のイベントを、ブラウザを経由せずに広告主のサーバーからMicrosoft Advertisingへ直接送信するための仕組みです。送信先はUET（Universal Event Tracking）と同じ計測基盤で、ウェブサイト上のイベントもCRMのイベントもオフラインの成約も、ひとつの接続にまとめて流せる設計になっています。
従来のMicrosoft広告の計測は、サイトに設置したUETタグのJavaScriptがブラウザ上で発火し、そこからMicrosoftのサーバーへイベントを送る形が基本でした。この経路はブラウザの状態に依存するため、Cookie制限や広告ブロッカー、JavaScriptの実行失敗といった要因がそのまま計測欠損になります。CAPIは同じイベントを広告主のサーバー側から送るバイパス経路を用意することで、ブラウザに依存しない送信ルートを確保します。
Microsoftが公式に挙げているCAPIの利用目的は、計測精度の向上、オンライン・オフライン・CRM・アプリのイベントを単一の接続で送れること、アトリビューションのカバレッジ拡大、動的リマーケティング向けのオーディエンス生成、そしてブラウザ依存の計測から離れることです。単なる欠損対策の道具ではなく、計測基盤そのものをサーバー側へ寄せるための入口として位置づけられています。
UET JavaScriptの置き換えではなく、併用が公式の推奨構成
公式ドキュメントは、可能な限りUETと併用することを推奨しています。UETはブラウザ上の行動とページの文脈を取得でき、CAPIはUETが発火したあとに起きるイベントや、ブラウザからは見えない詳細をサーバー側から送る役割を担うためです。どちらか一方に寄せると、取得できる情報が偏ります。
実務的には、UETタグをそのまま残したうえでCAPIを追加する構成が標準になります。JavaScriptがどうしても使えない環境ではCAPI単独の実装も可能ですが、その場合はページの文脈情報やブラウザコンテキストを自前で組み立てて送る必要があり、実装コストが跳ね上がります。まずUETを正しく動かし、そのうえでCAPIを重ねるという順序を崩さないことが、導入を失敗させないための前提条件です。
併用すると同じコンバージョンが二重に届くことになりますが、これは仕様として想定された状態です。重複排除の仕組みが用意されているため、両方から送ること自体は問題になりません。むしろ片方だけに寄せてしまうと、UETが取れる情報とCAPIが取れる情報の両方を失うことになります。
実装の規模感としては、UETタグの設置が数十分で終わるのに対し、CAPIはサーバー側の開発が前提になります。公開されている仕様も、エンドポイントの呼び出し方だけでなく、識別子の準備、同意の扱い、検証と監視までを含んだ内容です。ブラウザにタグを貼るのと同じ感覚で着手すると、確実に工数を見誤ります。
提供状況はパイロット段階で、アカウント単位の有効化が要る
2026年8月にMicrosoft Learn上で実装ドキュメントが公開されましたが、機能自体はまだすべてのアカウントに開放されていません。公式ヘルプにも、この機能をまだ利用できないアカウントがある旨の注記が置かれています。利用にはMicrosoft Advertisingの担当者またはサポート経由での有効化が必要になるため、実装計画を立てる前にアカウントの提供状況を確認しておく必要があります。
この提供状況の遅れは、日本語の解説記事が古いままになっている理由でもあります。国内の計測ベンダーが公開している記事の中には、Microsoft広告はコンバージョンAPI非対応と明記したまま更新されていないものが残っています。ハッシュ化した顧客データで計測を補う拡張コンバージョンと、サーバーからイベントを送るCAPIは別の機能なので、社内で検討する際は両者を混同しないように整理してから議論すると話が早くなります。
提供が限定されている段階だからこそ、先に社内の準備を進めておく意味があります。識別子の棚卸し、同意取得の設計、CRM側のデータ整備は、いずれも広告媒体の都合とは独立して進められる作業です。有効化されてから着手すると、そこからさらに数か月かかることになります。
UETだけで欠けるCVは、ブラウザ・時間・場所の三方向から生まれる
UETだけでは取り切れないコンバージョンは、大きく三つの方向から発生します。ブラウザ側の制限でタグが動かない場合、クリックから時間が経ってから成果が確定する場合、そして成果がブラウザの外で起きる場合です。原因も対処法も異なるため、まとめて「計測漏れ」として扱うと打ち手を間違えます。
ブラウザ側の制限で消えるコンバージョン
件数として最も多いのがこの類型です。ITPをはじめとするトラッキング防止機能、サードパーティCookieの制限、広告ブロッカー、企業ネットワークのフィルタリング、JavaScriptエラーによる発火失敗が該当します。UETタグが正しく設置されていても、ユーザーの環境側で実行が止まればイベントは一件も届きません。
この類型はCAPIで最も素直に埋まります。サーバー側の処理としてイベントを送るため、ブラウザの状態に一切依存しないからです。ただし埋まるのは「送信の到達」であって、「誰のコンバージョンか」の紐付けは別の問題として残ります。msclkidや識別子を渡せていなければ、届いたイベントは広告クリックに結びつかないまま終わります。
UETタグ自体の不具合と混同されやすい領域でもあります。発火不良・重複計測・コンバージョン未反映といった症状は、CAPIを入れる前にUET側で潰しておかないと、サーバー送信を追加したときに原因の切り分けが一段難しくなります。
どの程度の割合で欠けるかは、業種と訪問者の環境によって変わるため、一律の数字で語れる領域ではありません。Safariの比率が高いBtoCのサイトと、社内ネットワークからのアクセスが多いBtoBのサイトでは、欠損の出方がまったく異なります。自社の実測値で判断するのが唯一の正解です。
クリックから離れた時間に確定するコンバージョン
BtoBの商材やリードジェネレーション型の事業では、フォーム送信の時点ではまだ成果と呼べません。商談化、見積提出、受注といった実際に売上につながる地点は、クリックから数週間から数か月後に訪れます。この間の情報はブラウザには一切残っていないため、UETでは原理的に取得できません。
CAPIはこの類型にも対応します。CRMや受注管理システムに記録された商談化や受注のイベントを、保存しておいたmsclkidと一緒に送れば、広告クリックに紐づいた成果として計上できます。従来はオフラインコンバージョンインポートという別の仕組みで扱っていた領域が、同じ接続に統合されるのがCAPIの実務的な価値です。
ただし送信できるイベントのタイムスタンプには制限があります。eventTimeは直近7日以内でなければ検証エラーになるため、受注が確定してから7日を超えて放置したデータは送れません。CRM側から日次でイベントを流す運用を、実装の段階で組み込んでおく必要があります。
媒体をまたいでオフライン成果を扱う設計は、以下の記事で整理しています。
ブラウザの外で起きるコンバージョン
電話での問い合わせ、実店舗への来店、アプリ内の課金、営業担当が直接受けた相談は、いずれもウェブサイト上のイベントとしては残りません。これらはUETの守備範囲の外にあり、CAPIを入れれば自動的に取れるようになるわけでもありません。自社側で「どのクリックに紐づく成果か」を判別できる状態を作って、初めて送信できます。
つまりCAPIは万能の欠損補填装置ではなく、自社が持っているデータを広告側へ渡すための配管です。渡せるデータを持っていない領域は、実装しても埋まりません。導入前に、どの成果地点のデータが社内のどのシステムに、どの識別子と一緒に残っているのかを棚卸ししておくことが、実質的な第一歩になります。
欠損量を先に見積もってから実装に入る
実装に着手する前にやっておきたいのが、欠損量の見積もりです。どれだけ取りこぼしているかがわからないまま開発工数を投じると、効果検証の基準を持てません。最も簡単な方法は、Microsoft広告の管理画面のコンバージョン数と、自社のフォーム送信ログや注文データのうちmsclkidが付いている件数を突き合わせることです。
msclkidを保存していない場合は、ランディングページのURLパラメータを一定期間ログに残す仕掛けを先に入れます。広告経由の着地件数と、そこから発生した成果件数の実数がわかれば、管理画面の数字との差がそのまま欠損の目安になります。差が一割程度なら実装の優先度は下がり、三割を超えるようであれば着手する根拠が立ちます。
この見積もりは、実装後の効果検証にもそのまま使えます。導入の前後で管理画面のコンバージョン数がどう変わったかを見るとき、比較の基準になるのは自社側の実数です。媒体側の数字だけを見て増えた減ったを議論しないための土台として、先に自社の実数を握っておきます。
| 欠損の起き方 | 主な原因 | CAPIでの埋まり方 | 追加で必要になるもの |
|---|---|---|---|
| タグが発火しない | トラッキング防止機能・広告ブロッカー・JSエラー | ほぼ埋まる | msclkidの保存 |
| 発火はするが紐付かない | Cookie寿命・クロスデバイス | 部分的に埋まる | ハッシュ化したメールと電話番号 |
| 成果確定が遅い | 商談・受注までのリードタイム | 埋まる | CRMからの日次送信と7日以内の送信 |
| ブラウザ外の成果 | 電話・来店・アプリ内課金 | 自社データ次第 | 成果とクリックを紐づける仕組み |
| ビュースルーの取りこぼし | クリックを伴わない接触 | ID Syncが前提 | クライアント側のID Syncピクセル |
自社でどの類型の欠損が起きているのか切り分けがつかない場合は、ハーマンドットの無料アカウント診断で実データから確認するところから始められます。
送信するイベントは、ページロードとカスタムの二層で組み立てる
CAPIで送るイベントは、ページロードイベントとカスタムイベントの二種類です。ページロードはページビューやシングルページアプリケーションの画面遷移ごとに一件、カスタムは購入完了やフォーム送信といった具体的な行動ごとに送ります。この二層構造を理解しないまま実装に入ると、コンバージョン目標が反応しない、収益額が入らないといったつまずき方をします。
ページロードイベントが担う役割
ページロードイベントは、ページのURL・リファラー・ページタイトル・キーワードといった文脈情報を運びます。Microsoft広告側で「特定のURLに到達したらコンバージョン」という到達ベースの目標を使っている場合、この情報がないと目標が発火しません。eventSourceUrlはページロードイベントでは必須項目として扱われます。
もうひとつの役割がpageLoadIdです。v4形式のUUIDで採番し、同じページで発生したカスタムイベントに同じ値を持たせることで、行動とページ文脈が結びつきます。カスタムイベントだけを送っている実装では、そのイベントがどのページで起きたのかを媒体側が判断できません。
シングルページアプリケーションの場合は、画面遷移のたびにページロードイベントを送る必要があります。ブラウザのURLは変わっていても実際のページ読み込みは発生していないため、フレームワーク側の遷移イベントを拾って明示的に送信する実装が要ります。ここを省くと、到達ベースの目標が動かないままになります。
カスタムイベントに載せる値と商品情報
カスタムイベントは、eventName・eventCategory・eventLabel・eventValueといった、既存のUETのカスタムコンバージョン目標と同じ考え方のパラメータで構成します。Microsoft広告の管理画面で作ってある目標の条件に合致する値を送らなければ、イベントが届いてもコンバージョンとしては計上されません。
売上金額を渡す場合はvalueとcurrencyを使います。ここに落とし穴があり、ページロードイベントには収益額を直接載せられません。到達ベースの目標に変動収益を紐づけたい場合は、収益額だけを持つカスタムイベントを別途送り、pageLoadIdでページロードイベントと結びつける必要があります。
ECサイトであれば、itemIds・pageType・ecommTotalValue・itemsといった小売向けのパラメータも送れます。商品IDはMicrosoft Merchant Centerへ送っているフィードのidまたはitem_group_idと一致している必要があり、ここがずれていると動的リマーケティングの商品出し分けが機能しません。
既存のUET実装がある場合は、そこで送っているイベント名とパラメータを先に棚卸しします。CAPI側だけで新しい命名を始めてしまうと、重複排除が効かないうえにレポートも分断されます。既存実装に合わせるのが原則で、命名を見直したい場合はUETとCAPIを同時に切り替えます。
| フィールド | 階層 | 必須の度合い | 実務上の注意 |
|---|---|---|---|
| eventType | イベント | 必須 | pageLoad か custom のいずれか |
| eventTime | イベント | 必須 | UNIX秒のUTC。直近7日以内でないと弾かれる |
| eventId | イベント | 重複排除に必須 | UET側と同じ値を渡す |
| eventName | イベント | 重複排除に必須 | UET側のイベントアクションと揃える |
| eventSourceUrl | イベント | ページロードで必須 | 到達ベースの目標で使われる |
| userData | オブジェクト | 必須 | 識別子を最低ひとつ含める |
| msclkid | userData | 強く推奨 | UUID形式。アトリビューションの主軸 |
| adStorageConsent | イベント | 任意 | Gが許諾、Dが拒否。既定は許諾扱い |
実装に入る前に社内で確定させておく項目
- 送信対象のイベント一覧と、Microsoft広告側のコンバージョン目標との対応表
- eventIdの採番元となるシステムと、その値がリトライ後も変わらないことの確認
- msclkidをどのストレージに、どの保存期間で持たせるか
- ハッシュ化して送る識別子の範囲と、プライバシーポリシー上の記載
- 検証を誰が実施し、どのログを残すか
重複排除はeventIdの採番ルールを決めた時点でほぼ決まる
重複排除は、UETとCAPIの両方から同じイベントを送るときに、同じUETタグID・同じeventId・同じeventNameを渡すことで成立します。仕組みとしてはこれだけで、特別な設定画面もオプションもありません。逆に言えば、この三つのうちひとつでもずれていると、同じコンバージョンが二重に計上されます。
UET側では、JavaScriptでイベントを送信する際にevent_idパラメータを付けます。CAPI側では同じ値をeventIdとして送ります。両者が突き合わされ、同一のユーザー行動として一件に統合される流れです。設定作業というより、採番の設計そのものが重複排除の実装になります。
同じ成果にひとつのIDを振る設計
実装で難しいのはIDの生成そのものではなく、「どの単位でIDを振るか」の定義です。購入であれば注文番号、フォーム送信であればリード登録時に採番したレコードIDのように、業務システム側で一意に決まる値を起点にするのが最も崩れにくい設計になります。ランダムなUUIDをブラウザ側で生成してしまうと、サーバー側から同じ値を再現できません。
ブラウザ側で採番せざるを得ない場合は、生成した値をサーバーへ渡してから両経路で使う流れにします。順序としては、サーバー側でIDを確定させ、その値をUETのevent_idとCAPIのeventIdの両方へ配る形が安全です。フロントとバックエンドのどちらが採番の責任を持つかを先に決めておくと、後からの手戻りがなくなります。
eventNameも揃える必要があります。UETのイベントアクションとCAPIのeventNameが違う文字列だと、媒体側は別のイベントとして扱います。命名は英小文字とアンダースコアで統一するなど、社内のルールを先に決めてドキュメントに残しておくと事故が減ります。
同じ購入に対して複数のイベントを送る設計にしている場合は、イベントごとにIDを分けます。購入完了とカート追加が同じIDだと、別の行動が同一視される可能性があります。IDは同じ成果を指す送信同士で一致させるためのものであり、イベント種別を越えて共有するものではありません。
送信タイミングがずれる場合の扱い
UETとCAPIで同じイベントを送る場合、両者の到達に時間差が生じることがあります。ブラウザからの送信は即時、サーバーからの送信はバッチ処理で数分から数時間後になる、といった構成です。この時間差自体は許容されますが、片方が届かないまま長時間が経過すると、重複排除の判定に乗らないリスクが残ります。
実務上は、リアルタイム送信を基本にして、バッチはあくまで再送や補完の手段として位置づけるのが安全です。公式ドキュメントもリアルタイムでの送信を推奨しており、レポートや最適化、そしてトラブル対応の遅延を抑えられます。夜間の一括送信だけに頼る設計は、切り分けが必要になったときに検証しづらくなります。
リトライとバッチ再送で崩れないIDにする
サーバー間の通信では、タイムアウトやネットワークエラーによる再送が必ず発生します。このときIDを毎回生成し直すと、同じコンバージョンが再送のたびに新しいイベントとして扱われ、そのまま重複計上につながります。公式ドキュメントも、リトライの際は同じeventIdを保持するよう明記しています。
バッチ送信でも同じ考え方です。検証エラーで一部のイベントが弾かれた場合、修正して再送するときに元のIDをそのまま使えるよう、送信キューにIDを保持しておく設計にします。再送を前提としたID設計になっているかが、運用に入ってからの数字の信頼性を分けます。
Meta広告のコンバージョンAPIを既に運用しているなら、イベントIDによる重複排除の考え方はほぼ共通です。実装済みの設計思想をそのまま持ち込めるので、Meta側の運用ノウハウがある組織はここでの立ち上がりが速くなります。
マッチング精度を決めるのは、msclkidと識別子の受け渡し設計
CAPIで送ったイベントが広告クリックに紐づくかどうかは、userDataに何を入れられるかでほぼ決まります。イベントが正常に受理されても、識別子が薄ければコンバージョンとして計上されないまま消えます。送っているのに数字が増えないという相談の大半は、この層の設計不足です。
msclkidの取得と保存の設計
msclkidはMicrosoftのクリックIDで、アカウントで自動タグ設定を有効にしていると、広告クリック後のランディングページURLにクエリパラメータとして付与されます。CAPIを使う場合、この値を捕まえて保存し、そのユーザーの以降のイベントに毎回同梱するのは広告主側の責任になります。
保存先はファーストパーティCookie、ローカルストレージ、サーバー側のストアのいずれでも構いません。公式が推奨する保持期間は90日で、新しいmsclkidを取得したら古い値は上書きします。ユーザーが複数回クリックしている場合、最新のものだけを保持すれば足ります。
ここで見落とされやすいのが自動タグ設定です。無効になっているとmsclkid自体が付与されないため、CAPIの実装がいくら正しくてもアトリビューションが成立しません。実装に着手する前に、アカウント側の設定から確認しておきます。
保存する値は最新のひとつで足りますが、いつ取得したかも一緒に持っておくと運用が楽になります。成果が確定したときに、そのmsclkidがまだ有効期間内かを判断できるためです。保持期間を過ぎた値を送っても紐付かないので、送信対象から外す判定を実装に含めておきます。
ハッシュ化したメールと電話番号の正規化手順
メールアドレスと電話番号はSHA-256でハッシュ化して送ります。ハッシュ化の前に正規化が必要で、ここを間違えると値が一致せずマッチしません。メールアドレスは前後の空白を除去し、ユーザー名部分のドットを削除し、プラス以降のエイリアスを取り除き、全体を小文字に変換してからハッシュ化します。
電話番号は国番号付きのE.164形式に正規化してからハッシュ化します。日本の番号であれば先頭のゼロを外して国番号を付ける形です。出力はいずれも小文字の16進数文字列にします。形式が不正な場合、そのフィールドだけが警告として除去され、イベント自体は正常として処理されます。受理されていても識別子が落ちている可能性があるため、レスポンスの警告内容まで確認する運用が必要です。
ハッシュ化の処理はサーバー側で行い、ブラウザから生の値を送らない構成にします。フロントエンドでハッシュ化する実装も技術的には可能ですが、正規化のルールが端末や実装ごとにずれる余地が残ります。正規化とハッシュ化を一箇所に集約しておくほうが、値の一致率を保ちやすくなります。
同意状態はadStorageConsentで明示する
CAPIは同意シグナルに対応しており、adStorageConsentにGまたはDを入れて送れます。既定では全イベントが許諾済みとして処理されるため、同意管理プラットフォームで拒否を選んだユーザーのイベントを、同意状態を付けずに送ると意図しない扱いになります。拒否として送られたイベントは、コンバージョンのアトリビューションにもリターゲティングにも使われません。
ハッシュ化しているとはいえ個人情報を扱う以上、プライバシーポリシーへの記載と取得同意の設計は、実装と同じタイミングで進める必要があります。法務確認を後回しにすると、実装が完了してから送信を止めることになりかねません。計測要件と同意要件はセットで決めるのが実務上の鉄則です。
| 識別子 | 用途 | 形式 | 取得元 |
|---|---|---|---|
| msclkid | 広告クリックとの紐付け | UUID | ランディングページのURLパラメータ |
| anonymousId | 訪問者の識別とID Syncとの突合 | v1形式のUUID推奨 | 自社で採番 |
| externalId | ログイン済みユーザーの識別 | 32バイトの16進文字列推奨 | 自社で匿名化した値 |
| em | マッチング精度の底上げ | SHA-256の小文字16進 | 正規化後のメールアドレス |
| ph | マッチング精度の底上げ | SHA-256の小文字16進 | E.164形式の電話番号 |
| clientIpAddress・clientUserAgent | ユーザー行動との突合 | 文字列 | リクエストヘッダ |
同意管理と計測をどう両立させるかは、以下の記事で詳しく扱っています。
ID Syncを省くと、リマーケティングとビュースルーが動かない
ID Syncは、広告主側の訪問者IDとMicrosoft側のIDを結びつけるための仕組みで、動的リマーケティングを使うなら必須です。CAPIの解説記事でほとんど触れられない一方、実装を落とすとオーディエンスが育たず、ビュースルーのアトリビューションも成立しません。Meta広告のCAPIの知識だけで設計に入ると、最も抜けやすいのがこの部分です。
ID Syncはクライアント側で実行する
公式ドキュメントは、ID Syncをサーバー側の呼び出しではなくクライアント側のピクセルとして実装するよう明記しています。ブラウザの文脈をMicrosoft側が読み取る必要があるためで、サーバーから同じリクエストを投げても意味を持ちません。CAPIで計測をサーバーへ寄せる設計であっても、この一点だけはブラウザ側に残ります。
必須のパラメータは、Microsoftが割り当てた顧客IDを含むRed3と、ゲストユーザーの匿名IDであるVIDの二つです。ログイン済みのユーザーがいる場合は、匿名化したUIDを任意で追加できます。発火場所はできる限り多くのページ、少なくともセッションごとに一度、可能であれば最初のページビューです。サイト全体に置くのが基本で、コンバージョンページだけに置く実装では役に立ちません。
anonymousIdとVIDを一致させる
ID Syncで送るVIDと、CAPIのイベントに入れるanonymousIdは同じ値である必要があります。ここがずれていると、サーバーから送ったイベントとブラウザ側で同期したIDが結びつかず、オーディエンス生成もビュースルーの計測も成り立ちません。二つの実装を別々の担当者が進める場合、値の受け渡し方法を最初に合意しておきます。
もうひとつ混同されやすいのが、Red3に入れる顧客IDとUETタグIDの違いです。ひとつの顧客アカウントに複数のUETタグが存在しうるため、両者は別の値になります。複数の顧客IDを持つアカウントでは主となる値を使い、判断に迷う場合はMicrosoft側の担当者に確認するのが確実です。
送る値そのものにも注意が必要です。生のユーザーIDをそのまま送ってはいけないという明確な注記があるため、新しくUUIDを生成するか、ハッシュ化した値を使います。既存の会員IDをそのまま流用する実装は、結果として個人情報の外部送信になり得るので避けます。
ID Syncの実装が漏れやすいのは、CAPIをサーバー側だけの話として捉えてしまうからです。計測をサーバーへ寄せるという文脈で議論が進むと、ブラウザ側に残す必要のあるピクセルの存在が抜け落ちます。要件定義の段階で、サーバー実装とクライアント実装の二本立てであることを明示しておけば、この抜けは防げます。
サーバー送信だけでは成立しない項目
- 動的リマーケティング向けのオーディエンス生成はID Syncが前提になる
- ビュースルーのアトリビューションもID Syncを通じたユーザー識別に依存する
- ID Syncはサーバー側からではなくクライアント側のピクセルとして実装する
- VIDとanonymousIdが一致していないと、両方の実装が無駄になる
ここまでの前提を社内のエンジニアと共有できているか不安が残る場合は、要件定義の段階で計測設計まで含めた相談をしておくと、手戻りの量が変わります。
送信経路は、直接実装・パートナー連携・タグマネージャーから選ぶ
送信経路の選択肢は三つです。自社サーバーから直接APIを呼ぶ方法、CDPや計測ベンダーのコネクタを使う方法、そしてサーバーサイドのタグマネージャーを経由する方法。どれを選ぶかは、開発リソースの有無と、コンバージョンデータがどのシステムに存在するかで決まります。
自社サーバーから直接送る
バックエンドの注文処理やリード登録処理から、そのままエンドポイントを呼ぶ構成です。送信先はcapi.uet.microsoft.comのイベント受け口で、パスにUETタグIDを含めます。認証はAuthorizationヘッダにBearerスキームでトークンを載せる形で、トークンはMicrosoft Advertisingの管理画面のUETセクション、またはCampaign Management API経由で取得できます。
この方式は自由度が最も高く、独自のデータモデルを持つ事業や、複雑なイベント定義が必要な場合に向きます。一方で、エラーハンドリング、リトライ、ログ保存、監視まで自前で作る必要があるため、継続的に面倒を見るエンジニアがいることが前提になります。作り切りで放置すると、サイト改修のたびに静かに壊れます。
トークンの管理も設計に含めます。UETタグごとに発行される値なので、複数のタグを扱う場合は対応関係を台帳として残しておきます。タグを共有されている立場のアカウントでは、既存トークンの取得はできても新規発行ができないため、権限の所在を先に確認しておくと待ち時間が減ります。
パートナーのコネクタを使う
すでにCDPや計測基盤を導入している場合、そのコネクタ経由で送るのが最短です。公式ドキュメントには、Commanders Act、MetaRouter、Segment、Stape、Tealium、Invoca、Freshpaintといったパートナーが掲載されています。イベントのマッピングやフォーマット整形はパートナー側が担当するため、開発工数を大きく圧縮できます。
ただしコネクタを使っても、アカウント、UETタグ、トークン、コンバージョン目標、同意の扱い、そして識別子の準備は広告主側の仕事として残ります。ツールを入れれば終わると考えていると、識別子が空のイベントを大量に送ることになり、費用だけがかかる状態になります。
サーバーサイドタグマネージャーを経由する
ウェブ上のコンバージョンが中心で、開発工数を抑えたい場合はこの経路が現実的です。サーバーサイドGTMでチェックアウトや購入のイベントを受け、そこからCAPIへルーティングします。すでにGoogle広告やMeta広告のサーバー送信をサーバーサイドGTMで運用しているなら、追加の学習コストはほとんどかかりません。
この構成の利点は、媒体ごとに個別のサーバー実装を作らずに済むことです。反面、タグマネージャー自体の運用コストとホスティング費用が継続的に発生するため、コンバージョン件数が少ない事業では費用対効果が合わないこともあります。導入判断は媒体単体ではなく、全媒体の合計で考えるのが妥当です。
複数媒体へ同時に送る構成では、媒体ごとの仕様差を吸収する層をどこに置くかが論点になります。イベント名の対応表、識別子の正規化ルール、同意状態の受け渡しを一箇所にまとめておかないと、媒体が増えるたびに設定が分岐して保守できなくなります。
| 経路 | 向いているケース | 初期工数 | 運用上の負担 |
|---|---|---|---|
| 直接実装 | 独自のデータモデル・オフライン成果が多い | 大きい | 監視と再送を自社で設計する |
| パートナー連携 | CDPや計測基盤をすでに運用している | 中程度 | 識別子と同意の管理は自社に残る |
| サーバーサイドタグマネージャー | ウェブCVが中心・複数媒体へ同時送信したい | 中程度 | ホスティング費用が継続的に発生 |
サーバーサイドGTMを軸にした計測設計は、以下の記事で詳しく解説しています。
検証は認証エラーと検証エラーの切り分けから始める
実装後の検証は、レスポンスの意味を正しく切り分けるところから始めます。認証で弾かれているのか、フィールドの検証で弾かれているのか、あるいは受理されているが一部のフィールドが警告として除去されているのか。この三段階の区別がついていないと、送っているのに増えないという状態から抜け出せません。
認証エラーと検証エラーの読み分け
認証エラーが返る場合、原因はトークンが欠けている、値が誤っている、あるいはリクエストパスのUETタグIDとトークンの対応が取れていないかのいずれかです。Authorizationヘッダの形式、管理画面からコピーしたトークンのアカウント、パスのタグIDという三点を確認するまで再送しないのが鉄則になります。
検証エラーの場合、レスポンスの詳細にインデックスとプロパティ名が入ります。インデックスは送信したバッチ内での位置、プロパティ名はフィールドのパスを示すため、どのイベントのどの項目が原因かを推測せずに特定できます。弾かれた実際の値まで返る場合もあるので、ログに残しておくと再発防止に使えます。
最も見落としやすいのが警告です。リファラーURLの形式不正やハッシュ値の不正は警告として扱われ、その項目だけが除去されたうえでイベント自体は成功として処理されます。成功レスポンスだけを見て問題なしと判断すると、マッチング精度がじわじわ落ちていきます。警告のログを残し、定期的に確認する運用が必要です。
バッチ送信の挙動と再送の設計
イベントは個別にもバッチでも送れますが、レポートや最適化の遅延を減らす観点から、リアルタイム送信が推奨されています。バッチの上限は1リクエストあたり1,000件で、これを超える場合は分割します。既定では、バッチ内に一件でも検証エラーがあるとリクエスト全体が失敗し、そのバッチのイベントは一件も処理されません。
不正なイベントを飛ばして残りを処理したい場合は、continueOnValidationErrorを有効にします。この設定では、有効なイベントが一件でもあれば成功が返り、処理件数と弾かれたイベントの詳細がレスポンスに含まれます。ただし問題を見えにくくする側面もあるため、弾かれたレコードを別途監視する仕組みとセットで使うのが前提です。
再送の設計では、指数バックオフのような一般的なリトライ制御に加えて、検証エラーは再送しないという分岐を必ず入れます。ペイロードが不正なまま同じリクエストを繰り返しても結果は変わらず、ログだけが膨らみます。一時的な障害と恒久的な不正を区別できるかどうかが、運用の負荷を大きく左右します。
公開後に見るべき監視項目
運用開始後に確認するのは、受理件数の推移、警告の発生率、管理画面のコンバージョン数との差分、そしてオーディエンスの母数です。UETタグ側の数字と極端に乖離している場合は、重複排除が効きすぎているか、逆にまったく効いていない可能性を疑います。
コンバージョンが増えない場合の確認順序は、目標設定、eventNameの一致、タイムスタンプ、msclkidの有無です。オーディエンスが育たない場合はID Syncと匿名IDの一致を疑います。症状ごとに見る場所が決まっているので、切り分けの順序を運用手順として文書に残しておくと、担当者が変わっても品質が落ちません。
もうひとつ見ておきたいのが、送信元システムごとの内訳です。ウェブのイベントとCRMのイベントを同じ接続に流している場合、片方だけが止まっていても合計値では気づきにくくなります。送信元を識別する値を付けるか、送信側でイベント種別ごとの件数を記録しておくと、異常の検知が早くなります。
| 症状 | レスポンス | 主な原因 | 最初に見る場所 |
|---|---|---|---|
| 認証が通らない | 認証エラー | トークン不正・タグIDの不一致 | Authorizationヘッダとパスのタグ指定 |
| バッチ全体が処理されない | 検証エラー | 一件の不正で全体が停止 | 詳細のインデックスとプロパティ名 |
| 受理されるがCVが増えない | 成功 | 目標設定・eventName・msclkidの欠落 | コンバージョン目標の条件 |
| マッチ率が上がらない | 成功（警告あり） | ハッシュ形式の不正で項目が除去 | 警告のプロパティ名 |
| コンバージョンが二重に出る | 成功 | eventIdの不一致 | UETとCAPIの採番元 |
本番送信の前に確認するポイント
- eventTimeがUNIX秒のUTCで、直近7日以内に収まっている
- eventTypeがページロードとカスタムのいずれかになっている
- userDataに識別子が最低ひとつ入っている
- UET側のevent_idとCAPIのeventIdが同じ値になっている
- レスポンスのリクエストID・ステータス・失敗した位置をログに残している
サーバー送信を追加する前に、UETタグ側の症状を潰しておく点検手順は以下にまとめています。
導入判断は、コンバージョン件数と開発体制の二軸で考える
Microsoft CAPIを入れるべきかどうかは、月間のコンバージョン件数と、サーバー実装を維持できる体制があるかの二軸で判断します。仕組みとして優れていても、月に数件しかコンバージョンが発生しないアカウントでは、実装コストに見合う改善量になりません。判断を先送りにするより、条件を数字で決めておくほうが健全です。
先に効果が出やすい条件
効果が出やすいのは、コンバージョン件数がある程度まとまっていて、自動入札を使っているアカウントです。自動入札は学習に使えるデータの量と質に依存するため、欠損していた分の成果が戻るだけで配信の判断が変わります。逆に手動入札で運用しているアカウントでは、レポートの数字が正確になる以上の効果は出にくくなります。
BtoBのように成果確定が遅い事業も相性の良い領域です。フォーム送信だけを最適化の対象にしていると、商談にならないリードばかりが増えていきます。商談化や受注をCAPIで戻せば、入札の対象が問い合わせ件数から売上に近い指標へ移るため、同じ広告費でも取れる成果の質が変わります。
逆に、UETタグ自体が正しく動いていないアカウントは、CAPIより先にやることがあります。タグの二重設置や目標設定の誤りが残ったままサーバー送信を追加すると、数字が合わない原因が増えるだけです。UETが健全に動いていることがCAPI導入の前提だと考えておくのが安全です。
内製と外注の分かれ目
判断の分かれ目は、実装そのものよりも運用の継続性にあります。CAPIは一度作れば終わりではなく、サイト改修のたびにイベントの送信箇所を確認し、エラーと警告を監視し、媒体側の仕様変更に追随する必要があります。この体制を社内に置けるかどうかが、最大の判断材料です。
Microsoft広告は日本国内では検索シェアが限られるため、専任の担当者を置くほどのボリュームにならないアカウントも少なくありません。Google広告の運用体制の中に、計測部分だけを標準化して組み込むのが現実的な落としどころになります。媒体ごとに別々の実装方針を持つと、維持できずに形骸化します。
ハーマンドットがMicrosoft広告の運用代行を受ける際は、まずUETタグとコンバージョン目標の点検から入り、CAPIの導入可否は欠損量とアカウント規模を見てから判断しています。計測基盤を整えないまま配信改善に着手しても、判断材料そのものが歪んだままになるためです。実装だけを切り出して発注するより、計測と配信を同じ担当で見たほうが結果的に速く進みます。
費用面の変動要素は、直接実装であれば開発工数、パートナー連携であればツール利用料、サーバーサイドタグマネージャーであればホスティング費用です。いずれも初期費用より継続費用のほうが判断に効くため、年間で見たときの負担額と、取り戻せる見込みのコンバージョン数を並べて比較します。
Microsoft広告の運用代行そのものを検討している場合は、費用相場や代理店の選び方をまとめた以下の記事もあわせてご覧ください。
まとめ：Microsoft CAPIはデータを渡す配管であり、設計の順序が成果を決める
Microsoft CAPIは、UETタグでは届かなかったコンバージョンをサーバー側から送り直すための仕組みです。ブラウザの制限で消えていたイベント、時間差で確定する商談や受注、ブラウザの外で起きる成果を、同じ接続に集約できます。ただし送れるのは自社が持っているデータだけであり、識別子の設計と重複排除のルールを決めないまま実装すると、数字はかえって信用できなくなります。実装の順序としては、UETの健全性を確認してから着手し、eventIdの採番を決め、msclkidと識別子の受け渡しを固め、ID Syncを置き、最後に検証と監視を組む流れが最短です。導入判断そのものも、欠損量とコンバージョン件数を測ってから下すのが妥当です。
- UETとCAPIは併用が前提。同じUETタグID・eventId・eventNameを揃えて重複排除を成立させる
- msclkidの保存とハッシュ化識別子の正規化が、そのままマッチング精度を決める
- リマーケティングを使うならクライアント側のID Syncが必須で、サーバー送信だけでは足りない
まずは無料で広告アカウント診断を
Microsoft広告の管理画面の数字と、社内に残っている実際の成果件数がどれだけ乖離しているのか。この差を測らないまま計測の実装に着手しても、投じた工数に見合う改善が返ってくるかは判断できません。ハーマンドットでは、UETタグの発火状況、コンバージョン目標の設定、欠損が起きている地点までを実データで確認したうえで、CAPIを含めた打ち手の優先順位をご提案しています。
広告アカウント診断では、現在の配信設定と計測設定を洗い出し、どこに改善余地がどれだけ残っているかを数字で提示します。Microsoft広告だけでなく、Google広告やMeta広告を含めた全体設計での相談も可能です。実装を内製するか外注するかの判断材料が欲しい段階でも構いません。
初回相談は完全無料・所要時間30分・オンライン対応可能です。