AI・機械学習チームの鴨田です。 この記事はエムスリー Advent Calendar 2025の21日目の記事です。 20日目は星川さんのSlackワークフロー使いこなせてる？進化したトリガーとリストで実現するハックでした。
TL;DR
- 問い合わせログからFAQ記事を自動生成するパイプラインを構築
- パイプラインはFAQ以外にも応用可能
日々、企業のシステムには膨大な「テキストデータ」が蓄積されています。問い合わせログ、社内チャットツールでの会話、メールでのやり取りなど...これらは「フロー情報」として消費されるか、あるいはDBの肥やしとして眠ったままになりがちです。
そんな中、LLM（大規模言語モデル）の登場により、これらの非構造化データを「ストック情報＝資産」へと変換するコストが劇的に下がりました。
本記事では、私たちが実際に構築・運用しているFAQシステムを事例に、そこで採用したデータ処理パイプラインの詳細と、その汎用的な可能性についてお話しします。
※この記事は2025/8/20(水)に行われたオンラインイベントで発表した内容をブログ化したものです
背景
サービスが成長するにつれ、サポート窓口には日々大量の問い合わせ（＝ユーザーの生の声）が寄せられます。理想的にはこれらを余すことなくFAQ化し、自己解決率を高めるべきですが、人力での運用には限界があります。
コンテンツ作成の負荷: 個別の問い合わせ内容を咀嚼し、抽象化し、万人に通じるFAQ記事へと昇華させる作業は非常に高コスト。
検索性の低下: 網羅率を上げようと記事を乱造すると、類似記事が増えることで検索ノイズとなる。
この状況を「リソースを増やさず」に解決するため、私たちはサポート窓口への問い合わせを起点として、自動的にFAQサイトが生成・更新されるシステムの構築に着手しました。
分類・クラスタリング・生成の3ステップパイプライン
ログデータから質の高いFAQ資産を生成するために、次の3段階のパイプラインを構築しました。
1. 分類（Classification）：
最初のステップは「分類」です。 すべての問い合わせがFAQ化に適しているわけではなく、既にFAQが存在する内容も含まれています。
ここでは、日々の問い合わせ履歴データ（担当者による解決方法も記載されたもの）と、既存のFAQデータベースを突合させます。LLMを用いて「既存のFAQで解決可能なもの」と「新規にFAQ作成が必要なもの」を分類し、後者のみを抽出します。これにより、パイプラインの後続処理に流すデータの純度を高めます。
2. クラスタリング（Clustering）：
次のステップは「構造化」です。 抽出された「FAQ化すべき問い合わせデータ」をEmbeddingし、意味的な類似性に基づいてクラスタリングを行います。
従来の手法では担当者が主観で決めていたカテゴリを、機械的なベクトル空間上でのクラスタリングを採用することで、実際にユーザーが抱えている課題（Issue）の粒度で客観的にグルーピングが可能になります
これにより、「同じような質問に対するFAQが微妙な表現違いで複数存在する」という乱立状態を防ぎ、1つのIssueに対して1つのFAQ記事を生成できます。
3. 生成（Generation）：
最後のステップが「生成」です。 特定されたクラスタ（Issue）ごとに、LLMを用いて回答記事のドラフトを生成します。
ここでは単なる要約ではなく、FAQサイトとして成立させるためのプロンプトエンジニアリングが重要になります。例えば、「詳細はサポート窓口へお問い合わせください」といった、対応を誘発するような文言を出力させないよう制約をかけます。FAQの目的は自己解決であるため、解決策を具体的に提示するコンテンツを生成させます。
運用設計
生成AIを活用したシステムにおいて、ハルシネーションのリスク管理と、継続的な品質改善は不可欠です。私たちは運用フェーズにおいても次の2つの仕組みを導入しました。
FAQレビューと即時反映の仕組み
生成されたFAQはそのまま公開するのではなく、Human-in-the-loop のプロセスを経ます。ここで重要なのは、レビューのハードルを下げる工夫です。
検索エンジン（今回はElasticsearchを採用）へのインデックス登録において、各FAQ記事に「レビュー済み」「未レビュー」といったステータスフラグを付与しました。 システムは定期的にDBとElasticsearchを同期しますが、この際「レビュー済み」の記事のみを検索対象とします。
これにより、運用担当者は管理画面上でステータスを変更するだけで、記事の公開・非公開を即座にコントロールできます。もし公開後に問題が見つかれば、ステータスを戻すだけで検索結果から除外できるため、「まずは公開してみて、フィードバックを得る」というアジャイルな運用が可能になりました。
また、各FAQページにはユーザーからのフィードバックボタンを設置し、その評価データを次回の生成や修正サイクルに回すことで、新旧問わずコンテンツの質が継続的に向上するループを作っています。
実際の問い合わせ行動を加味した検索スコアリング
FAQ記事が大量に増えたことで、検索エンジンのランキングロジックの最適化も必要となりました。 一般的に、検索システムの改善には「検索ログ」や「クリックログ」が用いられます。しかし、FAQサイト特有の事情として、「ユーザーがFAQで解決できずに直接問い合わせてきている」という事実があるのでそれも有効活用することにしました。
問い合わせ内容を分類し、対応するFAQ記事を特定する（パイプラインの分類フェーズ）
直近で問い合わせ流入が多いトピック（＝ホットなFAQ）の参照カウンタを増やす。
Elasticsearchでの検索時、このカウンタ値を重み付けとして利用し、ホットなFAQを上位に表示させる。
これにより、ユーザーが曖昧なキーワードで検索した場合でも、今まさに多くのユーザーが直面し、問い合わせが発生しているトラブルに関する記事が優先的にヒットするようになりました。Web上の行動と実際の問い合わせ行動のデータを統合することで、実需に即した検索体験を提供しています。
FAQ以外の応用
今回ご紹介した「分類・クラスタリング・生成」というフレームワークは、FAQ生成に限らず、社内のあらゆるテキストデータの活用に応用可能です。
プロダクト改善
ユーザーからのフィードバックや要望（Voice of Customer）をこのパイプラインに適用する事例です。
分類: ユーザーからの声を「機能要望」「不具合報告」「UI/UXへの不満」などに分類
クラスタリング: 類似した要望をグルーピングし、要望の多さ（クラスターのサイズ）を可視化
生成: LLMを用いて、各クラスターに対する「具体的な改善提案」や「開発チケット（仕様書）のドラフト」を生成
これをJiraやRedmineなどのプロジェクト管理ツールのAPIと連携させれば、ユーザーの声を起点とした開発タスクの起票までを自動化できます。
ナレッジマネジメント
社内のSlackやTeams、メールでのやり取りをソースとする事例です。
分類: 日々の会話ログから「業務に関する質問と回答」のペアが含まれるスレッドを抽出
クラスタリング: 業務ドメインやプロジェクトごとに話題を整理
生成: 抽出したQ&Aやトラブルシューティングの過程を、社内Wiki（Confluence等）や業務マニュアルの形式に整形して出力
これにより、特定の個人の頭の中やチャットのログに埋もれていたデータを、組織全体で参照可能な知識へと自動的に変換・蓄積することが可能になります。
まとめ
本記事では、エムスリーのAI・機械学習チームが取り組んだ、LLMを活用したデータ処理パイプラインついて解説しました。
繰り返しますが、ご紹介したパイプラインはFAQ生成に限らず、社内のあらゆるテキストデータの活用に応用可能です。社内AI活用でお困りの方はぜひこのパイプラインを活用していただければと思います（実際にやってみると、色んな”気付き”があると思うのでぜひコメントで教えてください）
余談ですが、このプロダクトはPoCから本番リリースまで1ヶ月というスピードで開発しました。
M3のテックブログを普段読んでいる方なら把握されていると思いますが、AI・機械学習チームにはこのようなシステム開発基盤が整っていたため実現が可能でした。
基盤技術を支えるテーマの記事はたくさんありますのでそちらも合わせて読んでいただけると嬉しいです。
We are hiring!
AI チームでは、LLMをはじめとする機械学習技術を用いて、実社会の複雑な課題解決に取り組むエンジニアを募集しています。 ご気軽にカジュアル面談からでも応募をお待ちしております！
