1件のAirbnb予約、複数のメール、
1行

予約メールに含まれる情報と、含まれない情報

予約メールは、送信された瞬間においては完全な予約ドキュメントですが、その後のあらゆる瞬間においては不完全なドキュメントです。確認メールには、確認コード、ゲストの名前、リスティング、チェックイン日とチェックアウト日、宿泊数、人数、ゲストが支払った合計額、この滞在であなたが得る収益、そして予約時にゲストが記入した場合はそのメモが含まれます。

データはメッセージ本文にあります。確認メールと一緒にカレンダーファイルが届いた場合、そこに含まれるのは日付と要約行だけで、確認コード、ゲスト、金額は含まれません。転送ルールを選ぶ前に決めておくべき最初のポイントはこれです。本文こそがドキュメントです。

Airbnbは複数のアドレスから送信しています。通知が届かない場合に関するAirbnbのヘルプページでは、連絡先に追加すべきアドレスとして[email protected]、[email protected]、[email protected]が挙げられています。これは送信者の許可リストを作る際に役立つヒントです。Airbnbが実際に使用しているアドレスを許可するのであって、推測した1つのアドレスを許可するのではありません。

メールに含まれない情報も同じくらい重要です。ゲストのメールアドレスは含まれていません。ゲストの電話番号は予約が確定した後にのみ利用可能になり、キャンセルが処理されると予約から消えます。メッセージには支払い日、予約の現在のステータス、変更履歴は含まれていません。こうした欠落があるため、確認メールは記録を開始することはできても、記録そのものにはなれません。

確認メールは予約が存在することを教えてくれます。しかし、その予約がメール送信時のままの状態かどうかは教えてくれません。

1件の予約を変える3つのメッセージ

一度も変更されない予約でも、確認と支払いは発生します。変更される予約では、最初のドキュメントと矛盾する2つ目のドキュメントが発生し、その矛盾をシート側で解決する必要があります。

変更はリクエストとして始まります。Airbnbのホスト向けヘルプページでは、ゲストが旅行変更リクエストを送信できること、また確認メール内のリンクから予約を変更することもできると説明されています。変更はAirbnb内で交渉され適用されます。より示唆に富む記述は、ソフトウェアを使った変更管理に関するAirbnb自身の注記にあります。予約の変更はソフトウェアを通じて承諾または拒否することはできず、Airbnbアカウント内で処理する必要があります。PMSがそのイベントを単独で取り込めないのであれば、その下流にあるスプレッドシートは、変更メールを取得しない限り対応できません。

キャンセルは別のメッセージであり、同時に3つの結果をもたらします。Airbnbのホスト向けヘルプページによると、ゲストがキャンセルするとホストに即座に通知され、日付のブロックが解除され、支払いと返金が調整されるとされています。いずれも新しい予約ではなく、元の確認から推測できるものでもありません。

支払いは別のタイミングで動きます。Airbnbの支払い規約には、各支払いが開始されるとホストにメールで通知されると記載されています。1回の支払いが複数の予約を対象にすることがあるため、支払い行と予約行が1対1で対応することはほとんどありません。

変更メッセージは確認メッセージより短いことがよくあります。何が変わったかを伝えるために書かれており、予約全体を繰り返すものではないため、確認メッセージから入力される列が変更メッセージでは空になることがあります。これは想定内です。確認コードとイベント種別は、変更メッセージが必ず伝えるべきフィールドです。

シートが変更を捉えられない理由

シートが変更を捉えられないのは、変更がAirbnb側で完了しており、シートは受信トレイに届いたものしか把握できないからです。

ほとんどの転送ルールは最初のメッセージを基準に書かれています。「予約確定」という言葉で組まれたフィルターは、後から届くキャンセルに関するメッセージを捉えられず、1つの件名から作られたルールは1つのイベントしか捉えられません。最も重要なメッセージは、ルールが書かれた後に届くものです。

2つ目の原因は追記型抽出です。処理されたメールはそれぞれ1行になり、これは監査証跡としては正しい動作ですが、ステータスフィールドとしては誤った動作です。以前の行を上書きするものがないため、確認メッセージは古い日付を保持したまま、それでいて完全に見えてしまいます。

3つ目は結合キーです。件名には通常、確認コードではなくゲスト名が記載されます。コードが欠けている場合や、別のテンプレートの別の場所にある場合、2つの行にスプレッドシートが照合できる共通の値がありません。その結果、どちらももっともらしい2つの行ができ、どちらが最新かを判断するルールがなくなります。

すべてを転送すると、4つ目の問題が現れます。問い合わせ、予約リクエスト、リマインダーが同じゲストと同じ日付に言及するため、予約のように見えてしまいます。後で辞退されたリクエストも、すでに行を作成済みです。キャンセルされた宿泊のリマインダーは、古い日付をログに残し続けます。

