ChatGPT広告の商品フィード入稿｜作り方・更新・エラー対処を解説

ChatGPT広告の商品フィードは、商品数が多いEC事業者が、カタログ情報をまとめてAds Managerへ取り込み、商品広告を作るための仕組みです。CSV・TXTの手動アップロード、安定したHTTPSのホストURL、SFTP接続から更新方法を選べます。商品名、価格、セール価格、画像、在庫、リンク先などを構造化しておくことで、商品ごとに広告を一件ずつ作る負担を減らせます。

ただし、フィードをアップロードしただけでは配信されません。処理・検証、広告グループでの商品選択、広告テンプレート、予算・入札・ターゲティング、審査、配信開始が必要です。またProductsタブは全登録商品の一覧ではなく、配信データが発生した商品のレポート画面です。本記事では、2026年9月4日に確認したOpenAI公式情報をもとに、設計からエラー対応まで説明します。

ASK AI自社の商品フィード設計をAIで整理

商品数と更新頻度を伝え、入稿方式と運用分担のたたき台を作れます。

ChatGPTを開く

ChatGPT広告の商品フィードとは

全体像：アカウント作成から配信までの基本手順は、ChatGPT広告の出し方で確認できます。

商品フィードは、商品カタログを機械が読み取れる表形式でAds Managerへ渡す仕組みです。OpenAI公式は、幅広い商品や頻繁に内容が変わるカタログを持つ小売広告主向けに案内しています。商品フィードから作成された広告は、初期プログラムで特に強い成果を示した広告群の一つと説明されていますが、すべての広告主で成果を保証するものではありません。

フィードの商品は自然検索へ掲載されるのか

2026年9月確認時点では、フィードの商品は広告での利用資格を持つためのもので、通常のChatGPT会話へ自然掲載されるものではありません。OpenAIは将来的な可能性に触れていますが、現在の広告フィードを登録すればオーガニック回答で推薦される、と説明してはいけません。

商品フィードが向く企業・向かない企業

入稿前に準備する商品データ

実際の必須列、データ型、文字数、許容値は最新のOpenAIフィード仕様で確認します。本記事では仕様にない列名を必須と断定しません。準備段階では、少なくとも次の情報源を一つにそろえます。

• 商品を一意に識別するID
• 商品名と説明
• 通常価格とセール価格
• 通貨と販売地域
• 在庫・販売可否
• 商品ページURL
• 商品画像URL
• ブランド、カテゴリ、商品ライン
• 広告対象に含めるかどうか
• 広告グループ分けに使うmetadata

商品名には社内コードだけを入れず、ユーザーが商品を判断できる名称を使います。説明は検索語の羅列ではなく、用途、対象者、主要仕様、サイズ、素材など、購入判断に必要な事実を優先します。価格・在庫・リンク先がサイトと一致することが最重要です。

CSV・TXT、ホストURL、SFTPを選ぶ

CSVまたはTXT

最初の試験や更新頻度が低い場合に向きます。担当者がファイルを確認してからアップロードできる一方、手動更新を忘れるリスクがあります。商品は2週間で期限切れになるため、長期運用で人の作業だけに依存しないよう注意します。

ホストURL

安定したHTTPS URLで商品フィードを公開し、Ads Managerが取得できる形です。定期的に価格や在庫を更新する運用に向きます。URLは認証画面やCookie同意で遮断せず、決めた担当者だけが生成処理を変更できるようにします。

SFTP

技術チームがサーバー間の更新を自動化する場合に向きます。接続情報は安全に管理し、チャット、原稿、共有スプレッドシートへ貼り付けません。失敗時の通知、再送、前回成功ファイルの保持も設計します。

Ads Managerでフィードを作成する手順

