世界中から旅行者が並びに来る、東京の人気店。その行列を、店舗の収益に変えます。
東京には、世界中からその一店のために飛んでくる人々が、1時間以上並ぶ名店があります。そして、その人たちの多くは、待たずに済むなら喜んで対価を支払います。ifastoは、その待ち時間を店舗の売上に変えるサービスです。
セクション 1 · ライブデモ · 停止中
これは実際に稼働しているプライシングエンジンです。
以下は仮想の店舗ですが、表示されている価格はすべて本物です。提携店舗で使用されているのと同じプライシングエンジンへのライブ呼び出しで、行列の変化に合わせて数秒ごとに再計算されています。行列が伸びていく様子をご覧ください。
スキップパスは、行列が10組に達した時点で開放されます。それ未満の場合、待ち時間が短く、スキップに価値がないためです。
The pricing engine is XGBoost-based (L1 wait prediction) feeding a multiplier-based pricing layer (L4) with hard caps on large-party inventory. The system targets a 12–15% conversion band on queued customers, self-regulating in real time. Calibrated against direct field observation from May 2026.
セクション 2 · 仕組み
価格はこうして決まります。
エンジンは4つの要素を組み合わせて、1つのスキップ価格を導きます。重要なのは抑制です。スキップパスの購入者が行列全体の12〜15%程度に収まるよう価格を調整しています。店舗にとって意味のある収益になりつつ、通常レーンで待つお客様が「割り込まれた」と感じない水準を保つためです。
価格が暴走しない仕組み。
スキップパスが1つ売れるたびに、次の価格は少しずつ上がります。これは意図的な設計です。需要が高まるほど自動的にブレーキがかかり、最高入札者に席を売り尽くして通常レーンのお客様を怒らせる、という事態を防ぎます。
ラーメン店と寿司店が同じ価格で売られるべきではない。
ベース価格は店舗ごとに、お客様がもともと支払っている金額に基づいて設定されます。￥1,500 のラーメン店と ￥30,000 の寿司店では、自動的に全く異なるスキップ価格に落ち着きます。手動で数値を調整する必要はありません。
大人数のテーブルは保護されます。
6名のグループがスキップするということは、希少なテーブル席を1つ手放すということです。そのため、デフォルトでは1サービスあたり大人数のスキップは1組のみに制限されています。この数値は変更も、完全に無効化も可能です。上限に達した場合、スキップ選択肢は自動的に非表示になります。
セクション 3 · 店舗向け試算
御店舗の数値で試算する。
繁忙時の御店舗の実態を入力してください。以下の試算は、ライブエンジンと同じロジックで算出されています。誇張なし、楽観的なシナリオなし。
なぜ作ったか
東京の長い行列に並びながら、この答えにたどり着きました。
あまりに長く待たされていて、ふとこの行列のせいで今日予定していたことの半分はできなくなる、と気がつきました。その瞬間に腑に落ちました。世界中の人がこの店のために旅をしてくる、そしてその体験との間に立ちはだかっているのはただ … 待ち時間なのだと。これを解決する方法があるはずだと。
Arnav
セクション 4 · パートナーシップ
店舗側のリスクはゼロです。
リスクはすべて私が引き受けます。開発コストも、運用コストも、価格設定を誤った場合のリスクも。店舗側は、ただ収益を受け取るだけです。
店舗の負担はゼロ円です。
初期費用、月額費用、最低料金、すべてかかりません。開発・ホスティング・運用のコストはすべて私が負担します。御店舗の帳簿に追加されるのは収益のみ。スキップパスの売上の70%が御店舗の取り分です。
当日中に稼働します。
既にお使いの POS または予約システムへの接続を1つ追加するだけです。スタッフが新しく覚えることも、店内に追加される機器もありません。エンジンは私の側で稼働します。御店舗内には何も置きません。
いつでも解約できます。
年間契約なし、通知期間なし。御店舗にとって機能していないと感じたら、メール1通で終了です。縛り付けるよりも、毎月選んでいただける関係を築きたいと考えています。