※この記事は、2025年8月に開催されたイベントでの発表内容をレポートしたものです。
登壇者はこの方
鴨田 将来（Masayuki Kamoda）
エムスリー株式会社
AI・機械学習エンジニア
自動運転向け機械学習システムや大量文書RAGシステムの構築などを経験。2024年にM3にJoin。主に製薬企業向け機械学習システムを担当
鴨田：本日は、以下の3点についてお話しします。
①問い合わせデータさえあれば、FAQサイトを自動で生成できる
②その実現のために、分類、クラスタリング、生成、検索という一連の技術を総合的に活用している
③デモの作成からリリースまでをわずか1ヶ月というスピード感で開発した
この3つをお伝えできればと思います。
FAQサイトの運用と課題
それではまず、FAQサイトの運用においてよく直面する悩みについてお話しします。
FAQサイトのメンテナンスは非常に大変な作業です。代表的な課題として3点挙げられます。
まず1つ目は、「ユーザーが正しい情報を見つけられない」という問題です。ユーザーが使う言葉とFAQで使われている専門用語が異なれば検索にヒットしにくくなりますし、同じような質問が複数存在すると、どれが正しい情報か判断しづらくなります。また、カテゴリー分けが直感的でなく、どこに情報があるか分かりにくいというケースも少なくありません。
2つ目は、「コンテンツ作成の負担が大きい」という点です。寄せられた個別の問い合わせ内容を、誰もが理解できるように抽象化してFAQを作成するのは、大変な労力を要します。さらに、FAQを作成できる担当者が限られているために更新が滞ってしまったり、どれだけ手間をかけても問い合わせ件数の削減に繋がっているか効果が見えにくいため、モチベーションの維持が難しいという課題もあります。
そして3つ目は、結果として「問い合わせ数が減らない」という問題です。例えば、サービスが成長していくのと同じペースでFAQサイトが成長したとしても、新しい機能に関する質問の多くはコールセンターに向かいます。つまり、FAQサイトによる問い合わせ数の減少分に対して、サービス成長による増加分が常に存在するのです。これによりコールセンターの業務が圧迫され、電話での対応がスムーズにいかなくなると、最終的にはユーザー体験を損ねることにも繋がりかねない、無視できない課題です。
やりがちな対策
こうした課題に対し、一般的な対策がいくつかあります。
1つ目は、とにかくFAQの数を増やすというアプローチです。問題の網羅率を上げる観点では有効ですが、一方で類似した内容のコンテンツが乱立し、かえって検索しにくくなるというデメリットも生じます。また、FAQの数が増えれば増えるほど、そのメンテナンスにかかるコストも増大します。そのため、FAQを増やす分だけ、検索体験も改善する必要があります。
2つ目は、カテゴリーを細分化する方法です。これもコンテンツを増やすという点では1つ目と似ていますが、ユーザーが考える分類と運営側が設定した分類に齟齬があると、ユーザーを迷わせてしまう原因となります。
最後に、人員を増やすという対策です。FAQのメンテナンスやコールセンターの人員を増強することは、一時的な解決にはなりますが、根本的な問題解決には至りません。リソースを増やすという対策は、時間もコストもかかる上、すぐには実行できないのが実情です。
このような状況の中、私たちは「なるべく早く、かつリソースを増やさずに状況を打開したい」という、一見すると矛盾した要求に応える方法を模索しました。その結果、我々AI機械学習チームが提案したのは、「コールセンターがお客様対応をしていれば、自動的にFAQサイトが生成・更新される」という仕組みです。これにより、ユーザーは欲しい情報をすぐに見つけられるようになり、コールセンターは同様の問い合わせ対応から解放されるという、双方にとってメリットのある状態を目指しました。
課題に対しての具体的な解決策
それでは、具体的な解決方法についてご説明します。
既存システムを踏襲したFAQ作成方法
まず、従来のFAQ作成・追加フローをご説明します。問い合わせを既存カテゴリーに分類し、カテゴリーがない場合は担当者が新たに作成し、FAQとともに既存システムに追加していました。しかしこの方法では、カテゴリーの分け方が担当者の主観に偏ってしまい、また、作成したFAQの問い合わせ削減への貢献度が把握しづらいという問題がありました。
そこで、AI機械学習チームは、問い合わせ履歴を基に、分類、クラスタリング、生成という3つのプロセスを組み合わせて、この課題を解決しました。
まず第1段階の「分類」では、電話での問い合わせ履歴と既存のFAQデータを突合させ、「FAQの作成が必要な問い合わせ」と「そうでないもの」を自動で分類し、必要な問い合わせのみを抽出します。
次に「クラスタリング」では、抽出された問い合わせを内容の類似性に基づいてグループ分けします。これにより、担当者の主観に頼ることなく、問題のイシューごとに客観的な粒度でFAQをまとめることが可能になります。
最後に問い合わせクラスごとに生成AIを用いてFAQを作成します。今回は問い合わせ件数の削減という目的を達成するため、プロンプトには「不明な点はカスタマーセンターへ」といった、電話での問い合わせを促すような文言を入れないよう工夫しています。
さらに、これらのプロセスでFAQを自動生成するだけでなく、その先の検索システム自体も改善しました。今回の仕組みを導入したことで、既存の約700件のFAQに対し、新たに5000件ものFAQが生成され、コンテンツが大幅に増加しました。この大量のコンテンツの中からユーザーが必要な情報を見つけ出せるように、検索ロジックの見直しも行いました。このように、問い合わせ減少という最終目的に対し、既存の仕組みにとらわれず、検索ロジックの見直しを含む最も効果的なアプローチを総合的に実行しました。
今回ご紹介したフレームワークは、FAQサイトの構築に限らず、様々な場面で応用できると考えています。例えば、「製品の改善提案」というテーマであれば、ユーザーからのフィードバックを「要望」や「不具合報告」に分類し、類似の要望をクラスタリングした上で、具体的な改善提案や開発タスクの仕様書、チケットのドラフトなどを生成AIが作成します。そしてその作成された開発タスクをさらにJiraやRedmineといったプロジェクト管理ツールに自動で起票することが可能です。
また、「業務効率化」という側面では、社内のSlackやメールといったテキストデータから、業務に関する質問と回答のペアやノウハウを抽出し、分類・クラスタリングを行います。そして、それらを基に社内版FAQや業務マニュアルのドラフトを生成AIで作成し、社内Wikiなどに自動で登録するといった活用が考えられます。このフレームワークは、社内に散在しがちなテキストデータを価値ある資産へと変える、非常に強力な仕組みであると確信しています。
運用面におけるシステムの自己進化
次に、このシステムが「自己進化」する仕組み、特に運用面について詳しくご説明します。
まず、生成されたFAQのレビューから検索システムへの投入までの流れです。ここで注目すべき点は、生成された新しいFAQと既存のFAQの両方を、一括で効率的にブラッシュアップできる仕組みを導入したことです。
生成AIにはハルシネーションがつきものなので、そのチェックはもちろん必要です。それに加え、FAQごとにユーザーからのフィードバックを収集できる仕組みを設けました。これにより、新旧問わず全てのFAQを継続的に改善していくことが可能になっています。
また、検索対象となるFAQを容易に変更できる仕組みも構築しました。現在はレビュー済みのFAQを検索エンジン（今回はElasticsearchを使用）と定期的に同期しています。従来であれば、特定のFAQを検索対象から外すには手間がかかりましたが、本システムでは担当者がFAQのステータスを「レビュー済み」から「未レビュー」に変更するだけで、次回の同期時に自動的に検索対象から除外されるようになっています。
この仕組みにより、「まずはFAQを公開してみて、もし問題があれば一時的に非公開にする」という柔軟な運用が可能となり、レビューの速度向上に繋がっています。さらに、検索ログや問い合わせ履歴を活用し、検索の最適化も行っています。
具体的には、電話での問い合わせ内容と関連付けられたFAQの参照回数をカウントし、その回数が多い、いわゆる「ホットなFAQ」ほど検索結果の上位に表示されやすくなるよう、検索スコアを調整しています。
ここで、「検索結果のクリックログだけを使えば良いのではないか」という疑問が浮かぶかもしれませんが、実際にはFAQサイトを全く参照せずに直接電話でお問い合わせをされるお客様もいらっしゃいます。そのため、電話での問い合わせ内容も加味することで、より実態に即した「ホットなFAQ」を特定し、ユーザーが必要とする情報へたどり着きやすくしています。この工夫により、曖昧なキーワードでの検索であっても、今まさに多くの人が困っている問題に関するFAQが見つかりやすくなっています。
開発速度について
これはフレームワークとは少し離れますが、開発速度についても少し自慢させてください。
このプロジェクトは、通常であれば半年から1年を要するところを、わずか1ヶ月という短期間でのスピード導入を実現しました。依頼を受けてから最初のミーティングを行い、約1週間後には関係者のみがアクセスできるデモサイトをリリースしました。これは、生成AIの能力を最大限に活用したからこそ可能になった速度感です。
残りの3週間では、デモ用のコードを製品レベルの品質に高める作業や、他サービスチームとの連携、ログの調整、そしてインフラの整備などを行いました。特に私が苦労したのはインフラ整備でしたが、SkaffoldやHelmといったツールを活用して、GCP上へのデプロイ作業をワンボタンで実行できるように自動化したことで、大幅な効率化を図ることができました。
リリース後も、実際に問い合わせ件数が減少しているかの効果検証を地道に行ったり、新たなお問い合わせ内容を基にFAQの整備を続けたりしています。このように、生成AIの活用と、リリースしやすい基盤整備が、高速な開発サイクルを実現する鍵となりました。
まとめと学び
個人的な学びとしては、新規開発の際に既存の実装や前提条件にとらわれず、「問い合わせ数を減らす」という本来の目的に対して最適なワークフローは何かをゼロベースで考えることの重要性を再認識しました。また、私自身、アプリケーション開発からインフラ構築までを一気通貫で担当したのは初めての経験で、このプロジェクトを通じてGCPについて少し分かるようになったと思います。
私からの発表は以上となります。
▼▼ ぜひ他登壇者の発表レポートもご覧ください
