即時予約と予約リクエストのモデルの違い

著者: Brian Tr · 更新日: 2026年10月7日

どのマーケットプレイスも、小さな問いに答えなければなりません。その答えが製品全体を形づくることになります。購入者が「はい」と言ったとき、誰が「はい」と返す必要があるのか。マーケットプレイスによっては、答えは「誰もいない」です。購入者がクリックして支払えば、予約が成立します。別のマーケットプレイスでは、購入者がリクエストを送り、販売者が判断するまで待ちます。

前者のモデルは通常、即時予約（インスタントブック）と呼ばれます。後者は予約リクエスト（Request to Book）です。どちらが優れているとも言えません。両者は購入者のスピードと販売者のコントロールを引き換えにしていて、適切な選択は、何を売っているか、販売者が失うものの大きさ、プラットフォームが販売者を守るために何ができるかで決まります。この記事では、両方のモデルを定義し、それぞれが承認率、キャンセル、検索をどう変えるかを整理し、成熟したマーケットプレイスの多くが行き着くハイブリッド型を取り上げ、どの種類のマーケットプレイスがどちらに傾くかを示します。

プラットフォームのルールは変わります。そのため、ここで説明するポリシーはすべて、引用したページを確認した2026年10月7日時点のものです。恒久的な事実ではなく、日付付きのスナップショットとして扱ってください。

重要なポイント

• Airbnbでは、「Confirm and pay」ボタンが表示されている出品は即時に予約でき、「Request to book」と表示されている出品は先にホストの承認が必要です（Airbnb Help Center、2026年10月7日確認）。
• Airbnbによると、リクエストに対してホストは通常24時間以内に返答し、インド以外では、ホストが断った場合やその期間内に返答しなかった場合、ゲストに請求されることはありません（Airbnb Help Center）。
• 5都市の約6,400件のAirbnb出品を対象とした2015年のフィールド実験では、白人らしい名前のゲストからの問い合わせは約50%で承認され、アフリカ系アメリカ人らしい名前のゲストでは約42%でした（Edelman, Luca and Svirsky, AEJ: Applied Economics, 2017）。
• 同じ論文のアブストラクトは、はっきりとアフリカ系アメリカ人らしい名前のゲストからの申し込みは、同一条件でもはっきりと白人らしい名前のゲストと比べて承認される可能性が16%低かったと報告しています（Edelman, Luca and Svirsky）。
• Airbnb自身の検索ランキングチームは、ホストがゲストのリクエストを承認する可能性を予測するモデルを含む、ランキングのエコシステムについて説明しています（Haldar et al., arXiv 1810.09591）。
• 2023年11月、Turoは2024年上半期から、ゲストがすべての旅行をBook Instantlyで予約できるようになると発表しました（Turo Field Notes）。

2つのモデルの定義

即時予約（インスタントブック） とは、販売者が事前にコミットするモデルです。販売者はルール（価格、カレンダー、最低宿泊日数、予約できる人）を一度設定し、そのルールを満たす購入者はすぐに確定の連絡を受け取ります。販売者は、個々の取引が成立する前にそれを目にすることはありません。

予約リクエスト（リクエスト予約） とは、販売者が取引ごとに判断するモデルです。購入者が日程と詳細を送信し、販売者がリクエストを確認して、承認または辞退します。それまで、予約は存在しません。

Airbnbのヘルプセンターは、1つのページで両方を示しています。住まいの予約ガイドでは、購入者に「Confirm and pay」と表示されていればすぐに予約でき、「Request to book」と表示されていれば、支払い情報を追加し、ポリシーを確認し、送信前にホストへメッセージを送れると説明しています（Airbnb Help Center、記事85）。即時予約の記事では、購入者側の条件も加わります。ゲストはアカウントの設定を完了している必要があり、予約は31泊未満でなければなりません（Airbnb Help Center、記事523）。

2つの流れの違いに注目してください。それがこの話のすべてだからです。予約リクエストには、購入者の意図と販売者のコミットメントの間にギャップがあります。そのギャップは、販売者がコントロールを得る場所であり、同時に購入者が足止めされる場所でもあります。

各モデルが最適化するもの

このギャップには、両側でそれぞれ価格がついていると考えてみてください。

