Make.com で楽天トラベル × じゃらん × 公式サイト 予約一元化 — ダブルブッキング 0、管理工数 半減レシピ

楽天トラベル・じゃらん・公式サイト・Booking.com — 複数のオンライン予約サイト (OTA: Online Travel Agent) を抱える宿は、ダブルブッキングと管理工数の二重苦と隣り合わせです。サイトコントローラーで在庫を同期しつつ、Make.com で「予約通知の一元集約 + スプレッドシート台帳化 + 異常検知」を月 ¥1,400 程度で組む設計を、日本の宿向けに具体化します。

• ダブルブッキング防止の核は「サイトコントローラー」、Make.com はその上に通知・台帳・分析を載せる役割分担で考える
• Make.com Core プラン ($9 / 月) + Google Workspace で月 ¥2,250 程度、月 1,000 予約規模まで余裕で収まる設計
• TEMAIRAZU・TL-リンカーン・ねっぱん!! の主要 3 つは料金構造と得意領域が異なる (本文に比較表あり)
• Make.com の Anthropic Claude モジュールで「予約メールから希望条件を要約 → スプレッドシートへ整形」も自動化可能
• 機会損失 (連絡漏れ・受け入れ漏れ・空室未調整) を月 1-2 件減らせれば、初期コストは 1 ヶ月で回収できる試算

1. このレシピで解決する課題

ホテル・旅館の予約管理でよく聞く悩みは次の 5 つです。

1. 複数 OTA の在庫同期遅れ: 楽天トラベルで売れた部屋がじゃらん側で在庫として残り、ダブルブッキング発生
2. 予約メールの分散: 楽天トラベル・じゃらん・公式予約・Booking.com からの予約通知メールが受信箱に散らばり、一覧性ゼロ
3. 夜間予約の見落とし: 22-翌朝の予約に翌朝まで気づかず、特別リクエスト対応が遅れる
4. 手作業の台帳転記: 「日付・人数・プラン・特別リクエスト」をエクセルに毎朝コピペで月 8-15 時間消費
5. キャンセル後の在庫戻し漏れ: キャンセル発生時に各 OTA で在庫戻しを忘れる

このうち 1 (在庫同期) はサイトコントローラーの役割で、Make.com 単体では解決できません。一方、2-5 は Make.com が得意な領域です。本記事はこの役割分担を前提に進めます。

なお予約システム業界では、Webhook を活用したリアルタイム連携が「人手を介さない予約管理」の鍵として整理されています (参考: 予約ラボ — Webhook と API の違い)。

2. サイトコントローラーと Make.com の役割分担

「Make.com で予約サイトを一元化したい」という相談を受けることがありますが、これは半分正解・半分誤解です。日本の主要 OTA (楽天トラベル・じゃらん・一休.com 等) の在庫同期は、原則としてサイトコントローラー (Site Controller) の領域です。

Make.com は「サイトコントローラーや PMS を置き換える」ものではなく、「その周辺で人手を奪っている雑務」を引き取るツールです。これを誤解したまま設計すると、ダブルブッキング防止を Make.com に期待してしまい、根本対策にならない事故が起きます。

次節では、サイトコントローラー側で押さえておくべき主要 3 製品の違いを整理します。

3. 主要サイトコントローラー 3 製品の違い

「Make.com を入れる前に、自社のサイトコントローラーが何かを把握する」のが第一歩です。日本国内の中小ホテル・旅館で導入実績の多い 3 製品を、編集部が一次情報源で確認した範囲で整理します。

(料金は各社公式・編集部確認時点。プランや税抜表記、キャンペーンの有無は変わるため、契約前に必ず公式へ確認してください。)

各社一次情報:

• TEMAIRAZU は 300+ パートナーとの連携と「楽天トラベル・じゃらん・Booking.com・Agoda を含む」と明記されています (公式)
• TL-リンカーン は「旅行会社 (リアルエージェント) と OTA を同一画面管理」が最大特徴 (HOTELIER 紹介ページ)
• ねっぱん!! は楽天トラベルサービスが提供、業界シェア No.1・稼働実績 9,000 施設を公式表示 (公式)

なお民泊・小規模施設では海外発の Beds24 が国内シェア上位という業界資料もあります (公式日本サイト)。

導入済みのサイトコントローラーで「現状の予約データがどう手元に届くか」を確認したうえで、次節の Make.com 設計に進みます。

4. 完成形 (フロー図)

サイトコントローラー側で在庫同期した結果として届く「予約確定メール」を Make.com の入口にする設計です。これにより、各 OTA の API 直叩きを避けつつ、現場で本当に欲しい情報だけを集約できます。

5. 必要なツールとコスト

合計目安: 月 ¥8,850 程度 (サイトコントローラー込み)。Make.com 周辺だけで見れば 月 ¥2,250 の追加投資で予約一元化を構築できます。

