Agentforce RAGの仕組みは？精度が上がらない5つの原因と改善Tipsも

Agentforce RAGとは、AIが回答を生成する前に社内のナレッジを検索し、その検索結果を根拠として答えを作る仕組みのことです。しかし、エージェントの設定は終わったのに回答精度が上がらず、プロンプトを何度書き直しても的外れな答えが返ってくる状態に悩んでいる担当者は少なくありません。なお、Agentforceの機能名や提供条件は更新が続いているため、本記事は2026年8月時点の情報にもとづいています。

そこで本記事では、Agentforce RAGの仕組みとWeb検索レトリーバーとの違いから、精度を左右する要素、精度が上がらない5つの原因、改善Tips6選、ユースケース別の整備水準、メンテナンス設計までを解説します。

この記事を書いた人

本田正憲

合同会社クロスコムの代表｜専門商社にて7年間のBtoB営業を経て、マーケティング業界に参入。現在はSalesforce公式コンサルティングパートナーとして、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援を提供している。

Agentforce RAGとは

本記事では、勤怠・給与計算ソフトを提供する中堅ソフトウェア企業が、カスタマーサポート窓口の問い合わせ対応にAgentforce RAGを導入したケースを例に解説します。この窓口はオペレーター6名で月およそ300件の問い合わせに対応していましたが、導入直後の正答率は60%にとどまり、月120件は誤った回答を返している状態でした。まずは精度の話に入る前提として、Agentforce RAGの定義と、AgentforceがRAGを使う理由を整理していきます。

Agentforce RAGの定義（検索拡張生成の仕組み）

Agentforce RAGとは、AIが回答を生成する前に社内ナレッジを検索し、その検索結果を根拠として答えを作る仕組みのことです。Agentforceでは、Agentforce Data Library（旧Einstein Data Library）がこの検索と根拠づけを担い、Salesforceのナレッジ記事・アップロードしたファイル・Web検索・カスタムリトリーバーの4種類をデータソースとして指定できます。

RAGが必要になるのは、AIモデル単体では自社固有の情報を知らないからです。汎用的なモデルは一般的な知識を持っていても、自社の製品仕様や社内ルールまでは把握していません。そこで担当者が自社のナレッジを参照先として登録しておくことで、エージェントは固有の情報にもとづいた答えを返せるようになります。

たとえば、先ほどのソフトウェア企業では、勤怠ソフトの操作マニュアルとFAQをあわせて450本ほどデータライブラリに登録し、顧客の質問に近い文書を検索してAIに渡す構成にしました。検索された情報がそのまま回答の根拠になるため、精度を上げたいときは、モデルやプロンプトより先に、登録したナレッジの側を見直す必要があります。

※参考記事はこちら

AgentforceがRAGを使う理由（ハルシネーション抑制と最新情報の参照）

AgentforceがRAGを採用しているのは、ハルシネーション（AIが事実でない内容をもっともらしく生成すること）を抑え、最新の情報にもとづいて答えさせるためです。参照すべき情報を明示的に渡せば、AIは記憶のあいまいさから答えを組み立てず、与えられた文書の記述にそって回答します。担当者がナレッジを更新すれば回答も同時に最新化されるため、モデルを入れ替えなくても情報の鮮度を保てます。

このソフトウェア企業のサポート窓口でも、顧客から「先月の法改正に対応した設定手順を教えてほしい」と尋ねられる場面がありました。あらかじめ改正内容を反映した仕様書を登録していたため、エージェントは更新後の手順だけを引用して回答し、オペレーターは内容を確認してそのまま顧客へ返せたのです。

RAGを使うかどうかは、回答の根拠を自社の文書で説明できる必要があるかどうかで判断しましょう。根拠の提示を求められない社内の雑談用途であれば、ここまでの仕組みは要りません。

AgentforceのRAGとWeb検索レトリーバーの違い3つ

ここまでAgentforce RAGの定義と、Agentforceがこの仕組みを使う理由を整理してきましたが、Agentforceには社内ナレッジを参照するRAGのほかに、公開されたWeb情報を参照するWeb検索という選択肢もあります。そこでここでは、Agentforce RAGとWeb検索レトリーバーの違いを、3つの観点から整理します。

