あなたの文書に関する回答は、構築されたテキストの質に依存します。チャットに全文ファイルを貼り付けると、モデルが実際に使用した部分が分かりません。Dockerでローカル実行する GroupDocs.Search.Mcp は、Claude Desktop、Cursor、Copilot に対して別のプリミティブを提供します：get_text_fragments はクエリに一致するパッセージだけを、数語の前後文脈と元ファイル名と共に返すので、エージェントは引用から回答します。

私の契約書は罰則について何と述べていますか？ パッセージを引用し、各パッセージを理解できるだけの文脈を付けてください。

設定とトラブルシューティングを含むステップバイステップ版はドキュメントにあります: 全文ファイルを読む代わりに一致するパッセージを取得する方法.

なぜ回答が文書からずれるのか

コンテキストウィンドウは予算のようなもので、全文ドキュメントはそれを無駄に消費します。罰則に関する質問は、50ページのうち3文程度で十分かもしれません。50ページ全体を貼り付けると、モデルは他のすべての情報の中からその3文を自分で探し出し、書く間それらを保持しなければなりません。長いコンテキストは要約され、冒頭の情報は軽視され、回答はあなたの契約書が何と述べているかではなく、モデルが一般的に契約書は何と言うかという感覚に依存し始めます。業界ではこの管理手法を context engineering と呼びますが、最もシンプルな形は不要なテキストを読み込まないことです。

フラグメントはどのような形か

インデックスはすでに各文書のテキストを保持しているため、サーバーは各一致箇所の前後のパッセージを切り出すことができます。これは、5つの合成契約書に対するテストから得られた実際の応答です。デフォルト設定（前後8語）ではフレーズが得られます：

-> get_text_fragments {"query":"penalty","indexName":"contracts"}
<- === contracts/acme-master-services-agreement.pdf (1 occurrence(s)) ===
     [content] …before the end of the Term, a termination penalty of
   three monthly fees applies, payable within 30…

前後20語にすると条項全体が得られます：

-> get_text_fragments {"query":"penalty","indexName":"contracts",
     "termsBefore":20,"termsAfter":20,"maxFragmentsPerDocument":1}
<- === contracts/acme-master-services-agreement.pdf (1 occurrence(s)) ===
     …convenience on 90 days written notice.
   12.3 If the Client terminates before the end of the Term, a termination
   penalty of three monthly fees applies, payable within 30 days of the
   termination date.
   14.2 Force majeure: neither party is…

termsBefore と termsAfter は調整可能なパラメータです：小さく設定すると「どのファイルのどのあたりか」程度の情報、大きく設定すると「条項全体を引用してほしい」ことになります。maxFragmentsPerDocument と maxDocuments は回答のサイズ上限を設定し、200回出現する単語がコンテキストを埋め尽くすことを防ぎます。

予算の比較（対比）

ファイルを読む                         インデックスを検索
-------------------------------------    -------------------------------------
エージェントがすべての文書を開く       search: どのファイルが一致するか (JSON)
  コンテキストがコーパスとともに増大   get_text_fragments: パッセージ
  長いファイルが質問を圧迫            （各ファイル前後約8語）
  各質問ごに繰り返し                回答がファイル＋パッセージを引用
                                      インデックスは次回再利用される

差はコーパスが大きくなるほど顕著になります。短いファイル3つ程度ではほとんど影響はありません。長い契約書やレポート、メールが入ったフォルダーの場合、1つの質問に対するフラグメントは数百語になり、候補文書すべての全文と比較されます。

言葉が異なるとき

全文検索は単語を一致させますが、これは根拠付けの機能（すべてのヒットが説明可能）であり、リコールの制限（同義語はヒットしない）でもあります。エージェントの役割はバリエーションを試すことであり、各バリエーションが実際に何に一致したかを見ることができます：

-> search {"query":"renewal OR renews","indexName":"contracts"}
<- umbrella-office-lease.pdf, 用語 ["renewal", "renews"]

-> search {"query":"renewl","indexName":"contracts","fuzzy":true}
<- umbrella-office-lease.pdf, 用語 ["renewal", "renews", "rent"]

ファジーマッチングはスペルミスを救い、さらに rent も取得しました。レスポンスが一致した用語を列挙しているため、エージェントやユーザーは過剰マッチを確認でき、盲目的に信頼する必要がなくなります。この透明性こそが「根拠付け」の意味するところです：単に「回答が出典を示す」だけでなく、「出典がどのように見つかったかが分かる」ことです。

根拠付けされた回答の例

引用を求めると、回答は一目で検証できる形で返ってきます：

2つの契約に終了罰金が規定されています。Acme MSA、条項12.3：「終了日から30日以内に支払われる、月額料金3回分の終了罰金が適用されます。」 Globex コンサルティング契約、セクション9：「クライアントは現在のフェーズに残る料金の50％を支払います。」 Initech の NDA は終了と罰金に言及していますが、罰金はないと記載されています。

要約が引用を誤読した場合、その誤読は引用のすぐ隣に表示されます。

正直な制限事項

  • 評価モードではインデックスは最大100文書しか保持せず、検索は最大10件しか返しません。評価モードは一部のフォーマットのインデックステキストに「Evaluation only…」という行を追加し、フラグメントに現れることがあります。サーバーにライセンスを付与し、インデックスを再構築すればこれを除去できます。まず get_license_status を呼び出してください。
  • フラグメントのコンテキストは単語数でカウントされ、文単位ではないため、パッセージが文の途中から始まることがあります。必要に応じて termsBefore を増やしてください。
  • OCRはありません：テキスト層のないスキャン画像からはパッセージを取得できません。
  • Dockerのみ対応です。Linux上では --user "$(id -u):$(id -g)" を追加してください。

よくある質問

Claude に文書からの出典を引用させるにはどうすればよいですか？
ファイル名とともにソーステキストを返すツールを提供します。get_text_fragments はまさにそれを行い、“パッセージとそのファイルを引用してください” と指示すれば習慣化されます。

これによりトークン使用量は減りますか？
質問に答えるために全文書を読み込む必要がなくなるため、エージェントは一致したパッセージだけを読みます。どれだけ節約できるかはファイルのサイズ次第です。

エージェントは必要に応じて全文ファイルを読むことはできますか？
はい、エージェントは独自のファイルツールで全文を読むことができます。フラグメントは検索と引用のためのもので、パッセージだけでは不十分な場合は全文を読みます。

さらに詳しく