RAG からエージェント型 AI へ：次世代エンタープライズシステムの構築

「RAG だけ」の課題

Retrieval-Augmented Generation（RAG）は、エンタープライズ AI のゲームチェンジャーとなりました。大規模言語モデルが事前学習の過程で正解を暗記していることを期待するのではなく、RAG は自社の文書に基づいて回答を grounding（根拠付け）します。ユーザーの質問を埋め込み、ベクトルデータベース内で類似したチャンクを検索し、それを LLM へのコンテキストとして渡すのです。これはエレガントで機能しており、よく整理されたコーパスに対する単純な質問であれば、多くの場合十分です。

しかし、企業規模で RAG システムを構築した経験があれば、「十分」がすぐに「不十分」になることを知っているはずです。

例えば、従業員が 2 つの社内プロセスの違いについて尋ねたとしましょう。標準的な RAG パイプラインはこのクエリを埋め込み、意味的に最も類似するドキュメントチャンクを検索し、LLM が一貫性のある回答を合成することを期待します。しかし実際には、3 つの問題が発生します。第一に、クエリには複数の正当な意味を持つドメイン固有の略語が含まれている可能性があり、システムには意図を明確化する仕組みがありません。第二に、ベクトル類似性だけでは、同じ概念に対して異なる用語を使用している重要な文書を見逃す可能性があります。第三に、システムには「どの程度自信があるか」を伝える信頼できる方法がなく、ハルシネーション（幻覚）によって生成された回答と、根拠のある回答が区別できません。

これは特殊なケースではありません。これが、エンタープライズ AI の日常です。

過去数年間、私は 3 つの世代にわたるインテリジェント検索システムを構築・運用してきました。それぞれの世代が、前世代では解決できなかった課題を克服しています。私が得た教訓を共有します。

第1世代：ハイブリッド検索 — なぜ単一の検索手法では不十分なのか

バニラな RAG（Retrieval-Augmented Generation）に対する最初の有意義な改善点は、エンタープライズ環境において単一の検索手法だけで事足りることは決してないと認識することです。

ベクトル検索は意味的な関連性を捉えるのに優れています。「在庫切れ」に関するクエリは、「ゼロ在庫」や「供給ギャップ」といった記述を含む文書にもマッチします。正確な単語が一致していなくても、意味が通じるからです。しかし、ベクトル検索では正確なキーワードの一致が見逃されがちです。企業環境には略語、製品コード、専門用語があふれており、正確な一致を見逃すことは致命的な失敗につながりかねません。

これは情報検索の分野でよく知られた課題です。その解決策はハイブリッド検索の実装にあります。密ベクトル検索と疎ベクトル（キーワード）検索（通常は BM25）を並列で実行し、結果を知的に統合するのです。このパターン自体は確立されていますが、本番環境で機能させるためのエンジニアリング上の判断こそが、多くのチュートリアルが不足している点です。

重複除去は、あなたが思っている以上に重要です。2 つの検索手法が重複する結果を返した場合、単純に連結すると候補セットに冗長なコンテンツが含まれてしまいます。一意の識別子、次にソース場所、最後にコンテンツ指紋による多段階の重複除去戦略を採用することで、再ランク付け器に渡す前に、マージされたセット内に真に固有の情報だけを確保できます。

ランク融合には注意が必要です。Cormack、Clarke、Buettcher（2009 年）が提案した Reciprocal Rank Fusion (RRF) は、スコア正規化を必要とせずに異種なスコアリングシステムからのランキングを組み合わせる標準的なアプローチです。これは、意味的シグナルと語彙的シグナルをマージする際に特に有効で、いずれの検索ソースでも高い順位を獲得したドキュメントにポイントを与える仕組みです。

レイテンシーは機能の一つです。逐次実行ではなく非同期実行で両方の検索を並行して実行すれば、品質を犠牲にすることなく、検索レイテンシを大幅に短縮できます。私の経験では 40% 以上も削減可能です。ユーザーは回答の質がどれだけ高くても、システムが応答しすぎるとすぐに離脱してしまいます。

クロスエンコーダーによる再ランク付け器が、最終的な精度フィルタとして機能します。これは、単独の検索手法よりもはるかに高い忠実度で、マージされた候補セットを元のクエリに対して再スコアリングします。

しかし、システムがドメインの構造を理解していなければ、完璧な検索でも意味をなしません。

Generation Two: Knowledge Graphs Meet RAG

標準的な RAG（Retrieval-Augmented Generation）は、ドキュメントをチャンクごとに分割した際、それぞれのテキスト断片を孤立した島として扱います。そこには「エンティティ」や「関係性」、あるいは「オントロジー」といった概念が存在しません。製品名が特定の階層に属していること、異なるドキュメントセットで使われる同義語があること、一見無関係な二つの概念が共通の上位カテゴリを共有していることなどを、システムは理解していません。