違い①参照するデータソースの範囲

1つ目の違いは「参照するデータソースの範囲」です。RAGは自社が登録したナレッジだけを参照し、Web検索レトリーバーは検索エンジン経由で取得した公開情報を参照します。Agentforceではどちらもデータライブラリのデータソースとして設定できるため、用途に応じて併用もできます。

社内ナレッジに限定すれば自社の正しい情報だけで答えさせられますが、Webを参照すると範囲は広がるかわりに情報の出どころを自社で制御できません。

先ほどのソフトウェア企業を例にとると、勤怠ソフトの仕様や操作手順のように正確さが求められる回答は社内ナレッジのRAGに任せ、労務まわりの法改正動向のように自社では持っていない情報に限ってWeb検索を組み合わせました。ただしWeb検索を有効にすると、検索エンジンが返したタイトル・URL・抜粋・公開日がデータライブラリへ取り込まれ、その内容が回答の根拠になります。自社の見解と食い違う記事が上位に出れば、そのまま引用される可能性が残ります。

参照先を選ぶ基準は、誤った回答が顧客に届いたときの影響の大きさに置くとよいでしょう。

違い②リアルタイム性と精度のトレードオフ

2つ目は、情報の新しさと精度の関係です。Web検索レトリーバーは公開されたばかりの情報にも触れられる一方、RAGは整備したナレッジの範囲で安定した精度を出します。Webの最新情報は鮮度が高くても、記述の正確さや自社の製品との関連性までは保証されません。

このソフトウェア企業でも、導入の検討段階で「最新情報を拾えるほうが顧客の役に立つのではないか」という意見が営業部門から出ていました。ところが試験的にWeb検索だけで回答させたところ、他社の勤怠ソフトの手順を引用して答えてしまう例が、20件のテストのうち3件で起きています。営業部門もこの結果を見て、社外向けの回答をWeb検索に任せる案を取り下げました。

新しさと正確さのどちらを優先するかは、その回答が社外に出るかどうかで切り分けるのが現実的です。社外向けの回答であれば、更新の手間を引き受けてでも参照先を自社で管理したほうが安全といえます。

違い③設定の複雑さとメンテナンスコスト

3つ目の違いは「設定の複雑さとメンテナンスコスト」です。RAGは登録したナレッジを継続的に更新する運用が前提になる一方、Web検索レトリーバーは情報源の整備こそ要らないものの、回答内容を自社で制御しにくくなります。

実際に、このサポート窓口では正確さと制御を重視して、RAGの整備コストを引き受ける判断をしました。棚卸しと初回のクレンジングに2名で3週間、公開後も月に一度、更新分を反映する時間を確保しています。逆にWeb検索を主に使う構成であれば、この3週間は不要でしたが、回答に何が引用されるかを事前に確かめる手段がありませんでした。

どちらを選ぶかは、回答を管理する工数を継続的に確保できるかどうかで決まります。月に数時間の更新すら担当を決められない状態であれば、RAGを広い範囲へ広げる前に、対象業務を1つに絞ったほうが失敗を避けられます。以上が、Agentforce RAGとWeb検索レトリーバーの3つの違いでした。

Agentforce RAGの精度を左右する3つの要素

前章ではRAGとWeb検索レトリーバーの違いを整理しましたが、RAGを選んだあとに担当者が最初に直面するのは回答精度の問題であり、その精度はひとつの設定だけで決まるものではありません。そこでここでは、Agentforce RAGの精度を左右する3つの要素を整理し、改善の優先順位を見極められるようにします。

要素①ナレッジ（データ）の質と整備状況

1つ目の要素は「ナレッジ（データ）の質と整備状況」です。精度に最も大きく影響するのは、参照させるナレッジの質になります。

古い情報や矛盾した記述が混ざっていれば、AIはそれをもとに誤った回答を作ってしまうため、情報の正確さ・鮮度・網羅性の3点が回答の質に直結します。

