宿泊施設の予約システムをどう選ぶか｜現場で回る条件から決める

結論から書きます。宿泊施設の予約システム選びで最初にやるべきことは、サービスを比較することではなく、自分が探しているものが「予約を受ける仕組み」なのか「予約後の業務を回す仕組み」なのか「複数の販売経路をつなぐ仕組み」なのかを切り分けることです。この3つは別物で、役割が違います。ここを混ぜたまま比較表を作ると、必ずどこかで話が噛み合わなくなります。

宿泊業のシステムは、飲食店や美容室の予約システムと比べて構造が複雑です。理由は単純で、宿泊業には自社サイト以外の販売経路が多数存在し、そこに在庫を出し分ける必要があるからです。この記事では、宿泊施設の予約まわりのシステムを、現場で回るかどうかという観点から選ぶための条件を、実際に検討する順番で並べます。

まず用語を整理する。3つの仕組みは役割が違う

宿泊予約まわりの解説記事が読みにくいのは、3つの異なる仕組みが「予約システム」という同じ言葉でまとめられているからです。まずここを分けます。

自社予約エンジン

自社の公式サイトから予約を受け付ける仕組みです。宿の公式サイトに「予約する」ボタンがあり、そこから日付と部屋タイプを選んで予約が完了する。あの部分を動かしているのが予約エンジンです。

役割は予約の受付に限定されます。予約が入ったあとの清掃の手配、宿泊台帳、チェックイン、精算といった業務は、予約エンジンの守備範囲ではありません。

施設管理システム

予約が入ったあとの業務を回すための仕組みです。宿泊台帳、部屋の割り当て、清掃の状況管理、チェックインとチェックアウト、精算、売上の集計といった、館内の実務を担当します。PMSと呼ばれます。

予約を受ける機能を持たないわけではありませんが、本体の役割は予約後の管理です。

サイトコントローラー

複数の宿泊予約サイトと自社予約の在庫を同期させる仕組みです。宿泊業に特有の存在で、これがないと販売経路を増やせません。

宿泊業では、複数の宿泊予約サイトに同じ部屋を出すのが一般的です。ところが、それぞれのサイトの管理画面に個別に在庫を入力していると、どこかで1件売れたときに他のサイトの在庫を減らす作業が発生します。この作業が遅れると、同じ部屋を二重に売る事故が起きます。サイトコントローラーは、この在庫の同期を自動でやる仕組みです。

この3つのうち、どれが今の課題を解決するのか。ここを先に決めてください。「予約が入らない」なら予約エンジンとサイトコントローラーの話、「予約は入るが管理が追いつかない」なら施設管理システムの話です。混同したまま探すと、必要のないものを買うことになります。

宿泊予約システムを紹介する解説でも、施設の規模やサービス内容に応じてタイプが分かれることが前提として示されています。

宿泊予約システムには、大きく分けて4つのタイプがあります。導入したい宿泊施設の規模やサービス内容などにあわせて、選び方を見ていきましょう。 出典: aspicjapan.org

比較を始める前に決める4つの前提

サービスを並べる前に、自分の施設の条件を4つ言語化してください。これをやらずに比較表を作ると、判断軸が定まらないまま項目だけが増えます。

部屋をどう持っているか

部屋タイプが何種類あるか。同じタイプの部屋が何室あるか。定員は部屋ごとに違うか。ドミトリーのようにベッド単位で売る部屋があるか。棟貸しや一棟貸切があるか。

ここが複雑な施設ほど、システムに求める在庫表現の柔軟性が上がります。部屋タイプが少なく、1タイプにつき複数室ある標準的なホテル型なら、たいていのシステムで表現できます。一方、ベッド単位で売るドミトリーと個室が混在する施設、離れが複数ある旅館、貸別荘のように棟ごとに条件が違う施設は、在庫の持ち方を表現できないシステムが出てきます。

料金をどう決めているか

固定の料金表で運用しているか、曜日や季節で変えているか、需要に応じて日ごとに変えているか。人数によって1人あたりの料金が変わるか。食事の有無で料金が分かれるか。連泊で割引があるか。

料金の作り方が複雑な施設ほど、料金設定の自由度が選定の主軸になります。日ごとに料金を変える運用をしているのに、期間単位でしか料金を設定できないシステムを選ぶと、毎日手作業が発生します。

