ChatGPT広告のConversions API｜Pixelとの併用・重複の防ぎ方・実装前の準備

この記事の要点

1. Conversions API（CAPI）は、Pixelの代わりではなく、Pixelを補うものとして案内されています。 開発者向けドキュメントは、2026年10月29日時点で「両方を使い、ブラウザの行動とサーバーで確定した成果を組み合わせる」と書いています。サーバーだけで送る場合もPixel IDが必要で、クリックの参照値（oppref）は自分で受け取って渡す必要があります。
2. 同じ成果を両方で送るときは、Pixel ID・イベント名・イベントIDをそろえます。 OpenAIは最初に届いた1件を使い、後から届いた重複は無視します。再送するときも同じイベントIDと元の時刻を使います。注文IDなど、社内で一意に決まる値をイベントIDにするのが分かりやすい方法です。
3. 実装の前に、「何を・いつ・どの経路で・どの情報と一緒に」送るかを決めます。 送れるのは行動から7日以内のイベントで、イベント品質の評価は行動から1時間以内に届いたかを見ます。メールアドレスなどの顧客情報は正規化してからハッシュ化し、1つのリストに入れる値は3つまでです（超えるとHTTP 400のエラー）。

読んでほしい人：ChatGPT広告の成果をサーバーや顧客管理の仕組みから送ることを検討している広告担当者・開発者、実装を外部に依頼する担当者。
この記事で扱わないこと：ブラウザのPixelの設置はPixelの記事、アプリのインストールの計測とMMP連携はアプリの記事、計測の全体像は効果測定の記事で扱います。

Pixelとの違いと、併用するかの判断

Conversions APIは、自社のサーバーから成果のイベントをOpenAIへ直接送る仕組みです。例えば、バックエンドで購入が確定したときに送ります。ブラウザから送るPixelとは、送る場所と得意な成果が違います。

開発者向けドキュメントは、CAPIでできることとして、ブラウザからの送信だけに頼らずに成果を測ること、対応する顧客情報で照合を改善すること、送信と再送をサーバーで管理することを挙げています。

位置づけの説明は、2026年10月7日から29日の間に変わりました。10月7日時点のCAPIのページは「Pixelだけより信頼できる計測元で、可能ならCAPIを使う」と書いていました。10月29日時点では「Pixelを補うもの。両方を使い、ブラウザの行動とバックエンドで確定した成果を組み合わせる」に書き換わっています。なお、開発者向けの成果最適化のページには「Pixelだけより信頼できる」という表現が残っています。ヘルプ（Conversion Measurement）も、より安定した計測のために両方を使えると書いています。

どの組み合わせにするかの考え方は、次のとおりです（当社の見解）。

CAPIだけで送る場合も、データソースのPixel IDが必要です。ブラウザにPixelを設置する必要はありません。同じWebサイトでPixelと併用する場合は、データソースを分けずに使い回します。

重複を防ぐ：イベントIDの決め方

同じ購入をPixelとCAPIの両方で送ると、何もしなければ2件に見える恐れがあります。開発者向けドキュメントによると、OpenAIは「Pixel ID・イベント名・イベントID」の組み合わせで重複を見分け、最初に届いたイベントを使って、後から届いた重複を無視します。カスタムイベントでは、イベント名の代わりにカスタムイベントの名前で見分けます。

イベントIDの決め方の原則は2つです。同じ行動には同じIDを使う（ブラウザとサーバーの両方、再送のときも）。別の行動には別のIDを使う。開発者向けドキュメントは「実際の注文IDか、ほかの一意のイベントID」を使うよう書き、例では注文ID（order_12345）をそのままイベントIDにしています。ただし、ブラウザ側が画像タグの場合は、URLのパラメータに注文IDを入れないよう書かれているため、注文番号以外のIDにします（Pixelの記事）。

「最初に届いた1件を使う」ことから、注意点が出てきます。ヘルプは、元のイベントの金額や照合の情報を変えるために重複を送り直さないよう書き、ブラウザとサーバーで同じ注文金額を送ること、Pixelにある参照値や顧客情報がサーバーのイベントに欠けていないかを別々に確かめることを求めています。後から届いた側の情報は使われないため、照合に使う情報はそれぞれの送信に入れておく、と当社は読んでいます。

