n8n × Slack 「対話型 AI ヘルプデスク」を作ったときの工夫

※この記事は「COUNTERWORKS Advent Calendar」 の12日目の記事です。

■ まえがき

自己紹介

仕事も趣味も AI コーディング中心の はなぽん と申します。
n8n は昨年から自宅でも活用しており、重要メールの着信をチャットへ通知したり、ちょっとした生活改善のためのオートメーションに使っています。
n8n を触る以前は、IFFFT や Node-Red などのツールを試していました。

「対話型 AI ヘルプデスク」を作った背景

社内にはワークフローシステムがあるものの、困っている社員の状況を想像すると、そもそも「どの申請を選べばいいのか」で迷ってしまうケースが多いと感じました。
そこで、社員に寄り添って状況を聞き取り、適切な申請や対応へ導いてくれる 対話型 AI ヘルプデスク を構築することにしました。

n8n とは？

n8n は、ノーコード／ローコードで高度な自動化ワークフローを構築できるオープンソースのオートメーションプラットフォームです。Slack、Google Workspace、AWS、データベース、外部 API など数百のサービスと連携でき、ドラッグ＆ドロップでノードをつないで複雑な処理を組み立てられます。
条件分岐、データ整形、Webhook、スケジューリング、AI モデルとの連携も自由度が高く、オンプレミスや自社クラウドにホスト可能な点から、セキュリティ要件の高いシステムにも適しています。

URL n8n.io

今回の「対話型 AI ヘルプデスク」では、n8n の AI Agent ノードが非常に扱いやすかったため、採用しました。

フロー設計

n8n のフロー設計では、「入力 → 処理 → 出力」 を明確にし、最初に必要なデータ構造を定義することが重要です。
トリガー（Slack / Webhook など）を起点に、条件分岐・データ整形・外部 API 呼び出しへ処理をつなげ、最後にログ保存や通知を行います。各ノードは Input → 処理 → Output の単位で接続すると整理しやすくなります。

主要な部品（ノード）

• AI Agent：AI によるタスク管理・返答生成を担当
• Slack Trigger：Slack の投稿を受け取る
• Chat Trigger：n8n 開発画面からチャットで手軽にテスト可能
• Field Editor：入力データの整形
• Merge：複数入力を待ち合わせて処理を同期

■ 「対話型 AI ヘルプデスク」の構築

今回は「対話型 AI ヘルプデスク」 をn8n上に構築しました。

n8nのワークフローの全体像は、次のようになります。

本ヘルプデスクは次の特徴を持ちます：

• Slack の投稿を受信
• 投稿タイプに応じて処理を分岐（対応方針は Google Sheets 管理）
• 申請の場合は必要項目を順に取得
• 必須項目の充足状況を AI が判断
• すべて揃えば担当者へ通知
• 申請以外は QA として回答

さらに、本記事では セッション管理を Google Sheets に永続化し、外部デバッグを容易にする設計パターン を紹介します。
処理順はノードの接続順で実行されるため、Merge ノードにより複数経路の結果をまとめて参照できるようにしています。

処理の流れ

ここでは、実際に採用した設計上の工夫をかいつまんで紹介します。

1. Slack Trigger と Chat Trigger を統合する「入力エミュレーター」

Slack と n8n Chat は入力形式が異なるため、そのままでは後続処理のロジックが複雑になります。
そこで、どちらの入力も 最終的に同一の Slack 風 JSON に統一し、AI Agent が入力元を意識しなくてよいように設計しました。

○ [Slack trigger] → そのまま event payload
○ [Chat trigger] → Slack 風 message JSON へ変換（thread_ts も疑似生成）

これにより、デバッグ時は Chat Trigger、実運用は Slack Trigger と、同じフローで柔軟に扱えるようになります。

2. セッションID = thread_ts（Chat は代替 ID を生成）

Slack では、1スレッドを識別する thread_ts がそのままセッションIDとして利用できます。
一方、n8n Chat にはスレッド概念がないため、以下のように擬似 ID を生成します。

debugsession-{日付}

これにより、

• 同一 thread_ts → 同じセッション
• 新しい thread_ts → 新規セッション

というシンプルで直感的なモデルが実現できます。

3. Google Sheets を “永続セッションDB” として利用

n8n にはセッション保持用の Memory ノードがありますが、外部から中身を確認できないためデバッグ性に課題があります。
そこで今回は、Google Sheets をセッションDBとして利用する方式を採用しました。

各セッションを 1 行 で管理し、以下のような情報を保存します：

カラム名	用途
session_id	スレッドID(=thread_ts)
context	会話サマリ（自動更新）
tasks_json	タスク一覧
requirements_json	必須項目の進捗
session_status	ongoing / waiting_for_user / completed
last_user_text	最新ユーザー発話
updated_at	最終更新日時

