メール受信からの自動取込パイプライン設計

はじめに

FAX注文をAIで読み取る仕組みの話をすると、みなさん「AIがどう読むか」に興味を持たれます。でも実は、その手前にある**「届いたFAXをどうやって漏れなく拾うか」**の土台こそが、地味だけれど一番大事なんです。

この記事では、FAX複合機からメール転送されてくるPDFを、定期実行で自動取得する取込パイプラインの設計を解説します。読み取りAIに渡す「前工程」の話です。

FAXがメールになって届く

複合機がPDFを転送する

最近のFAX複合機には、受信したFAXを画像PDFにしてメールに添付し、指定アドレスへ転送する機能があります。これを使うと、紙で出力される前のFAXがそのままデジタルデータとして手元に届きます。

つまり受注担当の目の前にあるのは、もう「紙のFAX」ではなく「PDFが添付されたメール」です。ここが自動化のスタート地点になります。紙を触らずに済むというだけで、処理の可能性が一気に広がるんですよね。

受信専用ボックスに集約する

転送先には、FAX受信専用のメールアドレスを1つ用意しました。取引先からのFAXがすべてこの1箇所に集まるようにしておくと、監視すべき場所が1つで済みます。

通常業務のメールと混ざらないよう分離しておくのもポイントです。専用ボックスにしておけば、「ここに届いたものは処理対象」とシンプルに扱え、後段のロジックが余計な条件分岐を持たずに済みます。

ポーリングによる取得設計

Gmail APIで受信箱を見に行く

メールの取得にはGmail APIを使います。「新着メールが来たら通知（プッシュ）」ではなく、こちらから定期的に「未処理のメールはある？」と見に行くポーリング方式を採用しました。

なぜプッシュではなくポーリングか

プッシュ通知は「即時性」では優れますが、通知の設定管理や、通知を取りこぼしたときの扱いが複雑になりがちです。FAX受注は秒単位の即時性を求められる業務ではありません。

数分の遅れは実務上まったく問題にならないので、シンプルで壊れにくいポーリングを選びました。5分間隔のCronで見に行くだけ。仕組みが単純なぶん、動作を追いやすく、障害の原因も特定しやすいという利点があります。

処理済みの管理

同じFAXを二重に取り込まないための管理は必須です。この仕組みでは、処理が終わったメールにラベルを付けて「処理済み」と印を付け、次回のポーリングでは未処理のものだけを対象にしています。

ラベルという形で状態をGmail側に残しておくと、仮にパイプラインが途中で止まっても、再実行したときに続きから拾えます。状態を自前のDBだけで持たず、メール自体にも残しておくのが、取りこぼしを防ぐコツです。

壊れにくくするための工夫

冪等性を意識する

定期実行の仕組みでは、同じ処理が二度走っても結果が壊れないこと、いわゆる**冪等性（べきとうせい）**が大事です。ネットワークの一時エラーやタイムアウトで、途中まで進んだ処理が再実行されることは普通に起きます。

そこで「このメールは処理済みか」を必ず最初に確認し、済んでいればスキップするようにしています。二重書き込みを防ぐこの一手間が、深夜に無人で動く仕組みの信頼性を支えています。

失敗を握りつぶさない

PDFが壊れている、添付が想定外の形式、といった例外は必ず起きます。ここで処理全体を止めてしまうと、後続の正常なFAXまで滞ってしまいます。

そこで1件ずつ独立して処理し、失敗したものは「エラーとして記録」して次へ進む設計にしました。あとで人がエラー一覧を見て対応できるようにしておく。失敗を静かに握りつぶさず、見える形で残すことが運用では効いてきます。

まとめ

メール受信からの自動取込パイプラインの設計を解説しました。

1. FAXはメールで届く：複合機のPDF転送で、紙を触らずデジタル処理の入口に立てる
2. ポーリングで拾う：即時性より単純さを優先し、5分間隔のCronで漏れなく取得する
3. 壊れにくく作る：冪等性を意識し、失敗は握りつぶさず記録して次へ進む

この土台があって初めて、AIによる読み取りが安定して回ります。次は、取り込んだPDFをどう構造化データにするのか、「LLMによる帳票の構造化データ抽出」で解説します。全体像は「FAX受注のAI-OCR自動取込」をご覧ください。