エージェント時代の文書検索は、ベクトル検索だけでは足りません。
LlamaIndex CEOのJerry Liu氏が2026年6月29日に発表した「Retrieval Harness」は、LlamaParse Indexにファイルシステム風の操作ツールを載せ、10件から100万件超のコーパスをエージェントが自律的にたどれる基盤です。LlamaIndex公式ブログでは「2026年版のRAG」と位置づけられています。本記事では、従来のRAGが抱える課題と、Retrieval Harnessが提供する4つのプリミティブ、導入方法までを整理します。
この記事でわかること
- Retrieval Harnessが解決するRAGの限界
- Hybrid Retrieve・List Files・File Grep・File Readの役割
- ページスクリーンショットによるレイアウト保持の仕組み
- Index V2での利用手順と提供状況
従来RAGの限界とRetrieval Harnessの位置づけ
RAG（Retrieval-Augmented Generation）は、外部文書を検索してLLMの回答に組み込む手法です。LlamaIndexはオープンソースとして、チャンク分割・埋め込み・インデックス化・検索という基本部品を標準化してきました。単発の質問応答には有効ですが、自律的に文書を調べるエージェントには不向きな面があります。
従来のRAGは、検索結果の上位チャンクをプロンプトに詰め込む「一発勝負」に近い設計です。回答がチャンク境界をまたぐと文脈が途切れ、エージェントがファイルを1件ずつ読み込んで補完しようとするとトークン消費とレイテンシが急増します。LlamaIndex公式ブログは、この問題を「セマンティック検索だけでは行き詰まる」と説明しています。
Retrieval Harnessは、コーパス全体をエージェントが呼び出せるツール群として公開する層です。Jerry Liu氏の投稿では、汎用エージェントが任意規模のデータを探索するために必要なツールセットだと述べられています。セマンティック検索と決定論的なファイル操作を1つの推論ループに統合するのが狙いです。
4つのファイルシステムプリミティブ
Retrieval Harnessの中核は、インデックス内の文書をファイルシステムのように扱う4つのAPIです。いずれもclient.beta.retrieval.*名前空間で提供され、既存のLLMオーケストレーションフレームワークのツール呼び出しにそのまま接続できます。
Hybrid Retrieve（ハイブリッド検索）
ベクトル類似度とキーワード検索を組み合わせ、デフォルトでリランキングを適用する第一段階の検索です。大規模コーパスから候補を素早く絞り込み、エージェントの探索範囲を初期化します。開発者ドキュメントでは、vector_pipeline_weightとfull_text_pipeline_weightで両検索の重みを調整でき、メタデータによるフィルタリングにも対応すると記載されています。
List Files（ファイル一覧）
インデックス内のファイル名を列挙し、エージェントに文書構造の地図を渡します。findエンドポイントでは完全一致（file_name）と部分一致（file_name_contains）の両方で検索できます。どの契約書や報告書が存在するかを把握してから深掘りする、という人間の調査手順に近い動きをAPIで再現します。
File Grep（サーバー側正規表現検索）
特定ファイルのパース済みテキストに対し、サーバー側で正規表現マッチを実行します。シリアル番号やエラーコードなど、完全一致が必要な語句をセマンティック検索に頼らず抽出できます。context_charsでマッチ前後の文字数を指定でき、関連箇所だけをエージェントに返せます。不要なチャンクをプロンプトに載せずに済むため、トークン効率が改善します。
File Read（ファイル直接読み取り）
top-kチャンクが文の途中で切れた場合、ファイル全体または指定範囲のパース済みテキストを直接取得します。offsetとmax_lengthでページネーションにも対応し、大容量文書でも必要な区間だけ読み込めます。チャンク分割の副作用である文脈欠落を、エージェントが自律的に修復するための手段です。
レイアウト保持と運用基盤
テキスト抽出だけでは意味が失われる文書向けに、LlamaParseはパース時にページのスクリーンショットを取得し、対応するチャンクに紐づけます。財務表や規制フォーム、多段組レイアウトでは、平坦化した文字列だけでは表の構造が再現できません。テキストだけでは判断がつかない場合、エージェントはレンダリング済みページを参照し、視覚レイアウトに基づいて推論を続けられます。
インフラ面では、LlamaParse Indexがパイプライン全体をマネージドで提供します。文書を接続するだけで、パース・チャンク化・埋め込み・ベクトルストアへの投入が自動で走ります。Incremental Syncは変更ファイルのみ再処理するため、1000件のフォルダに50件追加された場合、次回同期は50件分のコストと時間で済みます。自前のベクトルストアや埋め込みモデルを使う場合は、パース結果のダウンロードにも対応しています。
Pipeline Observabilityは、各ステージのステータスとファイル数を個別に追跡します。同期完了後にインデックスへ反映されないファイルがある場合、どの段階で止まったかをステージカウントから特定できます。取り込み失敗とワークフロー失敗を切り分け、事後調査に頼らず修正できるのが実務上の利点です。
使い方と既存機能との違い
Index V2はStarter・Pro・Enterpriseプラン向けのベータ機能です。SDKはllama-cloud（Python）または@llamaindex/llama-cloud（TypeScript）をインストールし、3段階で利用します。
- Directory — ソース文書をアップロードするコンテナを作成
- Index — ディレクトリ上にインデックスを作成し、パースからベクトル化まで自動実行
- Retrieve / Chat — ハイブリッド検索または組み込みチャットエージェントで問い合わせ
インデックスのstatusがreadyになったら、client.beta.retrieval.retrieveでセマンティック検索を実行できます。Retrieval Harnessのgrep・read・findは、検索結果から得たfile_idを使って追加探索に入る、という二段構えが基本パターンです。
従来のLlamaParse検索APIが「クエリを投げてチャンクを返す」単機能だったのに対し、Retrieval Harnessはエージェントが検索・一覧・grep・読み取りを組み合わせて多段階の調査を行う前提で設計されています。LlamaIndexのウェビナー資料では、grep派と埋め込み派の対立は偽の二項対立であり、コーパス規模によって最適な比率が変わると説明されています。小規模ならgrep中心、大規模ならまずハイブリッド検索で絞り込み、その後grepとreadで検証する、という使い分けが想定されています。
提供状況
Retrieval Harnessは2026年6月時点で、LlamaParseの有料プラン全ティアにおけるベータとして提供されています。ファイルシステムツールは軽量なAPIスキーマとして公開され、LlamaIndexダッシュボードからマネージドインデックスを初期化するか、開発者ドキュメントのAPI仕様に沿って既存アプリケーションへ組み込めます。Index V2のエンドポイントはGA前に変更される可能性があるため、本番導入時はリリースノートの確認が必要です。
エージェントが文書コーパスを「検索バー1本」で扱う時代は終わりつつあります。Retrieval Harnessは、RAGを静的な前処理から動的な探索ループへ移行させる、LlamaParse Indexの中核機能です。社内文書検索や規制対応の調査など、正確性と再現性が求められるユースケースでは、ハイブリッド検索とgrep・readの併用を検討する価値があります。