EC Choice AI

BLOG

ECデータ連携で最初に決めること — APIより先の定義とキー

モールやカートを増やすたびに、CSVやAPIの「つなぎ」が増えます。増えたあとに崩れるのは、多くが接続そのものではなく 定義・キー・欠損・確定タイミング です。画面ではつながっているのに、横断すると売上が合わない、商品が二重に見える、ある日だけゼロになる——こうした症状の多くは、連携を足す前に固定すべき前提が口頭のまま残っているときに起きます。

この記事の ECデータ連携 は、一元管理ツールの比較表ではありません。APIやCSVを選ぶ前に文章で決めるリスト、よくある失敗、1モールから横断へ広げる最小手順を整理します。売上の見え方そのものは EC売上の見える化、Shopify単体の見る順は Shopify分析 を参照し、本稿は つなぐ前の設計 に絞ります。

連携が増えるほど崩れるのは「定義」

受注・在庫・商品マスタは、モールごとに発生源と項目名が違います。実務では次が混在しやすいです。

  • 受注はモール画面やCSV、在庫は倉庫表、商品番号は各モールの管理番号
  • 「売上」「確定」「キャンセル戻し」の意味がチーム内で揃っていない
  • 欠損（まだ取れていない日・未紐づけSKU）をゼロとみなして合計してしまう

公開資料でも、基幹やモールをつなぐ前に データの正（マスタ）を領域ごとに決め、キーと更新頻度を一覧化する ことが前提として繰り返し書かれています。ツール選定より先に、社内で1枚の定義表を持つ方が手戻りが小さいです。

連携前に固定するリスト

CSVやAPIの接続作業に入る前に、次を Yes/No ではなく 1行の文章 で書きます。

1. モール・チャネル一覧

  • いま接続する対象（例: Amazon / 楽天 / Shopify / 自社）を列挙する
  • 「将来つなぐ予定」は別行にし、今回の範囲と混ぜない

2. 期間定義

  • タイムゾーン（例: 日本時間の暦日）
  • 基準日は注文日か、支払完了日か、出荷日か、売上確定日か
  • キャンセル・返品をいつ数字から戻すか

3. 売上定義

  • 税込か税抜か
  • 送料・ポイント・クーポンを含めるか
  • グロスか、キャンセル・返品後の純額か

モール画面の「売上」ラベルと自社定義の写像を1表にする。横断の足し算は、この写像のあとです。

4. SKU／商品キー

  • 横断の主キー（社内SKUなど）を1つ決める
  • モール側ID（ASIN、楽天商品管理番号、Shopify variant など）は別名として紐づける
  • キー欠落行の扱い（落とす／未紐づけ枠）。ゼロ埋めして合計に混ぜない

商品追加のたびに対応表を誰が更新するかも、運用として書いておきます。対応表の更新漏れは、取り込みエラーや二重計上の典型原因です。

5. 欠損の扱い

  • あるモールだけ連携が遅れている日を、売上ゼロとみなさない
  • 「未取得」「取得失敗」「キー未紐づけ」を状態として残す
  • 合計や平均に入れる条件を一文で決める

6. 確定タイミング

  • 日次の締め時刻（何時までの注文をその日の確定とするか）
  • 締め前の速報と、締め後の確定値を同じ列に載せない
  • 再送・再取込で二重にならないよう、注文番号など一意キーでの重複排除を前提にする

受注のように鮮度が要る領域と、商品マスタのように日次バッチで足りる領域は、同じ「即時API」に寄せる必要はありません。領域ごとに許容遅延を決め、方式（API／CSV）は後から選びます。

よくある失敗

ゼロ埋め欠損

取れなかった日や未紐づけSKUを 0 にして合計すると、見た目はきれいでも実態は「欠測」です。ダッシュボード上は売上が落ちたように見え、施策の議論が空転します。欠測は欠測のまま残します。

キー不一致

モール商品IDだけを主キーにすると、同じ実物がモールごとに別行になります。逆に、表記ゆれの商品名で結合すると誤結合が起きます。社内SKUを正とし、モールIDは写しとして持つ方が安全です。

締め前確定

セール中の速報を「確定売上」と同じ列に入れると、翌日の確定で毎回数字が動きます。速報と確定を分け、会議で使う表はどちらを正とするかを先に決めます。

在庫の正が複数ある

モール管理画面で在庫を直接いじると、次の同期で上書きされるか、正とずれます。在庫の正を一か所に決め、各モールへ配る数は「正から配る写し」と位置づける、という整理がバックオフィス設計でも繰り返し出てきます。

方式から入る

「まずAPIで全部つなぐ」と決めると、主従・キー・欠損が未決のまま実装が進み、結合テストで定義論争が始まります。方式は、定義リストと許容遅延が埋まったあとの選択です。

最小連携の進め方（1モール実証 → 横断）

一度に全モール・全領域をつなぐと、不具合の切り分けができなくなります。次の順が扱いやすいです。

  1. 定義リストを埋める — 上の期間・売上・キー・欠損・締めを1枚にする
  2. 商品キー対応表を整える — 対象モールのID ↔ 社内SKU。未対応は通知する
  3. 1モールで受注（または売上）だけ実証 — 取り込み漏れ・重複・キー欠落を数日見る
  4. 同じ定義で2モール目を足す — 足し算の前に写像表を確認する
  5. 在庫や出荷など領域を広げる — 領域ごとに正と更新頻度を追加する
  6. 監視 — 最終成功時刻・エラー通知先・欠測の見える化を運用に入れる

「スプレッドシートで全モールを毎朝結合する」運用からの移行も、いきなり全自動にせず、定義とキーが同じ場所に残ることを先に満たす方が安全です。転記表そのものの見極めは、売上見える化の記事側に寄せています。

チェックリスト（コピー用）

  • 今回つなぐモール／チャネル一覧を書いた（予定は別行）
  • 期間定義（TZ・基準日・キャンセル戻し）を1行で書いた
  • 売上定義（税・送料・クーポン・純額/グロス）を1行で書いた
  • 横断の商品キーと、欠落時の扱い（ゼロ埋めしない）を決めた
  • 欠損（未取得・失敗・未紐づけ）を状態として残すルールがある
  • 速報と確定の列を分け、締め時刻を決めた
  • 注文など一意キーでの重複排除を前提にした
  • 領域ごとに正（マスタ）と許容遅延を決め、その後にAPI/CSVを選ぶ
  • 1モール実証の合格条件（漏れ・重複・キー）を先に書いた
  • エラー通知先と、最後に成功した同期時刻の置き場がある

すべて Yes になる前に、新しい連携先やダッシュボードの話に進まない方が手戻りは小さいです。

次の一手

定義・キー・欠損の前提を揃えたうえで、モール横断の実測を手元に置きたい場合は、EC Choice AI の無料登録から始められます。料金の比較は料金プランからどうぞ。

本記事の主CTAは上記の登録と料金です。

まとめ

ECデータ連携で最初に決めるのは、APIのベンダー名ではありません。モール一覧・期間・売上定義・商品キー・欠損扱い・確定タイミング を文章で固定し、1モールで実証してから横断と領域を広げることです。ゼロ埋め・キー不一致・締め前確定を潰したうえで方式を選ぶと、つながったあとの数字論争を減らせます。先にチェックリストを埋め、同じ定義で実測できる状態を作ってください。

関連記事