n8n で Gmail の問い合わせを Slack に自動転送する

n8n は、アプリやサービスをつないで自動処理を組み立てられる、ノーコード／ローコードのワークフロー自動化ツールです。

問い合わせフォームからのメールが、気づいたら半日放置されていた。営業時間中なのに返信が翌日になってしまった。Gmailの受信トレイを開きっぱなしにしていても、こうした見落としは起こります。担当者がひとりなら気づけるかもしれません。でも、チーム全員がいつメールを確認するかバラバラなら、誰かが拾うだろうという空気が生まれ、結局誰も拾わない。

この「拾い漏れ」を仕組みで潰す方法が、Gmailに届いた問い合わせをSlackへ自動で流す転送ワークフローです。普段チームが見ているSlackチャンネルに通知が飛べば、メールボックスを開く習慣がない人でも気づけます。そして、これをプログラミングなしで組めるのがn8nというツール。

この記事を読めば、n8nの全体像から、Gmailトリガーの設定、問い合わせメールだけを絞り込むフィルタ条件、Slackへの投稿、テスト実行、本番運用でつまずく落とし穴の回避までが一通りわかります。「一から全部知りたい」という人が、読み終えた直後に自分の環境で最小構成を動かせる状態を目指します。

n8n で Gmail から Slack への転送を自動化する仕組み

問い合わせ転送の自動化は、突き詰めると「メールが届いた」という出来事を起点に、「Slackへ書き込む」という動作を機械に代行させることです。この起点と動作をつなぐ設計図を、n8nではワークフローと呼びます。まずは、その全体像を地図として押さえておきましょう。

n8n とは何か（ノーコード自動化ツールの位置づけ）

n8nは、複数のアプリやサービスをノード（処理の箱）として並べ、線でつないでいくことで自動処理を組み立てるツールです。ノーコード／ローコードという言葉のとおり、基本的な連携はマウス操作と設定項目の入力だけで完成します。プログラミングの経験がなくても、「Gmailで受信したら」「Slackに投稿する」という日本語の発想のまま組めるのが特徴です。n8n そのものの導入手順や基本機能は、n8n の導入ガイドでも詳しく扱っています。

似たツールにZapierやMakeがありますが、n8nの立ち位置を一言で表すなら「自分の手元でも動かせる自動化基盤」です。提供形態には大きく2種類あります。ひとつは、n8n社が運用するサーバーを使うクラウド版。もうひとつは、自分のパソコンやサーバーにインストールして動かすセルフホスト版です。セルフホスト版では、無料の Community edition を自分の PC やサーバーで動かせます。導入は一般に Docker や Node.js（npm）の環境があれば可能です。ソースコードは公開されていますが、ライセンスは利用条件を含む Sustainable Use License で、n8n 公式はこれを「オープンソース」ではなく fair-code と説明しています。自社の問い合わせ通知のように社内業務で使う分には問題ありませんが、顧客向けサービスとして提供する場合などは公式ライセンスを確認してください。

料金やプランの細かい条件は変更されることがあるため、最新の金額は公式サイトで確認してください。ここで覚えておきたいのは、無料で試せる選択肢が用意されているという点だけで十分です。

Gmail トリガー＋Slack ノードの基本フロー

今回作るワークフローは、たった3つのパーツでできています。順番に見ていきましょう。

最初のパーツがトリガーです。トリガー（処理の引き金）とは、ワークフローを動かし始めるきっかけのこと。今回はGmailノードをトリガーに設定し、「新しいメールを受信した」という出来事を引き金にします。n8nが定期的にGmailをチェックし、新着メールを見つけるとワークフローが起動する、という流れになります。

次のパーツが条件分岐です。受信したメールをすべてSlackに流すと、メルマガや通知メールまで混ざって通知が氾濫します。そこで、件名や送信元で「これは問い合わせだ」と判定できるメールだけを通すフィルタを挟みます。この絞り込みがあるかないかで、通知の使い勝手は大きく変わる。

最後のパーツがアクションです。アクション（実行する動作）として、Slackノードに「指定したチャンネルへ投稿する」役割を持たせます。ここで、受信したメールの件名や送信元を Slack メッセージに差し込みます。本文まで通知したい場合は、本文を取得する設定と情報管理上の扱いを確認したうえで追加します。

