よくあるご質問

複数の予約サイトに車を出していると、「1社で売れたのに、他のサイトではまだ空いている」という状態が起こります。放置すると、実際には貸せない車の予約を受けてしまいます。

レンタコネクトは、この調整を無人で行います。

1. 保有台数と予約状況から、日付ごとの空き台数を計算する
2. 計算した台数を、各予約サイトへ自動で反映する
3. 各予約サイトで入った予約を回収して台帳に取り込む
4. 台帳とサイトの台数が食い違ったら、検出して画面に出す

日常的な操作は前提としていません。事業者さまが行うのは、導入時の設定、状態の確認、そして食い違いが起きたときの判断です。

このほかに、回収した予約データを使った売上の分析と、他社料金の相場表示を備えています（L章・M章）。

違います。予約を受け付けるのは各予約サイトや自社サイトの役目で、レンタコネクトはその役目を持ちません。

レンタコネクトが行うのは、各予約サイトに出す「残り台数」をそろえることです。予約そのものを作ったり、変更したり、取り消したりはしません。

なお、サイトコントローラには料金も同期する製品がありますが、本製品は料金を同期しません（L章）。

主要な予約サイトに順次対応しており、対応サイトは今後も増やしていきます。

これまでのところ、接続できなかった予約サイトはありません。 新しい予約サイトを追加する場合は、そのサイト専用の接続を個別に開発して対応します。

そのサイト向けの接続を個別に開発して追加します。ご相談ください。

未対応のサイトがある状態でも、対応済みのサイトだけで運用を始めることはできます。ただしその場合、未対応サイトの予約はレンタコネクトの台帳に入らないため、その分は事業者さまの側で台数を見ていただく必要があります。

役割が分かれています。

3つとも必須ではありません。レンタコネクトは、すでに複数の予約サイトに出稿している事業者さまが対象です。

ありません。レンタコネクトは各予約サイトの管理画面に接続して在庫を書き換える方式のため、いまの予約の受け方を変えずに導入できます。

サイトごとに手作業で台数を直す必要がなくなること、そして過剰販売のリスクが下がることです。

台数と拠点が増えるほど手作業は追いつかなくなりますが、レンタコネクトは台数が増えても手間が変わりません。

サーバなどの設備をご用意いただく必要はありません。

8つの手順で進みます。

各手順が終わったかどうかは自己申告ではなく、実際のデータから判定します。 順番に進み、途中で戻ることもできます。

期間は、連携するサイト数・車両数・営業所数によって変わります。⑦のテスト期間をどれだけ取るかは事業者さまのご判断です。

ログイン情報は暗号化して保管します（AES-256-GCM）。管理画面および各予約サイトとの通信はHTTPSで暗号化されます。

管理画面は既存のレンタカー管理システムのアカウントをそのまま使い、事業者ごとに見える範囲を限定しています。

設計上、そうなっています。 手順⑧「運用開始」に達するまで、自動的な書き込みは行いません。 読み取りと表示だけを行います。

計算した台数が実態と合っていることを確認してから書き込みを始める設計です。問題が起きた場合も、書き込みを止めれば⑦の状態に戻せます。

ひとつだけ例外があります。 台帳が売り切れなのにサイトがまだ販売中、という食い違いを画面が検出したとき、その場で売り止め（0にする）ボタンが表示されます。これは事業者さまが押したときだけ動く操作で、運用開始前でも実行できます。下げる方向のみで、台数を増やすことはありません。

自社の車両と、予約サイト側の商品を結び付ける設定です。

サイト側の商品名は各サイトで異なります（同じ車でもサイトごとに呼び方が違います）。どの商品がどの車を指すのかは機械には判断できないため、人が対応付けます。

候補は画面が提示しますが、確定は事業者さまが行います。 自動で確定はしません。

その商品には特定の1台の台数を書き込む相手がいないため、監視と表示のみになります。台数の書き込みは行いません。

自社の1台とサイトの1商品を1対1で対応付けられれば、同じサイトが書き込みの対象になります（J章）。

