メール添付ファイルを自動でフォルダに保存し、名前をそろえる方法

先に知っておく、ツール側の動き

ルールを決める前提として、公式ドキュメントで確認できた範囲を整理します(2026年10月27日時点で閲覧した内容です)。

• Zapier:Gmail の「New Attachment」トリガーは、添付1件ごとに実行されます。複数の添付がまとめてZIPになる場合は、このトリガーに切り替えるよう案内されています(Common Problems with Gmail on Zapier)。また同社の Gmail 紹介ページでは、このトリガーの検知は「1 hour」と記載されています(How to get started with Gmail on Zapier)。
• Make:公式の解説では、Gmail の Watch Emails、Iterator、Google Drive の Upload a File の構成で、1通に複数の添付があっても Iterator が1件ずつ処理するとされています。確認間隔も設定します(Make:Gmail添付をGoogle Driveに保存)。
• n8n:Gmail Trigger はポーリングで動き、1回に取得する件数は初期値10件、最大50件です。既定では未読メールだけが対象です(Gmail Trigger)。Google Drive のアップロードでは、ファイル名・親フォルダなどを指定しますが、同名ファイルが既にある場合の挙動は、このドキュメントには書かれていません(Google Drive File operations)。

つまり「同名が来たらどうなるか」は、ツール任せにせず自分のルールで防ぐ必要があります。保存先によっては同名ファイルが並んで保存される場合もあれば、置き換わる場合もあるため、最初にテスト用フォルダで確かめてください。

ファイル名ルールの例

基本の形

次の形を提案します。

{受信日}_{送信元の略称}_{メール識別子}-{添付番号}_{元のファイル名}.{拡張子}

説明用の例:

20261027_abc商事_a1b2c3-01_請求書.pdf
20261027_abc商事_a1b2c3-02_請求書.pdf
20261028_abc商事_d4e5f6-01_請求書.pdf

「請求書.pdf」が何度届いても、受信日・メール識別子・添付番号のどれかが違うので重なりません。メール識別子は、ツールが返すメールIDの先頭6〜8文字などで十分です。

決めておく部品

• 受信日、決め方：YYYYMMDD(例:20261027)、理由：名前順に並べると時系列になる
• 送信元の略称、決め方：アドレスのドメインから変換、不明なら unknown、理由：空欄でアンダースコアが連続するのを防ぐ
• メール識別子、決め方：メールIDの先頭数文字、理由：同日・同送信元でも別メールを区別できる
• 添付番号、決め方：2桁(01、02…)、理由：1通に同名が2つあっても区別できる
• 元のファイル名、決め方：残す。ただし記号を置換、理由：後で内容を探しやすい

使えない文字と長さの扱い

元のファイル名には、保存先で問題になる文字(/ \ : * ? " < > | など)や、極端に長い名前が来ることがあります。次のように決めておくと安全です。

• 使えない文字は _ に置き換える
• 元のファイル名は40文字程度で切る(拡張子は切らない)
• 拡張子は小文字にそろえる
• 拡張子が無い場合は .unknown を付け、「要確認」に回す

保存先フォルダの設計

自動化が触るフォルダは最小限にします。

添付受信/
├─ 01_未確認/
│   ├─ 2026-10/
│   └─ 2026-11/
├─ 02_確認済み/      ← 人が移動する(自動化は触らない)
└─ 99_要確認/        ← 名前や形式が想定外のもの

ポイントは3つです。

• 自動化は 01_未確認 の月フォルダにしか書き込みません。 取引先別・案件別のフォルダへ自動で振り分けると、送信元の判定ミスがそのまま誤配置になるためです。慣れてから、判定が安定したものだけ振り分けを足してください。
• 月フォルダは自動作成にするか、月初に手動で作ります。 作り忘れると保存に失敗するので、どちらにするかを決めておきます。
• 99_要確認 を用意します。 拡張子なし、極端に大きい、想定外の形式(.exe など)は、ここに入れるか保存せず記録だけ残します。

同名ファイルが来たときの決め方

上のファイル名ルールなら、同名の衝突はほぼ起きません。それでも、次のような場面ごとに扱いを先に決めておきます。

• 別日に同じ名前(請求書.pdf)が届いた、推奨の扱い：受信日が違うので両方残す、人が確認すること：最新版がどれか
• 同じメールに同名の添付が2つ、推奨の扱い：添付番号で区別して両方残す、人が確認すること：内容が本当に別物か
• 同じメールがポーリングで二重に処理された、推奨の扱い：記録の「メールID+添付番号」が既にあれば保存しない、人が確認すること：記録の重複行
• 「修正版」「再送」と書かれている、推奨の扱い：上書きせず、別名で残す、人が確認すること：古い版を破棄してよいか
• 保存先に既に同じ名前がある(想定外)、推奨の扱い：保存を止めて 99_要確認 に別名で保存、人が確認すること：原因(ルール漏れ)

原則は自動化に上書きを許さないことです。古い版の削除は、人が判断して行います。

取りこぼしを防ぐ記録と点検

名前を整えても、そもそも保存されなければ意味がありません。取りこぼしの典型的な原因は、ポーリング間隔と取得件数の上限、既読メールが対象外になる設定、フィルタ条件の見落としです。たとえばn8nの既定は未読のみ・1回10件なので、人が先にメールを開いて既読にした場合や、短時間に大量に届いた場合は注意が必要です。

保存記録(スプレッドシート)の列

保存のたびに1行追加します。

• 処理日時、説明用の例：2026-10-27 10:05
• メールID、説明用の例：a1b2c3…
• 添付番号、説明用の例：01
• 元のファイル名、説明用の例：請求書.pdf
• 保存名、説明用の例：20261027_abc商事_a1b2c3-01_請求書.pdf
• 結果、説明用の例：成功 / 失敗 / 要確認

週1回の点検

• 受信箱で「添付あり」のメール件数を検索し、記録の行数(メール単位)と比べる
• 「失敗」「要確認」の行を見て、99_要確認 の中身と合わせて整理する
• 差があるときは、ツールの実行履歴でエラーの有無を確認する

AIに任せる部分と、人が確認する部分

AIは、ルール案の作成とテストデータの用意に向いています。実際のメールや取引先名は渡さず、架空の値に置き換えてください。依頼文の例です。

次の条件で、メール添付の保存ルールを検証したいです。
ファイル名の形式:
{受信日YYYYMMDD}_{送信元略称}_{メール識別子6文字}-{添付番号2桁}_{元のファイル名40文字まで}.{小文字の拡張子}
使えない文字は _ に置換します。

架空の添付ファイル名を20件作り、
・保存名に変換した結果
・同名になってしまうケース
・ルールが想定していないケース
を表にしてください。
次を必ず含めてください:同じ名前が別日に届く、同じメールに同名が2つ、
日本語と記号入り、拡張子なし、長い名前、大文字の拡張子。

AIの返した表は、そのまま信じず、次を人が確認します。

• 変換結果が、自分のルールどおりか(日付の形式、番号の桁など)
• 本番と同じ保存先で、テスト用の添付を実際に送って保存できるか
• 同じメールを2回処理させても、二重保存にならないか

最初の1週間の進め方

1. テスト用フォルダとテスト用メール(自分宛て)を作る
2. 上のルールで、同名添付2つ・日本語名・記号入りのメールを自分宛てに送る
3. 保存名と記録の1行を目で確認する
4. 問題なければ本番の 01_未確認 に切り替え、1週間は毎日、記録と受信箱を見比べる

この1週間で見つかったルール漏れを、命名ルールの表に1行ずつ足していけば、運用に耐える形になります。