データフィードとは？仕組み・用途・広告配信まで体系解説

この記事の要点

• データフィードとは、商品名、価格、在庫、画像URLなどを外部システムへ連携するために一定の形式で整理したデータです。
• 実務では「元データをそのまま送る」のではなく、媒体仕様に合わせて項目名、値、文字数、更新頻度を変換します。
• 広告成果以前に、価格不一致、在庫切れ掲載、ID不整合を減らす運用基盤として考えると役割が分かりやすくなります。
• CSV、XML、APIは目的ではなく受け渡し方式です。商品数、更新頻度、媒体数、開発体制で選びます。
• 配信後は承認率、欠損、鮮度、価格と在庫の一致を監視し、商品属性を継続的に改善します。

データフィードとは何か

データフィードとは、商品名、価格、在庫、商品ページURL、画像URL、ブランド、商品カテゴリなどの情報を、広告媒体やECモールなど外部システムへ連携するために一定の形式で整理したデータです。

ECサイトの商品一覧を例にすると、サイト内部には商品マスターや在庫DBがあります。一方、Google、Meta、Criteo、LINEヤフー、TikTokなどは、それぞれ別の項目名とルールで商品情報を受け取ります。そこで元データを媒体ごとの形式へ変換し、定期的に送信する処理が必要になります。

データフィードは「ファイル名」ではありません。CSV、TSV、XML、JSON、APIなど、受け渡し方法はいくつもあります。重要なのは、外部システムが必要とする項目を、決められた形式と更新タイミングで届けることです。

データフィードはどこで使われるのか

代表的な用途は商品広告です。利用者が過去に閲覧した商品や、検索語句と関連する商品を広告として表示するとき、広告媒体は商品ID、価格、在庫、画像、リンク先などを参照します。

用途は広告だけではありません。Merchant Centerの無料リスティング、商品比較、レコメンド、サイト内検索、アフィリエイト連携、在庫連携などでも同じ考え方を使えます。事業者側から見ると、社内にある商品情報を外部サービスへ安全に渡すための共通インターフェースです。

EC以外でも構造は同じです。求人なら求人ID、職種、勤務地、給与、応募URL。不動産なら物件ID、価格、間取り、所在地、画像URL。旅行ならプランID、出発地、料金、空席情報、予約URLがフィードの中心になります。

業種	1件を識別するID	変動しやすい情報	表示に使う主な情報
EC	商品ID/SKU	価格、在庫、セール価格	商品名、画像、ブランド
求人	求人ID	募集状態、給与条件	職種、勤務地、雇用形態
不動産	物件ID	価格、空室状況	物件名、所在地、間取り
旅行	プランID	料金、空席、日程	プラン名、画像、行程

商品DBから広告表示まで何が起きるのか

実務では、次の処理を分けて考えるとトラブルを追いやすくなります。

1. 商品マスターから必要項目を取得する
2. 媒体ごとの項目名と値へ変換する
3. 必須項目、文字コード、URL、価格形式などを検証する
4. ファイル送信またはAPIで媒体へ登録する
5. 媒体側で仕様チェック、ポリシー審査が行われる
6. 承認された商品が広告や無料掲載の候補になる
7. 価格、在庫、商品名などの変更に合わせて再送する

この流れで最も多い誤解は、媒体への送信が完了すれば配信準備も完了したと考えることです。実際には送信後にエラー、不承認、警告が発生します。さらに配信中の商品でも、サイト上の価格とフィード価格がずれると問題になります。

データフィードに含める主な商品情報

媒体によって必須項目は違いますが、共通して扱うことが多いのは次の項目です。

• 商品を一意に識別するID
• 商品名
• 商品説明
• 商品ページURL
• メイン画像URLと追加画像URL
• 価格とセール価格
• 在庫状況
• ブランド
• GTINやMPNなどの商品識別子
• 商品カテゴリ
• 色、サイズ、素材などの商品属性