導入をご支援するため、一定期間を無料の試用期間として設定できます。期間は担当者がご相談のうえ設定します。

空き台数 ＝ その日の基準台数 － その日を使っている予約の数

基準台数は、保有台数から稼働できない分を引いた値です。

既定では、貸出日から返却日までの各日で在庫を使っている扱いです。返却日も1台と数えるため、「返却日に同じ車を別のお客さまへ貸してしまう」重複は起きません。

当日中に次へ貸し出す運用の事業者さま向けに、返却日を在庫から除外する設定をご用意しています。会社単位の設定で、有効にするとその日が販売可能になります。

なお、設定を読み取れない場合は「返却日を含む」側で動きます。 安全側に倒す設計です。

基準台数を決めるのはレンタコネクトの画面です。 サイト側で台数を変更しても、それが基準台数として取り込まれることはありません。

導入時の取り込みでも台数は上書きされません。サイトから取り込むのは商品・営業所・車両名の一覧までで、保有台数は事業者さまが入力した値を正とします。

サイト側の台数と食い違った場合は「要注意」として提示し、どちらを正とするかを人が選びます（G章）。

日付ごとの台数調整をご用意しています。「この日は車検で1台減る」といった指定ができ、レンタコネクトの画面が正式な入力場所です。

余裕として意図的に売らずに残す台数のことです。レンタコネクトには、サイトへ送る台数から安全在庫を引く設定はありません（2026年8月に廃止しました）。

サイトへ送る台数 ＝ 車両の空きと、その車両が入っているクラスの空きのうち少ない方（0未満にはしない）

残したい台数は、その日の基準台数を下げて表します（Q18の日付ごとの台数調整）。基準は在庫を送る各サイトに同じ値で効くため、台帳とサイトの台数がずれません。

下げた分は売れ残りではなく意図的に売らない在庫で、販売機会の減少でもあります。保有1〜2台の車種は1台下げるだけで売れる数が大きく減るため、必要な日だけ下げてください。

保存した値と実際の予約状況がずれるのを避けるためです。

保存すると、予約が入ったのに保存値が古いまま、という状態が起こり得ます。毎回計算し直せば、その食い違いは原理的に発生しません。

どのサイトで売れても、その1台分が各サイトから減ります。 これが本製品の中心的な役割です。

計算では、車両単位で見た空きと、その車両が属するグループ全体で見た空きの少ないほうを採ります。どちらの見方でも売り越さないためです。

見ている単位が違うためです。 両方を並べて表示しています。

• 個別車両の数 … その車が物理的に何台空いているか
• クラスの数 … そのクラス全体として、あと何台売れるか

クラス全体が埋まっていれば、個別車両に空きがあってもそのクラスでは売れません。そのため「個別は1、クラスは0」という表示が起こります。どちらも正しく、実際に売れるのは少ないほうの数です。

予約通知メールを受け取ると、その時点ですぐに該当サイトへ問い合わせて内容を確認し、台帳に取り込んで他サイトへ反映します。

メールが届かなかった場合も定期処理で回収しますが、その分だけ反映は遅くなります（Q34）。

約5分間隔です（実測：直近の処理間隔の中央値300秒）。

通常は軽い処理だけを行い、前回の網羅的な読み直しから24時間が経つと、自動的に重い処理へ切り替わります。網羅的な読み直しは1日1回です（実測：直近7日間、いずれも1日1回）。

在庫を各サイトへ反映するのは、既定で本日から 92 日先までです。販売サイトが受け付ける日付の範囲がそれより長いサイトには、予約を取り込んだ日付までその範囲で反映します。

予約の回収・照合は 1 年先までを対象にしていますので、92 日より先の予約が取りこぼされることはありません。

ホーム画面から、その場で反映を指示できます。定期処理を待つ必要はありません。

外部サイトへの不要なアクセスを増やさないためです。

前回サイトで確認した値と変わらない期間は書き込みを行いません。書き込む必要がないうえ、アクセスが増えると相手サイトへの負荷にもなります。

