内見メールを1枚のシートに、
日程変更にも対応

内見確認メールには時刻だけでなくアクセス情報も含まれる

チームが必要とする項目は、予約が確定した時点でリスティングのワークシートから生成され、すでにメール本文に含まれています。プラットフォーム間で変わるのは項目の種類よりも、文言、順序、そしてその項目がこのメッセージに含まれているかどうかです。

ShowingTime は内見確認メールに指示文を含めますが、その文面はエージェントが依頼を確定する時点で調整できません。修正は別のメッセージとして送信する必要があり、内見エージェントの受信トレイでは異なる表示になります（ShowingTime instructions）。各メッセージはスナップショットであり、修正は最初のものとは見た目が異なる2つ目のスナップショットです。

内見確認メールは1件の予約のアクセス記録です。単なるカレンダー通知として扱うと、キーボックスの場所、指示、コードは受信トレイに埋もれたままになります。

1回の内見で複数のメールが届き、内見確認メールはそのうち1通だけ

1件の予約で、誰も物件に足を踏み入れる前に5通のメッセージが届くことがあります。リクエスト、内見確認メール、リマインダー、予定が動けば日程変更またはキャンセル、そして後日のフィードバック依頼です。いずれも同じプラットフォームから、似た件名で届き、ShowingTimeでは内見確認メールの送信者としてプラットフォーム名ではなく売主側エージェントの名前が表示されることがあります。

この量は、土曜の内見ツアーを回したことのある人なら誰でも馴染みがあります。ある買主側エージェントは、この体験をr/realtorsで「エージェントがリクエストを受け取った、見た、考えた、リクエストの近くでサンドイッチを食べた、と知らせるメールのBARRAGE（嵐）」と表現しました。パイプラインが「新着メールが入れば、新しい行を出す」という作りなら、そのメッセージはどれも行の候補になります。

NARの2025年世代別動向レポートは、買主側の実態を明らかにしています。買主は中央値で10週間検索し、中央値で7件の住宅を閲覧しました（NAR, 2025）。7件の住宅とは、少なくとも7件の予約を意味し、それらの住宅が使う売主側・プラットフォームの数だけ広がります。したがって1件の物件のシートには、命名の習慣もプラットフォームのテンプレートも異なる多くのエージェントからメッセージが届きます。

リードメールは、連絡先レコードにしなければならない問い合わせです。内見確認メールはすでに存在する予約であり、シートはそれを写そうとしています。だからこそ不動産リードメールのワークフローは別の問題を解決するのです。内見確認メールの役割は特定の時間枠のアクセスを証明することであり、5通のうちそれを果たすのは1通だけです。

すべてのメールが行になると、シートは後で断られたリクエスト、後で動いた内見確認メール、アクセス情報をまったく含まないフィードバック依頼で埋まります。残す価値のある行は内見確認メールです。真実を変える行はキャンセルです。ステータス列があれば、両者を同じイベントと見なすことなく、どちらも保持できます。

スプレッドシートと内見システムが一致しなくなる箇所

スプレッドシートと内見システムが一致しないのは、フィールドの読み取りを誤ったからではありません。プラットフォームが内見確認メールを発行・更新する仕組みの違いによって生じ、それぞれの構造が特定の種類の古い行を生み出します。

日程変更は新規リクエストとして届くため、古い行は変わらない

ShowingTimeでは、予約を日程変更すると、日程変更情報を含む新しい予約リクエストが売主側エージェントに送信され、確認を求められます（ShowingTimeの日程変更）。元の行は誰も編集しません。存在しない時刻のままスプレッドシートに残り、完了済みに見えるためそのまま残り続けます。

古い行は古く見えません。住所と時刻とエージェントがあり、これは正しい行が持つものとまったく同じです。

更新は土曜日の他のあらゆる作業と競合し、完了済みに見える行は自分が古いと決して知らせてくれません。古い時刻が置き換えられなかったことを伝えるエラーメッセージは表示されません。

