社内問い合わせの集中をAIチャットボットで解く、Q&A整備の進め方

導入前の状況を整理すると、社内ポータルの掲示板に質問と回答を掲載し、解決しない場合はヘルプデスクが電話で応じる体制でした。ところがサブスク型クラウドサービスが広がり、アップデートや新機能に関する問い合わせが増加。掲示板に載っている内容でも直接電話が来るようになり、しかも始業時や終業前に問い合わせが集中していました。

編集部の見立てでは、ここでの困りごとは単なる問い合わせ件数の増加ではなく、「答えはすでに用意されているのに、利用者がそこにたどり着けていない」という到達の問題だったのではないでしょうか。掲載済みの情報がありながら電話が鳴るのは、掲示板が探しにくかったり、そもそも探す前に人に聞いたほうが早いと判断されていたことを示しています。加えて、対応が日中に限られていたことで、質問が集中する時間帯と対応可能な時間帯がずれていた点も、負担を押し上げていたと考えられます。

うまくいった背景としてまず挙げたいのは、利用者側の言葉のばらつきを受け止める設計を最初から重視した点です。社内問い合わせでは、同じ内容でも人によって言い回しが変わります。採用されたシステムは独自のテキスト含意認識技術で多様な表現の意味を解析する仕組みを持ち、日本語の「ゆらぎ」を吸収する前提で設計されました。答えが用意されていても検索でたどり着けなければ電話に戻ってしまう以上、この「表現の違いを許容する」入口の設計が、自己解決を後押しする鍵になったと見られます。

次に効いたと考えられるのが、既存資産を作り直したうえで載せ替えた運用の手順です。掲示板の情報をそのまま流用するのではなく、AIチャットボット向けにQ&Aとシナリオへ再構築しています。単なる移植ではなく、チャットで答える形に合わせて質問と回答を組み直したことが、回答の精度につながったのではないでしょうか。

そして、自社だけで抱え込まなかった点も見逃せません。ゆらぎをどこまで許容するかの見極めや整備が難しい部分をベンダーであるNECが支え、約5カ月で約200種類の質問を想定した内容を整えています。非IT技術者でも運用できる操作性を条件に置いたことは、稼働後に情報システム部門が自ら手を入れ続けられる状態を意図した選択だったと考えられます。

成果として挙げられているのは、マニュアルやFAQの作成工数の大幅な削減です。従来は画面のスクリーンショットを多用した網羅的な資料を作っていましたが、質問文と回答文を短文でフォーマットに入力するだけで済むようになりました。今後は利用件数や時間帯別の状況、正答率などを定期的に分析してQ&Aの範囲拡大や改善を続ける計画で、情報システム以外の部門への展開や、手続き処理の実行までをガイドする仕組みへの発展も視野に入れています。