LINEヤフー広告のコンバージョンAPI対応で計測設計はどう変わるか
LINEヤフー広告 検索広告（ショッピング）で、計測タグを使ったコンバージョン測定と、コンバージョンAPIによるサーバーサイド計測の提供が始まりました。これは配信ロジックや入札方式の変更ではなく、コンバージョンという信号をどこから受け取るかという計測基盤の更新です。影響を受けるのは、ショッピング広告を回していて、なおかつ従来版のコンバージョン測定タグをそのまま使い続けているアカウントです。まず確認すべきは、自社が従来版タグのままか、すでにビジネスマネージャーの計測タグに寄せているかという一点になります。
この更新で実務的に効いてくるのは三つです。広告アカウントごとにタグを発行して実装していた作業が減ること、ブラウザー環境の変化で落ちていたコンバージョンをサーバーサイドから補えること、そして注文単位の識別子を渡すことで重複計上を防げるようになったことです。どれも「計測の精度を上げる」という言葉でまとめられがちですが、運用者が意思決定を変えるべきポイントはもっと具体的です。
本記事は2026年9月3日時点の情報にもとづき、広告運用代行の現場から見た移行の順序、失敗しやすい設定、そして「この条件ならまだ見送ってよい」という逆張りの判断基準まで整理します。仕様の紹介ではなく、明日の運用で何を止めて何を残すかを決めるための文書として読んでください。
この記事の要点
- 対応開始は2026年8月26日、対象はLINEヤフー広告 検索広告（ショッピング）に限定される
- 計測タグは広告アカウント単位のタグ発行・実装を不要にし、ディスプレイ広告と横断した効果測定を可能にする
- コンバージョンAPIはアクセストークンを発行してサーバーから直接送る方式で、ブラウザー環境に左右されにくい
- 従来版タグと計測タグを同じページに併設すると重複計測が起きるため、transaction_idの設計が移行の成否を決める
- 従来版タグは2026年秋頃に新規作成機能の提供終了予定。計測自体の終了時期は現時点では未公表
計測タグとコンバージョンAPIの対応開始で更新されたのは配信ではなく計測基盤
今回の更新で変わったのは、コンバージョンをどう受け取るかという入口の部分です。配信面が増えたわけでも、入札アルゴリズムが差し替わったわけでもありません。LINEヤフー for Businessが公開した計測タグおよびコンバージョンAPIへの対応開始のお知らせは2026年8月18日に掲載され、実施完了に伴って2026年8月27日に更新されています。実施日は2026年8月26日（水）です。
この区別は運用の初動を左右します。配信機能の追加であれば「試して効果を見る」で済みますが、計測基盤の更新は数値の定義そのものが動くため、切り替えたその日から過去との比較可能性が揺らぎます。だからこそ、機能の良し悪しを議論する前に、いつ切り替え、どの期間を比較対象から外すかを先に決める必要があります。
対応開始の事実関係と対象範囲を先に押さえる
対象サービスはLINEヤフー広告 検索広告（ショッピング）です。ここを読み違えて「LINEヤフー広告全体が刷新された」と受け取ると、関係のないアカウントまで棚卸ししてしまい、工数だけが膨らみます。ディスプレイ広告側の計測タグとコンバージョンAPIはそれ以前から提供されており、今回はショッピング広告がそこに追いついた形と理解するのが実態に近いはずです。
公式発表で明記された主な変更点は、計測タグによるコンバージョン測定、コンバージョンAPIによるサーバーサイド送信、transaction_idを用いた重複排除と注文関連計測への対応、クロスデバイスコンバージョンの判定精度向上、そしてコンバージョン価値の小数点対応の五点です。このうち小数点対応はコンバージョン種別「ウェブ（計測タグ）」が対象で、検索広告APIへの適用は今後のバージョンで順次予定と案内されています。レポートをAPI経由で自動集計している場合は、管理画面の数値と一時的にずれる前提で運用を組んでください。
| 確認項目 | 今回の発表内容 | 運用側で決めること |
|---|---|---|
| 対象サービス | 検索広告（ショッピング） | 対象アカウントの洗い出し |
| 実施日 | 2026年8月26日 | 切り替え日と比較除外期間 |
| 計測タグ | ビジネスマネージャー発行／広告アカウント発行を指定可能 | どちらの発行元に寄せるか |
| コンバージョンAPI | アクセストークンでサーバーから直接送信 | 送信を担う開発リソースの確保 |
| 重複排除 | transaction_idに対応 | 注文番号の採番ルール |
| 従来版タグ | 2026年秋頃に新規作成機能の提供終了予定 | 撤去の順番とタイミング |
計測タグという言葉が指しているもの
計測タグとは、LINEヤフーの各サービスを横断してユーザー行動を計測するために用意された共通のトラッキングタグです。従来はコンバージョン測定タグを広告アカウントごとに発行し、それぞれサイトに実装する必要がありましたが、計測タグでは発行済みのタグを広告管理ツール上で指定するだけでコンバージョン測定に紐づけられます。
ここで押さえておきたいのは、計測タグには発行元が二通りあるという点です。ビジネスマネージャーで発行したタグと、広告アカウントで発行したタグのどちらも指定できます。複数ブランドや複数代理店が同居しているアカウント構成では、この選択が後々の権限整理に効いてきます。長期的にはビジネスマネージャー側に寄せるほうが横断計測との相性はよく、広告アカウント発行タグは単一事業・単一運用者の環境に限って選ぶのが無難な判断です。
なお、配信最適化の設定論と計測基盤の話は分けて考える必要があります。ターゲティングや自動入札の設計については以下の記事をご覧ください。
広告アカウントごとのタグ発行から解放されて減る作業と、代わりに増える作業
減るのは発行と実装の往復作業で、増えるのは権限と紐づけの確認作業です。トータルの工数が下がるかどうかは、アカウント数と関係者の多さで決まります。アカウントが一つで実装者も一人なら恩恵は小さく、アカウントが十を超えて代理店と社内が分担している環境では効果が大きく出ます。
従来の運用では、広告アカウントを増やすたびにコンバージョン測定タグを発行し、サイト側の実装担当に依頼し、反映を待ち、テストコンバージョンで確認するという工程が発生していました。この一連の待ち時間が、新規アカウント立ち上げの実質的なリードタイムになっていた現場は少なくないはずです。計測タグに寄せると、この工程が「管理ツール上で既存タグを指定する」という一手に置き換わります。
タグ発行と実装の手間がどこまで軽くなるか
サイトへの実装が一度で済むという点が最大の変化です。計測タグをサイトに設置しておけば、あとから広告アカウントを追加してもサイト側を触る必要がありません。ECサイトのように改修リリースにレビューと検証が必要な環境では、この差がそのまま施策着手の速さになります。
一方で、実装が一度で済むということは、そのタグが壊れたときの影響範囲も広がるということです。サイトリニューアルやタグマネージャーの整理でひとつの計測タグを落とすと、紐づいた全アカウントのコンバージョンが同時に止まります。計測タグの実装箇所は、サイト改修時の必須チェック項目として運用手順書に明記しておくべきです。
代わりに増える権限とタグ管理の確認作業
ビジネスマネージャー発行タグを使う場合、タグの管理権限と広告アカウントの操作権限が別々に存在する点に注意が必要です。運用担当者に広告アカウントの権限しか渡していないと、タグの発行やアクセストークンの管理ができず、切り替え作業が止まります。着手前に、誰がタグを発行し、誰がトークンを保管し、誰が実装するのかを一枚の表に落としておくと事故が減ります。
タグの指定作業そのものも、担当を分けると滞ります。計測タグを広告管理ツール上で指定する操作は数分で終わりますが、その前段にある「どのタグを指定するのが正しいか」の確認には、サイト構成とビジネスマネージャーの構成を両方知っている人間が必要です。複数の計測タグが発行済みで、どれがどのドメインに設置されているか分からない状態のまま進めると、間違ったタグを指定してコンバージョンが計上されない事故につながります。着手前にタグと設置ドメインの対応表を作ってください。
もう一点、公式発表では、ディスプレイ広告などですでにスニペットIDを利用した計測を行っている場合、検索広告（ショッピング）で同一タグを使ってスニペットID計測を行うには個別の実装設定が必要と案内されています。ディスプレイ広告と同じ計測タグを流用する構成では、必ずスニペットID周りの実装確認を工程に入れてください。ここを飛ばすと、計測タグは動いているのに商品単位のデータだけが欠けるという、気づきにくい状態になります。
コンバージョンAPIで埋められる欠損と、埋められない欠損
コンバージョンAPIが埋められるのは、ブラウザー側の事情でタグが発火しなかった分です。逆に、そもそもサーバー側に注文データが残らない種類のコンバージョンは埋められません。この線引きを最初に共有しておかないと、導入後に「思ったほど増えなかった」という評価になりがちです。
コンバージョンAPIは、アクセストークンを発行し、自社サーバーからコンバージョンデータを直接送信する仕組みです。ブラウザーのトラッキング制限や広告ブロッカー、通信の途中離脱といった要因に左右されにくく、計測環境としての安定性が上がります。ビジネスマネージャーのマニュアルでは、発行したアクセストークンは画面を閉じると再表示できないため、その場でコピーして保管するよう案内されています。再発行は可能ですが、再発行の運用を前提にすると管理が煩雑になるため、初回に確実に保管する体制を組んでください。
サーバーサイド計測が効く領域を見極める
効果が出やすいのは、注文完了がサーバー側で確定するEC型のコンバージョンです。決済完了時に注文レコードが立つため、そのタイミングで送信すればブラウザーの状態に依存せず記録できます。注文金額や商品情報も併せて渡せるため、金額ベースの評価軸を持つアカウントほど恩恵が大きくなります。
もうひとつ効きやすいのが、コンバージョンの確定タイミングをずらしたい商材です。申込直後ではなく審査通過後や与信確定後を成果とみなす業種では、ブラウザーの画面遷移とコンバージョンの発生が時間的に切り離されています。サーバーから任意のタイミングで送信できる方式は、こうした業務フローと素直にかみ合います。ただし送信可能な時間の範囲には仕様上の制約があるため、自社の確定リードタイムがその範囲に収まるかを事前に確認してください。
逆に効果が読みにくいのは、資料請求フォームの送信完了のように、サーバー側の処理とコンバージョン定義が一対一で対応していないケースです。フォーム送信をメール送信の成否で判定している構成では、送信キューの遅延や失敗がそのまま計測のブレになります。この場合は、計測の安定性よりも先にフォーム基盤側の設計を直すほうが投資対効果は高くなります。
計測タグを外してAPI単独に振る判断はまだ早い
結論として、現時点でタグを撤去してコンバージョンAPI単独に振るのは推奨できません。公式発表では、計測タグによるコンバージョン測定では電話発信コンバージョンの計測機能は提供されていないと明記されています。電話をコンバージョンに含めているアカウントは、この一点だけで単独運用の対象外になります。
加えて、APIのレスポンスが正常であっても計測されるとは限らない点も、単独運用を避ける理由になります。送信自体は成功していても、値の形式が不正だったり重複と判定されたりすれば計測対象から外れます。タグ側が並走していれば、この取りこぼしにその日のうちに気づけますが、API単独では原因の切り分けに数日かかります。
また、クロスデバイスコンバージョンの判定精度向上は複数の識別情報を活用して行われると案内されており、送信する情報が少ないほど精度は出にくくなります。タグとAPIを併用してブラウザー側とサーバー側の両方から情報を送る構成のほうが、現実的には安定します。併用が前提になるからこそ、次に説明する重複排除の設計が避けて通れません。
他媒体でのサーバーサイド計測の考え方を先に押さえたい場合は、以下の記事をご覧ください。
transaction_idを軸にした重複排除の設計指針
重複排除はtransaction_idを正しく採番できるかどうかで決まります。仕組み側が自動で判定してくれるわけではなく、同じコンバージョンに同じIDが付いている場合にのみ機能します。裏を返せば、IDの設計を誤ると、タグとAPIの両方から届いた同じ注文がそのまま二件として計上されます。
公式発表では、重複計測を防止するtransaction_idへの対応と、注文金額・商品情報などを利用した柔軟なコンバージョン測定が可能になったと案内されています。ここで実務側が決めるべきなのは、どの値をtransaction_idとして渡すか、その値がブラウザー側とサーバー側で必ず一致するか、そして値が取得できなかったときにどう振る舞うかの三点です。
採番の原則と、どの値を渡すか
使うべきは、システムが一意に発行する注文番号や申込番号です。セッションIDやタイムスタンプを組み合わせて生成した値は、ブラウザー側とサーバー側で別々に作られてしまうため一致しません。transaction_idは新たに作るのではなく、既存の業務システムがすでに持っている一意な番号を流用するのが原則です。
値が取得できなかったときの振る舞いも先に決めておく必要があります。空文字を送るのか、送信自体を見送るのか、代替の値を生成するのかで結果が変わります。代替値を自動生成する実装にすると、本来は同一のはずのコンバージョンが別物として扱われ、重複排除がまったく効かなくなります。取得できない場合は送らないという判断のほうが、件数は減っても数値の信頼性は保てます。
注意したいのは、サンクスページで表示している注文番号と、基幹側で管理している注文IDが異なるケースです。フロント側は表示用の短縮番号、バックエンドは内部IDというように二重管理になっている環境は珍しくありません。この場合はどちらか一方に統一し、送信仕様書に明記したうえで、テスト注文で両経路の値が一致することを目視確認してください。
重複排除が効かない典型パターンを潰す
重複が起きるのは、片方の経路にIDが乗っていないときです。とくに多いのが、タグ側は自動で発火しているがAPI側の実装でIDの引き渡しを忘れているケースと、逆にAPI側は整っているがタグ側のパラメータ設定が空のままというケースです。どちらも管理画面上ではコンバージョンが増えているように見えるため、良い変化と誤認しやすいのが厄介なところです。
もう一つ見落とされがちなのが、確認の手順です。管理画面への反映には時間差があるため、送信した直後に件数が合わないことを不具合と判断してしまい、実装をやり直して事態を悪化させる例があります。本番投入前に少量のテストデータで送信し、反映を待ってから確認するという手順を工程に組み込んでおいてください。
| 状況 | 起きること | 先に見る画面 |
|---|---|---|
| API側にIDを渡していない | 同一注文が二重計上 | コンバージョン測定の設定画面 |
| 従来版タグと計測タグを併設 | 同一ページで二重計測 | サイト上のタグ実装状況 |
| フロントと基幹でID体系が別 | 排除が働かず件数が膨らむ | テスト注文の送信ログ |
| 返品・キャンセル後の再注文 | 別IDのため別件として計上 | 注文管理システムの採番仕様 |
| API送信が値の不正で弾かれる | 件数が想定より少ない | APIのレスポンスと反映状況 |
公式発表でも、従来版コンバージョン測定タグと計測タグを同じページに併設して同一のコンバージョン測定を行った場合、重複して計測される可能性があると明記されています。移行期はこの併設状態が一時的に発生しやすいため、併設する期間をあらかじめ日数で区切り、その期間の数値は評価に使わないと決めておくことが実務上の安全策になります。
ディスプレイ広告と横断した効果測定で数値の読み方がどう変わるか
横断計測が可能になると、媒体単位ではなくユーザー単位で経路を見られるようになります。ディスプレイ広告で認知した後にショッピング広告経由で購入した、といった流れが同じ計測タグの上で追えるため、これまで検索側にだけ寄っていた成果の見え方が変わります。
ただし、見え方が変わるということは、既存のレポートの前提が変わるということでもあります。ディスプレイ広告のコンバージョン数が増えたように見えても、それは配信が改善したのではなく計測できる範囲が広がっただけかもしれません。切り替え直後の増減を配信改善と読み違えると、誤った予算配分につながります。
実務としては、切り替え前後で最低二週間ずつのデータを取り、同じ期間の受注実績や問い合わせ件数といったサイト外の実数と突き合わせて評価するのが確実です。計測基盤を切り替えた直後の二週間は、入札や予算に手を入れない期間として固定する運用をおすすめします。自動入札を使っている場合はとくに、学習が新しい信号に慣れる時間を確保する意味でも有効です。
切り替え直後に見るべき管理画面
- コンバージョン測定の設定一覧で、計測タグ側と従来版タグ側の両方が有効になっていないか
- コンバージョン種別「ウェブ（計測タグ）」の計測ステータスが未計測のまま止まっていないか
- 日次のコンバージョン数が前週比で不自然に倍増していないか
- コンバージョン価値の合計が、注文管理システムの売上と桁単位でずれていないか
サーバーサイド計測の全体設計をタグマネージャー側から整理したい場合は、以下の記事をご覧ください。
移行を進める順序と、止めてよい作業・残すべき作業
移行は計測タグの設置から始め、コンバージョンAPIは後から重ねるのが安全です。両方を同時に立ち上げると、数値がずれたときに原因がタグ側かAPI側か切り分けられなくなります。まず計測タグでコンバージョンが正しく取れている状態を作り、そこにAPIを追加して差分を確認する順序が結局は速く終わります。
止めてよいのは、広告アカウントを追加するたびにコンバージョン測定タグを発行してサイト実装を依頼する作業です。計測タグに寄せた後は、この工程を運用手順書から削除して構いません。残すべきは、テストコンバージョンによる実測確認と、月次でのコンバージョン数と実績値の突き合わせです。計測が自動化されるほど、ずれに気づく機会は減ります。
棚卸しの段階で必ず出しておきたいのが、従来版タグの設置箇所の一覧です。タグマネージャー経由で入っているもの、テンプレートに直書きされているもの、特定のランディングページにだけ残っているものが混在しているのが普通で、この把握が甘いまま計測タグを入れると併設状態が意図せず長引きます。撤去できないタグが一つでも残っている限り、重複計測のリスクは消えないと考えて、洗い出しには時間をかけてください。
コンバージョンAPIの追加は、計測タグ側の数値が一週間程度安定してから着手するのが現実的です。両者の件数差を見て、差がタグの取りこぼし分として説明できる水準に収まっているかを確認します。差が説明できないうちは撤去に進まないという線引きを持っておくと、判断がぶれません。
従来版タグの撤去は最後に行ってください。
公式発表では、従来版コンバージョン測定タグによる計測は2026年秋頃に新規作成機能の提供終了を予定とされ、計測自体も今後提供を終了する予定と案内されています。ただし提供終了時期の詳細は決まり次第の案内とされており、現時点では未公表です。逆算すると、新規作成ができなくなる前に新しいアカウントを立てる予定があるかどうかが、着手時期を決める現実的な基準になります。
| 工程 | やること | 完了の判断基準 |
|---|---|---|
| 棚卸し | 対象アカウントと現行タグの一覧化 | 従来版タグの設置箇所がすべて特定できた |
| 権限整理 | タグ発行者・トークン保管者・実装者の確定 | 担当が空欄の役割がない |
| 計測タグ設置 | サイトへの実装と広告管理ツールでの指定 | テスト注文が管理画面に反映された |
| API追加 | アクセストークン発行と送信実装 | タグ経由との件数差が説明できる |
| 併設解除 | 従来版タグの停止と撤去 | コンバージョン数が想定水準で安定した |
この条件ならまだ移行を見送ってよい
すべてのアカウントが今すぐ移行すべきというわけではありません。検索広告（ショッピング）を配信していないアカウントは、今回の発表の対象外です。まずここで大半のアカウントは対象から外れます。対象外のアカウントに工数を割くくらいなら、クリエイティブや商品データの整備に回したほうが成果につながります。
次に、電話発信をコンバージョンの主要指標にしているアカウントも、現時点では急ぐ理由が薄い部類に入ります。計測タグでは電話発信コンバージョンの計測機能が提供されていないため、移行しても主要指標が計測できません。この場合は、従来版タグを維持しつつ、提供終了に関する続報を待つ判断が合理的です。
サイト改修のリソースを確保できない場合も、無理に進めないほうがよい典型です。計測タグの実装とAPI送信の開発は、いずれもサイト側の作業を伴います。中途半端に片方だけ入れた状態で放置するのが、最も事故が起きやすい状態です。着手するなら、撤去まで含めた工程を一度で走り切れるタイミングを選んでください。
見送りを選んだ場合に必ずやること
- 従来版タグの新規作成が必要になる予定がないか、半期単位で確認する
- 提供終了時期の続報が出た時点で、再検討する担当者を決めておく
- 見送り理由を記録し、次の担当者が判断を引き継げるようにする
運用代行に依頼する場合の役割分担と発注前の確認事項
計測基盤の移行は、広告運用と開発の境界に落ちやすい作業です。だからこそ、発注前に誰がどこまで持つのかを文書で確定させてください。広告管理ツール側の設定は代行会社、サイト実装は自社開発、APIの送信仕様は両者で合意という分担が現実的な落としどころになります。
確認しておきたいのは、代行会社が計測タグとコンバージョンAPIの両方の設定経験を持っているかどうかです。設定手順そのものは公開されていますが、移行期の併設期間をどう扱うか、数値のずれをどう説明するかという判断は経験値に依存します。提案の段階で、切り替え期間の数値をどう扱うかを説明できるかどうかが見極めのポイントになります。
費用面では、計測基盤の移行を通常の運用業務に含めるのか、別途の初期設定費として切り出すのかを確認しておくと後の齟齬を防げます。作業量はアカウント数と従来版タグの残存箇所で大きく変わるため、見積もりは棚卸しの結果を見てから確定させる進め方が双方にとって安全です。棚卸しだけを先に依頼できるかどうかも、聞いておく価値があります。
あわせて、移行後のレポート様式を事前に握っておくことも重要です。計測方式が変わると過去との連続性が切れるため、どの指標を継続比較の対象とし、どの指標を仕切り直すのかを合意しておかないと、月次報告のたびに数値の解釈で議論が発生します。ハーマンドットでは、こうした計測基盤の切り替え時には、切り替え前後の重複期間を明示したレポートを用意して認識を揃えています。
代行会社の選び方や依頼範囲の決め方については、以下の記事をご覧ください。
まとめは計測タグ移行を段階設計で進めること
今回の対応開始は、検索広告（ショッピング）の計測基盤を作り直すきっかけです。一度に全部を切り替えるのではなく、棚卸し、計測タグ、コンバージョンAPI、従来版撤去という順序で段階的に進めれば、数値のずれが起きても原因を特定できます。逆に順序を崩すと、増えたコンバージョンが実態なのか重複なのか判断できなくなり、入札判断そのものが止まります。移行の成否を決めるのは仕様理解ではなく、transaction_idの採番設計と、併設期間を評価から外す運用ルールです。
- 対応開始は2026年8月26日、対象は検索広告（ショッピング）のみ
- 計測タグは一度の実装で複数アカウントに紐づけられる代わりに、障害時の影響範囲が広がる
- コンバージョンAPIはタグとの併用が前提。電話発信コンバージョンは計測タグでは非対応
- 重複排除は業務システムの一意な注文番号を流用するのが原則
- 切り替え直後の二週間は入札・予算を触らず、実績値と突き合わせて検証する
従来版タグの計測終了時期は現時点では未公表ですが、新規作成機能の提供終了は2026年秋頃が予定されています。アカウント追加の予定があるなら、その前に手を打っておくのが安全です。
まずは無料で広告アカウント診断を
計測基盤の切り替えは、設定作業そのものより「今の自社アカウントがどの状態にあるか」を正確に把握するほうが難しい領域です。従来版タグがどこに残っているか、計測タグとの併設が起きていないか、コンバージョン数が実績と合っているか。この三点を外部の目で確認するだけでも、移行の失敗はかなり防げます。
ハーマンドットでは、LINEヤフー広告をはじめとする各媒体のアカウントを無料で診断し、計測設定の不備と改善余地を洗い出しています。移行を進めるべきか、まだ見送るべきかの判断まで含めてお伝えします。現状の設定内容を共有いただければ、優先順位をつけた具体的な打ち手をご提案します。
初回相談は完全無料・所要時間30分・オンライン対応可能