n8nでGmail処理を自動化する

Gmailで同じ種類のメールを毎回開き、件名を見て、別ツールへ転記し、誰かに知らせる。この繰り返しが業務の一部になっているなら、先に決めるのは「どのツールが最強か」ではなく、「どこから自動化を始めるか」です。

この記事の中心はn8nの機能紹介ではありません。目的は「Gmailの定型作業を減らす」ことです。接続手順・Nodeの能力・Cloud / Self-hosted差は、2026年9月27日時点のn8n公式Documentationを根拠にし、用途への当てはめは編集上の判断として分けて書きます。

Gmail画面の中で返信案を出すだけの用途なら、Gmailと一緒に使いやすいAIは？の方が先に合う場合があります。ここでは、受信以降の処理を自動化の流れとして組む前提で進めます。

まず試すなら

公式サイトへ進めます。

n8nn8nでGmailワークフローを作ってみる

結論：n8n化しやすいケース / まだ早いケース

n8n化しやすいケース

次がそろっていると、Gmail × n8nは候補になりやすいです。

• 同じ条件のメールが繰り返し来る（送信者、件名、ラベルなど）
• 受信後に「振り分け / 転記 / 通知 / 下書き作成」など決まった処理がある
• 途中で条件分岐や複数SaaSへの受け渡しが必要
• CloudかSelf-hostedかを自分で選べる（または選べる状態にしたい）

まだn8nを使うほどではないケース

次の条件では、先に手作業の整理や別手段の方が早いことがあります。

• 例外だらけで、ルール化できる条件がまだない
• 月に数通しか来ない
• Gmail内の検索・フィルタ・テンプレ返信だけで足りる
• Google認証やAPI有効化の準備が一切できない

編集上の判断として、最初の成功条件は「すべてのメールを賢く処理する」ではなく、「1つの定型メールを、Trigger → 条件 → 処理 → 出力まで通す」ことです。

n8n × Gmailで何を自動化できるか

公式ドキュメント上、n8nには Gmail Trigger と Gmail node があります。

Gmail Triggerは、Gmail上のイベントを起点にWorkflowを開始します。公式ドキュメントではイベントとして Message Received が案内され、設定した Poll Time に従って新しいメッセージを取得します。

Gmail node側では、Draft / Label / Message / Thread の操作が案内されています。代表例は次です。

• Message：送信、返信、取得、ラベル付与・削除、既読 / 未読
• Draft：作成、取得、削除
• Label：作成、取得、削除
• Thread：取得、ラベル操作、Trash / Untrash、返信

つまり、受信をTriggerにして、条件に合うメールへラベルを付け、返信や下書きを作り、別サービスへ渡す、という流れを公式Nodeの組み合わせで設計できます。存在しないNodeを前提にはしません。

Workflowの基本形

Gmail業務をn8nへ落とすときの基本形は、次の4段です。

1. Trigger：Gmail Trigger（Message Received）
2. Condition：TriggerのSearch / Label / Sender などのフィルタ、必要なら If / Filter node
3. Action：Gmail node（ラベル、返信、下書きなど）やデータ整形
4. Destination：Google Sheets、Slack、別のGmail操作、将来的なAI処理への受け渡し

公式のGmail Triggerには、Spam / Trashを含めるか、Label、Gmail検索構文（from: など）、Read Status、Senderといったフィルタがあります。ここで絞れるなら、後段の分岐を減らす方が運用しやすいです。

条件分岐が必要な場合、公式の If node / Filter node で比較条件を組めます。文字列の contains / starts with、数値比較、日付比較などが案内されています。

Gmailをn8nへ接続する前提

接続はGoogle credentialsが前提です。公式ドキュメントでは、Googleサービスノードに対して OAuth2 が推奨されています。Gmailについても、Service Accountは技術的に使える場合がある一方で domain-wide delegation が必要になりやすく、n8nは Gmail nodeではOAuth2を推奨 しています。

n8n Cloudの場合

