データフィードの作り方｜CSV・XML・API連携と更新方式を実務目線で整理

この記事の要点

• データフィードの作り方は「項目を並べる」前に、正となる商品データと更新要件を決めます。
• CSVは簡単、XMLは階層表現、APIは高頻度・差分更新に向きます。
• 共通マスターから媒体ごとの差分を変換する構成にすると、多媒体運用で更新漏れを減らせます。
• 作成後は形式チェック、必須属性、URL、価格、在庫、IDを検証し、媒体の診断まで確認します。
• 自動化するなら、生成処理より先に失敗検知と再送手順まで決めます。

データフィードの作り方は何から始めるか

データフィードを作る最初の作業は、CSVの列を作ることではありません。商品情報の正データがどこにあるかを決めます。

価格はECカート、在庫は基幹システム、商品説明はPIM、画像URLはCMSのように情報が分散している場合、どのシステムを正としてフィードへ集めるかを定義します。

次に、媒体が要求する項目へマッピングします。社内のsku_codeを媒体のidへ、sales_priceをpriceへ、在庫数をavailabilityの許可値へ変換する、といった対応です。

元データを棚卸しする

最初に次を一覧化します。

データ	正となるシステム	更新者	更新頻度	フィード利用
商品ID	商品マスター	商品登録担当	商品登録時	必須
商品名	商品マスター	商品担当	随時	必須
価格	EC/基幹	販売担当	高頻度	必須
在庫	在庫DB	自動	高頻度	必須
画像URL	CMS/CDN	制作担当	随時	必須
GTIN	商品マスター	商品登録担当	登録時	媒体により推奨/必要

正データが決まっていないと、ECサイトは新価格、フィードは旧価格という状態が起きます。

媒体仕様を列単位で整理する

媒体のテンプレートを見て、そのままCSVを作る前にマッピング表を作ります。

例:

社内項目	Google向け	TikTok向け	変換ルール
sku_code	id	item_id	そのまま
product_name	title	title	文字数を調整
stock_qty	availability	availability	1以上→in_stock
tax_in_price	price	price	通貨を付与
main_image	image_link	image_link	HTTPS URL

この表があると、媒体仕様変更の影響を特定しやすくなります。

CSVで作る場合

CSVは1行1商品、列に属性を持たせる形式が一般的です。小〜中規模のフィードを始めるには扱いやすい方式です。

注意するのは、カンマを含む商品説明、改行、ダブルクォート、文字コード、先頭ゼロ、日付、価格形式です。表計算ソフトで開いて保存しただけで、JANコードの先頭ゼロが落ちることもあります。

CSV生成は可能ならスクリプトやETL処理で自動化し、手作業編集は例外対応に限定します。

XMLで作る場合

XMLは階層構造を表現しやすく、媒体がXML形式を提供している場合に使います。タグで項目名が明示されるため、列順への依存は小さくなります。

一方、タグ閉じ忘れ、エスケープ、名前空間など、CSVとは別の検証が必要です。商品説明に&や<が入る場合も正しく処理します。

既存のCMSやECプラットフォームがXMLフィードを出力できるなら、その機能を使う方が開発負荷を抑えられる場合があります。

APIで作る場合

API連携は、商品データをプログラムから媒体へ送る方式です。高頻度更新、差分更新、商品数が多いケースに向きます。

実装時は認証、レート制限、タイムアウト、リトライ、重複送信、部分失敗、削除、ログを設計します。成功レスポンスを受け取っただけでは、媒体審査まで成功したとは限りません。送信結果と媒体側の診断を分けて監視します。

方式選定表

条件	CSV/TSV	XML	API
手軽さ	高い	中	低い
高頻度更新	△	△	◎
差分更新	△	△	◎
手作業確認	◎	△	△
開発負荷	低	中	高
大量商品	○	○	◎

最初からAPIを選ぶ必要はありません。日次更新で十分な商品群なら、安定したCSV生成と監視の方が総工数を抑えられることがあります。

変換ルールを別管理する

商品マスターを媒体仕様に合わせて直接変更すると、複数媒体で使い回しにくくなります。元データと変換ルールを分けます。

代表的な変換は次です。

• 在庫数から媒体の在庫ステータスへ変換
• 税込/税別価格の整形
• ブランド表記の統一
• カテゴリコードのマッピング
• タイトルの文字数調整
• URLへのパラメータ付与
• 空欄時の処理
• 禁止文字の除去

例外ルールが増えたら、適用順序を決めます。「全商品共通→カテゴリ別→ブランド別→個別SKU」のように優先順位を固定します。

商品IDを決める

IDは後から変えない前提で設計します。サイト側タグ、広告カタログ、分析基盤で同じ商品を識別できるようにします。

親商品IDとSKUのどちらを使うかは、在庫と価格の管理単位で判断します。色やサイズごとに在庫が違うなら、SKU単位IDの方が扱いやすいケースが多くなります。

IDに商品名や価格を含めると、名前変更や価格変更でIDまで変わる設計になりやすいため避けます。

事前検証を作る

媒体へ送る前に、最低限のチェックを自動化します。

1. ID空欄と重複
2. 必須項目空欄
3. URL形式
4. 画像URL形式
5. 価格の数値形式
6. 在庫値の許可値
7. 文字数
8. GTIN桁数や形式
9. 不正文字
10. 商品件数の急減

