複数サイトで在庫がズレるのはなぜか
サイトごとに数字が違う。どれが正しいのか分からない。この状態が続くと、人は自分を責めます。もっと注意していれば、もっと早く直していれば、と。でも、扱う販売サイトが3つを超えたあたりから、それは個人の努力でどうにかなる量ではなくなります。
- 1件の予約で、何回の修正が発生するのか
- 在庫がズレる5つの原因
- なぜ「どれが正しいか」が決まらないのですか？
- 二重予約には原因が2種類ある
- 構造で防ぐとは何をすることか
- よくある質問
複数の販売サイトで在庫がズレるのはなぜですか？
予約が1件入るたびに、直す先が「サイト数から1を引いた数」だけ発生するからです。4サイトなら3回、7サイトなら6回。これに1日の予約件数を掛けた数が、毎日の手作業です。1回でも抜ければ、そのサイトだけ在庫が残って二重予約になります。
1日10件の予約が入る事業者が7サイトを扱っていれば、1日60回の修正です。1件あたり30秒で終わったとしても30分。実際には管理画面を開いて、日付を探して、数字を直して、保存する。そんなに速くは終わりません。
この作業をしていた事業者の言葉が、業界の導入事例に残っています。
「販売先を行き来し一つ一つ在庫の開け閉めを行う必要があるため、作業自体の手間が膨大」「時にはたった2人で全体の予約管理を見なければならないこともあり負担がかなり大きく」
出典：メトロエンジン株式会社「メトロコンダクター」導入事例（株式会社ビッグビジネス／奄美ラッキレンタカー、販売チャネル7サイト）https://metroengines.jp/archives/3226（2023年12月22日公開・2026年9月12日確認）。※当社の事例ではありません。手が回らなくなるのは、担当者の集中力が足りないからではありません。直す先が、扱うサイトの数だけ毎回ついてくるからです。これは注意力の問題ではなく、構造の問題です。
在庫がズレる5つの原因
実務で起きるズレの代表的な原因は、次の5つです。①手作業の直し忘れ ②商品の紐付け漏れ ③電話予約・ウォークインの反映漏れ ④キャンセルの戻し忘れ ⑤販売サイト側の仕様変更への対応遅れ。このうち②と④は、気づくのが特に遅れます。
| 原因 | 何が起きるか | 気づきやすさ |
|---|---|---|
| ①直し忘れ | 1サイトだけ在庫が残り、そこから予約が入る | 二重予約が出て初めて分かる |
| ②紐付け漏れ | 販売サイトに商品を足したが連携側で結んでおらず、予約が入っても在庫が減らない | 🔴 連携しているのに減らないので、非常に気づきにくい |
| ③電話・ウォークイン | その場で貸したが、どのサイトの在庫も閉じていない | 忙しい日ほど漏れる |
| ④キャンセルの戻し忘れ | 空いているのに売っていない＝静かな機会損失 | 🔴 事故にならないので、誰も気づかない |
| ⑤仕様変更 | サイト側の画面や項目が変わり、取り込みが崩れる | ある日から急にズレ始める |
②の紐付け漏れは、宿泊業では「野良プラン」と呼ばれて古くから知られています。新しいプランを販売サイトに足したのに連携側で結んでいないと、そのプランから予約が入っても在庫が減りません。連携を入れているという安心感があるぶん、発見が遅れます。
④のキャンセル戻し忘れは、事故を起こさないので放置されがちです。しかし在庫としては「空いているのに売れない」状態で、売上に直接効いています。二重予約より静かで、二重予約より長く続きます。
なぜ「どれが正しいか」が決まらないのですか？
正解を置く場所を決めていないからです。楽天にも、じゃらんにも、自社サイトにも数字があり、どれも少しずつ違う。サイト同士を比べている限り、多数決以上の決め方がありません。台帳をひとつ用意して「これが正解」と決めれば、比べる相手は常に1つになります。
サイトの数が増えると、比べるべき組み合わせは急速に増えます。4サイトなら6通り、7サイトなら21通り。サイトコントローラーの解説記事でも「5つのOTAを接続している場合、在庫更新の組み合わせは20通り」と語られています。数え方の流儀は違っても、関係の数が人の手に負えなくなるという点は共通です。
× 直接つなぐ
接続数 ＝ n(n−1)/2
○ 中央台帳
接続数 ＝ n
二重予約の原因は、何種類ありますか？
ひとつは予約情報を書き写す過程のミス、もうひとつは在庫が他のサイトで開いたまま残ることです。前者は予約の取り込みを自動化することで、後者は在庫の連動によって防ぎます。どちらか片方だけを直しても、二重予約は残ります。
| 原因A：転記ミス | 原因B：在庫が閉じない | |
|---|---|---|
| 起きる場所 | 予約メールを読んで台帳に書き写すとき | 予約を受けたあと、他サイトを直すとき |
| データの向き | 販売サイト → 自社（受け取り） | 自社 → 販売サイト（送り返し） |
| 対処 | 予約の取り込みを自動化する | 在庫を連動させる |
| 関連記事 | 転記ミスを根本からなくす | この記事 |
予約の取り込み側は、レンタゲートの記事で扱っています。この記事は在庫を返す側の話です。どちらも同じ「ダブルブッキング」という言葉で語られますが、直す場所が違います。
構造で防ぐとは、何をすることですか？
結局のところ、やることは3つです。
-
正解を置く場所を1か所に決める
台帳をひとつ用意し、各サイトはそこを見に来る構造にします。比べる相手が常に1つになるので「どれが正しいか」の議論が消えます。
-
予約が入ったら、他サイトを自動で閉じる
人が覚えている必要をなくします。サイト数が増えても、日々見る画面はひとつのままです。
-
それでも出たズレを、解消するまで残す
通知は流れて消えますが、差は消さずに残します。解消されるまで画面に出続ければ、忘れることができません。
3つ目が抜けている仕組みは、意外と多くあります。自動化は失敗することがあるので、失敗したときに気づける形まで含めて設計する必要があります。
レンタコネクトが行わないこと
- 紐付けていない商品の予約で、車両の在庫を減らすこと（商品と車両を結ぶと在庫連動の対象になります）
- 販売サイトの予約の作成・変更・取消
- 導入直後の自動送信（送信はサイトごとに事業者が有効にします）
- 料金・価格の同期と自動変更
レンタコネクトは台帳の数字と販売サイトの数字がズレたら、その日・その商品を特定して記録し、画面で通知します。解消されるまで残り続けます。初期費用0円、月額10,000円（税別）から。導入直後は観測モードで書き込みません。台帳の取り込みと在庫の照合を済ませ、事業者がサイトごとに送信を有効にしてから書き込みます。
レンタコネクトを見る →よくある質問
起きます。2サイトでも予約1件につき1回の修正が必要で、その1回を忘れれば二重予約になります。ただし件数が少ないうちは手作業で回ります。3サイトを超えたあたりから急に苦しくなります。
販売サイト側の商品一覧と、台帳側の車両一覧を並べて、対応が付いていない商品が無いかを確認します。定期的な確認が必要です。
台帳の在庫数とサイトの在庫数を突き合わせれば差として出ます。事故にならないので自分では気づけません。差を検出する仕組みが要ります。
防げますが、絞った分だけ売れなくなります。安全のために意図的に絞った結果が機会損失になることがあります。安全在庫の決め方で詳しく書いています。
出典
- メトロエンジン株式会社「メトロコンダクター」導入事例（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日時点）。