各項目は「存在するか」だけでなく「意味が正しいか」を確認します。例えばGTIN欄に社内SKUを入れると、形式上は文字列が入っていても商品識別子としては誤りです。Googleは固有商品IDについて、GTIN、MPN、ブランドを正しく提供し、推測した値や類似商品の値を入れないよう案内しています。

商品タイトルも同様です。商品名が入っていれば終わりではありません。色、サイズ、型番、対象者など、検索や商品理解に必要な情報が欠けると、媒体側がユーザーの検索や興味関心と商品を結び付けにくくなります。

CSV・XML・APIの違い

CSVは表計算で扱いやすく、仕組みも単純です。商品数が少なく、日次程度の更新で足りる場合に扱いやすい方式です。XMLは階層構造を持てるため、複雑な属性を扱う媒体で使われます。APIは差分更新や高頻度更新に向きますが、認証、再送、レート制限、エラー処理まで含めた実装が必要です。

方式	向いている状況	長所	注意点
CSV/TSV	小〜中規模、日次更新	作成と確認が容易	項目増加で管理が煩雑になりやすい
XML	階層情報や既存仕様に合わせる	表現力が高い	手作業での確認は難しい
API	高頻度、差分更新、大規模	鮮度を上げやすい	開発と監視が必要

詳しい選定はデータフィードの作り方で扱います。

フィード変換で何を加工するのか

商品DBの項目名と媒体の項目名は一致しないことが多いため、変換層を用意します。例えば社内のstock_status=1を媒体側のin_stockへ変える、税込価格へ整形する、商品URLへ計測パラメータを加える、といった処理です。

変換ルールは元データを書き換えず、媒体ごとの差分として持つと保守しやすくなります。Google向けの文字数制限に合わせた商品名を商品DBへ上書きしてしまうと、他媒体や自社サイトで使う商品名まで影響を受けます。

変換時に確認したい項目は、値の置換、文字数、禁止文字、通貨、税、URL、画像サイズ、カテゴリマッピング、欠損時の処理です。例外商品を手作業で修正する場合も、修正理由と期限を記録します。

更新頻度は価格と在庫の変動から決める

更新頻度を「毎日1回」と固定する前に、商品情報がどの程度変化するかを確認します。欠品が1時間単位で起きる商品と、年に数回しか価格が変わらない商品では必要な鮮度が違います。

更新が遅いと、広告上は在庫ありなのにサイトでは売り切れ、広告上の価格と商品ページの価格が違う、といった状態が発生します。逆にほとんど変わらないデータを数分ごとに全件送信しても、システム負荷と運用コストが増えるだけです。

実務では「変動率」と「許容遅延」を決めます。例えば在庫変動が激しく、欠品表示を30分以内に反映したい商品群はAPIや差分更新を検討します。商品説明やブランドのように変化が少ない項目は、同じ更新頻度で送る必要はありません。

商品IDは後から変えない前提で設計する

商品IDは媒体とサイト側の行動データを結び付けるキーになります。リターゲティングやカタログ広告では、サイトで計測した商品IDとフィード内の商品IDが一致しないと、閲覧商品と広告商品を対応付けられません。

途中でID体系を変えると、媒体上では別商品として扱われる場合があります。SKU統合、商品マスター移行、ECカート変更のときは、広告運用側も含めてID変更の影響を確認します。

商品バリエーションがある場合も、親商品IDと子SKUのどちらを媒体IDに使うかを最初に決めます。色やサイズごとに価格、在庫、GTINが異なるなら、通常はバリエーション単位で一意のIDが必要です。

品質は「必須項目が埋まっているか」だけで判断しない

フィード品質は4段階で見ると整理しやすくなります。

段階	確認内容	代表的な問題
形式	ファイルを読めるか	文字コード、区切り、XML構文
仕様	媒体ルールを満たすか	必須項目欠損、値の形式違反
一致	サイトと同じ内容か	価格不一致、在庫不一致、URL切れ
表現	商品を十分説明できるか	タイトル不足、画像不足、分類粗さ