1. Ads ManagerのToolsタブを開く。
2. Feedsを選択する。
3. Create Feedを選び、新しいフィードを作る。
4. 対象フィードの3点メニューから取込方式を選ぶ。
5. CSV／TXTをアップロードするか、ホストURLまたはSFTPを設定する。
6. 処理完了を待ち、Upload Historyでエラーを確認する。
7. エラー行と項目を修正し、再取込する。

処理には数分から数時間かかる場合があります。アップロード直後に同じファイルを繰り返し送らず、処理ステータスを確認します。成功件数だけでなく、警告、除外、エラー商品数を記録してください。

商品を広告グループへ絞り込む

配信条件：商品群と会話文脈をどう組み合わせるかは、ChatGPT広告のターゲティングも参考になります。

キャンペーン作成時にProduct feedを選び、広告グループで使用するフィードと商品フィルターを指定します。画面に表示される商品数を見て、想定した商品が条件を通っているか確認します。

ads_metadataを使う

標準フィルターだけで商品群を分けられない場合は、ads_metadataにbidding_tierやproduct_lineのような運用用値を入れ、広告グループ作成時の整理に使えます。値は社内だけが分かる略号にせず、定義表を残します。

一つの広告グループへ混ぜすぎない

家具、化粧品、家電を一つにまとめるより、同じ顧客ニーズ、価格帯、商品カテゴリで分けます。どの会話や検討場面に役立つ広告かを広告グループ単位で説明できる状態にします。

広告テンプレートを作成する

公式案内では、広告グループごとに一つの広告テンプレートを作成します。2026年9月確認時点では、テンプレートで選択できるのは画像フィールドが中心です。サンプル商品プレビューで、商品名、説明、画像、価格の見え方を確認します。

• 画像が小さすぎたり切れたりしない
• 商品名が社内コードだけになっていない
• 説明が途中で切れても誤解を生まない
• 通常価格とセール価格が正しい
• ブランド表記がサイトと一致する
• リンク先が該当商品のページである

審査前の最終チェック

1. 正しいフィードを選択した。
2. 広告対象の商品数が想定と一致した。
3. 商品名、説明、画像、価格、リンク先を確認した。
4. 広告テンプレートのプレビューを確認した。
5. キャンペーン目的、予算、入札、対象国を設定した。
6. 広告グループのフィルターと対象商品を確認した。
7. 禁止・制限カテゴリの商品を除外した。
8. 在庫切れや期限切れのセールを除外した。

商品フィードは大量の商品を一度に広告対象にできるため、一件のミスが多数の広告へ広がります。開始前に全件を目視するのが難しい場合も、カテゴリ別の件数、価格の最大・最小、空欄、重複ID、画像エラー、リンクHTTPを機械的に確認し、各カテゴリから標本を目視します。

商品フィードの更新運用

更新頻度は商品の変化速度に合わせます。在庫と価格が毎日変わるのに週一回しか更新しなければ、広告とLPの不一致が増えます。反対に、内容が変わらない商品を短時間ごとに全件再送すると、運用負荷と障害切り分けが増えます。

更新前後に残す記録

• 生成日時とタイムゾーン
• 総商品数、追加、更新、削除の件数
• 広告対象・対象外の件数
• エラー・警告件数
• 価格・在庫の基準システム
• 前回成功時との差分
• 処理完了時刻と担当者

障害時の戻し方

誤価格や全件在庫切れなど重大な異常があれば、該当広告グループを止め、前回正常データへ戻せるようにします。最新ファイル一つだけを上書きせず、少なくとも直近の成功版と生成ログを保持します。

アップロードエラーの原因

• 必須項目が空欄または列名が仕様と違う
• 価格・通貨・日付・真偽値の形式が違う
• 商品IDが重複または更新ごとに変わる
• 画像URLが直接開けない、認証が必要、形式が非対応
• 商品URLが404、リダイレクト、地域遮断になる
• 文字コードや区切り文字が想定と違う
• 禁止商品またはポリシー違反の説明が含まれる
• ホストURLやSFTPの取得に失敗している