どの販売経路を使うか

国内の宿泊予約サイトを何社使うか。海外向けのサイトを使うか。自社サイトからの予約をどれくらいの比率にしたいか。旅行会社経由の団体予約があるか。電話予約が何割か。

海外向けのサイトを使うなら、多言語と多通貨の対応が必要になります。国内のみなら不要です。この判断だけで候補が大きく絞れます。

誰が毎日触るか

フロントのスタッフか、経営者本人か、清掃担当も見るのか。人数は何人か。パソコンで操作するのか、スマートフォンからも見たいのか。

小規模な宿では、経営者がひとりで全部やっているケースが多く、その場合は操作の分かりやすさが機能の多さより重要になります。逆にスタッフが複数いる施設では、権限の分け方が論点になります。

条件1｜自社サイトからの予約を取れる形になっているか

宿泊業の収益構造を考えると、自社サイト経由の予約比率を上げることが直接的な利益改善につながります。宿泊予約サイト経由の予約には販売手数料が発生し、予約が増えるほど手数料も増えるからです。

そこで最初の条件は、自社サイトからの予約を無理なく取れる形になっているかです。確認したいのは次の点です。

予約画面がスマートフォンで使いやすいか。宿泊予約の多くはスマートフォンから行われますから、パソコン向けの画面をそのまま縮めただけの作りだと、途中で離脱されます。日付の選択、部屋の選択、人数の指定、この3ステップが指で操作しやすいかを実際に確認してください。

空室カレンダーが分かりやすいか。どの日が空いていてどの日が満室かが一目で分かる表示になっていないと、利用者は日付を何度も変えて試すことになり、その途中で離脱します。

予約完了までの入力項目が多すぎないか。氏名、連絡先、人数、日付、部屋タイプ。この5つで完了できるのが基本です。会員登録を必須にすると予約率が落ちます。

デザインを自社サイトに合わせられるか。予約ボタンを押した瞬間に見た目がまったく違うページに飛ぶと、利用者は別のサイトに移動したと感じて不安になります。色や書体を合わせられるか、あるいは自社サイト内に埋め込めるかを見てください。

直接つながることの意味

自社サイト経由を増やすというのは、要するに仲介を経由しない取引の比率を上げるということです。仲介が入ればその分の費用が乗り、直接つながればそれが乗らない。当たり前の話ですが、この差は積み重なると大きくなります。

同じ構造は、人が仕事を受ける場面でも起きています。仲介する事業者が入ると受け手の手取りはその分だけ減り、依頼する側は同じ予算で頼める量が減ります。逆に手数料0%の直接取引が成立する場では、依頼する側は同じ予算でより多く頼め、受ける側の手取りは厚くなります。宿泊施設が自社予約を伸ばそうとするのも、仕組みとしてはこれと同じことです。

ただし正直に書いておくと、宿泊予約サイトをやめて自社サイトだけにするという判断は現実的ではありません。予約サイトは集客の場でもあり、そこで施設を知った人が次から自社サイトで予約するという流れが成立するからです。比率を変える話であって、ゼロにする話ではありません。

条件2｜在庫の同期が確実に走るか

販売経路を複数使うなら、ここが最大の論点です。

在庫の同期には、いくつかの段階があります。何も同期していない状態では、各サイトの管理画面に個別に在庫を入力し、売れるたびに他のサイトを手で減らします。これは規模が小さいうちは回りますが、経路が3つを超えると事故が起きます。

次の段階が、一方向の同期です。ひとつの画面で在庫を入力すると各サイトに配信される。ただし各サイトで売れた分が自動で戻ってこない、という状態です。この場合、売れた分の反映が遅れて二重販売が起きます。

必要なのは双方向の同期です。どのサイトで売れても、他のすべてのサイトと自社サイトの在庫が同時に減る。これが成立して初めて、販売経路を安心して増やせます。

確認すべき具体的な項目は次のとおりです。自分が使いたい予約サイトすべてに対応しているか。対応の中身が在庫と料金の両方の配信か、在庫だけか。売れた予約が自動で戻ってくるまでの時間はどれくらいか。同期に失敗したときに通知が来るか。

最後の項目が意外に重要です。同期は必ずどこかで失敗します。ネットワークの問題、予約サイト側の仕様変更、設定ミス。失敗したときに黙って止まるシステムでは、気づいたときには二重販売が起きています。失敗を通知する仕組みがあるかを必ず確認してください。