共同担当エージェントと内見指示はMLSから一度だけ取得され、その後更新されない

ShowingTimeはリスティングデータ（共同出品エージェントや内見指示を含む）を初回に一度だけ取得します。その後MLSで行われた変更は自動的に反映されません（共同出品エージェント、内見指示）。公開後に共同担当エージェントを追加したリスティングでは、共同担当エージェント欄が空のまま内見確認メールが送信され続けることがあり、内見指示が変更されたリスティングでは古い指示が送信され続けたり、まったく送信されなかったりします。

メールに含まれていなかった項目を復元できる抽出設定はありません。シート上の共同担当エージェントが空であることは、リスティングのワークシートに関するシグナルであり、読み取りに関するシグナルではありません。有効な対応は、空欄にフラグを立てて内見プラットフォーム側で修正することであり、抽出を再実行して異なる結果を期待することではありません。

アクセスコードは発行対象の予約とともに失効する

Master LockのBrokerBayロックボックスガイドには、内見確認メールのコードは確定した予約に対してのみ有効であると明記されています（Master Lock Vaultガイド、2022年）。これにより、重複した行が現実世界の失敗を引き起こします。内見エージェントがシートを開き、以前の行からコードを読み取り、物件まで車を走らせても、ボックスは開きません。

重複した行のコストは1分のクリーンアップです。古いコードのコストは、移動、内見の遅れ、そしてポーチに立ち尽くす買主です。だからこそ、シートには単なるログではなく最新ビューが必要なのです。

内見に関わるのは誰か、各ロールが所有する項目

1件の予約に6人が関わり、それぞれが記録の異なる部分を所有します。すべてを1人の「あなた」が管理している前提でシートを書くと、引き継ぎが漏れます。

所有権が明確になれば、列の構成も決まります。リスティングコーディネーターはステータスと日程変更を所有します。売主側エージェントは指示とアクセスを所有するため、そこが空欄なら上流で修正すべき事項です。内見エージェントは、内見確認メールには一切現れない現場メモを所有します。

ShowingTime、SentriLock、BrokerBayで共通して使える列セット

列セットはメールではなく内見予約を表すものでなければなりません。この名前を一度入力すれば、値は固定テンプレート内の位置ではなく意味で検出されるため、同じセットで3つのプラットフォームすべてを読み取れます。

ロックボックスのコードをシートに記載すべきかは、意図的に判断してください。チーム、バーチャルアシスタント、またはCRM同期と共有されるシートは、内見確認メールよりもはるかに広い配布範囲になります。チームが知る必要があるのがボックスの場所と、コードが内見確認メールにあるという事実だけなら、「コードは内見確認メールに記載」とアクセスメモ列に書けば十分です。コードを保存する必要がある場合は、シートを制限し、予約が過ぎたら古い行を削除してください。プラットフォームがワンデイコードを発行する場合、それは予約とともに失効するため、先に持ち越しても運用上の価値はありません。固定の組み合わせコードは別の問題であり、共有シートに保存する場合はより慎重な検討が必要です。

各メッセージを転送せずにメールをシートに取り込む方法

ShowingTimeからGoogle Sheetsへの設定と呼ばれているものは、実際にはメール経由のルートです。プラットフォームが内見確認メールを送信し、受信トレイがそれを読み取り、シートが行を受け取ります。3つのプラットフォームのいずれも内見をスプレッドシートに書き込まないため、接続点は受信トレイです。専用のメールアドレスと1つの転送ルールが手動転送を置き換え、抽出はアクセス情報がすでに記載されているメッセージ本文を読み取ります。