エラーを修正するときは、エラー行だけを削除して件数を合わせるのではなく、原因を商品データの基準システムへ戻して直します。次回生成で同じエラーが復活しないことを確認してください。

Productsタブが空・商品が少ない場合

Productsタブはアップロード済み商品の完全な管理一覧ではなく、配信データのレポート画面です。キャンペーンが未開始、開始日が未来、まだ配信されていない場合は空でも異常とは限りません。

1. フィードのUpload Historyで処理成功を確認する。
2. 広告グループ作成画面で対象商品数を確認する。
3. キャンペーンの開始日とStatusを確認する。
4. 商品フィルターで全件除外していないか確認する。
5. 配信開始後、レポート反映まで最大7時間程度待つ。
6. それでも不足する場合は例となる商品IDを揃えて問い合わせる。

問い合わせ時は、広告アカウントID、フィードID、キャンペーン名、広告グループ名、期間、タイムゾーン、商品ID例、Productsタブの画面を揃えます。認証情報や顧客データは送信しません。

フィード広告の効果測定

計測設定：商品別コンバージョンを取得する場合は、OpenAI Pixel・Conversions API設定を確認してください。

表示、クリック、CTR、CPCだけでなく、商品ページ到達、在庫、カート、購入、売上、粗利、返品まで追います。人気商品だけ配信されていないか、低単価商品にクリックが偏っていないか、広告グループ別に確認します。

商品フィード運用で失敗しやすいこと

1. 手動アップロード後に2週間以上更新しない
2. 在庫・価格の基準データが複数ある
3. 商品IDが更新のたびに変わる
4. 全商品を一広告グループへ入れる
5. 禁止・制限商品を除外しない
6. 画像URLにログインや期限付き署名が必要
7. Productsタブを全登録商品一覧だと思う
8. エラー商品を削除するだけで原因を直さない
9. 売上だけ見て粗利・返品を確認しない

商品データの設計表を先に作る

フィード作成で最初に決めるべきなのはファイル形式ではなく、「どのシステムを正とするか」です。価格はECカート、在庫は倉庫管理、商品名は商品マスターというように参照元が分かれていると、更新のたびに数字が食い違います。項目ごとに情報源、更新担当、更新時刻、異常値の判定、修正方法を一枚の設計表へまとめてください。OpenAIが指定する最新の列名や許容値は公式仕様を確認し、自社独自の呼び方をそのまま送らないことが重要です。

管理対象	正とする情報源	確認する内容	異常時の対応
商品ID	商品マスター	重複、欠損、更新前後の不意な変更	新旧IDの対応表を作り、配信実績との分断を防ぐ
商品名・説明	ECの商品詳細	誇大表現、文字化け、禁止表現、古い仕様	公開ページと同時に修正し、表示差をなくす
価格・セール価格	販売システム	通貨、税込・税別、セール期間、ページとの一致	不一致商品を除外し、正しい価格で再生成する
在庫・販売状態	在庫管理	欠品、予約、販売終了、更新遅延	在庫同期まで広告対象から除外する
商品URL	ECサイト	HTTP状態、リダイレクト、モバイル表示	リンク切れを直し、最終URLを再検証する
画像	画像配信基盤	取得可否、形式、画質、商品との一致	アクセス制限や差し替え漏れを修正する
広告用分類	広告運用台帳	商品群、利益率、季節、優先度	ads_metadata等の分類値を統一する

アップロード前の品質検査

フィードは「ファイルを開ける」だけでは合格ではありません。構文、事業データ、リンク、ポリシー、広告表示の五段階で検査します。全件を人手で見るのではなく、自動検査で候補を絞り、価格差や禁止カテゴリなど影響の大きい項目を人が確認する形が現実的です。