料金の配信も同期の対象に入るか

在庫だけでなく、料金も同期の対象になります。日ごとに料金を変える運用をしている施設では、各サイトに料金を配信できるかが効いてきます。

さらに踏み込むと、サイトごとに料金を変えたい場合があります。自社サイトを最も安くしたい、特定のサイトだけ限定プランを出したい、といった運用です。これができるかどうかは、システムによって差が出ます。自社サイト最安を打ち出したい施設は、この点を必ず確認してください。

条件3｜予約後の業務がどこまで乗るか

予約を受けるところまでは、どのシステムでも似た機能を持っています。差が出るのは予約後です。

宿泊台帳が自動で作られるか。予約が入った時点で台帳に反映され、フロントで確認できるか。手で転記する運用が残るなら、そこが事故の発生源になります。

部屋の割り当てができるか。予約時点では部屋タイプだけが決まっていて、実際にどの部屋番号を割り当てるかは当日近くに決めるのが一般的です。この割り当て作業を画面上でできるか、複数の予約をまとめて自動で割り当てられるかを見てください。

清掃の状況が分かるか。チェックアウト済みで清掃前の部屋、清掃済みで受け入れ可能な部屋。これがシステム上で分かると、フロントと清掃の連絡が減ります。小規模な施設では不要かもしれませんが、部屋数が増えるほど効きます。

チェックインとチェックアウトの処理ができるか。宿泊者名簿の記録が法令で求められる形で残るか。この点は宿泊業に固有の要件なので、宿泊業向けに作られたシステムかどうかで差が出ます。汎用の予約システムには宿泊者名簿の機能がないことがあります。

精算に対応しているか。現地決済と事前決済の両方に対応しているか。領収書を発行できるか。会計ソフトに連携できるか。

これらをすべて求めるなら施設管理システムが必要です。予約を受けるだけでよく、予約後は手作業で構わないなら予約エンジンだけで足ります。施設の規模と部屋数から判断してください。

宿泊予約に必要な機能が最初から揃っているかどうかは、はじめて導入する施設ほど重要になります。

宿泊予約に必要な機能が網羅的に用意されているので、はじめて予約システムに触れる場合でも機能の不足を感じません。 出典: aspicjapan.org

条件4｜料金とプランの設計を表現できるか

宿泊業の料金設計は、他業種と比べて複雑です。ここを表現できないシステムを選ぶと、毎日手作業が発生します。

確認したい項目を並べます。

日ごとに料金を変えられるか。曜日別、季節別、連休や繁忙期など、料金が変わる単位で設定できるか。1日ずつ手で入力するしかないのか、期間をまとめて設定できるのか。ここの作業効率は、日々の運用時間に直結します。

人数によって料金が変わる設定ができるか。4名定員の部屋に2名で泊まる場合と4名で泊まる場合で、1人あたりの料金が変わるのが宿泊業では一般的です。これを部屋料金として設定するのか1人あたりで設定するのか、両方できるのかを確認してください。

食事の有無でプランを分けられるか。素泊まり、朝食付き、2食付き。この3つが基本です。さらに食事の内容を複数用意する施設なら、その分だけプランが増えます。

連泊割引、早期予約割引、直前割引といった条件付きの料金設定ができるか。

キャンセルポリシーをプランごとに変えられるか。返金なしの割安プランと、直前まで無料キャンセルできる通常プランを併存させたい場合、この設定が必要です。

オプションを追加できるか。夕食の追加、レイトチェックアウト、駐車場、レンタル品。これらを予約時に選ばせて料金に加算できるかを見てください。

条件5｜規模に対して過不足がないか

宿泊施設と一口に言っても、規模と業態の幅が非常に広い分野です。大型のホテルと、部屋数が数室のゲストハウスでは、必要なものがまったく違います。

小規模な施設で、部屋数が少なく、経営者がひとりで運営している場合。必要なのは自社サイトからの予約受付と、複数の予約サイトの在庫同期です。施設管理システムの高度な機能は使いこなせず、費用だけがかかります。操作が簡単で、設定項目が少ないものを選んでください。

中規模で、フロントにスタッフがいて、部屋数がある程度ある場合。予約から予約後の管理まで一貫して扱える構成が必要になります。清掃管理、部屋割り当て、精算といった機能が効いてきます。