本製品が同期している範囲では、起きないように設計しています。 ただし「起きない」と言い切ることはできません。次のような場合は防げません。

• レンタコネクトが連携していない販売経路で予約を受けた場合
• 予約サイト側で、事業者さまが直接台数を増やした場合
• 予約サイトへの接続が途絶えている間に、そのサイトで予約が入った場合

3つ目については、接続が途絶えているサイトがある間は台数を増やす反映を止めるという対策を持っています（Q31）。

台数を減らす方向は安全側なので、無条件で反映します。売り越しにはなりません。

台数を増やす方向は危険です。実際には売れている日を再び販売してしまう可能性があるため、条件が整っている場合にのみ反映します。

次の条件がそろっている場合にのみ、増やす反映を行います。

• 予約サイトに接続できていること
• 対応付けが済んでいること
• 営業所が確定していること
• 予約・在庫を一度は取得していること
• 台帳とサイトの照合が済んでいること
• 事業者さまが送信を開始していること

整っていない場合は反映を保留し、何が足りないのかを画面に表示します。

接続できていない、または連携を停止しているサイトの予約が、台帳に届いていない可能性があるためです。連携を停止すると、そのサイトの予約は台帳に取り込まれません。販売をやめたサイトは、停止ではなく接続を解除すると、この制限はかかりません。

その状態で「空いている」とみなして他サイトに出すと、実際には売れている日を再び販売することになります。接続状態そのものを確認できない場合も同じく止めます。「わからない」を「問題なし」として扱わないためです。

なお、減らす反映は続きます。 止まるのは増やす方向だけです。

事業者さまが行った台数調整は、本製品が勝手に上書きしません。

ただし、サイト側の在庫数そのものについては、次の定期反映で計算結果が書き込まれます。サイト側で恒久的に変えたい場合は、レンタコネクトの画面で基準台数または日付ごとの調整として入力してください（Q17・Q18）。

食い違いが出た場合は「要注意」として提示し、どちらを正とするかは人が選びます（G章）。

行いません。 本製品が扱うのは日付単位の台数です。

時刻を伴う貸出可否の判断は、予約を受け付ける側（各予約サイト・自社サイト）が行います。

1日1回の網羅的な読み直しで回収します。 反映までに最大24時間かかります。

ただし、そのサイトの読み取り自体が失敗し続けている場合は、回収できません。 読み取りの失敗は画面に状態として表示されますので、続くようであればご連絡ください。

即時反映が必要な場合は、予約通知メールが専用アドレスへ届くよう転送設定をお願いしています（Q8）。

変更として取り込み、台帳の予約を新しい期間に更新します。

空き台数は毎回計算し直すため、元の期間はそのまま空きに戻ります。 手作業で戻す必要はありません。

取り消しのお知らせが届いた場合は、その時点で反映します。お待たせしません。

一方、お知らせが無いまま予約サイトの一覧から消えたときだけは、1 回目では取り消しにせず印を付けて保持し、次の確認でも現れない場合に取り消しとして確定します。通信の不調で実在する予約を消してしまうと、その車が空いて見えて過剰販売につながるためです。

消えません。 破棄せず「要確認」として画面に残ります。

対応付けを作れば、その予約は在庫計算に反映されます。

その予約は在庫の計算に入りません。 破棄もされず、「要確認」として画面に残ります。

貸出日から返却日までの各日で在庫を使う計算のため（Q16）、返却日が分からないと何日ぶん使うのかが決まりません。 推測で埋めると、実際より短く見積もれば過剰販売に、長く見積もれば売り損ないになります。

予約サイトによっては、予約一覧に返却日が含まれていないことがあります。その場合は予約の詳細を追加で確認しますが、それでも取得できなかった分が「要確認」となります。

対処 — 画面に出た予約を確認し、必要に応じてサイト側でご確認ください。

取り込めます。連携したサイトごとに過去分の予約を読み込む画面をご用意しています。

