Shopifyにバーチャル待合室は標準搭載されていない — 公式が文書化している唯一のスロットルは「待合室」ではない

この記事でわかること

トラフィック急増時にShopifyが実際にやっていること App Storeのこのカテゴリーはほぼ空である — それ自体が調査結果実際に効く比較軸: キューをどこで強制するか CrowdHandler Waiting Room Queue-it Queue-Fair

この記事の目次Contents閉じる開く

「Shopify バーチャル待合室」で検索すると、トラフィック急増時にShopifyが何をしてくれるかを説明するベンダー記事が並ぶ。しかしShopify自身のドキュメントを読むと、そこに書かれている内容はもっと狭く、そして安心できるものではない。

Shopify Help CenterにはFlash salesというページがある。まさに待合室が解決しようとする状況、つまり「数万人の顧客が在庫を奪い合い、再入荷のたびに数分で売り切れる」ケースについての公式ガイダンスだ。このページに「queue」という語は出てこない。「waiting room」も出てこない。代わりに書かれているのは、配送アプリを停止する、在庫を割り当てた1拠点以外のfulfillment locationを無効化する、決済を手動キャプチャに切り替える、そして問題が起きたときに切り替えられるpassword pageを用意しておく、という運用手順である。

これがプラットフォームの素の状態だ。ここから先はすべて、お金を払って手に入れる領域になる。

トラフィック急増時にShopifyが実際にやっていること

ここで3つの異なる仕組みが混同されている。役割はまったく違う。

Storefront APIのcheckout-level throttle。 これは実在する。「Shopifyにはキューがある」と言われるときに指されているのは、たいていこれだ。ShopifyのAPI limitsページにはこう書かれている。「Shopify limits the amount of checkouts that can be created on the Storefront API per minute. If an API client exceeds this throttle, then a 200 Throttled error response is returned.」Shopifyの推奨は「指数バックオフを備えたリクエストキューを実装すること」だ。

よく読んでほしい。対象はStorefront API、つまりヘッドレス構成の経路である。返ってくるのはアプリ側へのエラーコードであり、何を表示するかを決めるのはアプリ側だ。買い物客に見える待合室ではないし、誰かの順番を保持もしないし、先着順でもない。しかもShopifyは具体的な数値を公開していない。API limitsページにも、これを導入したchangelogエントリ（2020年8月4日発効）にも数字は書かれていない。Liquidベースのオンラインストアを運用しているなら、ドロップを支配しているのはこの仕組みではない。そしてオンラインストア側に同等の買い物客向けキューがあるという記述は、Shopifyの公開ドキュメントには存在しない。

Storefront API全体のレート制限。 同じページで、Storefront APIのrate-limiting methodは「None」と明記され、「Requests from real buyers aren't subject to a fixed request-per-minute limit」とされている。Shopifyの立場は、Storefront APIは「最大規模のフラッシュセールにもスケールする」というものだ。つまりプラットフォームは、あなた自身のトラフィックからあなたを守ってはくれない。全部さばきにいく。

ボット対策。 Shopifyは、Storefront APIとShopifyホストのオンラインストアページに対する自動化トラフィックをレート制限している。最も厳しい制限が適用されるのは「unsigned, anonymous bots」で、より高い上限が必要なボット運営者にはWeb Bot Authでのリクエスト署名が案内されている。悪意あるリクエストには430 Shopify Security Rejectionが返る。これは有用な機能だが、キューではない。トラフィックを分類するだけで、順序付けも在庫に対する流量制御もしない。

そしてこの3つとは別に、Shopifyのカートは在庫を確保しない。カートに入れても何も予約されない。ドロップのたびに発生する「カートに入っていたのに消えた」というクレームはこの仕様が原因であり、トラフィック制御だけでは解消しない。

正直にまとめるとこうなる。Shopifyはページを配信し続け、ボットは制限し、ヘッドレスのcheckout生成は数値非公開のまま絞り、そして顧客を列に並ばせることはしない。

App Storeのこのカテゴリーはほぼ空である — それ自体が調査結果

