AIでGmail添付ファイルを自動保存する方法｜受信から整理までつなぐ

Gmail添付の自動保存は、AI分類から始めず「対象メールを絞る→添付を取得する→保存先へ格納する→処理済み状態を記録する」順に設計します。保存漏れや重複は、分類の賢さより対象条件、message ID、再実行の扱いで防ぎます。最初は狭い条件で保存経路を試し、必要になってからファイル名整理やAI分類を追加してください。

自動化の対象を決める

どのメールの添付を保存するかを先に定義します。送信元、件名の語、Gmail label、添付の有無、受信期間などを組み合わせます。差出人が表示名だけで変わる場合や、同じ送信元から請求書と広告が来る場合は、subjectやlabelなど補助条件も必要です。filterを広くして全添付を保存すると、不要資料や個人情報までDriveへ複製するおそれがあります。

添付fileだけを残すのか、メール本文、受信日時、送信元、message IDも記録するのか決めます。後から元のメールへ戻る必要がある業務では、Driveのファイルと元メールを結ぶIDを保存します。保存先folderのアクセス権がメールboxより広くないか、社内共有設定も確認してください。

表は横にスクロールできます

条件	例	例外
Sender	登録済み取引先	表示名でなく実address確認
Subject / label	請求書、申請受付	件名は送信者が変えられる
Attachment	fileありのみ	inline imageの扱い
保存先	取引先別folder	folder権限の継承
命名	受信日_送信元_元file名	同名衝突時のrule

Makeで組む最小Workflow

MakeのGmail modulesは条件でメールを検索し、添付があるメールを選ぶ設定を提供します。Google Drive modulesにはUpload a Fileがあり、MakeのWorking with files説明ではGmail attachmentをDriveへ渡す例が案内されています。実際のmodule名、表示フィールド、connection条件は変更されるため、利用時に現行Apps Documentationを確認してください。

1. Gmail watchまたはsearchを使い、対象条件と添付有無を絞る。

2. メール本文ではなく、まずmessage IDとattachment metadataを取得する。

3. MIME typeとファイル名を確認し、対象外形式やサイズ条件を除外する。

4. Driveの決めたfolderへ、元file名と受信情報を含む名前でuploadする。

5. upload成功後にDrive file ID、message ID、attachment ID、保存時刻を処理台帳へ記録する。

6. 不明なfileは隔離folderまたは要確認queueへ送る。

同じ処理をApps Scriptや別のautomation platformで作る場合も、Gmailのsearch/watch、添付取得、Drive upload、状態記録の4役を分けます。Makeの用語をそのまま他サービスの機能名へ置き換えず、実際のtriggerが新着を検出する方式と再取得条件を確認します。

重複と再実行を制御する

Scenarioが失敗して再実行されたとき、同じ添付を別fileとして保存しない設計が必要です。message IDだけでは一通のメールに複数添付がある場合を区別できないため、attachment IDやファイル内容hash、業務上の書類番号を組み合わせます。ファイル名が同じだけで重複と判断すると、異なる月の請求書を誤って上書きすることがあります。

状態はpending、saved、error、needs_reviewなどに分けます。Drive uploadが成功し、保存先のfile IDを確認できた後にsavedへ更新します。保存前に処理済みを記録すると、途中失敗で取りこぼしが起きます。逆に保存直後、台帳の書き戻し前に失敗する場合もあるため、再実行時にDrive側を検索して既存fileを確認する方法を検討します。

表は横にスクロールできます

状態	条件	再実行時
pending	まだuploadしていない	対象として処理
saved	Drive file IDを確認済み	再保存を抑止
error	uploadや記録に失敗	原因とattemptを確認
needs_review	条件が不明、想定外形式	人が判断

ファイル名と保存先

元の添付名は監査や照合に必要なため、置き換える場合も台帳へ残します。安全な命名例は「受信日_取引先識別子_元名」のような形式ですが、日付は受信日・文書日・請求日のどれか明示します。ファイル名に個人名やメールaddressを含めると、Driveの一覧やURLで不用意に露出する可能性があります。

同名衝突のときは、既存ファイルを上書きするか、別名保存するかを業務側が決めます。請求書や契約書のように記録性が必要な資料は、無条件上書きしない方が追跡しやすいです。保存後に元メールを削除・移動・既読化する場合は、保管処理の成功確認とは別の承認済みruleにしてください。

