こんにちは。AI事業本部の市田拓馬です。

LLMの性能が大きく進化し、AIは便利なチャットツールとして使われるだけでなく、社内に分散した情報を探し、つなぎ、整理することで、将来的には情報管理の一部を担うようになっていくのではないかと考えています。

今回は、そのような技術が実現されていくまでにどのような課題があるのかを掴むために、企業内RAGベンチマークであるHERBを読んでみました。

参照した主な資料

本記事では、主に以下の論文・公式実装・データセットを参照しています。

• 論文：Prafulla Kumar Choubey et al., “Benchmarking Deep Search over Heterogeneous Enterprise Data”
  https://arxiv.org/abs/2506.23139
• 公式実装：SalesforceAIResearch/HERB
  https://github.com/SalesforceAIResearch/HERB
• データセット：Salesforce/HERB
  https://huggingface.co/datasets/Salesforce/HERB

HERBは、企業内の複数情報源をまたいで必要な情報を探すタスクを、Deep Searchとして扱うベンチマークです。本記事でも、この論文の問題設定に沿ってDeep Searchという言葉を使います。

本記事はHERB論文を完全再現するものではなく、論文と公式実装を読みながら、社内RAGの今後の方向性を考える記事として書いています。

この記事の要約

社内RAGは、社内文書やチャットログなどを検索し、その結果を根拠に生成AIが回答する仕組みです。社内規程、仕様書、FAQ、議事録、設計書などを横断して探せるだけでも、業務上の価値は大きいと思います。

一方で、実務でAIに聞きたいことは、1つの文書だけで閉じない場合があります。

たとえば、「この顧客の未解決バグは何件あるのか」「この仕様書を誰がレビューしたのか」「この問い合わせはどのPull Requestで修正されたのか」といった問いです。Pull Requestは、GitHubなどでコード変更や修正対応をレビュー・管理する単位です。

こうした問いに答えるには、文書、Slack、会議録、会議チャット、Pull Request、URL、社員情報、顧客情報などをまたいで確認する必要があります。HERB論文は、このような複数情報源をまたぐ企業内RAGのタスクをDeep Searchとして扱っています。

本記事でいう「情報管理」とは、文書管理システム、チャット、会議録、Pull Request、顧客情報などに分散した情報を、業務判断に使える形で探索・接続・整理することを指します。

この記事の結論は次の通りです。

社内RAGは、文書検索を重要な基盤としながら、今後はSlack、会議録、文書、Pull Request、URL、社員・顧客情報などをまたいで、業務判断に必要な情報を探索・接続・整理する方向へ広がっていく。HERB論文でいうDeep Searchは、その変化の中で何が難しくなるのかを考えるうえで、かなり参考になる題材だと思います。

1. はじめに：社内RAGはどこまで広がるのか

社内RAGは、社内文書を検索してAIが回答する仕組みとして、大きな価値を持っています。

たとえば、社内規程、仕様書、議事録、FAQ、設計書、製品資料などを検索対象にして、ユーザーの質問に関連する文書を取得し、その内容をもとにAIが回答する。これは、社内ナレッジ活用の出発点としてかなり有効です。

一方で、AI活用が進むと、社内RAGに期待される役割は少しずつ広がっていくはずです。

• この顧客の未解決バグは何件あるのか
• この仕様書を誰がレビューしたのか
• この機能は議論されたが、最終的に実装されたのか
• この問い合わせは、どのPull Requestで修正されたのか
• 競合製品のデモURLは社内で共有されているのか

これらは、1つの社内文書を探せば終わる問いではありません。

顧客の未解決バグを確認するなら、顧客からの報告、社内での議論、修正Pull Request、顧客IDとの対応を見に行く必要があります。仕様書のレビュー担当者を確認するなら、仕様書そのものに加えて、Slackでのレビューコメントや会議録でのフィードバック、社員IDとの対応も関係してきます。

文書検索は社内RAGの重要な基盤です。そのうえで、実務上の問いに答えようとすると、文書検索を土台にしながら、分散した社内情報を業務判断に使える形でつなぐ必要が出てきます。