これにより、
AI の判断材料が 人間側に可視化される構造になります。

Slack でメッセージが届くたびに、

• 同一スレッド → 既存セッションを Sheets からロード
• 新規スレッド → 空の初期状態をロード

というシンプルな制御で扱えます。
Sheets 保存により AI の “思考過程” を人間が後から追える のが大きなメリットです。

4. Helpdesk AI（AI Agent）が “状態管理の差分更新” を担当

Helpdesk AI は AI Agent ノードで実装し、以下の処理を一括で担います：

• 新規入力の理解
• タスク / 必須項目の状態更新
• 次に取得すべき情報の判断
• context（要約）の更新
• Slack に返すメッセージ生成

状態管理ロジックをコードで書かずに済むため、
プロンプトとスプレッドシートの構造を改善するだけでシステムが進化します。

利用しているシステムプロンプトの抜粋は次の通りです：

あなたはITヘルプデスクのアシスタントです。Google Sheetsに保存されている必須項目に関する情報を使用して
ユーザーの申請に必要な情報が揃うまで、何回もユーザーに質問をします。

## Slackに返すメッセージ

更新後のセッション状態を決定してください。

## Process

1. ユーザーの依頼を理解する
2. Google Sheets Toolを使用して対応表からどの希望しているタスクを探す。
3. タスクが決まったら、必要項目を確認する
4. 全ての必要項目の情報が揃うまで、ユーザーに質問して回答を得る。
5. 必須項目が全て揃ったら、対応を完了する。

回答は日本語で、親切で分かりやすい表現を心がけてください。

## Output
出力は 必ず JSON のみ とし、以下のスキーマに完全に従ってください。
余計な文章やコメントは一切出力してはいけません。


reply: Slackにそのまま投稿するメッセージ本文。ユーザーに次にしてほしいことや、足りない情報があれば質問も含めること。

- session_status: ongoing, waiting_for_user, completed, aborted のいずれか。
- context: 会話全体の要約。次のターンで再利用できるように簡潔に書く。
- tasks: 既存のタスクをもとに追加・更新・削除した結果の一覧。タスクIDは既存タスクのIDを維持すること。
- requirements: 各プロセスごとに、「どの必須情報フィールドが埋まっているか / 足りないか」を status と value で表現すること。足りない情報がある場合は、reply 内でその情報を質問すること。

## Json形式
... つづく...

ナレッジシートの例：

5. Backyard AI（追加 AI Agent）で永続化と通知を担当

Helpdesk AI にすべてを任せず、次の役割を 別の AI Agent（Backyard AI） に分離しています：

• セッション情報を Google Sheets に書き込む
• 必須項目が揃ったら担当者へ Slack 通知する

理由：
1つの AI にタスクを詰め込みすぎると精度が落ちやすいためです。

Sheets のカラム名を具体的にすることで、
「AI がどの軸で考えるべきか」を自然に誘導できます。

セッション用スプレッドシートの項目は、人間が理解しやすい形で要点がまとるようにします。
項目名を具体的にすることで、どの軸でAIが考えるべきかが明確になり、AIに詳しく指示する必要がなくなります。

6. AI Agent の結果に基づいて Chat / Slack へ返信する

最後に、AI Agent の出力をもとに、

• Chat Trigger 経由 → n8n Chat 形式で返信
• Slack Trigger 経由 → Slack メッセージ形式で返信

という分岐を行います。
Field Editor で整形してから、それぞれの送信用ノードへ接続しています。

工夫と理由

① Slack と Chat を共通フローで扱う
→ デバッグ効率が圧倒的に向上。

② セッションを Google Sheets に永続化
→ Memory のブラックボックス化を避け、AI の判断を可視化。

③ AI Agent が使うツールは最小限に
→ 安定性・再現性が向上。

④ thread_ts をセッションIDとして採用
→ Slack の仕様と一致し、直観的に理解しやすい。

⑤ context は「蓄積＋要約」が重要
→ 会話の一貫性を保つための必須設計。

■ 取りこぼしたこと（今後の改善ポイント）

JSON の入出力には Structured Output Parser を使うべき

LLM は JSON を壊しがちで、実運用ではパーサーの導入が必須です。

• 構造保証
• 型保証
• 軽微な誤りの補正

今回は ChatGPT o4-mini の安定性に甘えて省略しましたが、
他モデルを使う場合は必ず導入を推奨します。

■ 全体まとめ

n8n × LLM × Google Sheets を組み合わせることで、

• データベース不要
• ノーコード寄りで現場主導運用
• 外部デバッグが容易
• AI エージェントの拡張が簡単

といった実用的で強力な「対話型 AI システム」を構築できます。

Google Sheets を永続DBとして採用することで、
AI がどう判断したのかを後から確認できる透明性の高い仕組みが実現しました。

以上です！