MakeとDifyをノーコードで繋ぎAI自動メール返信ワークフローを構築する

MakeとDifyで構築する「下書き承認型」AIメール返信術｜誤送信ゼロを目指す実務的自動化フロー

2026年1月5日更新 2026年3月20日約18分で読めます

文字サイズ:

MakeとDifyで構築する「下書き承認型」AIメール返信術｜誤送信ゼロを目指す実務的自動化フロー

はじめに：AIに「勝手に」返信させる恐怖と、その解決策

お客様からの問い合わせメールに、AIが不適切な返信をしてしまうのではないかという懸念はもっともです。現在のLLM（大規模言語モデル）は非常に優秀ですが、文脈の取り違えや「ハルシネーション（もっともらしい嘘）」のリスクをゼロにすることはできません。特に、企業の顔として接するカスタマーサポートや一次対応において、誤った情報の送信は信用の失墜に直結します。

しかし、リスクを恐れてAI活用を諦めてしまうのは、ビジネスにおける大きな機会損失です。

実用的なAI導入において、多くの企業で成果を上げている設計思想が「Human-in-the-loop（人間がループに入る）」です。AIに直接「送信」ボタンを押させるのではなく、AIにはあくまで「完璧に近い下書き」を作らせる。そして、人間がその内容を確認し、承認（送信）ボタンを押す。このプロセスであれば、誤送信のリスクを排除しつつ、メール作成にかかる時間を大幅に短縮できます。

本記事では、ノーコードツール「Make（旧Integromat）」と、AIアプリ開発プラットフォーム「Dify」を連携させ、この「下書き承認型」の自動返信ワークフローを構築する手順を解説します。

エンジニアでなくても実装可能な構成です。順を追って設定していけば、業務負担を減らし、ROI（投資対効果）の向上に貢献する「AIアシスタント」を構築できます。

1. なぜ「全自動」ではなく「半自動」なのか？実務に耐えうるAI返信の設計思想

まず、手を動かす前に、なぜこのシステム構成にするのか、その「設計思想」を共有します。プロジェクトマネジメントの観点からも、システムの目的と制約を正しく理解しておくことは、運用開始後の予期せぬトラブルを防ぐために不可欠です。

AIによる「誤送信」と「ハルシネーション」のリスク

ChatGPTをはじめとする生成AIは、進化のスピードが非常に速く、論理的思考力や文脈理解力が飛躍的に向上しています。OpenAIの公式情報（2026年1月時点）によると、GPT-4oやGPT-4.1といった旧モデルは2026年2月13日をもって廃止され、より長い文脈の理解や文章の構造化に優れたGPT-5.2（InstantおよびThinking）が新たな主力モデルへと移行しています。システムを構築・運用する際は、Dify側で廃止される旧モデルを指定したままにせず、最新モデルへ適切に移行設定を更新することが不可欠です。

しかし、どれほど高性能なモデルへと進化し、汎用知能が向上したとしても、確率的に次の言葉を予測して文章を生成するという基本的な仕組みは変わりません。そのため、自社のサービス仕様に含まれていない機能を「できます」と断言してしまったり、古い価格情報を提示してしまったりするハルシネーションのリスクは常に残ります。

また、DifyのRAG（検索拡張生成）機能を使って社内ナレッジを参照させる場合、検索技術は従来の単なるキーワードマッチから、文脈を考慮したハイブリッド検索やリランク（再順位付け）、さらには画像や図表まで認識するマルチモーダル対応へと進化しています。それでも、AIが参照データを誤って解釈したり、検索漏れが発生したりする可能性はゼロではありません。

全自動で即時返信を行うシステム（受信→即AI生成→即送信）は、例えるなら「非常に優秀だが、まだ業務知識が完璧ではない新人スタッフに、一切のチェックなしでお客様対応を任せる」ようなものです。ビジネスにおける信頼性を担保するためには、AIの出力に対して人間の目が介在するプロセスが不可欠です。

Make × Difyで実現する「ドラフト作成＋人間承認」モデル

そこで採用するのが、今回構築する「ドラフト作成＋人間承認」モデル（Human-in-the-loop）です。