先ほどのソフトウェア企業では、サポート窓口で使うマニュアルとFAQ450本を棚卸ししたところ、旧バージョン向けの手順が90本残っていました。棚卸しの基準は、公開日が1年以上前の文書と、同じ操作を説明した文書が2本以上ある箇所の2点に絞っています。担当者が公開日と対象バージョンを1本ずつ確認し、重複と旧版を削除して360本まで減らしたうえで、同じ操作を指す表現をそろえました。

ナレッジの整備状況は、登録した本数では測れません。同じ質問に対して答えが1つに定まるかどうかで判断しましょう。答えが2通り出てくる質問が残っているうちは、チャンクやプロンプトを調整しても精度は安定しません。

要素②チャンク設計の精度

次に効いてくるのが、ナレッジをどの単位に分割して登録するかの設計です。チャンクとは、長い文書を検索しやすい単位に区切った一つひとつのまとまりを指し、Agentforce Data Libraryではこの分割と索引付けをプラットフォーム側が自動で行います。

区切りが適切なら、質問に関連する部分だけを過不足なく取り出せます。逆に区切り方を誤ると、必要な情報が欠けたり、無関係な情報まで一緒に取り込まれたりします。

このソフトウェア企業では実際に、同じ操作マニュアルを章単位で登録した場合と工程単位で登録した場合を比べ、同じ質問への回答が変わることを確認しました。章単位では前置きの文章まで検索結果に入り、工程単位では手順の記述だけが返っています。

チャンク設計を見直すべきかどうかは、返ってきた回答に質問と関係のない段落が混ざっているかどうかで判断できます。混ざっていなければ、この設定に手を入れる必要はありません。

要素③プロンプト設計の精度

もう1つの要素が、エージェントに与えるプロンプト（指示文）の設計です。検索した情報をどう使い、どの形式で答えるかを、担当者はここで指定します。回答の形式や、情報が見つからないときの振る舞いを決めておかなければ、AIは曖昧な答えを返したり、根拠のない内容を組み立てたりします。

このサポート窓口でも、ナレッジを整えチャンクの単位を見直したうえでプロンプトの指示を具体化して、ようやく正答率が安定しました。3つのうち1つでも欠けていた段階では、同じ質問に対する回答が日によって変わる状態が続いています。

改善の順番は、ナレッジ、チャンク、プロンプトの順に見直すのが基本です。プロンプトから手をつけると、参照している情報の誤りが残ったまま指示だけが長くなり、原因の切り分けが難しくなります。プロンプトを直す前に、検索されたナレッジのどの記述が回答へ使われたかを確認しておけば、指示の問題か情報の問題かを分けて考えられます。以上が、Agentforce RAGの精度を左右する3つの要素でした。

Agentforce RAGで精度が上がらない5つの原因

ここまで精度を左右する3つの要素を整理してきましたが、実際に精度が上がらないとき、やみくもにプロンプトを書き換えても改善しないことがほとんどです。そこでここでは、Agentforce RAGで精度が上がらない代表的な5つの原因を取り上げ、自社のエージェントがどれに当てはまるかを点検していきます。

原因①ナレッジに古い・矛盾した情報が混在している

1つ目の原因は「ナレッジに古い・矛盾した情報が混在している」ことです。AIは渡された情報を前提として答えるため、参照先に誤りがあれば、その誤りをそのまま含んだ回答が返ります。

改訂前後の資料が両方残っていたり、部署ごとに異なる記述があったりすると、AIはどれを信じるべきか判断できず、回答が揺れたり誤ったりします。

具体例でいうと、このソフトウェア企業では、「残業時間の集計方法」を尋ねる質問に対して、登録された3本の文書がそれぞれ違う計算式を返していました。旧料金プラン向けの記述、法改正前の労働時間の扱い、営業部が独自に作った手順書が、同時に検索対象へ入っていたためです。

この原因に当てはまるかどうかは、同じ質問を5回続けて投げてみると分かります。回答が毎回同じ内容にならなければ、参照先に矛盾が残っています。5回のうち2通り以上の答えが出た質問は、そのままナレッジの修正対象へ回しましょう。

原因②チャンクが大きすぎて無関係な情報まで取得される

