しばしば、いいえ。契約書、レポート、メールのフォルダーに対して、全文検索ツールを備えたAIエージェントは適切なファイルを見つけ、該当する箇所だけを読み引用し、インデックスはローカルで実行され、埋め込みモデルやベクトルストアは不要です。GroupDocs.Search.Mcp は Claude Desktop、Claude Code、Cursor、または Copilot に、1つの Docker コマンドでそのツールを提供します:

契約書フォルダーをインデックス化し、次にどの契約書が終了ペナルティに言及しているかを教えて、その条項を引用してください。

設定とトラブルシューティングを含むステップバイステップのバージョンはドキュメントにあります: AI エージェントでドキュメントを検索する方法 (MCP 使用).

なぜみんな最初に埋め込みを選ぶのか

「retrieval-augmented generation（検索強化生成）」がレシピとして登場したからです。ドキュメントをチャンクに分割し、各チャンクを埋め込み、ベクトルを保存し、質問を埋め込み、最も近いチャンクを取得してプロンプトに貼り付けます。これは機能し、質問がドキュメントと全く異なる表現である場合に適したツールです。しかし、呼び出す埋め込みモデル、実行するストア、調整すべきチャンク分割、そしてドキュメントが変更されるたびに再埋め込みが必要なパイプラインです。「300 件の契約書のうち、どれが終了ペナルティに言及しているか」という質問に対しては、検索インデックスが直接答える方が適しています。

直感に裏付ける証拠が揃いました。2025 年後半に arXiv に掲載された研究 (Keyword search is all you need) では、エージェントにフォルダー上でキーワードと正規表現検索だけを行わせ、標準的な RAG パイプラインと比較しました。その結果、ベクトルデータベースなしで RAG スコアの 90% 以上を達成し、頻繁に変わるコレクションにより適していることが示されました。コーディングエージェントはすでに実践でこのパターンを示しており、grep で検索し、結果を洗練させ、再度検索します。

エージェントは代わりに何をするのか

3 つの呼び出しです。GroupDocs.Search.Mcp は 8 つのツールを提供しますが、ループで必要なのはそのうちの 3 つです:

user              agent                         Search MCP server
 |  "Which contracts mention a termination penalty?"           |
 |---------------->|                                           |
 |                 |-- add_to_index ------------------------->|  reads the
 |                 |   {"documentsPath":"contracts",           |  files once,
 |                 |    "indexName":"contracts"}               |  stores text
 |                 |<- "5 document(s) added, 5 in the index" --|
 |                 |-- search ------------------------------->|
 |                 |   {"query":"termination AND penalty"}     |
 |                 |<- {"documentsFound":3, "documents":[ ... |  which files
 |                 |-- get_text_fragments ------------------->|
 |                 |   {"query":"\"termination penalty\""}     |
 |                 |<- === contracts/acme-...-agreement.pdf ===|  the passages
 |<- "Two contracts carry one: Acme (3 monthly fees, 12.3),    |
 |    Globex (50% of the remaining fees). Initech excludes it."|

add_to_index はファイルを一度だけ読み取り、テキストをディスク上の名前付きインデックスに保持します。search は一致したファイルを出現回数付きの JSON で返します。get_text_fragments は各一致箇所を数語のコンテキストと共に返すので、エージェントは契約全体を読み込む代わりに条項を引用できます。

以下は、5 件の合成契約書に対してテストした際にサーバーが実際に返した結果です:

-> search {"query":"termination AND penalty","indexName":"contracts"}
<- documentsFound 3: acme-master-services-agreement.pdf,
   globex-consulting-agreement.docx, initech-nda.docx

-> get_text_fragments {"query":"\"termination penalty\"",...}
<- === contracts/acme-master-services-agreement.pdf (1 occurrence(s)) ===
     …a termination penalty of three monthly fees applies, payable
     within 30…
   === contracts/globex-consulting-agreement.docx (1 occurrence(s)) ===
     …Early termination penalty: the Client pays 50 percent of the fees…

3 番目の契約書に注目してください。Initech の NDA は termination AND penalty にマッチしましたが、そこには 「終了に関連する料金やペナルティはありません」 と記載されているからです。この箇所がマッチと単なる言及を区別し、箇所を読むエージェントはそのように答えます。これがグラウンディングです：回答のすべての主張は、開くことのできるファイルと文を指し示します。

それぞれのアプローチが勝つ場面

埋め込みパイプライン                       エージェント型全文検索
-------------------------------------    -------------------------------------
ドキュメントを分割し、埋め込み、ベクトルストアに保存    add_to_index: ローカル全文検索インデックス
質問を埋め込み、上位 k 個のチャンクを取得                agent searches, refines, searches again
チャンクをプロンプトに貼り付け                           get_text_fragments: 引用された箇所
ドキュメントが変更されたときに再埋め込み                update_index が変更箇所を再読
埋め込みモデルとストアが必要                             実行時にモデル呼び出しなし、ネットワーク不要
意味にマッチ；ランキングは不透明                         単語にマッチ；すべてのヒットが説明可能

全文検索は、質問とドキュメントが共通の単語を持たない場合に失敗します。たとえば 「どの契約がリスクが高いか？」 にはキーワードがありません。語彙が共有されている場合、つまり多くの人が自分のドキュメントについて尋ねる質問（条項名、製品、顧客、請求書番号、日付範囲など）では全文検索が有利です。クエリがヒットしないとき、エージェントは renewal OR renews のように試したり、曖昧検索を行ったりします。サーバーは支援します：引用符なしの 2 語クエリは GroupDocs.Search では何もマッチせず、空結果にはエージェントにフレーズを引用させる hint が含まれます。

質問に応じたツール選択

ユーザーの質問 エージェントの呼び出し
“このフォルダーをインデックス化” add_to_index
“どのファイルが X に言及していますか？” search
“X について何と書かれていますか？” get_text_fragments
“ファイルが変更された、更新してください” update_index
“ドラフトフォルダーを忘れる” remove_from_index
“インデックスに何がありますか？” get_index_info
“別のインデックスを開始” create_index
“なぜ結果が 10 件だけなのですか？” get_license_status

インデックスは PDF、Office、OpenDocument、HTML、メールアーカイブ（PST、OST、MSG、EML）とその添付ファイルを含む、合計 82 種類のフォーマットを理解します。

実行方法

claude mcp add groupdocs-search -- docker run --rm -i \
  -v /path/to/documents:/data ghcr.io/groupdocs-search/search-net-mcp:latest

Cursor、Claude Desktop、GitHub Copilot を組み込んだ VS Code、その他のクライアントは、各自の設定ファイルで同じコンテナを使用します: AI クライアントへの登録。Linux では --user "$(id -u):$(id -g)" を追加し、コンテナがインデックスを書き込めるようにします。サーバーは GroupDocs.Search 26.10 エンジンで動作し、新しいインデックス形式によりインデックスが小さくなり、メモリ使用量が約半分になります（リリースノート）。

正直な制限

  • 評価モードではインデックスは最大 100 文書しか保持できず、検索は最大 10 件しか返しません；すべての応答にその旨が示されます。まず get_license_status を呼び出してください。
  • 全文検索であり、意味検索ではありません：単語にマッチし、意味にはマッチしません。
  • OCR はありません：テキスト層のないスキャン済み PDF はファイル属性のみでインデックス化されます。
  • Docker イメージとしてのみ提供されます（パックされたツールは NuGet のサイズ制限を超えています）。

FAQ

Claude はローカルのドキュメントをアップロードせずに検索できますか？
はい。サーバーはマシン上のコンテナで実行され、マウントしたフォルダーを読み取ります；エージェントが引用した箇所だけがモデルに送られます。

これは RAG ですか？
検索強化型（retrieval-augmented）ですが、エージェント型です：モデルは何を検索するか、十分な情報が得られたかを判断し、埋め込みではなく全文検索インデックスを使用します。

ドキュメントが変更されたらどうなりますか？
エージェントに更新を依頼してください。update_index は変更・追加・削除されたファイルだけを再読します。

さらに深掘り