メール受信: 顧客からのメールを受け取る。
AI思考: Difyがナレッジベースを参照し、最適な回答案を生成する。最新モデルのPersonalityシステムを活用し、文脈に適応した自然な会話調になるようプロンプトで調整することも有効です。
下書き保存: Makeがメールソフト（Gmail等）の「下書きフォルダ」に返信案を保存する。
通知: 担当者に「返信案ができました」と通知が届く。
人間承認: 担当者は内容やトーン＆マナーを確認し、必要なら微修正して「送信」をクリック。

このフローであれば、AIの回答が万が一的外れであっても、担当者が修正すれば良いだけです。お客様には常に正確な情報が届く状態を担保できます。

期待できる効果：対応時間を短縮

「結局人間が見るなら、手間は変わらないのでは？」と思われるかもしれません。しかし、このシステム導入により、問い合わせ対応時間を大幅に短縮できる可能性があります。

通常、問い合わせメールへの返信には以下の工程が発生します。

メールを読む
必要な情報をマニュアル等から探す
文章を構成し、丁寧語で入力する

今回のシステム導入後は、AIが作成した下書き（ドラフト）を確認し、必要に応じて修正して送信ボタンを押すだけで済みます。最新のAIモデルは応答速度も向上しており、より迅速に的確なドラフトを用意してくれます。「ゼロから文章を考える」という最も認知負荷の高いプロセスをAIが肩代わりするため、作業効率は劇的に改善します。

1件あたりの対応時間を短縮できれば、担当者がより付加価値の高い業務（複雑なクレーム対応や企画業務など）に集中できる時間を生み出すことが期待できます。

2. 統合アーキテクチャとデータフローの全体像

2. 統合アーキテクチャとデータフローの全体像 - Section Image

構築作業に入る前に、今回作成するシステムの全体像（アーキテクチャ）を把握しておきましょう。どのツールが何を担当し、データがどう流れるかを論理的に理解しておくことで、設定作業がスムーズに進みます。

システム構成図：Gmail ⇄ Make ⇄ Dify

今回は以下の3つの主要コンポーネントを使用します。

Gmail: メールの受信と送信（下書き保存）を担当。
Make: オーケストレーター（指揮者）。Gmailからの通知を受け取り、Difyへ指示を出し、その結果をまたGmailに戻す役割。
Dify: 頭脳。渡されたメール本文を読み解き、ナレッジベースに基づいて回答文を生成する役割。

これらに加え、オプションとしてSlack（またはMicrosoft Teams）を通知用に使用します。

データの流れ：受信→文脈解析→回答生成→ドラフト保存→通知

具体的なデータの流れは以下のようになります。

[Gmail] メールを受信。
[Make] 新着メールを検知（トリガー）。送信者が除外対象でないかチェック。
[Make -> Dify] メール本文と件名をAPI経由でDifyに送信。
[Dify] 事前に登録されたマニュアル（ナレッジ）を検索し、回答を生成。
[Dify -> Make] 生成された回答テキストをMakeに返却。
[Make -> Gmail] 「Re: 件名」で返信メールを作成し、本文にAIの回答をセットして「下書き」に保存。
[Make -> Slack] 「下書きを作成しました。確認してください」というリンク付きメッセージを送信。

必要な技術スタックとアカウント準備

このハンズオンを進めるために、以下のアカウントを準備してください。

Makeアカウント: Freeプランでも試せますが、メール数が多い場合はCoreプラン以上推奨。
Difyアカウント: クラウド版（Dify.ai）またはご自身でホスティングしている環境。
Gmailアカウント: テスト用に個人のGmailでも構いませんが、Google Workspaceアカウントの方が実務には適しています。
Slackアカウント: 通知を受け取るためのワークスペース。

準備ができたら、まずは「頭脳」となるDifyの設定から始めましょう。

3. 【Dify側設定】高精度な回答を生成するAIエージェントの構築

Makeで連携する前に、Dify単体で「良い回答」ができる状態を作っておく必要があります。ここが不十分だと、自動化しても質の低い下書きが量産されることになります。

ナレッジベース（RAG）の整備とアップロード

まず、Difyの「ナレッジ」機能を使って、AIに参照させたいドキュメントを登録します。

