エージェントやUIなどの消費者に「ある目的の候補集合」を渡したいとき、既存の汎用検索/一覧エンドポイントをそのまま流用したくなる。だが汎用検索を流用すると、そのツールが持つ3つの性質を一緒に背負う。

流用で背負う3つ

• デフォルト取得上限: 汎用検索はページング前提でデフォルト件数上限（例100）を持つ。全件が欲しい経路で流用すると黙って上限で頭打ちになる。
• 本文込みのペイロード: 一覧系はレコード本体（本文等の重いフィールド）を返すことが多く、候補一覧だけ欲しいのに本文の塊を転送する。
• softなフィルタ: 絞り込み条件を呼び出し側の指示（プロンプトやクエリ引数）に依存すると、呼び出し側が条件を忘れれば漏れる。公開/非公開やテナント境界など安全上絶対守りたい条件で特に危険。

判断基準

候補集合に次のいずれかが要るなら、汎用検索の流用でなく目的専用の索引取得を作る。

• 全件が要る（恣意的上限を置きたくない）→ 索引はid/title等の軽いキーだけにし本文を載せない。軽いので全件返しても安い。本文は索引から個別取得の二段でオンデマンドに取る。
• 条件を確実に守らせたい（公開のみ等）→ プロンプト遵守のsoftでなくクエリ側で強制するhardな専用経路にする。
• その目的だけの選別述語が汎用検索の一般パラメータとズレるなら、汎用側へフラグを増やさず目的専用クエリに分ける。

落とし穴

contextに本文を詰めないためにagentへ検索させるとしても、検索ツールが本文返却とデフォルト上限を持てば、バルク本文も恣意的上限も検索ツール側に隠れて残るだけで消えない。

検証

デフォルト上限を超える件数のデータを用意し、候補経路が全件返すか、索引ペイロードに本文が含まれないか、呼び出し側からフィルタを外してもクエリが除外を維持するかを確認する。