本記事では、この方向性を考えるために、HERB論文が扱うDeep Searchという問題設定を見ていきます。

2. HERB論文でいうDeep Searchとは何か

Deep Searchという言葉は、本記事ではHERB論文の文脈に限定して使います。

HERB論文では、Deep Searchを、何を検索するかだけでなく、どの情報源を検索すべきかも判断する検索中心のタスクとして説明しています。たとえば、ある文書に誰がフィードバックしたかを確認する場合、文書のメタデータだけで分かるとは限りません。Slackでレビュー依頼が出ていたり、会議録にフィードバックが残っていたりする場合もあります。

つまり、HERBで扱うDeep Searchでは、検索対象が「文書」だけに閉じません。文書、Slack、会議録、Pull Request、URL、社員情報、顧客情報などをまたいで、必要な証拠を集める必要があります。

たとえば、「この仕様書を誰がレビューしたのか」という質問なら、次のような確認が必要になります。

1. 仕様書本体を探す
2. 文書の著者を確認する
3. Slackでレビュー依頼やコメントを探す
4. 会議録でフィードバック発言を探す
5. 人名を社員IDに変換する

これは、単に長い文書を読むタスクではありません。どの情報源に何がありそうかを判断し、複数の証拠をつなげて答えを作るタスクです。

この観点で見ると、社内RAGは「関連文書を探す仕組み」から、「業務上の状態を確認するための情報探索基盤」へ広がっていく可能性があります。ここでいう情報探索基盤とは、社内に散らばった情報を、業務判断に使える形で探索・接続・整理する仕組みのことです。

3. HERBを使う理由

HERBは、Heterogeneous Enterprise RAG Benchmarkの略で、企業内の異種データをまたぐRAGを評価するためのベンチマークです。

HERBのデータには、Slackメッセージ、会議録、会議チャット、社内文書、GitHub Pull Request、URL、社員情報、顧客情報などが含まれます。論文では、合成されたソフトウェア企業を舞台に、製品計画、製品開発、製品サポートのワークフローを作り、その中で発生する文書、Slack、会議、Pull Requestなどをデータとして生成しています。

HERBがこの記事の題材として使いやすいのは、質問が単純な一問一答ではないからです。

論文には、Product Requirements Document、つまり製品要求仕様書の著者とレビュー担当者の社員IDを探す質問があります。この質問では、PRDを見つけ、著者を確認し、Slackや会議録にあるフィードバックをたどり、関係する人物を社員IDに対応づける必要があります。

また、議論されたものの実装されなかった機能を確認する質問では、Slackや会議録から提案された機能を拾い、それをGitHub Pull Requestの実装記録と照合します。未解決バグが最も多い顧客企業を探す質問では、未解決バグを集め、それぞれを顧客に対応づけ、件数を集計します。

こうした例は、社内RAGが文書検索を基盤にしながら、分散情報を業務判断に使える形でつなぐ方向へ広がるとき、どこが難しくなるのかを考える材料になります。

本記事では、HERBのスコア完全再現は目的にしません。HERBを題材に、Deep Searchという問題設定と、社内RAGの社会実装で出てきそうなボトルネックを整理します。

4. HERB公式実装から見る、非構造化検索と構造化ツール

HERBのGitHubリポジトリには、論文で使われたRAG手法の実装が公開されています。ここでは、その中でもReAct Agentic RAGのコードを見ながら、非構造化検索と構造化ツールがどう分担されているかを確認します。

HERBでいうReAct Agentic RAGは、LLMが非構造化検索や構造化データ参照を必要に応じて呼び出しながら、段階的に情報を集めて回答する構成です。

非構造化検索とは、自由な文章として書かれたデータを検索することです。HERBでは、Slackメッセージ、会議録、社内文書、会議チャットがこれに当たります。

一方、構造化ツールは、決まった項目を持つ情報を正確に引くためのものです。たとえば、社員名から社員IDを引く、顧客IDから会社名を引く、Pull Requestリンクからタイトル・著者・レビュー状態を取得する、URLからメタデータを取得する、といった処理です。