Difyのトップメニューから「ナレッジ」を選択し、「ナレッジを作成」をクリック。
FAQリスト、製品マニュアル、過去の回答集などをアップロードします。PDFやWord、Markdown形式などが対応していますが、AIが読み取りやすいよう「Q&A形式」のテキストデータにしておくと精度が向上します。
インデックス設定は「高品質」を選択し、処理完了を待ちます。

システムプロンプトの設計：トーン＆マナーの指示

次に、「アプリ」を作成し、チャットボットの設定を行います。

「スタジオ」から「最初から作成」→「チャットボット」を選択。
「コンテキスト」に先ほど作成したナレッジを追加します。
プロンプト（命令文）の設定が重要です。以下のような構成を推奨します。

# Role
あなたは自社のカスタマーサポート担当です。
丁寧で親しみやすいトーンで、顧客からの問い合わせに回答してください。

# Constraints
- コンテキスト（ナレッジ）にある情報のみに基づいて回答してください。
- ナレッジに情報がない場合は、正直に「申し訳ありませんが、その件については担当者より確認して改めてご連絡いたします」と回答し、適当な情報を捏造しないでください。
- 返信の冒頭には「お問い合わせありがとうございます。」と入れてください。
- 文末は「今後ともよろしくお願いいたします。」で締めてください。

特に「わからない場合はわからないと言う」指示は、ハルシネーション防止のために必須です。
デバッグ画面でいくつか質問を投げ、意図した通りの回答が返ってくるかテストしてください。

APIアクセスの設定とAPIキーの取得

Makeからこのボットを呼び出すための「鍵」を取得します。

アプリ編集画面の左サイドバーにある「APIアクセス」をクリック。
右上の「APIキー」をクリックし、「新しいシークレットキーを生成」します。
生成されたキー（app-から始まる文字列）をコピーし、メモ帳などに控えておいてください（この画面を閉じると二度と表示されません）。
APIサーバーのURLも確認しておきます。クラウド版なら https://api.dify.ai/v1 です。

これで「頭脳」の準備は完了です。いよいよMakeでの構築に移ります。

4. 【Make側実装 Step 1】メール受信トリガーと無限ループ防止策

4. 【Make側実装 Step 1】メール受信トリガーと無限ループ防止策 - Section Image

Makeにログインし、新しいシナリオ（Create a new scenario）を作成します。
最初のステップは、メールの受信を検知することですが、ここで最大の落とし穴である「無限ループ」への対策を施します。

Gmail/Outlookモジュールの接続設定

中央のプラスボタンを押し、「Gmail」を検索して選択します。
トリガーとして「Watch Emails」を選びます。
Webhook接続（Create a connection）の設定を行い、Googleアカウントを認証します。
Folder: 通常は「Inbox（受信トレイ）」を選択。
Criteria: 「Only Unread emails（未読のみ）」にしておくとテストしやすいですが、運用に合わせて「All emails」でも構いません。

フィルタリング設定：特定件名やドメインのみを対象にする

全てのメールにAI返信するのは危険です。メルマガや社内連絡にまで返信しないよう、フィルターを設定しましょう。

Gmailモジュールの直後の点線をクリックして、フィルターを設定します。

Label: Filter: Target Emails
Condition:
- Subject (Text operator: Does not contain) Re:
  - ※すでに返信のやり取りが始まっているメール（Re:がついているもの）を除外する場合。
- Sender: Email Address (Text operator: Does not contain) no-reply@
  - ※自動送信メールを除外。
- Sender: Email Address (Text operator: Does not contain) your-own-email@example.com
  - ※自分自身を除外（重要）。

【重要】自動返信メールに反応させないための除外設定

最も懸念されるのは、相手も自動返信を設定していて、「AI返信」→「相手の自動応答」→「それにまたAI返信」... という無限ループが発生することです。

これを防ぐため、以下の条件をフィルターに必ず加えてください。

Subject (Text operator: Does not contain) Automatic reply
Subject (Text operator: Does not contain) 自動応答
Subject (Text operator: Does not contain) 不在通知

また、Makeの実行回数制限（1回の実行で処理するメール数）を1〜5程度に絞っておくのも安全策として有効です。