2つ目に多いのが、チャンクを大きく区切りすぎているケースです。一つのまとまりに情報を詰め込みすぎると、検索の時点で無関係な内容まで一緒に取り込まれ、AIはノイズを含んだ材料から答えを組み立てることになります。

このソフトウェア企業の場合は、長い操作マニュアルを章ごとにまとめて登録していたため、「打刻の修正方法」を尋ねただけで、章の冒頭にある製品概要と注意事項まで検索結果に入っていました。回答の内容自体は誤っていないものの、前置きが長く、顧客が知りたい手順を読み取るまでに時間がかかる状態でした。

この窓口では、章単位で登録していた12本のマニュアルを工程単位へ分け直し、1つのチャンクに手順が1つだけ入る形へそろえました。チャンクが大きすぎるかどうかは、回答の長さで見分けられます。1つの質問への回答が画面を何度もスクロールする長さになっていれば、区切りの単位を小さくする余地があります。

原因③チャンクが小さすぎて文脈が途切れる

逆に、チャンクを小さく区切りすぎているケースもあります。一文だけを切り出しても、その前提や条件が別のまとまりに分かれていれば、AIは断片だけを根拠に答えることになります。

たとえば、このサポート窓口では、「管理者権限を持つユーザーのみ」という前提条件が別のチャンクへ分かれてしまい、設定手順の途中の一文だけが検索される回答が見られました。一般権限の利用者がその回答どおりに操作しても画面が進まず、結局オペレーターへ問い合わせが戻ってくることになったのです。

原因②とは反対方向の失敗ですが、点検の方法は同じで、実際の質問に対する回答を読んで判断します。回答に「ただし」「〜の場合は」といった条件が一切現れないときは、条件を書いた部分が切り離されている可能性があります。前提条件を含む手順書については、条件と操作を同じファイルに収めておくと、この失敗を避けられます。

原因④プロンプトで回答形式と「答えられない場合の返答」を指定していない

4つ目は、プロンプトで回答の形式や、答えが見つからないときの振る舞いを指定していないことです。指示が曖昧なままだと、AIは検索結果が不十分でも無理に答えを組み立てます。AIには、分かりませんと返すよりも、手元の材料から回答を作ろうとする傾向があるからです。

先ほどのソフトウェア企業では実際に、ナレッジへ登録していない他社製品との連携方法を尋ねられた際、一般的な手順を組み合わせた、実在しない設定画面の説明が返っていました。顧客がその画面を探しても見つからず、問い合わせが二度手間になっています。

この原因は、ナレッジにわざと登録していない質問を投げるだけで確認できます。答えられない旨が返ってくれば問題はなく、もっともらしい手順が返ってくれば、プロンプトの指定が足りていません。公開前の確認では、登録済みの質問だけでなく、範囲の外にある質問を2〜3問まぜて試すようにしましょう。

原因⑤テストクエリが実際の利用場面と乖離している

5つ目は、検証に使う質問が、現場で実際に入力される質問とずれていることです。実際の顧客は言葉を省いたり、製品名を略したり、複数の質問を1文にまとめたりします。

このソフトウェア企業のサポート窓口では、開発側が用意した模範的な質問では正しく答えるのに、顧客の砕けた言い回しでは精度が落ちていました。「有給休暇の繰り越し設定を教えてください」には答えられるのに、「有給、繰越、去年の分どうなる？」には答えられない、という差が出ていたのです。

テストクエリが現場とずれていないかは、実際に窓口へ届いた質問を原文のまま使っているかどうかで確かめられます。担当者が書き起こした整った質問しか手元にないなら、その時点で検証の前提が本番と異なっています。チャットのログやメールの原文が残っていれば、そこから直近1か月分を抜き出すだけで、本番に近い検証用の質問はそろいます。以上が、Agentforce RAGで精度が上がらない5つの原因でした。

Agentforce RAGの精度を上げるTips6選

ここまで精度が上がらない5つの原因を整理してきましたが、原因が特定できれば、打つべき対策も具体的に決まります。そこでここでは、Agentforce RAGの精度を上げるための実践的なTipsを6つ紹介し、優先順位をつけて取り組めるように整理します。