1. 構文検査：文字コード、区切り、改行、ヘッダー、必須値の欠損、商品IDの重複を確認します。
2. 事業データ検査：価格、通貨、在庫、販売期間、商品状態が販売システムと一致するか照合します。
3. リンク検査：商品URLと画像URLを実際に取得し、エラー、ログイン要求、過度なリダイレクトがないか確認します。
4. ポリシー検査：商品カテゴリ、説明、画像、遷移先がOpenAIの広告ポリシーに抵触しないか確認します。
5. 表示検査：複数の商品でプレビューし、動的に差し込まれた商品名、価格、画像が文として成立するか確認します。

検査結果には、検査日時、対象ファイル、総商品数、除外数、除外理由、承認者を残します。「エラーがゼロだった」という結論だけでは、後日データが変わったときに原因を追えません。前回との差分件数も保存すると、商品IDの全置換や価格の桁ずれなど大きな事故を早く発見できます。

更新方式別の運用ルール

方式	向く状況	最低限の運用	主な注意点
CSV・TXT手動	商品数が少ない、初回検証	担当者と更新日を固定し、更新後に履歴を確認	休暇や引き継ぎで止まりやすい。2週間の期限切れを防ぐ
ホストURL	日々商品情報が変わる	生成時刻、HTTP監視、前回件数との差分通知	認証やアクセス制限でOpenAIが取得できない状態を避ける
SFTP	大規模で定時連携したい	専用資格情報、送信ログ、失敗時の再送、鍵の更新	転送成功と内容の正しさは別。Upload Historyまで確認する

自動連携でも完全放置にはできません。生成成功、転送成功、OpenAI側の処理成功、商品が広告対象として利用可能、配信実績へ反映という段階は別々です。各段階の件数をつなぎ、どこで減ったかを確認できるようにします。

件数を照合して異常を見つける

運用台帳では、元の商品数から実際に配信・レポート表示された商品数までを一本の漏斗として管理します。Productsタブはアップロードした全商品を示す一覧ではないため、ここだけを見て「大量に欠落した」と判断しないでください。

段階	例として記録する数	差が出る主な理由
商品マスター	販売可能な全商品	予約・終売・広告対象外を含む
出力ファイル	抽出条件を通った商品	欠品、利益率、地域など自社条件で除外
処理成功	OpenAI側で処理できた商品	データエラー、URL取得失敗、仕様不一致
広告グループ対象	フィルター条件に一致した商品	分類値の表記ゆれ、条件の設定ミス
配信・レポート	配信データが発生した商品	予算、入札、需要、審査、最大7時間程度の反映待ち

この照合を更新直後と翌営業日に行うと、処理待ちと本当の障害を分けやすくなります。件数の変動率に警告線を置き、通常の販売変動を超えた場合だけ担当者へ通知する設計も有効です。

広告グループの分け方を設計する

広告グループは、単にカテゴリ名で分けるだけでなく、検索・会話の意図、利益率、在庫の安定性、価格帯、季節性、遷移先の内容が近い商品をまとめます。高利益の商品と在庫処分品を同じ目標で運用すると、入札や評価の判断が曖昧になります。

• 用途別：初心者向け、業務向け、ギフト向けなど、購入理由に合わせて分ける。
• 収益性別：粗利や許容獲得単価が大きく異なる商品を分ける。
• 在庫安定性別：常時在庫と限定品を分け、欠品時の影響を小さくする。
• 遷移先別：商品詳細、カテゴリ一覧、特集ページなど着地体験が異なるものを分ける。
• ポリシー確認別：追加確認が必要なカテゴリを通常商品と混在させない。

最初から細分化しすぎると配信量が分散します。開始時は意思決定に必要な少数の区分にとどめ、実績が集まってから分割します。区分を変えた日は台帳へ残し、変更前後の数字を安易に同じ条件として比較しないでください。

よくある事故と復旧手順

セール終了後も値引き価格が残った

セール期間の判定とフィード生成時刻を確認し、該当商品を一時除外します。商品ページとフィードの両方を正しい価格へ直し、再処理後にプレビューを確認してから対象へ戻します。

