複数チャネルで在庫を同期する方式には「一方向同期」と「双方向同期」があり、自社のチャネル構成と運用体制に合わない方式を選ぶと、在庫ズレや運用負荷の増大を招きます。この記事では、両方式の仕組み・メリット・デメリットを比較し、チャネル数や運用体制に応じた選び方の判断軸を解説します。
この記事のポイント
- 一方向同期は更新元→各チャネルの一方通行。シンプルで始めやすいが、モール側の在庫変更は手動反映が必要
- 双方向同期はどこで在庫が変わっても全体に自動反映。柔軟だが競合処理の設計が必須
- チャネル構成・実店舗有無・運用チームの体制で、自社に合った方式を判断する
一方向同期と双方向同期──EC在庫管理における2つの同期方式
在庫同期の方式は大きく2種類に分かれます。まず、それぞれの仕組みを明確にしておきます。
一方向同期とは：更新元から各チャネルへ一方通行で在庫を配信する方式
一方向同期は、在庫の更新元（マスターとなるシステム）を1つ決め、そこから楽天・Amazon・Yahoo!ショッピングなどの各チャネルへ在庫数を配信する方式です。
データの流れは常に「更新元→各チャネル」の一方通行です。各チャネルで商品が売れた場合、受注情報は更新元に取り込まれ、更新元が在庫数を再計算したうえで各チャネルに配信し直します。
ポイントは、モールの管理画面から直接在庫数を変更しても、その変更は更新元には戻らないという点です。在庫の正は常に更新元が握ります。
双方向同期とは：どのチャネルで在庫が変わっても全体に反映する方式
双方向同期は、どのチャネルで在庫の変動が起きても、その変更がすべてのチャネルに自動反映される方式です。
たとえば、楽天で5個売れれば、Amazon・Yahoo!ショッピング・自社ECの在庫もそれぞれ5個減ります。同様に、実店舗のPOSで在庫を3個引き当てれば、EC側の在庫も3個減ります。
データの流れは「すべてのチャネル⇔すべてのチャネル」です。更新の起点がどこであっても、最終的には全チャネルの在庫が一致する状態を目指します。
ファイル同期との違い──EC在庫同期はなぜ複雑なのか
「一方向同期」「双方向同期」という用語は、NASやクラウドストレージのファイル同期でも使われます。しかし、EC在庫同期にはファイル同期にはない複雑さがあります。
- 在庫引当の競合：複数チャネルで同じ商品が同時に売れた場合、在庫が1個しかなければどちらの注文を確定するかの判断が必要になる
- 返品・交換処理：在庫の「戻し」が発生したとき、どのチャネルの在庫に加算するかを決める必要がある
- セット商品・バリエーション：親商品と子商品の在庫連動があるため、単純な数値の上書きでは処理できない
ファイル同期のように「新しいファイルで上書き」すれば済む世界ではありません。この違いを理解しておくことが、方式選択の前提になります。
一方向同期のメリットとデメリット
メリット：在庫の正が常に1か所で管理しやすい
一方向同期では、在庫の更新元が1つに固定されます。「在庫数が正しいかどうか」を確認する場所が1か所で済むため、棚卸時の突合がシンプルです。
在庫に不整合が見つかった場合も、更新元の数値を修正すれば各チャネルに再配信されるため、原因の切り分けと対処がしやすくなります。
メリット：導入・設定がシンプルで始めやすい
一方向同期は「更新元→各チャネル」という単純な構造のため、設定項目が少なく、非エンジニアでも運用しやすい傾向があります。
導入コストも双方向同期と比べて抑えられるケースが多く、在庫同期を初めて導入する事業者にとってはハードルが低い方式です。
デメリット：モール側の在庫変動を手動で更新元に反映する必要がある
モールの管理画面から直接在庫数を変更した場合、その変更は更新元には戻りません。
たとえば、楽天の管理画面で在庫を手動で減らした場合、更新元の在庫数はそのままです。次の同期タイミングで更新元の数値がモールに上書きされ、手動で減らした分が元に戻ってしまうことがあります。
モール側での在庫調整が頻繁に発生する運用では、手動で更新元に反映する作業が積み重なり、負荷が大きくなります。
デメリット：モール独自の在庫調整（返品・取り置き等）が反映されにくい
モール経由の返品受入や、店頭での取り置き対応など、更新元を経由しない在庫変動は、一方向同期では自動反映されません。
これらの例外処理が多い事業者にとっては、一方向同期だけでは運用を回しきれない場面が出てきます。
双方向同期のメリットとデメリット
メリット：どこで在庫が動いても自動で全体に反映される
双方向同期の最大のメリットは、在庫変動の発生源がどこであっても、手動介入なしに全チャネルの在庫が更新される点です。
楽天で売れても、Amazonで返品が入っても、実店舗のPOSで引き当てが起きても、すべての在庫変動が自動的に全チャネルに伝搬します。手動反映の作業が最小化されるため、チャネル数が多い事業者ほど運用工数の削減効果が大きくなります。
メリット：実店舗併用やモール独自の在庫調整にも対応しやすい
実店舗のPOSシステムと連携して在庫を同期する場合、店頭での販売や在庫調整がリアルタイムにEC側の在庫に反映されます。
モール管理画面から直接行う在庫調整（キャンペーン用の限定数量設定など）も、双方向同期であれば他チャネルに自動反映されます。
デメリット：競合（コンフリクト）の発生リスクがある
双方向同期で最も注意が必要なのが「競合」です。
たとえば、在庫が残り1個の商品が、楽天とAmazonでほぼ同時に売れた場合、どちらの注文を確定し、どちらをキャンセルするかを判断するルールが必要です。
この競合処理のルールを事前に設計していないと、両方の注文が確定してしまい二重販売になるか、あるいは両方キャンセルされて販売機会を失います。
デメリット：設計と運用の難易度が上がる
双方向同期では、以下のような設計が必要になります。
- 競合処理ルール：同時に在庫が変わった場合、どちらを優先するか
- 例外処理：返品、取り置き、セット商品の在庫連動のルール
- ロールバック設計：同期エラーが起きた場合の復旧手順
これらの設計を運用チームが理解し、日々の運用で判断できる体制が必要です。一方向同期と比べて、導入と運用の難易度は確実に上がります。
一方向同期と双方向同期の比較表
| 比較項目 | 一方向同期 | 双方向同期 |
|---|---|---|
| 在庫の更新元 | 1か所に固定 | 固定しない（全チャネルが起点になりうる） |
| データの流れ | 更新元→各チャネル（一方通行） | 全チャネル⇔全チャネル（双方向） |
| 導入の容易さ | シンプル・低コスト | 設計が複雑・コストが高め |
| 日常の運用負荷 | モール側変更の手動反映が必要 | 手動介入が最小化される |
| 競合リスク | なし（更新元が常に正） | あり（競合処理ルールが必須） |
| 実店舗・POS連携 | 手動反映が必要 | 自動反映が可能 |
| 向いている事業者 | チャネル数が少なく、更新元で一括管理できる事業者 | チャネル数が多く、複数箇所で在庫が変動する事業者 |
この表は「どちらが優れているか」ではなく、「自社の状況にどちらが合うか」を判断するためのものです。
自社に合った同期方式を選ぶ3つの判断軸
比較表を見ても決められない場合は、以下の3つの軸で自社の状況を確認してください。
判断軸1：在庫を直接変更するチャネルがいくつあるか
在庫の変更が更新元の1か所だけで完結するなら、一方向同期で十分です。
たとえば、自社ECを更新元として楽天・Amazonに配信するだけで、モール管理画面で直接在庫を触ることがないなら、一方向同期のほうがシンプルに運用できます。
一方、楽天の管理画面からも在庫を調整する、Amazonの返品処理でも在庫が変わる、というように在庫を直接変更するチャネルが複数ある場合は、双方向同期を検討すべきです。
判断軸2：実店舗やPOSとの連携が必要か
ECだけの運営であれば一方向同期で回せる場合が多いですが、実店舗も並行して運営している場合は状況が変わります。
店頭での販売や取り置きによる在庫変動を、EC側にリアルタイムで反映する必要がある場合、双方向同期が前提になります。
実店舗の在庫変動を毎回手動でEC側の更新元に反映する運用は、店舗スタッフの負荷を考えると現実的ではありません。
判断軸3：運用チームの人数とIT対応力
双方向同期は、競合処理のルール設計や例外パターンへの対応など、一方向同期にはない運用判断が発生します。
運用チームが1〜2名で、ITに詳しい人員がいない場合、双方向同期の設計・運用を担いきれないリスクがあります。
この場合は、まず一方向同期で在庫管理の仕組みを整え、運用が安定してからチャネル構成の変化に応じて双方向同期に移行するのが現実的です。
在庫の更新元を一本化して複数モールの在庫を管理する方法を参考に、まず更新元の設計から始めることを推奨します。
Shopifyを在庫の更新元に固定し一方向同期で運用すると、複数モールの在庫ズレや二重販売を減らせます。導入前の準備から運用フロー、連携方法の選び方までを実務目線で整理します。 [summary] この記事のポイント * 在庫の更新[…]
同期方式の選択ミスで起きる3つの問題パターン
同期方式の選択は、一度決めると変更コストが大きいため、事前に起こりうる問題を把握しておくことが重要です。
一方向同期で無理に運用した結果、モール側の在庫調整が反映されず在庫ズレが拡大する
実店舗を併用している事業者や、モール管理画面での在庫調整が頻繁に発生する事業者が一方向同期を選ぶと、手動反映の作業が積み重なります。
「あとで更新元に反映しよう」と後回しにした在庫調整が溜まり、更新元の在庫数と実在庫の乖離が拡大します。結果として、在庫ズレが頻発する原因と同じ構造の問題が発生します。
在庫ズレの原因は発生タイミングごとに整理でき、在庫の正（SoR）を1つに決めて運用ルールを固定化すれば再発防止につながります。この記事では、在庫ズレの原因を6カテゴリとEC特有の原因に分けて整理し、SoR設計と原因切り分けチェックリストま[…]
双方向同期を導入したが競合処理を設計しておらず、在庫数が上書きされる
双方向同期を導入したものの、「同時に在庫が変わった場合の優先ルール」を決めていないケースです。
たとえば、更新元で在庫を100個に修正した直後に、モール側で5個売れて95個になったとします。競合処理ルールがなければ、100個と95個のどちらが正しいかをシステムが判断できず、タイミング次第で片方のデータが上書きされます。
この種の事故は目に見えにくく、棚卸まで気づかないことが多い点が厄介です。
方式を決めずに運用を始め、チャネルごとに同期方式が混在する
「楽天は一方向同期で、Amazonは双方向同期で」というように、チャネルごとに同期方式が混在する状態は、在庫の整合性を保つうえで最悪のパターンです。
一方向同期のチャネルでは更新元の在庫を正とし、双方向同期のチャネルではモール側の変更も反映される──この2つのルールが同居すると、在庫数の不整合が構造的に避けられなくなります。
在庫同期の方式は、全チャネル統一で決めるのが原則です。
まとめ：まず在庫の更新元を決め、チャネル構成に合った同期方式を選ぶ
一方向同期と双方向同期は優劣の関係ではなく、自社のチャネル構成と運用体制に合わせて選ぶものです。
- 一方向同期が向いている事業者：在庫の変更が更新元の1か所で完結する、チャネル数が少ない、運用チームが少人数
- 双方向同期が向いている事業者：複数チャネルで在庫を直接変更する、実店舗・POS連携が必要、競合処理の設計・運用を担える体制がある
迷った場合は、まず一方向同期で在庫の更新元を1つに決めて運用を安定させ、チャネル追加や実店舗連携のタイミングで双方向同期への移行を検討する段階的アプローチが現実的です。
自社に合った在庫同期方式の選定や、在庫の更新元の設計について整理したい方は、こちらから相談できます。