購入者にとって、ギャップのコストは時間と確実性です。今夜泊まる場所が必要な旅行者は、1日待つことはできません。5件の出品を比較している購入者は、5件の保留中のリクエストを抱えるか、1件ずつ送らなければなりません。Airbnb自身のガイダンスにもそれが表れています。即時予約について、ホストの条件を満たすゲストが、承認を求めるリクエストを送る代わりに、すぐに予約できる仕組みだと説明しており（Airbnb Help Center、記事85、関連記事）、ゲスト向けのページではこの選択肢を「especially convenient for last-minute trips」（直前の旅行にとりわけ便利）と呼んでいます（Airbnb Help Center、記事523）。

販売者にとって、ギャップをなくすことのコストはコントロールです。ギャップがなければ、プロフィールを読むことも、質問することも、合わない宿泊を断ることもできません。これが最も重要になるのは、悪い取引のコストが大きい場合です。自宅に見知らぬ人が入る、見知らぬ人が自分の車を運転する、特定のスキルが必要なプロジェクトなどです。販売者が失うものが大きいほど、ギャップを取り戻したくなります。

プラットフォームは、全体のレベルでも同じトレードオフを感じています。待ち時間をなくせば、保留中のリクエストを抱える購入者が減るため、コンバージョンにはおそらくプラスに働きますが、前提にするのではなくテストすべきです。逆のリスクも現実にあります。見知らぬ人が自動的に予約するモデルでは、そもそも出品しない販売者もいます。これがより広いファネルにどうつながるかは、マーケットプレイスのコンバージョンのリファレンスを参照してください。

承認率、キャンセル、「ノー」のコスト

リクエスト型のモデルでは、販売者の判断が、プラットフォームが管理しなければならない変数になります。2つのことが起こります。

第一に、承認は保証されていないため、リクエストは予約ではなく確率です。Airbnbの検索ランキングの研究者は、はっきりとそう述べています。彼らが説明するランキングモデルは、ホストがゲストの予約リクエストを承認する可能性を予測するモデルを含む、モデル群のエコシステムの一部です（Haldar et al.、「Applying Deep Learning To Airbnb Search」）。これは予約リクエストが設計にもたらす帰結です。あるホストが特定のゲストを断る可能性が高いなら、その出品をそのゲストに表示するのは、双方の時間の無駄です。即時予約はこの予測の問題を取り除きます。承認はルールによってすでに決まっているからです。

第二に、販売者の返答の振る舞いが、測定し管理すべきものになります。Airbnbはゲストに対して、ホストが通常24時間以内に返答すること、そしてインド以外では、ホストが断った場合やその期間内に返答しなかった場合、ゲストに請求されないことを伝えています（Airbnb Help Center、記事85）。この一文には、ポリシー全体が詰まっています。リクエストには期限があり、購入者は解放され、販売者がコミットするまでプラットフォームは支払いを受け取りません。こうしたルールがなければ、返答の遅い販売者が、購入者の資金や予定を際限なく拘束できてしまいます。

キャンセルも動きますが、より微妙な形です。即時予約では、販売者はこの特定の購入者に同意していないため、ミスマッチは確定後に、キャンセルや紛争として現れます。予約リクエストでは、ミスマッチはより早い段階で、辞退として取り除かれます。同じミスマッチが、別の箱に入るのです。モデルを切り替えるプラットフォームは、問題が消えると期待すべきではありません。問題は「辞退されたリクエスト」から「キャンセルとクレーム」へと場所を移すだけで、プラットフォームは新しく現れる場所に対するポリシーを必要とします。これはコンバージョンの問題であると同時に、トラスト＆セーフティの設計の問題でもあり、即時予約のプラットフォームの販売者に、審査ツールや、ペナルティなしでキャンセルできる手段が通常与えられるのはそのためです。販売者の保護と救済措置は、この取引のもう半分であることが多く、プラットフォームが供給の質をどれだけ管理できるかに左右されます。

業界を動かした差別の調査結果