その結果は、ある種の特有のエラーです。ゲストが2泊の宿泊を2日ずらしたとします。確認の行は依然として火曜日と表示しています。清掃担当はシートから清掃切り替えを組み立て、経理担当は元の宿泊数を数え、行は完成しているように見えるため、誰も再確認しません。データが打ち間違えられたわけではありません。後のイベントが以前の行に適用されなかっただけです。

予約メールはイベントです。予約シートは記録です。その間のギャップに、誤ったチェックイン日が潜んでいます。

同じスナップショットの問題はeコマースの注文確認メールにも現れ、住所変更やキャンセルによって、正しく見えても誤って発送される行が残ることがあります。ここでの違いは量です。ショップは注文ごとに1通の確認メールを送りますが、短期賃貸では確認、変更、キャンセル、支払いが送られ、それぞれが同じ予約を異なる角度から説明します。

メールを受信トレイに転送し、本文を読み取る

入口となるのはAirbnb連携ではなく、受信トレイのアドレスです。メール受信トレイを使うと、アカウントにAirbnb予約メール専用のアドレスが割り当てられます。そこへ送信または転送されたメールは処理キューに入り、送信者の許可リストによって無関係なメールは排除されます。Airbnbで重要なのは、どこを読み取るかを指定する設定です。

照合は意味ベースで行われるため、1つのテンプレートで4種類すべてのメッセージ形式に対応できます。これにより、確認・変更・キャンセル・支払いのそれぞれにパーサーを用意することなく、Airbnbの予約データを抽出できます。チェックイン日を繰り返さない変更メッセージでは、そのセルは推測で埋められるのではなく空のままになり、これは台帳で望ましい動作です。予約がメールではなくスクリーンショットで届く場合は、予約スクリーンショットから確認コードと日付を抽出するための項目別ガイドがその入力を扱います。同じ本文のみの設定は、メール本文に書かれた請求書を抽出可能にするものでもあり、このルーティングパターンの一般的な版はメールパーサーのワークフローで扱われています。

すべてのイベントを保持し、予約ごとに1行を表示

受信トレイから届くテーブルはイベントログであり、そのままにしておくべきです。キャンセルメッセージは予約がキャンセルされた唯一の証拠だからです。作業用のビュー用に2つ目のタブを追加し、どの行が予約を表すかは確認コードに決めさせます。

生データタブでは、処理済みのすべてのメッセージを到着順に保持し、=ROW()で連番列を追加します。行番号が大きいほど新しいメッセージであり、エクスポートに受信タイムスタンプがない場合に必要な唯一の時計です。Google Sheetsの作業タブでは、数式を生データタブに向け、コードで並べ替えてから連番を新しい順に並べ替え、各コードの最初の行を保持します:

=UNIQUE(SORT(Emails!A2:L, 1, TRUE, 2, FALSE))

これにより確認コードごとに1行が返され、並べ替えで最新のイベントが先頭に来るため、残る行は最新のものになります。変更は日付を置き換えます。キャンセルはステータスを置き換えます。以前の行は生データタブに残っており、経理担当が支払いがなぜ動いたのかと尋ねたときに役立ちます。

数式は確認コードが列A、連番が列Bであることを前提としているため、列の文字はご自身のレイアウトに合わせて調整してください。キャンセルされた行は作業ビューに残し、現在の稼働状況リストが必要なときにフィルタで除外します。キャンセル行を削除すると返金の説明が失われ、来月にはなぜ金額が足りないのか誰も思い出せなくなります。

自動で解決しないケースが1つあります。確認コードを本当に欠いているメッセージはそれで結合できないため、生データタブに表示されたままになり、手作業で照合します。これはまれであるべきで、数式が黙ってその行を落とすよりも、孤立した行が見えるほうがよいのです。

誰がどの列を見るか

1つのテーブルでホスト、コホスト、清掃担当、経理担当に対応できますが、それはそれぞれが自分の業務用に作られたビューを開く場合に限られます。

ホストは重複排除タブを使います。これは稼働状況の記録と収入の記録を兼ねており、予約ごとに1行で日付、宿泊数、人数、支払い、ステータスが並びます。生データタブは請求内容を確認するためのもので、1か月の計画を立てるためのものではありません。

コホストに必要なのは、ゲストの名前、日付、人数、そして予約時にゲストが残したメモです。共有シートのビューなら、Airbnbのログイン情報を渡さずにこれらを確認できます。これはコホストが一部のリスティングにのみ追加されている場合に重要です。

清掃担当や運用責任者に必要なのは3つです。チェックアウト日、リスティング、そして同じ日に別のゲストがチェックインするかどうか。この担当者には重複排除タブを開いてもらい、生データタブは決して使わせないでください。清掃担当が生データタブを見ることは、修正された日付が再び誤った日付に戻ってしまう最も一般的な原因です。

経理担当に必要なのは、ゲスト合計、清掃料金、あなたの支払い、月であり、キャンセルされた行もそのまま残しておく必要があります。支払いメッセージは専用のタブに入れるべきです。1件の支払いが複数の予約をカバーすることがあり、照合は予約と銀行イベントという2つの粒度の比較になるからです。出力先がシートではなくCRMの場合は、同じフィールドセットをCSVインポートで移行します。メールをCRMの連絡先に変換するパターンはゲスト記録にも当てはまり、予約コードを識別子として重複を防ぎます。