HERB論文のReAct Agentic RAGでは、非構造化検索として、Slackメッセージ、会議録、会議チャット、社内文書を対象にした単一のHybrid Retrieverを使っています。Hybrid Retrieverは、意味ベースのベクトル検索と、キーワード一致に近いBM25検索を組み合わせる検索器です。さらに、社員、顧客、Pull Request、URLに関する情報を取得するための構造化検索ツールを定義しています。

この構成は、社内RAGを実装するうえで示唆的です。

たとえば、Slackで「Fionaが仕様書にレビューコメントをした」と見つかったとします。文章検索としては、そのSlackメッセージを見つけられれば一歩進みます。ただ、最終回答に社員IDが必要なら、社員名と社員IDを対応づける必要があります。このとき、社員マスタを引く構造化ツールが必要になります。

別の例では、会議録で「この顧客の不具合は修正対応する」と書かれていても、本当に修正されたかどうかはPull Requestを確認しなければ分かりません。Pull Requestには、作成者、レビュー状態、マージ済みかどうかといったメタデータがあります。

重要なのは、これらの情報が最初から完全に接続されたデータベースとして存在しているわけではない点です。Agentは、まず非構造化検索で関連する文脈を見つけ、その中に出てくる人名、顧客名、Pull Requestリンク、URLなどを手がかりに、必要に応じて構造化ツールを呼び出します。

検索対象を増やすだけではなく、検索結果から次にどの構造化情報を引くべきかを判断できるか。ここが、HERBを読んでいて特に面白いポイントでした。

5. 社会実装でボトルネックになりそうなこと

HERBを読むと、社内RAGを複数情報源へ広げるときの難しさは、検索精度だけではないことが分かります。どの情報源を見るか、必要な証拠を取り切れるか、情報不足を見抜けるか、Agentが適切なツールを使えるかも重要になります。

5.1 情報源が分散している

社内情報は、1つの文書にまとまっていません。Slack、会議録、ドキュメント、GitHub、顧客管理、社員マスタなどに分かれています。

文書検索が有効な場面は多くあります。ただし、業務判断に必要な情報が複数の場所に分かれている場合、それらが同じ業務状態を指しているのかを接続する必要があります。

たとえば、顧客からの不具合報告はSlackにあり、修正状況はPull Requestにあり、顧客IDと会社名の対応は顧客マスタにあるかもしれません。これらを別々に検索できても、業務判断に使える形にするには、同じ案件としてつなげる必要があります。

5.2 非構造化データと構造化データを接続する必要がある

Slackや会議録は文章です。一方で、社員ID、顧客ID、Pull Requestの状態、URLメタデータは構造化データです。

HERBの公式実装では、この2つを分けて扱っています。文章データは検索し、社員ID、顧客ID、PRメタデータのような構造化データは、Agentから呼び出せる検索関数として参照します。これは社内RAGをAgentとして実装するときの自然な設計の一つだと思います。

この接続が弱いと、AIは関連しそうな文章を見つけても、業務判断に使える情報まではたどり着けません。

5.3 必要な証拠を取りこぼす可能性がある

関連文書を拾えても、必要な証拠が全部揃うとは限りません。

HERB論文のHuman Analysisでは、モデルが「active bugsが最も多い顧客」を答えるとき、再オープンされたバグだけに注目し、未解決バグ全体を無視してしまう例が報告されています。正しく答えるには、Slackや会議録から報告済みバグを集め、解決Pull Requestがあるものを除外し、再オープンされたものを含める必要があります。

一部の証拠を拾えただけでは、業務上は危うい回答になることがあります。Deep Searchが難しいのは、検索結果の上位にそれらしい文書があるかどうかだけでなく、必要な確認項目を埋め切れるかが問われるからです。

5.4 回答不能な質問にどう対応するか

社内データの中に、必要な証拠が存在しない質問もあります。その場合、AIは無理に答えるのではなく、確認できないと言う必要があります。

HERBには、回答可能な質問だけでなく、回答不能な質問も含まれています。これは、RAGシステムが情報不足を認識できるかを評価するためです。

これは実務でも重要です。存在しない情報をAIがもっともらしく作ってしまうと、業務判断を誤る可能性があります。