「前回10,000件だったフィードが今回200件」なら、200件すべてが仕様上正しくても送信前に止めるべきです。件数変化の監視は、項目検証とは別に用意します。

テスト商品で媒体へ送る

初回は全商品を送る前に、カテゴリやバリエーションが異なる代表商品を選びます。通常商品、セール商品、在庫切れ、バリエーション商品、GTINなし商品などを含めると検証範囲が広がります。

媒体側で承認されるか、タイトルと画像が意図どおり表示されるか、価格と在庫が合うかを確認します。

更新方式を決める

全件更新は実装が単純ですが、商品数が多いと負荷が増えます。差分更新は効率的ですが、削除や更新漏れの管理が難しくなります。

高頻度で変わる価格と在庫だけ差分更新し、商品説明やカテゴリは日次全件更新するなど、属性によって経路を分ける方法もあります。

更新頻度は媒体の上限だけでなく、自社の許容遅延から決めます。

失敗時の再送と監視

自動化では、成功ルートより失敗ルートを先に決めます。

• ファイル生成に失敗した
• 0件になった
• 送信先に接続できない
• APIの一部だけ失敗した
• 媒体側で大量不承認になった
• 価格不一致が急増した

それぞれで「自動再試行する」「送信を止める」「担当者へ通知する」の条件を決めます。

媒体追加時は共通マスターから分岐する

Google、Meta、Criteo、LINEヤフー、TikTokへ配信する場合、媒体ごとに別の商品マスターを手作業で持つと二重管理になります。

共通商品マスターを持ち、媒体ごとの変換ルールで出力を分けます。Criteoのように既存Google/Facebook系フィードを再利用できる媒体でも、取込後の項目確認は行います。

最小構成サンプル

小規模ECで最初に作るなら、次の構成でも始められます。

• 商品マスター: 商品ID、商品名、価格、在庫、URL、画像URL、ブランド
• 生成: 1日1回CSV
• 検証: ID重複、必須項目、URL、価格、在庫、件数
• 配信: 1媒体
• 監視: 最終成功時刻、送信件数、媒体不承認数
• 通知: 更新24時間停止、件数50%以上減少、大量不承認

ここから商品数、媒体数、更新頻度に合わせてAPIや差分更新へ拡張します。

実務チェックリスト

• 正データ元を項目ごとに決めた
• 媒体仕様と社内項目のマッピング表がある
• IDの生成規則が固定されている
• CSV/XML/APIの選定理由を説明できる
• 変換ルールを元データと分離した
• 必須項目の事前検証がある
• 商品件数の急減を検知できる
• 送信ログを保存している
• 媒体診断を確認している
• 更新失敗時の再送条件がある
• 担当者通知の経路がある
• 媒体仕様変更時に影響箇所を追える

公式情報と更新時点

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

媒体ごとの受け付け形式、必須属性、API仕様は変更されます。Google Merchant Centerなど対象媒体の公式ヘルプで実装時点の仕様確認を推奨します。

• データフィードとは
• データフィード広告とは
• Google Merchant Centerの商品フィード完全ガイド

フィード仕様書を作る

実装後に担当者が変わっても維持できるよう、フィード仕様書を残します。

仕様書には、項目名、型、必須/任意、正データ元、変換ルール、空欄時処理、最大文字数、例、更新頻度を記載します。

変換コードだけを仕様書代わりにすると、広告運用担当が確認できません。表形式で人が読める仕様を用意します。

差分更新で削除漏れを防ぐ

差分更新では、追加・変更だけでなく削除を扱う必要があります。販売終了商品を商品マスターから消しただけでは、媒体側に残る場合があります。

削除対象を明示的に送るのか、定期的な全件同期で整合させるのかを決めます。週1回全件、日中は差分、といった組み合わせもあります。

テスト環境がない媒体への対応

媒体によっては本番アカウントでしかフィード取込を試せない場合があります。その場合は、少数の商品セットやテスト用ラベルで影響範囲を絞ります。

送信前にローカル検証を強くし、商品件数、必須項目、URL、価格、在庫をチェックします。

ロールバックを用意する

変換ルール変更で全商品タイトルが壊れた場合、すぐ前バージョンへ戻せるようにします。

フィード生成コード、変換ルール、カテゴリマッピングをバージョン管理し、直前の正常フィードも一定期間保存します。

本番運用の監視SLAを決める

更新失敗の許容時間を決めます。

例えば、価格・在庫更新は2時間以内に復旧、商品説明更新は翌営業日でも可、といった形です。属性ごとに鮮度要件が違うため、すべて同じSLAにする必要はありません。

データ型を明示する

フィード仕様書では文字列、数値、真偽値、日時、URLなどの型を明示します。価格を文字列として自由入力できると、1,980円、1980、1,980 JPYのように表記が揺れます。

変換前の型と媒体へ送る型を分けて定義します。

日時とタイムゾーン

セール開始・終了、在庫反映、バッチ時刻を扱う場合、タイムゾーンを固定します。日本向けならJST基準か、システム内部UTCかを仕様書へ書きます。

セール終了が1時間ずれるだけで価格不一致が発生することがあります。

監視ログの保存期間

更新失敗が翌月に発覚した場合でも原因を追えるよう、送信ログと生成ファイルを一定期間保存します。

少なくとも最終成功時刻、商品件数、エラー件数、処理時間、ファイルハッシュなどを残すと差分調査に使えます。