多くのビジネス知識はメールに保存されており、必要な情報は通常添付ファイルにあります：見積書、署名済みの修正契約、改訂されたスケジュールなど。GroupDocs.Search.Mcp は Docker 上でローカルに実行され、メールファイルやアーカイブ（PST、OST、MSG、EML）を開き、すべてのメッセージとすべての添付ファイルをインデックス化します。そのため Claude Desktop、Cursor、Copilot などがアーカイブ内を直接検索し、マッチがどの添付ファイルから来たかを正確に示すことができます。

メールフォルダーをインデックス化します。どのメッセージが価格上昇について言及しており、正確に何と書かれていますか？

設定とトラブルシューティングを含むステップバイステップのバージョンはドキュメントにあります: ローカルで AI エージェントを使用してメールアーカイブと添付ファイルを検索する方法.

エージェントにとってメールが難しい理由

アーカイブはコンテナの中のコンテナであるためです。PST はフォルダーを保持し、フォルダーはメッセージを保持し、メッセージは添付ファイルを保持し、添付ファイルはそれ自体が Word ファイル、PDF、スプレッドシートです。ファイルツールを持つエージェントは、これを一つの大きなバイナリファイルとしてしか見ません。アーカイブをまず個別のファイルにエクスポートすれば動作しますが、処理が遅く、機密データがディスクに複製され、アーカイブが変更されるたびに再度実行しなければなりません。また、モデルは PST をまったく読み取れません。

検索エンジンがこの入れ子構造を自動的に処理します。各メッセージと各添付ファイルが検索可能な項目となり、結果にはコンテナの場所とその中でマッチが見つかった位置の両方が記録されます。

添付ファイル内のマッチはどのように表示されるか

以下は、3 つの EML メッセージでテストした際にサーバーが返した結果です。フレーズ「price increase」は、添付された Word の見積書の中にだけ出現します；メッセージ本文は単に 「更新された見積書が添付されています」 と述べています。

-> add_to_index {"documentsPath":"mail","indexName":"mail"}
<- Indexed 'mail' into index 'mail': 3 document(s) added, 3 in the index.

-> search {"query":"\"price increase\"","indexName":"mail"}
<- { "documentsFound": 1, "documents": [
     { "filePath": "mail/2026-09-18-re-q3-pricing.eml",
       "innerPath": "quotation-Q-2026-118.docx",
       "occurrences": 1 } ] }

-> get_text_fragments {"query":"\"price increase\"","indexName":"mail"}
<- === mail/2026-09-18-re-q3-pricing.eml → quotation-Q-2026-118.docx
   (1 occurrence(s)) ===
     …Due to raw material costs we announce a price increase
   of 6 percent from 2026-11-01.…

filePath はメッセージを指し、innerPath は添付ファイルを指します。エージェントは「Contoso からの Re: Q3 pricing メッセージで、添付の見積書 Q-2026-118 に記載された 11 月 1 日からの 6% の価格上昇」と答えることができ、その文のすべての部分が追跡可能です。

mail/2026-09-18-re-q3-pricing.eml          <- filePath
  |- body: "please find the updated quotation attached"
  '- attachment: quotation-Q-2026-118.docx  <- innerPath
        "...we announce a price increase of 6 percent..."

メールで有効な質問例

通常のクエリ言語が適用され、いくつかのパターンは特に文書のやり取りで有用です。これらはすべて同じテストメールボックスで確認されています：

  • 「Fabrikam からのどのメッセージが配送遅延について言及していますか？」: fabrikam AND delay。送信者アドレスはメッセージと共にインデックス化されるため、contoso でも本文に会社名が記載されていない請求書が見つかります。
  • 「注文 77812 に言及しているすべてのメールを見つけて」: 77812。整数は単語として扱われます。
  • 「10 月に期限が来る請求書はどれですか？」: invoice AND content: daterange(2026-10-01 ~~ 2026-10-31)。これはメッセージ本文に書かれた日付、ここでは 「2026-10-22 が期限」 にマッチします。content: プレフィックスは重要で、これがないと日付範囲はエンジンが各ファイルに記録した日付にもマッチしてしまいます。

メールにおいてローカル実行が他の何より重要な理由

メールは機密情報が集まる場所です：個人データ、交渉内容、HR のやり取り、法的助言など。メールボックスをアップロードまたはサービスに同期する必要がある検索ツールは、多くのチームにとって受け入れられません。ここではアーカイブをマシン上のコンテナに読み取り専用でマウントし、そこでインデックス化し、検索します。外部に出るテキストはエージェントが回答に引用する部分だけで、ローカルにホストされたモデルを使用すればそれすらも外部に送信されません。

より厳密な設定として、アーカイブを読み取り専用でマウントし、インデックスに専用のボリュームを割り当てます：

docker run --rm -i \
  -v /srv/mail:/data:ro \
  -v /srv/mail-index:/index -e GROUPDOCS_MCP_INDEX_PATH=/index \
  ghcr.io/groupdocs-search/search-net-mcp:latest

大規模アーカイブのスコーピング

数万件のメッセージを含むアーカイブでもライセンスがあれば問題なくインデックス化できますが、計画的に行うことが重要です。フォルダーや年ごとに別々のパス（mail/2025、mail/2026）でインデックス化すれば、エンジンは単一ファイルではなく全体のインデックスパスを削除できるため、特定の年だけを削除または再構築できます。メールは契約書やレポートとは別のインデックスに保持し、文書のやり取りに関する質問が他のすべてのデータに埋もれないようにします。アーカイブが拡大した際には、update_index が新しいメッセージを取得し、古いものは再読しません。

正直な制限事項

  • 評価モードではインデックスは最大 100 件のドキュメントしか保持できず、検索は最大 10 件まで返します。また すべてのメッセージと添付ファイルがカウントされる ため、実際のアーカイブにはライセンスが必要です。まず get_license_status を呼び出してください。
  • 大きな PST のインデックス作成には時間がかかります：すべてのメッセージと添付ファイルが開かれます。一度インデックス化し、その後は update_index を使用します。
  • テキスト層のないスキャンされた添付ファイルはファイル属性のみでインデックス化され、OCR は行われません。
  • Docker のみ対応です。Linux で上記の読み取り専用設定を使用しない場合は --user "$(id -u):$(id -g)" を追加してください。

FAQ

Outlook を使用せずに AI で PST ファイルを検索できますか？
はい。エンジンは PST、OST、MSG、EML を直接読み取り、Outlook は関与せず、何もエクスポートされません。

メールの添付ファイル内も検索できますか？
はい。添付ファイルはそのメッセージの項目としてインデックス化され、マッチがあった場合は innerPath で添付ファイル名が返されます。

メールボックスはどこかにアップロードされますか？
いいえ。ローカルコンテナ内で読み取られ、エージェントが引用する部分だけがモデルプロバイダーに送信されます。

詳細を見る