通常の比較記事ならここで7本のアプリを並べる。7本はない。

2026年9月2日時点でApp Storeを調べた結果、本物のバーチャル待合室リスティングは1件だけだった。CrowdHandler Waiting Roomで、公開日は2025年7月28日、レビューは1件である。

このカテゴリーで名前の通った他の2社、Queue-itとQueue-Fairは、App Storeのリスティングではない。自分で連携する外部SaaSだ。この区別は形式的な話ではなく、課金経路、導入経路、そしてストアの前段に置かれるコードを誰が持つのかを決める。

さらに、この分野を検索した人がたどり着くアプリの一部は、別の問題を解いている点にも注意がいる。Wait.li ‑ Viral Waiting ListsはPre-ordersカテゴリーに分類されるリファラル型の事前登録リストで、発売前に興味を登録した顧客をバッチで有効化する仕組みだ。これはマーケティング用のwaitlistであり、リスティングにトラフィック制御機能の記載はない。waitlistはセール前に人を集めるもの、waiting roomはセール中に人を並べるものだ。前者を後者だと思って導入すると、最悪のタイミングでそれに気づくことになる。

実際に効く比較軸: キューをどこで強制するか

どの製品も、待ち順位が表示されたブランドページを買い物客に見せる。違いは、そのページをどこで強制するかにある。

テーマレベル（JavaScript / app embed）。 キューはストアフロント内に置かれる。保護対象ページのスクリプトが有効なトークンの有無を確認し、なければリダイレクトする。導入が速く、DNS変更が不要で、商品単位にスコープできる。弱点は構造的なもので、チェックがブラウザ上で走るため、そのページを経由しなければチェックも経由されない。この方式のベンダーがcart validationとcheckout validationを別途用意しているのはそのためだ。

エッジ / DNSレベル（プロキシ）。 トラフィックがShopifyに届く前にベンダーを通る。ゲートを通らずにストアへ到達するものはない。こちらのほうが強固だが、Shopifyでは手間も大きい。自分で制御できないホスト型プラットフォームの前段に層を差し込むことになるからだ。

通常、checkoutそのものを守れるのは後者だけである。Shopifyでは1社が第3のルートを見つけている。

CrowdHandler Waiting Room

CrowdHandler Waiting RoomのShopify App Storeリスティングページ上部

出典: Shopify App Store（CrowdHandler Waiting Room、2026-09-02時点）

CrowdHandlerは英国拠点の待合室ベンダー（App Storeリスティング上の所在地はCheltenham, ENG, GB）で、DNS、Cloudflare、AWS CloudFront、Akamai、WordPress、サーバーサイドAPIの各連携も文書化している。Shopifyアプリはそのプラットフォームを3プランに簡素化したパッケージ版だ。

CrowdHandler公式のShopifyフラッシュセールガイドによるセットアップ手順は、アプリをインストールし、テーマでapp embedを有効化し、Shopify管理画面のproduct mapperで個別商品またはコレクション単位に保護を設定する、というものだ。つまり強制はテーマレベルのJavaScriptだが、CrowdHandlerはその上にShopifyネイティブの仕組みを2つ重ねている。

1つ目がCart Validatorで、待合室を正しく通過していない訪問者が保護対象商品をカートに追加することを防ぐ。2つ目がcheckout ruleだ。Shopifyのcheckout settingsを開き、CrowdHandlerのcart-checkout-validationルールを追加し、「Allow all customers to complete checkout」のチェックを外す。これがこのアプリを単なるリダイレクトスクリプト以上のものにしている部分で、App Storeのデータアクセス表示にShopify Functionsのcart and checkout validationsの参照が含まれていることとも整合する。

Enterpriseプランでは、待合室を迂回した注文を自動で返品・返金する機能もある。発生を防ぐのではなく、事後に取り消す方式だ。