Tips①ナレッジのクレンジング：矛盾・古い情報を除去してから登録する

1つ目のTipsは「ナレッジのクレンジング」です。矛盾した記述や古い情報を取り除き、最新で正確な状態に整えてから登録することが、精度改善の出発点になります。

クレンジングを最優先にすべきなのは、原因①で見たとおり、参照する情報に誤りが残っていれば、チャンクやプロンプトをどれだけ調整しても正しい回答が返らないからです。

先ほどのソフトウェア企業のクレンジングでは、すでに廃止した旧プランの料金表と、部署ごとに食い違う残業計算の記述が混在していると分かりました。担当者2名が3週間かけて450本のうち90本を削除・統合し、残る360本の表現をそろえたところ、サポート窓口の正答率は60%から88%まで改善しました。

クレンジングをどこまで進めるかは、対象を業務単位で区切って決めましょう。全社のナレッジを一度に整えようとすると着手できないため、まずは問い合わせ件数の多い1業務に絞るのが現実的です。

Tips②チャンクサイズは200〜500トークンを基準にする

次に取り組みたいのが、チャンクの単位をそろえることです。Agentforce Data Libraryを使う場合、チャンクへの分割はプラットフォーム側が自動で行うため、担当者が調整できるのは登録する文書の切り方になります。Data 360の検索インデックスを自分で設計する場合は、HTMLタグの意味を使って区切る方式と、段落や改行のブロックで区切る方式のどちらかを選びます。

このソフトウェア企業では、操作マニュアルは工程単位、FAQは一問一答単位というように、1つのファイルに1つの答えだけが入る形へ分け直しました。1ファイルに複数の手順が同居していた頃と比べ、検索結果へ無関係な段落が混ざる回数が減っています。

文書の性質によって適した単位は変わります。まずは1業務分だけ切り方を変えて、変更の前後で回答を読み比べてから全体へ広げましょう。

※参考記事はこちら

Tips③メタデータタグで検索精度を上げる

3つ目は、ナレッジにメタデータタグ（文書の属性を示す目印）を付けることです。カテゴリや対象、更新日などのタグを添えておくと、検索の対象範囲を先に絞り込めます。登録する情報量が多いナレッジほど、この効果は大きく出ます。

先ほどのサポート窓口では、製品名・対象バージョン・想定する質問の種類の3つをタグとして付けました。旧バージョン向けの手順が新バージョンの質問に混ざる誤りは、タグでの絞り込みを入れる前後で月18件から4件まで減っています。タグを付ける対象は、まず誤りが多かった製品バージョン関連の文書に限り、効果を確かめてから全体へ広げました。

タグを設計するときは、項目を増やしすぎないことが条件になります。付与の手間が増えると更新時にタグだけ古いまま残り、かえって誤った絞り込みが起きるため、最初は3項目程度から始めるとよいでしょう。あわせて、タグの値は自由入力にせず選択式にしておくと、表記のゆれが原因で絞り込みから漏れる文書を防げます。

Tips④プロンプトで「回答できない場合の返答」を明示する

4つ目は、原因④への直接の対策として、答えが見つからない場合の振る舞いをプロンプトで明示することです。「該当する情報がなければ、その旨を伝えて有人の窓口を案内する」と書いておけば、AIは根拠のない手順を組み立てずに済みます。

このソフトウェア企業でも当初は、禁止事項を10行以上並べたプロンプトを使っていましたが、指示どうしが競合して回答が長くなっていました。そこで回答形式の指定と、答えられない場合の返し方の2点に絞り直したところ、クレンジング後も月36件残っていた誤答が20件程度まで減っています。

プロンプトは長くする必要はありません。指示を増やすほどAIが優先順位を読み取りにくくなるため、要点を2点までに抑えるほうが回答は安定します。案内先の窓口名や受付時間のように変わりやすい情報は、プロンプトに直接書かず、ナレッジ側に置いて参照させましょう。

Tips⑤本番想定のクエリで繰り返しテストする

