社内SFAデータで検索AIを作ってみた｜なぜRAGを採用しなかったのか

この記事のポイント

社内SFAデータを活用した検索AIを構築する場合、必ずしもRAGが最適な選択肢とは限りません。
実際に検証した結果、構造化データはベクトル検索よりもデータベースとして扱い、LLMには検索条件の解釈やレポート生成を担わせる方が安定した結果を得られました。

要点サマリ

社内SFAデータを自然言語で検索・活用できる環境を目指し、セルフホストLLMを用いた検索AIの構築を行いました。
当初はRAGによる検索を検討しましたが、CSV形式の構造化データでは期待した検索精度や集計結果を得ることができませんでした。そこで、SFAデータを夜間バッチでPostgreSQLへ連携し、Open WebUIのPython Toolから必要なデータを取得する構成へ変更しました。
その結果、自然言語による検索だけでなく、営業レポートの作成支援にも活用できる環境を構築できました。

用語解説

• SFA：Sales Force Automation の略称。営業活動や案件情報を管理するためのシステム。
• RAG：Retrieval-Augmented Generation の略称。外部データを検索し、その結果をLLMへ渡して回答を生成する仕組み。
• LLM：Large Language Model の略称。大量のテキストを学習した大規模言語モデル。ChatGPTやGemini、Qwenなどが該当する。
• Open WebUI：Ollamaや各種LLMをWebブラウザから利用するためのオープンソースのWebインターフェース。
• Open WebUI API：Open WebUIが提供するAPI機能。外部プログラムからLLMを呼び出し、チャット生成や各種処理を自動実行できる。
• Ollama：サーバーやPC上でLLMを実行・管理するためのオープンソースソフトウェア。
• PostgreSQL：オープンソースのリレーショナルデータベース管理システム。本記事ではSFAデータの格納先として利用。
• Python Tool：Open WebUIから呼び出せる拡張機能。LLMが必要なパラメータを指定し、Pythonプログラムによる検索や集計処理を実行できる。
• バッチ処理：あらかじめ決められた時刻に自動実行する処理方式。本記事では夜間にデータ集計やレポート生成を実行。
• Microsoft Teams：Microsoftが提供するコミュニケーションツール。本記事では生成したレポートの配信先として利用。
• セルフホスト：クラウドサービスではなく、自社で管理するサーバーやGPU環境上でシステムを運用する形態。

なぜセルフホストLLM環境を構築したのか？

社内では機密情報や個人情報の取り扱いを考慮し、Open WebUIとOllamaによるセルフホストLLM環境が導入されていました。その環境を活用し、営業部門からの要望をきっかけにSFAデータ活用の検証を行うことになりました。

解説
近年、生成AIを活用した業務効率化が広く進められており、社内でも生成AI活用への関心が高まっています。

一方で、当社では情報セキュリティガイドラインにより、機密情報や個人情報を生成AIサービスへアップロードすることを禁止しています。そのため、顧客情報や案件情報を含む業務データを活用する場合は、情報を外部へ送信しない仕組みが求められます。こうした背景から、社内ではOpen WebUIとOllamaを利用したセルフホストLLM環境が導入されていました。

その後、営業部門から「生成AIを活用してSFAデータをもっと有効活用できないか」という相談がありました。SFAには案件情報や活動履歴などのデータが蓄積されていますが、必要な情報の検索やレポート作成をより効率化したいという要望です。そこで既存のセルフホストLLM環境を活用し、自然言語でSFAデータを検索・活用する仕組みの検証を行うことにしました。

まず検討したのが、生成AIとの連携手法として広く利用されているRAGによる検索アプローチでした。

なぜRAGを採用しなかったのか？

自然言語でSFAデータを検索する仕組みを検討する中で、まず候補に挙がったのがRAGでした。しかし実際に検証を進めると、CSVのような構造化データでは期待した効果を得ることができず、別のアプローチを採用することになりました。

解説
検索AIの実現方法を検討する中で、まず候補として挙がったのがRAG（Retrieval-Augmented Generation）です。
RAGは生成AIと外部データを連携させる代表的な手法であり、社内文書検索やナレッジベース構築などで広く活用されています。