形式と仕様だけ通っても、広告成果につながる商品データとは限りません。例えば商品タイトルが「ABC-123」だけでは、承認されてもユーザーが何の商品か判断しにくくなります。

商品フィード最適化の基本では、タイトル、説明、画像、カテゴリ、GTINをどう改善するかを属性別に整理しています。

媒体ごとの違いをどう管理するか

複数媒体を使う場合、媒体ごとに商品マスターを作ると更新漏れが起きやすくなります。実務では、共通の商品マスターまたは基準フィードを持ち、媒体固有の差分だけ変換する形が扱いやすくなります。

例えばGoogle向けにはGTINやGoogle商品カテゴリを追加し、LINEヤフー向けには商品セットで使う分類項目を整え、TikTok向けには用途に合うカタログ項目を出します。Criteoは公式ヘルプで、既存のGoogleまたはFacebook系の商品フィードを再利用してProduct Catalogを設定できると案内しています。完全に同一の運用で済むとは限らないため、再利用後に項目差分と審査結果を確認します。

導入前に確認する項目

データフィード導入前は、媒体選定より先に社内データの状態を確認します。

• 商品を一意に識別できるIDがあるか
• 価格と在庫をどのシステムが正とするか
• 商品画像を安定したURLで取得できるか
• 商品ページURLが商品ごとにあるか
• ブランド、GTIN、カテゴリなどが商品マスターに存在するか
• 価格変更と在庫変更を何分以内に反映したいか
• エラー通知を誰が受けるか
• 媒体仕様変更を誰が確認するか

商品DBに必要情報が存在しない場合、フィード変換だけでは解決できません。例えばGTINが商品マスターにないなら、仕入れ先や商品登録フローから取得する仕組みが必要です。

運用開始後に見る指標

広告管理画面のROASだけを見ると、データフィードの問題を見落とします。フィード運用側では、少なくとも次を確認します。

1. 登録商品数
2. 承認商品数と不承認商品数
3. 必須属性の欠損数
4. 価格不一致、在庫不一致の件数
5. 画像エラー、リンク切れ
6. 最終更新時刻と更新遅延
7. 商品IDの重複と欠落

広告成果を見るときは、商品データ変更日を記録します。タイトルを変えた日、画像を追加した日、GTINを補完した日が残っていないと、成果の変化とフィード改善を対応付けられません。

データフィードが向いているケースと向いていないケース

商品数が多いほど相性は良くなりますが、商品数だけで判断しません。更新頻度が高い、配信媒体が複数ある、手作業での入稿ミスが起きている場合は、小規模でも自動化の効果があります。

一方、商品が10点程度で半年に一度しか情報が変わらず、利用媒体も1つだけなら、専用ツールや複雑なAPI連携を作る必要はない場合があります。媒体の管理画面から直接登録した方が総工数を抑えられることもあります。

判断時は初期開発費だけでなく、毎月の修正、仕様変更対応、エラー監視、担当者引き継ぎまで含めて比較します。

実務チェックリスト

公開前、媒体追加時、ECリニューアル時には次を確認します。

• 商品IDがサイト計測と一致している
• 商品名が実商品を正確に表す
• 商品ページURLが200系で応答する
• 画像URLが外部から取得できる
• 価格の通貨と税込/税別の扱いが正しい
• 在庫値が媒体の許可値へ変換されている
• セール価格の開始・終了条件が正しい
• GTIN、MPN、ブランドを推測値で埋めていない
• カテゴリ変換ルールに未分類商品が残っていない
• 送信後の媒体診断を確認している
• 全件更新と差分更新の失敗時に再送できる
• エラー通知の担当者が決まっている

公式情報と更新時点

最終確認日: 2026年8月29日。

