RAGで社内マニュアルに答えるAIを1カ月で構築、薬局検索サイト運営社の検証

問い合わせは電話、メール、Webフォームと複数の窓口から届き、対象となるサービスもオンライン診療や服薬指導、お薬手帳と幅広く広がっていました。サービスごとに専門用語もオペレーションも違うため、答える従業員の理解度によって回答の中身に差が出る。同社が最初に見つめ直したのは、この回答品質のばらつきでした。

編集部の見立てでは、困りごとの本質は従業員の能力差ではなく、事業が広がるほど覚えるべき知識が増え続けるという構造そのものにあったのではないでしょうか。マニュアルが存在していても、それがサービス単位で散らばっていれば、問い合わせを受けた人は「どの資料のどこに書いてあるか」を毎回探し当てなければなりません。そこへ、自社プロダクトの開発を優先する方針から検証にリソースを割けないという事情が重なり、社内で解決策を試すこと自体が難しい状態にあったと考えられます。

顧客ではなく従業員を利用者に据えた設計が、この取り組みの起点になっています。最終的な目標を問い合わせシステムへの組み込みに置きながら、まず作られたのは、従業員が質問して精度の高い回答を得たうえで、自分の言葉で顧客に返すための社内向けボットでした。AIの回答がそのまま顧客に届かない構造にしておけば、精度が十分でない段階でも実運用に近い形で試せます。検証を止めずに前へ進めるうえで、この線引きが効いたと考えられます。

情報源をサービス単位で切り分け、3種類のアプリとして分けた点も見逃せません。専門用語もオペレーションも異なる複数サービスを一つのボットにまとめれば、参照すべき文書が混ざって回答が曖昧になりやすい。困りごとの構造に合わせて、器のほうを分けた判断です。実装は社内チャットのSlackアプリとして載せる形をとり、クラスメソッドが、情報源となるドキュメントを扱うためのセキュアな環境と、言語モデルが持たない社内固有の情報を参照させるRAGの仕組みをAWS上に構築したうえで、基盤モデルの選定もあわせて担いました。

精度が出ないことを前提に置いた改善の分解も、この進め方の特徴です。課題は、製品の操作マニュアル自体が不足している点と、プロンプト（質問の入力内容）に対してAIが完全な回答を返せていない点の二つに整理されています。前者はマニュアルの修正・追加によるドキュメント整備で、後者は正しい質問の書き方を検証し、適切な質問方法をアプリ上で説明する運用改善で手当てする。原因を文書側と使い方側に切り分けたことで、「精度が低い」という漠然とした状態が、担当を決めて着手できる作業へと姿を変えたのではないでしょうか。

2023年10月のキックオフから約1カ月でPoC検証用の環境が立ち上がり、サービス別に3種類のSlackアプリが用意されました。2023年12月からは社内検証が始まり、精度検証と利用後のアンケートを通じて社内からの要望を集めている段階です。回答精度についてはまだ課題が残ると同社自身が捉えており、ドキュメント整備と質問方法の改善を並行して進めながら、2024年春には新人教育用の生成AIチャットボットを社内ローンチする予定です。