大規模で、複数の施設を運営している場合。本部から全施設を見られること、施設ごとに設定を変えられること、売上を横断的に集計できることが要件に加わります。

民泊や貸別荘のような形態の場合。棟単位の在庫表現、非対面のチェックイン、鍵の受け渡し方法との連携、といった固有の要件が出てきます。一般的なホテル向けのシステムでは表現しきれないことがあるので、同じ形態での導入実績があるかを確認してください。

無料で始められるサービスもありますが、月間の予約件数に上限が設定されているのが一般的です。上限を超えたときにどうなるか、有料に移るときにデータが引き継がれるかを、始める前に確認してください。

条件6｜多言語と多通貨が要るかどうか

海外からの宿泊客を受け入れる施設では、この条件が加わります。

予約画面が多言語に対応しているか。対応言語は何か。自動翻訳なのか、手で訳文を入れられるのか。自動翻訳だけだと、施設の説明文が不自然な訳になることがあります。手で訳文を入れられるほうが確実です。

料金を外貨で表示できるか。決済を外貨で受けられるか。海外発行のクレジットカードに対応しているか。

予約確認のメールが利用者の言語で届くか。予約時に日本語以外を選んだ人に日本語のメールが届くと、内容が伝わりません。

海外の予約サイトと連動できるか。国内サイトへの対応と海外サイトへの対応は別問題です。

国内客のみを想定している施設なら、これらはすべて不要です。使わない機能の分まで費用を払う必要はありません。ここを冷静に切り分けてください。正直なところ、この部分は「あったほうがいい」という理由で選ばれがちですが、実際に使わないまま費用だけがかかっているケースが目立ちます。

条件7｜予約後の連絡と当日の受け入れが自動で回るか

予約が入ってからチェックインまでのあいだに、宿泊施設は利用者と何度か連絡を取ります。この連絡が自動で回るかどうかで、日々の作業量が変わります。

まず予約完了の通知です。予約が入った瞬間に、利用者に確認のメールが届き、施設側にも通知が届く。この当たり前に見える流れが、実は設定によって抜けることがあります。施設側の通知先を複数のアドレスにできるか、スマートフォンに届くようにできるかを確認してください。予約に気づくのが遅れると、その分だけ準備が後手に回ります。

次に、宿泊日が近づいたときの案内です。到着予定時刻の確認、駐車場の場所、チェックインの方法、食事の時間。これらを事前に送っておくと、当日の問い合わせが減ります。この案内を自動で送れるか、送る文面を施設ごとに作り込めるか、送るタイミングを指定できるかを見てください。手で1件ずつ送っている施設では、この機能だけで作業時間が明確に減ります。

チェックインの方法にも触れておきます。近年は、フロントに人を常駐させない形の施設が増えています。事前に本人確認と決済を済ませ、当日は暗証番号や鍵の受け取りだけで入室してもらう運用です。この形を取るなら、予約システム側で事前の本人確認情報を集められるか、鍵の受け渡しの仕組みと連携できるかが要件になります。

宿泊後の連絡も設計の対象です。滞在の御礼、口コミ投稿の依頼、次回利用の案内。これらを自動で送る仕組みがあると、リピーターを増やす手立てがひとつ増えます。ただし送りすぎると逆効果になるので、送信の頻度を自分で制御できることが条件です。

問い合わせ対応の窓口をどこに置くか

予約システムを入れても、問い合わせはなくなりません。むしろ、予約の入り口が増えることで、問い合わせの入り口も増えます。予約サイト経由のメッセージ、自社サイトの問い合わせフォーム、電話、メール。

これらがバラバラの場所に届くと、返信漏れが起きます。予約システムがメッセージ機能を持っている場合、どの経路のメッセージまで集約できるかを確認してください。集約できないなら、少なくとも「どこを何時に確認するか」というルールを決めておく必要があります。返信の遅れは、口コミの評価に直接跳ね返る部分です。

条件8｜データを持ち出せるか

契約前に必ず確認すべき項目です。導入時に考えることではないように見えますが、後回しにすると取り返しがつきません。

持ち出したいのは、宿泊者の情報、予約の履歴、未来の予約データ、料金の設定内容の4つです。