重複は、PixelとCAPIの間だけで起きるわけではありません。ヘルプは、重複したタグ、ページの再読み込みや処理の呼び直し、同じイベントをすでに送っている計測パートナーの連携も確かめるよう挙げています。Shopifyのアプリなど、別の連携が同じ成果を送っていないかも確かめます。

送る項目と、クリックの参照値

CAPIのリクエストは、Pixel IDを付けた送信先に、Conversions APIのキーで認証して送ります。1回に送れるイベントは1,000件までで、1件でも不正なイベントがあると、そのまとまり全体が失敗します。開発者向けドキュメントの購入の例（イベントの部分）は次のとおりです。

{
  "events": [
    {
      "id": "order_12345",
      "type": "order_created",
      "timestamp_ms": ${EVENT_TIMESTAMP_MS},
      "action_source": "web",
      "source_url": "https://shop.example.com/checkout/confirmation",
      "data": {
        "type": "contents",
        "amount": 8900,
        "currency": "USD"
      }
    }
  ]
}

主な項目は次のとおりです。

金額の送り方はPixelと同じで、通貨の最小単位の整数です（8,900円は8900）。商品ごとの金額は1単位の価格で、数量は別に送ります（10月7日時点の「商品ごとの金額」から書き換わった説明。詳しくはPixelの記事）。上の例の時刻（${EVENT_TIMESTAMP_MS}）は原典ではシェルの変数で、実際には行動の時刻をミリ秒の整数で入れます。

opprefは自分で受け取って渡す

広告がクリックされると、LPのURLの末尾にクリックの参照値（oppref）が付きます。Pixelはこれを自動で取ってCookieに保存しますが、CAPIは自動では取りません。LPで受け取ったopprefを、フォームの送信や注文のデータと一緒にサーバーへ渡し、元の値のままイベントに入れる仕組みが必要です。ヘルプは、転送やLP内の移動でopprefを落とさないこと、値を作ったり他の訪問者の値を使ったりしないことを求めています。

PixelとCAPIを併用する場合は、Pixelが保存する __obref というCookieの値（ブラウザの参照値）をブラウザで読み、サーバーへ渡して user の obref に入れることもできます。opprefはイベントの項目、obrefは user の中の項目です。obrefも、同意の要件に従って扱い、同意が取り消されたら送るのをやめます。

opprefのない成果も送る

10月29日時点の開発者向けドキュメントとヘルプは、opprefの付いた成果だけでなく、送ることが許された成果をすべて送るよう勧めています。開発者向けドキュメントは、その理由を、ビュー経由の成果をキャンペーンの数字に入れるためと書いています。この勧めは、10月7日時点の両方の資料にはなかった記載です。opprefがあるイベントだけを選んで送る実装は見直します（当社の提案）。

顧客情報の送り方：正規化とハッシュ化

user の項目は任意ですが、照合を助けます。メールアドレス・電話番号・自社の顧客ID・名・姓は、正規化してからUTF-8でSHA-256のハッシュにし、小文字の64桁の16進数で送ります。元の値は送りません。地域の情報（国・都道府県・市区町村・郵便番号）、IPアドレス、ユーザーエージェント、Pixelのobref、Androidの広告ID（GAID）はハッシュ化せずに送ります。iOSの広告ID（IDFA）は対応していません。

電話番号は注意が必要です。原典の例は米国の番号（+1 (415) 555-2671 → 14155552671）だけです。国内の表記には国番号がないため、規則をそのまま当てはめると「9012345678」になり、国番号が欠けます。当社は、国番号81を付けた形にしてから規則を当てはめるのが趣旨に合うと考えます。日本語の氏名を漢字・かな・ローマ字のどれで送ると照合に役立つかは書かれていません。

各項目は、複数の値をリストで送れます。ただし、1つのリストに入れられるのは3つまでで、超えるとHTTP 400のエラーになり、値は切り詰められません。10月7日時点のドキュメントは「先頭の有効な3つを使い、残りは無視して受け付ける」と書いていたため、扱いが変わっています。1件の不正なイベントでまとまり全体が失敗するため、メールアドレスを4つ持つ顧客が1人いるだけで、同じまとまりで送った他の成果も受け付けられなくなります（当社の注意）。送る前に3つまでに絞る処理を入れます。

