「リアルタイム在庫連携」は実際に何秒なのか　海外の速度表記とAPI上限から考える

在庫連携ツールや価格改定ツールの紹介ページには、ほぼ例外なく「リアルタイム」と書かれています。ところが、その言葉が指す時間を各社の表記から拾い集めると、3桁近く違う数字が並びます。海外ツールの公開表記と、Amazon・Yahoo!ショッピングが公開しているAPI制限値から、「リアルタイム」の中身を分解します。

「リアルタイム」に業界の共通定義は無い

まず、同じツールについて別々の会社が書いた数字を並べてみます。以下はいずれも2026年8月時点の各社サイトの表記で、第三者による計測ではありません。

RepricerExpressは自社サイトで、競合の価格が変わってから自分の価格が更新されるまでを「1〜2秒」と表記しています。同じ会社のツールを、競合にあたるRepricer.comの比較記事は「15分ごとに価格改定する」と紹介しています。1〜2秒と15分では、450倍から900倍の開きがあります。

ここで大事なのは、どちらのページも「何を起点に、何を終点として測った数字なのか」を書いていない点です。前者は変化を検知してから価格を送るまでの速さを指しているように読め、後者は次に相場を見に行くまでの間隔を指しているように読めます。ただしこれは、書かれていない前提をこちらで補った読み方にすぎません。定義が明示されていない以上、この二つを同じ物差しの上に並べて比べることはできない、というのが正確なところです。

同じRepricer.comの比較記事は、Informed.coを「10〜15分ごと」、Seller Snapを「5〜10分ごと」としています。いずれも競合他社が書いた数字である点には注意が必要です。なお、RepricerExpressのページにも第三者による計測結果は示されていません。

もうひとつ、速度表記には適用範囲という落とし穴があります。Auraは自社ブログで、標準の状態ではAmazon側が新価格を確定するまでに1分30秒から2分の待ちがあり、Hyperdrive機能を使うとこれが10秒以内に縮むと説明しています。ただし同社の記載では、この機能の対象は1アカウントあたり50商品です。3,000SKUを扱う事業者にとって、この10秒は在庫全体の1.7%にしか効きません。

遅延はどこで生まれるのか

在庫や価格が実際に切り替わるまでの時間は、次の4区間の合計になります。

1. 検知待ち（相場や自社在庫の変化に気づくまで）
2. 自社処理（ルール判定とキューの滞留）
3. API送信（モールのレート制限で決まる）
4. モール側の反映（受け付けてから店頭表示が変わるまで）

このうち、公開情報から数字を出せるのは1・3・4です。順に見ていきます。

検知待ちはAPIの上限で決まる

Amazon SP-APIのgetItemOffersは、公式ドキュメント上で0.5リクエスト／秒、バースト1と定められています。1商品の相場を見るのに2秒かかる計算です。1,000SKUをこの方法だけで一巡させると2,000秒、およそ33分になります。5,000SKUなら2時間46分です。

比較記事に「15分ごと」「10〜15分ごと」といった数字が並ぶのは、ポーリング中心の設計ではこのあたりが構造的な下限に近いからではないかと考えられます。ただし各社が内部設計を公開しているわけではないので、これは数字の並びから読み取った推測です。

秒単位を掲げるツールは、ポーリングではなくプッシュ通知を使っています。SP-APIのNotifications APIにはANY_OFFER_CHANGEDという種別があり、上位20オファーの価格変更、カートを獲得している出品の入れ替わり、カート価格の変動などをきっかけに、Amazon Simple Queue Service経由で送られてきます。Amazonは公式ドキュメントで、これを「情報を取りに行く代わりに、Amazonから直接受け取る」仕組みだと説明しています。

ただし制約もあります。通知が拾うのはコンディション別の上位20オファーまでで、21位以下の値動きは届きません。また、自分が出品していない商品は購読できません。プッシュに切り替えても、見えていない範囲は残ります。

送信側にも上限がある

価格や在庫を送る側にも制限があります。

AmazonのListings Items API v2021-08-01では、patchListingsItemとputListingsItemがいずれも5リクエスト／秒、バースト5です（アカウントとアプリケーションの組み合わせあたりの値）。1,000SKUの価格を1件ずつ送ると200秒、10,000SKUなら2,000秒でおよそ33分かかります。