宿泊者の情報が出せないと、リピーターの把握ができなくなります。予約履歴が出せないと、過去の稼働状況を分析できなくなります。未来の予約データが出せないと、乗り換えのときに手で入れ直すことになり、その作業中に必ず事故が起きます。

出力形式も確認してください。表計算ソフトで開ける形式なら扱えます。画面を1ページずつ印刷するしかないなら、実質的に持ち出せません。

契約の縛りも見ておきましょう。最低利用期間、途中解約の条件、解約後にデータが残る期間。解約と同時にデータが消えるサービスもあります。

導入を進める順番

条件が固まったら、次の順番で進めてください。

最初にやるのは現状の棚卸しです。直近1年分の予約が、どの経路から何件入ったかを数えます。予約サイト経由が何件、自社サイトが何件、電話が何件、旅行会社経由が何件。この分布が分かると、優先すべき機能が自動的に決まります。

次に、3つの仕組みのうち何を入れるかを確定します。予約エンジンだけか、サイトコントローラーも要るか、施設管理システムまで要るか。全部入りの構成を最初から選ぶ必要はありません。段階的に足していく方法もあります。

そのうえで候補を3つ程度に絞り、必ずデモか無料期間で実際に触ります。触るときは、繁忙期の1日を想定して操作してください。予約を10件入れて、うち2件を変更し、1件をキャンセルし、部屋を割り当てる。この一連の作業にどれくらい時間がかかるかを測ると、実際の運用負荷が見えます。

導入の切り替えは閑散期に行います。切り替え直後は既存の管理方法と並行して運用し、両方が一致することを確認してから旧方式をやめる。この二重運用の期間を惜しむと、後から不一致が発覚します。

在庫の同期を設定するときは、最初は1サイトだけつないで数日運用し、正しく動くことを確認してから残りをつなぐ。全部を一度につなぐと、問題が起きたときにどこが原因か分からなくなります。

口コミと比較記事の読み方

比較記事を読むときの注意点も書いておきます。

まず、ランキングの順位は掲載側の事情で決まっていることがあります。順位そのものより、各サービスの説明に書かれている具体的な条件を拾ってください。対応している予約サイトの一覧、料金の課金単位、契約期間。この3つは具体的に書かれていることが多く、比較の材料になります。

口コミは、自分と規模と業態が近い施設が書いたものを読んでください。部屋数が数室の宿と、数百室のホテルでは、必要なものが違います。星の数の平均には意味がありません。

低評価の口コミは内容を見てください。「機能が足りない」という不満は、その人が求めていた機能が自分にも必要かどうかで意味が変わります。一方で「同期がずれる」「サポートの返信が遅い」「画面が重い」といった不満は、規模を問わず影響します。こちらは重く見るべきです。

正直なところ、比較記事で紹介されているサービスの数が多すぎる場合、そのほとんどは読者にとって関係がありません。自分の条件で3つに絞ってから読むほうが、時間の使い方として効率的です。

導入事例のページを見るときも、注意点があります。掲載されている事例は、当然ながらうまくいったものだけです。自分の施設と規模も業態も違う事例を読んでも参考になりません。読むなら、部屋数と業態が近い事例を探し、そこに書かれている導入前の課題が自分と同じかどうかを見てください。課題が違えば、同じシステムを入れても同じ結果にはなりません。

予約システムで解決しないこともある

正直に書いておくと、予約システムを入れても解決しないことがあります。

まず、予約が増えるわけではありません。予約システムは予約を受ける仕組みであって、集客の仕組みではありません。販売経路を増やすことで露出は増えますが、宿として選ばれる理由がなければ予約は入りません。集客と、施設そのものの魅力づくりは別の話です。

次に、料金の設定判断は代替できません。需要に応じて料金を上げ下げする判断は、システムが候補を出すことはあっても、最終的には人が決めます。近隣の相場、地域のイベント、天候、過去の実績。これらを踏まえた判断は、道具の外側にあります。

そして、運用のルールがなければ機能しません。誰が在庫を入力するか、料金を誰が変えるか、同期のエラーに誰が気づくか。この役割分担が決まっていない施設では、どんなシステムを入れても在庫が実態からずれます。導入と同時に、運用のルールを紙1枚にまとめて共有することを勧めます。

システムを選ぶ視点は業種を超えて共通する

宿泊施設に固有の要件を並べてきましたが、業務システムの選び方そのものには、業種を超えた共通点があります。

