DAY20では、自社EC、ECモール、実店舗で同じ商品を販売するときの在庫同期を学びました。在庫を同期するには、システムから別のシステムへ、商品や注文の情報を渡す必要があります。その代表的な方法が、APIによる連携、CSVファイルによる連携、担当者による手作業の3つです。

APIなら必ずリアルタイム、CSVなら古い、手作業なら使えない、という単純な話ではありません。APIを使っていても1時間ごとにしか更新しなければリアルタイムとはいえませんし、商品数が10件しかなく月に数回しか変更しない業務なら、手作業のほうが安くて分かりやすい場合があります。大切なのは、最も高度な方法を選ぶことではなく、連携する情報の重要度、更新頻度、間違えたときの影響、運用できる人員を見て選ぶことです。

特定のECサービスやAPIの操作方法ではなく、システム連携を設計するときの共通する考え方を扱います。

先に結論｜3つの方法には、それぞれ向いている仕事がある

更新速度だけを比べると、一般的には「API・Webhook（速い）→定期的なCSV取込→担当者による手動更新（遅い）」の順です。しかし、比較すべきは速度だけではありません。

身近な例で考えると「情報を届ける3つの方法」

学校から家庭へ連絡する場面を想像してください。

学校が予定を登録すると保護者のアプリへ自動で通知される「APIに近い方法」、児童の一覧を表にまとめて別の担当者へ渡す「CSVに近い方法」、担当者が名簿を見ながら一件ずつ電話する「手作業に近い方法」。ECのデータ連携でも、同じように特徴が異なります。

1．データ連携とは何か

データ連携とは、ある場所に登録された情報を、別のシステムでも利用できるように渡すことです。ECでは、次のような情報が連携されます。

単にデータを移すだけでなく、どの情報を、いつ、どの番号でつなぐかを決めることがデータ連携です。

2．APIとは｜システムが情報を受け渡すための窓口

APIは、Application Programming Interfaceの略です。システムが別のシステムに対して、決められた方法で情報を取得・登録・変更するための仕組みです。たとえば、Google Sheets APIには、指定したスプレッドシートや範囲の値を取得したり、特定の範囲へ値を書き込んだり、複数範囲をまとめて更新したりする機能があります。

実際に利用できる操作は、各サービスが公開しているAPIの仕様によって異なります。データは、JSONなどのシステムが読み取りやすい形式で受け渡されることが一般的です。

3．APIを使えば必ずリアルタイムになる？

APIを用意していても、いつ呼び出すかによって更新速度は変わります。注文のたびに呼び出せばリアルタイムに近くなりますが、5分ごとなら最大約5分、1日1回なら日次連携です。

「API対応」と書かれているだけでは、更新速度は分かりません。何をきっかけに動くか、何分ごとに確認するか、エラー時に再実行するか、相手側への反映に何分かかるか、夜間やメンテナンス中も動くかを確認します。

4．Webhookとは｜出来事が起きたことを相手へ知らせる仕組み

Webhookは、注文作成、商品更新、返金などの出来事が発生したとき、サービス側から指定された送信先へ通知する仕組みです。Shopifyの公式開発資料でも、Webhookは店舗で特定の出来事が起きた際に、ほぼリアルタイムで通知を受け取る方法として説明されています。また、システム側から繰り返しAPIへ問い合わせる方法の代わりとして利用できます。

自社システムから定期的に「新しい注文はありますか？」と確認する方法をポーリングと呼びます。Webhookでは、ECで注文が発生した時点でシステム側から通知が届きます。Webhookで「注文が入った」と知らせてもらい、その後APIで詳しい情報を取得する設計もあり、Webhookは通知、APIは情報の取得・登録というように組み合わせて利用できます。

5．Webhookにも失敗はある

Webhookを使っても、通知を必ず一度だけ、正しい順番で受け取れるとは限りません。Shopifyの公式資料では、Webhookの配信順序は保証されず、重複配信を識別する仕組みや、取りこぼしに備えてAPIによる定期的な照合作業を行うことが推奨されています。同じ通知を複数回受け取る、通知の順番が入れ替わる、自社システム停止中に受信できないといったことが起こり得るため、通知IDの記録、二重処理の防止、更新日時の比較、失敗した処理の再実行、定期的な照合の仕組みが必要です。

6．CSVとは｜データを表形式でまとめたファイル

CSVは、Comma-Separated Valuesの略です。商品名、SKU、価格、在庫などを、決められた列に並べて保存します。

