こんにちは。RightTouchでProduct Engineerをしている松尾です。
このブログはQANTナレッジデスク(β)のリリースを記念した連載の第3回です。
これまでの連載では、以下のテーマを取り上げてきました。
本記事では、これまでの連載でも触れてきた「トークスクリプト機能」に焦点を当てます。
顧客の「リアル」を知ることから始める
ナレッジデスクは、生成AI時代における企業の「ナレッジ」を統合管理し、お客様とのコミュニケーション品質を支えることを目指しています。
開発にあたり、まずは統合的な管理を実現するために様々な企業様へヒアリングを重ねました。「実際にどのようにナレッジを管理・利用しているか」を深掘りした結果、見えてきた事実があります。
それは、コンタクトセンターを抱える企業の多くが、「トークスクリプト」を業務の核となるドキュメントとして使用しているということでした。
トークスクリプトとは、コンタクトセンターのオペレーターが顧客対応時に使用する、会話の流れや分岐を構造化したドキュメントです。オペレーターはこれを参照しながら顧客応対を行います。
しかし、一般的なナレッジ管理システムには、トークスクリプト特有の複雑でリッチな構造を表現できる機能は多くありません。その結果、多くの企業がExcelなどの描画ツールを駆使し、多大な工数をかけてスクリプトを構築・メンテナンスしていました。
私たちは、このアナログで管理コストの高いトークスクリプトを「構造化」してシステムに取り込むことこそが、プロダクトの価値につながると考えました。
顧客に Deep Dive し、解像度を上げる
実際にナレッジやトークスクリプトがどのように使われているのかを理解するため、複数のコンタクトセンターを訪問しました。応対環境や使用ツール、並行作業、通話後の処理まで一連の流れを観察し、現場の方から詳しく話を伺いました。
そこで見えてきたのは、オペレーターは多くのツールを行き来しながら応対しており、常にマルチタスクを強いられているという現実でした。 この状況では、少しの迷いがそのまま応対品質の低下につながります。「直感的に使えて迷わないUI」が不可欠だと強く感じたのは、このときです。
この学びを踏まえて、まずはトークスクリプトのプロトタイプを作成し、いただいた Excel のスクリプトをプロダクト上に再現しました。その上で、社内でロールプレイングを実施し、実際にその UI で応対が成立するかを検証しました。
2人1組になり、ユーザー役とオペレーター役に分かれて応対を進めていきます。 このロールプレイで痛感したのは、初心者にとって「スクリプトを読む」「相手の話を聞く」「相手の情報を調べる」「分岐を判断する」を同時にこなすのは想像以上に難しいということでした。 「相手を待たせてはいけない」という焦りと、「誤った案内をしてはいけない」というプレッシャーが重なると、冷静に全体を見渡す余裕がなくなり、スクリプトを追うことすら困難になります。
さらに、注意書きが画面端にあったり、補足情報がアコーディオンに隠れていたりすると、必要な情報に気づけないという問題が繰り返し発生しました。
約1時間のロールプレイで、視線誘導・分岐の見せ方・補足情報の扱いなど、数十の改善点が洗い出されました。 そして何よりも大きかったのは、オペレーターが置かれている認知負荷の大きさを、身体感覚として理解できたことです。
ロールプレイで得た認知負荷の感覚は、その後の UI 改善でも大きな参考になりました。 現場でどこに迷いが生じるのかを、より確かに捉えられるようになったと思います。
慣れ親しんだ見た目と、Webにしかできない表現
UI設計において意識したのは、「既存のExcel文化」と「Webならではの利便性」のバランスです。あまりに使い勝手が異なると、移行に対する心理的ハードルが高くなってしまいます。一方で、従来のトークスクリプトにあった「認知負荷の高さ」や「編集の困難さ」は解消しなければなりません。
例えば、Webビューアでは以下のような工夫を取り入れました。
- ルートのハイライト: これまで話してきたルートをクリックで強調表示し、選ばなかった分岐をグレーアウトさせることで、今の会話にフォーカスできるようにする。
- 選択肢の適正化: Excelでは無限に縦横に広がりがちな分岐を、Web上では「最大4つ」までに制限。それ以上となる場合は折りたたむことで、情報量を絞る。
これらは「工夫の一例」です。「本当にこれで現場の役に立つのか？」その答えを見つけるために、仮説で作った画面を顧客に見せ、実際のオペレーターやSV（スーパーバイザー）の方々に触ってもらう。そこでのフィードバックをもとに、また改善を加える。
私たちは今も、この地道なブラッシュアップを繰り返している最中です。
現場の声を聞けば聞くほど、改善の余地が見えてきます。
「もっと見やすく、もっと迷わない」体験を目指して、現在進行形でUI/UXを磨き続けています。
Excelからの移行：LLMを前提としたデータ構造の再設計
UIの磨き込みと並行して、最大の課題であった「移行コスト」の解決にも取り組んでいました。
多くの企業では、既に膨大な量のトークスクリプトがExcelなどで運用されています。新しいツールを導入する際、この既存資産を手作業で作り直すことになれば、導入のハードルは極めて高くなってしまいます。
そのため、既存のExcelファイルを「いかに少ない工数で取り込めるか」が重要なポイントでした。
これを実現するために開発したのが、LLMを活用したトークスクリプトの取り込み機能です。
開発にあたっては、LLMが生成しやすいデータ構造について根本的な検討を行いました。
初期の検討では、分岐の入れ子構造をそのままJSONで表現していました。しかし、トークスクリプトは分岐が多岐にわたるため、ネストが深くなるとLLMの生成結果が破綻しやすく、構造のエラーが頻発するという課題がありました。
そこで採用したのが、ノード同士を「隣接リスト形式」で表現する構造への転換です。
階層的な入れ子構造を持たせず、各ノードをフラットに配置し、次に進むステップIDや分岐先を外部参照として持たせる形にしました。
この構造により、LLMへの生成指示が格段にシンプルになり、複雑な分岐を持つスクリプトでも安定してデータ化できるようになりました。
結果として、LLMによる取り込み結果をベースに微調整を行うだけで済み、1つのトークスクリプトあたり10〜20分程度でプロダクトへの移行が完了するという成果が得られました。
おわりに
今回の開発を通じて、改めて 「現場を知ること」 の重要性を痛感しました。
泥臭いロールプレイや現場観察があったからこそ、机上では到達できない解像度で課題を捉えられ、価値あるプロダクトへと繋げることができたのだと思います。
顧客の課題に深く潜り込み、それを技術によってシンプルに解きほぐす。
これからもこの姿勢を大切にしながら、本質的な課題解決に挑み続けていきます。
採用情報
RightTouch では、Product Engineerをはじめ、プロダクト価値を一緒に育てる仲間を積極採用中です。カジュアル面談も歓迎しています。ご興味があれば、ぜひ採用ページをご覧ください。
