RAGとAIエージェントの違い：自社に必要な構成はどちら？

RAG（検索拡張生成）は、回答時に選択した情報を言語モデルへ渡します。アプリが承認済み情報源を検索し、関連箇所をモデルの文脈へ入れ、通常は出典付きで根拠ある回答を求めます。業務の流れは事前に設計します。

エージェントはモデルが次の手順を判断します。検索結果を確認し、別の検索を行い、計算ツールを使い、チケットを更新し、人へ承認を求めることがあります。エージェント型RAGは検索の周囲に判断ループを置き、操作型エージェントは業務状態を変更するシステムまで広げます。

取り込み側では、文書を抽出し、有用な単位へ分割し、メタデータを記録し、検索可能な表現を作ります。質問側では、質問を解釈し、候補を検索・順位付けし、モデルの文脈を構築し、取得した証拠に基づく回答を生成します。

従業員が「トロント出張の食事上限はいくらか」と尋ねる場合、最新規程インデックスへの1回の検索で十分かもしれません。固定された流れは速度と費用を予測しやすくします。また、文章を評価する前に正しい箇所を取得したか確認できるため、評価も容易です。

Microsoftの現行アーキテクチャガイドは、複数段階の推論、動的な情報源選択、質問分解、反復的な絞り込み、検索後の操作にエージェント型RAGを勧めています。「カナダで販売中の商品で、未解決のリコールと在庫があるものはどれか」という質問には、商品台帳、規制情報、在庫の検索と比較が必要です。

単純なFAQを高度に見せるためにエージェント型ループを使うべきではありません。推論手順が増えるたび、モデル呼び出し、待ち時間、失敗経路、確認すべきログが増えます。途中結果を見るまで必要な検索を決められない場合に使います。

目標成果が業務レコードを変更する、または外部へ連絡する場合は検索だけでは足りません。サポートエージェントは注文と規程を検索し、対象条件を判断し、返品を準備し、金額基準を超えれば承認を求め、チケットを更新できます。検索が証拠を供給し、ツールが状態を変えます。

ツールは分けて権限を与えます。注文参照、返品案作成、返金実行を1つの広い機能にまとめません。狭いツールは、権限、承認、失敗分析を明確にします。読み取りと下書きから始め、取り消し可能な書き込み、その後に不可逆・金銭操作へ進みます。

実際の質問と期待する根拠箇所を組にしたテストを作ります。必要な証拠が上位に返るか、アクセスフィルターが権限外文書を除外するか、回答が実際に使った根拠を引用するかを測ります。分割不良、古いインデックス、弱いメタデータは、モデルの幻覚のように見えることがあります。

次に、根拠性、完全性、回答拒否を評価します。証拠がない場合、一般的なモデル記憶で穴を埋めず、不足を伝えるべきです。エージェントには、ツール選択、引数精度、停止条件、承認、最終状態のテストを追加します。

RAGは取り込みと検索で文書単位の権限を維持する必要があります。質問と埋め込みが似ているという理由で、従業員へ給与文書を返してはいけません。監査のため、情報源、権限文脈、取得箇所、最終引用を記録します。

エージェントでは、プロンプトインジェクションと過剰な権限のリスクが加わります。検索内容を指示ではなく信頼できないデータとして扱います。ツール入力を検証し、権限を制限し、重要操作に承認を求め、ループ回数、費用、取引額へ上限を設けます。モデルの拒否動作は認可の代わりになりません。

第1段階はリンク付き検索、第2段階は根拠付き生成、第3段階は質問分解や複数情報源検索、第4段階は読み取り専用ツール、第5段階は承認付き操作です。現在の段階では事業成果を満たせず、新たなリスクと費用に見合う効果があると評価で示された場合だけ進みます。

この進め方は次の投資判断に必要な証拠も作ります。検索ログは不足情報を示し、RAG評価は回答限界を示し、操作案は規程の例外を示します。業務状態を変更できる段階までに、チームは失敗箇所を把握できます。