なお Make.com の料金は本記事執筆時点 (2026 年 5 月) で Free $0 / Core $9 / Pro $16 / Teams $29 構成、Free は 1,000 クレジット / 月、Core 以上は 10,000 クレジット / 月という枠です (公式 Pricing)。1 クレジットの定義は原則 1 オペレーションですが、AI モジュールはトークン消費量で変動する点に注意 (Make.com Credits ヘルプ)。

6. 設定手順 (約 90 分)

Step 1: Make.com アカウント作成と接続準備 (10 分)

1. Make.com でサインアップ (Free から開始可)
2. ダッシュボードで「Create a new scenario」をクリック
3. 後で使う Gmail / Google Sheets / Slack / LINE Messaging API を「Connections」から OAuth で接続
4. 担当者の Google アカウントを使う場合、各 OTA の通知メールがそのアドレスに届く設定になっているかを先に確認

Step 2: 予約台帳の Google Sheets を準備 (15 分)

統一台帳のカラム例:

• 受付日時
• ソース (楽天 / じゃらん / 公式 / Booking 等)
• 予約番号
• チェックイン日 / チェックアウト日 / 泊数
• 部屋タイプ
• 人数 (大人 / 小人)
• 顧客名
• 連絡先 (メール / 電話)
• プラン名
• 料金 (税込)
• 特別要望
• ステータス (受付 / 連絡済 / 当日 / 滞在中 / 完了 / キャンセル)

PMS を使っている場合は、PMS の予約一覧をマスタにし、本台帳は「分析・通知用のミラー」と位置付けると役割が分かりやすくなります。

Step 3: シナリオ #1 — 予約通知受信 → 解析 → 台帳追記 (30 分)

[Trigger]
  Gmail > Watch Emails
    folder: INBOX
    filter: from:travel.rakuten.co.jp OR from:jalan.net OR from:booking.com OR label:公式予約
    Maximum: 10

[Module 2]
  Tools > Set multiple variables
    本文プレーンテキスト化、ヘッダから送信元判定 (rakuten / jalan / booking / official)

[Module 3]
  Text parser > Match pattern (正規表現) または
  Anthropic Claude > Create a Prompt
    →「以下の予約確認メールから JSON で抽出: {予約番号, IN, OUT, 部屋, 人数, プラン, 料金, 特別要望}」

[Module 4]
  JSON > Parse JSON
    Claude が返した文字列を構造化データに変換

[Module 5]
  Google Sheets > Add a row
    Step 2 で作成した台帳に新規行追加 (ステータス: 受付)

ポイント: 楽天トラベル・じゃらんは確認メールの本文フォーマットが定期的に微変更されるため、正規表現だけで運用すると保守が重くなります。Make.com の Anthropic Claude モジュールを併用すると、フォーマット変更に強くなります (Make.com Anthropic Claude Integration)。

Step 4: Slack / LINE 通知の追加 (15 分)

シナリオ #1 の最後に Router を挿入し、2 系統に分岐します。

[Router]
  ├─ Branch A: Slack > Create a Message
  │    Channel: #予約-受信
  │    Text: "🛏 新規予約 (${ソース})
  │           ${顧客名} 様 / ${人数}名 / ${部屋}
  │           ${IN} 〜 ${OUT} (${泊数} 泊)
  │           特別要望: ${特別要望 or '—'}
  │           [台帳で見る](${シート URL})"
  │
  └─ Branch B: LINE Messaging API > Push Message
       To: ${フロント担当の LINE userId}
       Text: 上記と同様の要点版

なお LINE Notify は 2025 年 3 月 31 日に提供終了しているため、現役で利用可能なのは LINE Messaging API です (LINE Notify サービス終了告知)。

Step 5: シナリオ #2 — ダブルブッキング検知 (15 分)

サイトコントローラーが正常稼働していれば理論上は発生しませんが、運用エラー (在庫上限のチューニングミス・手動操作の競合) に備えて重複検知を仕込みます。

[Trigger]
  Schedule > Every 30 minutes

[Module 2]
  Google Sheets > Search rows
    対象: 今日 + 翌 30 日のチェックイン日

[Module 3]
  Tools > Aggregator
    キー: 「チェックイン日 + 部屋タイプ」 でグループ化

[Module 4]
  Filter: グループ内に 2 件以上の予約がある場合のみ通過

[Module 5]
  Slack > Create a Message
    "🚨 ダブルブッキング疑い: ${IN} ${部屋} に予約 ${件数}件
     ${予約番号 1} / ${予約番号 2}
     至急サイトコントローラーで確認してください"

「30 分間隔で Sheets を読みに行く」だけで、現場が気づくより先にアラートが上がります。

Step 6: シナリオ #3 — 前日リマインダー & 当日朝サマリ (10 分)

[Trigger]
  Schedule > Every day at 17:00 (前日リマインド)

[Module 2]
  Google Sheets > Search rows
    フィルタ: チェックイン日 = 翌日 AND ステータス = 受付

[Module 3]
  Iterator (検索結果を 1 件ずつ処理)

[Module 4]
  Slack > Create a Message
    "📋 明日の到着 (${件数}件):
     - ${時刻} ${顧客名} 様 / ${部屋} / ${特別要望}"