CSVファイルを使うと、多数の商品や在庫をまとめて出力・更新できます。Shopifyの公式機能でも、商品情報やロケーション別の在庫をCSVでインポート・エクスポートできます。APIのようにシステム同士が直接つながっていなくても、共通のCSV形式を用意すればデータを移せます（システムAからCSV出力→編集・変換→システムBへアップロード→取込結果を確認）。

7．CSVのメリット

8．CSVの注意点

出力した直後から古くなる可能性があります。10時にCSVを出力し10時30分に取り込む間に、10時10分に2個販売されて実在庫が8個になっていても、古い「10個」で上書きすると販売可能在庫が2個増えてしまいます。Shopifyの在庫CSVには、現在値と更新後の値を比較し、エクスポート後に在庫が変わっていた行を取り込まない安全確認の仕組みがあります。

必須の列がない、列名が違う、SKUが空欄、数字の列に文字が入っている、文字コードが合わない、同じSKUが重複しているといった違いでエラーになることもあります。サービスによっては取込開始後に途中で止められない場合があるため、取込前にデータをバックアップする、少数の商品で試す、更新対象の列を確認する、取込後に件数とエラーを確認することが大切です。Shopifyの商品CSVについても、インポート開始後はキャンセルできないため、事前のバックアップが案内されています。

9．手作業による連携とは

たとえば、モールへ注文が入ったら、担当者がモールの注文画面を開き、注文番号・商品・住所を確認し、倉庫の管理表へ入力し、出荷後に追跡番号を確認して各ECへ手入力します。システム連携はありませんが、人が情報をつないでいます。

手作業自体が問題なのではありません。誰が、いつまでに、何を見て、どこへ入力し、誰が確認するかが決まっていないことが問題です。

10．手作業が向いているケース

必要な速度と件数が人の処理能力を超えたら、CSVやAPIへの移行を検討します。

11．一方向連携と双方向連携

一方向連携は、システムAからBへだけ送ります（商品管理→ECサイト、EC側で変更しても商品管理側へは戻りません）。双方向連携は、AとBの両方から変更できます。便利に見えますが、同じ項目を同時に変更すると、どちらを正しい値とするか分からなくなります。すべてを双方向にせず、項目ごとに「どこから更新するか」を決めます。

12．データをつなぐための共通番号

データ連携では、同じ商品・注文・顧客を識別する番号が必要です。商品は商品コード・SKU・JANコード・販売先の商品ID、注文は注文番号・販売先注文番号・出荷番号・決済ID、顧客は顧客番号・会員ID・メールアドレス、配送は出荷番号・荷物番号・追跡番号で識別します。

自社ECで「白いTシャツM」、モールで「ベーシックTシャツ／ホワイト／M」、倉庫で「Tシャツ白M」のように表示名が違っても、基準SKU「TS-001-WH-M」が同じなら同一商品として扱えます。商品名だけではつながりません。DAY20で作成した販売先別の商品コード対応表が、API・CSV・手作業のすべてで重要になります。

13．全件上書きと差分更新

更新日時を使い、「最終連携10時00分→それ以降に更新された注文だけ取得」という方法もあります。Shopifyも、Webhookだけに依存せず、更新日時などを使って定期的にデータを照合することを案内しています。

14．重複処理を防ぐ

同じ注文データを2回受け取った場合、そのまま登録すると注文が二重になり、商品を2回発送する、在庫を2回減らす、売上を2回計上するといった問題が起こります。注文番号ORD-001が登録済みかを確認し、未登録なら登録、登録済みなら二重登録しないという判定が必要です。注文番号だけでなく、通知ID、処理ID、返金IDなども記録し、同じ処理を何度実行しても結果が二重にならない設計を検討します。

15．連携エラーを分ける

「APIエラー」「CSVエラー」と一つにまとめると、原因が分かりません。

16．エラーが起きたら誰が対応する？

自動連携を作っても、エラーを確認する人がいなければ止まったままです。通知先、担当者、対応期限、暫定対応、再処理方法、エスカレーション先、完了条件、記録先を決めます。

17．認証・アクセス権限

API連携では、システムへ自由にアクセスできるわけではありません。一般的には、APIキー、アクセストークン、OAuthなどを使い、誰がどの情報へアクセスできるかを管理します。Google Sheets APIでは、アプリが利用する情報と操作範囲を認可スコープで指定します。Googleは、アプリに不要な広い権限を求めず、できる限り狭い範囲のスコープを選ぶことを推奨しています。

