新しいチャットが開始されるたびに、エージェントはあなたのドキュメントを忘れた状態から始まります。エージェントは時間とコンテキストを犠牲にして再読することもできますし、記憶している何かに相談することもできます。GroupDocs.Search.Mcp はローカルディスク上に名前付きの全文インデックスを保持し、セッション間やコンテナの再起動後も存続するため、Claude Desktop、Cursor、または Copilot は各セッション開始時にプロジェクトのドキュメントがすでに検索可能な状態となり、ファイルが変更されたときは 1 回の呼び出しでインデックスを更新します:

契約書をいくつか編集しました。契約インデックスを更新し、現在ペナルティが記載されている契約書を教えてください。

設定とトラブルシューティングを含むステップバイステップ版はドキュメントにあります: ファイルが変更されたときにドキュメントインデックスを最新に保つ方法.

エージェントにとって「メモリ」とは何ですか？

実際には、2 つのことを指します。会話の外部に永続する状態、そしてその状態を安価に保つ方法です。チャット履歴はどちらも満たせません。セッションが終了すると履歴は消え、ドキュメントが変更されても更新されません。検索インデックスはドキュメントに適した手段です。ドキュメントと同じディスク上に存在し、ファイルを読み込まずに「どのファイルが X と言っているか」を答え、インクリメンタルに更新できます。

session 1    add_to_index --> index "contracts" --+
                                                 |  kept on disk in
session 2    search, get_text_fragments <--------+  /data/.groupdocs-search-
             (nothing is re-read)                    index/contracts
files edit   update_index --> re-reads changed, added, deleted files only
new project  create_index {"indexName":"legal-2026"} --> a separate index

更新はどのように機能しますか？

update_index はインデックスとディスク上のファイルを比較し、変更されたものだけを再読します。以下は、2 回の呼び出しの間に 1 件の契約書にペナルティ条項が追加された後、テストでサーバーが返した結果です:

-> get_index_info {"indexName":"contracts"}
<- { "documentCount": 5, "indexedPaths": [ "contracts" ],
     "documentsWithErrors": [], "status": "Ready" }

-> update_index {"indexName":"contracts"}
<- Index 'contracts' updated: 0 added, 1 updated, 0 removed;
   5 document(s) in the index.

-> search {"query":"penalty","indexName":"contracts"}
<- documentsFound 3, including the edited initech-nda.docx

カウントは何が起こったかを示しています: 1 ファイルが再読され、他は何も触れられていません。削除されたファイルは同じ呼び出しで除外されます。

なぜプロジェクトごとに 1 つのインデックスが必要なのか？

別々のコーパスは別々の回答を必要とするからです。今年の契約書に関する質問で昨年のドラフトが出てきてはいけませんし、あるクライアントのドキュメントが別のクライアントのものと混ざってはいけません。インデックス名はコストが低いです:

-> create_index {"indexName":"legal-2026"}
<- Index 'legal-2026' created. Add documents with add_to_index
   (indexName: 'legal-2026').

各インデックスは /data/.groupdocs-search-index 配下のフォルダーとして存在し、名前を指定しない get_index_info はすべてのインデックスを一覧表示します。add_to_index が初回使用時にインデックスを作成するため、通常は create_index を明示的に呼び出す必要はありませんが、意図的に名前を付けることで「インデックス」を「このプロジェクトのメモリ」に変えることができます。

削除に関する唯一のルール

エンジンは追加されたパス全体を削除し、内部の個々のファイルは削除しません。試みた際にサーバーは次のように明示します:

-> remove_from_index {"documentPath":"contracts/hooli-supply-terms.txt",...}
<- Removal failed for 'contracts/hooli-supply-terms.txt':
   'contracts/hooli-supply-terms.txt' is inside the indexed folder
   'contracts'. GroupDocs.Search removes whole indexed paths only: ...

この点を考慮して設計してください。将来的にコーパスの一部（例：特定の年、クライアント、ドラフト）を削除する可能性がある場合は、contracts/2025、contracts/2026 のように別々のパスとしてインデックス化し、個別に削除できるようにします。ディスク上でファイルを削除し update_index を実行しても同様に削除されます。

要求せずに最新状態を保つ

create_index (optional)
      |
      v
add_to_index ---> search ---> get_text_fragments
      ^              ^
      |              |  get_index_info: counts, paths, status
update_index  (files changed on disk)
      |
remove_from_index  (only a path that was given to add_to_index)

更新を自動化する実用的な 3 つの方法:

  1. エージェントの指示に組み込む。 CLAUDE.md または AGENTS.md に「ファイルが変更されている可能性がある場合は、回答前にこのプロジェクトのインデックスに対して update_index を呼び出す」という行を追加すると、セッション開始時にエージェントが実行します。
  2. スケジュールで実行。 MCP 対応の自動化ツールであれば、毎晩 update_index を呼び出すことができ、変更が少ない場合は呼び出しが高速です。
  3. 一括コピー後に実行。 1 回の呼び出しで追加されたすべてのファイルを取得します。

インデックスはアップグレード後も存続します。GroupDocs.Search 22.7 から 26.8 で作成されたインデックスは初回使用時に変換され、隣にバックアップが保持されます。

エージェントが決定することとインデックスが行うこと

エージェントが決定すること インデックスが行うこと
質問が属するインデックス 各名前付きインデックスを個別のフォルダーに保持
ファイルが変更された可能性がある時期 変更・追加・削除されたファイルのみを再読
検索する単語と試すバリエーション 単語、フレーズ、範囲をマッチさせ、見つけた語句を報告
引用するコンテキストの量 要求された語数分の前後テキストを含むパッセージを返す
何を伝えるか 何も返さない: カウント、パス、テキストを返すだけで、結論は返さない

分割は意図的です。判断はモデルに残り、推論に使用される事実は検査可能なツールの出力から得られます。

正直な制限

  • 評価モードではインデックスは最大 100 文書までしか保持できず、検索は最大 10 件までしか返しません。インデックスを信頼できる情報源として使用する前に get_license_status を呼び出してください。
  • インデックスは /data（またはインデックスボリューム）がホストフォルダーとしてマウントされている場合にのみ永続します。そうでなければコンテナの終了とともに消失します。
  • インデックスには文書のテキストが含まれます。文書と同様に保護し、不要になったら廃棄してください。
  • Docker のみ対応です。Linux では --user "$(id -u):$(id -g)" を追加してコンテナがインデックスを書き込めるようにしてください。

FAQ

エージェントはセッション間でドキュメントを記憶していますか？
永続的なインデックスがあれば、はい。インデックスはディスク上に残り、次のセッションでは何も再読せずに検索できます。

ファイルが変更されたときにインデックスを再構築する必要がありますか？
いいえ。update_index は変更・追加・削除されたファイルだけを再読します。

インデックスを読み取り専用のドキュメントとは別に保持できますか？
はい。ドキュメントは読み取り専用でマウントし、書き込み可能なフォルダーを /index にマウントし、GROUPDOCS_MCP_INDEX_PATH=/index を設定してください。

詳細を見る