セゾンテクノロジーがRAG製品と連携基盤をつなぐ検証、社内文書検索の精度を確認

セゾンテクノロジーはデータベースをはじめとする構造化データの連携を強みとしてきた企業で、生成AIへの取り組みも構造化データ側から始まっています。そのぶん非構造データの扱いには技術的な課題が残っていた一方、顧客が生成AIに期待する入り口の多くは社内文書の検索であり、チャットボットのように社内データを探したいという問い合わせが数多く寄せられていました。さらに業界共通の悩みとして挙がっていたのが、RAG（社内の文書を検索してAIの回答に使う仕組み）に着手すると思うように精度が出ず、コストと時間をかけて改修を延々と繰り返してしまう「RAGの沼」です。

編集部の見立てでは、ここでの本質的な困りごとは非構造データを扱う技術を持たないことではなく、精度をどこまで作り込めば完成なのかという線引きを自社で引けない点にあったのではないでしょうか。終わりの見えない改修は、技術の問題である以上に、投資判断の問題として重くのしかかります。

一から構築せず、完成したプロダクトを検証の起点に据えた判断が、この取り組みの土台になっています。選定理由として挙がっているのは、エンジニアが苦労するチャンキング（長い文書を検索しやすい単位に区切る処理）を含め、精度を出すための独自技術が製品側に作り込まれていた点です。最も沼にはまりやすい精度づくりの工程を製品に預け、自社は連携の設計に力を注ぐ。この役割分担が、検証を短い助走で立ち上げる条件になったと考えられます。

疎結合という設計思想を連携の中心に置いた点も見逃せません。HULFT Square自体はデータ連携基盤でありRAGの機能を持たないため、データを最適化してSuper RAGへ渡し、返ってきた回答を社内チャットや後続の業務プロセスへ流す受け渡し役に徹する構成が採られています。AIの画面の中ですべてを完結させず、既存の業務の流れの途中にAIを差し込む形にしたことで、検索精度は製品側、データの整え方と回答の行き先は連携基盤側という切り分けが保たれます。業務ワークフローの中にSuper RAGを一人の担当者として登場させるという構想も、この切り分けがあって初めて具体的な設計に落ちるものです。

検証の進め方そのものにも工夫がありました。API連携を組む際、仕様書の記載箇所を人に尋ねる代わりにSuper RAGへそのまま質問を投げるという方法が示され、その体験が製品理解の入り口になっています。検証対象のAIを、検証作業そのものの道具として使ってしまう発想です。導入を検討している段階から、どう聞けば欲しい答えが返るのかを実地で覚えられる進め方といえます。

社内テストでは、提案書やマーケティング向けの汎用コンテンツをフォルダ分けして検索させ、期待通りの精度で回答が得られています。データの投入からエンベディング（文書を検索用の数値表現に変換する処理）、回答の取得までのAPI連携も滞りなく進み、RAG構築で陥りがちな泥沼化を回避できるプロダクトという評価に至りました。ただし親・子・孫と枝分かれする深い階層のように文書構造が複雑になる場合には相応の工夫が必要という所見も示されており、いずれも技術検証段階での確認結果です。