タイミング設計。 queue activation timeを設定し、その前に15分〜24時間のcountdown periodを置く。カウントダウン中、買い物客は商品ページに入れないが、順位はまだ発行されない。順位が割り当てられるのはキューが起動した瞬間である。CrowdHandlerがこれを推奨する理由は公平性で、URLに早くから張り付く優位性を消すためだ。実務的には、誰も到達できない状態のまま商品を公開し、告知メールを送る時間枠が作れる。

在庫連動。 stock syncingを有効にすると待合室がShopifyの在庫を認識し、one-in-one-outが自動制御され、残在庫やsold-out表示も待合室内に出る。使わない場合は流量（rate）を手動設定する。CrowdHandlerが自社ガイドで示す目安は在庫数÷10で、1,000点なら毎分100人だ。

料金（USD、Shopifyの請求書に合算）。 課金単位は訪問者数ではなく、同時待機数と流量である。

Lite — 無料。 waiting room 1件、ストア1件、待機顧客100人、毎分10人、best-effortsサポート。公式ドキュメント自身が、テスト用およびセール間の設定維持用と位置づけている。
Plus — $1,500 / month。 room 5件、ストア2件、待機顧客20,000人、毎分300人、サポート応答8時間、priority access codes。
Enterprise — $5,600 / month。 room 20件、ストア5件、待機顧客100,000人、毎分1,000人、サポート応答1時間、Advanced Security（IP intelligence、anomaly detection、自動注文保護）。

プラン変更はShopify管理画面から可能で、ダウングレードしても設定は保持される。セール間はLite、イベント時に上げる、という運用が想定されている。

既知の制約。 ドキュメントには、anti-cheat機能が商品ページ上のbranded accelerated checkoutボタンと非互換であると明記されている。CrowdHandlerのJavaScriptは標準のaccelerated checkoutを自動的に隠すが、非標準の決済ボタンはセール中に無効化が必要になる場合がある。撤収手順にも注意がいる。待合室を無効化してもmapperのタグを商品に残したまま在庫があると、買い物客はカートに追加すらできなくなる。captchaは自前のreCAPTCHA、hCaptcha、ALTCHAアカウントが必要だ。

レビュー。 2025年10月20日付のノルウェーのマーチャントによる5つ星が1件のみ。「Shopify向けのキューシステムが急ぎで必要だった」こと、ベンダー側がローンチ前の設定を手伝い本番も監視していたことが書かれている。1件は1件であり、そのローンチがうまくいったことと手厚いサポートが存在することは分かるが、多数のストアにおけるスケール時の挙動は分からない。

Queue-it

Queue-itはトラフィック制御専業のベンダーだが、Shopify App Storeには出ていない。2026年9月2日時点で、Shopify向けページは「Get early access」フォームの背後にある。現状の導入は他プラットフォームと同じで、Queue-itはクライアントサイド・サーバーサイド・エッジ合わせて20以上のコネクタを提供し、Akamai、CloudFront、Cloudflare、ASP.NET、PHP、JavaScriptを挙げている。

リスティングがなくてもQueue-itを理解しておく価値があるのは、アクセス方式を明示している点と、ここで扱う3社のうち唯一、Shopify自身の挙動との直接比較を公開している点だ。同社はShopify向けページで「Shopify's checkout throttle」について、起動タイミングや方法を制御できない、公平アクセスの仕組みがない、ブランディングとカスタマイズが限定的、訪問者への情報開示がない、と整理し、自社の granular な起動制御、first-in-first-outと抽選、フルカスタマイズ、リアルタイムの待ち時間表示と対比させている。

このFIFO対抽選の違いは、選択を迫られていること自体をマーチャントが知らないことが多い論点だ。Queue-itのScheduled waiting roomは、早く来た訪問者をカウントダウンページに集め、セール開始時にランダム化する。これとは別にtrue first-in-first-out、つまり到着順どおりの入場も運用できる。両者が語る公平性はまったく違う。FIFOは早く来た者に報いる、つまり「早く来ることを自動化した者」に報いる。開始前に集まった全員の中から抽選すれば、そのインセンティブは消える。ボットの多い市場で売るなら、これは設定項目ではなく戦略判断だ。