5つ目は、原因⑤への対策として、本番で実際に来そうな質問でテストを繰り返すことです。確認しておきたい質問の型は、次の3つになります。

テストに入れるべき3つの質問の型 ①言葉を省いた質問・・・「有給、繰越どうなる？」のように主語や述語が欠けた聞き方です ②条件があいまいな質問・・・利用者の権限や契約プランを明示しない聞き方です ③表記がぶれた質問・・・製品名や機能名を略したり誤記したりする聞き方です

このサポート窓口では実際に、オペレーターが受けた質問を原文のまま100件集め、公開前に一巡させ、公開後も月に一度、同じ100件を投げ直す運用にしました。正答した件数を毎回記録しておくと、ナレッジを更新したあとで精度が下がっていないかを、同じ基準で比べられます。

テストの件数は、多ければよいわけではありません。実際に届いた質問を優先し、答えられなかった質問だけを翌月の整備対象に回すほうが、改善は続きます。

Tips⑥RAGとプロンプト指示の優先順位を明確に設計する

最後に、RAGで取得した情報と、プロンプトで与えた指示のどちらを優先するかを決めておきます。両者が食い違う場面でルールがないと、AIの判断がその都度変わり、同じ質問でも回答が一定しません。

先ほどのソフトウェア企業の場合は、事実に関わる部分は検索したナレッジを優先し、回答のトーンや文字数はプロンプトの指示に従わせる、と役割を分けました。ナレッジに書かれた金額や日付をプロンプト側の例文が上書きしないよう、プロンプトには具体的な数値を書かない運用にしています。

優先順位を決めるときの基準は、その情報が変わったときに誰が更新するかに置きましょう。更新の担当がナレッジ側にあるなら、その項目はナレッジを上位に置いたほうが、運用と設計が食い違いません。逆に、謝罪の言い回しや回答の長さのように更新の担当がいない項目は、プロンプト側で固定しておくほうが管理は楽になります。以上が、Agentforce RAGの精度を上げる6つのTipsでした。

ユースケース別・Agentforce RAGに必要なナレッジ整備の水準

ここまで精度を上げる6つのTipsを紹介してきましたが、ナレッジの整備は、どの用途でも同じ水準が必要なわけではありません。そこでここでは、代表的な3つのユースケースを取り上げ、Agentforce RAGでそれぞれ最低限整えておきたいナレッジの水準を整理します。

ユースケース①営業FAQエージェントの最低水準

1つ目のユースケースは「営業FAQエージェント」です。よくある質問とその回答を正確に網羅しておくことが最低水準になります。

同じ質問に違う答えが返れば利用者の信頼はすぐに失われるため、網羅性と一貫性の両方を保つ必要があります。

先ほどのソフトウェア企業では、まず問い合わせ件数の多い上位50問を洗い出し、それぞれに正しい回答を1つずつ用意しました。同じ内容を説明した文書が複数見つかった場合は、正とする1本を決めて残りを削除し、参照先が1つに定まる状態にしています。営業担当が個別に作った提案書は、そのまま登録せず、内容を確認したうえで正式なFAQへ書き直してから追加しました。

営業FAQで最低水準に達しているかは、問い合わせの多い順に質問を並べて確かめましょう。上位8割の質問に一貫した答えを返せていれば、公開後に大きな混乱は起きません。残りの2割は無理に埋めず、答えられない旨を返して担当者へつなぐ設計にしておくほうが、信頼を保てます。

ユースケース②商談サポートエージェントの最低水準

次に挙げるのが、商談サポートエージェントです。製品仕様や過去の事例を最新の状態に保つことが最低水準になります。仕様の誤りや古い事例をもとに提案すれば、商談の場で訂正が必要になり、顧客の信頼を損ないます。

このサポート窓口を運営するソフトウェア企業では、製品情報の更新があるたびに当日中でナレッジへ反映し、参照される事例は四半期ごとに見直す運用にしました。価格や提供条件を含む文書には更新日をタグとして付け、90日を過ぎたものは検索の対象から自動的に外しています。

