Mistral Agentic Searchを導入するときは、既存の単発RAGを直ちに置き換えず、まず検証対象の部品として扱う。製品は2026-08-20に公開され、モデルが文書インデックスを反復検索し、候補文書内で情報を特定し、読み取り、検証できる。2026-08-21時点の公式な入口はMistral Search Toolkitと、StudioおよびVibe内のLibrariesである。公開記事にはプラン、地域、価格の条件が書かれていない。Search Toolkitの更新履歴（changelog）では0.0.8が技術プレビュー（tech preview）とされ、現在掲載されている0.0.9にも破壊的変更がある。本番投入前にバージョン、アカウントでの利用可否、商用条件を確認する。
短い文書から既知の項目を探す質問や、大量の検索結果を返す処理には、検索を1回だけ行う検索拡張生成（retrieval-augmented generation、RAG）を残す。答えが長い文書、表、脚注、複数の情報源に分散し、回答から確認可能な位置へ戻る必要がある場合だけAgentic Searchを試す。「既存インデックスを使える」という説明にも条件がある。現在のバックエンドがSearch Toolkitに接続でき、文書ID、権限メタデータ、安定した位置情報を保持できなければならない。
受け入れ評価では、コーパスのスナップショット、インデックス設定、モデルを固定し、単発RAG、複数回のsearch、完全なナビゲーションを比較する。各経路でタスク合格率、根拠の再確認可能性、成功タスク当たりのコスト、第90百分位（p90）遅延を記録する。完全なナビゲーションで合格率が安定して上がらない、または元文書の位置へ戻れない場合は、対象とする質問を増やさない。
質問ごとに単発RAGかAgentic Searchかを決める
Mistralの公開記事は、短い文書の直接参照、大量のキーワード・意味検索、情報源が予測できる単純な質問にはインデックス検索を勧めている。長い文書、複数の情報源、表、根拠確認が必要な回答がAgentic Searchの対象だ。
| 実際の質問の特徴 | 既定の経路 | 切り替え・停止条件 |
|---|---|---|
| 答えが通常は最初の検索結果に含まれる | 単発RAG | 固定評価セットで正しい箇所を繰り返し逃す場合だけ検索回数を増やす |
| 文書が短く構造が安定し、項目の位置が既知 | 単発RAGまたは構造化クエリ | 直接特定できる項目にエージェントのツールループを追加しない |
| 総合判断をせず、大量の関連箇所を返す | インデックス検索 | 再現率、遅延、処理量を優先し、文書全体を開かない |
| 答えが長い報告書の表、条項、図注、脚注にある | Agentic Search | 文書と安定したページ・位置を返す。見つからなければ根拠不足とする |
| 契約書、財務報告書、技術仕様を複数比較する | Agentic Search | 軌跡に必要な情報源がすべて含まれなければ結論を出さない |
| 根拠を見つけるまでに検索語の変更が必要 | Agentic Search | 検索回数と参照可能文書に上限を設け、到達したら人へ回す |
ナレッジベース全体を一度に移行せず、質問の種類で振り分ける。簡単な質問は単発RAGに残し、文書内移動や複数情報源の確認が必要だと評価で確認できた質問だけをAgentic Searchへ送る。
search、open、navigate、read、grepの役割を分ける
Mistralの公開記事には5つのツールが記載されている。候補文書を見つける処理と、文書内で答えを確認する処理を次のように分ける。
| ツール | 役割 | 評価時の確認点 |
|---|---|---|
search |
既存インデックスから候補文書を探す | 検索語が絞られているか、同じ無関係な結果を繰り返していないか |
open |
候補文書を1件開く | 正しい版、日付、権限範囲を選んだか |
navigate |
ページ、章、文書内領域へ移動する | 位置が安定し、スキャンPDFのページ番号が原本と一致するか |
read |
現在位置の内容を読む | 表の見出し、単位、脚注、前後関係を保っているか |
grep |
開いた文書内で文字列パターンを探す | 表現の違い、OCR誤り、同名項目で見落とさないか |
公開記事はツールの機能を説明しているが、既存文書の権限を自動継承するとは述べていない。認可を受け入れ条件にする。searchは現在の利用者が閲覧できる文書だけを返し、openとreadでも権限を再確認する。インデックスに一致しただけで、テナント、部署、プロジェクトの境界を越えてはならない。
同じインデックスで単発RAG、多段search、完全ナビゲーションを走らせる
Mistralは、Agentic Searchが既存インデックス上で動作でき、モデル固有の微調整も不要だとしている。ただし、どのインデックスでも作業なしで接続できるわけではない。現在のSearch Index文書が組み込みバックエンドとして挙げているのはVespaで、その他はカスタムベクトルストアとして接続する。評価前に、アダプターが本文、文書ID、安定した位置、権限メタデータを返せるか確認する。その後、コーパスのスナップショット、インデックス設定、モデルの版、採点規則を固定し、モデルに許可する検索ツールだけを変える。
| 経路 | 許可するツール | 確認すること |
|---|---|---|
| A：単発RAG基準 | インデックス検索を1回行って回答 | 現在の仕組みが失敗する質問の種類は何か |
| B：多段検索 | searchを繰り返し実行 |
検索語の変更と再試行で漏れた文書を回収できるか |
| C：完全ナビゲーション | searchにopen、navigate、read、grepを追加 |
文書内移動で正答率が上がり、無駄な検索が減るか |
共通インデックスについて、少なくともコーパスのスナップショット、インデックス設定ハッシュ、文書ID規則、位置規則を保存する。分割方法、埋め込みモデル、順位付け、生成モデルを同時に変えてはならない。3経路の比較後に、解析器、分割、ハイブリッド検索、再順位付けを個別に評価する。
評価質問には正解と根拠位置を付ける
既存検索の失敗、手動確認の記録、実際の利用者からの追加質問を基に評価セットを作る。業務らしく見える質問を無作為に生成してはならない。採点対象の各質問に、人が確認した正解、必須情報源、根拠位置を用意する。正解を定義できない質問は探索用セットに入れ、本番開始条件には使わない。
次の項目は例示であり、実際の業務データによる結果ではない。run_repetitions: 3は小規模試行の開始値にすぎず、一般的な統計基準ではない。本番評価の反復回数はリスクとサンプル数から決める。
query_id: contract-renewal-notice-period
corpus_snapshot: contracts-2026-08-21
index_config_hash: sha256:<index-config-hash>
model_id: <explicit-model-id>
harness_version: <commit-or-release>
scorer_version: <rubric-version>
tool_budget: search=4, open=3, read=6
run_repetitions: 3
question: 現行契約と旧契約の自動更新通知期限を比較する。
required_sources: 現行契約、旧契約
expected_evidence: 両契約の更新・解除条項にあるページと原文
answer_rule: それぞれの期限、版の日付、差分を示す。情報源が1つでも欠けたら根拠不足とする
forbidden_behavior: 一方から他方を推測する、単位を省く、OCR結果を確認済み原文として扱う
同じ質問をA、B、Cの各経路で実行し、次を記録する。
| 記録項目 | 合格条件 |
|---|---|
| 実行設定 | データとインデックスの版、モデルとツールの設定、実行基盤と採点器の版を確認できる |
| 最終回答 | 人が確認した規則に従い、数値、日付、単位が一致する |
| 根拠の完全性 | 必須情報源をすべて含み、再度開ける位置を示す |
| 検索軌跡 | 権限外文書、無効なループ、必須情報源の欠落がない |
| 停止動作 | 根拠不足、ツール失敗、回数上限のときに推測しない |
| 反復実行 | 全経路で同じ回数を実行し、合格率と失敗分布を示す |
| 資源消費 | モデル、OCR・埋め込み、検索ツール、基盤の費用と平均・p90遅延を記録する |
最終回答と根拠の両方が合格した場合だけ、タスク成功と数える。正しい数値でも、版が違う、または再確認できないページを示した場合は失敗だ。各経路のコストは「その経路の全実行費用 ÷ その経路の成功タスク数」に統一する。安定したp90を計算できるほどサンプルがない場合は、各実行の遅延とサンプル数を示し、精密に見える末尾指標を出さない。
FinanceBenchとOfficeQA Proは評価問題の選択にだけ使う
Mistralが2026-08-20に公表した結果は、用途別の調整をしていない既定のSearch Toolkit設定で、Mistral Medium 3.5とGLM-5.2を試したものだ。多段検索と文書ナビゲーションが長く密度の高い表中心の資料に有効な可能性は示すが、企業内ナレッジベースでの改善幅は予測できない。
| 公式評価 | 文書と質問 | Mistralの公表結果 | 自社評価に加えるべき問題の種類 |
|---|---|---|---|
| FinanceBench | 米国証券取引委員会への提出書類368件、質問150件、平均約147ページ | 単発RAGから多段searchへ移ると2モデルで47.3、52.6ポイント上昇し、ナビゲーション追加でさらに8.7、6.7ポイント上昇 |
長い財務報告、章をまたぐ数値、検索語の反復変更 |
| FinanceBenchの資源消費 | 同じ評価 | 完全ナビゲーションは多段searchよりトークンを23.9%、33.7%削減。全体p90は255秒から154秒、平均遅延は108秒から71秒へ低下 |
品質、コスト、末尾遅延をまとめて記録し、ツール回数だけで判断しない |
| OfficeQA Pro | 米国財務省公報696件、高難度質問133件、スキャン・表中心のPDF約8.9万ページ | GLM-5.2の完全経路は51.9%で単発RAGより45.6ポイント高い。Mistral Medium 3.5は27.1ポイント上昇 | OCR文書、複数表にまたがる計算、検証可能な数値回答 |
公開ページの要約には、FinanceBenchで26.7%から86%になった集計結果もある。これらはすべてMistral自身の評価であり、記事には質問別出力、採点器のプロンプト、完全な実行成果物がないため、独立再現ではない。公開ベンチマークを再実行するときは、FinanceBenchのデータ版、OfficeQA Proのデータ・採点器の版、実行基盤のコミットを固定する。自社資料の大半が短いFAQ、整ったWebページ、固定項目なら、その質問は単発RAGに残す。
機密文書では隔離境界を段階ごとに確認する
Mistralは、Search Toolkitの公開モジュールをクラウドまたはオンプレミスで動かし、既存インデックスを利用できるとしている。ただし、インデックスがローカルでも処理経路全体がローカルとは限らない。公式QuickstartはVespaをローカルで動かすが、例の埋め込み処理はMistral APIを使う。本番前にデータ取り込み、検索、推論、ログの4群でデータ経路を描き、それぞれの保存場所、事業者、保持期間、アクセス役割を記録する。
少なくとも次の4境界を確認する。
- 文書認可をチャット入口だけでなく、
search、open、readの各段階で実行する。 - 検索ログとデバッグログに、無関係な本文、個人情報、別テナントの断片を保存しない。
- OWASPのRAGセキュリティ指針に従い、文書を信頼できないデータとして扱う。文書内の命令でツール権限、システムプロンプト、回答規則を変更させない。
- 認可済みの根拠が見つからない場合は、未承認の情報源や公開Web検索へ広げず、根拠不足を返す。
データがどこへ行くか、誰が読めるか、いつ削除されるかを説明できない段階があれば、テスト環境に留める。厳格な隔離が必要なら、ローカル解析、インデックス、推論を個別に確認してからクラウド部品を選ぶ。
単発RAG、Agentic Search、人手確認の3つの出口を残す
本番ルーティングを単発RAGとAgentic Searchの二択にしない。簡単な質問は単発RAGへ送り、評価で多段処理が必要だと確認した種類だけをAgentic Searchへ送る。根拠不足、権限競合、ツール失敗、検索上限への到達は、人手確認または明示的な回答拒否へ回す。
対象を広げる前に、次を確認する。
- 複雑な質問の回答・根拠合格率が単発RAG基準より高い
- 誤って振り分けた簡単な質問で、成功タスク当たりのコストや末尾遅延が増えない
- 各回答から文書、位置、ツール順を再生でき、権限または文書の削除がインデックスとツールのアクセスに反映される
- Agentic Search停止時は単発RAGまたは根拠不足へ戻り、根拠なしで回答しない
高リスク質問で権限外文書、誤った版、根拠のない結論が1件でも出たら、その質問種類のAgentic Search経路を停止する。権限、インデックス、回答規則を修正し、同じ評価セットを再実行してから戻す。
接続前に答える3つの質問
既存インデックスをすべて作り直す必要があるか？
必ずしも必要ではない。Mistralは既存インデックス上で動作できるとしているが、現在のSearch Index文書で組み込み対応しているのはVespaで、その他のバックエンドにはカスタムベクトルストアの実装が必要だ。既存アダプターが本文、文書ID、安定した位置、権限メタデータを返せる場合だけ、元のインデックスで3経路を比較する。解析、分割、表抽出、OCRですでに必要情報を失っている、または必要項目を返せない場合は、アダプター追加、移行、再構築が必要になる。
モデルの微調整は必要か？
必要ない。Mistralは5つの検索ツールに微調整やモデル固有の学習は不要としている。ただし、実用性はモデルが正しいツールを選び、回数上限を守り、安定した根拠位置を返せるかで決まる。自社の質問で確認する。
最短で試す方法は？
MistralはSearch Starter Appを勧めている。これはCopierのプロジェクトテンプレートで、ローカル試行にはuvを使うPython 3.12以上の環境、Docker/Vespa、Mistral API Keyが必要だ。既定設定はデータ取り込み、検索、ツール軌跡の確認には使えるが、本番設定ではない。StudioまたはVibeで直接試すならLibrariesを選ぶ。既存エージェント、ワークフロー、顧客環境へ組み込む場合は、Search Toolkitの版、バックエンド適合、商用条件を先に評価する。