予約リクエストになぜ隠れたコストがあるのかを示す最も強力な証拠は、Airbnbでのフィールド実験から得られたものです。ベンジャミン・エーデルマン（Benjamin Edelman）、マイケル・ルカ（Michael Luca）、ダン・スヴィルスキー（Dan Svirsky）は、名前以外は同一のゲストアカウントを作成しました。はっきりとアフリカ系アメリカ人らしい名前のグループと、はっきりと白人らしい名前のグループを用意し、2015年7月7日から30日の間に、空き状況を尋ねる約6,400件のメッセージをホストに送りました（Edelman, Luca and Svirsky）。

結果は、白人らしい名前が約50%、アフリカ系アメリカ人らしい名前が約42%の割合で承認されました。著者らが掲げる見出しの結論は、承認の可能性が16%低いというもので、このパターンはあらゆる規模のホストに共通し、アフリカ系アメリカ人のゲストを一度も受け入れたことのないホストに集中していたと報告しています。

著者らはこれを市場設計に結びつけています。Airbnbではホストがゲストの名前、多くの場合は写真を見た上で承認または拒否でき、一方でAmazon、eBay、Expediaのようなプラットフォームでは、販売者が事実上すべての購入者を受け入れると事前にコミットしているため、差別の余地がほとんどない、と述べています。著者らが提案した改善策には即時予約の拡大が含まれており、それによって差別の機会がなくなり、ゲストにも利便性の利点がもたらされると述べています。また、彼らのサンプルでは、即時予約を許可しているホストはごく一部にすぎなかったことも観察しています。さらに論文には、掲載が受理された日に、Airbnbが、即時予約を提供するホストの割合を増やす目標を含む変更計画を発表したことが付記されています。

注意点が2つあります。これは1つのプラットフォーム、1つの年、1種類の問い合わせの結果です。つまり、ホストが個人の属性を見る状況でのリクエスト型モデルについての証拠であり、普遍的な法則ではありません。そして論文は、この問題全体を市場設計者にとってのトレードオフとして明確に位置づけています。販売者の判断に役立つ情報は、偏見を可能にすることもあるのです。予約リクエストが本質的に差別的なわけではありません。販売者に裁量の判断を与えるものであり、偏見が入り込みうるのは裁量のあるところです。

Turoも、同様の主張を率直な言葉で行いました。2023年の発表は、ホストによるゲストの選別は差別的になりうるものであり、自社のコミュニティに望む行動ではない、と述べています（Turo Field Notes）。

ハイブリッド型：ギャップなしのコントロール

ほとんどのマーケットプレイスは、両極の間のどこかに行き着きます。よくあるパターンは4つです。

1. 条件付きの即時予約。 販売者は事前にコミットしますが、条件を満たす購入者に対してのみです。Airbnbは、即時予約を、ホストの条件を満たすゲストがすぐに予約できる仕組みだと説明しています（Airbnb Help Center、記事85、関連記事）。コントロールは、一人ひとりを判断することから、基準を一度設定することへ移ります。スピードを保ちながら、販売者にフィルターを与えますが、プラットフォームが販売者に何を条件として許すか（そしてその条件自体が偏見を生まないか）は、監査に値する設計上の判断です。

2. 例外つきの即時予約。 即時確定が安全でない場面では、プラットフォームが承認に戻します。Airbnbの例は直前の到着です。ゲストがチェックインの2日以内に予約し、ホストのチェックイン時間帯の外に到着したい場合、ホストにはRequest to Bookが送られ、希望する時間で問題ないかどうかを判断します（Airbnb Help Center、記事85）。即時確定を手放さずに、運用上のエッジケースを処理する、小さなルールです。

3. 即時予約と販売者側のコントロール。 Turoの2023年11月の投稿は、Book Instantlyが標準の予約方法になると発表するとともに、この変更に2つのホスト向けコントロール機能を組み合わせました。場所に基づく旅行期間の設定と、カスタマイズ可能な受け取り・返却時間です（Turo Field Notes）。同じ投稿はプラットフォーム側の審査にも触れており、Turoはすべてのゲストと旅行を機械学習のリスクモデルで審査し、高額な車両には年齢や免許保有年数の制限などの適格性の制限を適用するとしています。コントロールは、取引ごとの承認から、設定とプラットフォームによるリスク評価へと移ります。Turoはまた、Book Instantlyをオンにした車両は、ゲストが待つことを好まないため、月ごとの収益が高くなる傾向があると、自社の主張として述べています。これはプラットフォームが自社のデータについて述べたものであり、独自に検証することはできません。