商談サポートで整備が足りているかどうかは、直近の仕様変更が反映されるまでの日数で測れます。反映に1週間以上かかる状態であれば、エージェントに提案材料を任せる前に、更新の手順を先に決める必要があります。反映が追いつかない期間は、価格と提供条件だけをエージェントの回答対象から外し、営業担当が口頭で補う運用に切り替えるとよいでしょう。

ユースケース③CS（カスタマーサクセス）問い合わせ対応の最低水準

もう1つが、CS（カスタマーサクセス）の問い合わせ対応です。手順やルールを矛盾なく整備しておくことが最低水準になります。同じ問い合わせに異なる手順が返れば、利用者は解決までに何度も連絡することになり、窓口が受ける問い合わせの総数が増えてしまいます。

先ほどのソフトウェア企業のサポート窓口も、まさにこのCS対応にあたり、手順の食い違いをなくす整備に最も力を入れました。オペレーター6名が月300件を担当する体制のなかで、月120件あった誤答を20件まで減らせたのは、この整備を先に終えたからです。

CS用途で公開してよいかどうかは、操作を伴う回答に前提条件が付いているかで判断しましょう。権限や契約プランの条件が抜けた手順を返す状態のままでは、公開後にかえって問い合わせが増えます。以上が、Agentforce RAGで整えておきたいユースケース別の3つの水準でした。

会社選びや整備の進め方をさらに詳しく知りたい場合は、ほか記事「Agentforce導入支援会社の選び方」にて解説していますので、ぜひ参考にしてもらえると嬉しいです。

Agentforce RAGのメンテナンス設計

ここまでユースケース別に必要なナレッジの水準を整理してきましたが、Agentforce RAGは一度作れば終わる仕組みではありません。そこでここでは、Agentforce RAGのメンテナンス設計を、3つの観点から整理します。

メンテ①ナレッジの更新頻度をどう設計するか

1つ目の観点は「ナレッジの更新頻度をどう設計するか」です。情報の変化が速い領域ほど、更新の間隔を短く設計する必要があります。

製品仕様やルールが変わったのにナレッジが古いままでは、AIは誤った回答を返すため、情報の鮮度を保つ仕組みを運用に組み込んでおく必要があります。

このソフトウェア企業では、法改正や仕様変更のように反映が遅れると誤答へ直結する情報は当日中に更新し、事例や社内の運用手順は四半期ごとに見直す、と2段階に分けて管理しました。どちらへ分類するかは、その情報が誤っていた場合に顧客まで影響が及ぶかどうかで決めています。

更新頻度が適切かどうかは、更新から反映までにかかった日数を記録しておくと判断できます。当日更新と決めた情報が3日以上遅れているようなら、頻度の設計より先に担当の割り当てを見直す必要があります。四半期ごとの見直しについても、期日を決めずに「随時」としてしまうと着手されないため、月末の決まった日を確保しておきましょう。

メンテ②精度の低下を検知するモニタリング指標

2つ目は、精度が落ちてきたことに気づくための監視です。利用者の評価と、回答できなかった質問の記録を指標として追います。回答が少しずつ的外れになっても、担当者は気づかないうちに使わなくなるだけで、わざわざ管理者へ報告しないことが多くあります。

先ほどのサポート窓口では、回答への評価ボタンの押下結果と、答えられなかった質問のログを毎週集計する運用にしました。低評価の割合が2週続けて上がった時点で、その週に更新したナレッジを確認する手順まで決めています。実際にこの2つの数字を月次の運用会議へ出したことで、誤答が20件を超えた月に原因となったナレッジを特定できました。

監視の指標は、増やしすぎないほうが続きます。低評価の割合と、答えられなかった質問の件数の2つだけでも、精度が落ちはじめた時期は特定できます。反対に、利用者数や起動回数のような数字を並べても、回答の質が落ちたかどうかは読み取れません。

メンテ③ナレッジ管理の運用体制

3つ目は、誰がナレッジを管理し続けるかの体制です。担当と役割を決めておかなければ、更新も監視も続きません。メンテナンスに必要な役割は、次の3つになります。

