ZendeskのチケットをAIチャットボットで活用するバックエンドを構築した

Zendeskのチケットを AIチャットボットで活用する バックエンドを構築した 2025.9.24 Wed. 第27回 Customer系エンジニア座談会 株式会社kickflow プロダクト開発本部 CRE / 西山 良

自己紹介 ⻄⼭ 良 / Tsukasa Nishiyama ● 経歴 ○ 株式会社はてな（2019.05 〜 2024.02） ■ ○ 株式会社kickflow（2024.03 〜） ■ ● ● Mackerelチーム CRE プロダクト開発本部 CRE 趣味 ○ キャンプ🏕 ○ 深夜ラジオ📻（週末にまとめて聴く派） SNS ○ @tukaelu / id:tukaelu 2

kickflowについて

kickflowとは 中堅〜⼤企業をターゲットにした 稟議‧ワークフローSaaS 「クラウドのラクさ」と「オンプレの機能性」を両⽴ © kickflow, Inc. 4

今日お話すること ● 最近、kickflowのヘルプセンターに導入した AIヘルプデスクのこと ● その裏側で日々のサポート対応で生まれる資産を活かすための工夫と仕組みについて 5

【宣伝】 Difyで実現する AIヘルプデスク：顧客体験を向上させた構築の裏側 https://tech.kickflow.co.jp/entry/2025/09/03/123008 6

• https://tech.kickflow.co.jp/entry/2025/09/03/123008

『AIヘルプデスク』とは？ 7

AIヘルプデスクを導入するに至った経緯 kickflowはワークフローの申請フォームや承認経路を柔軟に設計・実装できる。 例えば、「申請者の属性」や「フィールドの入力値」に応じて、次のようなことができる。 ● セクション（単一・複数の入力フィールドのブロック）の表示切り替え ● フィールドの入力値を使った計算 ○ ● フィールドごとに変数名が割り振られ、計算するための様々な関数が用意されている 承認経路を動的に切り替える など... 拡張性が高いので 『これはできる？』『どういう式を組めばいい？』 といった問い合わせがある。 → このようなユーザーの疑問・課題を迅速に解決して、顧客体験を向上につなげたい！ 8

ということで、 Difyで構築した（※画面は開発中のものです） 9

LLMが参照するナレッジベースを整える Difyの「知識検索」で使用するナレッジには、次の 2つを採用した。 ● Zendeskで公開しているヘルプセンターの記事 ○ ヘルプの記事は Markdown化してGitHubで管理・執筆をしていたので、 リポジトリで管理している Markdownファイルをそのまま Difyに登録した ○ ● PRのマージをトリガに記事を公開しているので、ナレッジの更新もそれに倣った Zendeskで対応したサポートチケット ○ Zendesk API（Tickets / Comments）からチケットを出力する GASを実装 ■ ○ 個人情報（社名や個人名など）を LLMに除去させてファイル出力 テクニカルサポートチームの目 grep（👀）によるチェックの後に Difyに手動で登録 10

umm... 🤔 11

サポートチケットの運用がしんどくないか？ ● GASは良きタイミング（チケットのクローズ後）に実行する必要がある ○ ● クローズされるタイミングはチケットごとに異なる サポートチケット（メール）を人の目で再びチェックするのはしんどい 👀💫 ○ 引用文やビジネス的なやりとりを多く含みがち ■ ○ 『知識』としたい本質的な情報 < そうではない部分 個人情報を除去するキツめのプロンプトを書いても残ってしまうことがある ■ 個人情報はナレッジベースには絶対に混入させたくない 󰢃 テクニカルサポートチームの日々の業務の負担（ Toil）になってしまうのは避けたい ... 12

サポートチケットをより簡単にナレッジ化する仕組みを作ることにした 13

サポートチケットのナレッジ化でやったこと ● LLMにサポートチケットを 『要約』 させることにした ○ 個人情報の除去から、知識化すべき要点の抽出にフォーカス ■ ● 『ユーザーの課題』 と『課題を解決する方法』 ○ チケット内の具体的な表現はいい感じに抽象化し、より汎用的な知識にする ○ 生成した要約をナレッジとすべきかを LLM自身に評価させた ヘルプセンターと同じように GitHubのPRベースの運用とした ○ チケットがクローズしたタイミングで要約化して PRが作成される ○ テクニカルサポートチームは普段からヘルプ記事の執筆のために PRを作っているので 学習コストも低く始めることができる これで、 作成された 要約をナレッジとして反映するか判断 するだけ になるはず 🙌 14

要約させるためのプロンプト（抜粋・例） テクニカルサポートの会話の履歴から、AIサポートエージェント向けの学習データを生成します。 以下に定義したルールをもとに、チケットのやりとりからユーザーの課題（ Q）とその解決方法（ A）を抽出・生成してください 。 ## 学習データの生成に関するルール - 『チケットのやりとり』を読み込んで、ユーザーの課題（Q）とその解決方法（A）を抽出します。 - 会話はマーカーで区切られ、最初のマーカーより上に記載されている内容が問い合わせ本文です。 - 基本的には最初の問い合わせにユーザーの解決したい課題が記載 されています。 - ただし、詳細にヒアリングして課題を適切に突き止めることもあるため、すべてのやり取りを注視 してください。 - ユーザーの課題を抽出する際は以下の点について考慮・注意をしてください。 - 氏名、会社名、メールアドレス、電話番号などのような個人情報は絶対に含まないよう除外してください。 - 簡潔にまとめすぎると、学習データとして有効に機能しない可能性 があるので気をつけてください。 - 問い合わせをしたユーザー固有の名称や用語と思われる場合は、汎用的な言い回しに置き換え てください。 - 解決方法には、課題を解決するためにユーザーが行うべき手順を簡潔に記載してください。 - 抽出したユーザーの課題（Q）とその解決方法（A）を、『出力フォーマット』で規定した通りに出力します。 - 最後に「学習データ化の可否」について、あなたの判断をコメントして ください。 - テクニカルサポートチームは、この可否コメントも参考に学習データとするかを判断します。 : 15

要約をアウトプットするフォーマット ## ユーザーの課題 {抽出したユーザーの課題（ Q）のテキスト } ## 解決方法 {抽出した解決方法（ A）のテキスト } ## 学習データ化の可否 **{可 / 否}** 理由： - {理由を簡潔に箇条書き } - {理由を簡潔に箇条書き } : 最終的には網掛け部分 がDifyにナレッジとして 反映される 16

チケットがクローズすると PRが作られていく 17

細かい作業は Claude Code Actionに任せる 18

まとめ ● 日々積み上がるサポートチケットを、効率よく生成 AIの学習データとして 役立てることができた（はず？） ○ 要約の精度の評価、 AIヘルプデスクの評価（ KPIの策定など）はこれから ● 小さな作り込みでも『 Toilの削減』と『顧客体験の向上』の実現はできる ● AIを活用した顧客体験の向上施策のひとつとして参考になると嬉しいです ● みなさまのAI活用事例もぜひ伺ってみたいです 19

ご清聴ありがとうございました！