エージェント向けの検索は、「ベクトルDBを足せば終わる」問題ではありません。人間と違うクエリ形状・読み方を前提に、どう探させるか（関数呼び出し / コマンド / コード生成）と何を返すか（チャンク / 生コーパス / 境界付きワークスペース）をセットで設計する必要があります。
📑目次
本記事は、RAG・エージェント基盤を設計する開発者、検索/IR基盤の運用者、ドキュメントやコーパスをエージェントに渡すプロダクト担当を想定しています。独立ソース（Hornet、Mintlify、Perplexity Research、arXiv、VentureBeat）の数値と制約を整理し、導入判断用の比較表とチェックリストまで落とします。発見経路となった Speaker Deck / Hatena は話題性のシグナルに留め、方式選定の根拠には使いません。
人間とエージェントで検索行動が違う
同じ検索エンジンでも、エージェントの query mix は人間と異なります。容量計画は volume だけでなく mix 計画になります。
クエリ長と演算子の差
Hornet（Jo Kristian Bergum, 2026-06-03） の独立計測では、人間（AOL ログ）のクエリ長中央値が約2語なのに対し、エージェント（BrowseComp 上の GPT-5 系）は中央値約10語で、人間の p99 を超える長さです。phrase や site: などの演算子も濃くなります。
serving capacity の振れ
100M ドキュメント・同一 BM25 top-10 条件では、serving capacity が大きく振れます。
- 人間（AOL）: 約 3236 QPS（p99 ≤ 500ms）
- エージェント（BrowseComp）: 約 384 QPS（同条件）
- 比率: 約 8.4倍
結果の読み方
読み方の差も設計に効きます。
- 人間: 上位から流し読みし、無関係はスキップし、上位バイアスが残る
- エージェント: 返却全件がコンテキストに入りやすく、無関係文書の混入が精度を大きく下げる
- lost-in-the-middle も起きやすい
容量計画への含意
読者への含意は明確です。「エージェントが増えたから QPS を倍にする」だけでは足りません。
- 長いクエリ・演算子・多段検索に耐える契約を先に置く
- 1クエリ単価とツール回数を観測する
- エージェント向け検索の議論は、まずこの負荷差を前提にする
出典: Hornet — Agentic query workloads change retrieval cost（2026年6月時点）
どう検索させるか — MCP・コマンド探索・Search as Code
探し方は少なくとも3系統あります。導入の軽さと制御粒度がトレードオフです。エージェントループやハーネス設計の外側契約とも接続します（関連: AIエージェントループとハーネス設計のポイント）。
クエリを投げさせる（Function calling / MCP）
検索を関数として公開し、固定パイプラインが top-k を返します。導入は最も軽い一方、制御はツール引数の範囲に閉じます。top-k が毎回コンテキストに積み上がりやすく、長時間タスクでは文脈汚染が起きやすいです。
コマンドで探させる（grep / ls / cat / find）
コーパスをコードベースのように探索させます。
Mintlify（Dens Sumesh, 2026-03-24） は、chunk-only RAG が複数ページ横断や厳密構文に弱いことを受け、Chroma 上の仮想 FS（ChromaFs + just-bash）で UNIX 語彙を提供しました。
実測の要点:
- サンドボックス clone の p90 session boot: 約 46秒 → ChromaFs で約 100ms
- 既存 DB 再利用により、限界コンピュートはほぼ0
- 探索の流れ: coarse filter → prefetch → in-memory fine grep
- 読み取り専用 + パス木の prune で RBAC
制約と評価上の注意
制約もあります。関連度の概念が弱く、語彙不一致や特徴文字列を当てられないと空振りします。
arXiv:2605.15184（Sen et al.） は次を報告しています。
- 多くの設定で grep が vector より高精度
- 一方、最終スコアは harness と結果提示方式（inline vs file）に強く依存
コードで組ませる — Search as Code（SaC）
Perplexity Research（2026-06-01） は、取得・ランキング・フィルタ・fan-out・集約を primitive SDK として公開し、サンドボックス内のコード生成でタスク固有パイプラインを組む Search as Code を提案します。
問題意識は、モノリシックな query→pipeline→resultset 契約にあります。1タスクで数百〜数千回の retrieval が起きる長時間作業では、次が起きやすいです。
- 粗い文脈
- 未使用のドメイン知識
- context pollution
Search as Code では、中間状態を実行環境で処理し、モデル文脈には絞った結果だけを載せます。代わりに、次の運用コストは最大になります。
- SDK 境界の設計
- sandbox 監査
- オペレータ教育
いま決める1行: top-k を毎回積む MCP で足りるか / 厳密文字列探索が主か / パイプラインをコードで組みたいか。
出典（2026年時点）:
何を返すか — チャンク・DCI・境界付きワークスペース
返し方は「読む単位」と「見える範囲」の設計です。top-k チャンクは予測可能ですが、早期フィルタが不可逆になります。RAG の限界を超えた知識運用の議論とも重なります（関連: Agent Searchで知識を運用する）。
チャンクを返す（従来 RAG）
エンジンがランクした上位 k チャンクのみを注入します。量は予測しやすい一方、チャンク分割時点で見える範囲が固定されます。厳密文字列、疎な手がかりの結合、多段仮説の更新には脆い、というのが DCI 系の問題意識です。
コーパスを直接渡す — DCI（Direct Corpus Interaction）
arXiv:2605.05242（Li et al., 2026-05-03） は、埋め込み・ベクトル索引・retrieval API なしで、grep / file read / shell などにより生コーパスを探索する DCI を定義します。
- 主張: 早期 top-k で落ちた証拠を回復できる
- 報告: BRIGHT/BEIR や BrowseComp-Plus 系で強い結果
現場報告（VentureBeat）
VentureBeat（Ben Dickson, 2026-05-22） は、BrowseComp-Plus で意味検索を DCI に置き換えた例を紹介しています。
- 精度の例: 69%→80%、API コスト低減
- 規模 fragility: 100k→400k ドキュメントで精度低下とツール呼び出し増
- 実務に近い形: hybrid（意味検索で recall、DCI で precision）
コンテキスト境界を渡す — Dr-DCI / RISE
Dr-DCI
Dr-DCI（arXiv:2606.14885, Lu et al.） は、retriever を workspace 拡張アクションにし、局所 workspace 内だけ DCI を実行します。
- BrowseComp-Plus で最大 71.2–73.3%
- raw DCI よりツール/時間/コスト削減
- 100K–10M でも安定、と報告
RISE
RISE（arXiv:2606.06880, Zhuang et al.） は、retrieval の役割を「window 用 top-k」だけでなく bounded interaction space の構築と定義します。BM25 空間 + shell 風ナビの報告例:
- BrowseComp-Plus: 純 DCI 並み約 78%・約 1/4 コスト
- 1M ドキュメント: RISE-BM25 81% 対 unrestricted DCI の劣化
対称な制約
制約は対称です。
- 生 DCI: スケールで全件スキャン化し、遅延と不安定さが増える
- 境界付き: 一次検索で落ちた文書が永久に見えない
- 上限: 境界付けの質
選ぶときの3問: 厳密一致が必要か / コーパスが10万を超えて伸びるか / 境界漏れを許容できるか。
出典（2026年時点）:
比較表｜探し方×返し方の選択軸
唯一解はありません。ユースケース制約で行列の1セルを選びます。エージェント query mix は serving capacity を大きく振るため（Hornet 約8.4x）、探し方・返し方を変えると QPS だけでなく1クエリ単価とツール回数も変わります。
探し方の比較
| 軸 | 向く条件 | 強み | 弱み・注意 | 主な独立根拠 |
|---|---|---|---|---|
| MCP / function top-k | 導入速度優先、エンジン機能をそのまま使いたい | ランキング・言い換えをエンジン任せ、実装が軽い | 引数範囲外の制御が弱い、top-k が文脈を汚しやすい | Perplexity SaC が批判するモノリシック契約 |
| コマンド探索（grep/VFS） | 厳密文字列・段階探索、docs をコード同様に触りたい | 学習済み語彙、読む量をエージェントが制御、Mintlify は boot 高速・安価 | 関連度概念が弱い、語彙不一致で空振り、harness 依存 | Mintlify; arXiv grep vs vector |
| Search as Code | タスク固有パイプライン、中間結果を文脈に載せたくない | 戦略をコード化、サンドボックスで中間処理 | SDK+sandbox 運用と教育コスト最大 | Perplexity SaC |
返し方の比較
| 軸 | 向く条件 | 強み | 弱み・注意 | 主な独立根拠 |
|---|---|---|---|---|
| 返す: チャンク RAG | 注入量を予測したい、コーパス巨大 | スケールとコスト予測がしやすい | 早期フィルタ不可逆、厳密一致に脆い | VentureBeat / DCI 問題意識 |
| 返す: 生 DCI | 小〜中規模、原文検証・再走査が必須 | 索引不要で最新、引用・突き合わせが強い | 大規模で遅延・不安定・タイムアウト | arXiv DCI; VentureBeat 規模 fragility |
| 返す: 境界付き WS（Dr-DCI/RISE） | 大規模でも原文操作したい | recall と precision の二段、コスト/安定の報告例 | 境界漏れは回復不能、WS 運用が増える | arXiv Dr-DCI; RISE |
出典: 上表の各行に対応する Hornet / Mintlify / Perplexity / arXiv / VentureBeat（2026年時点）
短い判断基準
- リテラルやエラーコード探索が主 → コマンド or DCI 系を候補に
- コーパスが急拡大する → 生 DCI 単独を避け、境界付き or hybrid
- チームが sandbox/SDK を運用できない → SaC を後回し、MCP + 段階的コマンドから
- 評価は harness 込みで測る（grep vs vector は提示方式で逆転しうる）
コードグラフでコンテキストを絞る系の実装とも組み合わせ可能です（関連: codebase-memory-mcp）。いずれの場合も、コンテキストに何を載せるかが精度とコストを決めます（関連: コンテキスト設計力）。
導入判断チェックリストと次のアクション
ここからが実務です。popularity や英語ベンチ1本のスコアだけで本番方式を固定せず、自システムの制約から「探し方×返し方」を1組選び、今週中に評価タスクを1本固定してください。
採用・強化向きの兆候
- top-k チャンクだけでは複数ページ横断や厳密構文が落ちる
- エージェントが1タスクで何十回も検索し、文脈が汚染される
- コーパス更新が速く、オフライン索引の鮮度がボトルネック
- 人間向け QPS 計画のままエージェント負荷を載せてレイテンシが崩れる
段階導入の推奨順
- 代表タスク 5–10 件を固定（成功条件を outcome で書く）
- 現状の top-k RAG/MCP で失敗モードを分類（早期脱落 / 文脈汚染 / 語彙不一致 / コスト）
- リテラル需要が高ければ、コマンド or DCI を狭いコーパスで PoC
- コーパスが10万超・伸びるなら、Dr-DCI/RISE 型の境界付き WS を設計図に入れる
- hybrid: 意味検索で候補引込 → 境界内で grep/read 精密検証
- クエリ長・演算子・p99・ツール回数・トークンをダッシュボード化（mix 計画）
- SaC は SDK 境界と sandbox 監査が用意できてから
今日からのチェックリスト
- 「厳密一致が必要なタスク」と「意味想起で足りるタスク」を2列に分ける
- 1タスクあたりの想定検索回数と許容トークン/レイテンシを数字で書く
- いまの返し方がチャンクのみか、原文 read ができるかを1行で宣言する
- コーパス規模の上限（今 / 12ヶ月後）を概算する
- 失敗時に primary 検索の外を再探索できるかを Yes/No で答える
- harness（CLI/agent runtime）と tool-result 提示（inline vs file）を固定して評価する
- エージェント query mix を人間 QPS 計画と分けて観測する項目を1つ決める
- セキュリティ: 読み取り専用、パス prune/RBAC、sandbox 出力の持ち出し境界を確認する
やらないこと
- Hatena ブクマ数や Speaker Deck の再話だけで方式を決めない
- 英語ベンチ1本のスコアだけで本番方式を固定しない
- 未観測のまま「エージェント用に QPS を倍」だけして終わらない
筆者の観点
エージェント検索では、まず「エージェントが増えた＝索引を大きくする」ではなく、query mix と返し方の契約を測れる状態にすることが優先です。
- MCP top-k は最短距離だが、長時間タスクでは文脈汚染のコストが後から効く
- 厳密文字列が主戦場なら、コマンド/VFS や DCI 系を狭い範囲で比較する
- コーパスが伸びる前提なら、境界付き workspace を最初から設計図に入れる
数値は公開ベンチと単一の現場報告に依存するため、自タスクの outcome 成功率とツール回数で上書きしてください。
よくある質問（FAQ）
Q1. ベクトルDBを入れればエージェント検索は十分か？
- 不十分なことが多いです
- 密検索は意味想起に強い一方、厳密文字列・疎な手がかり・多段仮説では早期 top-k がボトルネックになり得ます（DCI / VentureBeat）
- hybrid を検討してください
Q2. grep だけでよいか？
- 条件次第です
- 多くの設定で grep が vector より高精度だった報告もありますが、最終スコアは harness と結果提示に強く依存します（arXiv:2605.15184）
- 語彙不一致にも弱いです
Q3. DCI と境界付きワークスペースの違いは？
- DCI は生コーパスを直接探索します
- 境界付き（Dr-DCI/RISE）は軽い検索で workspace を作り、その中だけで精密操作します
- 大規模では後者が安定・低コストになりやすい一方、境界漏れは回復できません
Q4. Search as Code はいつ検討する？
- 固定 top-k 契約では中間結果が文脈を汚染し、タスク固有の fan-out/集約が必要なときです
- SDK + sandbox の運用負荷を飲めるチーム向けです（Perplexity）
Q5. まず何から測るべきか？
- 代表タスクの outcome 成功率
- 1タスクあたり検索回数、p99、トークン
- 厳密一致タスクの再現率
- インフラなら人間/エージェントの query mix 別 QPS も分ける
Q6. Hatena や Speaker Deck だけで判断してよいか？
- 発見シグナルとしては有用です
- 数値・手順・制限の根拠は Hornet / Mintlify / Perplexity / arXiv / VentureBeat など非 Hatena の独立ソースを使ってください
関連記事:
- Open Knowledge Format（OKF）とは？エージェント向けMarkdown知識仕様の導入判断
- MLOpsの継続的学習とエージェント評価｜Demo Hellを避ける実務設計
- グラフとループの使い分け｜導入判断チェックリスト【2026】
まとめ
- エージェント検索は query mix と読み方が人間と違い、基盤コストと精度の両方を動かします。
- 設計の本体は「どう探させるか」×「何を返すか」の組み合わせ選択です。
- MCP は軽いが文脈汚染しやすい。コマンド/VFS は厳密探索に強い。SaC は最大柔軟と最大運用コストです。
- 返し方はチャンク（予測可能）／DCI（原文操作）／境界付き WS（大規模との両立）で制約が対称です。
- 次アクション: タスク分類 → 失敗モード計測 → 狭い PoC → hybrid/境界設計 → mix 観測。人気シグナルは話題性に留め、独立ソースの数値と自タスク評価で決めてください。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す