はじめに
こんにちは、QANT ナレッジデスク(β)(以下 QANT ナレッジデスク)のロジック開発を担当している原田です。普段は QANT プロダクト群のロジック開発を行っております。
本記事は、QANT ナレッジデスクのリリースに際して、「ロジックを開発しているときに私が日々何を考えていたのか」を当時を思い出しながら書きました。技術ブログではありつつ技術的な内容に関しては（いろいろな事情も込みで）ボカした内容になりましたが、その上で「なぜそうやったのか」という点については色々触れることができたと思っています。
この記事で私と同じようにプロダクト開発やロジック開発に従事されている方々に向けて、「技術選択をするときにどう考えるべきか」「新しい技術が登場したときにどう向き合うべきか」といった、プロダクト開発で直面する判断のヒントになれば幸いです。
QANT ナレッジデスクとの出会い
私と QANT ナレッジデスクの関係は 2024 年 11 月から始まりました。当時はまだプロダクトの立ち上げ時期で、私は業務委託として検索ロジックの開発に取り組んでいました。この時は業務委託契約というのもあって、技術的な課題を解くことに集中していた一方で、プロダクト全体をどうするかという視点はまだ持っていなかったなと思います。
そして、2 ヶ月後の 2025 年 1 月に正式入社し、本格的に 本プロダクトに関わり始めたことでその状況が変わりました。業務委託の頃は「与えられた技術課題を解く」ことが仕事でしたが、正社員として「このプロダクトで何を実現するか」を自分で考える立場になりました。
最初は競合プロダクトの状況をよく知らなかったので、市場に出ている他社のナレッジマネジメントツールを触ることにしました。多くのツールを触る中で、「検索精度が悪い」「検索が遅い」「対応ファイル形式が限られていて導入ハードルが高い」といった課題が見えてきました。
こうして技術開発から入り、プロダクト全体の課題に向き合うようになったことで、私にとって QANT ナレッジデスクは「自分が責任を持って関わっていくプロダクト」へと変わっていきました。
なぜ LLM ベースの検索を選ばなかったか
入社後 2 ヶ月くらいの間は、引き続き検索周りの課題にメインで取り組む事となりました。
当時、世の中的には「RAG で全てできる」という雰囲気や、「LLM を用いたクエリ拡張をどう実装するか」といった議論が盛んでした。確かに、これらのアプローチは検索精度を向上させる可能性を秘めています。しかし、実際に検証してみると、大きな課題が見えてきました。それはクエリごとに LLM を使うコストと生成処理によるレイテンシーです。
クエリ拡張でも RAG でも、検索のたびに LLM による生成処理が走ります。これは、ユーザーが検索ボタンを押してから結果が返ってくるまでに数秒かかることを意味します。さらに、検索頻度が高ければ高いほど、LLM の利用コストが積み上がっていきます。
このプロダクトの主要ユースケースはコールセンター業務におけるナレッジ参照である事を考えるとコストとレイテンシーの話はよりクリティカルになります。オペレーターは顧客対応中に何度もナレッジを検索し、お客様を待たせることなく的確な情報を案内する必要があります。このシナリオでは、検索に数秒かかることは許容できません。
また、QANT の基盤技術の側面から見たときも、リアルタイム性の求められる処理にこの検索技術が使われる場合を考えると、レイテンシーの大きなロジックであるほど、それが採用できない可能性が高くなります。
LLM の推論速度は日々改善されていますが、それでもコストとレイテンシーの課題は残ります。こうした理由から、このプロダクトで要求される検索ロジックは、生成ベースのアプローチではなく、違う仕組みを使う必要があることが明白でした。
そして、私たちが最終的に選択したのは、ドキュメントの徹底した前処理とベクトル検索でした。ドキュメントの構造を理解し、意味のある単位で情報を整理し、高品質なベクトル表現を事前に作成しておく。こうすることで、検索時には LLM を使わず、ミリ秒単位で結果を返せるようになります。これは、LLM に全てを任せるのではなく、古典的な検索技術も含めて最適な組み合わせを見つけることの重要性を教えてくれました。
チャンキング設計で考えたこと
では、「ドキュメントの徹底した前処理」とは具体的に何を意味するのでしょうか。その核心にあるのが、ドキュメントのチャンキングと Embedding をどう設計するかという問題です。
世の中には、QA パターンをはじめとする様々なチャンキング手法が存在します。しかし、私が気づいたのは、既存の手法をそのまま適用するだけでは不十分だということでした。
なぜなら、「どの FAQ がどういうクエリで検索されるべきか」は、実際のユースケースによって大きく異なるからです。カスタマーサポートの現場で使われる言葉、顧客が使う表現、問い合わせの文脈など、これらを考慮せずに、汎用的なチャンキング手法だけに頼ると、本当に必要な情報が検索結果に出てこないという事態が起きます。
ベクトル検索では、ドキュメント側と検索クエリ側の両方を同じ Embedding モデルでベクトル化し、その類似度で結果を返します。つまり、検索精度を上げるためにチューニングできるポイントは、検索前の「前処理」の部分に集中しているということです。どういう単位でチャンクを切るか、どういう情報を付加するか、その設計次第で検索結果が大きく変わります。
こうした課題に取り組んでいくのは当然大変ですが、ここで妥協してどこかのアーキテクチャをただ持ってくるだけで済ませてしまったら、将来必ず何らかの問題が起きます。そして、その時になって「なぜ検索精度が落ちたのか」「なぜこのクエリで適切な結果が返らないのか」が分からなくなってしまいブラックボックス化してしまいます。このような事態は避けなければなりません。
だからこそ、私たちはカスタマーサポートドメインに特化しつつ、そのドメイン内で汎用的に使えるデータモデリングを追求しました。チームで日々議論を重ね、仮説を立てては検証し、改善していく地道なプロセスの繰り返しでした。
この前処理への徹底したこだわりが、ベクトル検索における精度と速度を決定づけ、ひいては このプロダクト全体のユーザー体験を支える基盤となると考えています。
ドキュメント変換との格闘
検索ロジックの目処が立った後、2025 年 3 月頃からドキュメント変換ロジックの開発に本格的に取り組み始めました。PDF、Word、PowerPoint など、様々な形式のドキュメントを正確に構造化し、QANT ナレッジデスクの UI で利用可能な形式に変換するロジックです。
当初、最新のマルチモーダル LLM の能力に期待し、その活用を試みました。確かにその性能には目を見張るものがありましたが、コールセンターのトークスクリプトのような複雑なレイアウトでは、複数カラムの読み取り順序が狂ったり、表の構造が正しく認識されなかったりと、安定した結果を得ることが難しい状況でした。さらに、なぜ特定の抽出に失敗したのかをデバッグすることも困難で、プロダクトとして提供するにはこの「ブラックボックス性」は致命的でした。
そこでロジックの方針を転換しました。基本的な要素（テキストブロック、表、画像など）の抽出には LLM を使わず、従来の画像処理やレイアウト解析といった、確実でデバッグ可能な技術を採用。その上で、抽出した要素間の意味的・位置的な関係性を解釈し構造化する部分に限定して LLM を活用する形にしました。
これは「LLM ではダメだった」から生まれたのではなく、「LLM の強みを活かすために、他の技術で何を補うべきか」という発想の転換から設計されました。この開発思想については、AI Engineering Summit 2025 での登壇でも詳しくお話ししています。
エージェント時代のナレッジ管理
これまでロジック開発現場のリアルをお伝えしてきましたが、ナレッジマネジメントには検索や変換と同じくらい大切な観点があります。それはナレッジをどう維持・更新していくかという問題です。
カスタマーサポートの世界には、KCS（Knowledge-Centered Service）という考え方があります。問い合わせ対応をしながら知識を蓄積し、その知識で次の対応を改善し、フィードバックからさらに知識を洗練させていく。この「作る → 使う → 育てる」の循環を回し続けるアプローチです。
私がこの KCS に注目しているのは、AI エージェントとの相性の良さです。エージェントが自律的に対応しながら知識を抽出・蓄積し、その知識を使って次の対応を行い、結果をフィードバックとしてナレッジを更新していく。このサイクルが自動で回り続ければ、人手によるナレッジ管理の負担は大幅に減ります。
QANT ナレッジデスクも、単なる検索ツールではなく、こうしたエージェント時代のナレッジ基盤へと進化していく必要があると考えています。
これからの QANT ナレッジデスク
私は、QANT ナレッジデスクが今後 QANT プロダクト群の最も重要なコアになると考えています。なぜなら、どのような業務でも、どのようなエージェントでも、その基盤となるのは「正確で、信頼できる、アクセス可能な情報」だからです。
本プロダクトで培った検索技術、ドキュメント変換技術、そして LLM と従来技術を組み合わせる知見は、他のプロダクトにも応用できる基盤技術です。ここでの技術的な蓄積が、QANT 全体の品質を左右すると言っても過言ではありません。
まとめ
QANT ナレッジデスクのロジック開発を通じて学んだ最も重要なことは、徹底したユーザー視点を持ち続けることです。技術的な解決策を選ぶ際、常に「誰のために、何のために」を問い続ける。この手法はユーザーの課題を本当に解決するのか、このタイミングで LLM を使うことはユーザー体験を向上させるのか。こうした問いに対して、ユーザー視点から答えを出せることが、堅牢で実用的なシステムを作る鍵だと確信しています。
LLM の登場で、多くのことが簡単にできるようになりました。しかし、それは同時に「考えることをやめてしまう」リスクもはらんでいます。私たちが QANT ナレッジデスクで目指しているのは、LLM の力を最大限活用しながらも、その限界を理解し、適切に他の技術と組み合わせることで、真にユーザーの役に立つプロダクトを作ることです。
今後も、この姿勢を大切にしながら、QANT のプロダクトを進化させていきたいと思います。
本記事で触れたプロダクト開発の思想については、顧客価値の創造のためのデータとの向き合い方でも書いています。また、RightTouch での AI 開発についてより詳しく知りたい方は、「"負の体験を減らす AI"をどうつくる？」もぜひご覧ください。
採用情報
RightTouch では、Product Engineerをはじめ、プロダクト価値を一緒に育てる仲間を積極採用中です。カジュアル面談も歓迎しています。ご興味があれば、ぜひ採用ページをご覧ください。