ImageToTable.aiのEmail Inboxは、すべてのアカウントに専用アドレスを付与します。そこに送られたメールは誰もログインすることなく処理キューに入り、ここで重要な設定は「何を読み取るか」と「誰からのメールを受け入れるか」の2つです。デフォルトでは実際の添付ファイルを読み取り、本文は無視しますが、有用な添付ファイルがない内見確認メールには適切でないデフォルトです。このデフォルトは実際のファイルを伴うメール向けに存在し、添付ファイル優先のメールデータ抽出ワークフローが想定するケースですが、内見確認メールは逆のケースです。本文のみまたは添付ファイルと本文に切り替えると、メッセージ自体が入力になります。本文のみの抽出ワークフローでこのモードを詳しく説明しています。

そこから、Custom Column Extractionがプラットフォームごとのテンプレートを不要にします。物件住所、内見日、開始時刻、ステータス、内見エージェントなど、必要な列名を入力すると、AIはページ上の位置ではなく意味を理解して各値を探し出します。入力した名前が出力のヘッダーになります。同じ列セットで、ShowingTimeの内見確認メール、BrokerBayの内見確認メール、SentriLockの予約通知を、フォーマットごとに別のルールを作成することなく読み取れます。

同じパイプラインの形は、単一のリスティングでも複数のリスティングでも機能します。行は1つのテーブルに蓄積され、プラットフォーム列がソースを区別します。サプライヤーが本文と添付ファイルの両方を送信した場合の対処を含む、メールからスプレッドシートへの受け渡しの仕組みは、メールからシートへのパイプライン解説で説明しています。

日程変更後も1回の内見につき1行を保つ

1回の内見につき1行を実現するには、追記専用ログと最新ビューという2つのレイヤーが必要です。抽出は読み取ったメッセージごとに行を追記します。以前の行を編集・削除することはないため、突き合わせの処理は抽出側ではなくスプレッドシート側で行う必要があります。

第1のレイヤーはログです。内見確認メール、日程変更、キャンセルはすべて1行になり、どの行も編集されません。これが監査証跡となり、プラットフォームが何をいつ送信したかを証明します。追記専用にしておくことで、誤った修正も元の記録を黙って上書きせず、目に見える形で残ります。

第2のレイヤーは最新ビューです。ログを読み取り、予約ごとに最新の有効な行を残し、上書きされた行を非表示にします。Google Sheetsでは、ログのコピーに補助列を追加して対応します。予約番号とステータス日付で並べ替え、同じキーを持つ先行行を数えます。=COUNTIFS($B$2:$B2,$B2)>1 のような数式で最初の行以降をすべてフラグ付けし、そのフラグを FALSE で絞り込めば、予約ごとに1行が残ります。

日程変更でプラットフォームが新しい確認番号を発行すると、古い行と新しい行は同じキーを共有しません。その場合は物件住所と内見エージェントで照合し、ステータスが新しい方の行を残します。キャンセルが届いた場合は、最初の1件が来る前に方針を決めておきます。最新ビューから除外してログには残すか、キャンセルとして表示して売主側が枠が消えた理由を確認できるようにするかです。

スプレッドシートでの15分の作業が、ログと最新ビューを分けます。これは多くのチームが省略する手順でもあり、そのために抽出が完璧に動き続けているのにシートが古くなってしまいます。

これが行わないこと

このパイプラインはメールを読み取るだけで内見を実行しないため、その上にレポートを構築する前に境界を明確にする必要があります。