IPアドレスとユーザーエージェントは、成果を起こした利用者の端末のものを送ります。イベント品質のヘルプは、サーバー自身のアドレスや汎用のユーザーエージェントで代用しないよう書いています。同じ人には同じ顧客IDを使い、共有の値や仮の値を複数の人に使い回さないことも求めています。

顧客情報を送るのは、許可されている場合だけです。ヘルプは、集めるデータを利用者に分かりやすく説明し、法令で必要な同意を得てから送るよう求めています。国内の法令（個人情報の第三者への提供や外部への送信の扱い）への対応は、OpenAIの説明とは別に、自社の法務・プライバシーポリシーと合わせて確かめます。

送るタイミングと再送

CAPIでは、送るタイミングを自社で決めます。公式資料には、3つの時間の条件があります。

ヘルプは、実際の行動が確定したらすぐに送るよう勧め、遅れているときは、定時の一括送信、待ち行列、失敗した送信、再送の間隔を確かめるよう書いています。夜間にまとめて送る運用は、1時間の基準を超えるため「遅れている」という警告の対象になり得ると当社は見ています。7日を超えた成果は受け付けられません。当社は、成果が確定した時点で送る仕組みを勧めます。

再送の扱いも決めておきます。時間切れやサーバーのエラーでは、届いたかどうか分からないことがあります。ヘルプは、同じ行動を再送するときは元のイベントIDと元の時刻を使うよう求めています。新しいIDにすると、別の行動に見えるためです。古いイベントを受け付けさせるために時刻を書き換えないことも求めています。エラーの応答コード、エラーの文面、送った時刻、イベントIDは記録します。

B2Bの受注のように、クリックから成果まで時間がかかる場合の考え方です。7日の条件は「行動が起きてから送るまで」の期間なので、受注が確定した時点で送れば受け付けられます。ただし、Ads Managerのクリックの帰属期間は7日・14日・30日から選ぶため、クリックから30日を超えた受注は、そのクリックの成果として数えられないと当社は考えます。受注までを追う方法はHubSpot連携の記事とB2B事例の記事で扱っています。

実装の分担：社内開発・計測パートナー・実装ツール

CAPIの実装は、自社の開発者が直接作るほかに、OpenAIのヘルプが挙げる連携先や実装ツールを使う方法があります。

Stape（実装ツール）とDatahashの記載は、10月7日時点のヘルプにはなく、10月29日時点で加わったものです。OpenAIの10月5日の発表は、Hightouch・Tealium・LiveRampとの連携で既存のシステムから成果を送りやすくなると書いていますが、ヘルプに設定の手順があるのはHightouchとLiveRampです。

鍵の管理は、どの方法でも同じ原則です。Conversions APIのキーは成果を送るためだけの鍵で、キャンペーンの管理に使うAdvertiser APIのキーとは別物です。どちらもサーバーで保管します。開発者向けドキュメントは、CAPIのキーをブラウザのコード、利用者から見える環境変数、ログ、ソースコードの管理に置かないよう書いています。サポートに問い合わせるときもキーを送りません。Pixel IDとCAPIのキーは、Ads Managerの成果（Conversions）の画面で用意できます。APIではキーに名前を付けて作れるため、送る仕組みごとに分けておくと、どこからの送信かを区別しやすくなります（当社の見解）。代理店などが顧客に代わって送る場合は、毎回のリクエストに integration_source という項目で、自社を示す一定の名前を入れます。

テストと確認の手順

