AIチャットボットを導入し、よくある質問への返信作成は自動化できるようになったけれど、それ以外の処理はまだ手動というケースは多く残っています。問い合わせメールに返信し、CRM に登録し、担当者に連絡し、対応記録を残す、という流れにおいて、一件あたりはそれぞれ数分でも、積み重なると多くの時間を消費することになります。
今回はMakeを使って、Gmailの受信から HubSpotへの登録、Slackへの通知、スプレッドシートへのログ記録まで、1本のシナリオで全て自動で完結させました。
【目次】
全体の流れ
シナリオの処理順を最初に整理しておきます。今回はカテゴリ判定とカテゴリ別の返信生成でGoogle Geminiを使用しました。1回目は軽めの分類タスク、2回目は返信文の生成、というように役割を分けて2段階でAIを使うことで、プロンプトをシンプルにし、精度の向上を図った点がポイントです。

以下のような構成になっています。
Gmail(受信トリガー)
↓
Google Gemini AI(カテゴリ判定)
↓
Router(カテゴリ判定によって4ルートに分岐)
├─ 製品仕様 → Gemini AI(返信生成)→ Gmail 送信 → HubSpot → Slack → Google Sheets
├─ 料金・契約 → Gemini AI(返信生成)→ Gmail 送信 → HubSpot → Slack → Google Sheets
├─ 技術サポート→ Gemini AI(返信生成)→ Gmail 送信 → HubSpot → Slack → Google Sheets
└─ その他 → HubSpot → Slack(要確認通知のみ)→ Google Sheets
モジュール 1:Gmail Watch Emails
シナリオが起動するきっかけとなるトリガーには Gmail Watch Emails モジュールを使います。全受信メールを対象にはせず、特定のラベルが付加されたメールの受信で絞り込むことで、必要なメールのみを処理することができます。
設定例
項目 | 設定値 |
Filter type | Simple filter |
Folder | All mail |
Label | inquiry |
Criteria | Only unread messages |
Mark as read when fetched | Yes |
Limit | 5 |
Filter type について、Simple filter は、送信者(Sender email address)、件名(Subject)、その他文面に含まれるキーワードといった条件を、Makeが用意した個別の設定項目(フォーム)に一入力していく形式です。より込み入った条件(from:hoge.com -subject:自動返信など)を書きたい場合は Gmail filter を選ぶと Gmail の検索構文がそのまま使えます。
Labelについて、ラベルの付与は Gmailのフィルタ設定で行います。問い合わせフォームの送信元アドレスからメールが届いたら、「inquiry」といったラベルを付与しておく方法が比較的容易です。
【参考】Gmail でラベルを作成、管理する
取得できる主なデータ
- {{1.From (name)}} — 送信者の名前
- {{1.From (email)}} — 送信者のメールアドレス
- {{1.Subject}} — 件名
- {{1.full text body}} — メール本文(テキスト形式)
- {{1.Date}} — 受信日時
- {{1.Thread ID}} — スレッドID(返信を同一スレッドに乗せたい場合に使用)
モジュール 2:Google Gemini AI(カテゴリ判定)
問い合わせカテゴリの判定には Google Gemini AI (Generate a Response) モジュールを使います。以前は HTTP モジュールで API を呼び出す必要がありましたが、Makeに Google Gemini AI のモジュールが追加されてから、認証も含めてかなり設定が楽になりました。
モデルは、公開時の現状ではGemini 2.5 Flash でも精度は十分で、消費トークンも抑えられます。返信文の生成も Gemini 2.5 Flash でまず試し、精度が十分ではない場合には上位モデルに変更する形がおすすめです。1
プロンプト例
以下の問い合わせメールを読み、次の4つのカテゴリのうち最も適切なものを1つだけ返してください。 |
Google Gemini から「この問い合わせは料金に関するものですので、『料金・契約』に分類されます。」のような文章が返され、後続の Router の条件が壊れてしまわないよう、最後の「カテゴリ名のみを返してください。余分な説明は不要です。」の一行が重要です。これで「製品仕様」「料金・契約」など単語のみでの回答を支持することができます。
モジュール 3:Router
モジュール 2 (Google Gemini AI) が返したカテゴリ文字列を条件にRouterで分岐させます。
各ルートのフィルタ設定
ルート名 | 条件 |
製品仕様 | {{139.Result}} テキストが次と等しい 製品仕様 |
料金・契約 | {{139.Result}} テキストが次と等しい 料金・契約 |
技術サポート | {{139.Result}} テキストが次と等しい 技術サポート |
その他 | {{139.Result}} テキストが次と等しい その他 |
参照するモジュールの番号について
{{139.Result}} の 139 の部分は、参照するモジュールのモジュール番号に合わせる必要がある点にご注意ください。
モジュール番号はモジュール名の右隣に表示されます。

