無在庫販売の在庫確認｜API連携＋ダブルチェック

在庫チェックを怠ると、販売トラブル（欠品事故）につながります

無在庫販売は、自分の手元に在庫を置かずに売る商売です。仕入れ先の在庫が切れても、自分の店では商品が売れ続けます。

そのまま注文が入ると、仕入れができずにキャンセルと謝罪が増えていきます。キャンセルと出荷の遅れは、そのままアカウントの評価に跳ね返ります。

やっかいなのは、この確認作業が商品数に比例して増えることです。1商品あたり1分で済んでも、商品数と確認の回数を掛けた分だけ積み上がります。人の目で全部を見ている限り、扱える商品数には必ず天井が来ます。

商品数を増やす判断と、確認する体制を増やす判断はセットです。片方だけ増やすと、在庫切れが表に出ます。

自動取得は「動くか」より「認められているか」で決まる

天井にぶつかると、次に考えるのは在庫データを自動で取ってくることです。ただし、ここで自作のスクレイピング（相手のサイトの表示内容を自動で読み取るプログラム）に手を伸ばすと、商品数を増やした段階でつまずきます。

当方が自社のEC運用でデータを取っていたときは、連続して読み取ると3桁を超えたあたりでエラーページが返るようになりました。しかも、これは日によって変わります。同じやり方が翌日には通らないこともあり、「何件までなら大丈夫」という線があるわけではありません。

別のサイトでは、IPアドレス（ネット上の住所のようなもの）ごと止められて、アクセスそのものができなくなりました。こうなると、プログラムだけでなく、同じ回線から人が手で見に行くこともできません。逃げ道が用意されていない止まり方です。

止められなくても、黙って壊れることがあります。画面の読み取りは、相手のページの作りに合わせて組むものだからです。ページの作りが変わった日から、プログラムは動かなくなるか、違う場所の数字を拾い始めます。

つまり、少ない商品数で動いていたことも、きのう動いていたことも、あすの保証にはなりません。自動で取ることを考え始めたら、次の3つを先に確かめてください。

1. 規約を読む
   取得先の規約で、プログラムからの自動アクセスが認められているかを見ます。
2. 公式の受け取り口があるか調べる
   認められていない場合、仕入れ先が公式に用意しているデータの受け取り口（API）があるかを探します。
3. 止まったときの損と比べる
   その受け取り口が有料なら、払う額と、データが取れずに販売が止まる損を並べて考えます。

公式の受け取り口は、決まった窓口に申込書を出すと決まった書式で返ってくる仕組みです。相手が用意した正面玄関なので、ある日いきなり閉められることがありません。

そのため判断の軸は「いま動いているか」ではありません。規約で禁止されているなら、有料でも公式の経路に切り替えるほうが、商売として続けられる形になります。

無在庫販売そのものができるかどうか、条件は何かは、出品先のモールごとに違います。この記事は規約で認められた範囲での運用を前提にしています。出品先それぞれの規約を必ず確認したうえでご判断ください。

なぜ「在庫管理ツール1つ」では解決しないのか？

在庫チェックは在庫管理ツールを1つ入れれば済む、と考えるとここでずれます。

その前に、ここからの説明に出てくる場所を3つ呼び分けます。

• 仕入れ先のECサイト（モール）：商品を仕入れる先のサイト全体。在庫データの受け取り口（API）を用意しているのはここです
• 販売元：そのモールに出店して、実際に商品と在庫を持っている店。仕入れ先が単独のネットショップなら、モールと販売元は同じ相手です
• 自分の店：読者が商品を売る側。出品先のモールが複数あることもあります

次の表は、在庫チェックに出てくる3つの役割と、それぞれが担わない部分を並べたものです。

読み方の要点は、1行目と2行目が互いの代わりにならないことです。まとめて管理するサービスは、自分の店の在庫数をそろえて売り越しを防ぎます。ただし、仕入れ先の在庫が切れたことは教えてくれません。

逆に、データを受け取る側は在庫の変化を教えてくれます。そのかわり、出品を止める操作はしてくれません。この2つをつなぐ部分が、自社で決めるやり方になります。

3行目は、上の2行の見張り役です。自動取得は失敗しても、手元の管理画面には前回の数字が残ったまま、正常に見え続けます。しかも、モールの画面や受け取り口に出る在庫数そのものが、実物より遅れて動くこともあります。

壊れにも、ずれにも、数字を受け取った経路の中からは気づけません。だから、販売元の店のページという別の経路で、人が数点だけ見比べます。