この仕組みでできないこと

境界は受信トレイです。これはAirbnbが送信するメールを読むだけで、それ以外は行いません。シートを作る前に、いくつかの制限を明示しておく価値があります。

背後にAirbnb APIはありません。Airbnbはホスト向けにオープンな予約APIを提供していません。アクセス権はソフトウェアパートナーにあり、2025年の優先ソフトウェアパートナーリストはGuesty、Hostaway、Hospitable、OwnerRez、Lodgify、Beds24、Uplisting、Hostfullyといった物件管理・チャネル管理システムで構成されています。双方向同期が必要なら、そのカテゴリから購入することになり、スプレッドシートのワークフローとは別の購入です。

カレンダーやPMSとの同期はありません。Airbnbのカレンダーエクスポートは.icsフィードで、別のカレンダーで日付をブロックするために使われます。これは日付のみを運び、ゲスト、コード、支払いは含まれないため、予約記録の代わりにはなりません。

Airbnbへの書き戻しは行われません。このシートは価格の変更、日付の開放や締め切り、ゲストへのメッセージ送信、キャンセル処理はできません。起きたことを記録するものであり、リスティングを管理するものではありません。

ゲストメッセージの自動化は別の業務です。「Airbnb メール自動化」の検索結果のほとんどは、定時返信やメッセージテンプレートに関するものです。これは同じ受信トレイのデータ側を扱うもので、両者は互いに干渉せずに併用できます。

メールで届かないイベントは見えません。予約通知がオフになっている場合、ゲストがメールではなく電話をかけてきた場合、アプリのスレッドで変更が合意された場合、シートはそれを把握できません。メールはプラットフォームのイベントのコピーであり、プラットフォームそのものではありません。

連絡先データは意図的に薄くなっています。 ゲストのメールアドレスはなく、電話番号は確認後にのみ記載され、キャンセル後は電話番号がまったく残りません。このシートはマーケティングリストではなく運用記録として扱ってください。

FAQ

これはAirbnbに直接接続しますか？

いいえ。専用の受信トレイに転送したメールを読み取るだけです。Airbnbへのログインも、API接続も、カレンダー同期もありません。利点は、Airbnbがすでに送信しているメッセージで機能することです。予告なく変わるアドレスやテンプレートにも対応します。

どのAirbnbメールを転送すべきですか？

確認、変更、キャンセル、支払いです。問い合わせ、予約リクエスト、リマインダーも完全なログが必要なら含められますが、行が増えるため、シートを誰かに渡す前にイベント種別で絞り込んでください。拒否されたリクエストは予約ではありません。

変更メールと新規予約を区別できますか？

はい。新規予約は新しい確認コードを持ち、変更は変更対象の予約のコードを再利用します。推定のイベント種別列がどの種類のメッセージが届いたかを記録します。変更メッセージにコードがない場合でもイベント種別で判別でき、その行は手動で結合します。

キャンセルで行は削除されますか？

いいえ。キャンセルは異なるステータスの行を追加し、作業ビューにはそのコードの最新ステータスが表示されます。行は残してください。支払いが欠けている理由と再び空いた日付を説明し、予約が消えたわけではない唯一の記録になります。

Vrbo、Booking.com、直接予約でも機能しますか？

はい。受信トレイはどのプラットフォームがメッセージを送ったかを問いません。他の送信者を許可リストに追加し、同じ列を保てば、複数チャネルで予約が入るポートフォリオが1つのテーブルにまとまります。自社サイトからの直接予約の確認も同様に機能します。

完成したテーブルはどこに出力されますか？

XLSXまたはCSVとしてエクスポートし、Google Sheetsで開くかインポートするか、CSVをCRMにインポートします。Google Sheetsアドオンはサイドバーからアップロードしたファイルを前提としているため、受信トレイのメッセージは代わりにエクスポートの経路をたどります。Airbnbの予約をGoogle Sheetsに取り込む方法を探していた場合、エクスポートは最後のステップであり、シートが正しいかどうかを決める作業はそれより前、列とイベント種別を定義した時点で行われています。

行はどのメッセージを採用するかの判断です

Airbnbの予約は1つのドキュメントではありません。短い一連のメッセージであり、シートの行はそのうちどれを採用するかの判断です。確認コードをキーとし、最新メッセージを優先するようにすれば、シートは受信トレイのコピーではなくなり、どの日付を信じるべきかの注記を添えずに清掃担当、コホスト、経理担当に渡せるものになります。

変更があった予約を1件で試してみてください。確認と変更を転送し、列を一度設定して、ビューがどの行を保持するかを確認します。行の日付が最後のメールの日付と一致していれば、その設定は手作業ではつい省略してしまいがちな役割を果たしています。