公式ドキュメント上、n8n Cloudユーザー向けに Managed OAuth2 が使えるGoogleノードがあり、その中に Google Mail / Google Mail Trigger が含まれます。Managed OAuth2では、credential画面で Sign in with Google ができ、Google Cloud Console側の追加セットアップなしで始められる、と案内されています。

Custom OAuth2へ切り替えることもできます。

Self-hostedの場合

公式ドキュメントでは、Managed OAuth2は self-hosted ユーザーには使えない、と明記されています。Self-hostedでは Custom OAuth2 を使う必要があり、おおむね次の準備が案内されています。

1. Google Cloud Consoleでプロジェクトを作成する
2. Gmail API を有効化する
3. OAuth同意画面を設定する
4. OAuth client（Web application）を作成し、n8nの OAuth Redirect URL を登録する
5. Client ID / Client Secret をn8n credentialへ入れ、Sign in with Google する

Authorized domains には、Cloudなら n8n.cloud、Self-hostedなら自インスタンスのドメインを追加する、と公式手順で案内されています。localhost開発時は、Googleが localhost redirect URI を許可している、という説明もあります。

Google側でつまずきやすい条件

公式のトラブルシュートでは、次が典型例として案内されています。

• Gmail APIが有効化されていない
• External + Testing の同意画面で、Test users に自分のアカウントが入っていない
• Testingモードでは同意・tokenが7日で期限切れになる場合がある
• redirect_uri_mismatch（Redirect URLの不一致）
• 「Google hasn't verified this app」警告

記事判断に影響する差は、「CloudはManaged OAuth2で始めやすい」「Self-hostedはGoogle Cloud側の準備が必須」です。料金プランやSelf-host運用全体の比較は、この記事では深く扱いません。関連Guide（G318 / G322 / G324）が公開されたらそちらへ進んでください。

最小Workflowの作り方

Hands-on未実施のため、ここは公式Documentation上の手順・仕様を編集上の標準フローに再構成したものです。「この画面でこう動いた」という実測結果ではありません。

1. Triggerを置く

新規Workflowを作り、最初のノードに Gmail Trigger を追加します。

• Credential：Google OAuth2（CloudならManaged OAuth2も候補）
• Event：Message Received
• Poll Times：業務に合う間隔
• Filters：まず Sender / Search / Label / Read Status で対象を絞る
• Max Emails per Poll：公式ではデフォルト10、最大50。超過分は次のpollで取得、と案内されています

編集上の判断として、最初は「Unreadのみ」「特定送信者のみ」など、誤爆しにくい条件から始めるのが安全です。

2. 条件を足す

Triggerフィルタだけでは足りない場合、If または Filter を挟みます。

例：

• 件名に「請求」を含む
• 特定ラベルが付いている
• 添付の有無で分岐する（ただし、フィールドの実在確認は実行データで行う）

公式の If node は true / false の2分岐、Filter node は条件に合うitemだけを後続へ通します。

3. 処理する

条件に合ったメールへ、Gmail nodeで処理を加えます。

例：

• Add Label to a message
• Mark as Read
• Create a draft / Reply to a message
• Get a message（本文やヘッダを後続へ渡す）

本文の一部を別サービスへ渡す場合は、expressionsで前ノードのデータを参照する、というn8nの基本概念を使います（公式の first workflow ガイドでも expressions が中核概念として説明されています）。

4. 出力・通知する

Destinationの例は、公式に存在するNodeの範囲で次が現実的です。

• Google Sheets node：行の Append など
• Slack node：Message Send
• 別のGmail操作：下書き作成や返信

Google Sheets連携の深掘り記事（G446）や、AI処理を足す構成（G320 / G445）は、この最小形が通ってから検討する方が失敗が少ないです。

5. 公開して自動実行する

公式の first workflow ガイドでは、定期実行などを本番で使うには Workflow を Publish する必要がある、と案内されています。Trigger付きWorkflowは、公開前の手動 Execute と、公開後の自動実行を分けて考えてください。

実務で使いやすいWorkflow例

以下は架空のHands-on結果ではありません。公式Nodeの組み合わせで組める、編集上の設計例です。