5.5 Agentが適切なツールを使えるか

ツールを用意しても、Agentが適切に使えるとは限りません。

HERB論文では、GPT-4oベースのReAct Agentのツール利用を50問分分析しています。その結果、21問では非構造化検索だけに依存しており、ツール利用の系列も短く浅い傾向があったと報告されています。さらに、Artifact系の質問では、PR検索やURL検索のような構造化ツールを使うべき場面でも、表面的なテキスト言及だけで答えるケースがありました。

社内RAGを実務に近づけるには、検索器を強くするだけでなく、Agentが「次にどの情報源を見るべきか」「どのツールを使うべきか」を判断できる必要があります。

6. まとめ

社内RAGは、社内文書を検索して回答する仕組みとして大きな価値を持ちます。

そのうえで、実務の質問に答えようとすると、Slack、会議録、文書、Pull Request、URL、社員・顧客情報をまたいで必要な情報を探す場面が出てきます。

HERB論文でいうDeep Searchは、この広がりを考えるための分かりやすい問題設定です。特に、非構造化検索と構造化ツールをどう接続するか、必要な証拠をどう取りに行くか、答えられない質問をどう扱うかは、社内RAGの社会実装でも重要な論点になると思います。

今回はHERBを題材に、複数情報源をまたぐ社内RAGの課題を整理しました。次は、こうした探索をより効率的・高精度に行うために、社内情報をどのようにナビゲーション可能な構造へ変換するかを見ていきたいと思います。

Appendix: HERBを少数クエリで動かしてみる

HERB論文でいうDeep Searchを実際に動かして確かめるために、HERBの公式実装に近い構成で少数クエリを試してみます。

目的は、HERBのスコアを完全再現することではありません。

見たいのは、次の点です。

• 回答精度はどの程度か
• Agentが非構造化検索だけで終わるのか、必要な場面で社員ID、顧客ID、Pull Requestなどの構造化データ参照まで進めるのか
• 回答不能な質問に対して、無理に答えず「分からない」と言えるのか
• max_iterations のようなAgent実行上の制約が、結果にどう影響するのか

実験の位置づけ

今回の実験は、論文の再現実験というより、論文を読みながら手元で少し動かしてみるミニ検証です。

そのため、論文のスコアとは直接比較しません。特に、今回の実行では以下の点が論文設定と異なります。

• HERB全体では30製品、回答可能815問、回答不能699問が含まれる
• 今回の対象は、そのうち FeedbackForce 1製品のみ
• FeedbackForce には回答可能19問、回答不能30問が含まれる
• 今回実行したのは、そのうち回答可能3問、回答不能3問の合計6問のみ
• LLMはOpenAI GPT-4oではなく、Amazon Bedrock経由のClaudeを使用
• EmbeddingはOpenAI Embeddingではなく、Hugging Faceの sentence-transformers/all-MiniLM-L6-v2 を使用
• 公式評価のうち、content系とunanswerable系の自動採点は今回は実行していない

つまり、この記事で見るのは「どちらのモデルがHERBで高スコアか」ではなく、「Deep Searchでどのような失敗や挙動が見えるか」です。

HERB論文でも、既存のRAG手法はこのベンチマークで高いスコアを出せていません。論文では、最良のAgentic RAGでも平均スコアは32.96に留まったと報告されています。今回のミニ検証も、その難しさを小さく確認する位置づけです。

使ったモデル

今回は、Amazon Bedrock経由でClaude Sonnet 4とClaude Opus 4.5を使いました。

選んだ質問

FeedbackForceは、HERBデータセットに含まれる架空の製品名です。HERBでは、合成されたソフトウェア企業の中に複数の製品があり、それぞれにSlack、文書、会議録、Pull Request、URL、顧客情報などが紐づいています。

今回はその中からFeedbackForceを選び、回答可能な質問を3問、回答不能な質問を3問選びました。

この6問にした理由は、HERBのDeep Searchらしさが出やすいからです。

A0は、文書、会議録、社員IDの接続が必要です。A11は、未解決バグを拾い、顧客IDを会社名に変換し、件数を集計する必要があります。U1、U2、U16は、情報が存在しないときに無理に答えないかを見るための質問です。