個人情報と機密ファイル

添付は請求書、履歴書、医療資料、契約書などを含む場合があります。automation serviceへ渡すデータ、保存先の共有範囲、保持期間、削除責任者を確認します。AIで分類を加える場合は、添付本文をどのserviceへ送るか、契約やworkspace設定で許可されているか確認し、必要な範囲だけを処理します。AI分類の誤りで機密ファイルが広いfolderへ移動しないよう、曖昧な分類は自動振り分けせず人へ回します。

導入前テスト

最初にtest mailboxとtest folderを使い、対象メール、対象外メール、複数添付、同名file、空添付、upload失敗、再実行を確認します。実際の顧客メールを使う前に、外部共有・通知・既読化・削除の副作用がないかreviewします。

• 対象条件に合う添付だけ保存されたか。

• 添付数、ファイル名、MIME typeが記録されたか。

• retryで二重保存または上書きが起きないか。

• 保存先のpermissionが元メールの情報範囲に合うか。

• failure時にerrorを見つけ、再処理できるか。

• AI分類を止めても元添付の保存が続くか。

本番へ移す前に、処理件数と保存容量を小規模な期間で確認します。何件を超えたら停止するか、誰がerror queueを見るかも決めてください。

AIものさしの判断

必要なのが添付の保管なら「Trigger→Filter→取得→Upload→ID記録」から始めます。保存が安定してから、明確な分類価値がある場合だけAIを足します。曖昧な分類や機密資料は人の確認へ回し、AIが止まっても受信記録と元添付が失われない設計にしてください。

保存先を先に決める

メールを検知する前に、保存するDriveの共有ドライブまたはfolder、閲覧できる人、保持期間を決めます。個人のマイドライブへ保存すると、担当変更やアカウント停止時に引き継げない場合があります。組織で使うなら所有者とアクセス範囲を管理者と合わせ、顧客資料や本人確認書類などを広い共有folderへ流さないようにします。Makeのfile処理はファイル名とデータを次のmoduleへ受け渡す方式です。元名を残す場合も、個人名などをファイル名に含める必要があるか検討してください。

具体的な処理契約

表は横にスクロールできます

項目	保存する値	再実行時の扱い
mail_key	Gmail message ID	同じIDなら処理済みを参照
attachment_key	attachment IDまたは安定した識別子	mail_keyと組み合わせて重複確認
source	sender、受信日時、label	保存先の監査情報
destination	Drive folder ID、file ID	成功後に記録
status	pending / saved / error	errorは再試行可能にする

「同じファイル名だから重複」とは限りません。同じ取引先が毎月同名の請求書を送ることもあります。逆に、同じmessageを再取得して名前末尾へ連番を付け続けるのも避けたいところです。重複判定はmessageとattachmentの識別子を軸にし、必要ならファイル内容のハッシュを追加します。ハッシュを使う場合も、別案件で同じ内容の書類を意図的に保管する業務では、内容一致だけで破棄しないルールが必要です。

小さく試す手順

1. 自分宛てのテストメールを1通送り、対象条件が通ることを確認する。

2. 添付なしのメールを送り、保存処理に入らないことを確認する。

3. 2ファイル添付のメールで、元名とfile数が一致するか確認する。

4. 同じメールを再実行し、既存fileを重複保存しないことを確かめる。

5. 保存先への権限を一時的に失敗させ、error状態と再試行方法を確認する。

本番投入前には、通常のPDFだけでなく、同名file、拡張子の異なる画像、サイズ上限を超えるファイルも境界ケースとして扱います。Makeの最大file sizeは契約planによって異なるため、現在のplan表示を確認してください。上限超過を許容する設定やエラー時の処理は、保存漏れにつながらないよう決めます。

個人情報と運用監視

添付は本文より多くの個人情報を含むことがあります。scenarioの履歴にfile dataや本文をどこまで残すか、接続アカウントの権限、共有リンクの既定値、失敗ログの閲覧者を確認します。不要なpreviewやAI分類用コピーを長期間保持しないようにします。毎日見る指標は「検知件数」「保存成功件数」「error件数」「処理待ち件数」で十分です。errorを通知して終わりにせず、誰が何営業日以内に再処理するかを決めて初めて保管業務として閉じます。