[Module 5] (別シナリオ: 当日朝 8:00)
  当日のチェックイン一覧を支配人 LINE に Push

「前日 17 時に翌日分の特別要望を共有する」運用がフロント・厨房・清掃の連携を一段階上げます。

7. 編集部によるシミュレーション (期待効果の試算)

以下は 編集部による試算 です。客室数・OTA 構成・既存運用により実数値は変動します。

前提: 客室 10 室、月予約 200 件 (楽天 50% / じゃらん 30% / 公式 + Booking.com 20%)、平均単価 ¥18,000、フロント 2 名体制を想定:

費用感の整理:

• 月コスト (Make.com 周辺の追加分): ¥2,250
• 削減: 月 14 時間の事務作業 (時給換算 ¥1,500 で月 ¥21,000)
• 機会損失防止: ダブルブッキング 1 件あたりの補償・代替手配コスト ¥30,000-¥80,000 を年数回減らせる試算

月 1 件のダブルブッキング防止だけでも、初期コストの 10 倍以上を回収する構造になりやすい領域です。

8. 失敗パターン

9. 注意点 (法務・規約面)

• 個人情報保護法: 顧客の連絡先・宿泊履歴は要配慮個人情報を含み得るため、Make.com (EU/US データセンター) を経由する旨を自社プライバシーポリシーに明記
• 旅館業法 / 国際観光ホテル整備法: 宿泊者名簿の保管義務 (3 年) は PMS 側で確実に満たす設計とし、Make.com 側の Sheets はあくまでオペレーション用と位置付ける
• 各 OTA の利用規約: 楽天トラベル・じゃらん等の予約確認メールを業務目的で自動転送・解析する範囲は通常の運用想定内ですが、加盟店契約条項の確認は契約者の責任で行ってください
• 電気通信事業法 (特商法): 顧客への送信メールには、配信停止・問合せ先の明記が必要
• LINE Messaging API: フロー上のフリープラン (Communication Plan) は月 200 通までの送信制限あり、規模拡大時はライトプラン以上を検討 (LINE Developers)

10. トラブルシューティング

Q. 予約メールのフォーマットが微妙に変わって解析できなくなった

A. Anthropic Claude モジュール経由なら、プロンプトに「最新の予約確認メールサンプル 2 件」を Few-shot で追加すると追従できます。正規表現運用の場合は、Match pattern モジュールの直後に「失敗時 → Slack に原文転送 + 手動入力依頼」 Router 分岐を必ず仕込んでください。

Q. 予約 ID の重複行が増えてきた (台帳に同じ予約が 2 行ある)

A. シナリオ #1 の Google Sheets > Add a row の前に、Search rows で同一予約番号の存在チェックを入れ、存在すれば Update (キャンセル等で上書き)、なければ Add に分岐させます。

Q. ダブルブッキング検知のアラートが誤検知ばかり

A. 多くは「同じ予約者が同日連泊で 2 行に分かれているケース」が原因です。Aggregator のキーに「予約番号」を含めて除外するか、「異なる予約番号 × 同一部屋 × 同一チェックイン日」を厳密条件にしてください。

11. まとめ

ホテル・旅館の予約管理は、サイトコントローラー (在庫同期の基盤) + Make.com (通知・台帳・異常検知の上層) の二層で組むのが、2026 年時点で最もコスト対効果に優れたアプローチです。Make.com 周辺コストは月 ¥2,250 程度に収まり、月 1 件のダブルブッキング防止だけで投資回収可能な構造になります。

最大の効果は、22 時に届いた楽天トラベルの予約に翌朝ではなく 数十秒で全員が気づけること。これは顧客体験 (特別要望対応の速さ) と内部コミュニケーション (フロント・支配人・清掃間) の両方に効きます。

Make.com を無料プランで試す →
※ アフィリエイトリンクを含みます

関連レシピ

• Make.com で不動産仲介の物件問合せを自動化する完全レシピ
• Make.com で美容室の予約管理＆リマインダーを自動化する完全レシピ
• Make.com で整体院の LINE 予約を自動化するレシピ
• IT 導入補助金 2026 — AI で申請準備を 30 分に短縮

出典・参考情報

• Make.com 公式サイト
• Make.com Pricing 公式
• Make.com Credits (旧 Operations) ヘルプ
• Make.com シナリオスケジューリング 公式ヘルプ
• Make.com Anthropic Claude Integration
• TEMAIRAZU (手間いらず) 公式
• TL-リンカーン HOTELIER 紹介ページ
• ねっぱん!! 公式
• Beds24 日本公式
• 楽天トラベル
• じゃらん net
• LINE Developers (Messaging API)
• LINE Notify サービス終了 公式告知
• 予約ラボ — Webhook と API の違い
• HOTELIER — ホテル予約サイトコントローラーの一覧・まとめ

Mira ／ AI経営ラボ 編集長

Make.com を試す →
※ アフィリエイトリンクを含みます