「OTAをやめて自社予約へ移す」か「OTAを使い続ける」か。併用の話は、たいていこの二択として出てきます。ところが両方を同時に動かすと決めた時点で、残る問いは別のものに変わります。部屋は1つしかないのに、売る窓口が2つ以上になるという状態を、どう設計するかです。窓口は増やせます。増えないのは、売れる在庫と、年間に人を宿泊させられる日数です。
この記事は、OTA(宿泊予約サイト)と自社予約を併用するときに先に決める3点を、一次情報で確かめられる範囲だけで整理します。1つめが在庫の割り方、2つめが同期の時間差をどこで吸収するか、3つめが記録の集約先です。手数料の水準や、自社予約が予約全体の何割になるかといった数値は書いていません。公的に確認できる集計を見つけられなかったためで、「併用したほうが得か」を数字で答える記事ではありません。
扱わないことも先に挙げます。宿泊者の募集を委託できる相手の制限はOTAとは何か、使っているOTAが届出事項に関係するかはOTA依存を減らす方法、自社サイトを安くできるかどうかは最低価格保証を掲げる前にで扱っています。各社を横に並べた比較は民泊のOTA比較です。ここでは重ねず、両方を同時に回すときの在庫の設計だけに絞ります。
窓口は増やせても、売れる在庫は増えません
併用を考える動機は、たいてい「予約を増やしたい」です。ところが住宅宿泊事業の側から見ると、増やせる余地には天井があります。観光庁は「住宅宿泊事業」を、旅館業法第3条の2第1項に規定する営業者以外の者が宿泊料を受けて届出住宅に人を宿泊させる事業であって、人を宿泊させる日数が180日を超えないもの、と説明しています。年間の上限は180日で、届出住宅ごとに算定されます。
期間の区切りも決まっています。計算期間は毎年4月1日正午から翌年4月1日正午までとされ、1日の計算は正午から翌日の正午までという基準で行われます。ここで確かめておきたいのは、この数え方に予約経路という要素が入っていないことです。Airbnb経由で埋めた日も、別の仲介サイト経由で埋めた日も、自社サイトや電話で受けた日も、同じ1つの枠を使います。
つまり窓口を増やす行為は、枠を広げる行為ではありません。同じ枠をどの窓口で売るかを選び直す行為です。これが分かると、併用の目的が「予約の総数を増やす」から「同じ日数をどこで売るか」へ変わります。日数の数え方そのもので迷いやすい場面は民泊の180日ルールに分けて書きました。
枠が1本であることは、在庫の割り方にも効いてきます。片方の窓口に全在庫を出せば、もう片方に出す在庫は同じ日付を二重に売っている状態になります。二重に売った日が実際に両方で埋まれば、どちらかを断ることになります。ここから先は、その二重を許すのか、最初から分けるのかという設計の話です。
在庫の割り方は、3つの型に分かれます
併用の形は細かく見れば無数にありますが、在庫の扱いで整理すると3つに収まります。全在庫を全窓口へ出す型、窓口ごとに在庫を分ける型、期間で分ける型です。どれが有利かを示す公表データは確認できていませんので、ここでは起きうることと、先に読む条件だけを並べます。
型1は、同じ部屋を全部の窓口へ出し、どこかで売れたら他を閉じる形です。空室は残りにくい一方、閉じるまでの間に同じ日が別の窓口でも売れる余地が残ります。この余地の大きさは、次の節で見る同期の間隔で決まります。
型2は、窓口ごとに在庫を分ける形です。複数の部屋があるなら部屋の単位で、1部屋なら曜日や日付の単位で分けます。窓口をまたがないので、同期の遅れによる重複は起きません。代わりに、片方が埋まってもう片方が空いたままという日が出ます。ここで先に読むのは契約です。掲載する宿泊料金や部屋数を他の販売経路と同等にする条件が置かれている場合があり、自社の側へ在庫を残す余地がその分だけ狭くなります。条件の読み方は最低価格保証の記事に分けました。
型3は、期間で分ける形です。先の日付は仲介サイト、直前は自社、といった区切りを置きます。区切りの前後では両方に出る日が残るため、重複の余地が完全に消えるわけではありません。ここで先に確かめるのは、自分の側で同期を止められるかです。止められない仕組みなら、区切りは手で閉じる作業として残り続けます。
複数の届出住宅を持っている場合、割り方の選択肢はもう1段増えます。物件ごとに型を変えられるためです。ただし数える単位が届出住宅ごとと事業者ごとで分かれるため、管理の単位を先に決めておく必要があります(民泊の複数物件管理)。
同期は即時ではありません
型1と型3を選ぶなら、同期の条件が併用の設計そのものになります。ここは公表されている条件を読める部分です。Airbnbはヘルプセンターで、Airbnbのカレンダーは3時間ごとに自動更新され、連携しているほかのカレンダーから情報を取り込むと説明しています。取り込みは予約が入った瞬間ではなく、次の自動更新の時点です。
この1行から、重複予約が起きる場所が1か所に絞れます。自社サイトで予約が入って自社側のカレンダーが埋まってから、それがAirbnb側へ取り込まれるまでの間です。その間、Airbnbの画面ではその日付が空室のまま残ります。逆の向き、つまりAirbnbで入った予約が自社側へ伝わるまでの間隔は、自社側で使っている仕組みの取り込み条件で決まるため、このヘルプには書かれていません。
同じヘルプには同期の制限も書かれています。インポートされるデータの対象期間は最長2年、インポートしたカレンダーの同期を一時停止することはできない、外部サイトからの更新リクエストには回数制限があり超えると次の自動更新まで待つ、という3点です。表にすると、併用の運用で何を前提にするかが見えます。
| 読む項目 | Airbnbのヘルプに書かれている内容 |
|---|---|
| 自動更新の間隔 | カレンダーは3時間ごとに自動更新され、連携しているほかのカレンダーから情報を取り込む |
| 同期される情報 | 予約状況、ホストがブロックした日付、準備期間、予約締切日 |
| インポートの対象期間 | 最長2年 |
| 同期の一時停止 | インポートしたカレンダーの同期を一時停止することはできない |
| 手動での取り込み | 外部サイトからの更新リクエストには回数制限があり、超えると次の自動更新まで待つ |
3行目と4行目は、型3を選ぶときに効きます。2年より先の日付は連携の外にあり、連携を一度つないだら、その同期だけを止めて手で管理する運用には切り替えられません。「あとで止めればいい」が使えない前提で区切りを決めることになります。
同じ建物の中で貸し方を変えている場合は、1社の中でも同じ問題が起きます。Airbnbは、まるまる貸切と個室を同時に出している場合について、まるまる貸切の予約リクエストを承認すると対象の日付が個室のカレンダーでもブロックされるようになると説明しています。あわせて、ほかのウェブサイトでも宿泊施設をホスティングしている場合は、すべてのホスティングカレンダーを連携することで複数のゲストが同じ日に予約するのを防ぐことができる、とも書かれています。連携していない窓口が1つあるだけで、この仕組みは効きません。
準備期間が同期の対象に入っている点も、見落としやすい項目です。入れ替えの作業時間を見込んで日付を閉じている場合、その閉じた日付も相手側へ渡ります。自社側に同じ考え方の設定が無いと、片方の窓口だけ連泊の間隔が詰まった状態になります。
記録は分かれても、報告先は1つです
併用すると、宿泊者の記録の出どころが窓口の数だけ分かれます。一方で、知事へ出す定期報告は届出住宅ごとに1つです。観光庁の民泊制度運営システムの案内では、定期報告は2ヶ月毎に報告が必要とされ、報告項目として届出番号、報告対象期間、宿泊日数、宿泊者数、延べ人数、国籍別宿泊者数、宿泊日が挙げられています。国籍の区分は、日本を含む21の国・地域と「その他」です。
この一覧に予約経路の欄はありません。窓口ごとに分けて報告する形ではないので、併用している場合は報告の前にどこかで1つへまとめる必要があります。まとめる場所を決めずに運用を始めると、報告の時期が来るたびに手作業で突き合わせることになります。
| 報告項目 | 併用したときの値の出どころ |
|---|---|
| 届出番号 | 届出のもの。窓口では分かれません |
| 報告対象期間 | 制度の側で決まる期間。窓口では分かれません |
| 宿泊日数 | 窓口ごとに分かれる。同じ日を二重に数えない形でまとめる |
| 宿泊者数 | 窓口ごとに分かれる |
| 延べ人数 | 窓口ごとに分かれる |
| 国籍別宿泊者数 | 窓口ごとに分かれる。自社の受付で国籍を受けていないと埋まりません |
| 宿泊日 | 窓口ごとに分かれる |
国籍別の行だけ、集め方の問題が追加で出ます。仲介サイト経由では管理画面に残っていても、自社の受付では受け取る項目を自分で決めるためです。観光庁は同じ案内の中で、住宅宿泊事業者向けのソフトウェアとして電子宿泊者名簿を配布しており、宿泊者情報と定期報告データを作成できるとしています。名簿に記録する項目としては、宿泊開始日時、終了日時、宿泊日数、宿泊者氏名、住所、職業、国籍、旅券番号などが挙げられています。対応OSはWindows 10/11(64bit)とされています。
名簿そのものの義務は、経路の数に関係なく事業者にかかります。併用で増えるのは義務ではなく、同じ台帳へ2系統から書き込む手間です。記載項目と保存のしかたは民泊の宿泊者名簿、自社の受付で受ける項目の決め方は民泊の予約フォームの項目にあります。報告の時期と対象期間の並びはAgodaに民泊を掲載するで暦の形にしてあります。
併用を始める前に確かめる順序
ここまでを順番に直すと、自社サイトを作る作業は後ろのほうに来ます。先に決まっていないと、作ってから在庫を割り当てられないためです。
1つめは、在庫の割り方の型を決めることです。3つのどれにするかで、次に読む資料が変わります。2つめは、使っている窓口それぞれの同期の条件を、管理画面と公式ヘルプで確認することです。間隔、対象期間、止められるかどうかの3点です。3つめは、契約に価格と部屋数の条件が置かれているかを読むことです。型2と型3は、ここで余地が無いと分かった時点で選べなくなります。4つめが、名簿と報告の集約先を決めること。5つめが、自社の受付の作り込みです。
順番を入れ替えて困るのは、3つめを後ろへ回したときです。自社専用の在庫を前提に受付を作ってから契約の条件に気づくと、作った受付の設計から戻すことになります。なお、宿泊者の募集を他人に委託する場合の相手は、住宅宿泊仲介業者または旅行業法上の登録を受けた旅行業者に限られます。併用の設計は、その制限を満たした窓口の中で考えるものです。自社予約そのものの位置づけは自社予約とは何かにまとめてあります。
この記事で確認できなかったこと
併用している事業者の割合、経路ごとの予約の構成比、重複予約がどの程度の頻度で起きるかについて、公的に確認できる集計を見つけられませんでした。そのため、この記事には割合と頻度を書いていません。
同期の条件についても、確認できたのはAirbnbが公表している内容だけです。Booking.comのパートナー向けヘルプにあるカレンダー同期の説明は、2026-10-05に取得を試みたところ、サーバーから拒否の応答が返って読めませんでした。読めないものを他社の条件として書くことはできないため、この記事で挙げた同期の間隔はAirbnbの自動更新のものに限られます。ほかの窓口の間隔は、それぞれの管理画面と公式ヘルプで確認してください。
在庫の割り方の3つの型は、公表資料から導いた分類ではなく、在庫の扱いで整理した枠組みです。どの型が売上や稼働にどう効くかを示す公表データは確認できていません。自分の物件で決めるときは、契約書に置かれた条件と、各窓口の同期の条件という確かめられる2点から絞り込んでください。
このメディアの運営元について
myHotelsメディアは、民泊予約システムを提供する myHotels が運営しています。 記事は自社サービスの利用を前提にせずに書いており、料金や条件は下のページで確認できます。