1. 検証だけを行う。 リクエストに validate_only を true で付けると、イベントを保存せずに形式を検証できます。この送信は、直近のイベントの確認には表れません
2. 実際の行動で送る。 本番の成果を1件起こし、イベントID・行動の時刻（タイムゾーンも）・応答を記録します。テストであることを社内の記録に残します
3. 受信を確かめる。 利用できるアカウントでは、Advertiser APIのキーで直近のイベント（およそ15分の見本）を取り、イベントの種類・データソース・経路を確かめます。サーバーからのイベントは server_to_server と表示されます
4. 計上を確かめる。 24〜48時間ほど後に、Ads Managerの成果の列で、広告のクリック（または対象の表示）の後に起きた成果が載るかを見ます。受け付けられたことは、広告に計上されたことを意味しません
5. イベント品質を見る。 「CAPIのイベントが遅れている」「広告のクリックの情報がない」「照合の情報が少ない」などの警告を確かめます

エラーで拒否された、時間切れになった、サーバーのエラーが返ったときは、24〜48時間の反映を待たずにすぐ調べるようヘルプは書いています。サポートに問い合わせるときは、応答コード、エラーの文面、送った時刻、返されたリクエストIDやCF-Ray、キーや不要な顧客情報を消した送信内容を添えます。

この記事で分からないこと

• オフラインの成果（電話・来店など）が、どのように広告に結びつけられるか。 action_source には phone_call や physical_store があり、LiveRampにはオフラインの成果の手順がありますが、帰属の扱いは書かれていません
• 日本語の氏名や国内の電話番号の、照合に適した形。 原典の例は米国の値だけです
• サーバー側で、Pixelが保存する __oppref のCookieを読んで使ってよいか。 __obref については読んで渡す手順がありますが、__oppref については書かれていません
• 成果の合計にビュー経由を含めるか。 開発者向けのCAPIのページは「キャンペーン単位の別の指標で、合計には含めない」、ヘルプは「ビューの帰属期間が1日なら含める」と書いており、10月29日時点でも食い違っています（ビュースルーの記事）
• CAPIのキーを無効にする手順。 確認した範囲には書かれていません

実装前に決めることのチェックリスト

• [ ] 送る成果と、その「確定」の時点を決めた（注文の作成・決済の完了・申込の受付など）
• [ ] Pixelのみ・CAPIのみ・併用のどれにするかを決め、データソース（Pixel ID）を1つにした
• [ ] イベントIDの作り方を決めた（注文IDなど一意の値。ブラウザとサーバー、再送で同じ値）
• [ ] LPで受け取ったopprefを、フォームや注文のデータと一緒にサーバーへ渡す流れを設計した
• [ ] opprefの有無にかかわらず、送ってよい成果はすべて送る
• [ ] 送る顧客情報と正規化の方法を決め、各リストを3つまでに絞る処理を入れた
• [ ] 利用者の端末のIPアドレスとユーザーエージェントを渡せるか確かめた
• [ ] 金額の定義（円の整数、税・送料・割引の扱い）をPixelとそろえた
• [ ] 成果が確定した時点で送り、失敗したら同じIDと元の時刻で再送する仕組みにした
• [ ] キーの保管場所と担当者を決め、ブラウザのコードに出していない
• [ ] validate_only での検証と、実際の行動でのテストの手順と記録の方法を決めた
• [ ] 同意の扱いとプライバシーポリシーの記載を確かめた

よくある質問

Q. PixelなしでCAPIだけでも計測できますか。 できます。データソースのPixel IDは必要ですが、ブラウザにPixelを設置する必要はありません。ただし、Pixelが自動で行うopprefの受け取りと保存、自動詳細マッチングはなくなります。opprefをLPからサーバーまで受け渡す仕組みを自分で作ることになります。開発者向けドキュメントとヘルプは、両方を使うことを勧めています。

Q. 電話での問い合わせや店舗での購入も送れますか。 action_source には phone_call（電話）・physical_store（店舗）・offline などの値があり、送ること自体はできる形になっています。LiveRampの連携には、店舗での購入などオフラインの成果の手順もあります。ただし、こうした成果がどのように広告のクリックや表示に結びつけられるかは書かれていません。当社は、まずWebで起きる成果で計測を固め、オフラインの成果は別の指標として扱うことを勧めます。

Q. 顧客情報を送らないと、成果は計上されませんか。 user の項目は任意で、送らなくてもイベントは受け付けられます。広告への結びつけには、opprefや照合の情報などが使われます。ただし、イベント品質の評価では、メールアドレスや顧客IDが少ないと警告が出ることがあります。送るかどうかは、照合の改善と、プライバシーポリシー・同意の設計を合わせて判断します（当社の見解）。