評価方法

ここは注意が必要です。

HERB公式実装では、回答可能クエリの評価方法がtypeによって分かれています。

• person: 回答から社員IDを抽出し、ground truthとのF1で評価
• company: 回答から会社名を抽出し、ground truthとのF1で評価
• url: 回答からURLを抽出し、ground truthとのF1で評価
• pr: 回答からPull Requestリンクを抽出し、ground truthとのF1で評価
• content: 別のLLMに回答を採点させ、0-100点で評価

ここでいうground truthは、ベンチマーク側に用意されている正解データです。F1は、回答から取り出したIDや会社名の集合がground truthとどれだけ一致しているかを見る指標で、1に近いほど一致度が高くなります。

回答不能クエリでは、本来は「データ内に答えがない」と判断できることが正解です。公式実装では、別のLLMに回答を確認させ、存在しない情報を答えてしまっていないかを判定します。答えが見つからないと適切に述べていれば、回答不能として扱われます。

今回のミニ検証では、公式評価のすべては回していません。数値として扱うのは、手元でground truthと突き合わせられる person と company のF1です。文章で答える質問や回答不能の質問は、公式実装では別のLLMによる採点対象なので、ここではスコアを断定せず、回答内容の傾向として読みます。

回答可能クエリの結果

まず、回答可能な3問を見ます。ここでは、max_iterations=10 で実行した結果を使います。max_iterations=10 は、ユーザーとの会話10往復ではなく、Agentが検索、データ参照、観察、推論を繰り返す内部ステップ数の上限です。この上限はモデルへのプロンプトではなく、Agent実行側の制約です。

fallback は、ReAct Agentが通常の最終回答まで到達できず、通常の検索QA経路に回ったことを示します。今回の実行では、主な原因は max_iterations=10 に達したことでした。

A0: Market Research Reportの著者・レビュー担当者ID

A0のground truthは10個の社員IDです。

Sonnet 4もOpus 4.5も、回答に含まれていた社員IDは7個でした。余計な社員IDは目視上見当たりませんでした。

F1で見ると、両モデルともおおよそ0.82です。

両モデルとも、著者と一部のレビュー担当者には到達しています。一方で、正解セット全体は取り切れていません。Deep Searchでは、関連する証拠を少し拾うだけでは不十分で、必要な人物を網羅する必要があります。

A8: セキュリティリスクで追加できなかった機能

A8は、正解が社員IDや会社名のような短いリストではなく、文章で説明するタイプの質問です。そのため、HERB公式実装では、別のLLMに「回答が正解にどれくらい近いか」を0-100点で採点させます。

今回はそこまでの自動採点は行っていません。そのため、A8については点数ではなく、回答がどの情報に触れていたかを観察します。

回答傾向としては、両モデルともセキュリティリスクで追加できなかった主要な2系統の機能に触れていました。

• 高負荷データ処理向けのmiddleware強化
• 量子化モデル実行向けのinference pipeline最適化

Opus 4.5はここでPull Request側のメタデータまで参照していました。これは、単にSlackや文書を検索するだけでなく、「その機能がどのPull Requestで扱われ、最終的にどうなったのか」まで確認しようとした動きです。

A11: 未解決バグが最大の会社名

A11のground truthは5社です。

BlueWave
SmartData
ComputeWorks
CloudSync
NextGenTech

Sonnet 4は、BlueWave と SmartData の2社を答えました。正解5社のうち2社なので、F1はおおよそ0.57です。

Opus 4.5は、max_iterations=10 の実行ではfallbackに回り、正解会社名まで到達しませんでした。そのため、company F1としては0相当です。

ここだけ見るとSonnet 4の方が良く見えます。ただし、これは「Opus 4.5のモデル能力が低い」という話ではありません。Opus 4.5は、10ステップの探索予算内で最終回答まで到達できず、fallbackに回っています。

A11だけ探索上限を増やしてみる

ここで気になったのは、Opus 4.5のA11がfallbackに回った理由です。