5. 【Make側実装 Step 2】Dify APIとの接続とデータマッピング

ここが本記事の重要な部分です。Difyには専用のMakeモジュールがないため（2023年時点では公式モジュールがない場合が多い）、汎用的な「HTTP」モジュールを使用します。

HTTP Requestモジュールの設定詳細

Gmailモジュールの次に「HTTP」アプリを追加し、「Make a request」を選択します。
URL: https://api.dify.ai/v1/chat-messages
Method: POST
Headers: ここで認証情報を渡します。
- Name: Authorization
- Value: Bearer {先ほどコピーしたDifyのAPIキー}
  - ※Bearerとキーの間に半角スペースを忘れずに。

JSONペイロードの構築：メール本文をDifyに渡す

次に、Difyに送るデータの本体（Body）を作ります。

Body type: Raw
Content type: JSON (application/json)
Request content: 以下のJSONコードをコピーし、貼り付けます。

{
    "inputs": {},
    "query": "{{1.text}}",
    "response_mode": "blocking",
    "conversation_id": "",
    "user": "make-user-001"
}

ここで重要なのが、"{{1.text}}" の部分です。ここには、Makeの変数ピッカーから、Gmailモジュール（モジュール番号1）で取得した「Text content（メール本文）」をドラッグ＆ドロップしてください。これで、受信したメールの本文がDifyへの質問（query）として送信されます。

レスポンスデータの解析と抽出

HTTPモジュールの設定の下の方にある「Parse response」にチェックを入れます。これにより、Difyから返ってきたJSONデータ（AIの回答が含まれている）をMakeが自動的に分解し、次の工程で使いやすくしてくれます。

一度ここで「Run once」をクリックしてテスト実行してみましょう（自分宛てにテストメールを送っておきます）。成功すれば、HTTPモジュールの出力（Output）の中に data -> answer という項目が見つかるはずです。これがAIの生成した回答文です。

6. 【Make側実装 Step 3】「下書き保存」による承認フローの確立

4. 【Make側実装 Step 1】メール受信トリガーと無限ループ防止策 - Section Image 3

AIからの回答を受け取ったら、それをメールの下書きとして保存し、人間に通知します。

Create a Draft（下書き作成）アクションの設定

HTTPモジュールの次に、再度「Gmail」モジュールを追加します。
今度はアクションとして「Create a draft」を選択します。
各項目を以下のようにマッピングします。
- To: Gmailモジュール（Step 1）の Sender: Email Address
- Subject: Re: + Gmailモジュール（Step 1）の Subject
- Content: HTTPモジュール（Step 2）の data.answer

これで、「受信した相手への返信」として、「件名にRe:をつけ」、「本文にAIの回答を入れた」メールが、送信されずに下書き保存されます。

返信先・件名・AI生成本文のマッピング

ここでのポイントは、署名の追加です。Difyのプロンプトで署名を入れても良いですが、Gmail側で管理したい場合は、Contentフィールドで以下のように記述します。

{{2.data.answer}}

--
[自社名] カスタマーサポート

このように、AIの回答と定型文を組み合わせることで、より自然なメールを作成できます。

担当者への通知：Slack/Teamsへのリンク通知実装

最後に、下書きが作られたことを担当者がすぐに知れるよう、Slackに通知を送ります。

Gmailモジュールの次に「Slack」アプリを追加し、「Create a Message」を選択します。
通知したいチャンネルを選択。
Text: 以下のようなメッセージを構成します。

【AI返信案作成】
以下のメールに対する返信案を作成しました。

件名: {{1.subject}}
送信者: {{1.sender.emailAddress}}

▼ Gmailで確認・編集して送信
https://mail.google.com/mail/u/0/#drafts

Gmailの下書きフォルダへの直接リンク（https://mail.google.com/mail/u/0/#drafts）を入れておくのがUX（ユーザー体験）向上のコツです。担当者はSlackの通知を見て、リンクをクリックし、内容を確認して送信ボタンを押すだけです。

7. トラブルシューティングと運用時の注意点