「その他」ルートについて
分類できなかった問い合わせに的外れな返信をしてしまうリスクを避けるため、今回は「その他」ルートについては自動返信をしないようにしています。
モジュール 4:Google Gemini AI(返信文生成)
各ルートで再度 Google Gemini AI (Generate a Response) モジュールを使用し、カテゴリに合ったプロンプトで返信文を生成します。プロンプトのポイントは、モジュールの設定でURL Content を"Yes"にし、情報源として既にウェブサイトのURLを参照させている点です。また、外部に公開していない情報を情報源とする場合には、Google Drive に文書を用意し、動的に差し込む構成でも問題ありません。

製品仕様ルートのプロンプト例
あなたはSaaS企業のカスタマーサポート担当です。以下の製品仕様に関する問い合わせに対して、丁寧かつ簡潔な返信メールを日本語で作成してください。 |
料金・契約ルートのプロンプト例
あなたはSaaS企業の営業担当です。 |
モジュール 5:Gmail Send an Email
Google Gemini が生成した返信文を使用して返信をします。
設定例
項目 | 設定値 |
To | {{1.From (email)}} |
Subject | Re:{{1.Subject}} |
Body type | Raw HTML |
Content | {{1.From (name)}} 様 |
Body type を Raw HTML とした場合、Content は HTML で記述する必要があります。Google Gemini からの返信は HTML で記述されておらず、送信した際に改行が消えてしまうため、改行コードを<br>に置き換える点がポイントです。

スレッドに返信したい場合
既存のメールスレッドに返信したい場合は threadId を設定します。ただし、Gmail APIの仕様として In-Reply-To ヘッダーも合わせて設定しないとスレッドが分裂することがあります。In-Reply-To には元メールの Message-ID を指定します。シンプルに新規メールとして送るだけなら threadId は不要です。
モジュール 6:HubSpot Create or Update a Contact
HubSpotへの登録はコンタクトを作成・更新するモジュールを使います。メールアドレスで既存コンタクトと照合し、新規なら作成、既存なら更新します。
設定例
今回はView MethodをCompactにしたうえで、KeyとValueは以下の設定を行いました。自社のプロパティ設定に応じて設定してください。
Key | Value |
{{1.From (email)}} | |
First Name | {{1.From (name)}} |
モジュール 7:Slack Send a Message
特定のチャンネルに通知を送ります。
設定例
項目 | 設定値 |
Enter a channel ID or name | Enter manually |
Channel ID or name | 投稿したいチャンネルのIDまたはチャンネル名を入力する。 |
Text | 新規問い合わせ(製品仕様) |
「自動返信済み」の明記が必須
担当者が改めて返信しようとして二重送信が発生しないよう、自動返信済みであることを明記するようにしています。自動返信を行わない「その他」ルートでの Slack への送信では、文章を変更して未返信であることを明記するなどの工夫も行うと良いでしょう。
モジュール 8:Google Sheets Add a Row
対応履歴をSpreadsheetに記録していきます。
推奨の列構成
ログを残しておくことで定期的に見返すことができ、プロンプト改善や FAQ 整備に役立ちます。
列名 | マッピング |
受信日時 | {{1.Date}} |
送信者名 | {{1.From (name)}} |
送信者メール | {{1.From (email)}} |
カテゴリ | 製品仕様(固定値) |
問い合わせ内容 | {{1.full text body}} |
送信した返信文 | {{4.Result}} |
担当者 | プリセールス担当(固定値) |
よくあるミスと対策
(1) Routerの条件がマッチしない
Google Gemini の出力に全角スペースや改行が混入していると、カテゴリ判定の完全一致条件が通らなくなります。対策として、分類用プロンプトに「スペースや改行を含まずカテゴリ名のみを1行で返してください」と明示するか、番号で返させる方法が安定しやすいです。
(2) 返信の件名が Re:Re:Re: になる
subject に Re:{{1.Subject}} と設定すると、もとのメールの件名がすでに Re:から始まっていた場合にRe:Re:になります。Makeのtrim関数やreplace関数でRe:を除去してから付け直すか、件名をそのまま使う設定にするか選択します。
(3) HubSpotで氏名が上書きされる
既存コンタクトに対してFirst Name に {{1.From (name)}} を毎回入れると、表示名が変わっていた場合に上書きされます。初回登録のみ名前を入れたい場合は、HubSpot 側でワークフローの条件を使うか、Makeのif関数で既存判定をすると良いでしょう。
(4) エラー処理
Google GeminiのAPIエラーやGmailの対象メールの取得失敗は、Makeのシナリオ実行ログには残りますが、気づかないまま問い合わせが処理されない状態が続くことがあります。Error Handler の設定を追加して、異常時に Slack 通知を飛ばすようにしておくことで、エラーに気づきやすくなります。
エラーハンドリングの設定
エラー通知は最初から設定しておきましょう。
設定方法:各モジュールを右クリック → Add error handler → Route