料金（USD）。 小規模事業者向けのQueue-it Essentialsはイベント単位課金で、他社が使っていない単位である。

年1イベント: from $1,499 / event
年2イベント: from $1,349 / event（from $2,699 / annually）
年3イベント: from $1,276 / event（from $3,839 / annually）
Unlimited events: from $5,999 / year（from $499 / monthly）、年払い

全バンドルに、イベントあたり5,000人のキュー収容、Scheduled waiting room、20以上のコネクタ、流量調整、FIFO、50以上の言語、管理者アカウント無制限、24/5のテクニカルサポートが含まれる。24/7 peak protection、Bots & Abuse Management、「your turn」メール通知、追加room、追加キュー容量はいずれもアドオンだ。エンタープライズ料金は個別見積もりとなる。

Queue-Fair

Queue-FairもShopify App Storeには出ておらず、料金も一切公開していない。料金ページに「We don't display specific numbers on our website」と明記されており、単発イベント、シーズン利用、従量、定額と用途が幅広いためだとしている。同社が最も選ばれていると説明しているのは従量モデルで、「サイトへの訪問者数と、その訪問者がどれだけ頻繁にキューに入れられるか」で課金される。24時間保護が必要なサイト向けにはFlat Rateがある。Free Tierも存在し、「comparable surge protection quote」に対する25%割引も提示している。

Shopifyでの連携方法はクライアントサイドJavaScriptアダプターで、ページにタグを1つ追加し、キューと起動ルールはQueue-Fair Portalで設定する。Queue-FairはNode、PHP、Python、Ruby、Java、Go、.NET、Cloudflare、Google Cloud、Azure向けのサーバーサイド／エッジアダプターに加えSquarespace専用アダプターも公開しているが、Shopify専用アダプターもShopifyアプリも、今回の調査で確認できるShopify固有のドキュメントも存在しない。同社が公開しているeコマース向けページにShopifyへの言及はない。

Shopifyマーチャントにとってこれが意味するのは、汎用のJS経路で動作はするが、CrowdHandlerが備えるようなShopifyネイティブのcart / checkout強制はない、ということだ。Queue-FairがShopifyのcheckoutをゲートできるかどうかは、公式情報では確認できなかった。

比較表

	CrowdHandler Waiting Room	Queue-it	Queue-Fair
App Storeリスティング	あり（2025年7月28日公開）	なし（early access登録）	なし
Shopifyでの強制方法	Theme app embed（JavaScript）+ product/collection mapper	クライアント／サーバー／エッジのコネクタ20以上	クライアントサイドJavaScriptアダプター
checkout自体を保護	可 — Cart Validator + `cart-checkout-validation` checkout rule	Shopify固有の記載なし。トリガーはadd-to-cartやloginも保護可	公式情報では確認できなかった
入場順	カウントダウン後、起動時に順位発行。one-in-one-out	FIFO、またはセール開始時の抽選	公式情報では確認できなかった
在庫連動	可 — Shopify stock syncingでone-in-one-out	在庫僅少時のアクセス制御による売り越し防止を明記	公式情報では確認できなかった
ボット対策	captcha（自前アカウント）、fingerprinting、IP firewall。Enterpriseでanomaly detectionと自動返金	Bots & Abuse Management（Essentialsではアドオン）	今回未検証
課金単位	月額（同時待機数と流量）	イベント単位、または年額で無制限	キュー投入訪問者数（従量）、または定額
開始価格（USD）	無料（待機100人、毎分10人）／$1,500 / month	from $1,499 / event、$5,999 / year（無制限）	Free Tierあり。有料料金は非公開
課金経路	Shopifyの請求書	ベンダーと直接契約	ベンダーと直接契約
評価 / レビュー件数	5.0（1件）	リスティングなし	リスティングなし

課金単位は互いに換算できない

ここが落とし穴だ。3社、3つの互換性のないメーターがある。

