こんにちは、開発1部の庄司です。
GENDAでは、現場の業務に近いところでエンジニアがワークフロー改善に関わることがあります。
本記事では、問い合わせ対応の初動を支援するために、n8nとLLMを組み合わせて作った仕組みを紹介します。
今回作ったのは、問い合わせ内容の要約、分類、関連情報の収集、返信案の下書き、参照した情報の提示をLLMに支援させる仕組みです。ただし、問い合わせ対応をLLMに丸ごと任せるものではありません。最終的な判断や返信内容の確定、送信は、問い合わせを担当するチーム（以下「対応チーム」）が行います。
設計上のポイントは、LLMの出力だけで業務判断を完結させるのではなく、人間が判断しやすい状態を作るためにLLMを使うことです。そのために、n8nのワークフローを「問い合わせ検知」と「返信案生成」の二つに分け、Slackのボタンを起点に、必要なタイミングで返信案の生成に進める構成にしました。
分類と生成を分け、必要な情報だけを段階的に読み込むことで、対応チームがレビューしやすい出力になるようにしています。
支援の背景
問い合わせ対応では、最初の確認にどうしても時間がかかります。
問い合わせが届いたら、まず内容を読み、重要度や対応方針を判断します。そのうえで、関連するドキュメントや業務ナレッジを探し、過去の方針や説明と矛盾しないかを確認しながら返信案を作成します。さらに、その返信案を対応チーム内でレビューしてから、実際の返信に進みます。
一つひとつの作業は単純に見えますが、実際には確認すべき文脈が多く、地味に時間がかかります。また、問い合わせ内容によって必要な情報も変わるため、固定のテンプレートだけでは対応しきれません。
そこで、n8nを使ってGmail、Slack、Google Docs、Webページ、LLMをつなぎ、初動確認から返信案の下書きまでを支援するワークフローを作りました。
設計上の課題
最初に考えたのは、問い合わせを検知したら、そのまま返信案まで自動生成する構成でした。ただ、実務で使うことを考えると、この構成にはいくつか問題がありました。
- すべての問い合わせで、通知直後に返信案の下書きへ進むのが最適とは限らない
- 返信案を作る前に、人間が内容を確認したいケースがある
- どの情報を参照したのか分からないとレビューしづらい
- LLMに大量の情報を毎回渡すと、コストと品質の両面で扱いにくい
- 一つのワークフローにすべて詰め込むと、後から変更しづらい
特に重要だったのは、返信案を生成すること自体よりも、その返信案をレビューできる状態にすることでした。
返信案だけがSlackに投稿されても、対応チームは判断しづらくなります。何を根拠にその返信案になったのか、どのカテゴリとして分類されたのか、追加で確認すべき点はあるのか、どのタイミングで下書き生成に進めるのか。こうした情報がそろっていて、はじめて返信案を確認しやすくなります。
そのため、LLMの出力をそのまま結論として扱うのではなく、対応チームが判断するための材料として扱う設計にしました。
全体の構成
今回作ったワークフローは、大きく二つに分かれています。
一つ目は、Gmailで問い合わせを検知し、LLMで問い合わせ内容の要約と温度感などの初動判断を行ったうえで、Slackに通知するワークフローです。この通知には、返信案生成に進むためのボタンも付けています。
二つ目は、Slackのボタン押下を起点に起動するワークフローです。分類結果に応じて必要な情報を集め、関連する情報を選んだうえでLLMに返信案を生成させ、Slackに返信案、参照情報、分類結果を投稿します。
問い合わせ検知と返信案生成を分けることで、対応チームがSlack上で一度内容を確認し、必要なタイミングで下書き生成に進めるようにしました。
ワークフロー構成
ワークフロー1：問い合わせ検知と通知
ワークフロー1は、Gmailで問い合わせを検知し、問い合わせ内容をLLMで要約し、温度感などの初動判断を行ったうえでSlackに通知するところまでを担当します。
ワークフロー2：返信案生成
ワークフロー2は、Slackのボタン押下を起点に起動します。関連情報を収集し、その中から必要な情報を選んだうえで、LLMに返信案を生成させます。生成した返信案は、参照した情報や分類結果とあわせてSlackに投稿します。
n8nは、各SaaSやAPIをノードとしてつなげてワークフローを作れるため、このような処理を段階的に組み立てやすいです。今回の構成では、Gmailを問い合わせ検知の起点にし、Slackを対応チームの確認とレビューの場として使っています。
また、Google DocsやWebページにある情報は必要な範囲だけ参照し、LLMの処理は分類と生成に分けました。人間の判断が必要なタイミングはSlackのボタンとしてワークフローに組み込み、LLMに任せる部分と対応チームが判断する部分を分けています。
設計のポイント
1. 問い合わせ検知と返信案生成を分ける
最初に決めたのは、問い合わせ検知と返信案生成を一つのワークフローにまとめないことです。
問い合わせが届いた時点で必ず返信案を作る構成にすると、まだ内容確認が必要なケースでも生成用のLLMを実行してしまいます。また、通知と生成が密結合になるため、後から処理を変更しづらくなります。生成処理に失敗したときに、問い合わせ検知側の見通しも悪くなります。
そこで、まずは問い合わせを検知し、要約と温度感などの初動判断だけを行ってSlackに通知します。その通知を見た対応チームが、下書き生成に進めたいタイミングでSlackのボタンから二つ目のワークフローを起動する形にしました。
この分割により、初動通知は軽く保ちつつ、必要なタイミングで返信案生成のような重い処理を実行できるようになりました。
2. Slackのボタンを人間の判断ポイントにする
今回のワークフローでは、Slackのボタンを単なるUIではなく、人間の判断をワークフローに入れるための境界として使っています。
問い合わせを受けた時点では、すぐに返信案の下書き生成へ進むべきか、追加確認を先に行うべきか、対応チーム内で議論すべきか、といった判断が残っています。これらをすべて自動判定に寄せるのではなく、Slack上で対応チームが内容を確認してからボタンを押す形にしました。
この構成にすると、問い合わせの内容をまずSlackで確認し、下書き生成に進めたいタイミングで返信案生成を起動できます。返信案生成前後の議論もSlackのスレッドに集約でき、不要なLLM実行を抑えられる点も、この形にした理由のひとつです。
以下は、ワークフロー1がSlackに投稿する通知の例です。件名、要約、判定理由を確認したうえで、下書き生成に進めたいタイミングで「返信文を作成」ボタンを押します。メール本文やその後の議論も同じスレッドにまとまるため、対応チーム内で文脈を追いやすくなります。
人間が判断する箇所をワークフローの外に置くのではなく、Slackのボタンとして明示的にワークフローの中に入れたのがポイントです。
3. 分類と生成を分ける
LLMの使い方も、1回の大きなプロンプトで全部やらせるのではなく、分類と生成に分けました。
分類側では、軽量モデルを使って、問い合わせカテゴリ、参照すべき情報の種類、返信案生成に必要な情報、出典URLの引用が必要かどうかを判定します。この結果を後続ノードで扱いやすい形にし、条件分岐や参照情報の選択に使います。
その後、生成向けモデルに、元の問い合わせ内容、分類結果、選ばれた参照情報を渡して返信案を作ります。
分類と生成を分けることで、生成前に問い合わせの扱いを明示でき、後続処理の分岐も作りやすくなりました。生成モデルに渡す情報を絞れるため、コストと品質のバランスも取りやすくなります。また、分類結果をSlackに出せるため、対応チームのレビュー材料としても使えます。
すべてを生成向けモデルで処理することも技術的には可能です。ただ、今回の構成では、頻度の高い分類処理は軽く、必要なときだけ走る返信案生成は重く、という分け方が自然でした。
プロンプトを頑張って1回で解かせるよりも、ワークフローとして役割を分けたほうが、実務では扱いやすいと感じています。
4. 必要な情報だけを段階的に読み込む
問い合わせ対応では、参照すべき情報が問い合わせ内容によって変わります。すべての情報を毎回LLMに渡すこともできますが、入力が長くなりすぎますし、関係ない情報が混ざることで出力の根拠も追いづらくなります。トークン消費量、つまりコストも増えますし、後から参照情報を増やすほど扱いづらくなります。
そこで、必要な情報だけを段階的に読み込む構成にしました。
まず問い合わせ内容を分類し、その分類結果から必要な情報の候補を選びます。そのうえで、選ばれた情報だけを生成用LLMに渡し、生成結果とあわせて参照した情報をSlackに出すようにしています。
n8nに用意されたLLMノードでは、Agent Skills を直接実行できるわけではありません。
厳密には、HTTP RequestノードなどからAPIを直接呼び出すことで実現できる可能性はあります。しかし、今回はn8nのLLMノードを使う前提で設計しています。
一方で、Agent Skillsの Progressive Disclosure に近い考え方、つまり「最初から全部読ませるのではなく、必要になった情報だけを段階的に渡す」という設計は、n8n上でも再現できます。
今回のワークフローでは、分類ノードと情報選択ノードを挟むことで、この考え方を取り入れました。
結果として、LLMに渡す情報を絞りつつ、対応チームには「何を参照して返信案を作ったか」が見えるようになっています。
5. 返信案をレビューしやすい形で出す
返信案を生成して終わりにしないことも意識しました。
Slackには、返信案だけでなく、問い合わせの要約、分類結果、参照した情報、出典URLの引用を推奨するかどうかもあわせて投稿します。これは、対応チームがSlack上でレビューしやすくするためです。
返信案だけがある状態だと、一見よさそうに見えても、根拠を確認するために別のドキュメントを探しに行く必要があります。一方で、参照情報や分類結果も同じスレッドに出しておくと、レビュー時に見るべき情報がまとまります。
また、返信案をそのまま使う前提ではなく、対応チームが修正しやすい下書きとして扱えるようにしました。
LLMの出力を「正解」として出すのではなく、「レビュー対象」として出すことが大事でした。
あえて自動化しなかったこと
今回の構成では、便利そうに見えても、あえてワークフローに含めなかったこともあります。
1. 返信の送信までは含めない
返信メールの送信まではワークフローに含めませんでした。
問い合わせ対応では、文面の正しさだけでなく、返信するタイミングや表現のニュアンスも重要です。LLMが作った返信案が一見自然に見えても、そのまま送ってよいかどうかは、問い合わせの背景や相手との関係性も踏まえて判断する必要があります。
そのため、LLMが生成するのはあくまで下書きまでにしています。最終的な判断、文面の確定、送信は人間が行います。
2. すべての問い合わせで返信案を自動生成しない
問い合わせを検知したら、毎回すぐに返信案を作る構成にはしませんでした。
問い合わせによっては、返信案を作る前に対応チーム内で内容を確認したほうがよいケースがあります。追加確認が必要なものや、すぐに方針を決めづらいものまで一律で返信案生成に進めると、不要なLLM実行が増えるだけでなく、レビューする側の負担も増えてしまいます。
また、問い合わせ検知、分類、情報収集、返信案生成、Slack投稿を一つの大きなワークフローにまとめることも避けました。通知までのワークフローと返信案生成のワークフローを分けることで、初動通知の改善と返信案生成の改善を、それぞれ独立して進めやすくしています。
Slackのボタンを起点にすることで、対応チームが内容を確認したうえで、必要なタイミングだけ下書き生成に進めるようにしました。
3. すべての情報を毎回LLMに渡さない
関連しそうな情報をすべてLLMに渡すことも避けました。
入力が大きくなるほど、コストが増えるだけでなく、生成結果がどの情報を根拠にしているのか追いづらくなります。関係の薄い情報が混ざることで、レビュー時に確認すべき範囲も広がってしまいます。
また、すべての判断を一つのLLMコールに任せる構成にもしていません。分類と生成では、求められる出力の性質が違います。分類では後続処理に使いやすい構造化された判断が必要で、生成では文脈を踏まえた自然な返信案が必要です。
そのため、必要な情報だけを選んで渡し、分類と生成は別ノードに分けました。参照した情報をSlackに出せるようにすることで、対応チームがレビューしやすくなり、プロンプトや分岐のデバッグもしやすくなります。
今回の設計では「LLMをどこに使うか」より先に、「人間がどこで判断するか」を決めました。そこを先に決めると、送信までは自動化しない、すべての問い合わせで自動生成しない、すべての情報を毎回渡さない、という判断に自然と落ち着きました。
使ってみて変わったこと
導入後は、問い合わせ対応の初動で確認すべき情報がSlackにまとまるようになりました。
問い合わせ内容の要約、初動判断、参照情報、返信案のたたき台が同じスレッドに集まるため、対応チームが最初に確認すべき情報を追いやすくなっています。問い合わせ内容の把握が速くなり、返信案をゼロから作る手間も減りました。
関連情報を探す時間も削減されました。参照した情報がSlackに出るため、返信案の根拠を確認しやすくなり、対応チーム内でのレビューもしやすくなっています。返信内容に関する議論をSlackのスレッド上でそのまま進められる点も、大きな効果でした。
目安として、従来は問い合わせ1件あたり45分程度かかっていた作業が、現在は20分程度で進められるようになってきています。
もちろん、問い合わせ内容によって確認すべきことは変わりますし、最終的な判断は今も人間が行っています。ただ、最初に読むべき情報や返信案のたたき台がまとまっていることで、対応チームが判断に集中しやすくなりました。
おわりに
今回、n8nとLLMを使って、問い合わせ対応の初動を支援するワークフローを作りました。
設計で重視したのは、LLMに問い合わせ対応を丸ごと任せることではありません。問い合わせ内容を整理し、必要な情報を集め、対応チームがレビューしやすい状態を作ることです。
そのために、問い合わせ検知と返信案生成を分け、Slackのボタンを人間の判断ポイントにしました。LLMの使い方も分類と生成に分け、必要な情報だけを段階的に読み込む構成にしています。返信案だけでなく、参照情報や分類結果もSlackに出すことで、対応チームが根拠を確認しながらレビューできるようにしました。
LLM活用というと、プロンプトやモデル選定に目が向きがちです。もちろんそれらも重要ですが、実務で使う場合は、どこで人間が判断するか、どの情報を根拠として見せるか、どの単位でワークフローを分けるかも同じくらい重要だと感じています。
n8nは、ローカルPCの状態に依存せず、イベント駆動でLLMを実行する環境として優れています。また、ノードベースで処理の流れが可視化されるので、SaaSやLLMをつなぐだけでなく、人間のレビューを前提にした業務フローとして設計しやすいツールだと感じました。
本記事は、LLM活用の話でありつつ、どちらかというとワークフロー設計の話でもあります。
今後も、現場の業務に踏み込みながら、LLMを安全に実務で使える形を探っていきたいと思います。
Discussion