検索パイプラインに知識グラフ（Knowledge Graph）のレイヤーを追加するアプローチ——これは「GraphRAG」と呼ばれることが増えています——がこのギャップを埋めます。核心となる考え方はシンプルです。ドメイン内のエンティティと関係性を構造化された形で表現できれば、その情報を活用して検索と生成の両方を強化できるのです。私の経験上、実用化において特に大きな影響を与える設計上の決断が二つあります。

決定論的エンティティ抽出 vs. LLM ベースの名詞句認識（NER）

GraphRAG のチュートリアルの多くは、テキストからエンティティを抽出するために大規模言語モデル（LLM）を使用することを推奨しています。しかし、本番環境ではこれにより三つの問題が生じます。第一にレイテンシの増加です。呼び出しごとに数百ミリ秒の遅延が発生します。第二にコスト増です。ドキュメントチャンクごとに API 利用料が徴収されるため、取り込み時に費用がかさみます。第三に非決定性（Non-determinism）の問題です。同じ入力でも実行ごとに異なる出力が生じるため、規制の厳しい環境ではデバッグがほぼ不可能になります。

ルールベースの多段階エンティティ抽出は、古典的な自然言語処理（NLP）において確立された手法であり、強力な代替案となります。エンティティインデックスに対して最長フレーズ優先でマッチングを行い、フォーマットの違いを吸収するために正規化マッチングを実行し、さらにトークンレベルでの一致を確認することで、マイクロ秒単位で一定の精度を実現できます。これはコスト増を加えずに達成可能です。この手法自体は新しいものではありませんが、GraphRAG の文脈では、多くの実務者がより「現代的」とされる LLM 方式を優先するあまり、この設計選択を見落としてしまいがちです。その結果、生産環境における大きなコスト増につながるケースも少なくありません。

Graph-Enriched Retrieval via Rank Fusion

エンティティタグ付きのドキュメントチャンクは、クエリに関連するエンティティをどれだけ含んでいるかでスコアリングできます。このグラフ信号は、ハイブリッド検索で用いられる RRF（Reciprocal Rank Fusion）メカニズムを通じて、ベクトルやキーワードのスコアと直接競合させることが可能です。つまり、適切なエンティティに言及していても表面言語が異なるドキュメントも検索結果として浮上します。これは純粋なベクトル検索では見逃されがちなケースです。

継続的なドキュメント取り込みを必要とする本番システムでは、ダウンタイムゼロでの再インデックス化が不可欠です。標準的なデータベースのパターン——増分更新のためのデルタ処理や、完全再同期のためのアトミックスワップ——は、エンティティの再マッピング操作中もシステムが利用可能であることを保証する、すでに実証済みのアプローチです。

Generation Three: Agentic AI — Systems That Reason

ハイブリッド検索や GraphRAG は検索課題を解決しますが、企業の質問は単一のステップで完結することは稀です。比較が必要な問いには、システムが二つの概念を独立して理解した上で統合する能力が求められます。計画立案に関する問いでは、サブタスクへの分解が必要です。トラブルシューティングの問い合わせでは、ドキュメント、構造化データベース、外部 API を単一ワークフロー内で参照する必要があります。

エージェント型アーキテクチャは、固定された「検索→生成」パイプラインに代わり、動的な推論システムを採用します。あらかじめ決められた経路をたどるのではなく、システムは中間結果に基づき、次のアクションを各ステップで判断します。これが、従来のパイプラインとエージェンシー型システムを分ける決定的な特徴です。

最近の業界分析では、効果的なエージェント AI が習得すべき中核分野として、「ツールの活用」「メモリ管理」「計画立案」「調整」「評価」の 5 つが挙げられています。私は実際に業務で使えるエージェントシステムを構築してきた経験から、企業導入には必須となる第 6 の要素を追加します。それは「安全性」です。これは単なる機能ではなく、アーキテクチャ上の境界線として確立されなければなりません。

最優先は安全性 — いつでも

企業環境では、クエリに顧客データや従業員情報、機密参照が含まれてしまう可能性があります。安全性の評価はパイプラインの最初のステップでなければなりません。これは下流のフィルタではなく、堅牢なアーキテクチャ上の境界線です。機密情報が検出された場合、検索や生成コンポーネントに到達する前にクエリを即座に拒否する必要があります。これは機能というより設計思想であり、私の経験上、企業向け AI システムにおける最も重要なアーキテクチャ上の決断の一つです。

検索前の曖昧さの解消

企業の言語は本質的に曖昧です。組織内では、一般的な略語が複数の有効な意味を持つことがあります。従来のアプローチである「LLM に推測させる」方法は、時間がかかり、結果も非確定的です。単語頻度のヒューリスティックを用いてドメイン固有の用語を特定し、厳選されたルックアップテーブルで解決する、軽量なデータベース依存型の曖昧さ解消手法であれば、遅延は大幅に短縮しつつ、同等かそれ以上の精度を実現できます。これはオンデバイス NLP の設計を推進する原則と同じです。最大限の柔軟性ではなく、遅延予算への最適化を目指します。

プランニングと分解