画像URLが社内では見えるのに取得されない

社内ネットワークやログイン済みブラウザだけで見える可能性があります。外部からのHTTP状態、アクセス制限、robots設定、画像形式を確認し、公開取得できる正規URLへ変更します。

商品IDが更新のたびに変わった

行番号や出力時刻をIDへ使うと、同じ商品が別物として扱われ、履歴も追いにくくなります。商品マスターの安定した識別子へ戻し、新旧対応表を保存します。

広告グループの商品がゼロになった

フィード全体の失敗と決めつけず、フィルター値の大文字小文字、空白、表記ゆれ、ads_metadataの更新漏れを確認します。条件を一つずつ外して、ゼロになる条件を特定します。

更新成功なのにProductsタブへ出ない

Productsタブの性質と反映時間を確認します。配信が有効か、予算・審査・日程に問題がないかを調べ、最大7時間程度のレポート反映待ちを考慮します。

30日で立ち上げる実務計画

1. 1〜5日目：商品マスター、価格、在庫、画像の情報源と責任者を確定し、禁止・制限カテゴリを洗い出します。
2. 6〜10日目：少数商品で検証用ファイルを作り、URL、画像、価格、プレビューを確認します。
3. 11〜15日目：Ads Managerへ登録し、処理結果とエラーを分類します。エラー修正を商品マスター側へ戻します。
4. 16〜20日目：用途や収益性で広告グループを設計し、少額・限定範囲で配信を始めます。
5. 21〜25日目：商品数、対象数、配信数を照合し、価格差、欠品、リンク切れの監視を整えます。
6. 26〜30日目：更新方式、担当者、休日対応、復旧手順、週次レポートを文書化して通常運用へ移します。

成功条件は「全商品を入れた」ではなく、商品情報が正しく、更新が止まらず、配信対象を説明でき、問題時に戻せることです。最初の30日は商品数を増やすより、データ品質と復旧の再現性を優先してください。

担当者別の日次・週次・月次チェック

頻度	商品担当	広告担当	システム担当
日次	価格変更、欠品、終売、セール終了を確認	配信状態、急な商品数減少、広告表示を確認	ファイル生成、URL取得、SFTP転送の成功を確認
週次	説明・画像の更新漏れを確認	商品群別の費用、クリック、成果を比較	エラー傾向、再送、処理時間を確認
月次	商品マスターの棚卸し	分類・フィルター・広告グループを見直す	資格情報、権限、ログ保存、復旧手順を点検

各チェックには「異常なし」を選べるだけでなく、確認した件数と証拠へのリンクを残します。日次確認を一人へ依存させず、休暇時の代行者と連絡先も決めておきます。セール開始日や大型商品更新日は通常より確認回数を増やし、更新前のファイルを一定期間保存してください。

フィードのセキュリティと権限管理

商品フィードには公開商品情報が中心でも、仕入れ値、社内分類、未公開商品、顧客データを誤って含めてはいけません。広告配信に必要な列だけを専用の出力処理で作り、元データベースの全列をそのままエクスポートしないでください。

• ホストURLはフィード専用とし、ディレクトリ一覧や別ファイルを公開しない。
• SFTPの資格情報は担当者個人で共有せず、専用アカウントと安全な保管先を使う。
• 退職・異動時にアクセスを削除し、鍵やパスワードの更新日を記録する。
• 検証用ファイルにも顧客名、注文番号、メールアドレスを入れない。
• 出力・転送・設定変更のログを保存し、誰が何を変えたか追跡できるようにする。

障害調査でサポートへ例示商品を送る場合も、必要な商品ID、発生時刻、画面、エラーだけに絞ります。SFTPの秘密鍵や認証情報そのものは共有しません。

成果が出ないときの改善順序