整理すると、Gmailトリガー（受信検知）→ フィルタ（問い合わせだけ選別）→ Slackノード（投稿）という一直線の流れ。この3段構えが、問い合わせ転送ワークフローの骨格です。本記事ではこの骨格を、設定項目の意味を確認しながら一つずつ組み上げていきます。

自動転送を作る前の事前準備

手を動かす前に、必要なものをそろえておくと作業が止まりません。ここで用意するのは大きく3点。n8nを動かす環境、Gmailとの接続認証、Slackの受け取り先です。準備段階でつまずく人の多くは、認証の登録でひっかかります。先に全体像を把握しておきましょう。

この3つがそろえば、ワークフロー作成に進めます。それぞれもう少し掘り下げます。

n8n の用意（クラウド版とセルフホスト版）

n8nを使い始める入口は、前述のとおり2通りあります。クラウド版は、公式サイトでアカウントを作ればブラウザ上ですぐにワークフロー編集画面が開きます。サーバーの知識は要りません。試しに触ってみたい段階なら、こちらが最短ルート。

一方のセルフホスト版は、自分の環境にn8nをインストールして動かす方式です。一般的にはDockerを使ったコンテナ起動か、Node.js環境での実行が選ばれます。n8n 本体や資格情報、実行データの保存場所を自社の管理下に置きたい場合には、検討する価値があります。ただし、今回のように Gmail から Slack へ通知する構成では、セルフホストにしても問い合わせ情報は Gmail や Slack といった外部サービスを経由します。「自社サーバーに置けば社内で完結する」わけではなく、問い合わせ内容をどこまで Slack に送るか、n8n の実行履歴をどれだけ保存するか、投稿先チャンネルを誰が見られるかまで含めて設計してください。起動・更新・バックアップ・セキュリティ管理も自分で行う必要があります。なお、ツールを OSS かどうかやデータの持ち方で選ぶ視点は、OSS とデータ所有権で選ぶツール比較でも整理しています。

どちらを選んでも、ワークフローの作り方そのものは同じです。この記事の手順は両方に当てはまります。

Gmail と Slack の接続認証（資格情報の登録）

n8nがあなたのGmailを読み、あなたのSlackに書き込むためには、「このツールにアクセスを許可します」という認証手続きが必要です。この認証情報を、n8nでは資格情報（クレデンシャル）として登録します。一度登録すれば、以降のワークフローで使い回せます。

GmailやGoogleのサービスとの連携には、一般的にOAuthという認証方式が使われます。OAuth（オーオース）とは、パスワードそのものをツールに渡さず、「特定の操作だけを許可する鍵」を発行して連携する仕組みのこと。これにより、n8nにGmailのパスワードを教えることなく、メール受信の権限だけを安全に渡せます。具体的な接続手順は連携先のサービス側の画面遷移に従う形になり、表示は時期によって変わるため、最新の流れは公式ドキュメントを確認してください。

Slack側も同様に、ワークスペースへの接続を許可する認証を登録します。このとき、n8nがSlackでできることはOAuthで許可した範囲に限られます。今回は「指定チャンネルへメッセージを投稿する」動作ができればよいので、チャンネルへの投稿権限を持つ形で接続します。

認証の手順は、n8n Cloud とセルフホストで少し異なります。n8n Cloud では、Gmail トリガーや Slack ノードをブラウザから比較的かんたんに接続できます。一方セルフホストでは、Google Cloud Console で Gmail 用の OAuth アプリを設定したり、Slack App を作成して Redirect URL や権限範囲（スコープ）を登録したりする作業が必要です。Gmail 連携について、n8n 公式は Service Account より OAuth2 を推奨しています。

接続が完了すると、n8nの資格情報一覧にGmailとSlackが並びます。ここまで来れば下準備は完了です。

Gmail トリガーから Slack 通知までの作成手順

いよいよワークフロー本体を組み立てます。流れは、新規ワークフローの作成 → Gmailトリガーの設定 → Slackノードの設定 → テスト実行 → 有効化、の順です。各ステップで何を設定するのか、その項目がなぜ必要なのかを確認しながら進めていきます。まずは入口となるGmailトリガーから。

Gmail トリガーノードの設定（受信検知の条件）

