LINEヤフー広告の検索広告（ショッピング）で従来版のコンバージョン測定タグが10月6日に発行終了｜計測タグ・コンバージョンAPIへの移行と、事故が起きやすい3箇所

コンバージョン数が媒体の管理画面とカート側の受注件数で合わない。広告運用者の方から相談を受ける内容のうち、いちばん解決に時間がかかるのがこれです。原因は一つではなく、ブラウザーの制限、計測タグの設置場所、CV定義のずれが混ざっているからです。LINEヤフー広告の検索広告（ショッピング）では2026年8月26日に統合計測タグとコンバージョンAPIへの対応が始まり、この混ざりものの一部を切り分けられるようになりました。そして2026年10月6日（火）予定で、従来版のコンバージョン測定タグの新規作成が終了します。つまり移行は「やってもよい」から「新しくタグを発行するなら新方式で」へ変わります。ただし「入れれば数字が合う」という話ではありません。むしろ入れ方を間違えると、これまでより数字が合わなくなる箇所が3つあります。

いま何が使えて、いつ何が終わるのか

計測経路の選択肢が4つ加わる

加わるのは、計測の経路を選べるようにする仕組みです。公式告知によると、検索広告（ショッピング）で統合計測タグ（ビジネスマネージャー発行タグまたは広告アカウント発行タグ。以降の告知では「計測タグ」と表記されています）を指定したコンバージョン測定ができるようになり、あわせてコンバージョンAPIも利用できるようになります。アクセストークンを発行すれば、ブラウザーを経由せずサーバーサイドから直接コンバージョンデータを送れます。

追加されるもの	実務上の意味
統合計測タグの指定	広告アカウントごとに別のタグを貼らず、1本のタグで複数の広告種別を計測できる
コンバージョンAPI	サーバーから直接送信するため、ブラウザー側の制限に左右されにくい
transaction_idによる重複排除	タグとAPIの両方で同じ注文が届いても、二重計上を防げる
クロスデバイス計測の精度向上	複数の識別情報を使い、スマホで見てPCで買った経路を拾いやすくなる

この4つのうち、実務でいちばん効くのは3つめのtransaction_idです。重複排除の仕組みがあるからこそ、タグとAPIを併用するという選択が現実的になります。どちらか一方に寄せる必要がなくなり、ブラウザー経由で取れる分はタグで、取りこぼす分はAPIで補う構成が組めるからです。

10月6日に終わるのは「新規作成」で、計測そのものではない

2026年10月6日（火）予定で終了するのは、従来版コンバージョン測定タグの新規作成です。対象は「ウェブ（従来版）」と「電話発信」の2種類で、いずれも検索広告（ショッピング）が対象サービスになります。既存の設定内容は引き続き編集できるため、いま動いている計測がこの日を境に止まるわけではありません。

ただし、公式告知は「従来版コンバージョン測定タグを利用した計測は、今後提供を終了予定」とも述べており、終了日は決まり次第あらためて案内されるとされています。つまり10月6日は移行の完了期限ではなく、先に新規発行の口が閉じる日です。この日以降に新しいコンバージョンポイントを増やしたくなったら、計測タグを使うことになります。

時点	状態
2026年8月26日	統合計測タグ・コンバージョンAPIへの対応開始
2026年10月6日（予定）	従来版タグ（ウェブ〈従来版〉・電話発信）の新規作成が終了。既存設定の編集は継続可
未定（追って告知）	従来版タグを使った計測そのものの提供終了

期限が近いぶん、影響を受けるのは「これから何かを増やす予定がある」アカウントです。新しい入札戦略を試すために計測を整え直す予定があるなら、順番として先に計測側を片づけるほうが手戻りが出ません。検索連動型ショッピング広告に追加された3つの入札戦略のように、目標値を前提にした自動入札はコンバージョン計測が土台になるためです。

サーバーサイド計測で埋まる穴と、埋まらない穴

ブラウザー側の計測が取りこぼす場面

取りこぼしが起きるのは、タグが実行されない、あるいは実行されても識別情報が届かない場面です。具体的には、広告ブロッカーが有効なブラウザー、トラッキング防止機能でCookieの保持期間が短縮される環境、サンクスページに到達する前に離脱するが決済自体は完了しているケース、決済代行サービス側のドメインでサンクスページが表示されるケースなどが挙がります。

コンバージョンAPIは、この経路をサーバー側に移します。注文が確定した時点で自社のサーバーからLINEヤフー側へ直接データを送るため、ブラウザーで何が起きていたかに左右されにくくなります。仕組みとしては、ブラウザーという不安定な中継点を一つ外している、と理解しておくと迷いません。同じ考え方は媒体をまたいで共通で、Cookieに依存しない計測経路を用意する方向へ各媒体が進んでいます。

それでも合わない数字は残る

「コンバージョンAPIを入れればカート側の受注件数と一致する」わけではありません。一致しない理由は、計測経路とは別のところにあります。

まず、広告媒体のコンバージョンは広告に接触した人の注文だけを数えるため、そもそも母集団が違います。次に、媒体側は広告クリックの日付で計上する一方、カート側は注文日で集計するのが一般的で、日をまたぐ注文がずれます。さらに、公式告知では電話発信コンバージョンの計測機能は提供されないとされており、電話注文の比率が高い商材ではその分が丸ごと抜けます。サーバーサイド計測が埋めるのは「取れたはずなのに取れていなかった分」であって、定義の違いによる差ではありません。この線引きを持たずに導入すると、数字が増えた理由を説明できなくなります。

