はじめに
RightTouchでProduct Engineer（以下 PdE）として QANTナレッジデスク の開発リードをしている小室(com)と申します。 1年4ヶ月ほど前にRightTouchにジョインして以来、新規プロダクトとして開発を進めてきた QANTナレッジデスク ですが、この度無事βリリースが完了し、プレスリリースを発表しました！
リリース記念として4回にわたってナレッジデスクの開発の裏側について紹介していきます。
初回の本記事では、エンジニアの皆さんをはじめ、プロダクト開発に携わるみなさんを想定読者として、QANTナレッジデスク の概要から、やや技術寄りの話題までを、プロダクトエンジニアの視点で丸っと振り返って、まとめたいと思います。
QANTナレッジデスク について
QANTナレッジデスク はいわゆるナレッジマネジメントシステムです。Notionのようなツールをイメージして頂くと分かりやすいですが、toC向けの汎用ツールではなく、特にコールセンター業務のマニュアル管理に特化したシステムという点が大きく異なります。
現在、カスタマーサポート業界では生成AI（LLM）の登場によって大きな転換期を迎えています。従来は人間のオペレーターが1件ずつ顧客と向き合って対応する必要があり、一説には「企業へ届く顧客の声は全体の2%」とも言われています。残り98%の顧客は、負を抱えていても接点がなく、フォローされないままでした。
しかし、LLMの普及によって、従来はコスト的に不可能だった顧客接点にリアルタイムでアプローチできる可能性が生まれてきています。AIチャットや自動音声対応といったサービスがその代表例です。今後はさらに高度で多彩なAIエージェントが活躍していくでしょう。
そして、AIエージェントを「正しく・高品質に」動かすためには、良質なデータ（ナレッジ） が不可欠です。 これこそが、ナレッジマネジメントの価値そのものです。
ただし、カスタマーサポートの現場では歴史的に、情報の分断や管理工数の増大など、多くの課題が存在していました。 QANTナレッジデスク は、カスタマーサポートの現場で利用されるナレッジを統合管理し、AIを活用して改善を円環する次世代のナレッジマネジメントを実現させて行くことをビジョンとしています。
▼「QANT ナレッジデスク（β）」サービスサイトURL
https://qant.jp/product/knowledge-desk
First Issue
上記で説明した概要は長期的な青写真になります。
開発当初は最初に製品としてリリースする機能スコープとして、「First Issue」を落とし込んでいきました。
最終的にはAIエージェントが自律的に顧客対応できる世界が理想です。しかし、現状のLLMではまだ限界がありますし、人間ならではの温かみや柔軟性は今なお重要で、すべてをAIで代替することはできません。
そこで、車の自動運転に例えると、いきなりに完全自動運転(Lv5)を目指すのではなく、まずはLv2、Lv3のような部分的な自動運転を進めていくのが現実的だと考えました。
一方で、コールセンターでは人材確保が年々難しくなっています。 対応内容は複雑化・高度化する一方で、人材の流動性も高まっており、新人がベテランへと成長するまでに5年、10年とかかるケースも少なくありません。
このギャップを埋めるため、私たちのチームでは次の課題を最初のターゲットに据えました。
「新人オペレーターでも、無理なく高品質な応対ができるようにする」
開発の組織について
ここからは、プロダクトそのものから少し視点を変えて、開発の進め方や組織面の話をまとめていきます。
RightTouchの開発組織の特徴として、エンジニアの裁量や責任範囲は非常に大きく、柔軟なタスク管理で開発を行っていることが挙げられます。
私自身、前職では専任のスクラムマスターを置いた、わりと「きっちり目」のスクラム開発で進めていました。そのため、RightTouchにjoinした当初は、開発文化の違いに大きなギャップを感じることがありました。
当初は、自分なりにプロセスを形にしようと、チームにスプリントバックログやスクラムイベントを導入する運用も試してみました。しかし、新規開発であることや、PdE の裁量の広さといった要因から、決めすぎたプロセスが現実にそぐわない場面も多く見えてきました。
また、同僚のエンジニアも非常に経験豊富(シニア)かつプロダクト指向なエンジニアで構成されているため、プロセスをあえてスキップした方がより成果が最大化しやすいという実感がありました。
そこで、私たちは 「振り返り駆動」的なプロセス で運用することにしました。
- 毎週の「Dev Mtg」で
- 1週間の進捗共有
- 短期・中期の構想のすり合わせ
- そのうえで、次の1週間の行動を各自が自己補正しながら進めていく
という流れです。
少しおこがましい表現ですが、「守破離」でいうところの 破 にあえて挑戦することで、限られたリソースを最大限に活かしつつ、実験的な実装も柔軟に進められるようになりました。
詳しい取り組みについては、以前まとめた記事がありますので、よろしければそちらもご覧ください。
しかしながら、最近ではプレスリリース にもある通り、プロダクトが実際の顧客に利用され始め、社内的にも「基盤プロダクト」として期待値が上がってきています。それに伴い、チームも徐々に大所帯となってきました。
その結果、一つひとつの開発案件も大きくなってきており、これまで以上にフロー効率を意識した進め方に変更していく必要を感じ初めています。
私は、プロセスにはある種の「不可逆的な意思決定」が含まれると考えています。そのため、いかににYAGNIの精神を保ちつつ、それでいて「手遅れ」にならずにプロセスをアップデートしていけるかが、今後の課題だと感じています。
基盤構築
開発を始めるにあたって特筆するべきだったのが、プロダクト開発と並行して技術基盤を構築した点です。
RightTouchがプレイドからスピンオフした当初は、プレイド側の基盤も利用しながら開発を進めていました。しかし、QANTナレッジデスク は既存機能と完全に独立したプロダクトであるため、新たに RightTouch 独自のシステム基盤として構築することにしました。
Cloud Run
立ち上げ当初は PdE 2名の少人数で進めてていたこともあり、できる限りクラウドベンダーのマネージドサービスに頼りつつ、最小限度の構成でスタートする必要がありました。
そこで、バックエンドのホスティングには主に Cloud Run を採用しました。
Cloud Runはのコンテナイメージをホスティングするサービスで、Github Actionsから簡単にBuild・Applyできます。さらに、ダイレクトVPCアクセス機能を利用することでプライベート通信も容易に実現できます。コンパウンドでプロダクトを展開する弊社にとって、IAM制御を通じて Cloud Run どうしの通信が可能な点も、システム連携の観点から魅力でした。
個人的なの経験としては、 これまでは AWS Lambda を利用することが多かったため、「初期フェーズからコンテナは少し重いのでは？」と思っていました。しかし、実際運用してみるとメリットを感じる点が多くありました。
例えば、
- 形態素解析を使った機能を試したいときに、コンテナイメージに MeCab を入れて気軽に実験できる
- Lambda と違い、一つのインスタンスで複数リクエストを同時にさばける（デフォルトで 80）ため、最小起動台数を適切に設定すれば、あまりコールドスタートを気にせず運用できる
- k8s のマニフェストに近い構成ファイルで Apply 作業を管理できるため、GitOps の導入が容易
などです。弊社では、Github Actions から Skaffold コマンドを実行してデプロイを行っています。
難しい点としては、Lambdaと比較してビルド・デプロイ速度がかなり遅い部分があります。そのため、リモートでのデバッグ作業を最小限に抑えられるように工夫する必要を感じました。
AlloyDB
弊社の従来のプロダクトは主にMongoDBに依存していました。MongoDBはドキュメント指向DBとして、柔軟なドキュメント構造を扱えるため、特にイベントトラックデータなどの管理で重宝していました。
一方で、ナレッジマネジメントをはじめ、今後ますます増えていくエンタープライズ顧客の重要なデータをお預かりすることを考えると、より堅牢なデータ設計やトランザクション管理ができるRDSは捨てがたい選択肢でした。
そこで採用したのが、2022年末に GA した AlloyDB です。
AlloyDBはPostgresSQL互換のマネージドのデータベースです。PostgresSQLはExtensionを導入することで、様々な機能を追加できる柔軟性があります。Cloud Runとの接続については、Cloud Run Service の サイドカーコンテナ として AlloyDB Auth Proxy を設定することで接続することができました。
また、ストレージ層を分離した独自アーキテクチャにより、分析クエリを含む読み込みリソースを水平スケールできる点や、カラム型エンジンへ対応している点も期待しています。
AlloyDBは最低の起動料金が高く、初期構築の段階ではコスト面の不安もありましたが、将来的なユースケースの大規模化を見据えると、トレードオフとして妥当な選択だと考えています。
アプリケーションの構成
概要
基盤の話に続いて、QANTナレッジデスク 単体のアプリケーション構成について、技術的な話に触れたいと思います。
基本的な構成は、これまでの弊社プロダクトの前例に倣って、
- フロントエンド：React（Vite）
- バックエンド：Express
という構成を採用しています。
Item
Item モデルは、QANTナレッジデスク で管理する Page や Folder を表現する、最も重要なドメインモデルです。
Item はリビジョン管理が求められ、確実に変更履歴を追うトレーサビリティが必要になります。そのため、イベントソーシングを用いたイミュータブルなデータモデルを採用しています。
- Itemを更新する際は、まずRevisionテーブルにレコードを追加
- その上で、Itemテーブルの内容に新規のRevisionを畳み込んで更新
としています。
また、QANTナレッジデスク で扱うコンテンツは Page や Folder など複数の種類が存在しますが、すべて Item のサブクラスとして管理しています。
モデルの定義方法としては継承を用いず、代数的データ型 (ADT) を意識した以下のような表現を採用しています。
加えて、Itemの各サブタイプ自体も直積で表現し、
の用に「成分」で分解しています。詳細は割愛しますが、一つのモデルの中に性質の異なる複数のプロパティが存在するケースは多いため、成分ごとに明記できる点は、構造的部分型を採用するTypeScript ならでわの利点だと感じています。
テスト戦略
少し変わった試みとして、テスト戦略についても紹介したいと思います。
QANTナレッジデスク では Testing Trophy の考え方に則り、統合テストを主体としてテストを記述しています。統合テストの利点は、実際のデータベースの副作用を含めて確認できるため、クリティカルな不具合を防ぎやすく、テストを通過させたときに得られる安心感が大きいことです。
一方で、過去の経験から、統合テストには「テストデータの準備が重くなりがち」というデメリット も感じていました。
例えば、「ワークフロー機能で、一度差し戻しされた後に再度承認できるか？」をテストしたい場合、事前のArrangeフェーズで、何度もワークフローの状態遷移を発生させておく必要があります。このように、AAAパターンでいう最初のArrangeがどんどん重くなってしまう点が、統合テスト主体のテスト戦略のネックになると感じて来ました。
そこで試した運用が、
統合テストに利用するデータをUI画面から作成し、ストレージにDumpする
という方法です。
前述のワークフローのような複雑な状態遷移も、UIから操作する分にはそれほど労力がかかりません。そのため、UI でテスト用のデータセットを作り、それを丸ごとファイルとしてエクスポートし、リモートストレージ（GCS）に dump しておきます。統合テスト実行時には、その dump データをダウンロードして利用することで、テストコード上では Arrange フェーズをほぼスキップできます。
もちろん、dump データの管理コストが発生したり、複数人で同時に作業しづらいといったデメリットもありますが、現状の少人数フェーズではメリットの方が大きいと感じています。
また、副次的なメリットとして、初期データ投入が非常に楽になるという点もあります。
従来は、サンプルデータ一式をコード上に定義し、INSERT スクリプトを書いて新規開発者の環境構築時に投入する、という運用をしていました。
しかし、データモデルが複雑になるにつれ、
- コード管理が辛くなる
- 実践的なデータセットを用意するのが困難
- 結果として、各自のローカルに「秘伝のタレ」的なデータが溜まっていく
といった問題が起きがちです。
そこで、Dumpデータが取れるようにしたことで、一つの環境を立ち上げてデータをDumpし、これを複数人でDL・Restoreして利用することで、簡単に同じ環境をセットアップすることができるようになりました。 Itemのリビジョン・ワークフロー・コメントスレッドなど、複雑なデータモデルの多いナレッジマネジメントシステムにおいては、特に大きなメリットを感じています。
QANTナレッジデスク のこだわりポイント
ここからは、エンジニアとしてプロダクト開発を進めるうえで「こだわったポイント」をいくつか紹介します。
検索への注力
前述の通り、First Issueとして
「新人オペレーターであっても、負荷が少なく、品質高く対応できるようにする。」
という目標を設定しました。
これを実現するため、まずは顧客から電話を受けたコールセンターのオペレーターが、実際にナレッジを参照しながら電話応対をする際の流れを、細かくブレイクダウンしてみました。
- 顧客の発話を理解する
- (顧客が言ったことを) 社内用語に変換する
- 変換された社内用語で単語で検索する
- 検索結果から、目的にあったドキュメントを選択する
- 選択したドキュメントか必要な情報を探して理解する
- 顧客への伝え方を考える
- 顧客へ発話する
このような仮説に沿って考えると、オペレータは想像以上に多くのタスクをリアルタイムに処理していることがわかります。
私たちは、何社かコールセンター見学をさせていただき、このプロセスのうちうちどの点が最も「負」になっているのかを探りました。その結果、以下の点でつまづきのポイントがあることが見えて来ました。
2. 社内用語への変換
- 顧客が使う言葉と、社内用語や実際の手続き名称が大きく異なる場合がある
- 新人オペレーターにとって、この「翻訳」が難しく、結果として正しいキーワードで検索できない
4. 検索結果からの選択
- 検索結果に似たような記事が並んでしまい、業務知識の少ない新人にはどれが正解か判断しづらい
これらを踏まえて、電話対応に必要なドキュメントに、できるだけ負荷なく素早くたどり着ける仕組みを提供することが、まずは最もボトルネック解消つながるポイントだと考えました。
そこで、「高度な検索機能の実装」 を最初のプロダクトの軸としました。 具体的には、
- 顧客の発話と社内用語を紐付ける 文脈検索
- 検索結果に対し、顧客の問いに対する答えや、その記載箇所を補足的に提示する仕組み
このあたりのLLM機能まわりの開発の経緯は、AI エンジニアのharadyさんが詳しくまとめてくれている ので、ぜひそちらもご一読いただければと思います。
トークスクリプト管理機能
QANTナレッジデスク には、UIから簡単に可視性の高いトークスクリプトを作成・管理する機能があります。
特筆したいのは、トークスクリプト機能の実装をチームで判断したことです。
リッチなデザイン的レイアウトを作成できる機能は、ドキュメント管理システムにとって 「Nice to Have」 と見なされがちですし、LLMのようなメガトレンドとは異なり、目を惹く先端技術でもありません。
ただ、私たちは単に最新の技術を取り入れて終わるのではなく、ユーザーの「実際の価値」につながる機能を作ること を重視しています。
QANT Knowledge の最初のターゲットは、コールセンター内での対応マニュアル管理でした。そこで、実際のコールセンターを何社か見学させていただいたところ、現場における トークスクリプトの存在感が非常に大きい ことに気づきました。多くのオペレーターにとって、トークスクリプトはまさに生命線となっています。
実は私自身も、学生時代に損保会社のコールセンターで自動車事故の受付業務を5年ほど経験しており、特に新人時代はトークスクリプトが手放せませんでした。その実感もあり、チーム内でもトークスクリプトの重要性については認識がすぐに一致しました。
一方で、いざ開発に取り組むべくどんな仕様に落とすべきか検討を始めてみると、他に前例が少なく、思ったより答えを出すのが難しいことが見えてきました。 例えば、フローチャート構造はどのようなロジックで見せていくのか？編集作業はどのようなUIで提供すると効率的なのか？などです。
この部分は、エンジニアとデザイナーが何度も試作と議論を重ねながら、少しずつ形にしていきました。
結果として、実際に顧客に利用していただいていますが、「使い慣れると非常に簡単にスクリプトが作れる」とポジティブなフィードバックもいただいています。
ワークフロー機能
ワークフローの機能を組み込むかどうかは、システムの複雑性を大きく左右します。一般的な汎用のドキュメント管理システムでは、ワークフロー非対応のものが多いのはそのためでしょう。 私たちも当初、エンジニアの視点としてはシステムの複雑性の観点からワークフロー機能の実装を躊躇っていました。
しかし、ユーザーのニーズを深掘りしていくうちに、ユーザーにとって非常大きなメリットになる可能性が見えてきました。
コールセンター内での対応マニュアルは、基本的にオペレーターを統括するスーパーバイザー(SV)が管理します。業界によって温度差はあるものの、対応マニュアルに不備があってはならないので、厳格なチェック体制と履歴管理のもと、慎重に更新作業を進めていきます。
こうした背景から、QANT Knowledge も、ワークフローに対応できるプロダクト として設計する方向へ方針転換しました。
ワークフローもイベントソーシング型のデータモデルとしており、状態遷移イベントが発行されたときにイベントを畳み込むことで現在のワークフロー状態を構築できるようになっています。
状態遷移の管理が非常に複雑になることが予想されるため、ステートマシン管理ライブラリである xstate を導入し、宣言的な状態管理を実現しました。
これによってテスタビリティを担保し、ビジュアライザーによる状態遷移の可視化も可能になりました。
ドキュメントの自動変換
QANTナレッジデスクを使い始めていただく上で、最初に立ちはだかる大きな障壁の一つが データ移行コスト です。
弊社がお世話になっているクライアントでは、Word / Excel / PDF など様々な形式でドキュメントが管理されています。エンタープライズ企業が多いため、ドキュメント数も膨大です。これら全てゼロから人力で移行しようとすると、莫大なコストがかかってしまいます。
そこで、生成AIを使ったサポート機能として、「自動変換サービス」 を提供することにしました。
ただ、実際に取り組んでみると、想像以上に難しいタスクであることがわかりました。 世の中には OCR やエンティティ抽出系の機能に優れたドキュメントAIツールは多く存在しますが、
- Excel や PDF のような多彩なレイアウト
- 表・段組み・注釈・図表などを含むドキュメント
を「セマンティックに構造化されたデータ」へ変換できるような仕組みで、精度の高いものがありませんでした。
そのため、既存のマネージドツールだけに依存するのではなく、LLMを活用した 独自のワークフローを構成し、タスク分解を工夫することで、ある程度の変換精度を実現することができました。
まだまだ精度の限界はありますが、検証を実施させていただいたクライアントにおいては、一定の工数削減に寄与することができました。
進めながら感じたこと
開発当初、私の頭の中にあった「ドキュメントの管理システム」のイメージは、Confluence, Notionのようなものでした。
そのため、こんなことを考えたりもしました。
「Notionより良いツールが作れるのだろうか？」
しかし、コールセンター見学などを重ねるにつれて、その考えは徐々に変わっていきました。
そもそも、本当にConfluenceやNotionだけで要件を満たせるのであれば、どのコールセンターもすでそれらを広く導入しているはずです。
ところが現実には、汎用ツールの機能は、エンタープライズのお客様の具体的なニーズに落とし込まれきっておらず、現場の業務要件を満たせないケースが少なくありません。
そこで、改めて「自分たちの価値はどこにあるのか？」を考えました。
私の個人的な理解としては、RightTouch のプロダクトエンジニアリングは 「ドメイン SI」 と捉えると分かりやすいと感じています。
従来の SI は、個別企業ごとにフルスクラッチのシステムを作り込んでいくイメージがありますが、私たちはそうではなく、ある程度汎用性を持たせた機能としてシステムを開発しつつ、一方で、カスタマーサポート業界や特定の顧客群のユースケースに深くフィットするようなシステムに作り込むことで、「単なる汎用ツール」では実現できない 実務的な価値 を提供します。
これはLLMの登場によって、「システムがどれだけ個別のユースケースに深くアジャストできるか」が重要になってきている、という時代の潮流ともマッチしていると感じています。
ユースケースに深く寄り添いつつも、一方でドメインレベルで汎用性を保つことで、個別最適に陥らず、多くの事例や知見を取り込みながらベストプラクティスを見つけていける、というのがRightTouchの実現するべき使命になるのではないかと考えています。
さいごに
QANTナレッジデスクはまだまだ始まったばかりです。
カスタマサポートの進化を通じて、世の中から少しでも「負」が減るよう、そしてLLMなどの最新技術を取り入れながら、ユーザーの「実在するニーズ」に深く入り込んだシステムの開発を続けていきたいと考えています。
ナレッジマネジメント一つをとっても、私たちの掲げるビジョンは非常に壮大で、足元とのギャップに目眩がしそうになることもあります。
ただ、1年で起こる変化を過大評価せず、10年で起こる評価を過小評価せずに(アンソニー・ロビンスの名言より)、一つひとつ実際的な価値を積み上げていきたいと思います。
思いのほか長文となってしまいましたが、最後まで読んでいただいてありがとうございました。
採用情報
RightTouchでは、Product Engineerをはじめ、プロダクト価値を一緒に育てる仲間を積極採用中です。カジュアル面談も歓迎しています。ご興味があれば、ぜひ採用ページをご覧ください。