今回も当初は、SFAから出力したCSVデータをベクトル化し、利用者の質問に応じて関連データを検索する構成を想定していました。例えば「前日の活動内容を教えて」「失注案件を確認したい」といった問い合わせに対して、関連するデータを抽出して回答するイメージです。しかし実際に検証を進めると、CSVのような構造化データでは期待していた結果を得ることができませんでした。

利用者が求めていたのは、類似したデータの検索ではなく、「条件に合う案件を抽出したい」「案件状況を集計したい」「レポートとしてまとめたい」といった要求です。一方で、ベクトル検索が得意とするのは類似性に基づく検索であり、構造化データに対する条件抽出や集計処理とは目的が異なります。

そのため、今回の用途ではRAGを中心とした構成よりも、データベースを活用したアプローチの方が適していると判断しました。

構造化データをどう扱うべきだったのか？

CSVデータをナレッジとして検索するのではなく、データベースとして扱う構成へ変更しました。構造化データの特性に合わせて役割を分離することで、検索精度と運用性の向上を図りました。

解説
RAGによる検索を検証する中で、今回扱うデータは文章ではなく構造化データであることを改めて認識しました。顧客情報や案件情報は、レコード単位で整理されたデータであり、類似文章の検索よりも条件抽出や集計処理に適しています。

そこで構成を見直し、SFAから夜間バッチでCSVデータを出力し、分析用のPostgreSQLへ取り込む方式を採用しました。これにより、本番環境へ直接アクセスすることなく、検索や集計処理を実行できるようになります。

また、この構成にすることでデータ更新のタイミングを管理しやすくなりました。RAGのようにベクトルデータを再生成する必要がなく、CSV取込処理だけで最新データを反映できます。

今回の検証では、「データはデータベースとして扱う」「LLMは自然言語インターフェースとして利用する」という役割分担が、構造化データ活用において有効であることが分かりました。

Open WebUIのPython Toolをどう活用したのか？

LLMにはデータ検索や集計処理を直接行わせず、自然言語の解釈とレポート生成を担当させました。実際のデータ取得や集計処理はPython Tool側に実装することで、精度と保守性の向上を実現しました。

解説
PostgreSQLへデータを集約した後、次に検討したのは利用者とのインターフェースです。営業部門から求められていたのは、SQLやデータベースを意識せず、自然言語でSFAデータを活用できる仕組みでした。当初は自然言語から直接データを検索させることも考えましたが、構造化データに対する検索や集計処理は、LLMよりもプログラムで実装した方が確実です。

そこで、Open WebUIのPython Tool機能を利用し、定義済みの検索・集計処理を呼び出す構成を採用しました。
例えば、「先週の営業活動のサマリーを作成」という依頼に対して、LLMは必要な条件を解釈し、Python Toolへパラメータを渡します。Python ToolはPostgreSQLから必要なデータを取得し、集計結果をLLMへ返却します。その後、LLMが取得結果を要約し、利用者が読みやすいレポート形式へ整形します。

この方式により、データ取得ロジックとレポート生成ロジックを分離できました。集計条件の変更や検索機能の追加もPython側で対応できるため、プロンプトだけに依存した実装と比較して保守しやすい構成になっています。また、Open WebUIからだけでなく、API経由で同じ処理を呼び出せるため、後述するTeamsへの自動投稿機能にも応用できました。

セルフホストLLMをレポート作成にどう活用したのか？

検索AIとして構築した環境は、定型レポートの作成にも活用できました。
一方でセルフホストLLMはクラウドサービスと比較すると応答速度が遅いため、リアルタイム利用だけでなく夜間バッチ処理との組み合わせを採用しました。

解説
SFAデータ活用の検証を進める中で、取得したデータを要約し、レポート形式で出力できることにも着目しました。例えば、前日の営業活動や案件状況を一覧化したデータをPostgreSQLから取得し、その内容をLLMへ渡すことで、人が読みやすい文章へ自動変換できます。単なるデータ一覧ではなく、「今週の受注案件」や「注目すべき案件」といった観点を含めたレポートとして出力できるため、情報共有にも活用しやすくなります。