4. 見積りと交渉による予約。 価格や範囲が固定されていない場合、どちらの純粋なモデルも当てはまりません。購入者が依頼内容を説明し、販売者が条件を提案し、双方が確定します。これは1段階多い予約リクエストであり、商品がカスタマイズされるところでは当たり前の形です。プラットフォーム上で価格がどう発見されるかに直接つながります。

どのマーケットプレイスがどちらに傾くか

パターンは、商品がどれだけ標準化されているか、悪いマッチのコストがどれだけ大きいか、購入者にどれだけ時間があるか、という少数の変数に従います。

レンタル管理ソフトウェアの提供企業がホスト向けに示すガイダンスも、この論理と一致しています。長期滞在のみを提供するホスト、独自の特徴があるホスト、ゲストに特別な要件があるホスト、あるいは空き状況が他の要因に左右されるホストには、予約リクエストを勧めています（Rentals United help center）。これはベンダーの運用上のアドバイスであり、研究ではありませんが、上記の変数と合致しています。

B2Bのケースには注記が必要です。契約が大きく、関係性が重要な場合、購入者と販売者の双方が、コミットの前に会話を期待するため、「ギャップ」は欠陥ではありません。製品の一部です。購買プロセスがなぜ異なるのかは、B2BとB2Cのマーケットプレイスの違いのリファレンスで扱っており、マネージド型マーケットプレイスのモデルも、部分的には同じ問題への答えです。プラットフォームがマッチングの段階に入り込むことで、どちらの側もそれをしなくて済むようにします。

モデルの選択と順序づけ

取引モデルを設計または見直すときは、いくつかの考え方の手順が役に立ちます。

1. 悪いマッチのコストから始める。 失敗した取引が安く、元に戻せるなら、即時に傾けます。高額または安全でないなら、判断のポイントを残すか、販売者の判断の代わりにプラットフォームが行う審査を置きます。
2. 誰がリスクを負うかを決める。 即時予約が機能するのは、販売者が事前にコミットできるだけの下振れ（検証、保護、救済措置）をプラットフォームが吸収しているときです。プラットフォームがまだそれをできないなら、販売者は承認を求め、即時予約を強制すれば離れていきます。
3. モデルを供給側の成熟度に合わせる。 初期、販売者を一人ずつ口説いている段階では、ゲストを承認できる柔軟性が、そもそも出品してもらう決め手になることがあります。供給が増えるにつれて、デフォルトを即時に寄せることが、コンバージョンに役立つかもしれません。販売者を迎え入れる方法は、出品者オンボーディングのリファレンスで扱っています。
4. デフォルトに働かせる。 販売者が設定を変えることはほとんどありません。デフォルトが即時かリクエストかが、マーケットプレイス全体を形づくります。Turoの発表が、Book Instantlyを提供することではなく標準にすることについてだったのは、そのためです。
5. 選択を検索に表示する。 Airbnbでは、ゲストが即時予約の出品だけを表示するようにフィルターできます（Airbnb Help Center、記事85）。プラットフォームが即時予約の出品をより上位に表示するか、どのように表示するかは、公には文書化されていないことが多いため、前提にしないでください。私たちが確認したランキングの論文は、承認の予測を説明していて、即時の出品へのブーストは説明していません。検索とマッチングが取引モードをどう使うかは、自社のデータでテストする価値があります。

よくある間違い

• モデルを純粋なスピードの問題として扱う。 スピードは重要ですが、本当の判断はコントロールとリスクのトレードオフです。
• ミスマッチがどこへ行くかを忘れる。 辞退が減れば、キャンセルが増えることがあります。両方を測定してください。
• 期限を設けずにリクエストを放置する。 リクエスト型のモデルには、Airbnbの24時間という文言が示すように、期限と、購入者を解放するルールが必要です。
• 監査なしに販売者へ裁量を与える。 エーデルマン、ルカ、スヴィルスキーの実験は、承認の権限が、プラットフォームが認めないような使われ方をしうることを思い出させてくれます。
• 別のカテゴリーのルールをそのまま真似る。 標準化されたレンタルでうまくいくことが、カスタムのサービスでは失敗することがあります。