もう一つ効いてくるのが、仕入れ先ごとの差です。公式の受け取り口があるかどうかは仕入れ先によって違うため、仕入れ先が複数のサイトに分かれているほど条件はばらつきます。受け取り口が無い仕入れ先ほど3行目の人の確認に頼ることになり、そちらが扱える商品数の上限を決めます。

毎月かかる費用と、一度だけかかる費用

費用は「毎月出ていくもの」と「作るときと直すときだけ出ていくもの」に分かれます。次の表は、その内訳です。

注目してほしいのは、毎月の欄が2行しかないことです。月額として読めるのは、受け取り口の利用料と、プログラムを動かすパソコンの費用の2つだけです。

直す費用は、仕入れ先や出品先のモールの仕様変更に引きずられます。そのため、毎月いくらという形では見積もれません。

自社の月額を出すときは、受け取り口の料金が「取る量に応じたプラン制」になっている点から逆算します。取る商品数と1日あたりの更新回数を先に決めれば、必要なプランが決まります。パソコンのほうは、その処理を1台で回せるかどうかで決まります。

なお、在庫確認の工程をまるごとAIエージェント（指示を受けて自分で手順を考えて動くAI）に任せる形も考えられます。ただし、この形は処理のたびに費用が発生するため、商品数が増えるほど毎月の額が読みにくくなります。

当方にこの構成の実績はありません。いまのところは、決まった処理をプログラムに任せ、判断は人のルールで補うほうが費用を見積もりやすいと考えています。

→ くわしくは「AI導入費用は月1万円から｜3タイプ別の内訳」で解説しています。

運用ラインを決める手順

この手順の要は、1と7で同じ数字を測ることです。在庫チェックが良くなったかどうかは、体感では分かりません。そのため、事故の件数という1つの物差しで前と後を比べます。

担当は専任でなくてかまいません。ただし「在庫切れが見つかったとき、誰が出品を止めるか」だけは決めてください。ここが空白のままだと、自動化しても事故は減りません。

1. 今のトラブル件数を数える
   直近1か月の注文から、仕入れ先の在庫切れが原因のキャンセル・遅延が何件あったかを数えます。
2. 取得先ごとに規約を仕分ける
   プログラムからの自動アクセスが認められているかを、仕入れ先ごとに確かめます。
3. 公式の受け取り口を検討する
   認められていない、または分からない場合は、公式に用意された受け取り口への登録を考えます。
4. 対象と回数を決める
   自動で取る対象を主力商品に絞り、1日に何回更新するかを決めます。
5. 毎日、数点だけ人が見る
   前日から在庫が大きく動いた商品を数点選び、その商品を出している販売元のページを開いて表示を確かめます。
6. 止める条件を決める
   データが取れなかったとき、その商品の出品を止める条件をあらかじめ決めておきます。
7. 1か月後にもう一度数える
   1で数えた件数を測り直し、決めた線が正しかったかを判定します。

当方のEC運用でつまずいた点

在庫データがうまく取れていない状態のまま、販売が続いていたことがあります。管理画面には前回の在庫数が残り、見た目は正常のままでした。

そこで足したのが、数点だけ人が手で確かめるルールです。見張る対象を、商品の在庫数から「プログラムが正しく動いているか」に変えたのが転換点でした。

このとき見に行くのは、取り込んだデータの画面ではありません。その商品を出している販売元のページを直接開いて、表示を確かめます。出どころの違う情報で見比べないと、取得の失敗は見つからないからです。

家計簿にたとえると分かりやすいかもしれません。自分でつけた帳簿を何度見直しても、記入もれは見つかりません。通帳を開いて突き合わせて、はじめて気づきます。在庫の確認もこれと同じで、別の場所から取った数字と比べる必要があります。

頻度は1日1回にしました。仕入れ先の実際の在庫が画面に出るまでには時間差があります。そのため、回数を増やしても正確さは上がらないと判断しました。

かわりに正確さを上げたのは、見る商品の選び方です。前日の在庫と大きく動いている商品から先に見ると、取得の異常がいちばん出やすい場所を突けます。

次の比較は、この考え方に切り替える前と後で、やり方がどう変わったかを並べたものです。

入れ替わったのはツールではなく、人が確認する目的です。人がやるのは在庫数を数えることではなく、自動化が壊れていないかを確かめる仕事になりました。

自社で試すなら、まず見比べる点数と回数を決めて1か月やってみてください。そこで数字の食い違いが出るなら、その仕組みはまだ全部を任せられる状態にありません。

※ 上記は当方が自社のEC運用で経験した内容にもとづきます。

FAQ

自社の業務に合わせたAIツールの選定・導入は、ぜひ当社（ゲンバAI）へ無料でご相談ください。