マルチチャネルEC受注収集の例外処理設計

この記事が答える問い

複数のモールで販売していると、注文を確認して社内の表やシステムに転記するだけで毎日の時間が削られていきます。そこで受注収集を自動化しようとすると、ほぼ確実にぶつかるのが「うまく取り込めなかった注文をどう扱うか」という問題です。

この記事では、韓国の主要ECモール（ABLY・ZIGZAG・NAVERスマートストア）の注文をひとつの運用画面に集めるパイプラインを設計・実装したときの考え方をもとに、例外処理の設計で押さえておきたい点を整理します。会社名やサービス名、社内の数値は伏せています。

結論

受注収集の自動化で大事なのは、失敗をなくすことより、失敗した注文を元の形のまま残し、人が判断できる状態にすることです。

• 取り込みに失敗した明細は、元のデータ（ペイロード）ごと別の場所に退避する
• どのチャネルの、どの注文が、なぜ失敗したのかがすぐ分かるようにする
• データの中身に原因がある失敗は、自動で再試行せず担当者が1件ずつ判断する

自動化の価値は「全部を自動で処理すること」ではなく、「人が見るべき注文だけが人の前に届くこと」にあります。

収集が壊れるポイント

開発の前に、連携の手続きがある

モールのAPIは、申し込めばすぐ使えるとは限りません。プラットフォームごとに提携の申請や審査の手順が異なり、それが終わるまでは開発に着手できないこともあります。前述のパイプラインでも、各モールのオープンAPIを自分たちで申請・発行するところから始めました。

自動化の見積もりでは、コードを書く時間とは別に連携手続きの時間と、通らなかった場合の代替手段を最初に確認しておくのが安全です。

注文の「形」がモールごとに違う

同じ「注文」でも、項目名、ステータスの種類、オプション（色・サイズなど）の持ち方はモールによって異なります。これをそのまま後工程に流すと、モールが増えるたびに後工程も直すことになります。

そこで、取り込んだ直後にモールごとの差を吸収し、社内で扱う注文の形をひとつに統一しておきます。後工程は統一された形だけを相手にすればよくなり、新しいチャネルを足すときも変換部分を追加するだけで済みます。

1件の注文が、1件の発送とは限らない

実務では「別々の注文を1つの箱で送る（合流発送）」「1件の注文を複数回に分けて送る（注文分割）」といったケースが日常的に起きます。注文と発送を1対1で設計してしまうと、こうしたケースがすべて例外として手作業に戻ってきます。

設計の段階で、注文と発送の対応が1対多・多対1になりうる前提でデータを持っておくことが重要です。

失敗した注文をどう扱うか

元のデータごと退避する

取り込めなかった明細は、エラーメッセージだけでなく、モールから届いた元のデータごと専用のテーブル（例：failed_import）に自動で退避します。元のデータが残っていれば、原因の調査も、修正後の再取り込みも、後から確実に行えます。逆に、エラーログだけでは「何が届いていたのか」が分からず、モール側の画面を見に行くことになります。

自動リトライと、人の判断を分ける

失敗には大きく2種類あります。

データに原因がある失敗は、何度再試行しても同じ結果になります。それどころか、自動で流し続けると誤った内容のまま後工程に進んでしまう危険があります。前述のパイプラインでは、この種類の失敗は自動リトライに回さず、担当者が1件ずつ判断して処理する構成にしました。

「どこで壊れたか」がすぐ分かるようにする

退避したデータには、チャネル名、注文番号、失敗した段階、エラー内容をあわせて残します。これがあるだけで、「特定のモールで仕様が変わった」「特定の商品だけ毎回失敗する」といった傾向が見えるようになり、恒久的な対応につなげられます。

導入前のチェックリスト

1. 連携したいモールごとに、APIの申請・審査の手順と所要期間を確認したか
2. 社内で扱う「注文の形」をひとつに決めたか
3. 合流発送・注文分割など、注文と発送が1対1にならないケースを洗い出したか
4. 取り込みに失敗した注文を、元のデータごと残す場所を決めたか
5. 自動で再試行してよい失敗と、人が判断する失敗を分けたか
6. 失敗した注文を誰が、いつ確認するかを決めたか

まとめ

受注収集の自動化は、うまくいく注文を速く流す仕組みであると同時に、うまくいかない注文を見落とさない仕組みでもあります。失敗を「なかったこと」にせず、元の形で残して人の判断につなぐ設計にしておくと、モールの仕様変更や想定外の注文があっても運用が止まりにくくなります。