AI活用

n8nでGmailを自動分類する|誤判定を確認してからラベルを付ける

n8nでGmailを分類するときの構成を、候補作成・人の確認・ラベル付けに分けて解説。誤分類、判定不能、同じメールの再処理を試す入力例を用意しました。

この記事の目次
  1. Gmailの操作と分類の判断を分ける
  2. 分類名と、反映するラベルの対応を固定する
  3. 迷った分類は、ラベルを付ける前に確認へ戻す
  4. ラベルを付ける前に、4種類の入力で確かめる
  5. ラベルが付いても、後続の通知は失敗することがある

n8nでGmailを自動分類するときは、まず分類候補を一覧へ出し、確認した結果だけを元メールへ反映します。初回から返信、削除、アーカイブをつなげず、ラベル付けに範囲を絞ると、間違いを確かめやすくなります。

この記事は、Gmailのメールを分類候補からラベルへつなぐ設計を扱います。分類モデルそのものの精度評価や、すべてのメールを無人で処理する設定は別の課題です。

Gmailの操作と分類の判断を分ける

n8nの公式Gmailノードには、メッセージの取得やラベルの追加・削除などの操作があります。Gmail Triggerで受信を検知し、取得したメールを分類し、承認後にGmailノードでラベルを付ける流れにします。認証方法と操作名は利用する版の画面で確認してください。

Gmail Trigger → メールIDと必要な本文を取得
  → ルール、またはAIで分類候補を作成
  → 許可した分類かを検査
  → 確認待ち一覧へ保存
  → 担当者が承認
  → 元のメールIDへラベルを追加 → 結果を記録

AIを使わず、宛先や定型の件名で判定できるものは条件分岐で処理できます。自由記述をAIへ送るときは、署名や長い引用を必要以上に含めず、業務上送ってよいデータだけにします。

スポンサーリンク

分類名と、反映するラベルの対応を固定する

AIから返った文字を、そのまま新しいGmailラベルとして作らないでください。「見積相談」「請求確認」「確認待ち」のように許可する分類を決め、分類名と既存ラベルIDの対応を管理します。

{
  "message_id": "test-message-001",
  "category": "見積相談",
  "reason": "制作費用の見積もりを依頼している",
  "review_required": true
}

これは分類結果の形式例です。メールIDは取得時の値を処理側で保持し、AIが書いた値で送信先を変更しないようにします。分類が許可した値と一致しなければ、確認待ちとして残します。AIが自分で付けた信頼度だけで、自動反映の可否を決めません。

迷った分類は、ラベルを付ける前に確認へ戻す

例えば合成メールに「請求金額も操作方法も確認したい」と書くと、複数の分類に該当します。どちらを優先するか、複数ラベルへするか、確認待ちにするかを先に決めてください。

AIが返す確信度の数字だけで、分類が正しいと判定しません。代表的な入力、迷う入力、分類外の入力で、期待する分類と実際の結果を並べます。ラベルが付いたことと、判断が正しいことを別に確認します。

ラベルを付ける前に、4種類の入力で確かめる

架空のテスト入力 期待する扱い
「制作の見積もりをお願いします」 見積相談の候補。確認後に指定ラベルを付ける
「請求書の宛名を確認したい」 請求確認の候補。支払先変更や支払いは実行しない
「先ほどの件です」 文脈不足として確認待ち
同じメールIDをもう一度入力 処理済みの状態を確認し、通知や一覧行を重複作成しない

この表は正解を用意したテスト例で、実測結果ではありません。自分の業務で分類が紛らわしいメールを匿名化して追加し、誤りを「別分類になった」「確認待ちにすべきだった」に分けて記録します。

ラベルが付いても、後続の通知は失敗することがある

ラベル付けと通知は別の処理です。通知が失敗したときにメール取得からやり直すと、一覧への重複記録が起きる可能性があります。「候補保存済み」「承認済み」「ラベル反映済み」「通知済み」を分け、再開する箇所を決めます。

誤分類を見つけたら、分類辞書を修正し、すでに付けたラベルを対象IDで確認します。メール自体を削除して帳尻を合わせる運用にはしません。AIに複数のツールを選ばせたい場合は、ツール・承認・停止条件の設計へ進めます。

スポンサーリンク