判断の分かれ目は、最初の検索結果だけで答えられるか、原文をたどって検証すべきかに尽きます。2026年8月現在、Mistral Agentic Searchは、複雑な文書をモデル自身が検索し、開き、移動し、読んで確かめるための検索レイヤーです。MistralのFinanceBench評価では、一発検索型RAGの正確性が26.7%だった条件に対し、反復検索と文書ナビゲーションを組み合わせた構成は86%に達しました。約3倍という伸びは大きいものの、これはMistralが公表した特定ベンチマークの結果であり、あらゆる社内文書で86%を保証する数字ではありません。
- 仕組み：
search、open、navigate、read、grepの5ツールで、初回検索の後も証拠を探し直せます。 - 向く質問：長い報告書、表や脚注、複数文書の照合、回答根拠の位置確認が必要な質問です。
- 導入判断：短く整理された文書の直接検索は従来RAGを残し、調査が必要な質問だけAgentic Searchへ振り分ける設計が現実的です。
対象読者：社内検索や文書QAの精度改善を検討する開発者、PM、情報システム担当者。まず確認したいのは、自社の誤答が「モデルの推論不足」ではなく「必要なページまで到達できないこと」に起因しているかどうかです。
一発検索型RAGは、上位のチャンクに答えが入っていれば速く、扱いやすい構成です。問題は、答えが表の続き、別ページの注記、別文書の条件に分かれている場合です。最初に取れた断片だけをモデルへ渡す設計では、「資料は合っているのに、読む場所が違う」という失敗から戻れません。
Mistralが2026年8月20日に発表したAgentic Searchは、この戻れない構造に反復ループを加えます。RAGを捨てる製品ではありません。既存インデックスを出発点に、モデルが「次にどこを調べるか」を決められるようにする点が新しさです。ここでは、精度3倍という見出しの中身、5ツールの役割、Search ToolkitとLibrariesの違い、導入時に測るべき指標まで順に整理します。
26.7%から86%へ、数字が示した設計の差
Mistralの公式発表が前面に出したのは、FinanceBenchにおける正確性の変化です。一発検索型RAGは26.7%、検索を反復し文書内をナビゲーションするAgentic Searchは86%。同じ「文書から答える」システムでも、モデルへ渡す道具と調査手順によって結果が大きく変わった、とMistralは説明しています。
| 比較条件 | 正確性 | 読み取り方 |
|---|---|---|
| 一発検索型RAG | 26.7% | 初回に取得した固定チャンクから回答 |
| Agentic Search | 86% | 検索の反復と文書ナビゲーションを含む |
ただし、数字だけを切り取ると誤解が生まれます。Mistralの評価は、同社のSearch Toolkitをデフォルトのチャンク分割、デフォルトのランキング、個別チューニングなしで使ったものです。検証モデルはMistral Medium 3.5とZ.ai GLM-5.2。つまり「任意のモデルと任意のRAGを比べれば常に3倍」という一般法則ではなく、公開されたハーネスと評価条件にひもづくベンダー公表値です。
それでも実務上の示唆は明確です。精度が伸びた主因を、モデルサイズだけに求めなくてよくなりました。初回検索が弱かったときに検索語を変える、候補文書を開く、該当ページへ移る、原文を読む。この調査手順そのものが改善対象になります。
5つのツールで「検索」から「読解」へ進む
Agentic Searchの中核は、モデルへ与える5つの検索ツールです。名称はファイル操作に似ていますが、単なるUIではありません。各ツールを分離することで、モデルは「候補を探す段階」と「証拠を読む段階」を行き来できます。
| ツール | 役割 | 判断できること |
|---|---|---|
search |
既存インデックスを使い、コーパス全体から関連文書を探す | 候補が足りなければ検索語を変えて再検索する |
open |
候補になった特定文書を開く | 別文書へ進むか、この文書を掘るかを決める |
navigate |
ページ、節、領域へ移動する | 表、条項、脚注など目的の位置へ絞り込む |
read |
指定位置の内容を取得する | 回答に必要な文脈と証拠がそろったかを確認する |
grep |
開いた文書内で語句やパターンを探す | 固有名詞、項目名、条番号などの位置を特定する |
たとえば、複数年の財務資料から特定指標の変化理由を尋ねる想定シナリオを考えます。一発検索では、質問に近いチャンクが返った時点で回答生成へ進みます。Agentic Searchでは、まず関連資料を探し、該当年度の文書を開き、表の位置へ移動し、周辺の注記を読みます。根拠が足りなければ、別年度や別の検索語でもう一度探します。
- 質問を分解し、必要な文書の候補を検索する
- 有望な文書を開き、ページや節を絞る
- 語句検索と読解で、回答根拠の前後関係を確認する
- 証拠が不足していれば検索条件を修正する
- 必要な根拠がそろってから回答を生成する
ポイントは、5ツールのすべてを一度ずつ呼ぶことではありません。質問と途中結果に応じて、必要な操作を選べることです。短い規程の定型質問なら最初の検索で終わってもよく、表と脚注の照合が必要なら文書内を深くたどる。この可変性が、固定パイプラインとの大きな違いです。
一発検索型RAGとの違いは「戻れるか」にある
Mistral公式ドキュメントは、Agentic Searchをキーワード検索やセマンティック検索と並ぶ新しい検索方式ではなく、それらを使って反復するオーケストレーション層と説明しています。したがって、ベクトル検索、ハイブリッド検索、リランクは不要になりません。最初の候補を出す土台として引き続き使います。
| 観点 | 一発検索型RAG | Agentic Search |
|---|---|---|
| 検索回数 | 原則として初回検索で固定 | 途中結果に応じて反復 |
| 文書の扱い | 取得チャンクをコンテキスト化 | 文書を開き、位置を移動して読む |
| 失敗からの回復 | 初回候補が弱いと回答も弱くなりやすい | 検索語や文書を変えて探し直せる |
| 得意な質問 | 答えの位置が予測しやすい直接参照 | 長文、表、脚注、複数資料の照合 |
| 運用上の注意 | 取りこぼしを検索品質で管理 | ツール回数、停止条件、証拠品質も管理 |
自社のRAG基盤を先に整えるなら、RAG精度を上げるリランク・ハイブリッド検索のガイドが土台になります。より広いAgentic RAGの設計パターンは、Agentic RAGの4パターン比較で確認できます。今回のMistral発表は、その設計論を文書ナビゲーションという具体的なツール面まで落とし込んだものと捉えると分かりやすいでしょう。
一発検索を残す判断も重要です。Mistral自身、短く整理された文書の直接参照、大量の検索結果を返す用途、答えの場所が予測できる単純な質問では、インデックス検索が適切な出発点だとしています。Agentic Searchの価値は、すべての検索を複雑にすることではなく、追加調査が必要な質問だけに「次の一手」を与えることです。
FinanceBenchの86%を正しく読む
FinanceBenchは、企業の財務文書を使った質問応答ベンチマークです。Mistralの今回の評価対象はSEC提出書類368件、質問150件。文書種別には10-K、10-Q、8-Kが含まれ、平均は約147ページ、総ページ数は約53,900ページと説明されています。長く、表が多く、数値の周辺文脈を読む必要があるため、文書ナビゲーションの差が出やすい条件です。
| 項目 | 確認できた条件 |
|---|---|
| 対象文書 | SEC提出書類368件 |
| 質問数 | 150問 |
| 文書規模 | 平均約147ページ、合計約53,900ページ |
| Search Toolkit設定 | デフォルトのチャンク分割とランキング、個別チューニングなし |
| 検証モデル | Mistral Medium 3.5、Z.ai GLM-5.2 |
| 採点 | 人手ラベルで較正したLLMジャッジ |
伸びの中心は「検索を繰り返せること」
Mistralの内訳で最も大きいのは、一発検索から検索のみを反復するAgentic loopへ変えた段階です。正確性はMistral Medium 3.5で47.3ポイント、GLM-5.2で52.6ポイント上昇したと報告されています。最初の候補が弱くても、検索語を変え、別の候補へ進めることが大きな改善要因でした。
そのうえで、open、navigate、read、grepを加えると、Mistral Medium 3.5でさらに8.7ポイント、GLM-5.2で6.7ポイント上昇しています。広い再検索を繰り返すだけでなく、正しい文書の中へ入って狙った場所を読むことにも独立した効果があった、という分解です。
86%は自社データの保証値ではない
この評価には少なくとも3つの限定があります。第一に、結果の公表主体はMistralであり、第三者による再現試験ではありません。第二に、財務提出書類という特定領域で、質問と正解が整備されたベンチマークです。第三に、採点にはLLMジャッジが使われています。公式条件を明示した点は評価できますが、自社の契約書、設計書、社内規程へ数字をそのまま移すことはできません。
FinanceBench原論文と公式公開リポジトリも確認しておくと、150問の公開サンプルが何を含むか、回答と証拠がどのように用意されているかを追えます。ベンチマーク値は導入の結論ではなく、自社評価を設計するための仮説として使うのが安全です。
精度3倍を自社の検証項目へ置き換える
PoCで再現すべきなのは「86%」そのものではありません。自社で実際に失敗している質問を集め、一発検索から反復検索、さらにナビゲーション追加へ進むごとに何が直るかを比較します。平均点だけでなく、どの質問型に効いたかを残すと、本番でAgentic Searchへ振り分ける条件が見えてきます。
| 評価軸 | 見る内容 | 判断につながる問い |
|---|---|---|
| 回答正確性 | 正解との一致、必要な計算や条件の反映 | 反復で誤答が減った質問型は何か |
| 証拠到達 | 正しい文書、ページ、節を参照できたか | モデルより検索経路に問題がないか |
| 根拠の十分性 | 回答を支える前後文脈がそろっているか | 一つのチャンクだけで断定していないか |
| 失敗時の挙動 | 根拠不足を認識し、再検索または保留できるか | 見つからない情報を作っていないか |
| 運用効率 | ツール呼び出し、トークン、応答時間、処理費用 | 精度向上に見合う負荷か |
評価データには、簡単な直接参照だけでなく、表の列と脚注を一緒に読む質問、複数文書を比較する質問、答えが存在しない質問を含めます。存在しない答えに対して「見つからない」と返せるかは、正解できるかと同じくらい重要です。RAG評価指標の組み立て方は、RAGASとRAG評価指標の実装ガイドも参考になります。
比較は同じ質問、同じ文書集合、同じモデルで行います。モデルまで同時に変えると、改善が検索ループによるものか、モデル差によるものか分からなくなります。Mistralの発表から持ち帰るべきなのは、段階を分けて効果を測る姿勢です。
Search ToolkitとLibrariesの境界を見極める
Agentic Searchの提供形態は大きく2つです。自社のエージェントや業務フローへ検索基盤を組み込むSearch Toolkitと、StudioやVibeの中で文書検索を使うLibrariesです。どちらが上位という関係ではなく、検索基盤を自分で構成したいか、管理された知識ベースから始めたいかで選びます。
| 観点 | Search Toolkit | Libraries |
|---|---|---|
| 主な対象 | 独自エージェント、業務フロー、顧客向け実装 | StudioやVibeで文書知識を利用するチーム |
| 構成自由度 | 取り込み、分割、埋め込み、検索、リランク等を構成 | 文書を持続的な知識ベースとして管理 |
| 運用負担 | インデックスや検索基盤の設計・監視が必要 | 基盤構築を抑えて利用開始しやすい |
| 配置 | 公式発表ではクラウドとオンプレミスに対応 | Studio、Vibe、APIとの接続を公式docsで案内 |
| 向く判断 | 既存基盤へ組み込み、細かく制御したい | まず管理された環境で文書QAを試したい |
Search Toolkitは検索基盤を部品から組みたい場合
Search Toolkit公式ドキュメントでは、取り込み、検索、評価のコンポーネントを持つPythonフレームワークと説明されています。抽出、チャンク分割、埋め込み、ベクトルストア、クエリ書き換え、リランクなどを交換できるため、既存の検索要件へ合わせやすい一方、設計責任も自社側に残ります。
最初の試用には、Mistral公式GitHubのSearch Starter Appがあります。公式docsによれば、取り込みパイプライン、Vespaの検索インデックス、ナビゲーションツールを公開するMCPサーバー、サンプルデータを含むひな型です。具体的な導入コマンドは更新される可能性があるため、この記事に転記せず公式READMEを参照してください。
Librariesは知識ベースの管理から始めたい場合
Libraries公式ドキュメントでは、文書を登録してエージェントへ接続できる持続的な知識ベースとされています。文書の処理状態やアクセス権を管理し、回答には参照元へのリンクを含められます。検索バックエンドを一から組むより、文書QAの利用体験と権限制御を先に検証したいチームに向きます。
コストとレイテンシは「呼び出し回数」だけで決まらない
Agentic Searchは複数のツールを呼ぶため、一発検索より常に重いように見えます。実際、各ツール呼び出しには処理コストがあります。一方で、正しい文書へ入った後にgrepやnavigateで絞れば、広い検索を何度も繰り返す無駄を減らせます。Mistralも公式発表でトークン使用量とレイテンシの改善を報告していますが、具体値を自社環境へ流用するべきではありません。
2026年8月30日時点で、今回確認した発表ページにはAgentic Search専用の一律料金は示されていません。見積もりでは、モデル入出力、埋め込みやOCR、インデックス基盤、検索ツール呼び出し、ログ保存を分けて計測してください。Librariesと自社運用のSearch Toolkitでは費用構造も異なります。
| 制御点 | 設計例 | 避けたい状態 |
|---|---|---|
| 質問ルーティング | 直接参照は一発検索、調査型だけ反復検索 | 全質問を無条件にAgentic Searchへ送る |
| 探索上限 | 検索の反復回数と停止条件を定義 | 証拠が増えないまま探索を続ける |
| 検索範囲 | 文書名、部門、期間、権限で候補を絞る | 毎回コーパス全体を広く検索する |
| 再訪防止 | 確認済み候補を記録し、別の証拠を探す | 同じチャンクを何度も読み直す |
| 観測 | 各ツールの入力、出力、所要時間を保存 | 最終回答だけを見て原因を追えない |
評価では平均応答時間だけでなく、遅い側の分布も見ます。単純質問の大半が速くても、複雑な質問で探索が止まらなければ運用負荷が跳ね上がります。精度、証拠到達、ツール回数、トークン、応答時間を同じログへ結びつけると、どこまで探索させるのが妥当か判断できます。
導入時に起こりやすい失敗と回避策
失敗1：すべての質問を反復検索へ送る
避けたい設計：文書名と項目が明確な直接参照まで、毎回複数文書を開いて調べさせる。
回避策：質問の複雑さ、文書数、証拠確認の必要性でルーティングします。一発検索で十分な質問を残すことは、Agentic Searchの否定ではなく適切な使い分けです。
失敗2：86%を自社の合格基準として流用する
避けたい設計：FinanceBenchの数字だけで稟議や本番判定を進める。
回避策：自社文書から正解と根拠位置を持つ評価セットを作り、一発検索、反復検索、ナビゲーション込みの順に比較します。ベンダー値は仮説の根拠、自社値は導入判断の根拠と分けてください。
失敗3：インデックスの品質問題をツールで隠す
避けたい設計：文書抽出の崩れ、権限メタデータの欠落、更新漏れがある状態で、検索回数だけを増やす。
回避策：正しい文書が候補に入るか、ページや節の位置情報を保持できるか、最新版へ更新されているかを先に確認します。Agentic Searchは既存インデックスを活用しますが、壊れた土台を自動で直す仕組みではありません。
失敗4：回答だけを採点し、探索経路を残さない
避けたい設計：正答か誤答かだけを記録し、どの検索・文書・ページを使ったかを保存しない。
回避策：ツール呼び出しと参照位置をログ化し、誤答を「候補文書なし」「位置特定失敗」「読解失敗」「回答生成失敗」に分けます。原因が分かれば、インデックス、ツール指示、モデルのどこを直すべきか切り分けられます。
よくある質問
Mistral Agentic SearchはRAGの代替ですか？
全面的な代替ではありません。キーワード検索やセマンティック検索を使う既存インデックスの上で、モデルが検索と文書ナビゲーションを反復する層です。短く整理された文書の直接参照では、一発検索型RAGが適切な場合もあります。
なぜFinanceBenchの精度が大きく伸びたのですか？
Mistralの内訳では、一発検索を検索反復へ変えた段階が最も大きな改善要因です。さらに文書を開き、ページや節へ移動し、原文を読むツールを加えることで追加改善が報告されています。初回検索の失敗から回復できることと、正しい文書内を深掘りできることの二段階です。
既存の検索インデックスを利用できますか？
Mistralは既存インデックスを出発点にできると説明しています。ただし、文書内を移動するには、チャンクと元文書の位置関係を追える構造が必要です。現在のインデックスが文書ID、ページ、節、アクセス権を保持しているかを確認してください。
Search ToolkitとLibrariesはどう選べばよいですか？
自社のエージェントや業務フローへ組み込み、取り込みや検索構成を制御したい場合はSearch Toolkitが候補です。StudioやVibeを中心に、管理された文書知識ベースから試したい場合はLibrariesが候補です。データ配置、権限、監視、運用担当の要件も合わせて比較します。
オンプレミスでも使えますか？
Mistralの公式発表は、Search Toolkitをクラウドまたはオンプレミスで利用できるとしています。実際の構成ではモデル接続、OCR、埋め込み、検索バックエンド、ログの各データ経路を確認し、自社の分離境界を満たすか個別に設計してください。
料金や応答速度はどの程度ですか？
一律には答えられません。発表ページにはAgentic Search専用料金の数値がなく、応答速度も文書量、モデル、検索回数、インデックス、配置によって変わります。自社の代表質問で、精度と証拠到達率に加えてツール回数、トークン、応答時間、処理費用を同時に測ってください。
ここまでの要点
- Mistral Agentic Searchは、既存の検索インデックスへ反復検索と文書ナビゲーションを加える検索レイヤーです。
- MistralのFinanceBench評価では26.7%から86%へ約3倍に改善しましたが、特定条件のベンダー公表値であり、自社精度の保証ではありません。
- 改善は、検索を繰り返せる段階と、文書を開いて目的の位置を読める段階の両方で確認されています。
- Search Toolkitは組み込みと制御、Librariesは管理された知識ベースからの利用に向きます。
- 導入可否は、簡単な質問を一発検索に残したうえで、自社の複雑な質問に対する正確性、証拠到達、運用負荷を比較して決めます。
あわせて読みたい
- Agentic RAG実践ガイド｜4つのRAGパターン比較と選び方
- RAG精度を上げるリランク・ハイブリッド検索ガイド
- RAGの精度を測る｜RAGASと評価指標の実装ガイド
- AIエージェントツール比較12選
参考・出典
- Introducing Agentic Search — Mistral、2026年8月20日公開（参照日: 2026年8月30日）
- Agentic Search — Mistral Docs（参照日: 2026年8月30日）
- Search Toolkit — Mistral Docs（参照日: 2026年8月30日）
- Libraries — Mistral Docs（参照日: 2026年8月30日）
- mistralai/search-starter-app — Mistral公式GitHub（参照日: 2026年8月30日）
- FinanceBench: A New Benchmark for Financial Question Answering — Islamほか、2023年（参照日: 2026年8月30日）
- patronus-ai/financebench — FinanceBench公式公開リポジトリ（参照日: 2026年8月30日）
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