大量更新はFeeds APIを使うことになります。JSON_LISTINGS_FEEDは仕様変更により、1回あたりの上限が10,000件から25,000件へ、投入頻度が5分に1回から5分に5回へ引き上げられました。一方でcreateFeed操作そのものの持続レートは0.0083リクエスト／秒、つまり約120秒に1回で、バーストが15です。Amazonは「先に到達した方の制限が効く」と明記しています。まとめて送るほど1件あたりは速くなり、こまめに送るほど1回あたりの待ちが効いてくる、という関係です。

モール側の反映が最後に残る

Yahoo!ショッピングのAPIは、公開されている各仕様ページで一律「1クエリー／秒」と記載されています。1リクエストで扱える件数は操作によって違い、在庫更新APIは商品コードをカンマ区切りで最大1,000個、商品一括更新APIはitem1からitem100までの最大100商品です。

ここで見落としやすいのが反映です。商品登録APIと商品一括更新APIの仕様ページには、どちらも「フロント反映はしません。別途反映処理が必要です」と明記されています。価格は商品データに含まれるため、価格改定はこの経路に乗ります。つまりYahoo!ショッピングでは、商品データの更新と反映が別の工程になっています。

ひとつ補足しておくと、この注記があるのは商品データ側のAPIで、在庫更新APIの仕様ページには同じ記載がありません。在庫数だけを更新する場合と、価格を含む商品データを更新する場合とで、必要な工程が違うということです。

その反映を担う商品個別反映APIは、「指定した商品データを１つだけを反映します」という仕様で、こちらも1クエリー／秒です。1,000商品を個別反映で処理すると1,000秒、約17分かかります。3,000商品なら50分です。

さらに同ページには、「OKレスポンスが返却されてもシステムの処理途中でエラーになる場合があるため、反映履歴または反映エラーメールをご確認ください」と書かれています。送信が成功したことと、店頭に反映されたことは別物です。連携ツールが送信成功だけを見て「同期完了」と表示していれば、実際には反映されていない状態を正常として扱ってしまいます。

遅延1分は、どれくらいの売り越しにつながるのか

秒数の議論を、自社の損失に翻訳します。ここからは公開情報にもとづく試算で、当社の実測値ではありません。

在庫を1点だけ持つ商品を考えます。あるモールで注文が入った瞬間から、他モールの在庫表示が更新されるまでのL秒間、他モールは売れる状態のまま残ります。この窓の中に別モールから同じ商品への注文が入ると、売り越しになります。

同じ商品への注文の平均到着率を「1日の受注件数 ÷ 86,400秒」とすると、1日あたりの売り越し件数の上限はこう書けます。

売り越し件数／日 ≒ n² × L ÷ 86,400 × (N−1) ÷ N

• n：その商品が1日に受ける注文件数（全モール合計）
• L：在庫を全モールに反映しきるまでの遅延秒数
• N：出品しているモール数

注目すべきは、nが2乗で効くことです。注文が増えると、危険な窓の数と、その窓に別の注文が飛び込む確率が同時に上がるためです。売り越しは受注量に比例するのではなく、受注の集中度に対して急に立ち上がります。

3モール出品（N=3）として年間換算したものが次の表です。

1日1件しか売れない商品なら、遅延が15分あっても年2.5件です。安全在庫を1点積むだけで実質的に消えます。ところが1日10件動く商品では、同じ15分の遅延が年253件になります。これは年間受注3,650件の6.9%にあたります。

この数字がAmazonのアカウント指標にどう関わりうるかも見ておきます。出荷前キャンセル率について、複数のEC専門メディアは、目標値が2.5%未満で、直近7日間の出品者出荷（MFN）注文を対象に測られると説明しています。FBA注文は対象外です。つまりここでの話は、自己発送で売っている場合に限られます。

条件を置いた仮の計算として、1日10件・遅延15分の商品を8点抱え、3モールに均等に分散していると仮定すると、Amazon分の売り越しは週13件になります。同じ週のAmazonでの出品者出荷注文が500件なら2.6%で、目標値をわずかに超えます。ただしこれは、目標値を超える条件を逆算して組み立てた例です。一般的な水準を示したものではありません。

売り越しは1件ごとの損失が小さく見えるため後回しにされがちですが、集中して出るとアカウントの健全性指標にまで届きうる、という程度には見ておいたほうが安全です。

Methodology

この記事の数字の出どころ