新しいワークフローを作成すると、まっさらな編集画面（キャンバス）が表示されます。ここに最初のノードとしてGmailを追加し、役割をトリガーに指定します。具体的には、ノードを追加する際に「新着メールの受信を検知する」種類のトリガーを選ぶ形になります。表示名はバージョンによって異なるため、一般的に「メール受信時」に相当する項目を選ぶ、と理解しておけば十分です。

Gmailトリガーを置いたら、先ほど登録した資格情報を選んで接続します。接続が成功すると、検知の条件を指定できるようになります。ここで設定できる代表的な項目が次のとおり。

1. どのメールを対象にするか：受信トレイ全体か、特定のラベル・送信元・Gmail 検索条件で絞るか
2. チェックの間隔：n8n がどのくらいの頻度で Gmail を確認するか
3. データの簡略化（Simplify）：既定はオンで、メッセージ ID・ラベル・From・To・Subject などのヘッダーが返る（本文は既定では含まれない）

Gmail トリガーには Simplify という設定があり、既定ではオンです。このとき返るのはメッセージ ID、ラベル、From、To、CC、BCC、Subject などのヘッダーが中心で、メール本文は既定の簡略化データには含まれません。件名と送信元だけを Slack に通知する最小構成なら、この既定のまま始められます。本文まで通知に含めたい場合は、テスト実行で取得データを確認したうえで、Simplify をオフにするか、取得したメッセージ ID を使って Gmail ノードで本文を取得する構成を検討してください。

この段階で「特定のラベル」を指定しておくのは、後々の絞り込みを楽にする有効な手です。たとえば、問い合わせフォームから届くメールに Gmail の自動振り分け機能で専用ラベルを付けておけば、トリガーの時点で対象を問い合わせメールに寄せられます。ラベルのほか、送信元（Sender）や Gmail の検索条件（Search）でも、トリガーの段階で対象を絞れます。

チェックの間隔については、注意したい点があります。n8n の Gmail トリガーは、設定した確認間隔（Poll Time）に応じて Gmail を見に行くポーリングという方式です。ポーリング（定期確認）とは、常時監視ではなく決まった周期で見に行く仕組みのこと。これはクラウド版・セルフホスト版に共通の仕様なので、どちらで動かしても、メール受信から Slack 通知まで多少のタイムラグが生じます。完全な即時通知ではない、という前提を理解しておくと、後で「すぐ来ない」と慌てずに済みます。具体的な最短間隔はプランや仕様で変わるため、最新の数値は公式ドキュメントで確認してください。

設定を終えたら、この時点で一度トリガーだけを実行してみると、実際にメールが取得できるか確かめられます。ここで自分の Gmail から1通テストメールを送り、n8n がそのメールの件名や送信元を読み取れているかを確認しておくと、次の Slack 設定でつまずきにくくなります。本文まで Slack に出したい場合は、この段階で本文データまで取得できているかも合わせて見ておくと、後段の差し込みでつまずきません。

Slack ノードの設定（送信先チャンネルとメッセージ整形）

トリガーで取得したメールを、今度は Slack へ流す番です。ワークフローの編集画面でGmailトリガーの隣に新しいノードを追加し、Slack を選びます。ここでも最初に求められるのが、Slack 側との接続認証。事前準備で登録した資格情報を選べば、n8n があなたのワークスペースへ投稿できる状態になります。

Slack ノードを開くと、まず「どんな操作をするか」を選ぶ項目が現れます。今回やりたいのはチャンネルへのメッセージ投稿なので、メッセージ送信に相当するアクションを指定。次に決めるのが、投稿先のチャンネルです。問い合わせ専用のチャンネルをあらかじめ作っておくと、通知が他の会話に埋もれません。チームの誰がいつ見ても「ここを見れば問い合わせがわかる」状態を作れるのが利点。

ここからが、この連携のいちばん面白い部分です。投稿するメッセージ本文に、Gmail トリガーが取得したメールの情報を差し込めます。件名や送信元など、トリガーが返した項目を変数として埋め込めるのです。たとえば「新しい問い合わせが届きました」という定型文に続けて、件名と送信者を動的に挿入すれば、Slack を見ただけで誰から何の用件かが一目でわかります。メール本文まで通知に含めたい場合は、前段のテスト出力で本文が取得できていることを確認してから差し込んでください。