Q. 送信に失敗したイベントは、どうすればよいですか。 エラーの内容を記録し、形式・Pixel ID・キーを確かめます。1件の不正なイベントでまとまり全体が失敗するため、どのイベントが原因かを調べ、直してから送ります。届いたか分からない場合に再送するときは、元のイベントIDと元の時刻を使います。新しいIDにすると、別の成果として数えられる恐れがあります。

Q. 代理店に実装を任せるとき、何を渡せばよいですか。 送るのに必要なのは、Pixel IDとConversions APIのキーです。キャンペーンの管理に使うAdvertiser APIのキーとは別物で、成果を送るだけならAdvertiser APIのキーは要りません。代理店が顧客に代わって送る場合は、integration_source に自社を示す一定の名前を入れるよう開発者向けドキュメントは求めています。キーは送る仕組みを持つ側のサーバーで保管してもらい、メールやチャットに貼らない運用を決めておきます（当社の提案）。

まとめ

• CAPIはPixelを補うもの。10月29日時点のドキュメントは、両方を使ってブラウザの行動と確定した成果を組み合わせるよう案内している
• 両方で送るときは、Pixel ID・イベント名・イベントIDをそろえる。最初に届いた1件が使われ、後の重複は無視される
• opprefは自分で受け取って渡す。opprefのない成果も、送ってよいものはすべて送る
• 顧客情報は正規化してハッシュ化し、各リストは3つまで。超えるとエラーになり、まとまり全体が失敗する
• 行動から7日以内に送る。品質の評価は1時間以内に届いたかを見る。再送は同じIDと元の時刻で
• 鍵はサーバーで保管し、送る仕組みごとに分けて管理する

サーバーから成果を送る設計を一緒に整理したい場合は、成果が確定する仕組み（注文・申込・顧客管理のシステム）、現在のPixelの設置状況、送れる顧客情報の範囲をお手元に用意のうえ20分の無料相談をご利用ください。

出典

• Conversions API（位置づけ、すべての成果を送る勧め、送信先と1,000件・まとまり全体の失敗、項目と時刻の条件、action_source、opprefとobref、user の項目と正規化・ハッシュ化、3つまでの制限とHTTP 400、IPアドレス、integration_source、重複の見分け方、ビュー経由の記述）
• Conversion Tracking（Pixel IDとキー、サーバーだけでもPixel IDが要る、送信の例、validate_only、opprefを自動で取らない、直近のイベントの確認、8,900円の例）
• Supported Events（イベント名、金額の単位、1単位の価格と合計）
• Measurement Pixel（Pixelが自動で行う処理、__obref、event_id）
• Conversion-Optimized Campaigns（開発者向け）（「Pixelだけより信頼できる」の表現）
• API Partner Setup（APIパートナーによるPixelとキーの作成、機能の有効化、integration_source）
• Conversion Setup（API Reference）（キーの作成と名前、キーを置いてはいけない場所、直近のイベントの確認は有効なアカウントのみ）
• Conversion Measurement（両方の併用、oppref、すべての成果を送る、同意）
• Troubleshooting conversion tracking for ChatGPT Ads（キーの種類、エラー時の確認と再送、7日と帰属期間の関係、受け付けと計上の違い、重複、同意、サポートに伝えること）
• Understanding and improving event quality（1時間以内の評価、IPアドレスとユーザーエージェント、顧客IDの扱い、照合の情報）
• Set up Measurement Partner Integrations（Hightouch・LiveRamp・Rockerbox・Stape・Datahash）
• More ways to measure ChatGPT Ads（2026年10月5日。Hightouch・Tealium・LiveRampとの連携）

いずれも2026年10月29日に本文を確認しています。2026年10月7日時点との比較は、当社が同日に保存した本文との比較です。

変更履歴

次回確認予定：2026年11月上旬。 CAPIのページのビュー経由の記述、顧客情報のリストの上限、オフラインの成果の扱い、実装ツールの追加を確認します。