CrowdHandlerは月額で、同時待機容量と入場レートを売る。買っているのは「20,000人が待てて、毎分300人が入れる」という状態だ。
Queue-it Essentialsはイベント単位で、1イベントあたり5,000人のキュー収容を売る。買っているのは「セール当日1日分」だ。
Queue-Fairはキューに入れた訪問者数で売る。買っているのは期間中の処理量だ。

自社の2つの数字を知るまで、この3つに優劣はつけられない。年間のドロップ回数と、同時に押し寄せる人数である。年1回の大型ドロップならイベント単位が明確に安い。1イベント$1,499に対し、1日しか使わない1か月に$1,500を払うことになるからだ。2週間に1回ドロップするなら月額か年額無制限が勝つ。同時接続が数百規模の小さなリリースを高頻度で回すなら、従量が両者を下回る可能性がある。普遍的に安い選択肢はなく、自社のカレンダーにとって安い選択肢があるだけだ。

アプリ版にだけ効く要素がひとつある。CrowdHandlerのPlusとEnterpriseの請求はShopifyの請求書に載る。3社の中でこれが成立するのはCrowdHandlerだけだ。

判断の順序

まだ何も壊れたことがないなら、今は買わなくていい。 まずShopify公式のフラッシュセール準備手順を消化する。fulfillment locationを1つに絞る、carrier-calculated ratesを止める、決済を手動キャプチャにする、コレクションとテンプレートを簡素化する、password pageを準備する。これらの失敗はトラフィック問題に見えて、実際には違う。無人でセールを開始したいだけなら、それはキューではなくスケジューリングの問題だ。

課題がサイト容量ではなく公平性とボットなら、商品ページだけでなくcartとcheckoutまで強制が届く必要がある。App Store上で現在それを満たすのはCrowdHandlerで、理由はCart Validatorとcheckout ruleの組み合わせにある。転売業者に狙われた経験があるならEnterpriseを前提に予算を組む。自動返品・返金もanomaly detectionもEnterprise限定だ。あわせて不正対策ツールの守備範囲も確認しておきたい。キューだけで不正が止まると考えないほうがいい。

年に1〜2回の大型イベントだけなら、月額契約を結ぶ前にQueue-it Essentialsの見積もりを取る。$1,499のイベント単位バンドルはそのカレンダーに合った形であり、セール開始時の抽選という選択肢は現時点でApp Storeのどのリスティングも提供していない。

支出前に挙動を試したいなら、CrowdHandlerのLiteとQueue-FairのFree Tierがある。Liteの待機100人・毎分10人という上限は、CrowdHandler自身のドキュメントが位置づけているとおりリハーサル用だ。本番の1週間前に、関心の低い商品を使い、シークレットウィンドウで試す。

どれを選ぶにせよ、撤収手順をテストする。 CrowdHandlerのガイドにある警告は全製品に一般化できる。待合室を消したあとに強制だけ残すと、買い物客は何も買えなくなる。待合室の失敗モードは「入れすぎる」ことではない。終わったつもりのあとに、静かに全員を締め出し続けることだ。

出典

料金、プラン上限、評価、レビュー件数はいずれも2026年9月2日時点で上記の情報源から確認した。Queue-itのShopify向け提供はearly access段階であり、Queue-Fairは料金を公開していないため、両者とも見積もりが必要となる。

Shop Pay Installmentsは有効化無料、アプリ不要、そしてShopifyは手数料を公開していません。レートを見られるのは自社の管理画面の中だけです。加えてCapital OneとChaseのクレジットカードを受け付けず、月次プランはデビットカード限定、ギフトカードとサブスクリプション商品は対象外で、商品ごとにオン・オフを切り替えることもできません。Affirmはパスワード保護中のストア、英語以外の主要言語、主にB2Bという理由でアカウントを停止します。さらにShopifyの「Getting paid」ページは「disputeは管理画面に通知される」と書き、FAQは「管理画面には通知されない」と書いています。適格性を満たせない場合の代替はKlarna、Afterpay、Sezzle、Zip、PayPalのon-site messagingアプリで、このカテゴリーの評価は1.0〜3.2です。調査日は2026年9月2日です。