在庫を見るだけの仕組みに、全ファイルを削除できる権限まで与える必要はありません。APIキーやアクセストークンを共有スプレッドシートやチャットへそのまま記載すると、閲覧した人がシステムへアクセスできる可能性があるため、保管場所を決める、閲覧できる人を限定する、ログへ表示しない、退職・契約終了時に無効化する、定期的に更新する、漏えい時の停止手順を用意することが必要です。

18．費用は「システム利用料」だけではない

API、CSV、手作業を比較するときは、月額料金だけで判断しません。APIは初期設計・開発費・サーバー・API利用料・保守・エラー監視などが、CSVは出力取込作業・ファイル変換・エラー修正・バックアップなどが、手作業は担当者の作業時間・二重確認・入力ミスの修正・誤出荷による損失などが費用として発生します。

注文数が増えるほど、手作業の人件費と処理遅延が増えます。一方、月に2件しか注文がない業務へ高額なAPI連携を作ると、開発費を回収できない可能性があります。

19．どの方法を選ぶ？判断表

20．3つを組み合わせる

実務では、一つの方法だけを使うとは限りません。商品名・説明・価格・画像URLなどはCSVで週1回まとめて更新し、頻繁に変わる注文・在庫はAPIで自動連携し、住所不備・在庫不足・名入れ確認などの例外注文は担当者が判断します。この組み合わせなら、すべてを自動化するよりも分かりやすく、手作業だけよりも負担を減らせます。

21．自動化する順番

実際のケースで考えてみよう｜自社ECとモールの注文を倉庫へ渡す

ある事業者は、自社ECとモールの注文を確認し、スプレッドシートへ転記して倉庫へメール送信、追跡番号を受領して各ECへ手入力する流れで出荷していました。1日の注文は5件でした。

データ連携を設計する12の質問

1. 何のデータを連携しますか？商品、注文、在庫、追跡番号などを分けます。
2. 正式なデータ元はどこですか？項目ごとに更新元を決めます。
3. 共通するIDはありますか？SKU、注文番号などを確認します。
4. 何分以内に反映する必要がありますか？即時、5分、1時間、1日などを決めます。
5. 1日に何件処理しますか？現在だけでなく、増加後も考えます。
6. APIは提供されていますか？取得・登録・更新できる項目を確認します。
7. CSVの入出力形式はありますか？必須列、ファイルサイズ、上書き範囲を確認します。
8. 手作業では何分かかりますか？担当者の作業時間を計測します。
9. 連携が失敗したら通知されますか？確認担当者と期限を決めます。
10. 同じデータを二重処理しませんか？処理済みIDを記録します。
11. 停止時に手動処理へ切り替えられますか？緊急用のCSVや作業表を用意します。
12. アクセス権限は必要最小限ですか？閲覧・更新・削除権限を確認します。

やってみよう｜手作業コスト計算機＆連携方法診断チェッカー

1件あたりの処理時間から月間の作業時間を自動計算し、自動化を検討すべき目安を確認できます。さらに、反映速度・処理件数・例外判断の頻度から、API・CSV・手作業のどれが向いているかをすぐに診断できます。入力内容はこのブラウザにのみ保存され、外部へは送信されません。

アウトプットワーク｜自社の連携方法を決めよう

対象となる業務を一つ選んでください。分からない項目は推測で決めず、「未確認」と記録してください。

理解度チェッククイズ

よくある質問

今回のまとめ

API、CSV、手作業には、それぞれ異なる役割があります。今回覚えておきたいポイントは、次の5つです。

1. APIは、システム同士が決められた方法で情報を送受信する仕組み
2. Webhookは、注文作成などの出来事を相手へ通知する仕組み
3. CSVは、多数の商品や在庫をまとめて更新する作業に向いている
4. 手作業は、少数件や例外判断の多い業務で利用できる
5. 更新速度だけでなく、ミス・費用・権限・復旧方法を含めて選ぶ

APIだから必ず速く正確になるわけではなく、CSVだから必ず古くなるわけでもなく、手作業だから必ず廃止すべきでもありません。重要なのは、頻繁に繰り返す通常処理はAPI・Webhook、大量のデータをまとめて変更するときはCSV、個別の判断が必要な例外は担当者による確認、というように仕事を分けることです。

獲得バッジ

文：横田和也／解決ドットコム編集部