Google Merchant Centerの商品データ仕様、画像、固有商品IDなど変更されやすい項目は公式ヘルプを確認しています。Googleは2026年4月14日に商品データ仕様更新を発表し、2027年1月31日から商品画像を500×500ピクセル以上とする新要件を案内しています。媒体仕様は変更されるため、実装時は各媒体の公式ヘルプの確認を推奨します。

• Google Merchant Center 2026年商品データ仕様更新
• Google Merchant Center 商品画像リンク
• Google Merchant Center 固有商品ID

次の理解には、データフィード広告とは何かとデータフィードの作り方がつながります。

データフィードの担当範囲を組織で分ける

データフィードは広告担当だけで完結しないことが多く、商品登録、EC運営、開発、広告運用の境界にあります。担当範囲が曖昧だと、エラーが起きたときに「広告側の問題」「商品DB側の問題」と担当者間で行き来します。

実務では、項目ごとに責任者を決めます。商品名とブランドは商品登録担当、価格はEC運営、在庫は基幹システム、フィード変換は開発、媒体診断は広告運用、といった分担です。さらに、障害時の一次対応者も決めます。

事象	一次確認	次の確認
商品が媒体へ出ない	広告運用: 不承認・警告	開発: 送信ログ
価格が違う	EC運営: 正価格	開発: 変換・更新時刻
在庫が違う	在庫担当: 正在庫	開発: 差分更新
画像が出ない	制作/EC: 元画像	開発: URL取得
商品名が古い	商品担当: マスター	開発: 更新対象

担当表を作ると、媒体障害の復旧時間を短くできます。

ECリニューアル時に起きるフィード事故

ECサイトのリニューアルは、データフィードへ大きな影響が出る作業です。URL、商品ID、画像CDN、価格取得元、在庫API、カテゴリ体系が同時に変わる可能性があります。

特に注意するのは商品IDです。旧ECではSKUを商品IDに使い、新ECでは内部連番へ変わる場合、広告媒体やイベント計測との対応が切れます。リニューアル前に「維持するID」と「変更するID」を一覧にします。

URLも同様です。商品ページURLが変わるなら、フィードのlinkだけでなく、リダイレクト、計測パラメータ、広告審査を確認します。画像CDNのドメイン変更では、媒体側から新URLを取得できるかをテストします。

リニューアルの切替日には、旧フィードと新フィードの商品件数、価格、在庫、URLをサンプリング比較します。全件一致を自動検証できるなら、切替前の確認精度が上がります。

商品削除と販売終了をどう扱うか

商品追加より難しいのが削除です。商品マスターから消えた商品が媒体カタログに残ると、販売終了後も広告候補に残る場合があります。

全件更新なら、媒体が新しい全件ファイルを正として削除を反映できる仕組みか確認します。差分更新では、削除イベントを明示的に送る必要がある場合があります。

販売終了と一時欠品も分けます。一時欠品なら在庫状態だけ変え、再入荷時に同じ商品IDで復活させます。販売終了なら、媒体側で削除または恒久的な非表示にします。

商品IDを再利用しないことも基本です。過去に販売終了したP001を別の商品へ割り当てると、媒体や分析基盤で旧商品の履歴と混ざる可能性があります。

データフィードの障害を5種類に分ける

障害対応は、原因を次の5種類に分けると早くなります。

1. 取得障害: 商品DBからデータを取れない
2. 変換障害: 価格や在庫、カテゴリの変換に失敗
3. 送信障害: ファイル転送やAPIが失敗
4. 媒体障害: 受信後の仕様エラーや不承認
5. 鮮度障害: 更新は成功しているが古い

例えば「商品が表示されない」という症状でも、取得段階で商品が欠落しているのか、媒体で不承認なのかでは対処が違います。ログを工程ごとに分けると、どこで件数が減ったか追えます。

データフィードの品質指標を定例で見る

広告成果と別に、フィード品質を運用KPIとして持つと異常を早く見つけられます。

