レンタカーのサイトコントローラーとは
「さっきの予約、ほかのサイトも閉じたっけ」──販売サイトを増やしていくと、この確認が1日に何度も挟まるようになります。直し忘れれば二重予約になり、怖くなって在庫を絞れば売り逃す。この記事は、その板挟みを構造として説明し、サイトコントローラーという仕組みが何をするものなのかを整理します。
- レンタカーのサイトコントローラーとは何か（定義）
- なぜサイト同士を直接つながないのか
- 手作業だと、1件の予約で何回の修正が発生しますか？
- レンタカー特有の在庫の決まり方
- 導入するとき、いまの在庫は壊れませんか？
- よくある質問
レンタカーのサイトコントローラーとは何ですか？
複数の販売サイトに分かれているレンタカーの在庫を、ひとつの台帳にまとめて管理し、予約が入った分だけ他サイトの在庫を閉じる仕組みです。各サイトから予約を読み取って台帳を更新し、更新後の在庫数をサイトへ送り返します。宿泊のサイトコントローラーと目的は同じですが、レンタカーは「返却日の扱い」と「車種グループの重なり」で在庫の数え方が変わるため、計算の仕方が異なります。
言い換えると、正しい数字を置く場所を1か所に決めるための道具です。いまはその場所が決まっていません。楽天にも、じゃらんにも、自社サイトにも数字があり、どれも少しずつ違う。どれが正しいのか分からなくなるのは、正解を置く場所を決めていないからです。
自社サイトの予約をレンタリザーブ（onlineReserve のレンタカー予約システム）で受けている場合は、接続の設定をすると、その予約も同じ台帳に入ります。
なぜ販売サイト同士を直接つながないのですか？
サイト同士を直接つなぐと、保たなければならない組み合わせの数がサイト数の二乗に近い速さで増えるからです。4サイトなら6通り、7サイトなら21通り。中央に台帳をひとつ置き、各サイトがそこを見に来る構造にすれば、接続の数はサイトの数と同じだけで済みます。
× 直接つなぐ
接続数 ＝ n(n−1)/2
○ 中央台帳
接続数 ＝ n
この数え方は、サイトコントローラーの解説でも同じように語られています。ある解説記事では「5つのOTAを接続している場合、在庫更新の組み合わせは20通り」と説明されています。数え方の流儀は違っても、サイトが増えると管理すべき関係が急に増えるという事実は共通です。
手作業だと、1件の予約で何回の修正が発生しますか？
予約が1件入るたびに、修正すべき先は「サイト数−1」だけ発生します。4サイトなら3回、7サイトなら6回。これに1日の予約件数を掛けた数が、毎日の手作業です。1回でも抜ければ、そのサイトだけ在庫が残り、二重予約になります。
手が回らなくなるのは、担当者の集中力が足りないからではありません。直す先が、扱うサイトの数だけ毎回ついてくるからです。これは注意力の問題ではなく、構造の問題です。
実際にこの作業に追われていた事業者の言葉が、業界の導入事例に残っています。
「販売先を行き来し一つ一つ在庫の開け閉めを行う必要があるため、作業自体の手間が膨大」「時にはたった2人で全体の予約管理を見なければならないこともあり負担がかなり大きく」
出典：メトロエンジン株式会社「メトロコンダクター」導入事例（株式会社ビッグビジネス／奄美ラッキレンタカー、販売チャネル7サイト）https://metroengines.jp/archives/3226（2023年12月22日公開・2026年9月12日確認）。※当社の事例ではありません。台帳にまとめると、何が変わりますか？
手作業が消えることよりも、見る場所がひとつになることのほうが効きます。
| 場面 | 台帳が無いとき | 台帳があるとき |
|---|---|---|
| 予約が入る | 残りのサイトを1つずつ開いて直す | 台帳が受け取り、台帳が閉じる |
| 数字が食い違う | どれが正しいか分からない | 台帳が正解。差が出た日と商品を記録して通知する |
| サイトを増やす | 覚える画面と作業が増える | 日々見るのは台帳ひとつのまま |
| 担当者が休む | その人しか手順を知らない | 同じ画面を誰でも見られる |
販売サイトを増やすときの負担は、送客の見込みよりも、見る場所と直す場所が増えることにあります。増やしても見る場所が変わらないなら、その負担は小さくなります。
レンタカーの在庫は、宿泊と何が違いますか？
同じ1台でも、返ってくる時刻によって、その日にもう一度貸せるかどうかが変わります。さらに同じ車両が複数の車種クラスで売られていることがあり、片方の残数だけを見て売り切ると在庫が破綻します。この2つがレンタカー固有の条件です。
そのためレンタコネクトが販売サイトへ送る在庫数は、「車両の残り」と「その車が入っている車種グループの残り」の小さいほうとしています。マイナスにはしません。在庫は日単位で数え、返却日を貸出中として数えるか（既定）、返却日も販売するかを事業者が選びます。返却の時刻は在庫の計算に使いません。また返却日が取れない予約は在庫の計算に入れず、「要確認」として画面に残します。推測で埋めると、それ以降の在庫計算が全部ずれるからです。
この2つの条件をどう扱うかは、宿泊用のサイトコントローラーとの違いで詳しく書いています。
導入するとき、いまの在庫は壊れませんか？
レンタコネクトの場合、導入初日から自動同期は始めません。接続直後は観測モードで、販売サイトの数字を読み取って台帳と突き合わせ、差分を表示するだけです。台帳の取り込みと在庫の照合を済ませ、事業者が販売サイトごとに送信を有効にして、はじめて同期が始まります。開始の前に、サイトの値がどれだけ変わるかを画面で確かめられます。一括での開始は行いません。
連携ツールを入れるときの一番の不安は「初日にいまの在庫を書き換えられること」です。触る前に合わせる、という順序を守れば、その不安は無くなります。
また、レンタコネクトの画面で手動調整した日の値は、送信で上書きしません。送信を有効にした商品では、販売サイトで直接変えた数はレンタコネクトの値に戻ります。差が出たときにどちらへ合わせるか（台帳の数字を販売サイトへ反映するか、販売サイトの数字を採用するか）は、事業者が選びます。
レンタコネクトが行わないこと
- 販売サイト同士を直接つなぐこと（中央の台帳と各サイトをつなぎます）
- 販売サイトの予約の作成・変更・取消
- 返却の時刻を見て、同じ日の中で在庫を開け閉めすること
- 導入初日からの自動送信（送信はサイトごとに事業者が有効にします）
- 料金・価格の同期と自動変更
初期費用0円、月額10,000円（税別）から。基本料に、連携する販売サイト数と2店舗目からの店舗数を加えて決まります。車両台数・予約件数では変わりません。最低契約期間はありません。料金・価格の同期および自動変更は行いません。
レンタコネクトを見る →よくある質問
あります。2サイトでも予約1件につき1回の修正が発生し、その1回を忘れれば二重予約になります。ただし手作業で回っているなら急ぐ必要はありません。3サイト以上、あるいは繁忙期に在庫を絞っているなら検討時期です。
ありません。いまお使いのアカウントにレンタコネクトが接続します。販売サイト側の契約や画面はそのままです。
必要ありません。一般的なWebブラウザだけで動きます。車載機器の設置もありません。
いいえ。料金・価格の同期および自動変更は行いません。AIによる価格提案も行いません。価格の誤反映はその瞬間から売上に直結するため、まず在庫が正しいことを先に置いています。
最低契約期間はありません。停止すると同期は止まり、販売サイトに送った値はその時点の数字で残ります。勝手に書き戻すことはありません。
出典
- メトロエンジン株式会社「メトロコンダクター」導入事例（2023年12月22日公開） https://metroengines.jp/archives/3226（2026年9月12日確認）
- ビジネスブレーン「サイトコントローラーの在庫同期ズレ対策｜ダブルブッキングを防ぐ運用チェックリスト」 https://miyako.com/aio/articles/site-controller-sync-error/（2026年9月12日確認）
- 送る在庫数の決め方、在庫を日単位で数えることと返却日の扱いの設定、返却日の分からない予約の扱い、観測モードと事業者によるサイトごとの送信開始、手動調整の扱いは、当社のレンタコネクトの実装にもとづく記述です（2026年9月12日時点）。