この取り込みは経営分析のためのもので、在庫の同期には影響しません。 何度実行しても同じ結果になります。

できません。 予約一覧は閲覧・検索・書き出しのみです。

予約の作成・変更・取消は、予約を受け付ける側（各予約サイト・自社サイト）の役目です。

合わせません。自動で台帳を書き換えることはしません。

違いの原因は複数あり得るためです。

• 事業者さまがサイト側を直接操作した
• 書き込みが失敗していた
• サイトの仕様が変わった
• 本製品がまだ知らない予約がある

原因によって「正しいほう」が変わるため、機械が決めるべきではないと考えています。

それを人が選ぶための表示です。 台帳の値とサイトの値を並べて提示します。

台帳の値をサイトへ送るか、サイトの値を台帳へ取り込むかを、日付をまとめて指定できます。

「回収済みの予約だけを材料に在庫表を組み立て直し、いまの台帳と比べる」機能をご用意しています。

違いがあれば、原因となった予約（台帳にない予約、期間が変わった予約など）を車両・日付まで示します。 この処理は読み取りのみで、何も書き換えません。

最大1日かかることがあります。

書き込みのたびにサイトの値を読み直して記録しますが、「期待した値になっているか」の突き合わせは1日1回の網羅的な確認で行うためです。

そのサイトが、設定した枠を超えて予約を受けている状態を表します。

本製品は、この値を0に切り上げず、そのまま表示します。 マイナスを0にしてしまうと、「売り止めで0」なのか「超過受注でマイナス」なのかが区別できなくなるためです。

マイナスが出ている日は、すでに超過している可能性があります。予約内容をご確認ください。

処理を止めて、状態として画面に残します。 誤った値を書き込むより、反映しないことを優先します。

また、接続できないサイトがある間は、各サイトで「増やす反映」が止まります（Q31）。

お知らせします。異常を検知した場合は、ご登録の宛先へメールでご連絡します。

ホーム画面にも、いまの状態、対処が必要な事項、そしてサイトごとに「送信できているか、できていないなら何が足りないか」が表示されます。

気づけるように設計しています。

連携の障害には、誤った値を書き込む失敗だけでなく、処理そのものが呼ばれなくなって何も起きなくなる失敗があります。後者は食い違いも出ないため気づきにくいものです。

これを検出するため、定期処理が実際に動いているかどうかだけを判定する独立した自己点検の仕組みを別に持っています。

成功した分はそのまま有効で、失敗した分は次の機会に再試行されます。

失敗したサイトについては、記録に残り、画面に状態として表示されます。失敗を理由に成功した分を巻き戻すことはしません。

「送信だけを止める」設定をご用意しています。サイトごとに指定できます。

この状態では、そのサイトへの在庫の書き込みは止まりますが、予約の回収は続きます。

大きく違います。連携ごと止めるほうが危険です。

連携を止めると予約の回収まで止まるため、台帳がそのサイトの新しい予約を知らない状態になります。その状態で他サイトへ在庫を出すと、実際には売れている日を販売してしまいます。

一時的に止めたい場合は、「送信だけを止める」をお使いください。

初期化は「導入をやり直す」ための操作です。車両台帳・対応付けなど、導入で作った設定が会社全体で消えます（設定によっては商品の一覧・営業所・ログイン情報も）。

消えないもの

• 予約の記録
• 事業者さまがご自身で行った台数調整
• 外部サイト側のデータ

外部サイトにすでに書き込まれた在庫の値は、元に戻さず、その時点で停止します。外部サイトのデータを本製品が勝手に書き換えないという方針によるものです。

自社サイトに本製品が書き込んだ在庫値も削除せず、事業者さまが編集できる状態へ戻します。

書き込む相手が定まらないためです。

「軽自動車クラス」のような商品は複数台をまとめた単位です。自社の特定の1台の台数を、その商品に書き込むと、どの車の話なのかが決まりません。 誤って書き込めば過剰販売や機会損失につながります。

