Progress SoftwareのAgentic RAG新機能が示す企業知識活用の次の一手
ニュースの概要
2026年10月1日、Progress Softwareは企業内の文書や業務データをAIエージェントが扱いやすい形でつなぐ『Agentic Knowledge Layer』を発表した。これは、社内に散らばる契約書やマニュアル、FAQなどの知識を一つの共有基盤として整理し、複数のAIエージェントが同じ情報源を参照しながら検索・要約・回答を行えるようにする仕組みだ。従来のRAG(検索拡張生成)は文書をベクトル化して類似検索する方式が主流だったが、今回の発表は検索の前段階、つまり『知識をどう構造化し、エージェントに渡すか』という実装レイヤーに踏み込んだ点が特徴といえる。
引用元: Progress Software、Agentic RAGの新機能を発表（Progress Software）
分析・見解
検索の前段階に踏み込んだ「共有知識レイヤー」という発想
Progress Softwareが打ち出したAgentic Knowledge Layerは、AIエージェントごとに個別の検索基盤を作るのではなく、企業全体で一つの知識基盤を共有する発想に立っている。これまでのRAG(検索拡張生成、＝文書を検索してから回答を作る方式)は、営業部門用、サポート部門用といった具合に、用途ごとにベクトルデータベースを個別構築するケースが多かった。同じ契約書や製品マニュアルを何度もインデックス化し直す無駄が常態化していたわけだ。共有型のレイヤーを挟むことで、この重複投資を解消しようという狙いは理にかなっている。
ベクトル検索だけでは拾いきれない「構造」への着目
興味深いのは、今回の発表が単なる検索精度の向上ではなく、文書コーパス(＝社内に蓄積された文書群)をどう構造化するかという、より上流の課題に焦点を当てている点だ。ベクトル検索は意味的に近い文章を見つけるのは得意だが、「この手順の次に何をすべきか」といった手順間の依存関係や、「この情報はどのレベルの担当者向けか」といった権限・文脈の階層までは表現しきれない。単純な類似度検索だけでは、複雑な業務プロセスを正確に再現する回答を安定して出すのが難しい。この課題意識は、文書をスキルツリー(＝手順や判断を木構造で整理したもの)として扱う発想とも重なる部分が大きい。
「検索して渡す」から「あらかじめ整理しておく」への重心移動
もう一つ見逃せないのは、実行時の検索コストを下げる方向への重心移動だ。毎回大量の文書をスキャンして関連箇所を探すよりも、あらかじめ知識を整理・圧縮しておき、エージェントが必要な部分だけを素早く引き出せるようにする方が、応答速度とコストの両面で有利になる。大規模言語モデルのAPI利用料は入力トークン数に比例するため、検索結果を絞り込めるほど運用コストは下がる。Progress Softwareの発表資料でも、事前に整理された知識層を介することで複数エージェント間の情報整合性を保つ狙いが語られており、これは単発の検索精度競争から、知識基盤そのものの設計競争へと業界の関心が移りつつある兆候と読める。
大手ベンダーの参入が示す市場の成熟度
Progress Softwareのような老舗ソフトウェアベンダーがこの領域に参入してきたこと自体にも意味がある。スタートアップが先行していたAgentic RAGの分野に、既存の企業向けソフトウェア基盤を持つベンダーが本格的に乗り出すのは、技術が実験段階から本番導入段階に移りつつある合図だ。今後は、どれだけ賢い検索ができるかよりも、どれだけ安定して企業の既存システムと統合できるかが選定基準の中心になっていくだろう。
ビジネスへの影響
自社の文書基盤を点検する好機にする
今回の発表を一過性のニュースとして読み流すのではなく、自社の文書管理の現状を点検するきっかけにしたい。部門ごとにバラバラのナレッジベースを運用している企業ほど、将来的な統合コストは膨らみやすい。マニュアル、FAQ、議事録といった社内資産が、どの程度構造化され、誰が更新責任を持っているかを棚卸しするだけでも、次の投資判断の精度は大きく変わる。拠点ごとに内容の異なる製品マニュアルが放置されているケースも多く、統合の前に内容そのものの矛盾を洗い出す作業が意外と重い負担になる。
ベンダー選定は「検索精度」より「構造化のしやすさ」で見る
RAG関連ツールを選ぶ際、多くの企業はベンチマーク上の検索精度を比較しがちだが、実務で効くのはむしろ、自社の文書をどれだけ手間をかけずに構造化できるかだ。手順書や契約書のように階層や依存関係を持つ文書が多い企業は、単純な類似検索よりも、文書を木構造や手順単位に分解できるツールの方が運用後の精度が安定しやすい。導入前に、自社の主要文書を数十件サンプルとして実際に構造化してみて、違和感がないかを確認する工程を挟むことを勧めたい。ベンチマークの数値だけを比較する評価は、自社特有の文書形式には当てはまらないことが多い。
複数エージェント運用を見据えた権限設計を先に決める
共有型の知識レイヤーは、複数のAIエージェントが同じ情報源を参照する前提で設計されている。これは裏を返せば、どのエージェントにどの情報へのアクセス権を与えるかという権限設計を、技術選定より先に固めておく必要があるということだ。後回しにすると、情報漏えいリスクと使い勝手のトレードオフを後から調整する羽目になりやすい。誰がいつどの情報にアクセスしたかを追跡できる仕組みも、導入初期の段階で組み込んでおくべきだろう。