差し込む情報は欲張りすぎないのがコツです。メール本文を丸ごと貼ると、長文の問い合わせで Slack が読みにくくなります。件名と送信元、本文の冒頭だけを通知し、詳しくは Gmail やサポートツールのリンクをたどってもらうほうが、すっきりした運用になることも多いはずです。整形の具体的な記法は変わることがあるため、最新の書き方はn8n 公式ドキュメントで確認してください。

テスト実行とワークフローの有効化

ノードを並べただけでは、まだ自動転送は動きません。仕上げに必要なのが、テスト実行と有効化の2段階。いきなり本番運用に回すのではなく、まず手元で1回動かして確かめる流れを踏みます。

n8n には、ワークフロー全体を試しに1回だけ走らせる機能があります。編集画面から実行を押すと、Gmailトリガーが実際にメールを取得し、そのデータがSlackノードへ渡り、テスト投稿が飛ぶところまでを一連で確認できます。自分のGmailから「問い合わせテスト」といった件名のメールを1通送り、数分待ってから実行してみてください。指定したチャンネルに通知が届けば、配線は正しくつながっています。

You can test individual nodes, or run the entire workflow, to make sure it works as expected before activating it.
— n8n 公式ドキュメント（https://docs.n8n.io/workflows/executions/manual-partial-and-production-executions/）

テストでSlackに何も来ないときは、どの段階で止まったかを切り分けます。Gmailトリガー単体では取得できているのにSlackに届かないなら、原因はSlack側の設定。逆にトリガーの時点でメールを拾えていなければ、ラベル指定や認証を見直します。n8n は各ノードの実行結果を個別に表示してくれるので、どこでデータが途切れたかを目で追えるのが助かるところ。

テストが通ったら、最後にワークフローを有効化します。編集画面の有効化スイッチをオンにすると、ここで初めて自動運転が始まります。これ以降は、あなたが画面を開いていなくても、新着の問い合わせメールが届くたびにSlackへ通知が飛ぶ仕組み。逆に言えば、有効化を忘れると「テストでは動いたのに本番で何も来ない」という、初心者がいちばん引っかかる落とし穴にはまります。動作確認できたら有効化、までをワンセットで覚えておきましょう。

問い合わせ転送を実務で使うためのカスタマイズと注意点

最小構成が動いたら、次は実務に耐える形へ育てる段階。届いたメールを片っ端から流すだけでは、すぐにSlackがノイズだらけになりかねません。ここでは、転送する対象を絞る方法と、運用で詰まりやすいポイントを先回りして押さえます。

特定の問い合わせだけ転送するフィルタ条件

受信トレイには、問い合わせ以外のメールも大量に届きます。メルマガ、社内連絡、自動送信の通知。これらを全部Slackに流せば、肝心の問い合わせが埋もれてしまうのは目に見えています。そこで使うのが、条件で絞り込む発想。

問い合わせメールを送信元やラベル、Gmail の検索条件で判別できるなら、まずは Gmail トリガー自体の Sender、Label Names or IDs、Search といったフィルタで対象を絞るのがいちばんシンプルです。余計なメールを取得してから落とすより、入口で絞るほうが無駄がありません。複数条件の組み合わせや、取得した内容に応じた判定が必要になったら、トリガーと Slack ノードの間に IF / Filter ノードを足します。代表的な絞り込みの軸は次のとおりです。

いちばん手堅いのは、Gmail側の自動振り分け機能と組み合わせる方法です。問い合わせフォームからのメールに専用ラベルを自動で付けておき、n8nのトリガーではそのラベルだけを見る。こうすればn8n側の条件分岐をシンプルに保てます。役割分担として、仕分けはGmail、通知はn8nと切り分けるイメージ。

件名キーワードで絞る場合は、表記ゆれに注意したいところ。「問い合わせ」「お問合せ」「ご質問」など、人によって書き方が違います。条件を厳しくしすぎると、本物の問い合わせを取りこぼす危険も。最初は緩めに設定し、実際の通知を見ながら少しずつ調整していくのが現実的な進め方です。

運用で詰まりやすいポイント（実行回数・認証・重複通知）

作った直後は快調でも、しばらく運用すると思わぬところでつまずきます。代表的な3つを挙げておきます。

ひとつめが、認証の期限切れ。GmailやSlackとの接続は、時間が経つと再認証が必要になる場合があります。ある日突然通知が止まったら、まず資格情報の有効期限を疑ってください。エラーログに認証関連のメッセージが出ていれば、接続を更新するだけで復旧することがほとんど。