そのため、クラス単位でしか対応付けられない商品は監視と表示のみとしています。

放置されません。 予約の回収は行われ、売り切れの確認もできます。

• そのサイトで入った予約は回収して台帳に取り込みます（他サイトの在庫にはきちんと反映されます）
• ホーム画面で予約サイトの在庫を最新に更新すると、クラスが売り切れているのにサイトで販売中の日を画面に出します

行わないのは「そのサイトへ台数を書き込むこと」だけです。

自社の1台と、サイトの1商品を1対1で対応付けてください。 そうすれば、同じサイトが書き込みの対象になります。

これはサイト側の商品構成に依存するため、サイトによって可否が異なります。

少ないほうです。

車両単位で見た空きと、その車両が属するクラス全体で見た空きの、少ないほうを採ってサイトへ送ります。どちらの見方でも売り越さないためです（Q21・Q22）。

できます。予約サイト側の営業所を読み取り、自社の店舗と結び付ける仕組みを備えています。

同じサイト内の異なる営業所を、同じ自社店舗に結び付けることはできません。販売しない営業所は「範囲外」として明示します。

サイトの情報から読み取ります。 自己申告ではありません。

読み取った営業所を、自社のどの店舗に対応させるかは事業者さまが確定します。未確定の営業所が残っている間は、対応付けの保存と運用開始ができません。

あります。自動で読み取れるサイトと、そうでないサイトがあります。

読み取れないサイトについては、画面がその事実を明示します。 推測で割り当てることはありません。

分けられます。本製品内の役割として「管理者」と「運用担当」の2種類を管理します。

なお、本製品が管理するのは本製品内の役割のみで、他製品のアカウント種別は変更しません。

記録は残ります。送受信、在庫の書き込み、食い違いの検出と解消、事業者さまの操作を記録として保持します。

画面からは、24時間・7日・30日・90日、および全期間を指定して検索できます。

できます。事業者さま向けの画面は日本語・韓国語・中国語・英語の4言語に対応しています。

いいえ。本製品は料金を同期しません。

料金について提供するのは確認のための表示だけであり、本製品から料金を変更することはありません。

各予約サイトが持っている料金プランを読み取り、自社の料金と並べて表示します。

「どのサイトに、どんなプランが、いくらで出ているか」を1か所で確認できます。

見られます。公開されている他社の料金水準を定期的に取得し、価格の推移とともに表示します。

見つけられます。自社の掲載価格・市場相場・指定した競合を突き合わせ、日付ごとに自社価格の位置と、サイト間で自社価格が食い違っていないかを表示します。

できません。 料金の設定・変更は、各予約サイトおよび自社の料金設定で行っていただきます。

本製品には料金を書き込む機能そのものがありません。

できます。すでに回収した予約データをもとに、次を提供します。

集計そのものは接続せずに行います。 すでに台帳にある予約データだけを使います。

過去分の予約を新たに取り込む場合は、その取り込み時にサイトへ接続します（Q39）。

見られます。サイトごとの手数料率を設定する画面があり、手取りの計算に使います。

分かります。車種別の画面で、よく売れる車種・取り消しが多い車種・単価の高い車種を確認できます。

多くの場合、そうではありません。 先の月は予約がまだ積み上がっていないためです。

この誤読を避けるための注記を画面に持っています。前年同時点との比較もあわせてご確認ください。

外部に対して本製品が書き換えるのは、各予約サイトの在庫数だけです。

自社の販売在庫ではないためです。

現場の予約を在庫に反映するには、自社の車両台帳に登録された車両を指定する必要があります。

調整の「取り消し」は自動で伝わりません。 追加・変更は取り込みますが、調整そのものを削除した場合は自動反映されません。

差が出た場合は食い違いとして表面化しますので、G章の手順でご対応ください。

次の場面です。いずれも「機械が決めると危険」と判断して、人にお任せしている箇所です。