しかし実際に運用してみると、セルフホスト環境で動作するLLMは、ChatGPTやGeminiなどのクラウドサービスと比較して応答速度に差がありました。特に長文のレポート生成では数十秒程度かかることもあり、リアルタイムな利用には向かない場面もあります。

そこで、レポート生成は夜間バッチ処理として実行し、利用者が出社する前に完成したレポートを配信する構成を採用しました。これにより、応答時間を意識することなくLLMの要約能力を活用できるようになりました。
また、Open WebUI APIを利用することで、生成したレポートを外部システムから取得できるため、Teamsとの連携も容易に実現できます。検索AIとして構築した仕組みを、日々の情報共有基盤としても活用できるようになりました。

Open WebUI APIを利用したTeams連携はどう実現したのか？

Open WebUI APIを利用することで、生成したレポートをTeamsへ自動配信できるようになりました。LLMがPython Toolを利用して必要なデータを取得し、自然言語による指示からレポートを生成しています。

解説
検索AIとして構築した環境は、利用者からの問い合わせだけでなく、定期レポートの自動生成にも活用しています。
レポート生成用に別途C#プログラムを開発し、夜間バッチ処理として実行しています。このプログラムはデータベースへ直接アクセスするのではなく、Open WebUI APIへ自然言語の指示を送信します。

例えば、
「先週の営業活動のサマリーを作成」
「先週、受注した案件のリストを抽出」
「Markdown形式で出力してください」
といった指示を送信すると、LLMが内容を解釈し、必要に応じてPython Toolを呼び出します。Python ToolはPostgreSQLから必要なデータを取得し、その結果をLLMへ返します。LLMは取得したデータをもとにレポートを生成し、Markdown形式で応答します。C#プログラムは生成されたMarkdownを受け取り、TeamsのWebhook機能を利用して指定チャネルへ投稿します。

この構成により、レポート生成ロジックをプログラム側へ実装する必要がなくなりました。レポート内容の変更も自然言語の指示を修正するだけで対応できるため、柔軟な運用を実現しています。
また、同じ仕組みを利用することで、将来的には日次レポート以外の定型レポートや通知業務にも応用できると考えています。

RAGと今回採用した構成を比較してどうだったか？

まとめ

本記事では、社内SFAデータを活用した検索AIの構築事例を紹介しました。

当初はRAGの活用を検討しましたが、CSVのような構造化データでは期待した効果を得ることができませんでした。そのため、SFAデータをPostgreSQLへ取り込み、Open WebUIのPython Toolを利用して必要なデータを取得する構成を採用しました。

今回の取り組みを通じて、以下のような知見を得ることができました。

• CSVのような構造化データは、ナレッジとして検索するよりもデータベースとして扱う方が適している
• Open WebUIのPython Toolを活用することで、LLMから柔軟にデータ取得や集計処理を実行できる
• Open WebUI APIを利用することで、自然言語によるレポート生成を既存システムへ組み込みやすい
• セルフホストLLMはリアルタイム用途だけでなく、夜間バッチによるレポート生成や情報共有との相性が良い

一方で、RAG自体が不要というわけではありません。社内規程やマニュアル、議事録などの文書検索では有効な手法であり、データの特性に応じて適切なアプローチを選択することが重要だと感じました。

今後は、対象データやレポートの種類を増やしながら、業務に合わせたLLM活用を継続的に検証していきたいと考えています。

お問い合わせ

本記事に関するお問い合わせは、下記よりご連絡ください。

お問い合わせフォーム

関連記事

ソリューション – アサミ情報システム株式会社｜GIS/3D/CityGML

OCRとAIで名刺情報を自動リスト化する方法｜誤字補正・項目分割・WEB情報補完の実例 – アサミ情報システム株式会社｜GIS/3D/CityGML

ChatGPTでAutoCADの図形描画スクリプトを作成する際の、エラー解消と指示出しのコツ – アサミ情報システム株式会社｜GIS/3D/CityGML