システムは構築して終わりではありません。運用開始後に発生しがちなトラブル（APIエラーや予期せぬ停止）への対処法と、安定稼働のためのポイントについて、プロジェクトマネジメントの観点から解説します。

よくあるエラー：タイムアウトとJSON形式エラー

Dify（特にChatGPTやClaudeなど、高性能なLLMを使用している場合）は、回答生成や推論に時間がかかり、MakeのHTTPリクエストがタイムアウトするケースが珍しくありません。

例えば、Claudeのモデル移行（前モデルのClaudeから、より高度な推論能力を備えたClaude等へのアップデート）に伴い、新たに「Adaptive Thinking（タスク複雑度に応じた思考深さの自動調整）」といった機能が推奨されるようになりました。こうした自律的な思考プロセスを伴う設定や、100万トークン規模の長文コンテキスト推論、あるいはCompaction機能（コンテキスト上限近辺での自動サマリー）が働く場面では、非常に精度の高い回答が得られる一方で、APIの応答時間は長くなりがちです。

対策として、旧来の単純な生成モデルを前提とした設定を見直し、MakeのHTTPモジュール設定で「Timeout」の値を長め（例：60秒〜120秒以上）に再設定しておくことが重要です。

また、メール本文に特殊文字が含まれていると、JSONの形式エラーになることがあります。HTTPモジュールのJSON作成部分で、本文データを入れる際に json_stringify 関数などは通常Makeが自動処理してくれますが、エラーが頻発する場合はMakeの組み込み関数を使って文字列を適切にエスケープ処理する必要があります。

Difyのクレジット消費管理

Difyのクラウド版を使用している場合、またはLLMプロバイダー（OpenAIやAnthropic等）のAPIキーを直接設定している場合、リクエストのたびに課金が発生します。予期せぬ大量のメール受信（スパム攻撃など）によってクレジットが急速に枯渇しないよう、Dify側またはプロバイダー側の管理画面で「利用上限（Hard Limit）」を事前に設定しておくことを強くお勧めします。

特に、入力トークンと出力トークンで単価が異なる高性能モデルを多用する運用や、複雑なエージェント計画を実行させる場合、1回あたりの処理コストが変動しやすいため、定期的な利用状況のモニタリングが不可欠です。

回答精度が落ちた時のナレッジベース更新フロー

運用を続けていると、「AIが特定の質問にうまく答えられない」「回答のニュアンスが自社の基準とズレている」といったケースが出てくる可能性があります。その際、Makeのシナリオ自体を修正するのではなく、Difyの「ナレッジ」を更新して対応します。

AIの回答精度を維持・向上させるための定期的なメンテナンス運用として、以下のサイクルを回します。

担当者がAIの作成した下書きを確認し、適切な内容に修正して送信する。
その「修正後の正しい回答」や不足していた前提知識を、Difyのナレッジベースに追加登録する。
次回以降、AIはその新しい知識を参照し、より正確な回答を生成できるようになる。

この地道なフィードバックサイクルこそが、AIを「単なる自動化ツール」から「頼れるチームのパートナー」へと育て上げるための重要なプロセスです。

まとめ：AIは「魔法」ではなく「チームの一員」

今回取り上げた「Make × Dify」によるメール自動化フローは、人間の手を完全に手放す完全自動化を目的としたものではありません。人間とAIがそれぞれの得意分野（AIは膨大な知識からの下書き作成、人間は最終的な文脈判断と責任）を分担することで、業務効率と品質を高いレベルで両立させる実践的なソリューションです。

リスク管理: 即時送信ではなく下書き保存＋人間承認のステップを挟むことで、誤送信のリスクを抑える。
効率化: ゼロから回答を作成する心理的・時間的負担を大幅に削減する。
継続的な成長: 日々の修正履歴をナレッジベースにフィードバックし、システム全体の精度を上げ続ける。

まずは「よくある質問」や定型的な問い合わせなど、影響範囲の小さな数パターンからスモールスタートで導入し、実用的なAI導入の第一歩を踏み出してみてください。

MakeとDifyで構築する「下書き承認型」AIメール返信術｜誤送信ゼロを目指す実務的自動化フロー - Conclusion Image

コメントは1週間で消えます

コメントを読み込み中...