• ツールの速度表記は、各社が2026年8月時点で自社サイトおよびブログに掲載している内容です。第三者による計測ではありません。競合ツールの速度に関する記述は、いずれも別の競合他社が書いたものである点に留意してください。
• Amazon SP-APIのレート制限は、Amazonの開発者向けドキュメントに記載された既定値です。Product Pricing APIのリファレンスには「事業上の必要性に応じて、記載より高いレートが適用される場合がある」旨の注記があり、実際の上限はアカウントによって変わります。
• Yahoo!ショッピングAPIの制限値と反映仕様は、Yahoo!デベロッパーネットワークの各API仕様ページの記載によります。
• 出荷前キャンセル率の目標値2.5%と、その対象が出品者出荷（MFN）注文・直近7日間であることは、EC専門メディアおよび海外のEC情報サイトの記載を参照しました。Amazonの公式ヘルプページは取得できなかったため、最新の基準はセラーセントラルのアカウント健全性ダッシュボードでご確認ください。

確認できなかったこと

• BQoolが自社サイトで価格改定サイクルを何分と表記しているかは、確認できませんでした。本記事の表では「確認できず」としています。
• 楽天市場のRMS APIについては、仕様書の閲覧にRMSへのログインが必要で、公開URLからレート制限値を確認できませんでした。このため楽天の数値は扱っていません。
• メルカリShops、au PAYマーケット、Qoo10のAPI制限値も同様に、公開情報から確認できた範囲に含まれていません。

計算していないこと

• 売り越しの試算は、在庫を常に1点しか持たない、注文が時間的に一様に到着する、遅延中は他モールが必ず古い値を表示する、という3つの前提を置いた上限値です。安全在庫を積めば実際の件数はこれより急速に下がります。
• 表の右下（1日30件・遅延5分以上）は、計算上の値が受注全体の7%を超えており、確率が小さいことを前提にした近似が崩れる領域です。上限としても粗いものとして扱ってください。
• キャンセルに伴う顧客対応の工数、レビュー低下、検索順位への影響は計算に含めていません。
• これらはすべて公開情報にもとづく試算であり、ClariaSyncの実測値ではありません。 当社の遅延実測値は現時点で公開していません。

ツール選定で確認すべき3つの質問

秒数を比べても意味がないとすれば、代わりに何を聞けばよいのか。次の3つが有効です。

1. その秒数は、どこからどこまでを測っていますか

変化が起きた時点を起点にしているのか、自社システムが変化を受け取った時点からなのかで、数字は大きく変わります。終点についても、APIにリクエストを送った時点なのか、モール側で店頭表示が変わった時点なのかを確認してください。Yahoo!ショッピングの商品データのように反映処理が別工程になっている場合、この違いが分単位で効きます。

2. その速度は、全商品に適用されますか

上位何件かだけが高速で、残りは通常サイクルという設計は珍しくありません。Auraが機能の対象を50商品と明記しているのは、むしろ誠実な部類です。自社のSKU数を伝えた上で、全件を一巡させるのに何分かかるかを聞くのが確実です。

3. 遅延している間、システムはどう振る舞いますか

遅延をゼロにはできない以上、遅延中の設計こそが差になります。安全在庫を自動で積むのか、危険な状態を検知して受注を止めるのか、それとも売り越しを許容して事後処理に回すのか。あわせて、送信成功と反映完了を区別して監視しているかも確認してください。区別していないツールは、反映されていない状態を正常と表示します。

ClariaSync の場合

ClariaSyncが行っているのは、遅延をゼロにすることではありません。モールのレート制限は誰にも動かせず、Yahoo!ショッピングの反映処理を待つ時間も、AmazonのListings Items APIの5リクエスト／秒も、ツールを乗り換えたところで変わりません。SKU数が増えれば一巡時間が伸びるのも同じです。

できるのは、遅延がある前提で売り越しを起こしにくくすることです。在庫にバッファを持たせて、反映を待っている間に売り切れてしまう幅を狭めます。価格の自動改定には下限と上限を設けているので、下限を割る価格も、相場から外れた高値も送りません。モール別の手数料を踏まえて利益を計算するため、価格を動かした結果が赤字になっていないかをモールをまたいで確認できます。

一方で、当社の遅延実測値はまだ公開できる段階にありません。この記事で示したのは公開情報からの試算だけで、そこに自社データは1件も含まれていません。実測値を公開できる状態になったら、この記事を数値付きで更新します。

秒数を掲げる代わりに、遅延がある前提でどう設計しているかを説明する。現時点でお伝えできるのはそこまでです。