複雑な多段階の質問に対して、LLM はクエリをサブクエリに分解し、それぞれを特定の検索ツールに割り当てることができます。実行前にこの計画をユーザーに表示する（ヒューマン・イン・ザ・ループのチェックポイントとも呼ばれます）ことで、信頼性を高め、誤解を早期に発見できます。これは、信頼性の高いエージェントシステムには人間の監督が不可欠であると強調する、Model Context Protocol (MCP) といった新興規格にも合致しています。

パラレルマルチソース検索

異なるサブクエリには、それぞれ異なるデータソースが必要になる場合があります。各サブクエリに必要なツールを分類し、並列実行することで、複雑なクエリに対する応答時間を、順次実行と比較して劇的に短縮できます。

保守的な信頼度スコアリング

多くの実運用されている RAG システムがここでつまずきます。パイプラインの各段階で信頼性スコアを単純に平均化すると、個々のコンポーネントの弱点が見え隠れしてしまいます。

決定理論で標準的に使われる「乗算スコアリング」は、あえて保守的なアプローチをとります。なぜなら、どの単一コンポーネントでも不確実性が高まれば、全体の信頼性は急激に低下するからです。2 つのシナリオを考えてみましょう。

まず、プランニングの信頼性が 0.9 で、リトリーバル（検索）の信頼性も 0.9 の場合、積算スコアは 0.81 となり、これは妥当な結果です。しかし、プランニングが 0.9 でも、リトリーバルが 0.1 に低下した場合はどうでしょうか？積算スコアは 0.09 になり、「何かおかしい」という明確なシグナルとなります。一方、平均値をとれば誤解を招く 0.5 という結果が出てしまいます。

この仕組みにより、システムは「わかりません」と言えるようになります。私はこれが、実運用される AI システムが持つべき最も重要な能力だと考えています。

反省による自己修正

信頼性が閾値を下回った場合、低品質な回答を返すのではなく、システムはなぜ失敗したかを評価し、批判的なフィードバックを生成して、追加の文脈とともに計画段階へとループします。このリトライループに上限を設定することは、チュートリアルではあまり言及されませんが、実運用システムには必須の制約条件です。

一般化可能な原則

これら3世代のシステムを実装し、私が提唱したパターンが複数の事業部門で採用される様子を見てきた結果、企業向け AI 施策全般に広く適用できると思われるいくつかの原則が明確になってきました。

柔軟性よりも、決定論的であることの価値の方が高いです。本番環境では、運用担当者が障害の再現やデバッグを行う必要があります。LLM の呼び出しは、本当に生成推論を必要とするタスクに限定し、それ以外の処理（エンティティ抽出、曖昧さ解消、ルーティング、信頼度計算など）には決定論的なロジックを使用しましょう。

レイテンシは単なる数値指標ではなく、機能そのものです。各コンポーネントごとに明示的なレイテンシ予算を設けて設計してください。1 ミリ秒でも削減できれば、ユーザーが実際にシステムを採用する確率は高まります。

信頼度スコアリングは妥協できません。「良い回答が見つかった」と「推測している」の区別ができないシステムは、本番環境で運用できるものではありません。これは後付けではなく、アーキテクチャ設計の初日から組み込むべき要件です。

プライバシーは機能ではなく、アーキテクチャ上の制約条件です。安全性のためのガードレールは、実行グラフ上で絶対的な境界線として実装する必要があります。機密情報を含むクエリは、その後のコンポーネントがどのように処理しようとも、決して下流のコンポーネントに到達させてはいけません。

今後の展望

方向性は明確です。エンタープライズ AI は、静的な検索パイプラインから、問題を分解し、複数の知識源を参照し、自身の信頼度を評価し、自己修正を行う動的な推論システムへと進化しています。そのための構成要素である知識グラフ、ハイブリッド検索、エージェント型オーケストレーション、人間が関与する設計手法は、すでに今日利用可能です。真の課題はアーキテクチャにあります。これらを組み合わせて、信頼性が高く、監査可能で、実ユーザーにとって十分な速度を持つシステムを構築することです。

次のフロンティアはマルチエージェントのオーケストレーションです。これは、専門的なエージェントが互いの能力を動的に発見し、組織の境界を跨ぐクエリに対して協力するシステムを指します。MCP やエージェント間ディスカバリープロトコルといった新興規格がこの実現を可能にしつつあります。これらのアーキテクチャ基盤に今日投資を行う組織は、技術が成熟した際に大きな優位性を得ることになるでしょう。

RAG は始まりに過ぎません。エンタープライズ向け知識システムが目指す先は、アジェンティック AI です。

Mona Sachdev 氏は、Dell Technologies で AI サイエンティストとして勤務しており、エンタープライズ AI、生成 AI、ナレッジグラフ、インテリジェント検索システムに取り組んでいます。彼女の専門分野は自然言語処理、セマンティック検索、およびエンタープライズアプリケーション向けの AI システムです。テキサス大学オースティン校で修士号を取得し、AI および検索技術に関する複数の米国特許の発明者でもあります。