現場の人が毎日触るものは、機能の多さより操作の浅さで決まる。外部との連動は双方向でなければ事故が起きる。データを持ち出せないものは長期的に不利になる。この3点は、どの業種のシステムでも変わりません。

同じ視点で他分野を見ると、判断の基準が立てやすくなります。従業員の情報やスキルを管理する分野については、タレントマネジメントシステム比較2026｜カオナビ vs HRBrain vs タレントパレットで主要サービスの設計思想の違いを整理しています。社内の承認や決裁の流れをシステム化する領域は、ワークフローシステム比較2026｜承認業務のDX化で年間200時間を削減で、どこに時間が消えているかという観点からまとめています。

システムの選定や導入設計を社内の人手だけで進めるのが難しい場合、外部の専門家に部分的に頼る選択肢もあります。業務の棚卸しからツール選定、定着までを外部に委託する形の仕事は増えており、AIコンサル・業務活用支援のお仕事にその内容がまとまっています。自社サイトに予約の導線を作り込む段階になれば、アプリケーション開発のお仕事で扱われている形の委託も検討対象に入ります。

現場を長く見てきた立場からの観察

フリーランスと在宅ワークの市場を20年運営してきた立場から、業務システムの導入について観察してきたことを書いておきます。

導入がうまくいく事業者とうまくいかない事業者の差は、システムの性能ではありません。決めた人が現場の操作を自分で試したかどうかです。運営者として多くの事業者を見てきた限り、うまくいかない事例のほとんどは、決めた人と使う人が別で、決めた人が忙しい時間帯に一度も触っていないケースでした。

もうひとつ、長く続く事業者ほど、道具を入れることより、入れたあとの運用ルールに時間を使っています。誰が何を入力するか、ずれが出たときに誰が直すか、同期に失敗したときに誰が気づくか。この取り決めが紙1枚になっている施設は、システムを乗り換えても混乱しません。逆に、人の記憶で回している施設は、どんなシステムを入れても同じ問題が再発します。

道具は運用を助けますが、運用そのものを作りはしません。選定に時間をかけたぶん、同じくらいの時間を運用ルールの整理に使ってください。

よくある質問

Q. 予約エンジンと施設管理システムは両方必要ですか？

施設の規模によります。部屋数が少なく、予約後の管理を手作業で回せる規模なら、予約エンジンとサイトコントローラーだけで足ります。部屋数が増えて清掃の手配や部屋割り当てが煩雑になってきた段階で、施設管理システムを検討するのが順序として自然です。最初から全部入りを選ぶ必要はありません。段階的に足していく方法で問題ありません。

Q. 無料の宿泊予約システムでも運用できますか？

月間の予約件数が少ない小規模な施設なら運用できます。ただし無料プランには件数の上限や機能制限があるのが一般的です。始める前に確認してほしいのは、上限を超えたときにどうなるか、そして蓄積したデータを出力できるかどうかです。データを出せない場合、後で別のシステムに移りたくなったときに、蓄積した情報がすべて失われます。

Q. サイトコントローラーがないと何が起きますか？

複数の宿泊予約サイトに部屋を出している場合、どこかで1件売れるたびに他のサイトの在庫を手で減らす作業が発生します。この作業が遅れると、同じ部屋を二重に売る事故が起きます。使っている予約サイトが1つだけなら不要ですが、2つ以上に出すなら実質的に必須と考えてください。経路が増えるほど、手作業では追いつかなくなります。

Q. 自社サイトからの予約を増やすにはどうすればいいですか？

予約画面をスマートフォンで使いやすくすること、空室カレンダーを分かりやすく表示すること、予約完了までの入力項目を減らすこと。この3点が基本です。会員登録を必須にすると予約率が落ちます。加えて、自社サイトだけの特典や最安料金を設定できるシステムを選ぶと、予約サイトから自社サイトへ誘導する材料になります。

Q. 導入の切り替えはいつやるのが安全ですか？

閑散期に行ってください。繁忙期に切り替えると、慣れない操作と忙しさが重なって予約の取りこぼしや二重販売が起きます。切り替え後しばらくは既存の管理方法と並行して運用し、両方の記録が一致することを確認してから旧方式をやめる方法が確実です。在庫の同期設定は、まず1サイトだけつないで数日試し、正しく動いてから残りをつないでください。