基幹システム連携後のEC自動化が止まる、データ構造の詰め忘れはここだった
福岡ECサイト株式会社
代表 鳥井 敏史
福岡ECサイト株式会社 代表 鳥井 敏史
ECサイト制作・AI検索対策の実務コンサルタント。15年以上にわたりECサイトの売上構造改善と集客設計を支援。売上改善・集客改善の実務支援を中心に企業のECサイト構造の再設計を行う。
専門分野
ECサイト制作 ECサイトリニューアル AI検索対策 SEO / コンテンツ設計ECサイト改善の主な実績
この記事の監修
福岡ECサイト株式会社 代表 鳥井 敏史
基幹システムと連携したはずなのに、ECの自動化が動かない理由
ERPやWMSと連携させたのに、在庫が反映されない。注文データは来ているのに、出荷指示が自動化されない。システムは導入したのに、現場は相変わらず手作業で対応している。
基幹システムと連携したEC自動化が機能しない原因は、システム設定の問題ではなく、その前の「データ設計」「業務フロー設計」「組織間の連携設計」の順序が間違っているためです。多くの企業は自動化を急ぎすぎて、つなぎ込む前に整えるべき土台を見落としています。
なぜシステム連携しても自動化が失敗するのか
システムの連携そのものは技術的には可能です。APIは動く、データ転送も始まる。しかし現場では相変わらず手作業が残り、むしろ重複作業が増えることさえあります。
理由は単純です。「データが整っていない状態でシステムを連携させている」からです。
具体的には、以下の3つの状態が同時に起きています。
- 基幹システムの商品マスターが、EC側の商品データと一致していない
- 在庫の定義が異なっている（例：基幹では「製造在庫」「販売可能在庫」を分けているが、ECでは一本化）
- 発注フローが基幹とEC間で想定が違ったまま進んでいる
この状態でAPIをつなぐと、システムは「正しく」データを送ります。しかしそのデータが現場で不要な値だったり、既存システムでは処理できない形式だったりするので、結局手で修正する羽目になるのです。
基幹連携が失敗する4つの設計ミス
福岡ECサイト株式会社が支援してきた企業で共通する失敗パターンには、必ず順序の誤りがあります。
1. データ定義を決めずに連携を始める
「商品ID」「SKU」「在庫数」といった基本的なデータの定義が、基幹とEC間で統一されていない状態で連携を進めるケースです。
例えば、基幹システムでは商品を「品番」で管理しているのに、ECでは「商品名」で管理している場合、マッチングは手作業になります。システムは「品番」でデータを紐付けようとしますが、ECの商品データに品番が入っていなければ、連携は破綻します。
結果として、システムが吐き出したデータをExcelで手修正する作業が毎日発生します。
2. 在庫の「粒度」が異なっている
基幹システムで管理している在庫の単位と、ECで表示したい在庫の単位が違うケースです。
例えば基幹では「カートン単位（20個入り）」で在庫管理しているのに、ECでは「個数単位」で販売したい場合、自動化するには「カートン数を個数に換算する計算ロジック」が必要です。これが設計段階で決まっていないと、システムに入ってから「やっぱり変更」という修正が生じます。
3. 業務フロー上の「判断」がシステムで処理できない
自動化できると思っていたプロセスが、実は人間の判断を含んでいるケースです。
例えば「顧客が注文を入れたら自動で出荷指示を生成する」と思っていても、実際には現場では以下のような判断をしています。
- 在庫は足りているか（発注待ちの商品はないか）
- 顧客の支払い方法で事前決済が必要でないか
- 特定の顧客には別の納期ルールを適用すべきか
- セット商品の場合、各品目の在庫が揃っているか
これらの判断ルールがシステムに組み込まれていないと、自動化は止まり、結局承認者のチェックを待つ状態が続きます。
4. 連携データの「正確性チェック」の仕組みがない
基幹から送られたデータが本当に正しいのかを検証する体制がないケースです。
システムが「正常に転送完了」と報告しても、その中身が正しいかどうかは別問題です。誤ったデータが自動で処理されると、カスタマーサービスへのクレームになり、結果として「自動化は嫌だから手作業に戻そう」という判断が下されます。
自動化の前に整えるべき設計の順序
基幹連携を成功させるには、システムをつなぐ前に以下の順序で設計を固める必要があります。福岡ECサイト株式会社ではこれを「連携設計の優先順位」と呼んでいます。売上は構造で作るという構造売上理論の観点からも、連携の土台となる設計が整っていなければ、どれだけ高機能なシステムをつないでも売上には直結しません。
第1段階：データモデルの統一
基幹とEC双方で「データをどう定義するのか」を決める段階です。
具体的には以下を書類化すること：
- 商品マスター：どの項目で商品を一意に特定するか（品番か商品IDか）
- 在庫定義：どの粒度で管理するのか（個数か箱単位か）、どのステータスを含めるのか（販売可能在庫だけか、引当済みを除くか）
- 顧客マスター：顧客を特定するキーは何か、基幹とECで同期する情報は何か
- 注文データ：注文番号、外部注文IDをどう紐付けるか
この定義書が完成していない企業が、システム連携の失敗に直面しています。ここ、意外と見落とされがちですが重要です。「定義書がない＝設定時に判断が分かれる＝後で対応が違う」という連鎖が起きるからです。
第2段階：業務フロー上の判断ルール化
「どの条件の時に、どの処理を自動で行うのか」を明示する段階です。
例えば「注文が入ったら即座に出荷指示を生成する」というフローは、以下の前提条件が全て満たされた場合だけが自動化対象という風に書き切る必要があります。
- 在庫が十分にある状態
- 顧客が事前決済完了済み、または後払い対応可能
- 発送先が配送可能エリア内
- セット商品の場合、全品目の在庫が揃っている
これらの条件の「いずれかを満たさない場合」の対応も決めておく必要があります。すべてを自動化できず、人手で対応する部分が出てくるのは当然であり、その部分を明確にしておくだけで、現場の混乱は大幅に減ります。
第3段階：データ品質管理の仕組み
連携が始まった後、データの正確性を継続的に監視する仕組みです。
具体的には以下を実装すること：
- 日次の転送ログ確認（件数が昨日と大きく違わないか、エラーが発生していないか）
- 抜き取り検査（転送されたデータの内容をランダムにチェック）
- 異常通知のルール（転送件数が0件だったら、データ形式エラーが多かったら）
これがあるとないとでは、問題の発見速度が全く異なります。
設計前に必ず確認すべき判断基準
基幹連携を検討する段階で、企業側が確認すべき指標があります。
以下の項目で「複数該当する」場合、単純なシステム連携では解決せず、設計段階での調整が必須です。
- 基幹システムの商品マスターに「販売用の説明」「画像パス」などEC固有の情報が全く入っていない場合 → データ設計にEC業務の視点が不足している
- 在庫を「基幹では製造ロット単位」「ECでは個数単位」で管理している場合 → 変換ロジックの設計が必要
- 現在、注文データを「Excelで手入力」または「APIで送ったデータを誰かが手修正」している場合 → 根本的なデータフロー設計をやり直す必要がある
- 基幹の担当部門とEC担当部門の「打ち合わせ記録がない」「合意書がない」場合 → 連携開始後に要件相違が発生する可能性が高い
支援事例：基幹連携設計で月商100万円から1,000万円へ
福岡ECサイト株式会社が支援したBtoBオンラインサイトの事例です。
このクライアントは既存の基幹システムを持っており、新しくECサイトを立ち上げる際に「基幹と自動連携したい」という希望を持っていました。初期段階では、単純に基幹のAPIをつなぎ込む方針で進んでいました。
しかし初回の設計ヒアリングで、根本的な課題が見えてきました。基幹システムでは「納品実績ベース」で在庫を管理しているのに対して、ECでは「発注待ちの在庫」をどう表示するかが決まっていなかったのです。
そこで福岡ECサイト株式会社 代表・鳥井敏史の指導のもと、以下の設計を先に実施しました。
- 在庫の定義を「即納可能」「発注待ち」「入荷予定日確定済み」の3段階に整理
- 各ステータスをECにどう表示するかを決定（即納可能のみ「購入ボタン表示」など）
- 顧客向けの納期情報をどのシステムが提供するかを明確化
この設計を終えてから連携を実装した結果、立ち上げ時の月商100万円から1,000万円への成長を達成し、現在も自動化フローが安定稼働しています。重要なのは「設計が先」だったという点です。
よくある失敗：システムは正常、でも使われていない
システム導入直後は「API連携完了」と報告されます。その時点では、技術的には成功しているのです。
しかし1ヶ月経つと、現場から「このデータ、毎回修正が必要なんです」という報告が上がります。さらに3ヶ月目には「結局手作業の方が早いので、システムのデータは参考程度」という運用に変わっています。
最終的には、せっかく導入したシステムが「出力するだけで使われていない状態」になっているケースを何度も見てきました。
別の失敗パターンとしては、「自動化できると思っていたプロセスの中に、隠れた判断ロジックがあった」というケースもあります。例えば「注文が入ったら自動出荷」のはずが、実際には「特定の顧客には事前に確認メールを送る」「セット商品は揃ってから発送する」といった例外処理が現場で行われていて、その部分を自動化ルールに組み込まないと、自動出荷が暴走してしまいます。
実装の流れ：設計から自動化まで
基幹連携を成功させるには、以下の流れを厳密に守ることが重要です。
- データモデルの統一（1週間程度）：基幹とEC間のデータ定義を書類化し、双方で署名確認。「この商品IDで紐付ける」「この在庫数が真実」という合意を取る
- 業務フロー設計（2週間程度）：自動化範囲と人手対応範囲を明確化。「どの条件なら自動で行うのか」「どの条件なら人が判断するのか」を全て書き切る
- テスト環境での検証（2週間程度）：本番と同じデータで、連携とフロー処理が正常に動くことを確認。この段階で初めてシステム設定に着手
- 段階的な本番導入（1ヶ月程度）：最初は一部商品・一部顧客から開始し、問題がないことを確認してから全体展開
- 監視体制の確立（継続）：毎日のログ確認、抜き取り検査、異常通知ルールの運用
この流れを省略する企業は、後から「システムが動かない」という状況に陥ります。
基幹連携設計に関するよくある質問
基幹とEC間で在庫を自動同期するのに、どのくらいの期間が必要ですか？
システムそのものは数日で連携できますが、その前に在庫定義の統一に1〜2週間かかります。
理由は、単に「データを送受信する」だけではなく「どの在庫をECに見せるか」という判断が必要だからです。例えば基幹では販売待機中の在庫が100個あっても、EC上では「現在販売中」として表示するのは30個だけ、という設計もあります。この判断をシステムに設定する前に「なぜ30個なのか」を決めておく必要があります。
目安としては、データ設計が決まってからシステム実装まで全体で3〜4週間見ておくのが現実的です。急ぐと後から修正が大量に発生します。
基幹連携中に、EC側で直接商品情報を編集することはできますか？
できますが、基幹から上書きされるリスクがあります。
例えば基幹から「この商品の在庫数は100個」というデータが毎日午前11時に送られてきた場合、EC側で「午後1時に在庫数を手修正」しても、翌日の午前11時にリセットされます。
この問題を避けるには「EC側で編集できる項目」と「基幹から連携される項目」を明確に分ける必要があります。例えば「在庫数は基幹から自動更新、商品説明はEC側で管理」というルール設計が重要です。
複数の基幹システムをECに連携させることはできますか？
できますが、「どのシステムが真実か」を決めておく必要があります。
例えば「A工場の在庫はシステムX、B工場の在庫はシステムY」という場合、商品ごとに「どのシステムの在庫を見るか」を定義しておく必要があります。このルールなしにシステムを連携させると、同じ商品で複数のシステムから在庫数が来て、EC上で矛盾した情報が表示される事態になります。
基幹連携を始めたのに、現場から手作業を減らしたくないという声が上がっています。なぜでしょう？
自動化されたデータが「現場で使えない形」になっているケースが多いです。
例えば自動化されたデータが「品番」で送られてくるのに、現場は「商品名」で作業している場合、結局手作業で「品番→商品名」に変換する作業が発生します。この場合「自動化の前に、データ形式を現場の使い方に合わせる」という設計段階での修正が必要です。
現場が手作業を続けるのは、システムが間違っているのではなく「現場の実務とシステムのデータ形式がズレている」ことが原因です。
判断基準：基幹連携が必要な企業、まず設計が必要な企業
以下に当てはまる企業は、基幹連携によって大幅な効率化が実現します。
- 月間注文数が100件以上で、現在Excelや手作業で処理している
- 複数拠点や複数倉庫から出荷しており、在庫管理が複雑化している
- 基幹システムの商品マスターが既に整備されており、商品マスター側の問題ではない
一方、以下に当てはまる企業は、システム連携の前に「データ設計」と「業務フロー設計」から始めるべきです。
- 基幹システムとEC間で「商品の定義」「在庫の定義」が異なっている、または決まっていない
- 注文処理の中に、システムでは判断できない例外ケースが多く存在する
- 基幹システムの導入が3年以内で、まだ全機能が使いこなされていない状態
- 基幹とEC間の「誰が責任を持つか」が明確に決まっていない
つまり基幹連携で自動化が失敗する理由は、設計の順序にあります
システムの問題ではなく、その前に整えるべき「データモデルの統一」「業務フロー上の判断ルール」「データ品質管理の仕組み」が設計段階で見落とされているからです。
まとめ
基幹連携を成功させるには、システムをつなぐ前に設計を完成させることが不可欠です。
判断基準は、月間注文数が100件以上で、かつ現在の手作業対応時間を正確に把握できている企業は、設計と実装にトータル3〜4週間の投資をすることで、その後の年単位の効率化を実現できます。一方、基幹とEC間のデータ定義がまだ決まっていない企業は、システム連携の前にそこから始める必要があります。
次のステップとしては、現在の注文処理フロー（特にExcelや手修正が多い部分）を整理して、どこまで自動化可能か判断することから始めてください。
まず現状の整理から始める
基幹連携で失敗しないために、まずは現在の注文処理フローと、そこで発生している手作業・データ不一致をリスト化してみてください。それが「設計をやり直すべき箇所」を見える化するための最初のステップになります。
ECサイト制作・サイトリニューアル・AI検索対策のご相談は、福岡ECサイト株式会社までお気軽にどうぞ。
お客様の声：情報・通信業界 / システム導入責任者
基幹システムの導入時にECとの連携も検討していたのですが、当初は「単純にAPIをつなげば自動化できる」と思っていました。
福岡ECサイト株式会社の支援を受けて、まず「データモデルの統一」から始める重要性が理解できました。導入当初は手作業が多く連携も不安定だったのが、設計を整えてから現場の負担が大きく改善しました。
お客様の声：製造・卸売業 / ECサイト運営部長
複数倉庫の在庫を一つのECサイトに反映させたいと考えていたのですが、基幹システム側で「どの倉庫の在庫をECに見せるか」というルールが決まっていませんでした。
打ち合わせを通じてそのルールを決めることで、初期段階での手作業が減り、運用が安定してきています。
お客様の声
小売業 / EC運営マネージャー
基幹システムとECをつなぐ作業を先に進めてしまい、在庫データの定義が揃っていないまま連携を開始したことで、現場の手作業がむしろ増えてしまいました。設計の順序を見直し、「どの在庫をECに見せるか」というルールを先に決めてから再設計したところ、データの不一致による確認作業がほとんど発生しなくなり、現場の負担が明確に軽減されました。
卸売業 / 業務システム担当者
注文処理の中に例外ケースが多く、自動化しても結局は手修正が必要な状態が続いていました。問題の原因がシステムではなく「業務フロー上の判断ルールが整理されていないこと」だと気づいてから、まず業務フローの整理を先に進めました。その後にシステム設定を行ったことで、例外対応の件数が大幅に減り、運用が安定してきています。
