SendGrid依存からの脱却
メール配信サービスとして市場で存在感を持つSendGridの一つの機能として、Inbound Email Parse Webhookという機能があります。指定したメールアドレスに届いたメールの内容をWebhookとして指定のURLにPOSTしてくれる機能ですが、非常に便利なため、利用している方も多いのではないでしょうか。実際、ショッピングモールから届く注文メールをWebhook通知させてシステムに取り込んだり、問い合わせメールを各種チャットツールへ投稿させたりといった、様々な使い方が可能です。
一方で、SendGridのシステムが不安定な際や、仕様変更等の影響を直接的に受けるため、依存することへのリスクが常に存在するのも事実です。外部要因はコントロールできないため、事業の拡大に伴ってそのリスクが大きくなることが予想されたため、代替機能として開発がスタートしました。
SendGrid書式に準拠することで移行コストを低減
既存のSendGrid Inbound Email Parse Webhook連携のシステムが軽微な修正で移行できるよう、POSTされるデータ形式はSendGrid書式のものをベースにし、機能上不要なものは削ぎ落とすことで見通しを改善。取り込みたいメールの送信先（転送先）を変更するだけで既存システム側は何も変更しなくても問題ないように配慮しました。
扱いが難しい添付ファイルについても、正確かつ適切に処理できるように配慮。セキュリティ面にも気を遣いながら、「届いたメールをそのままWebhookで通知する」という一見簡単そうに見えて当たり前に思えるけれど非常に難しいことを実現しています。POSTするデータ形式は将来的に複数用意できるように考慮し、Sendgrid書式以外の独自書式実装が必要になった際の設計上の負荷を軽減しています。
リトライ処理やスパム機能の組み込み
加えて、Webhookの受け手側システムが不調の場合に失敗することを考慮し、Webhook送信のリトライ処理を実装。失ってしまっては困るメール内容も、リトライできることで、確実に受け手側のシステムで処理できる状態を実現しています。リトライ処理は一定時間間隔で自動リトライする機能に加え、急ぎの場合などに手動でリトライ処理を実行できる機能も実装。様々なユースケースに対応できるように配慮されています。
また、メール転送側でスパムメールを絞れない場合を考慮し、スパム対策機能も追加。特定条件に合致する/しないメールについてはWebhook通知を行わないようにできるため、特定の件名の注文メールのみ処理に回す、といったことや、NGワードが含まれるものは迷惑メールとして無視して処理しない、といったことが行えるようになっています。
Slack、Chatwork通知への展開も視野に
SendGrid依存からの脱却が主目的だったため、構築当初はシンプルに、届いたメールに対してWebhook送信を行うという構成で構築。ただ、今後、届いた内容を直接Slackに通知したり、Chatworkに通知したりといった機能拡張が行えるように、あらかじめ設計上の考慮を行っています。
他にも、特定条件に応じた前処理や、集計レポート機能といった拡張も可能なため、単なるWebhook送信機能にとどまらない展開も可能です。メール処理は処理量も多くなりがちで、システム負荷が高くなりがちです。システムの安定運用のための負荷管理、運用監視を行う仕組みづくりも同時に行っています。
こういったお悩みをお持ちであればご相談ください
メール連携のシステムを構築したい
メール以外のコミュニケーション手段も発展してきましたが、まだまだメールが情報伝達の主流であることは変わりません。結果通知メールや注文確認メールといった、何かの履歴を残すためのデータはメールで送られてくることが多いため、そうしたメールを起点とした処理を行いたいという方も多いのではないでしょうか。
ショッピングモールに出店されているEコマースであれば注文メールを起点とした在庫処理や注文処理を実装できるでしょうし、顧客サポート部門であれば、問い合わせメールを起点とした問い合わせ対応システムをより高度に実装することもできると思います。他にもメール内容の一部を抜き出してそれを基に処理するということはいくらでも考えうるため、非常に応用範囲の広い分野と言えるかもしれません。
メールをシステムに取り込むことで、情報の一元管理や、プログラムによる前処理、後処理が容易になります。また、様々なツールを組み合わせて対応しているのであれば、一つのシステムで集中的に管理することで業務効率が向上することも見込めるでしょう。
外部サービスの機能を自社システムに組み込みたい
外部サービスを利用することは、スピードが求められる競争環境において非常に有効な手段の一つです。一方で、外部サービスの突然の閉鎖や、システムダウン等、コントロールできない要因に左右されてしまうリスクが存在するのも事実です。また、利用量に応じて費用がうなぎのぼりになるケースも存在します。
自社に開発体制がない場合や、そこまでするほどの費用対効果が見込めない場合は、お金で解決することで多くの場合は問題はありませんが、自社に開発リソースがある場合や、中長期的に費用対効果が望めない場合には、同等の機能を自社システム内に組み込んでしまうことを検討する価値があるでしょう。自分たちでコントロールできる機能にすることで、リスクコントロールが自分たち自身で行えますので、外部要因によりシステムが不安定になったり、最悪の場合停止したりするリスクを低くすることができます。
外部サービスの機能をそのまま移植することも一つでしょうし、自社システムにより便利になるように調整して統合することも有効です。最低限必要な機能の定義からはじめ、より高度な連携はできないかといった視点でアイデア出しをすることをおすすめします。
当社では、メール連携システムの開発を、パートナー企業として支援することが可能です。ご相談はもちろん無料ですのでお気軽にお問い合わせください。
