自作の反響転送を専用サービスへ移す手順｜並行稼働から切替まで

回答: 自作の転送を専用サービスへ移すときは、止めてから入れ替えるのではなく、自社の反響が一巡し、必要な媒体・条件を確認できる期間、並行稼働させてから切り替えてください。 手順は4段階です。①いまの仕組みが何をしているかを書き出す ②専用サービスを並行で動かす ③同じ反響が両方に届くか突き合わせる ④ポータル側の送信先を切り替えて、自作側を止める。 詰まるのは機能ではなく、重複通知・フィルター条件の持ち出し・ポータル側の宛先変更の3点です。なお、媒体と転送先が少なく、必要な通知速度を満たし、監視・復旧・引き継ぎの体制も整っているなら、自作を続ける選択も妥当です。

この記事でわかること

• 移行を検討するタイミングと、しなくてよいケース
• 並行稼働を挟む理由
• 4段階の移行手順
• 詰まりやすい3点（重複通知・フィルター条件・ポータル側の宛先）
• 切替前に確認するチェック項目

移行を考えるのはどんなときか

答え: 機能の不足より、維持できる人がいなくなりかけているときです。

自作の転送は、作った時点では最適な選択であることが多いです。要件が自社に合っていて、費用も抑えられます。問題が出るのは、たいてい次のどれかが起きたときです。

• 作った人が異動・退職した、または他の業務で手が回らなくなった
• 媒体のメール形式が変わって、都度の改修が発生するようになった
• 転送先が増えて（店舗・担当・チャット）、条件分岐が追いきれなくなった
• 止まっていたことに後から気づく、という事象が複数回あった

逆に、自作が向いている条件もあります。要件が特殊で既製品に無い処理が必要な場合、扱う媒体が限られていて形式変更の影響が小さい場合、社内に継続して保守できる人がいる場合です。自作が常に不利というわけではありません。判断の材料は反響対応をAI+GASで自作する前の4つのリスクと、作り方そのものを扱った反響メールのチャット転送をGASで自作する方法｜判断の基準にまとめています。

なぜ並行稼働を挟むのか

答え: 長く動いている自作の仕組みには、ドキュメントに残っていない処理が入っていることがあるからです。

作ってから間もない、または仕様書を更新し続けている仕組みなら、この心配は小さくなります。一方、年単位で動いていて改修を繰り返してきた仕組みには、その場で足された例外処理が積み重なっている場合があります。特定の媒体だけ件名を書き換える、ある送信元は無視する、特定の時間帯だけ転送先を変える、といった処理です。仕様書に残っていない処理は、作った人の記憶か、コードを読まないと分かりません。

いきなり切り替えると、この「残っていない処理」が抜けます。仕様書にない例外処理がある場合、切替後に反響が届かなくなって初めて気づくおそれがあります。並行稼働させて突き合わせれば、切り替える前に差分が見つかります。

並行期間の目安は、自社の反響が一巡する期間です。月末に集中する媒体や、週末だけ動く媒体があるなら、それが1回は含まれる長さにしてください。

移行の手順（4段階）

答え: 書き出し・並行稼働・突き合わせ・切替の順に進めます。

①いまの仕組みが何をしているかを書き出す

コードを読む前に、観測できる事実から書き出すほうが速いです。

確認すること	具体的に見るもの
入口	どのメールアドレスで受けているか。媒体ごとに別か
条件	何を条件に振り分けているか（送信元・件名・本文の文字列）
出口	どこに送っているか（チャットのどのグループ、誰のメール、どのシステム）
例外	無視している送信元、書き換えている文字列、時間帯の分岐
失敗時	落ちたときに誰かに通知が行くか（失敗通知の有無を確認する）

ここで「出口」を全部洗い出すのが重要です。個人のメールアドレスへの転送が含まれていないかも確認してください。 含まれていると、後の重複通知の原因になります。

②専用サービスを並行で動かす

ポータル側の送信先はまだ変えません。 いまの受信アドレスに届いたメールを、専用サービス側にも渡す形にします。

• 受信メールを既存の経路と専用サービスの両方へ配信できるか、メール管理者に確認して設定する。エイリアスを使う場合も、両方へ届く配信設定とテストが必要
• 専用サービス側の通知先は、本番とは別のテスト用グループにする（現場に二重通知が行かないようにする）

③突き合わせる

並行期間中、同じ反響が両方に届いているかを確認します。見るのは件数だけではありません。

• 件数が一致しているか
• 振り分け先が同じか（店舗・担当の割り当て）
• 抽出された項目が同じか（氏名・連絡先・物件情報）
• 自作側だけが拾っている例外処理がないか

差分が出たら、専用サービス側の設定で埋められるか確認します。埋められない処理があれば、それが移行の判断材料になります。

④切り替えて、自作側を止める

• 本番の通知先と、切替時に確認する担当者を決めておく
• ポータル側の管理画面で、媒体ごとに反響の送信先を変更する
• 専用サービスの通知先を本番に切り替え、並行稼働用に追加した転送ルールや旧経路を整理する（専用サービスに同じメールが二重に入らないようにする）
• テスト用の反響を送り、本番の通知先に1回だけ届くことを確認する
• 未着や重複が出たときは、事前に決めた手順で戻す
• 自作側はすぐ消さず、通知だけ止めて1か月ほど残す（問題が出たときに戻せるようにする）

ポータル側の宛先変更は、媒体ごとに管理画面の場所が違います。入口の確認はポータルの反響管理画面はどこから入る？媒体別の入口と宛先設定にまとめています。

