回答: ポータルサイトの反響メールをチャットへ自動転送する仕組みは、Google Apps Script（GAS）で自社でも作れます。ただし「どの程度の遅れを許容できるか」で作りが大きく変わります。定期確認による遅れが許容できるなら、Apps Script の時刻トリガーが候補になります。受信を契機に短時間で届けたい場合は Gmail API のプッシュ通知（Cloud Pub/Sub との組み合わせ）を使う構成が候補になり、クラウドサービスを組み合わせたシステムの構築と運用になります。ただし、プッシュ通知にも遅延・欠落があり、到達時間を保証する方式ではありません。どちらを選ぶかは、速度の要件と、作ったあとに誰が保守するかで決まります。
この記事でわかること
- 反響メールをチャットへ転送する仕組みの作り方が、速度の要件で分かれる理由
- Apps Script の時刻トリガーで作る場合の仕様上の制約（実行間隔・実行アカウント）
- 短時間での通知を目指す場合に増える構成要素と、定期的なメンテナンス作業
- 作る前に決めておくべき5つのこと（アカウント・認証情報・異常検知・復旧・個人情報）
- GASで作るのが向いているケースと、向かないケース
最初に決めるのは「何分で届けばよいか」
答え: 技術の選択より先に、業務として許容できる遅れを決めてください。ここが決まらないと、作ったあとに作り直しが必要になることがあります。
反響対応では「競合より先に電話がつながるか」が結果に影響する場合があります。実際に Mail2Link を導入した株式会社えびす不動産では、反響受信から10〜30秒での初回アプローチをルーティン化し、電話接続率が60%から90%へ向上しています（媒介契約獲得率29%）。一方で、問い合わせの性質によっては定期確認による遅れが実害にならない業務もあります。
目安として次のように整理すると選びやすくなります。
| 許容できる遅れ | 現実的な作り | 主に必要になるもの |
|---|---|---|
| 数分〜10分程度の遅れを許容できる | Apps Script の時刻トリガーで定期確認 | Apps Script と転送先への接続設定 |
| 1分前後で届けたい | 同じ方式で最短間隔（1分）に設定 | Apps Script（受信からの到達時間は保証されない） |
| 受信を契機に短時間で届けたい | Gmail API + Cloud Pub/Sub で通知を受けて処理 | Google Cloud プロジェクト、Pub/Sub、通知を処理するアプリ、権限設定、監視（通知の遅延・欠落対策も必要） |
方式A：時刻トリガーで定期確認する
答え: Apps Script の時刻トリガーで Gmail を定期的に見に行き、新しいメールを整形してチャットのWebhookへ送る方式です。構成を比較的シンプルにしやすく、定期確認による遅れが許容できる業務に向いています。転送先がWebhookによる投稿に対応していることも確認してください。
作りの骨格は次のようになります。
- 転送対象を絞る条件を決める（送信元アドレス、件名、本文のキーワード）
- Gmail を検索して未処理のメールを取り出す
- 本文から必要な項目を抜き出し、チャットで読みやすい形に整える
- チャットツールのWebhookへ送信する
- 送信成功を確認したメールに処理済みラベルを付け、二重送信を防ぐための管理をする
- 時刻トリガーを登録して定期実行する
生成AIを使うと、この骨格のコードを用意する助けになります。ただし公式仕様として、次の点は押さえておく必要があります。
- 時刻トリガーの間隔は最短で1分です。メールの受信そのものを契機にする標準のトリガーはありません（Google公式: インストール可能なトリガー）。
- 実行時刻は多少ランダムにずらされます（同上）。1分間隔に設定しても毎回きれいに1分ごとに動くわけではなく、受信からチャット到達までの時間を保証するものではありません。次の実行までの待ち時間や、検索・送信処理の時間も考慮してください。
- 時刻トリガーは作成者のアカウントで動作します（同上）。個人アカウントで作ると、その個人に紐づいた仕組みになります。
- Apps Script には実行時間やメール関連の割り当て上限があります（Google公式: 割り当て）。反響数や処理内容によって上限に当たることがあるため、見込み件数で確認してください。
つまり方式Aは、受信直後に起動する方式ではなく、設定した間隔（最短1分）で新着メールを確認する仕組みです。実際の転送時間が自社の許容範囲に収まるかを確認して使います。
方式B：受信を契機に短時間での通知を目指す
答え: Gmail API の watch と Cloud Pub/Sub を組み合わせると、メールボックスの更新を契機にしたプッシュ通知を受け取れます。ただし通知にはメール本文が含まれないため、通知を受けて本文を取得し、チャットへ送る処理が必要です。通知の遅延・欠落もあり、短時間での到達を保証する方式ではありません（Google公式: プッシュ通知）。
必要になるものが増えます（構成の詳細はGmail API 公式のプッシュ通知ガイドを参照）。
- Google Cloud プロジェクトと Pub/Sub のトピック・サブスクリプション
- 通知を受け取って処理するアプリ（Webhookで受ける場合は公開する受け口）
- Gmail API の認証と、Pub/Sub などへの権限（IAM）の設計
- 動いているかどうかを見る監視
通知を受けてから転送するまでの骨格は、次のようになります。
- watch の登録時に返された履歴IDを保存し、以後の通知を受け取る
- 保存済みの履歴IDを使って、Gmail API の history.list で変更の差分を取得する
- 差分から転送対象のメールを特定し、本文を取得する
- 本文を整形してチャットへ送信する
- 送信成功を確認し、処理済み情報と処理を終えた範囲の履歴IDを保存する
さらに運用として、次の作業が必要です。
- watch は7日以内に呼び直す必要があり、Google は1日1回の更新を推奨しています。更新が止まって期限を過ぎると通知を受け取れなくなるため、更新処理とその失敗の確認を運用に含めます（Google公式: プッシュ通知）。
- 通知の遅延・欠落に備え、定期的に差分を取りに行く処理も併せて用意します。
ここまで来ると、作っているものは「転送スクリプト」ではなく小さなクラウドシステムです。社内に継続して見られる担当がいるかどうかが、作るかどうかの分かれ目になります。
作る前に決めておく5つのこと
答え: コードより先にこの5つを決めておくと、担当が変わっても運用を続けやすくなります。運用担当や手順が未定のままでは、担当変更時に保守や復旧が難しくなるおそれがあります。
- 誰のアカウントで動かすか。 時刻トリガーは作成者のアカウントで動きます。組織で管理する運用アカウントを使い、コードは共有ドライブなどで共有します。ただし、コードの共有だけではトリガーや認証は引き継げません。引き継ぎ時は、後任の運用アカウントでトリガーを再作成し、Gmailへのアクセス権と外部サービスの認証を確認します。切り替え前に動作を確認し、旧トリガーの停止と新トリガーの稼働開始の手順を決め、二重実行を防ぎます（Google公式: インストール可能なトリガー）。
- 認証情報をどこに置くか。 チャットのWebhook URLやAPIキーをコードに直接書かないようにします。スクリプトプロパティなどに分け、誰が見られるかを決めます。
- 失敗に誰がどう気づくか。 通常のインストール型トリガーでは、実行失敗時に作成者へメール通知されます。通知を確認する担当と、担当者以外にも知らせる経路を決めます。正常終了しても対象メールを抽出できず転送されていない場合など、標準の失敗通知では気づけない状況の検知方法も考えます（Google公式: トリガーのエラー）。
- 止まったとき誰が直すか。 担当者名、連絡先、復旧の手順、再実行の方法を文書にします。ポータル側のメール形式が変わったときに誰が調べるかも、ここに含めます。
- 個人情報をどこまで持つか。 反響メールには氏名・電話番号・希望条件が含まれます。ログやスプレッドシートに本文を残すのか、残すなら誰が見られて、いつ消すのかを先に決めます。
この5つは、そのまま自社の棚卸しにも使えます。すでに自作で動かしている場合は、未定の項目が残っていないかを確認してみてください。
GASで作るのが向いているケース、向かないケース
答え: 自作が合う条件は実際にあります。重要なのは、全部を同じ方式でやろうとしないことです。
| 向いている | 向かない | |
|---|---|---|
| 速度 | 定期確認による遅れが実害にならない | 短い遅れでも業務への影響が大きく、定期確認では要件を満たせない |
| 件数・種類 | 件数が少なく、メールの形式が単純 | 複数ポータル・複数形式への対応や変更時の保守を担えない |
| 体制 | 保守できる担当がいて、レビューや引き継ぎの仕組みがある | 特定の担当者に依存し、異動・退職時の引き継ぎ手順がない |
| 障害時 | 止まったことに自社で気づき、調査・復旧できる | 止まったことに気づく経路がない |
| 扱う情報 | 個人情報の保持範囲を決め、運用できる | 図面・見積・個人情報を扱うが管理方法が未整備 |
| 転送先 | 転送先が限られ、条件分岐が単純 | 複数店舗・複数グループへの振り分けを保守する体制がない |
左の列に当てはまり、想定件数や速度の要件を満たせるなら、自作が候補になります。自社の業務に合わせて抽出・整形の条件を調整しやすい点も利点です。右の列に当てはまる場合は、体制や設計を補うか、その業務を専用サービスに任せるかを検討できます。業務によって自作と専用サービスを使い分ける方法もあります。
専用サービスを選ぶ場合、見るべきは機能の数ではなく運用の部分です。異常を検知して知らせてくれるか、ポータル側の仕様変更にどこまで対応するか、問い合わせ窓口と復旧の責任がどこにあるか。あわせて、メール本文や添付ファイルをどこに・どれだけの期間持つのかを提供元に確認してください。自作する場合は、同じことを自分たちで決めて記録しておく必要があります。
自作のリスク面を詳しく整理した記事として反響対応をAI+GASで自作する前に確認すべき4つのリスクもあわせてご覧ください。まず現物で比べたい場合は反響メール転送、無料で試せる範囲はどこまでかが参考になります。
よくある質問
生成AIに書かせたコードでも問題なく動きますか
動く状態まで持っていくことは可能ですが、生成されたコードの確認と動作検証が必要です。動き始めたあとも、ポータル側のメール形式が変わったときに影響を調べて直す、実行が止まったことに気づく、担当が変わっても引き継ぐ、といった作業があります。「作る」と「動かし続ける」を別の作業として計画してください。
1分間隔のトリガーにすれば実質リアルタイムになりますか
最短1分には設定できますが、実行時刻は多少ずらされ、受信を契機にした即時起動にもなりません。次の実行までの待ち時間と処理時間があるため、チャットに届くまでの時間を実際に確認してください。受信を契機に短時間での転送を目指すなら方式Bが候補になりますが、プッシュ通知にも遅延・欠落があり、到達時間は保証されません。
作った担当者が退職したら止まりますか
退職だけで停止するとは限りません。ただし、時刻トリガーは作成者のアカウントで動くため、そのアカウントの停止や権限変更が動作に影響する可能性があります。コードの共有に加え、後任の運用アカウントでトリガーを再作成し、Gmailへのアクセス権と外部サービスの認証を確認してください。切り替え前に動作を確認し、旧トリガーの停止と新トリガーの稼働開始を調整して、二重実行を防ぎます。これらの手順も文書に残します。
個人情報の扱いで最低限決めておくことは何ですか
本文やファイルをどこに残すか、残す場合の保持期間、誰が見られるかを決めてください。転送のついでにスプレッドシートへ全文を控える作りにすると、気づかないうちに個人情報の台帳ができていることがあります。
まとめ
反響メールをチャットへ転送する仕組みは、自社でも作れます。判断では、必要な速度が出るかと、監視・保守・復旧を続けられる体制があるかを確認してください。
まず自社の許容できる遅れを決め、次に「作る前に決めておく5つのこと」に答えを書いてみてください。そのうえで、想定件数での動作、許容遅延、割り当て上限、転送先の仕様への適合を確認できれば、自作での運用を検討できます。未解決の項目が残るなら、設計や体制を補うか、その業務に合う専用サービスを比較してください。
反響対応の速度と運用を、自社で抱えずに済ませたい場合
Mail2Link はポータルサイト等の反響メールを LINE WORKS・LINE・Chatwork へ転送するサービスです。タイトル・本文・送信元などで転送条件を設定できます。オプションとして添付ファイル連携や、LINE WORKS限定の対応状況ボタンを利用できます。無料プランは転送通数に上限があるため、その範囲で動作を確認できます。
—
この記事を書いた会社
7plus株式会社 不動産会社向けの営業DX支援を行うITソリューションプロバイダーです。反響対応を即時化する「Mail2Link」「Mail2Link×AI」、ノーコード業務アプリ「BizBlock」の開発・提供に加え、Salesforce認定パートナーとして不動産特化型Salesforceパッケージの導入・定着コンサルティングも行っています。
詳しくはこちら → https://7plus.jp/