配信成果が弱いとき、すぐに商品を大量追加するのではなく、データ品質、対象商品の選び方、広告テンプレート、遷移先、予算の順に切り分けます。価格や在庫が違えば成果以前の問題であり、広告グループの商品が広すぎれば何が効いたか判断できません。

1. 商品URL、画像、価格、在庫が正しいか再確認する。
2. 広告グループのフィルターが想定商品へ一致しているか確認する。
3. 実際の広告プレビューと遷移先のメッセージがつながっているか確認する。
4. 商品群別に費用と成果を比較し、利益や在庫を含めて評価する。
5. 一度に一つの変更を行い、変更日と判断期間を記録する。

クリック率だけで優劣を決めると、安価だが利益の出ない商品へ偏る可能性があります。売上、粗利、返品、在庫回転、購入後の継続など、自社の事業指標と結びつけてください。広告レポートの数値とEC側の注文を照合する際は、期間、タイムゾーン、計測定義をそろえます。

商品フィード公開前の最終チェックリスト

• 公式の最新仕様で列名、形式、必須条件を確認した。
• 商品IDは重複せず、継続更新でも安定している。
• 価格、通貨、在庫、販売状態が商品ページと一致している。
• 商品URLと画像URLを外部環境から取得できる。
• 禁止・制限カテゴリと広告表現を確認した。
• フィード全体の件数と広告グループ対象件数を記録した。
• 複数商品で広告テンプレートをプレビューした。
• 更新頻度、担当、休日対応、期限切れ防止を決めた。
• 失敗時に戻せる前回ファイルと変更履歴がある。
• 配信後の反映待ちとProductsタブの性質を担当者が理解した。

この十項目のどれかが確認できない場合は、未確認のまま全商品へ広げず、少数商品で問題を閉じてから拡大します。

公開後の初回確認では、代表商品だけでなく、最高価格・最低価格、セール対象、在庫僅少、長い商品名、画像差し替え直後の商品も選びます。境界条件の商品を確認すると、通常商品では見えない表示崩れや更新漏れを早く発見できます。問題があった商品は修正が完了するまで対象から外し、フィード全体を止めるべき障害か、個別商品の障害かを分けて判断してください。

確認結果は日付、担当者、対象商品IDとともに保存し、次回更新時の比較基準として再利用します。

あわせて確認したい関連記事

• ChatGPT広告の出し方
• ChatGPT広告の料金
• ChatGPT広告のターゲティング
• ChatGPT広告の効果測定
• ChatGPT広告代理店の選び方

よくある質問

商品フィードは何商品から使えますか？

公式は一律の最小商品数を示していません。商品数より、更新頻度と手動作業の負担で判断します。

CSVを一度入れれば更新不要ですか？

いいえ。商品は2週間で期限切れになるため、継続運用では再アップロード、ホストURL、SFTPなどの更新が必要です。

フィード登録で自然なChatGPT回答にも商品が出ますか？

2026年9月確認時点では広告利用のための登録であり、通常会話への自然掲載を保証しません。

処理にはどれくらいかかりますか？

商品数などにより数分から数時間かかる場合があります。Upload Historyで進行とエラーを確認します。

Productsタブが空なのは失敗ですか？

必ずしも失敗ではありません。配信データが発生した商品を表示するレポート画面で、反映に最大7時間程度かかる場合があります。

広告テンプレートはいくつ必要ですか？

公式案内では広告グループごとに一つです。プレビューで商品ごとの表示を確認します。

監修：魚見幸司
AI活用マーケティング総合研究所

商品フィードを大量入稿の手段だけでなく、価格・在庫・リンク・審査・更新・収益を一貫して管理する運用基盤として扱う方針で監修しました。

参照した一次情報

• OpenAI：Create Campaigns from Product Feeds
• OpenAI：Troubleshooting Common Issues
• OpenAI：Ad policies

最終確認日：2026年9月4日。必須項目、許容値、画面、更新条件は変更される可能性があります。入稿前にAds Managerの最新フィード仕様を確認してください。