エラー発生時のSlack通知テキスト例
🚨 問い合わせ自動対応でエラー発生 |
スモールスタートのすすめ
最初からすべての機能を一気に組み込もうとせず、GmailからGoogle Geminiへ返信を送る3モジュールだけで動かしてみて、慣れてからHubSpotなどのCRMやSlackなどのコミュニケーションツールを追加していくところからお試しいただくのも方法の一つです。
最小構成
Gmail Watch Emails → Google Gemini AI(Generate a response)→ Gmail Send an Email

これだけで「受信したら自動で返信する」というシナリオが動きます。そこからRouter、HubSpot、Slack、Spreasheetと順番に足していけば、各モジュールの動作を確認しながら拡張できます。
まとめ
今回作ったシナリオで自動化できたのは、受信・分類・返信・CRM登録・社内通知・ログ記録の6工程です。イレギュラーなお問い合わせ以外は、お問い合わせ内容に合わせた返信を全て自動で行えるようになります。Make は ドラッグ&ドロップで「シナリオ(自動化の流れ)」を描ける直感的な操作感が特徴であるため、エンジニア以外の方でもコツをつかめば、比較的容易に使いこなせるようになるでしょう。
一方で、実際に構築を進めると、モジュールごとの細かな設定項目や、エラーメッセージの読み解き、AIのモデル選択によるコスト面の違いなど、つまずきやすい部分も少なくありません。すべてを最初から完璧に組み上げる必要はなく、エラーが出たら一つずつ原因を確認しながら調整していく、という前提で取り組むのがおすすめです。まずは小さなな処理から始めて、業務自動化の効果を体感しながら進めていくのがおすすめです。
出典一覧
1 MakeのGoogle Geminiモジュールのモデル別消費クレジットは、公式ドキュメント(https://apps.make.com/gemini-ai)の「Simple text prompt」記載箇所に掲載されていますが、本稿で扱う「Generate a response」はAPIキーによる接続が必要なモジュールであり、同じ換算レートがそのまま適用されるかは公式ドキュメント上では明記されていません。そこで、入力1000文字程度、出力200文字程度になるようなプロンプトを使って、実際に「Generate a response」モジュールでGemini 2.5 FlashとGemini 3.5 Flashを実行して検証したところ、いずれも1operation=1creditの消費でした(検証時点)。つまり、特定条件下では少なくともこの2モデルにおいては、モデルによるMakeの消費クレジット数の差は見られないと言えます。ただしGemini API側では、モデルごとにトークン単価が異なるため、モデル選択によって課金額が変わる点には注意が必要です。Gemini APIの料金については、公式サイト(https://ai.google.dev/gemini-api/docs/pricing)で最新情報を確認してください。
