Difyで実現するAIヘルプデスク：顧客体験を向上させた構築の裏側

こんにちは、kickflowでテクニカルサポートを担当している大谷です。

最近、多くのサービスでAIチャットボットを見かけるようになりました。kickflowでも、お客様の疑問をより迅速に解決し、顧客体験が向上することを目指し、AIヘルプデスクの構築に取り組みました。
今回のプロジェクトでは、テクニカルサポートチームが中心となり、CRE (Customer Reliability Engineer) と協力してAIヘルプデスクを構築しました。
この記事では、非エンジニアである私が、DifyというLLMアプリケーション開発プラットフォームを使い、プロンプトエンジニアリングを駆使して技術的な課題を乗り越えていったプロセスをご紹介します。
技術的な詳細やより深い知見については、今後CREから発信される記事に譲るとして、まずは非エンジニアでもAI開発に挑戦できるということをお伝えできれば幸いです。

完成したAIヘルプデスク
利用したツール：Dify
AIヘルプデスクを支えるチャットフロー
回答精度向上のためのアプローチ
プロンプトによる応答制御
継続的な運用を可能にするナレッジの自動更新
リリース後の課題
今後の展望
おわりに

完成したAIヘルプデスク

まず、今回構築したAIヘルプデスクがどのようなものかをご紹介します。
以下の画像のように、kickflowのヘルプセンターに埋め込まれており、ユーザーは24時間365日、いつでもkickflowに関する質問をすることができます。

利用したツール：Dify

今回のAIヘルプデスク構築には、DifyというオープンソースのLLMアプリケーション開発プラットフォームを利用しました。Difyは、GUIベースで直感的にLLMアプリケーションのワークフローを構築できるため、プログラミングの深い知識がなくても、迅速にプロトタイピングと改善を進めることができます。

特に、RAG(Retrieval-Augmented Generation)の仕組みを簡単に構築できる「ナレッジベース」機能は、私たちのプロジェクトに不可欠でした。この機能を使って、既存のヘルプセンター記事と過去の問い合わせ履歴という2つのナレッジをAIに学習させ、回答精度を向上させるアプローチを取りました。

AIヘルプデスクを支えるチャットフロー

私たちが開発したAIヘルプデスクは、Difyの「チャットフロー」機能を用いて構築されています。これは、複数のノードを組み合わせることで、複雑なAIアプリケーションの処理を視覚的に設計できるものです。

このフローは、以下の主要なステップで構成されています。

検索キーワード抽出：ユーザーの質問からLLMがキーワードを抽出し、検索精度を高めます。ここでは、スピードを優先してGemini 2.0 Flash Lite（執筆時点）を使用しました。
知識検索：事前に登録したナレッジから、抽出したキーワードをもとに適切な情報をハイブリッド検索（キーワード検索＋セマンティック検索）で探します。
IF/ELSE：検索結果がヒットしたかどうかで処理を分岐させ、適切な回答を生成します。
回答生成：検索で得られた情報をコンテキストとして、LLMがユーザーへの回答を生成します。回答品質を最優先するため、この部分にはClaude 4.0 Sonnet（執筆時点）を採用しました。
会話履歴の保持：各ステップで、ユーザーの入力とAIの回答を「会話変数」に保存し、マルチターンのやり取りでも自然な会話が続くように工夫しました。

このように、各ノードで異なるLLMを使い分けたり、処理を細かく分岐させたりすることで、単一のLLMでは実現が難しい、精度と応答速度を両立したシステムを構築することができました。

回答精度向上のためのアプローチ

AIヘルプデスクをユーザーに安心して使ってもらうためには、何よりも回答の精度が重要です。私たちは、精度を向上させるために、主に3つの工夫を行いました。

1. 過去の問い合わせチケットをナレッジとして活用

既存のヘルプ記事だけではカバーしきれない、より実践的な質問に答えるため、過去にZendeskで受け付けた問い合わせの中から約150件を抽出し、ナレッジ化しました。

具体的な手順は以下の通りです。

Zendesk APIで問い合わせのコメントデータを取得
取得したデータから個人情報を除去 (Gemini API)
問い合わせ1件ごとにMarkdownファイルへ分割
Difyのナレッジベースに手動で登録

Markdownへの分割処理では少しつまずきましたが、CREに協力してもらい、スクリプトを完成させることができました。

2. 複雑な質問は専用のノードで対応

「REST API / Webhook」のように、特定の複雑なトピックに関する質問は、汎用的なプロンプトではうまく回答を生成できないことがあります。

この課題を解決するため、Difyのワークフロー内で質問分類器のノードを使用しました。特定のキーワード（例：「Webhook」）を含む質問が来た場合に、そのトピック専用のプロンプトを持つノードに処理を振り分けることで、回答の精度を向上させています。

3. 実際の問い合わせデータを用いた継続的な精度評価

改善の効果を客観的に測るため、ナレッジ化していない過去の問い合わせデータをテストケースとして利用し、回答精度の評価と改善を繰り返しました。

この地道なチューニングにより、ヘルプ記事が存在する問い合わせに対する正答率を約70%から80%以上に向上させることができました。

プロンプトによる応答制御

精度向上だけでなく、AIの振る舞いを細かく制御することも重要です。例えば、以下のようなケースはプロンプトエンジニアリングによって対応しました。

AIが回答すべきでない質問への対応: 「承認経路を変更してほしい」「チケットの処理が終わりません」といった、個別対応が必要な質問には直接回答しないよう指示をしました。
表記ゆれの統一: 「Kickflow」や「KickFlow」といった表記を、正式名称である「kickflow」に統一して回答するよう制御しました。

これらの調整は、Difyのワークフロー内でプロンプトを編集することで実現しています。

継続的な運用を可能にするナレッジの自動更新

一度作って終わりではなく、継続的に運用していくための仕組みとして、ナレッジの自動更新を整備しました。ヘルプコンテンツやお問合わせ履歴は日々更新されるため、AIヘルプデスクのナレッジも常に最新の状態に保つ必要があります。
そこで、エンジニアの協力のもと、以下の2つのイベントをトリガーとして、ナレッジが自動更新される仕組みを構築しました。

ヘルプ記事が更新された時
問い合わせ対応がクローズされた時

この仕組みにより、手動での更新作業の手間をなくし、情報の鮮度を維持しています。

リリース後の課題

ヘルプセンターの記事を出典として明記するようにプロンプトに指示を入れていました。運用を開始後、しばらくすると「出典を開くとエラーになる」といった声が社内外から聞こえるようになりました。
ナレッジの中で回答が探せない場合に、事実に基づかない、もっともらしい嘘の情報を生成する、ハルシネーションが発生していました。この課題では、プロンプトを大幅に見直し、LLMが解釈しやすいプロンプトをGeminiと対話をしながら一緒に構築していきました。