【 Dify + n8n 】 Gmail 受信メールに対して半自動で LLM が返信文面を作成して下書き保存
前提記事
本記事は、以下の記事をある程度の前提としています。
適宜ご参照ください。
そもそも Dify とは、 n8n とは何か？ 組み合わせることで何が嬉しいのか？
Dify と n8n を VPS - Docker 環境で稼働・連携させるまでの具体的な手順
はじめに
「無料部分」での趣旨
本記事は「無料部分」と「有料部分」とで構成されています。
「無料部分」では、主に以下のことが書かれています。
Dify + n8n の組み合わせにより、人間が能動的に Dify ワークフローを実行しなくてもよくなる、その一例についての全体像
詳細な実装の解説は省かれています
「有料部分」の位置づけ
逆に「有料部分」では、
詳細な実装の解説
今すぐ使える！ インポート用ファイルを配付
n8n ワークフローの json ファイル
Dify の DSL ファイル
となります。
半自動って？
タイトルの「半自動」で文面生成って何？ という話について。
まず、受信したメールの中身について、これは受信者がコントロールできるものではありません。
どのような内容のメールが送られてくるのか、それは送信者に委ねられるわけです。
つまり、個人情報・機密情報等が送られてくるメールに含まれている可能性は、大いにあります。
「メール本文に個人情報・機密情報等が含まれているかどうか？」ということを、そもそも LLM に判定してもらいたいくらいですよね。
しかし現状、クラウドベースの LLM を用いることがほとんどと思われます。
つまり、LLM に渡してはいけないものを確認するために LLM にデータを渡さなくてはならない、というジレンマが生じます。
将来的には、
性能がそこまで高くはないローカル LLM で、個人情報・機密情報が含まれているかどうかを確認
問題がない場合、クラウドベースの LLM で、返信文面生成
というようなフローが作れるようになると良いのですが、もう少し先のことですね。
ということで、「全自動」でメール文面を LLM に渡すには、リスクが高いために「半自動」にするわけです。
では「半自動」とは？
ここでは、以下のように定義します。
Gmail で特定のラベルを用意する
特定のラベルが付けられているメールを対象として、LLM へ本文を渡す
つまり受信者が手動でやるべきこととして、
受信したメールを目視確認
自動生成対象と思ったものについて特定のラベルを付ける
ということが残ります。
ローカル LLM を安価に自在に使えるようになるまで、もうしばしの辛抱ですね。
n8n 側の全体像
さて、それではまず n8n 側の全体像から見ていきましょう。
ノードの数がやや多いので、ちょっと複雑に見えるかもしれませんが、基本的にはほぼ一本道ですので、そんなにややこしいことはありません。
流れとしましては、
時間トリガーとして、何分毎に自動実行される
Gmail の受信メールに特定のラベルが付与されているものを探す
特例のラベルが付与されているものが複数ある場合、そのうちの最新のメール一件に絞り込む
絞り込まれたメールから本文を取得
取得した本文に対して Dify で返信文面案を作成
作成された返信文面案を、受信メールに対する下書きとしてセット
付与されていた特例のラベルを剥がす
となります。
なお、ワークフローのベーステンプレートとして、以下の `Compose reply draft in Gmail with OpenAI Assistant` を使わせていただきました🙏
ただ、こちらをそのまま使おうとしても、個別の環境依存や文字コード以外の点でも、いくつか壊れていて動かない箇所がありましたので、使われる方は要注意です。
Dify 側の全体像
次に n8n から呼ばれている Dify 側の全体像も見ます。
ここでは検証環境として Cohere Command R + を利用しています。
やっていることはシンプルでして、
n8n から の POST リクエストのパラメータ ＝ 受信メール本文 を `text` 変数に受ける
受け取った `text` 変数を、一度、構造的なデータとして分析させる
構造的なデータに変換した受信メール本文に対して、返信文面案を作成させる
作成を終えた返信文面案を return する
応用編として、受信メール本文だけでなく、送信元メールアドレスも一緒に受け取るようにして、送信元メールアドレスに応じたナレッジを通した上での返信文面案作成、ということもできるでしょう。
動作確認
それでは実際に、これがどのように動作したか、入力内容と出力結果を確認してみましょう。
事例 1
事例 1 です。
具体的な情報を問われていますが、今回、Dify 側に RAG を仕込んでいませんので LLM では回答不能なものになっています。
その場合は `【要文面作成】` などと出力してもらうようにしています。
下書きとしての雛形が作成されるだけでも、負荷はそれなりには減るのではと思います。
もちろん、相手先に応じた RAG を組み込んでいただくと、実用性がグッと高まりますね👍
下書きで弊社社名を誤っているのはご愛嬌……
事例 2
事例 2 です。
こちらもスケジュール調整ということで、具体的な情報を問われていますね。
同じく、LLM では回答不能なものになっています。
この場合の対応策としては、Dify 側に RAG を仕込むというよりは、あらかじめ n8n 側で Google カレンダー等のカレンダーアプリから今後の予定情報を取得しておいて、その情報ごと Dify にコンテクストとして渡してあげるのが良いでしょう。
こちらは宛名部分が少しオカシイですが、プロンプトをもう少し工夫すれば改善されることでしょう。
おわりに
はい、ということで、以上になります！
具体的に n8n と Dify とを連携させることでどんなことができるかというのは、アイディア次第でいくらでも！ という感じではありますが、そうは言っても何か一つ具体的に示してもらえないと……という方向けに、作成してみました。
他にも記事にして欲しいネタなどありましたらコメントでお知らせいただけると嬉しいです😀
「そうは言っても難しいよ！」「代わりに構築してくれん？」という場合はお気軽にご相談ください🙌
以下、有料部分
有料部分の概要
n8n ワークフローの json 配付
n8n ワークフローのカスタマイズと解説
Gmail API の有効化と OAuth 2.0 認証
Dify ワークフローの DSL 配付
Dify ワークフローについての補足説明
読者限定 Discord サポートのご招待
対象読者
「自分で調べながら構築するのは大変そうかなあ」という方
「やればできるだろうけれど時短したいなあ」という方
補足
配付されたワークフローファイルをインポートした上で、ちょいちょいとカスタマイズするだけになっていますので、だいぶ時短できます
Gmail API を使うための OAuth 2.0 設定の部分だけは、やや詳細な作業が必要です
ただ、ここで一度 OAuth 2.0 設定を経験することで、他での応用も効かせることができると思います。再利用性のある知見を身につけることができます
ここから先は
この記事が気に入ったらサポートをしてみませんか？