【第440回】 Agentforce ： データライブラリのレトリーバークエリの変更
2026 年 1 月中旬以降、新規にデータライブラリを作成した場合、または既存のデータライブラリで古いクエリを使用しているレトリーバーのコンテンツ項目を変更した際に、レトリーバーのクエリが自動的に新しい形式へ変更されていることに気づいた方も多いかもしれません。
結論から言うと、これは不具合ではなく 想定通りの挙動であり、新しい仕様 です。
固定値版クエリ（旧仕様）
従来のクエリは、いわば「固定値版のクエリ」でした。
検索条件や取得件数がクエリ内に直接記述されているため、どの条件で、どのデータを使っているのかが一目で分かるという特徴がありました。
SELECT
"v"."hybrid_score__c" AS "Score",
"c"."Chunk__c" AS "Chunk",
"c"."SourceRecordId__c" AS "SourceRecordId",
"c"."DataSource__c" AS "DataSource",
"c"."DataSourceObject__c" AS "DataSourceObject"
FROM
hybrid_search(
TABLE("KA_Knowledge_Data_Library_176_index__dlm"),
'{!$_SEARCH_STRING}',
'Language__c=''{!$_LANGUAGE}''
AND KnowledgePublicationStatus__c=''Online''
AND DataSource__c IN (''Question2_c__c'', ''Answer2_c__c'')',
30
) AS "v"
INNER JOIN
"KA_Knowledge_Data_Library_176_chunk__dlm" AS "c"
ON "c"."RecordId__c" = "v"."RecordId__c"
INNER JOIN
"ssot__KnowledgeArticleVersion__dlm" AS "kav"
ON "c"."SourceRecordId__c" = "kav"."ssot__Id__c"
ORDER BY
"Score" DESC
LIMIT 10実行時パラメーター版クエリ（新仕様）
一方、新しいクエリは 「実行時パラメーター版」 です。
検索文字列・フィルター条件・取得件数などがすべてプレースホルダーに置き換えられ、実行時に動的に渡される設計になっています。
SELECT
"v"."hybrid_score__c" AS "Score",
"c"."Chunk__c" AS "Chunk",
"c"."SourceRecordId__c" AS "SourceRecordId",
"c"."DataSource__c" AS "DataSource",
"c"."DataSourceObject__c" AS "DataSourceObject"
FROM
hybrid_search(
TABLE("KA_Knowledge_Data_Library_176_index__dlm"),
:"_SEARCH_STRING",
:"_PREFILTER_EXPRESSION",
:"_NUM_OF_RESULTS"
) AS "v"
INNER JOIN
"KA_Knowledge_Data_Library_176_chunk__dlm" AS "c"
ON "c"."RecordId__c" = "v"."RecordId__c"
INNER JOIN
"ssot__KnowledgeArticleVersion__dlm" AS "kav"
ON "c"."SourceRecordId__c" = "kav"."ssot__Id__c"
ORDER BY
"Score" DESC
LIMIT {!$_NUM_OF_RESULTS}この変更自体は、Agent が状況に応じて最適な検索条件を使えるようにするための改善であり、内容が変わらない限り、動作上の問題はありません。
分かりにくくなった点
ただし、固定値版クエリでは以下のように条件が明示されていたため、
「どのデータソースを対象に」「何件取得しているか」が直感的に分かりました。
hybrid_search(
TABLE(KA_Service_Agent_1766068136_index__dlm),
'{!$_SEARCH_STRING}',
'Language__c=''{!$_LANGUAGE}''
AND KnowledgePublicationStatus__c=''Online''
AND DataSource__c IN (''Question2_c__c'', ''Answer2_c__c'')',
30
) v新仕様では、これらがすべてプレースホルダーに置き換わるため、クエリを見ただけでは中身が分からなくなっています。
hybrid_search(
TABLE("KA_Service_Agent_1766068136_index__dlm"),
:"_SEARCH_STRING",
:"_PREFILTER_EXPRESSION",
:"_NUM_OF_RESULTS"
) AS vプレースホルダーの中身を確認する方法
そこで、以下の手順で 実行時に使われている実際の値 を確認できます。
手順
1. レトリーバーの詳細ページ（クエリが表示されている画面）を開きます。
2. F12 キーを押して、ブラウザ搭載の「開発者ツール」を起動します。
3. 「Network」タブを選択します。
4. 「Clear Network Log」ボタン（斜線入りの丸いアイコン）をクリックして、一度ログをクリアします。
5. レトリーバーの詳細ページを F5 で再読み込みすると、データが流れ込んできます。
6. フィルターに「EDC.getRetrieverConfiguration」を入力します。
7. 表示されたうちの一つが「EDC.getRetrieverConfiguration=1」なので、そちらをクリックします。ここで、ダブルクリックはしないでください。
※ もう一つの行は「EDC.getRetrieverConfigurations=1」（s あり）でそちらではありません。マウスオーバーすることでどちらか分かります。
8. 次に「Response」タブを開きます。
9. すると、従来のクエリの形で設定が確認できます。
画面で見ると分かりづらいので、メモ帳に移して確認した方が良いです。
{
"placeholderName": ":\"_PREFILTER_EXPRESSION\"",
"placeholderType": "NamedParameter",
"placeholderDataType": "Text",
"placeholderValue": "
Language__c = '{!$_LANGUAGE}'
AND KnowledgePublicationStatus__c = 'Online'
AND DataSource__c IN (
'ssot__ArticleNumber__c',
'Answer2_c__c',
'Question2_c__c'
)
"
}10. これには ArticleNumber__c、Answer2_c__c、Question2_c__c が利用されていることが分かりますが、このことはデータライブラリの現在のコンテンツ項目の設定とも一致しています。
いかがでしたでしょうか。
突然クエリの形式が変わり、戸惑った方もいらっしゃるかもしれませんが、
これは Agent にとってより柔軟で賢い検索を行うための仕様変更です。
仕組みを理解し、必要に応じてプレースホルダーの中身を確認しながら対応していきましょう。
今回は以上です。