• 生成商品件数
• 送信成功率
• 媒体登録率
• 承認率
• 必須属性欠損率
• 価格不一致率
• 在庫不一致率
• 画像取得エラー率
• 更新遅延時間

これらを日次で全部見る必要はありません。価格・在庫・更新遅延は日次、属性欠損やカテゴリ品質は週次、媒体仕様差分は月次といった分け方ができます。

データフィードとPIM・商品マスターの違い

PIM（商品情報管理システム）は商品情報を社内で統合管理する仕組みで、データフィードはその情報を外部へ渡す形です。PIMがなくてもフィードは作れますが、商品名、画像、ブランド、GTIN、カテゴリが複数システムに分散していると変換処理が複雑になります。

商品情報の正データがどこにあるかを決めたうえで、フィードは配信用の派生データとして扱います。媒体ごとの都合で商品マスター自体を書き換えない方が、複数媒体への展開がしやすくなります。

データフィードと構造化データの違い

ECページの構造化データは、商品ページ内へ商品名、価格、在庫などを機械可読な形で記述する仕組みです。データフィードは、商品一覧をまとめて外部サービスへ送る仕組みです。

両方に同じ商品情報が含まれる場合、価格や在庫が食い違わないようにします。フィードは新価格、構造化データは旧価格という状態が続くと、媒体側の不一致判定につながる可能性があります。

複数国・複数通貨での注意点

海外販売では、通貨、税込/税別、言語、配送、在庫、商品URLが国ごとに変わります。国内向けフィードをそのまま翻訳するだけでは足りません。

同じSKUでも販売国ごとに価格と在庫が違うなら、国別のフィードまたは市場別の属性管理が必要です。商品IDを共通にするか、市場別IDにするかも媒体仕様と分析要件で決めます。

データフィード導入の見積もり項目

開発費だけでなく、次を含めて見積もります。

• 商品マスターの欠損修正
• 変換ルール作成
• 初回媒体審査対応
• 更新バッチ
• API認証更新
• エラー通知
• 仕様変更対応
• 担当者引き継ぎ

商品数が多くてもマスターが整っていれば実装は比較的単純です。逆に商品数が少なくても、価格と在庫が複数システムに分散していると工数が増えます。

初回導入で「成功」と判断する条件

初回は広告売上だけで成功判定しません。まず運用基盤として次が達成できたかを確認します。

1. 対象商品が想定件数登録された
2. 主要商品が承認された
3. 価格と在庫がサイトと一致する
4. 更新が予定時刻に成功する
5. エラー通知が届く
6. 商品IDがイベントと一致する
7. 担当者が修正手順を説明できる

この状態が整ってから、タイトル、画像、カテゴリなど成果改善へ進みます。

データフィードの導入方式を段階化する

最初から全媒体・全SKU・リアルタイム更新を目指すと、要件が膨らみます。導入は段階化できます。

第1段階は、主力1媒体へ日次CSVで配信し、商品ID、価格、在庫、画像、URLの整合を確認します。第2段階で自動生成と監視を入れ、第3段階で複数媒体へ展開し、第4段階で価格・在庫を高頻度更新します。

この順なら、商品マスターの欠損や変換ルールの問題を早い段階で見つけられます。

最終的に見るべき状態

データフィード運用が安定している状態は、商品追加や価格変更が担当者の手作業なしで媒体へ反映され、失敗時だけ人が対応できる状態です。商品マスター、変換、送信、媒体診断のどこで問題が起きたかを追え、担当者が変わっても同じ手順で復旧できることを目標にします。

運用設計の確認

導入後は、商品追加、価格変更、欠品、販売終了の4つを実際に発生させ、媒体へ意図どおり反映されるかを確認します。通常時だけでなく変更時の動きを確認しておくと、障害時の切り分けが早くなります。

運用開始後も、商品追加と販売終了を月次でサンプル確認します。