導入前後で比較するなら、比べる相手は自社の過去のコンバージョン数です。同じ期間・同じCV定義で、導入前の2週間と導入後の2週間を並べ、増分がどのくらいかを見る。増えた分はこれまで取りこぼしていた分だと解釈でき、目標値の見直しにも使えます。CPAやROASの目標値は計測できるCVの数を前提に決めているため、計測が変わったら目標も見直す、という順番になります。

移行で事故が起きやすい3箇所

従来版タグと新しいタグを同じページに併設する

従来版のタグと新しいタグを同一ページに併設すると、重複計測のリスクがあると公式告知でも案内されています。移行期の事故としてはこれがいちばん重い。移行期に「念のため両方残しておこう」と考えるのは自然ですが、その判断がそのままCV数の水増しにつながります。

安全な進め方は、テスト環境か、影響範囲の小さいコンバージョンポイントを1つ選んで先に切り替え、数字が想定どおりかを確認してから本番のサンクスページに広げる順番です。切り替えの当日に見るべきは、1時間単位の数値ではなく翌日以降の確定値です。反映の遅れを重複と誤認して元に戻す、という二度手間がよく起きます。

既存のスニペットID計測との共存を設定しないまま進める

スニペットIDを使った既存の計測を続けながら新しいタグへ移る場合、告知では個別の実装設定が必要とされています。ここを飛ばすと、片方の経路だけが有効になったり、両方が独立して数え始めたりします。すでにタグマネージャーで複数の計測タグを管理している構成ほど、どのタグがどの条件で発火するかの一覧を先に作っておく価値があります。

transaction_idを送っていないのに併用を始める

タグとAPIを併用するなら、transaction_idは必須の前提です。重複排除は同じ注文を同じIDで識別できて初めて働くので、APIの送信側で注文番号を渡していなければ、単純に二重に数えられます。自社のカートシステムで注文番号をどのタイミングで確定しているかを開発担当かカートの提供元に先に確認しておくと、実装の手戻りが減ります。

計測を整えたあとに残るのは、媒体ごとに違う定義の数字を並べて全体を判断する作業です。LINEヤフー広告のコンバージョンとGoogle広告・Meta広告のコンバージョンは、計上のタイミングもアトリビューションの考え方も揃っていません。ADmini（アドミニ）は各媒体のデータを1画面に集約し、項目名を揃えた表として持てるので、定義の違いを踏まえたうえで並べて比較できます。

ADminiの媒体データ1画面集約とピボット集計で、媒体をまたいだCVとコストの比較が毎朝同じ形で見られます。ADminiなら無料で始められます。無料で試してみる →

まとめ

先に限界を書いておきます。今回の対応で解決するのは計測経路の問題だけで、CV定義のずれ、集計期間のずれ、電話注文のような計測対象外の経路は残ります。これらを一緒くたにして「計測を強化したのに数字が合わない」と結論づけると、次に何を直せばよいかがわからなくなります。

そのうえで、10月6日という期限が付いたことで判断の順番は変わりました。既存の計測は当面続きますが、新しいコンバージョンポイントを増やす予定があるなら、その発行は期限前に済ませるか、最初から計測タグで組むかの二択になります。取りこぼしていた分が見えるようになれば実際のCPAは下がって見えるので、切り替えの前後で何がどう変わったかを自分で説明できる状態にしておく必要があります。ADmini（アドミニ）のようなツールで媒体横断の数値を毎日同じ形で残していれば、その説明は前後比較の表を出すだけで済みます。

まず今週やることは、いま検索広告（ショッピング）のコンバージョンをどのタグでどのページから取っているかを1枚のメモに書き出し、10月6日までに新規発行する予定があるかを確認することです。移行の判断も、事故の切り分けも、この現状把握がないと始まりません。

ADminiの媒体データ1画面集約とExcel・CSVアップロードで、広告の数字と自社の受注データを同じ表に並べられます。ADminiなら無料で始められます。無料で試してみる →

よくある質問

LINEヤフー広告の検索広告（ショッピング）でコンバージョンAPIはいつから使えますか

2026年8月26日（水）に提供が始まっています。同時に、ビジネスマネージャー発行タグまたは広告アカウント発行タグを指定した統合計測タグでのコンバージョン測定にも対応しました。利用にはアクセストークンの発行など広告主側の設定が必要で、提供開始日に自動で切り替わったわけではありません。設定していなければ、従来のコンバージョン測定タグによる計測がそのまま続いています。

従来版のコンバージョン測定タグは10月6日で使えなくなりますか

使えなくなるのは新規作成だけです。2026年10月6日（火）予定で終了するのは「ウェブ（従来版）」「電話発信」の新規作成で、既存の設定内容は引き続き編集できます。ただし従来版タグを使った計測そのものも今後終了予定とされており、終了日は決まり次第あらためて告知されます。10月6日以降に新しいコンバージョンポイントを増やす場合は計測タグを使います。

計測タグとコンバージョンAPIを両方使うと二重計測になりませんか

transaction_idを送っていれば重複排除が働き、同じ注文が両方の経路から届いても二重には計上されません。逆に言えば、注文番号にあたるtransaction_idをAPI側で渡していない状態で併用すると、単純に二重計上されます。併用を検討する場合は、自社のカートシステムで注文番号がいつ確定するかを先に確認してください。

コンバージョンAPIを入れれば、カート側の受注件数と数字が一致しますか

一致しません。広告媒体のコンバージョンは広告に接触した人の注文だけを数えるため母集団が異なり、媒体はクリック日、カートは注文日で集計するのが一般的なため期間もずれます。また電話発信コンバージョンは今回の計測機能の対象外です。サーバーサイド計測が埋めるのは取りこぼし分であり、定義の違いによる差は残ります。