回答: メールをチャットへ転送する仕組みは自社でも作れます。運用を続けるには、業務に合う速度と、保守・復旧の体制があるかを確認することが大切です。この記事では、速度・引き継ぎ・異常検知・変更への追従・個人情報の観点から、計20項目で自社の状態を棚卸しできるチェックリストを用意しました。「はい」が少ないことは内製をやめる理由にはなりません。どこを決めていないかが分かることが目的です。
この記事でわかること
- 自作の転送を「業務システム」として運用できているかを確認する20項目
- 合計数に頼らないチェック結果の読み方と、次に手をつける順番
- 空欄が多かったカテゴリ別に、何が起きやすいか
- これから内製する場合に、作る前に決めておくべきこと
なぜコードではなく運用を見るのか
答え: 生成AIを使って転送のコードを用意できても、動き始めたあとの保守や確認は必要です。
仕組みが止まっても反響メールが届き続ける場合、チャットに来ていないことに誰かが気づくまで、対応漏れが増えるおそれがあります。ポータル側のメール形式の変更に解析処理が対応していなければ、項目を取得できなくなることがあります。保守担当が作った本人だけで引き継ぎがなければ、異動後の修正が難しくなります。
こうした問題には、コードの設計と運用体制の両方が関わります。以下の20項目は、その中で「決めていないこと」を洗い出すためのものです。
A. 速度と要件
答え: 技術の選択より先に、業務として許容できる遅れを決めてください。ここが決まっていないと、作ったあとに方式の見直しが必要になることがあります。
| # | 確認項目 |
|---|---|
| A-1 | 「何分以内に届けばよいか」を業務として決めている（感覚ではなく基準として） |
| A-2 | 現在の仕組みが、実際に何分で届いているかを測ったことがある |
| A-3 | 定期確認（時刻トリガー）で足りる業務か、受信を契機にした通知が必要な業務かを区別している |
| A-4 | 繁忙期に件数が増えたとき、処理が間に合うかを確認している |
Apps Script の時刻トリガーは、最短で1分間隔の定期確認です。メール受信そのものを契機にする方式とは異なり、実行時刻も多少ずれます（Google公式: インストール可能なトリガー）。Gmailで受信を契機に通知する場合、Gmail API と Cloud Pub/Sub によるプッシュ通知が選択肢になります。ただし通知の到着時間は保証されず、遅延・欠落に備えた定期的な同期処理も必要です（Google公式: プッシュ通知）。また Apps Script には実行時間などの上限があるため、見込み件数で確認してください（Google公式: 割り当て）。
B. アカウントと引き継ぎ
答え: 「コードを共有してある」ことと「引き継げる」ことは違います。
| # | 確認項目 |
|---|---|
| B-1 | 仕組みが動いているアカウントが、個人のものではなく組織で管理するアカウントになっている |
| B-2 | スクリプトやコードが共有ドライブ等に置かれ、複数人が開ける状態になっている |
| B-3 | 作った本人以外に、中身を読んで直せる人が社内にいる |
| B-4 | 担当者が異動・退職するときに、誰へ何を引き継ぐかが決まっている |
時刻トリガーは作成者のアカウントで動作します（Google公式）。個人アカウントのまま運用していると、その個人に紐づいた仕組みになります。コードの共有に加え、後任アカウントでのトリガー再作成、必要な権限・認証の設定、動作確認、旧トリガーの停止まで引き継ぎ手順に含めてください。
C. 異常の検知と復旧
答え: 停止を見逃すと影響が広がる業務では、異常検知を優先してください。個人情報の共有範囲などに重大な問題があれば、そちらを先に是正します。
| # | 確認項目 |
|---|---|
| C-1 | 処理が失敗したときに、誰かへ自動で通知が届く（実行履歴を見に行かなくても気づける） |
| C-2 | 「転送が止まっていること」に、何時間以内に気づけるかの見込みがある |
| C-3 | 止まったときの復旧手順（調べる場所・再実行の方法）が文書になっている |
| C-4 | 復旧を担当する人と、その人が不在のときの連絡先が決まっている |
失敗時に管理者へ通知を送る処理は、仕組みの一部として最初から検討しておきましょう。詳しくはエラーに気づけず反響を取りこぼすでも整理しています。
D. 変更への追従
答え: 保守の負担はコード量だけでなく、変更の頻度にも左右されます。利用先の変更に、誰がどう対応するかを決めておきましょう。
| # | 確認項目 |
|---|---|
| D-1 | ポータルサイトのメール形式が変わったことに気づける仕組みがある（取得できなかった項目の検知など） |
| D-2 | 形式が変わったときに、誰が調べて直すかが決まっている |
| D-3 | 直したあと、取りこぼした期間の反響をどう追いかけるかが決まっている |
| D-4 | 利用しているAPIやサービスの仕様変更・終了の告知を、誰かが追っている |
Gmail API のプッシュ通知を使う構成の場合、監視の登録（watch）を7日以内に呼び直す必要があり、Googleは1日1回の更新を推奨しています（Google公式: プッシュ通知）。この更新処理自体が止まっていないかも、確認の対象に入ります。
E. 個人情報とセキュリティ
答え: 転送のついでに控えたスプレッドシートが、気づかないうちに個人情報の台帳になっていることがあります。
| # | 確認項目 |
|---|---|
| E-1 | 反響メールの本文やファイルを、どこに残すか（残さないか）を決めている |
| E-2 | 残す場合、保持期間と削除の方法が決まっている |
| E-3 | 残したデータを誰が見られるかを把握している（スプレッドシートの共有範囲を含む） |
| E-4 | チャットのWebhook URLやAPIキーがコード内に直接書かれておらず、閲覧できる人を限定している |
この観点は専用サービスを選ぶときの確認項目にもなります。何を・どれだけの期間持ち、いつ消すのかを提供元に確認してください。自作の場合は、同じことを自分たちで決めて記録しておく必要があります。
採点と読み方
「はい」の数は、未整備の項目を把握する目安です。合計数だけで運用継続の可否や、専用サービスへの移行を判断しないでください。未整備の内容、停止時の影響、社内の改善・復旧体制を確認します。
| 確認すること | 読み方 | 次の一手 |
|---|---|---|
| 未整備の項目の内容 | 「はい」が多くても、異常検知や個人情報管理などに重要な問題が残る場合があります | 空欄ごとに業務への影響を確認してください |
| 停止時の影響 | どの項目から対応するかは、停止を見逃した場合や復旧が遅れた場合の影響によって変わります | 影響の大きい項目を優先し、個人情報の共有範囲などに重大な問題があれば先に是正してください |
| 改善・復旧の体制 | 未整備の項目が多くても、社内で改善できる場合があります | 担当者と対応手順を決め、内製継続や外部サービスの利用を検討してください |
空欄が多かったカテゴリ別の意味は次のとおりです。
| 多かったカテゴリ | 示していること |
|---|---|
| A | 速度の要件や実測の確認が不足している可能性があります。方式が業務に合っているか確認が必要です |
| B | 属人化している可能性があります。引き継ぎや複数人での保守がなければ、担当者の交代後に修正・復旧が難しくなります |
| C | 停止を見逃したり、復旧が遅れたりする可能性があります。停止時の影響に応じて優先してください |
| D | 形式・仕様の変更に対応できず、項目の取得や転送に支障が出る可能性があります |
| E | 個人情報の保存・共有・削除のルールが未整備の可能性があります。実際の管理状況を確認してください |
よくある質問
点数が低いと、内製をやめるべきということですか
違います。空欄は「決めていないこと」であって、「できないこと」ではありません。B・C は設計と運用ルールで改善できます。未整備の内容と停止時の影響を確認したうえで、内製を続ける判断も、一部の業務に外部サービスを利用する判断もあり得ます。
これから作る場合、どこから決めればよいですか
A（速度の要件）が先です。ここで方式が変わるため、後から決めると作り直しになることがあります。次に B（誰のアカウントで動かすか）、C（失敗にどう気づくか）です。これらを決めてから書き始めると、あとで整える手間を減らしやすくなります。方式A・方式Bの具体的な作りの違いは反響メールのチャット転送をGASで自作する方法｜判断の基準で解説しています。
全部を専用サービスに置き換える必要がありますか
ありません。すべてを内製するか、すべてを外に出すかの二択ではありません。利用条件や対応範囲が合う場合には、停止時の影響が大きい業務に外部サービスを利用し、それ以外は自作のまま運用する、という分け方もできます。
自作のリスクをもっと詳しく知りたい
反響対応をAI+GASで自作する前に確認すべき4つのリスクで、メール形式の変更・属人化・エラー監視・個人情報の観点を個別に整理しています。
まとめ
このチェックリストは、内製をやめさせるためのものではありません。すべてに「はい」と答えられても、それだけで運用に問題がないとは判断できません。未整備の内容、停止時の影響、社内の改善・復旧体制を合わせて確認してください。
少量のメールを単一チャネルへ転送し、メール形式が単純で、定期確認による遅れを許容でき、保守・復旧体制がある場合はGASも選択肢です。自社の条件に合わせて処理を調整できる利点があります。
停止を見逃すと影響が広がる業務では、C（異常の検知）を優先してください。ここが空欄なら、専用サービスを検討する前に、失敗時の通知を整えることが改善の一歩になります。ただし、個人情報の共有範囲などに重大な問題があれば、そちらを先に是正しましょう。
反響メールの転送をサービスに任せたい場合
Mail2Link はポータルサイト等の反響メールを LINE WORKS・LINE・Chatwork へ転送するサービスです。タイトル・本文・送信元等による転送条件を設定できます。添付ファイル連携はオプションです。対応媒体・必要な機能・利用条件を確認してください。無料プランでも動作を確認できますが、転送通数に上限があります。
—
この記事を書いた会社
7plus株式会社 不動産会社向けの営業DX支援を行うITソリューションプロバイダーです。反響対応を即時化する「Mail2Link」「Mail2Link×AI」、ノーコード業務アプリ「BizBlock」の開発・提供に加え、Salesforce認定パートナーとして不動産特化型Salesforceパッケージの導入・定着コンサルティングも行っています。
詳しくはこちら → https://7plus.jp/
