この記事の結論
専任媒介の報告が32日滞留した理由は、リマインドが届かなかったからではありません。リマインドは毎朝届いていましたが、報告されませんでした。原因は、SUUMO閲覧数・問い合わせ数・案内数を手で集計して定型文に埋める作業が重いことです。入力に合わせて右側の報告文がその場で組み上がる設計に変えたところ、報告の実行率が上がりました。書く時間がゼロにならない限り、リマインドだけでは滞留は解消しません。
リマインドは届いていた。それでも報告されなかった
関東の売買仲介会社で、専任媒介の業務報告が滞留していました。宅建業法34条の2は、専任媒介契約では2週間に1回以上、業務処理状況を依頼者に報告することを義務付けています（最新の要件は管轄の行政機関または専門家にご確認ください）。しかし、8件すべてが7月23日の期限を過ぎ、8月24日時点で32日間超過していました。
問題は、リマインドが届かなかったわけではありません。実際に毎朝8時にリマインドメールが担当者へ送信されており、2026年4月14日8時40分の送信をGmailで確認しています。それでも報告が実行されなかったのです。
担当者に聞くと、「報告しなければならないことは分かっているが、手が回らない」という答えが返ってきました。具体的には、SUUMOの管理画面で閲覧数・問い合わせ数・案内数を確認し、定型文に手で埋め込み、所見を追加して送るという作業です。
この作業が1件あたり5〜10分、専任8件で全部で40〜80分かかります。営業担当の日常業務の中で、この時間をまとめて確保することが難しく、結果的に後回しにされていました。
導入前後の報告滞留状況
v1: リマインドのみ
- 毎朝8時にリマインドメール送信
- スプレッドシートに直接入力
- 報告文は手で埋め込む（1件5〜10分）
- 結果: 8件すべて32日超過
v2: 報告文自動生成
- 入力欄に数値を打ち込むだけ
- 右側の報告文がリアルタイムで更新
- コピーして送信、書く時間ゼロ
- 結果: 実行率が上がった
通知を増やしても、書く時間がゼロにならない限り滞留は解消しない
リマインドが届くことと、報告が実行されることは別問題です。通知は届いていても、実行に必要な時間がゼロにならない限り、滞留は解消しません。
v1の失敗：スプレッドシートへの直接入力
最初に導入したv1のシステムは、Googleスプレッドシートの「活動報告」シートに営業担当が直接入力する方式でした。シートには物件名・報告期限・SUUMO閲覧数・問い合わせ数・案内数の列があり、担当者がそこに数値を入れると、別の列に報告文が自動生成される仕組みです。
しかし、この方式には3つの問題がありました。
スマホから使いづらい
営業担当は外出先から報告したいことが多いのですが、スマホでスプレッドシートを開くと、列が狭くて見づらく、入力欄をタップしても隣のセルを触ってしまうことがありました。結局、パソコンの前に座るまで報告が後回しになりました。
行の取り違え
8件の専任媒介が並んでいるシート上で、どの行がどの物件かを目で追う必要があります。似た物件名があると、間違った行に数値を入れてしまうことがありました。一度入れた数値を別の行に移し替える作業が発生し、余計な手間が増えました。
数式の破損
シートには報告文を自動生成するための数式が入っていますが、営業担当が誤って数式のセルに上書きしてしまうと、報告文が生成されなくなります。復旧のために管理者を呼ぶ必要があり、その間に報告のタイミングを逃しました。
v1では、リマインドメールは毎朝届いていましたが、報告の実行率は上がりませんでした。通知だけでは解決しないことが確認できたため、v2では報告文の生成を含めた設計に切り替えました。
v2で変えたこと：報告文がその場で組み上がる設計
v2では、営業担当が使う画面を、スプレッドシートから独立した業務アプリに切り替えました。構成は以下の通りです。
| 層 | 役割 |
|---|---|
| Googleスプレッドシート | 物件台帳の正本（現場が今まで通り使う） |
| GAS（Google Apps Script） | 台帳を読んでアプリへ送るだけ（毎朝7時自動実行） |
| Supabase（PostgreSQL・東京リージョン） | 報告データの正本 |
| Vercel（Next.js） | 営業担当が使う画面 |
営業担当が使う画面の動線は、①トップに報告状況ダッシュボード（期限超過は赤、2日以内は黄色）、②「報告する」を押すと報告作成画面、③左側に入力欄、右側にリアルタイムで組み上がる報告文、④「本文をコピー」で報告文をコピー、⑤「報告済みにする」で履歴記録と次回期限を14日後に自動更新、です。
報告作成画面の動線
入力に合わせて報告文がその場で組み上がるため、書く時間がゼロになる
この設計の最大のポイントは、入力に合わせて報告文がその場で組み上がることです。営業担当は、SUUMO閲覧数・問い合わせ数・案内数を入力欄に打ち込むだけで、右側の報告文がリアルタイムで更新されます。定型文のテンプレートを開く必要も、手で埋める必要もありません。
報告文の生成ロジックは、以下のルールで動いています。
- 閲覧数・問い合わせ数・案内数を定型文に埋め込む
- 閲覧数が前回より増えていれば「関心は高まっています」と追記
- 問い合わせ数が0なら「反響はありませんでした」と表記
- 案内数が1件以上なら「現地案内を実施しました」と追記
営業担当は、右側の報告文を確認し、問題なければ「本文をコピー」を押すだけです。書く時間がゼロになりました。
報告済みボタンで次回期限が自動計算される
報告文をコピーして売主へ送ったら、「報告済みにする」ボタンを押します。すると、以下の処理が自動で走ります。
- 報告履歴にステータス「sent」で記録される
- 物件の「前回報告日」が今日の日付に更新される
- 「次回期限」が前回報告日の14日後に自動計算される
営業担当は、次回の期限を手で計算する必要がありません。システムが勝手に14日後を計算し、次回のリマインド対象に入れます。
もし未入力の項目があると、報告文に【要入力】と表示されます。そのまま「報告済みにする」を押そうとすると、確認ダイアログが出ます。数値の入力漏れを防ぐための設計です。
システム構成の実際
v2のシステム構成は、Googleスプレッドシート（物件台帳の正本）→ GAS（毎朝7時に自動取込）→ Supabase（報告データの正本）← Vercel（営業担当が使う画面）の4層です。
報告データは以下のテーブルで管理されています。
| テーブル | 内容 |
|---|---|
| properties | 物件台帳（シートから取込）。前回報告日・次回期限で報告サイクルを管理 |
| reports | 報告。status='draft' が進行中の1件、status='sent' が履歴 |
| staff | 担当者とリマインド先メール |
| settings | 報告周期（既定14日）・リマインド開始日・会社名・署名 |
売主の氏名・住所が入るため、RLS（Row Level Security）を有効にし、匿名アクセスは不可にしています。独自ドメインで公開し、Cloudflare Accessで社内メールドメインのみ許可する設計です。
リマインドメールの送信基盤
リマインドメールは、毎朝7時にGASが「今日リマインドすべき物件」をアプリのAPI（/api/due）に問い合わせ、次回期限が今日から2日以内の物件の担当者へメールを送ります。既存のGoogleアカウントの送信枠を使う構成で、メール送信基盤を新たに契約していません。
リマインドの送信は、v1でも実装されていました。v2で変えたのは、リマインドの有無ではなく、報告文の自動生成です。リマインドだけでは滞留は解消しません。
他社が真似する条件
この仕組みを他社が真似する場合、以下の条件が必要です。
報告台帳がスプレッドシートまたはExcelで管理されている
物件台帳が紙またはシステムに閉じている場合、取り込みの手間が増えます。スプレッドシートまたはExcelで管理されている状態であれば、GASまたはPythonスクリプトで取り込むことができます。
ポータルサイトの数値を手で転記している
SUUMO・athome・HOME'Sなどの閲覧数・問い合わせ数を、営業担当が手で見て報告文に埋めている状態が前提です。この作業が報告の実行を妨げているため、自動生成の効果が出ます。
リマインドだけでは解決しないという認識
リマインドが届いていても報告されない状態を、経営者が認識している必要があります。「通知を増やせば解決する」と考えている段階では、この設計は採用されません。
稼働後の変化
2026年4月14日にセットアップを完了し、担当者へ配布しました。配布時点で、専任8件すべてが32日超過という実態が画面に表示される状態にしてあります。報告文の生成ロジックは、v1と同一挙動を維持しており、デモデータで全画面の動作を確認済みです。
報告業務の自動化が持つ意味
専任媒介の業務報告は、宅建業法で義務付けられた法定業務です。リマインドを増やしても、書く時間がゼロにならない限り、滞留は解消しません。Instagram投稿を店舗情報に自動連携して更新を止めない仕組みと同様、実行の負荷を下げることが鍵です。
入力に合わせて報告文がその場で組み上がる設計に変えると、営業担当はSUUMO閲覧数・問い合わせ数・案内数を入力するだけで、完成した報告文を得られます。報告済みボタンを押すと、次回期限が自動で14日後に更新されます。
報告が滞留すると、売主は不安になり、他社へ乗り換える可能性が高まります。売出価格と成約価格の差23.9%が教える媒介戦略で示した通り、売主との信頼関係が成約率に直結するため、報告の実行率を上げることが重要です。
よくある質問
Q. リマインドメールは届いていなかったのですか？
A. 届いていました。実際に毎朝8時に担当者へ送信されており、受信も確認できています。それでも報告が滞留していたため、問題は通知の有無ではなく、報告文を書く負荷にあったことが判明しました。
Q. なぜスプレッドシートの直接入力ではダメだったのですか？
A. スマホから使いづらい、行を取り違える、数式を壊すリスクがあるためです。営業担当が外出先から報告しようとしても、シート上の入力は操作ミスが起きやすく、結果的に後回しにされていました。
Q. 報告文の生成ロジックはどのように設計していますか？
A. SUUMO閲覧数・問い合わせ数・案内数を入力すると、定型文の中に数値を埋め込み、状況に応じた所見（反響が多い場合の追加文言など）を自動で追加する設計です。営業担当は数値を入れるだけで完成した報告文を得られます。
Q. SUUMO数値はどうやって取得していますか？
A. 現状は営業担当がSUUMOの管理画面を見て手入力しています。API連携が可能になれば自動取得も視野に入りますが、まずは報告文の組み上げを自動化することで、報告の実行率を上げることを優先しました。
Q. 他社が同じ仕組みを作る場合、何が必要ですか？
A. 報告台帳がスプレッドシートまたはExcelで管理されていること、ポータルサイトの数値を手で転記している状態であることが前提です。リマインドだけでは解決しないという認識を持ち、報告文の自動生成まで含めた設計が必要です。
相談窓口
専任媒介の業務報告に限らず、不動産会社の日常業務の中で「やらなければならないが、手が回らない」という作業は数多くあります。その多くは、リマインドを増やしても解決しません。実行に必要な時間がゼロにならない限り、後回しにされます。
商談前にAI導入効果を可視化する診断ツールの設計や、反響管理Excel→システムで追客漏れゼロへの記事でも触れていますが、業務の自動化は「何を自動化するか」ではなく「何が実行を妨げているか」から設計する必要があります。
生成AIを貴社の業務にどう組み込むかは、扱う物件・組織の規模・現在の業務フローによって最適解が変わります。株式会社MCOでは、不動産・建設業に特化したAI経営コンサルティングと実装代行、社内定着までの伴走を行っています。まずは公式LINEからお気軽にご相談ください。