無在庫販売（ドロップシッピング）で避けたい在庫切れ。商品ID25万件のズレ率を0.00883%で回す仕組みを大公開
この記事では正当なビジネスとして無在庫販売（ドロップシッピング）をしているEC事業者に向けて、どうすればトラブルを極小化し適切に在庫管理できるかについて、実例をふまえて紹介してきます。本記事の想定している対象読者は、例えば以下のような方です。
- 実店舗メインの法人だけど、これからEC事業で生き残りを図りたい
- 無在庫販売（ドロップシッピング）をしているけど、在庫のトラブルが多く困っている
- 仕入れ先の卸問屋がCSVでしか在庫を提供してくれず、リアルタイムの在庫管理ができない
- 在庫切れの謝罪メールが精神的にきつく、もう辞めたい
- 無在庫なのに在庫トラブルの対応が仕事の中心になっているEC担当者
ただの転売屋は本記事を読んでも参考になりません。
目次
- ドロップシッピングの在庫関連のトラブルはクリティカル
- 25万件の在庫の動きを把握しよう
- 在庫システムに反映する
- 在庫を監視する
- 25万件の在庫の1週間のずれの平均は0.00883%
ドロップシッピングの在庫関連のトラブルはクリティカル
無在庫販売だから在庫管理のトラブルは少ないというのが幻想なのは、この記事を読んでいる方なら分かるでしょう。むしろ無在庫販売だからこそ発生する在庫のトラブルがあります。問屋で欠品、メーカーで終売、CSVの作業が間に合わず在庫切れなど、挙げだしたら枚挙にいとまがありません。
あくまで仕入れで商売をしているということは、売っている商品は自社開発の商品ではないわけで他店との差別が図りにくい。充実させるべきは店舗サービスなのに、欠品に伴う在庫トラブルがあってはビジネスの存続が危ぶまれます。ドロップシッピングの在庫関連のトラブルはクリティカルなので、可能なかぎり避けなくていけません。しかしこれを妨げる要素があります。それを挙げてみましょう。
- 自動化したいのにメーカーや問屋にAPIが無い
- 仕入れ先のCSVが揃っていない
- 在庫の動きが読めない
こういった在庫トラブルの原因となり得る要素は、一つ一つ取り除かないといけません。根本的には卸し問屋にAPIを作ってもらえば解決しますが、現実的にはなかなか難しいでしょう。そこで、次はこういった課題に対して運用サイドでできることは何か、どういう解決方法があるのか、プログラムでどこまでできるのかについての事例を紹介します。
25万件の在庫の動きを把握しよう
ここで紹介するドロップシッピングの事例においては、以下のような条件を満たす必要がありました。
-
- 卸し問屋の許可を得ること
- 問屋のウェブサイトからCSVを定期ダウンロード
- 在庫の動きを正確に把握すること
- 在庫をネクストエンジン（楽天、カラーミー、yahooショッピング）に反映
卸し問屋の許可は得ていること
まず極めて重要なことを先に書きます。無在庫販売をするに際して、問屋のウェブサイトからCSVで在庫データを定期ダウンロードする必要があります。この事例において問屋の扱う商品数は25万件です。データ量の大きいファイルをダウンロードするとウェブサイトのサーバーには負荷がかかるので、それを頻繁にダウンロードするのは一般的にはマナー違反です。また利用規約に明記してあったり、システムで制限がかかっていることもあります。サーバー管理者の立場からすると、頻繁にダウンロードするアカウントやIPアドレスは敵のような存在で、度か過ぎるとブロックされます。
そのため、事前に卸し問屋の許可を得ていることが死活的に重要となります。許可を得ていればよほど負荷の大きいことをしない限り、安心してEC運用ができます。この辺りは問屋やメーカーごとにサービス運用ポリシーがあるはずなので、必ず確認しましょう。許可を得ることを確認できない限り、前に進めないことです。これ本当に大事です。
問屋のウェブサイトからCSVを定期ダウンロード
許可を得たら、次は問屋のウェブサイトからCSVを定期ダウンロードします。「定期」というのは仮に5分おきとしましょう。さすがに5分おきにウェブサイトからCSVをダウンロードするのは手作業ではできないので、プログラムで自動化します。こういう定期作業の自動化を「RPA」といいます。ChatGPTなど生成AIにプロンプトを入力すれば、RPAのソースコードを用意してくれます。
ただし、問屋のウェブサイトに二段階認証が導入されている場合は、RPAの定期ダウンロードは難易度が上がります。というのも二段階認証はボットによる不正操作を防ぐためのものなので、それをRPAで突破するというのは、設計思想に逆らうことになります。仮に突破できても、安定して動かない可能性が高いです。
在庫の動きを正確に把握すること
一般的に、問屋の在庫データは整っていないことが多いです。問屋やメーカーごとに在庫の動きが異なるので、その癖を正確に把握する必要があります。例えば、在庫が多い商品の在庫数が「○」であったり、在庫がない商品の在庫がゼロでなく在庫リストに商品IDが載ってこないなど、問屋ごとに特徴があります。間違ってもきれいに在庫データが載っているなどと期待しないことです。
在庫の動きを正確に把握できたら、以下のように表やフローチャートを作ってどうシステムに落とし込むかを完璧に設計しましょう。抜け漏れがあってはいけません。大事なのでもう一度書きますが、完璧に設計することです。それがドロップシッピングで在庫トラブルを極小化する条件です。
| パターン | A時点の在庫 | B時点の在庫 |
|---|---|---|
| パターン1 | ある | ない |
| パターン2 | ある | ある |
| パターン3 | ない | ある |
| パターン4 | ない | ない |
この例における商品Aの在庫を考えてみましょう。
パターン1では、A時点の商品Aの在庫は5ありますが、仮に5分後のB時点では在庫がありません。この問屋の在庫CSVでは商品AのIDがリストから消えます。つまり商品IDが消えることが、在庫が0になることを意味します。
パターン2では、どちらも在庫があるので、両時点で差分があればそれを計算して在庫データとして楽天やネクストエンジンなどに反映します。
パターン3では、在庫0から在庫が復活しています。なので増えた分を楽天やネクストエンジンなどに反映します。
パターン4では、在庫0から0のままです。これは在庫システムに反映する必要はありませんが、動きを把握しておく必要はあります。すべてのパターンを把握しておかないと、予想外の動きをして、在庫がずれる可能性があるからです。
在庫システムに反映する
上記のように問屋の在庫データの動きを把握したら、差分があった商品のみを差分リストにして、ネクストエンジン、クロスモール、RMS、Amazon、Shopifyなど在庫反映が必要なシステムにAPIで反映します。余談ですが、ネクストエンジンの在庫機能には拠点という概念があるので、倉庫が複数がある場合にも対応できます。
在庫APIで反映する場合、件数によっては一度で反映できないので分割してAPIリクエストします。当然その分だけ反映されるのに時間がかかります。したがって差分があった商品のみを反映するのです。間違ってもすべての商品在庫を絶対値で上書きしようなどと考えないことです。そういうシステム負荷を考慮しない考えではEC運用が破綻します。
在庫を監視する
在庫反映ができてもそれで安心してはいけません。どんな精確な時計でもいつか必ずずれるように、在庫はずれていきます。完璧に作ったはずのものでも、運用の中でほころびが生じてずれます。それは仕方がないことなので、防ぐことはできません。なので監視します。幸いにして楽天、Shopify、Amazon、Yahoo、カラーミーなどの主要ECモールやECカートには在庫取得するAPIがあるので、その仕組みを利用して監視しましょう。
25万件の在庫の1週間のずれの平均は0.00883%
最後に実績を紹介します。1ヶ月当たりの問屋在庫とネクストエンジンの在庫のずれを表にしてみました。日付の下がある一時点でのずれた在庫の数です。当然瞬間的に在庫がずれることはありますが、その原因は問屋サイトのメンテでCSVがダウンロードできないことでした。繰り返しますが、ズレが発生することは防げないので、そのために監視をします。念のため、監視システムの監視もします。ここまでやれば、在庫のトラブルに悩む可能性を可能な限り少なくして、ECを運用できます。