• 対応付けの確定 … 候補は提示しますが、確定は人が行います（Q12）
• 食い違いの解消 … どちらを正とするかは人が選びます（Q42）
• 保留の解消 … 何が足りないかは画面に出ますが、対処は人が行います（Q30）
• 超過受注への対応 … マイナス表示が出た日の扱い（Q45）

*本書は2026年8月時点の稼働版の実測に基づきます。*

お客様が予約サイトの管理画面で行っている操作を、同じ手順・同じ経路で自動的に行っています。特別な抜け道は使いません。

画像認証の自動突破、二要素認証の回避、アクセス制限の迂回といった、認証を回避する処理は行いません。

考え方としては、会計ソフトや家計簿サービスが、ご本人の登録に基づいて銀行口座の明細を自動で取り込むのと同じです。特別な技術ではなく、広く使われている方式です。

ご登録いただいた接続情報は暗号化して保管し、各予約サイトへ接続するときにだけ復号して使用します。

設定画面に表示するのは「設定済み」「未設定」の別のみで、保存したパスワードそのものを画面に表示することはありません。当社の担当者が画面上で確認することもできません。

連携以外の目的や、他の事業者さまの環境で使用することはありません。

いいえ。接続情報はお客様ご自身が設定画面で登録し、接続を有効にされた予約サイトに対してのみ使用します。当社が代わりに登録することはありません。

動作するのは、お客様が設定された範囲の処理だけです。実行の記録は残り、いつ何を更新したかを画面でご確認いただけます（K章）。

設定画面から接続を解除いただくと、保存していた接続情報は削除されます。再びつなぐ場合は、あらためてご登録いただきます。

一時的に止めたいだけの場合は、解除ではなく一時停止をお選びいただけます（I章）。

同様の仕組みは多くのサービスで使われており、それが理由で利用者のアカウントに問題が生じた事例は、私どもの知る限り確認されていません。本製品でも、これまでそうした問題は起きていません。

認証を回避せず、正規の手順による通信のみを行っているためです。また、お客様ご自身の権限の範囲を超える操作は行いません。

提携という形ではなく、お客様のアカウントの権限の範囲内で動作する仕組みです。当社が各社から特別な権限をお預かりしているわけではないため、お客様ご自身にできないことは、本製品にもできません。

各社から正式な連携手段が提供された場合には、そちらへ移行します。移行にあたってお客様のお手を煩わせることはありません。

不正アクセス禁止法は、アカウントの利用権者ご本人の承諾を得て行う入力を、明文で対象外としています（第2条第4項第1号）。本製品は、お客様ご自身が登録し、有効にされたアカウントに対してのみ動作します。

あわせて、認証を回避する処理は行っておりません（Q77）。

レンタカーは、車両ごとの在庫、クラス（まとめ売り）、営業所ごとの運用など、日々変わる条件が多く、複数の予約サイトへ自動で同期する仕組みを作るのが難しい分野でした。

予約サイトごとに画面も手順も異なるため、サイトの数だけ個別に作り込む必要があり、公開したあとも各サイトの変更に追随し続けなければなりません。開発にも運用にも、継続的な手間と費用がかかります。

本製品は、台帳を一つに保つ設計と、予約サイトごとに用意した個別の接続、そして食い違いを自動で検出して画面に出す仕組みを組み合わせて、この課題に取り組んでいます。

ご登録いただいた接続情報は、人にお伝えするものではありません。お客様の同意のもと、お客様に代わって、決まった手順で、決まった情報を読み込み、または記録するためにのみ使用します。他の目的に使われることも、他の方が利用することもありません（Q78）。

こうした定めは、複数の人が一つのアカウントを使い回し、誰が操作したのか分からなくなることを防ぐためのものと理解しています。本製品は、お客様ご自身が登録し、有効にされたアカウントに対してのみ動作し、実行の記録も残ります（Q79）。

当社は、各予約サイトが定める手順を尊重し、その範囲内で動作するよう設計しています。

なお、予約サイト側で担当者用のアカウントを追加できる場合は、本製品専用のアカウントを作成してご登録いただくこともできます。ご希望の際はご相談ください。