詰まりやすい3点

答え: 重複通知、フィルター条件の持ち出し、ポータル側の宛先変更を重点的に確認します。

1. 重複通知

並行稼働中と切替直後に最も起きます。原因は、自作側の出口を全部止めきれていないことです。

• 受信アドレスの自動転送ルールが複数残っている
• 個人が自分のメールに転送する設定を個別に入れていた
• チャット側に古いWebhookが残っていて、両方から投稿される

対処は、①の「出口の洗い出し」を漏れなくやることです。個人が自分で設定した転送は、本人に聞かないと分かりません。 切替前に全員に確認してください。

2. フィルター条件の持ち出し

自作側の条件分岐を、そのまま専用サービスに移せないことがあります。

• 本文の特定の文字列で判定している → 媒体のフォーマット変更に依存した条件なので、移さず作り直したほうがよい場合がある
• 複数条件のANDやORが深い → 専用サービス側の設定で表現できるか、並行期間中に確認する
• 時間帯や曜日で分岐している → 対応できるかを事前に確認する

ここで「移せない条件」が出たときは、その条件が本当に必要かを見直す機会でもあります。過去の事情で足されて、いまは不要になっている分岐が見つかることがあります。

3. ポータル側の宛先変更

意外に時間がかかる作業です。

• 媒体ごとに管理画面が違い、権限を持つ人が社内で分散していることがある
• 変更が反映されるまでに時間がかかる媒体がある
• 店舗ごとに契約が分かれていると、店舗数×媒体数の作業になる

切替日を決める前に、変更できる権限を誰が持っているかを確認してください。 ここが止まると、計画全体がずれます。

切替前のチェック項目

答え: 出口の洗い出し、並行稼働での一致、変更の権限、戻し方、失敗時の通知を確認してから切り替えます。

• [ ] 出口（転送先・通知先）を全部洗い出した。個人の転送設定も本人に確認した
• [ ] 並行稼働で、件数・振り分け先・抽出項目が一致することを確認した
• [ ] 自作側だけが拾っている例外処理を把握し、必要なものは移した
• [ ] 移せない条件について、必要かどうかを判断した
• [ ] ポータル側の宛先を変更できる権限を持つ人を確認した
• [ ] 切替後に問題が出たときの戻し方を決めた（自作側を1か月残す等）
• [ ] 失敗したときに誰かに通知が行く状態になっている

最後の項目は、自作側で入っていたかどうかも確認しておきたい部分です。移行の機会に入れておくと、「止まっていたことに後から気づく」が起きにくくなります。この論点はGASのエラーに気づかず反響を取りこぼす理由と対策で扱っています。

移行しないほうがよいケース

答え: 自作で必要な条件を満たせている場合や、既製品で代わりがきかない処理が必要な場合です。

• 媒体と転送先が少なく、必要な通知速度を満たし、監視・復旧・引き継ぎの体制も整っている — 自作を続ける選択も妥当です
• 要件が特殊で、既製品に無い処理が必要 — 並行稼働の③で差分が埋まらないと分かった時点で、移行を止める判断も妥当です
• 反響がほぼ紹介・既存顧客 — ポータル経由の自動処理の価値が小さくなります

よくある質問

並行稼働はどれくらいの期間が必要ですか

自社の反響が一巡する期間を目安にしてください。媒体に月末集中や週末集中があるなら、それが1回は含まれる長さが必要です。本記事では具体的な週数を断定していません。媒体構成によって変わります。

自作側のコードは残しておくべきですか

切替直後は残してください。ただし通知だけは止める（重複通知を防ぐため）。問題が出なければ、1か月ほどで止めても構いません。消す前に、どんな条件分岐が入っていたかの記録だけは残しておくと、後で参照できます。

属人化していてコードを読める人がいません

観測できる事実（どこに届いていて、どこへ送られているか）から並行稼働を始められます。コードを完全に理解しなくても、③の突き合わせで差分は見つかります。読める人がいない状態そのものが、移行を検討する理由になることもあります（GAS自作の属人化リスク｜担当者交代に備える引き継ぎのポイント）。

切替で反響を落とすのが怖いです

だから並行稼働を挟みます。並行期間中は自作側が本番として動いているので、自作側が正常に稼働している間は、専用サービス側の差分が本番の対応に及ぼす影響を抑えられます。受信記録と両方の経路の通知を照合し、未着や差分が解消したことを確認してから切り替えてください。

まとめ

自作から専用サービスへの移行で難しいのは、機能の比較ではありません。ドキュメントに残っていない処理を見つけることと、出口を全部止めきることです。並行稼働を挟んで突き合わせれば、どちらも切替前に見つけやすくなります。

移行しない判断も妥当です。媒体と転送先が少なく、監視・復旧・引き継ぎの体制が整っているなら、自作を続ける選択も妥当です。判断の材料として、まず①の「いまの仕組みが何をしているか」を書き出してみてください。それだけで、維持の負担がどこにあるかが見えてきます。

—

この記事を書いた会社

7plus株式会社 不動産会社向けの営業DX支援を行うITソリューションプロバイダーです。反響対応を即時化する「Mail2Link」「Mail2Link×AI」、ノーコード業務アプリ「BizBlock」の開発・提供に加え、Salesforce認定パートナーとして不動産特化型Salesforceパッケージの導入・定着コンサルティングも行っています。

詳しくはこちら → https://7plus.jp/