例A：特定送信者の受付メールをSheetsへ転記

Gmail Trigger（Message Received）
  └ Search / Sender で受付窓口メールに限定
→ If / Filter（件名や本文条件）
→ Google Sheets（Append Row）
→ Gmail（Add Label / Mark as Read）

向く条件：毎日同じ形式の申込・問い合わせが来る。

例B：重要メールをSlackへ即通知

Gmail Trigger
  └ Label または Search で重要条件に限定
→ Slack（Send a message）
→ Gmail（Add Label）

向く条件：見逃しコストが高いが、件数は多くない。

例C：定型問い合わせの下書きを先に作る

Gmail Trigger
→ If（FAQ対象の件名）
→ Gmail（Create a draft または Reply）
→ Slack（担当者へ確認依頼）

向く条件：最終送信は人が確認したい。完全自動返信にはしない。

例D：受信内容をAIへ渡して要約する（拡張）

Gmail Trigger
→ （必要なら）本文取得・整形
→ AI系ノード / ChatGPT連携
→ Slack または Sheets

ここから先はAI Workflowの設計が主役になります。Gmail接続の確認が終わってから、関連Guide（G320 / G445）側へ進む方が責務が分かれます。

Cloud / Self-hostedで確認すること

記事判断に必要な差だけを置きます。

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

確認点	n8n Cloud	Self-hosted
開始の速さ	公式上、すぐ始めやすい	インストールと運用が必要
Google認証	Managed OAuth2が使える案内あり	Custom OAuth2が必要
データ管理	n8n管理のCloud環境	自前インフラ上で制御
向きやすい人	まずGmail連携を試したい人	データ所在やカスタム要件が強い人

どちらが安いか、どれだけ運用負荷があるかは、料金・Self-host専用のGuide（G318 / G322 / G324）で別途判断してください。この記事では「Gmailを繋ぐ前に、認証方式の前提が違う」ことだけ押さえます。

AI処理を足す場合

Gmail自動化にAIを足すのは有効ですが、最初の失敗理由の多くはAI以前の Trigger条件と認証です。

編集上の順番は次が扱いやすいです。

1. Gmail Triggerで対象メールだけ拾えるか
2. Sheets / Slack など確定処理まで通るか
3. その後で要約・分類・下書き生成をAIへ渡すか

AI Workflowの基本構成やChatGPT連携は、関連Guide（G320 / G445）の範囲です。ここでは「AIを足す前に、Gmailの入口を安定させる」ことだけを条件にします。

n8nが向くケース / 別Toolも検討するケース

n8nが向くケース

• 条件分岐や例外処理を自分で設計したい
• Gmail以外のSaaSも同じ基盤で増やしたい
• CloudとSelf-hostedを用途で選びたい
• 将来、AIノードやカスタム処理まで広げたい

別Toolも検討するケース

• 画面操作の簡単さ最優先で、分岐はほぼ不要
• チームがすでにZapier / Make運用で標準化されている
• Gmail内完結のフィルタとテンプレで足りる
• Google Workspaceの標準機能だけで要件が閉じる

n8nとMake / Zapierの比較（G362 / G363）は、Tool選定そのものが主題のときに参照してください。この記事では「Gmail定型処理をWorkflow化できるか」に絞ります。

AIものさしの判断

Gmailの定型処理を減らしたいなら、n8nは有力な候補です。特に、受信をTriggerにし、条件で絞り、SheetsやSlack、Gmail操作へ渡す流れが見えているときに相性がよいです。

ただし、最初から全部を自動化しようとしない方がよいです。公式Documentation上でも、認証・API有効化・Publish（自動実行）は段階があります。Hands-on未実施の本記事では、次の順番を推奨します。

1. 自動化するメールを1種類に絞る
2. CloudかSelf-hostedかで認証方式を決める
3. Gmail Trigger → 条件 → 1つの出力まで通す
4. 安定してからラベル処理やAIを足す

自分のGmail業務をWorkflowとして想像できたタイミングで、n8nの画面へ進むのが自然です。