ナレッジ管理に必要な3つの役割 ①更新の責任者・・・仕様変更や法改正をナレッジへ反映する担当です ②内容を確認する担当・・・更新後の記述に矛盾がないかを点検する担当です ③改善を判断する担当・・・指標を見て整備の優先順位を決める担当です

これらがあいまいなままでは、運用が特定の担当者の善意に頼り、数ヶ月で止まってしまいます。このソフトウェア企業のサポート窓口では、更新の責任者をサポート部門のリーダーに、内容の確認を製品担当に割り当て、月に一度30分の見直しの場を設けました。

体制が整っているかどうかは、担当者が1名交代しても更新が止まらないかで確かめられます。1名に依存している状態であれば、役割を書き出して分担するところから始めましょう。以上が、Agentforce RAGのメンテナンス設計の3つの観点でした。

【一問一答】Agentforce RAGに関するよくある質問

ここまでメンテナンス設計まで整理してきましたが、最後に、Agentforce RAGについて検索されやすい疑問へ短くお答えします。

質問① Agentforce RAGはData Cloudなしでも使えるか

使えません。Data Cloudは2025年10月にData 360へ名称が変わり、Salesforce公式の学習コンテンツでも「Agentforce Data LibraryやEinstein Trust Layerは、Data 360なしでは動作しない」と明記されています。ただし必要なのはData 360の有効化であり、大規模なデータ統合の実装まで先に済ませる必要はありません。まずは1業務分のナレッジから始められます。

※参考記事はこちら

質問② Agentforce RAGのナレッジは何件程度必要か

明確な必要件数はありません。件数よりも、対象とする質問に答えられるだけの情報が正確に整っているかどうかが重要です。今回例に挙げたソフトウェア企業も、450本から360本へ絞り込んだうえで正答率を88%まで上げています。大量に登録しても、矛盾や古い情報が混ざっていれば精度は下がります。

質問③ Agentforce RAGと従来の検索機能は何が違うか

従来の検索は、キーワードに一致する文書を一覧で返すところまでが役割です。一方Agentforce RAGは、関連する情報を検索したうえで、その内容をもとにAIが回答を組み立てて返します。RAGは、社内の情報を「探す」から「尋ねて答えてもらう」へ変えられる仕組みです。利用者が文書を開いて答えを読み取る手間が省ける点が、大きな違いになります。

質問④ Agentforce RAGの構築と運用はどの会社に頼めばいいか

構築だけでなく、ナレッジの整備と運用後のメンテナンスまで一緒に取り組める会社を選ぶことをおすすめします。RAGの精度はナレッジの質で決まり、その維持には継続的な運用が欠かせないからです。設定の代行だけで終わる相手では、精度が落ちたときに原因を切り分けられません。

RAGの精度はプロンプトより先にナレッジの整備が決める

本記事では、Agentforce RAGの仕組みとWeb検索レトリーバーとの違いから、精度を左右する要素、精度が上がらない5つの原因、改善Tips6選、ユースケース別の整備水準、そしてメンテナンス設計までを整理してきました。

全体を通して見えてくるのは、精度の決め手がプロンプトの巧みさではなく、ナレッジの整備にあるということです。今回例に挙げたソフトウェア企業も、450本のナレッジから旧版と重複90本を取り除くクレンジングを起点に、月300件の問い合わせに対する正答率を60%から88%まで改善し、月120件あった誤答を20件まで減らしました。チャンクやプロンプトの調整にも効果はありますが、それらは正確なナレッジがあって初めて働きます。精度に悩んだら、まず参照させている情報を確認し、矛盾と古さを取り除くことから始めてください。

Agentforce RAGは、整えたナレッジを運用しながら改善を重ねていく仕組みです。一度の構築で完成させようとせず、更新と監視を続けることで、担当者がAIの回答を迷わず使える状態に近づきます。本記事で紹介した進め方を、ぜひ自社の状況に合わせて実践してみてはいかがでしょうか。

Agentforceの回答精度やナレッジ設計について、営業・サポートの現場を理解したうえで一緒に進めたい場合は、Agentforce導入・定着支援サービスにお気軽にご相談ください。1ユースケース×3ヶ月のスモールスタートから対応しています。