ふたつめは、実行回数や呼び出し頻度の制限。クラウド版には、プランごとに一定期間内の実行回数の上限が設けられているのが一般的です。SlackやGmail側のAPIにも、短時間に大量のリクエストを送ると一時的に制限がかかる仕組みがあります。問い合わせが急増したときに通知が遅れたり止まったりする原因になり得るため、扱う量が増えてきたらプランや仕様の確認を。具体的な上限値は変動するので、最新情報は各サービスの公式ドキュメントで確かめてください。

3つめが、この重複通知です。テスト段階では特に起きやすく、初心者を慌てさせます。まずは実行履歴で同じメールが何回処理されたかを確認し、原因を切り分けてから対処すれば、落ち着いて収められます。

よくある質問

Q. n8n は無料で使えますか？

セルフホスト版の Community edition は無料で、自分のサーバーや PC 上で動かせます。ただしライセンスは利用条件を含む Sustainable Use License（n8n 公式はこれを「オープンソース」ではなく fair-code と呼んでいます）で、顧客向けサービスとして提供する場合などは条件の確認が必要です。クラウド版には有料プランがあり、内容や金額は改定されることがあります。最新の料金や無料枠の条件は、n8n 公式サイトで確認してください。

Q. プログラミングの知識は必要ですか？

基本的な転送ワークフローはノードを並べて設定するだけで作れるため、コードを書かずに完成させられます。今回のGmail→Slack転送も、認証と項目選択が中心。ただし複雑な処理を組むときは、簡単な式を書ける知識があると応用の幅が広がります。

Q. Gmail 以外のメールでも使えますか？

n8n は多くのアプリやサービスと連携できるため、他のメールサービスを対象にしたトリガーも利用できる場合があります。利用できる連携の種類は更新されていくので、対応状況は公式ドキュメントで確認するのが確実です。

Q. メールはリアルタイムで転送されますか？

n8n の Gmail トリガーは、設定した間隔でメールを確認しに行くポーリング方式です。クラウド版でもセルフホスト版でも、受信から通知まで多少のタイムラグが生じます。完全な瞬時通知ではない前提で運用するとよいでしょう。最短間隔の仕様はプランや設定によって異なります。

Q. Slack 以外の通知先にも送れますか？

送信先のノードを差し替えれば、Slack以外のチャットツールやメール、タスク管理ツールへも転送できます。仕組みは同じで、トリガーはそのままにアクション側を変えるだけ。複数の宛先へ同時に流す構成も組めます。

まとめ

Gmail に届いた問い合わせをSlackへ自動で流す仕組みは、トリガー・条件・アクションという3つの部品の組み合わせで成り立っています。Gmailトリガーで受信を検知し、必要なら条件で絞り込み、Slackノードで通知する。この一本道さえ押さえれば、コードを書かずに対応漏れを防ぐ通知が手に入ります。

進め方として勧めたいのが、最初から完璧を目指さないこと。まずは個人情報を含まないダミーのテストメールを使い、絞り込みなしの最小構成で Slack に通知が届くところまでを確認します。動くことが確かめられてから、フィルタ条件で問い合わせだけに絞り、投稿する内容と閲覧範囲を確認したうえで本番運用へ進めます。この順番なら、どこかでつまずいても原因を切り分けやすく、挫折せずに育てられます。

問い合わせ対応の遅れは、メールを見落とす一瞬から生まれます。チーム全員が見るSlackに通知が集まれば、その一瞬を仕組みで埋められる。今日作ったワークフローを足がかりに、転送条件の調整や他ツールへの展開へと広げてみてください。こうした手作業を自動化に置き換える進め方は、業務効率化の始め方を整理した記事でも扱っています。n8n を使った自動化の幅広い活用法は、Zapier・Make との比較記事でも取り上げています。

参考資料

• n8n 公式ドキュメント: Workflow automation documentation
• n8n 公式: Gmail Trigger node documentation
• n8n 公式: Slack node documentation
• Google 公式: Gmail API Guides
• Slack 公式: Sending messages API
• n8n 公式: Manual and partial executions
• n8n 公式: ライセンス（Sustainable Use License / fair-code）
• n8n 公式: 実行データの保存と環境変数（EXECUTIONS_DATA_SAVE_*）