もしA11を解けなかった理由がモデル差ではなく、max_iterations=10 という探索上限にあるなら、探索上限を増やすことで挙動が変わるはずです。そこで、A11だけOpus 4.5で max_iterations=20 に増やして再実行しました。

結果は次の通りです。

max_iterations を10から20に増やすと、Opus 4.5はfallbackせず、顧客IDと会社名の対応までは参照できました。つまり、探索上限を増やすことでAgentの行動は変わりました。

一方で、最終回答は DataSolutions 一社で、しかもground truthに含まれない会社でした。探索上限を増やせば、必ず正解に近づくわけではありません。

ここで見えたのは、いいモデルを使い、探索回数を増やせばそのまま解ける、という単純な話ではなさそうだということです。必要な証拠を集め、解決済みか未解決かを判断し、顧客IDを会社名に変換し、会社ごとに件数を集計する。そのどこかでずれると、最終回答もずれます。

回答不能クエリの結果

次に、回答不能な3問を見ます。回答不能クエリでは、本来は「データ内に答えがない」と判断できることが正解です。今回は公式の自動採点を行っていないため、正確なスコアは出さず、無理に情報を作っていないかを目視で確認します。

U1では、両モデルとも競合製品のdemo URLは見つからないという方向で答えていました。U2でも、Technical ArchitectがMarket Research Reportをレビューした社員IDは見つからない、という方向の回答でした。ただし、Opus 4.5は FeedbackForce と backAIX の関係の扱いに少し混乱が見えました。

U16では、両モデルともfallbackに回ったうえで、reopened bugsの会社別集計は判断できないという回答になりました。少なくとも目視上は、存在しない会社名を強く断定する動きは見えませんでした。

今回見えたこと

少数クエリだけでも、Deep Searchの難しさはかなり見えました。

今回の実行では、単なる文章検索だけでなく、構造化データも参照されました。たとえば、A11では顧客IDから会社名を引く処理、A8ではPull Requestのメタデータ参照、U2では社員IDとロールの対応確認が行われています。

ただし、構造化データを参照できたからといって、必ず正解できるわけではありません。A11では、Sonnet 4は顧客IDから会社名を引くところまで進みましたが、正解5社のうち2社しか答えられませんでした。Opus 4.5も、探索上限を20に増やすと同じ処理まで進みましたが、最終回答は正解会社ではありませんでした。

一方で、A8ではOpus 4.5がPull Requestのメタデータまで参照しており、良い動きも見えました。つまり、モデルを強くすれば常に良くなる、構造化データを参照できれば常に正解する、という単純な話ではなさそうです。

さらに、max_iterations のようなAgent実行側の設定も結果に影響します。10ステップではfallbackに回った質問でも、20ステップにすると構造化データの参照まで進むことがありました。ただし、それでも正解に到達するとは限りません。

HERB論文でも、既存のRAG手法は全体として高いスコアを出せていません。今回のミニ実装を見ても、Deep Searchの改善は、モデルを強くする、検索精度を上げる、探索回数を増やす、という方向だけでは安定しない可能性があります。もちろん、モデル性能や検索精度の改善は重要です。ただ、それだけを主戦略にすると限界がありそうです。

• どの情報源を検索するか
• どの検索結果を証拠として採用するか
• いつ構造化データを参照するか
• どこまで探索を続けるか
• 回答不能なときに止まれるか
• 複数証拠をどう集計するか

こうした要素が絡み合って、最終回答が決まります。

ブログ本文への接続

本文では、社内RAGは文書検索を基盤にしながら、分散した社内情報を業務判断に使える形で探索・接続・整理する方向へ広がる、と書きました。

今回のミニ実装は、その主張を小さく確認するものになりました。

関連する文書を検索できても、必要な人物や会社を網羅できるとは限りません。構造化データを参照できても、集計を間違えることがあります。探索上限を増やしても、それだけで正解になるわけではありません。

だからこそ、社内RAGの今後の論点は、検索対象を増やすことだけではなく、検索、ツール利用、証拠取得、回答不能判定、実行制御をどう組み合わせるかに移っていくのだと思います。

HERB論文でいうDeep Searchは、その難しさを考えるためのよい問題設定だったと思います。