あなたのコーディングエージェントは、テキストである限りリポジトリ内のものを見つけるのが非常に得意です。Claude Code または Cursor にセンサーのデータシートが示す動作温度について尋ねると、grep で検索し、何も見つからず、推測するか諦めます。なぜならデータシートは PDF で、意思決定記録は Word ファイルだからです。GroupDocs.Search.Mcp は Docker でローカルに実行され、エージェントにこれらのドキュメントに対する全文インデックスを提供し、コードですでに使用している検索→読み取りループと同じものを使用します:
docs フォルダーをインデックス化し、センサーデータシートが示す動作温度と、どの ADR がテレメトリストレージを決定したかを教えてください。
設定とトラブルシューティングを含むステップバイステップ版はドキュメントにあります: リポジトリ内の PDF と Word ドキュメントを Claude Code または Cursor に検索させる方法.
grep が空の結果になるのはなぜですか?
PDF と DOCX は単語をプレーンテキストとして保存していないためです。DOCX は zip アーカイブで、PDF はテキストストリームを圧縮しています。バイト単位で検索しても単語は存在しません。小さなリポジトリでテストしました:PDF のデータシート 1 件、アーキテクチャ意思決定記録と DOCX の要件文書、そしてソースファイルです。
$ grep -ri "TimescaleDB\|operating temperature\|I2C" docs/
$ grep -rn "datasheet" src/
src/sensor.py:1:MAX_TEMP_C = 85 # see docs/datasheet
唯一のヒットは、エージェントが読めないドキュメントを指し示すコードコメントです。これがギャップです。定数の背後にある理由、設計の背後にある決定、テストの背後にある要件は、しばしばまさにそれらのファイルに存在します。
インデックスを使うと何が変わりますか?
エージェントはドキュメント用の取得ツールを得ます。リポジトリのルートからサーバーを登録し、リポジトリがストレージフォルダーとしてマウントされるようにします:
claude mcp add groupdocs-search -- docker run --rm -i \
-v "$(pwd)":/data ghcr.io/groupdocs-search/search-net-mcp:latest
すると同じ質問に対して回答が返ってきます。これはテストリポジトリでサーバーが返した結果です(パスはリポジトリルートからの相対パスで示しています):
-> add_to_index {"documentsPath":"docs","indexName":"gateway"}
<- Indexed 'docs' into index 'gateway': 3 document(s) added,
3 in the index.
-> search {"query":"TimescaleDB","indexName":"gateway"}
<- documentsFound 1: docs/adr-007-telemetry-storage.docx
-> get_text_fragments {"query":"I2C","indexName":"gateway"}
<- === docs/requirements-v2.docx (1 occurrence(s)) ===
…REQ-15: the I2C bus runs at 400 kHz.…
=== docs/tmp117-sensor-datasheet.pdf (1 occurrence(s)) ===
…I2C address selection: ADD0 pin to GND gives 0x48…
あるクエリで要件とデータシートの行が同時に見つかり、手作業で行うのが面倒で grep では不可能なクロスリファレンスの例です。小さなインデックスでは、最初の呼び出しから 80〜240 ミリ秒で検索結果が返ってきました。
エージェントがすでに知っているループ
user agent Search MCP server
| "What does the datasheet say about I2C addresses?" |
|---------------->| |
| |-- search {"query":"I2C"} --------------->|
| |<- requirements-v2.docx, |
| | tmp117-sensor-datasheet.pdf ------------|
| |-- get_text_fragments {"query":"I2C"} --->|
| |<- "...ADD0 pin to GND gives 0x48..." -----|
|<- "0x48 with ADD0 to GND, 0x49 to V+ (datasheet, p.1); |
| REQ-15 runs the bus at 400 kHz." |
search はどのファイルが該当するかを答え、get_text_fragments はコンテキスト数語と共に一致する行を返し、エージェントは両方を引用します。これは grep の形を拡張したもので、PDF、DOCX、XLSX、PPTX、HTML、Markdown、さらにはリポジトリにエクスポートされたメールスレッドまで、合計 82 種類のフォーマットに対応しています。
エージェントにいつ使用すべきか指示する
エージェントはツールを使用すべきタイミングに関するプロジェクト指示に従います。CLAUDE.md または AGENTS.md の 3 行が、grep を試みて失敗し諦めるエージェントと、最初にインデックスを検索するエージェントの違いを生みます:
PDF, DOCX and XLSX files under docs/ are indexed in the groupdocs-search MCP index
'docs'. grep cannot read them: use search (quote phrases) and get_text_fragments
for anything in specs, datasheets or ADRs, and cite the file.
Run update_index (indexName: docs) after pulling changes.
2 つの管理上のポイントがあります。インデックスはマウントされたフォルダーのルートにある .groupdocs-search-index/ に書き込まれるので、.gitignore に追加してください。また、プル後は update_index が変更された部分だけを再読み込みするため、インデックスを最新に保つコストは 1 回の呼び出しだけです。
Cursor と VS Code
同じコンテナは任意の MCP クライアントで動作します。VS Code では、ワークスペースの .vscode/mcp.json が開いているフォルダーをマウントできるため、インデックスがプロジェクトに追随します:
{
"servers": {
"groupdocs-search": {
"type": "stdio",
"command": "docker",
"args": [ "run", "--rm", "-i",
"-v", "${workspaceFolder}:/data",
"ghcr.io/groupdocs-search/search-net-mcp:latest" ]
}
}
}
Cursor は .cursor/mcp.json の mcpServers 配下で同じ command と args を使用します。設定ファイルをコミットすれば、プロジェクトのすべての開発者がツールを利用でき、インデックス自体は git に含めないようにしてください。
なぜすべてを最初にテキストに変換しないのですか?
可能です。エージェントが必要なときに各 PDF を変換させるか、リポジトリに Markdown のコピーを置くかです。どちらも少数のファイルでは機能します。インデックスは一度だけ変換を行い、1 回の呼び出しで最新状態を保ち、エージェントが読む前にどのファイルが重要かを回答します。これにより長時間のセッションのコンテキストが小さく保たれます。その背後にあるエンジンは GroupDocs.Search で、Office や PDF ドキュメントを直接読み取り、メンテナンスが必要なコンバータを介さない点が特徴です。
正直な制限事項
- 評価モードではインデックスは最大 100 文書しか保持できず、検索は最大 10 件しか返しません。最初に
get_license_statusを呼び出してください。 - フルテキスト検索であり、セマンティック検索ではありません。エージェントは文書が使用している語句を使うか、バリエーションを試す必要があります。
- OCR 非対応:テキスト層のないスキャンされたデータシートは、ファイル属性のみでインデックス化されます。
- Docker のみ対応です。Linux では
--user "$(id -u):$(id -g)"を追加して、コンテナが自分の所有するリポジトリにインデックスを書き込めるようにしてください。
FAQ
Claude Code はリポジトリ内の PDF ファイルを読むことができますか?
grep ではできません。GroupDocs.Search MCP サーバーを使用すれば、ローカルで変換せずに検索・引用が可能です。
Cursor と VS Code でも動作しますか?
はい。.cursor/mcp.json または .vscode/mcp.json で同じ docker run 引数を使用してください。VS Code は ${workspaceFolder} をマウントできます。
インデックスはコミットに含まれますか?
それは設定次第です。.groupdocs-search-index/ を .gitignore に追加してください。
さらに深掘り
- ドキュメント、標準的な手順: リポジトリ内の PDF と Word ドキュメントを Claude Code または Cursor に検索させる方法
- ドキュメントハブ: GroupDocs.Search MCP Server
- まずはこちら: フォルダー内のドキュメントに関する質問にベクトルデータベースは必要ですか?
- 関連: ファイルから根拠のある回答を得る: パッセージを引用し、モデルのメモリではなく
- 関連: AI エージェントのプロジェクトメモリ: プロジェクトごとにインデックスを作成し、最新に保つ
- 関連: AI エージェントが 1 つの質問に答えるために 300 件の契約書を読むべきでない理由
- 関連: AI エージェントでメールアーカイブを検索: PST、MSG、EML とその添付ファイル
- オンプレミスとセキュリティモデル: AI ドキュメント処理の 3 つのアーキテクチャと、ファイルをネットワーク内に保持するもの
- 質問: GroupDocs Search フォーラム
- ソース: GroupDocs.Search.Mcp on GitHub