• ネイティブなプラットフォーム連携はありません。 ShowingTime、SentriLock、BrokerBayのコネクタはなく、内見プラットフォームからのAPI取得も、シートから予約・確定・日程変更・キャンセルを行う方法もありません。
• カレンダーやロックボックスの制御はありません。 このパイプラインはGoogle CalendarやOutlookに書き込まず、ロックボックスを開けたり、割り当てたり、管理したりしません。プラットフォームが送信した内容を記録するだけです。
• その場での更新はありません。 日程変更は新しい行を生成します。内見ごとに1つの最新行を保つのは、上記の2層スプレッドシートの手順であり、自動的な動作ではありません。
• プラットフォームのレポートは依然としてリスティングごとの記録です。 ShowingTimeのListing Activity Reportには内見エージェント情報、メモ、フィードバックが含まれ、そのオーナー向けバージョンでは内見エージェントの詳細が意図的に省略されています（Listing Activity Report）。プラットフォームのレポートが提供しないクロスプラットフォーム、クロスリスティング、チーム、CRMのビューにはシートを使用し、レポートの代替として使用しないでください。
• 受信トレイは通知設定と同じくらいしか完全ではありません。 SentriKeyはメールが選択解除されていても、Message Centerに内見通知を送信します（SentriKeyガイド）。売主側の誰かがメールをオフにしている場合、内見確認メールは存在しますが、パイプラインには届きません。
• これはCRMではありません。 出力はスプレッドシートまたはJSONです。Follow Up Boss、kvCORE、および同様のシステムはCSVをインポートし、直接プッシュはAPIの仕事であり、組み込みのコネクタではありません。

また、ログは取引ファイルが始まるところで終わります。リスティングが契約になったら、内見アクティビティはクロージングドキュメントパッケージのコンテキストとなり、これには独自の完全性ルールと独自の保管場所があります。

FAQ

1つの列セットでShowingTime、SentriLock、BrokerBayのメールをまとめて読み取れますか？

はい、値がメッセージ本文に含まれていれば可能です。3つのプラットフォームは文言やフィールドの順序が異なりますが、カスタム列抽出は位置ではなく意味で各値を探すため、1つの列名セットで3つすべてに対応できます。「ログインして予約を確認してください」とだけ書かれ詳細がない通知からはフィールドを生成できません。値がメッセージ内に存在しないためです。

内見確認メールにPDF添付は必要ですか？

いいえ。内見確認メールは切り離すPDFではなくメッセージ本文として送信されるため、添付のみの既定設定では有用な結果が返りません。受信トレイを本文のみ、または添付と本文に設定して、メッセージ本文を直接読み取れるようにしてください。

内見が日程変更またはキャンセルされたときに行を更新できますか？

いいえ。各メッセージは新しい行になります。最新ビューを保つには、追記専用ログを予約ごとの最新の有効な行に絞り込む必要があり、これが上記の2層アプローチです。抽出は以前の行を編集または削除しません。

メールに共同担当エージェントが含まれていない場合はどうなりますか？

値が存在しないため、パイプラインはそのフィールドを空のままにします。これは通常、共同担当エージェントが追加される前に内見プラットフォームがリスティングを取得したことを意味し、内見プラットフォーム内で共同担当エージェントが追加されるまで空のまま送信され続けます。空欄は抽出エラーではなく、リスティング側の対応事項として扱ってください。

Follow Up BossやkvCOREに直接書き込めますか？

ネイティブにはできません。出力はスプレッドシートまたはJSONで、標準的な経路はCRMへのCSVインポートです。直接プッシュが必要なチームは、REST APIとwebhookを独自のブリッジとして使用します。

ロックボックスコードを共有シートに保管しても安全ですか？

通常は安全ではありません。共有シートは内見確認メールよりも広範囲に届きます。チームが本当にシート内にコードを必要としない限り、キーボックスの場所と「コードは内見確認メールに記載」という指示を保管してください。必要とする場合は、アクセスを制限し、予約後にコードを消去してください。ワンデイコードは予約が過ぎると無効になるためです。

内見シートは予約の記録であり、メールの一覧ではありません。シートが予約をキーにするようになれば、日程変更は例外ではなくステータス変更になります。

この変化により、シートは週次の売主レポート、チームダッシュボード、CRMインポートに使えるようになります。各プラットフォームの内見確認メールを1通ずつテストして、どのフィールドが返ってくるか、どのフィールドがメールに含まれていなかったかを確認してください。実際の内見確認メールで試す。