メールは、どの組織にもすでに存在する共通の連携手段です。仕入先は請求書を送り、フォームは送信内容を届け、機器はアラートを発します。メール取り込みでは、それを面倒な作業ではなくインターフェースとして扱います。スクリプトがメールボックスへ接続し、届いた内容を読み取って処理します。
これは古くからあるものの、過小評価されている方法です。すべての取引先に自社APIへの対応を求めるという代替案は、通常は実現できません。この記事では、適した用途、壊れにくい構成、Webhookを選ぶべき場面を説明します。
IMAPによるメール取り込みが役立つ用途
送信元が直接システムと連携しない、または連携できない場面で、メール取り込みが役立ちます。
取引先から届く書類。請求書、発注書、納品書、取引明細などが添付ファイルとして届きます。送信元の企業が自社システムに合わせた連携を開発することはないでしょう。送信者と管理番号を基に書類を保存するスクリプトだけで、必要な連携が完成することも珍しくありません。
機器からのアラート。バックアップ装置、監視システム、古い産業機器など、メール以外の送信手段を持たないハードウェアは数多くあります。IMAPでメールを取り込めば、すべての通知を一か所で受け取れます。
フォームの送信内容と返信。構造化されたメッセージをメールで送るものなら対象になります。処理したいバウンス通知や不在時の自動返信も含まれます。
返信による承認。メールに「承認します」と返信することも、業務フローの一つの段階です。その返信をプログラムで読み取るほうが、誰もログインしたがらない画面を作るより簡単な場合があります。
壊れにくい仕組みにする
メール取り込みの動作自体は単純です。長く安定して動かせるかどうかは、いくつかの設計判断で決まります。
専用のメールボックスを用意する。誰かのメールボックス内のフォルダーや、同じメールを人が読む共有環境は使わないでください。専用アドレスなら、人が整理したことでスクリプトの前提が崩れる心配がありません。TrekMailではユーザー単位の料金がないため、追加費用もかかりません。
処理専用の認証情報を使う。個人のログイン情報は使用しません。スクリプトの認証情報が漏れたり、更新が必要になったりしても、影響はその処理だけに限定されるべきです。
処理済みのメールは削除せず移動する。「処理済み」フォルダーがあれば監査履歴が残り、不具合の修正後に再処理できます。削除すると、すべてのミスが取り返せなくなります。そしてミスは必ず起きます。
同じメールが2回届いても正しく扱う。再試行、再接続、再処理は必ず発生します。Message-IDをキーにして、処理済みのメールを飛ばすようにすれば、重複はデータ障害ではなく、何も行わない処理になります。
停止を明確に通知する。スクリプトがメールボックスを読まなくなっても、誰かが請求書の行方を尋ねるまで気づけません。エラーが発生したときだけでなく、一定時間実行されていないときにも通知する必要があります。
IMAPが適している理由
メール取り込みにIMAPを使うのは、単なるダウンロード用プロトコルではなく、メール用の本格的なリモートファイルシステムとして機能するからです。
サーバー側で検索し、本文を取得するか決める前にヘッダーだけを読み、メールをフォルダー間で移動し、フラグを設定できます。メールボックス全体をダウンロードする必要はありません。必要なものだけを低コストで処理でき、何年分もの履歴があるメールボックスでは特に有効です。
最大の利点は、どこでも利用できることです。あらゆるプログラミング言語にライブラリがあり、既存の実装を壊すようなプロトコル変更もありません。今日書いたスクリプトが10年後も動くでしょう。多くのベンダーAPIより確かな見通しです。
無料プランにもIMAPが含まれるため、受信専用の取り込みメールボックスなら費用は一切かかりません。ただし送信はできません。プログラムから返信する場合は、有料プランまたは専用のSMTPプロファイルが必要です。
運用にかかるコスト
多くの人が想像するより小さいため、運用費用は意外に感じられるでしょう。
取り込みに使うのは通常のメールボックスで、個別課金ではなくプランごとの上限が適用されます。12個目の取り込みアドレスを追加しても限界費用はありません。だからこそ、送信元ごとに1つのメールボックスを割り当てても、無駄ではなく現実的な構成になります。実際に消費するのは共有ストレージと、問題発生時に対応する手間です。
ユーザーごとに課金するサービスと比べると、設計上の判断も変わります。そのようなサービスでは、新しいアドレスのたびに費用が増えるため、複数のメールフローを1つの過密なアドレスに集めがちです。スクリプトは無関係な複数の流れを後から分離しなければなりません。TrekMailでは、最も安い構成が同時に最も分かりやすい構成になります。
Webhookを選ぶべき場面
適用範囲を明確にしておけば、用途に合わない仕組みを作らずに済みます。
取引先がWebhookを提供しているなら、それを使ってください。遅延、信頼性、分かりやすさのどれを見ても、ポーリングよりプッシュが優れています。次のポーリング時に発見して文章を解析するのではなく、何かが起きた時点で構造化されたデータを受け取れます。メール取り込みは、こうした選択肢がない場合の代替手段です。
ポーリングには適切な間隔があります。1分ごとの確認なら問題ありませんが、1秒ごとは過剰で、レート制限の対象になります。本当のリアルタイム処理が必要なら、読み方にかかわらずメールは適切な通信手段ではありません。
人が書いたメールの解析も安定しません。機械が生成したメッセージから発注番号を取り出す処理は信頼できますが、人が入力した文章から意図を判断することはできません。それに依存する業務フローでは、誰にも完全には直せない失敗が少しずつ発生し続けます。
複数のメールボックスへ拡張する
メール取り込みは拡張しやすく、適した構成はメールフローの数によって変わります。
送信元が少ない場合は、送信元ごとにメールボックスを用意するのが最も明確です。各スクリプトが専用アドレスを読み、1つの変更がほかに影響することもありません。メールボックスは個別課金ではなくプランごとの上限で管理されるため、20個の取り込みアドレスでも1個と同じ料金です。
同じ種類の送信元が多数ある場合は、catch-allアドレスの後ろに1つのメールボックスを置く方法が適しています。invoice-acme@やinvoice-globex@を同じ場所で受け取り、アドレス自体をスクリプトの振り分け情報として使います。これは登録先ごとにエイリアスを用意する方法と同じ仕組みを、ベンダーではなく機械に応用したものです。
本当に大量のメールを扱う場合は、ストレージが共有される点を忘れないでください。添付ファイルが増え続ける取り込みメールボックスは、共有容量を消費します。後で問題に気づくのではなく、最初から容量制限と保存ポリシーを設計に含める必要があります。詳しくは、メールボックスのストレージ容量制限で説明しています。
