複数モール出店中のEC事業者の在庫・受注を統合管理し、欠品ロスを60%削減
楽天・Amazon・Yahoo!ショッピング・自社ECなど複数モールに出店するEC事業者で、モール別の在庫CSV手動更新に起因する売り違いと受注処理の深夜残業が常態化していた。共通在庫マスタを中核としたハブ&スポーク型アーキテクチャをPython(FastAPI)とAWS Lambda+EventBridgeで構築し、在庫反映を秒単位に短縮。欠品ロスを月次売上比で約60%削減し、繁忙期の深夜残業を解消した。
背景と課題
この企業は、楽天・Amazon・Yahoo!ショッピング・自社ECと複数の販売チャネルを並行運営するEC事業者です。主力商品は生活雑貨で、セール期には各モールへの出品点数が数千SKUに及びます。事業規模の拡大に伴い、複数チャネルを少数のオペレーターが管理する体制が限界を迎えつつありました。
課題の根本にあったのは、在庫管理の仕組みでした。
- モール別CSV更新の手作業運用:各モールへの在庫数反映がCSVの手動アップロードに依存しており、更新のタイムラグから複数モールで同一商品が同時に受注されてしまう売り違いが月数十件規模で発生していました
- 受注処理の属人化と深夜残業:各モールの受注データをまとめて出荷指示に変換する作業が手作業で、繁忙期(セール・年末)には担当者が深夜まで対応を余儀なくされる状況が続いていました
- セール時の機会損失と返金対応:キャンペーン中はリアルタイムの在庫反映が追いつかず、表示在庫と実在庫の乖離によって完売後に受注を受け付けてしまい、返金対応と顧客クレームが頻発していました
- 収益性分析の遅れ:売上・在庫データがモールごとに分散しており、商品別・モール別の収益性を把握できるのが翌月以降になってからで、低利益商品の入れ替えや値付け改善といった経営判断が常に後手に回っていました
「セールのたびに現場が混乱している。根本から仕組みを変えたい」という相談をいただいたのが、本プロジェクトの出発点です。
XECINのアプローチ
まず各モールのAPI仕様(楽天RMS / Amazon SP-API / Yahoo Trade API)を調査し、在庫更新と受注取得それぞれで利用可能な連携方式を整理しました。その上で、共通在庫マスタを中核に据えたハブ&スポーク型のアーキテクチャを設計し、各モールをスポークとして段階的に接続する方針を取りました。
- 段階的な移行計画の策定:影響度の小さいモールから接続を開始し、運用が安定したタイミングで楽天・Amazonの主要チャネルへ移行。既存業務を止めることなく基盤を切り替えました
- 在庫マスタ設計:SKU・倉庫ロケーション・モール別引き当て数量を一元管理できるデータモデルを設計し、重複管理の排除とリアルタイム反映の基盤を整えました
- 受注フローの自動化設計:モールごとに異なる受注データのフォーマットを正規化する変換レイヤーを設け、出荷指示への変換を自動化する処理を組み込みました
実施内容
体制
- XECINからプロジェクトマネージャー1名、バックエンドエンジニア2名、インフラエンジニア1名を担当
- クライアント側の運営責任者1名、物流担当者1名と週2回の定例ミーティングを実施し、運用要件を継続的に確認しながら開発を進めました
技術領域
共通在庫マスタとリアルタイム反映
共通在庫マスタをAWS DynamoDBで構築し、在庫数の更新をトリガーにAWS EventBridgeで各モールへ即時反映するイベント駆動の仕組みを実装しました。在庫反映にかかる時間はCSV手動更新時の数時間から秒単位に短縮され、セール中の同時受注リスクをほぼ排除しました。
- バックエンド:Python(FastAPI)によるREST APIで、在庫取得・更新・モール連携エンドポイントを設計・実装
- サーバーレス処理:AWS Lambda + EventBridgeでモール在庫更新をイベント駆動で処理
- データストア:DynamoDBでSKU別・倉庫別の在庫を管理し、高スループットな読み書きに対応
受注自動化パイプライン
各モールから受注データをAPIで取得し、出荷指示形式に変換・統合する自動パイプラインを構築しました。モールごとに異なるデータ形式をPythonの変換レイヤーで正規化し、物流システムへの出荷指示を自動生成します。エラー時のリトライと通知も組み込み、人手による確認作業を最小化しました。
楽天RMS・Amazon SP-API・Yahoo Trade APIの各仕様に対応した受注取り込みアダプターを個別に実装し、新モール追加時も最小限の工数で対応できる構造としています。
管理ダッシュボード
モール別・商品別の受注状況・在庫状況・収益性を可視化するダッシュボードをReact + TypeScriptで構築しました。DynamoDBの集計データを日次バッチで集計し、翌月にならなければ把握できなかった収益性情報をリアルタイムで参照できるようになりました。低利益商品の見直しや値付け調整を当月内に実行できる体制が整いました。
インフラ
- AWS Lambda + EventBridgeによるサーバーレス構成で、繁忙期のトラフィックスパイクにも追加コストを抑えて対応
- CloudWatch Logsでモール連携処理の成否を監視し、エラー時はSlackへ自動通知する仕組みを整備
成果
システム稼働開始後、現場の業務環境は大きく変わりました。
- 欠品ロスが月次売上比で約60%削減(売り違いに起因するキャンセル・返金が大幅に減少)
- 売り違いの発生件数が月数十件 → ほぼゼロ(在庫反映が秒単位に短縮されたことで同時受注を排除)
- 受注処理の手動工数を月120時間削減し、繁忙期の深夜残業を解消
- 商品別・モール別の収益性ダッシュボードにより、低利益商品の見直し判断が当月内に実行可能に
「セール前夜に深夜残業するのが当たり前だったのが、今では普通に帰れるようになった。売り違いのクレーム対応に追われることもなくなった」とご担当者から報告をいただきました。
継続支援
現在は月次の運用レビューを実施しながら、新規モール追加対応とダッシュボードの分析項目拡充を継続しています。将来的には需要予測モデルの組み込みも視野に入れており、在庫最適化のさらなる高度化に向けて取り組んでいます。