search

検索コマンド

見慣れないプレースホルダーがある場合や、接続されているツールを確認する必要がある場合は、CONNECTORS.md を参照してください。

接続されているすべての MCP ソースを、1 回のクエリで検索します。ユーザーの質問を分解し、並行して検索を実行して、結果を統合します。

手順

1. 利用可能なソースを確認する

検索する前に、利用可能な MCP ソースを確認します。利用可能なツールの一覧から、接続されているツールを特定してください。一般的なソースは次のとおりです。

• ~~chat — チャットプラットフォームのツール
• ~~email — メールツール
• ~~cloud storage — クラウドストレージツール
• ~~project tracker — プロジェクト追跡ツール
• ~~CRM — CRM ツール
• ~~knowledge base — ナレッジベースのツール

MCP ソースが接続されていない場合：

To search across your tools, you'll need to connect at least one source.
Check your MCP settings to add ~~chat, ~~email, ~~cloud storage, or other tools.

Supported sources: ~~chat, ~~email, ~~cloud storage, ~~project tracker, ~~CRM, ~~knowledge base,
and any other MCP-connected service.

2. ユーザーのクエリを解析する

検索クエリを分析して、次の項目を把握します。

• 意図：ユーザーは何を探していますか？（決定、ドキュメント、人物、進捗報告、会話）
• エンティティ：言及されている人物、プロジェクト、チーム、ツール
• 時間の制約：「今週」「先月」や特定の日付など、最近の情報を示す表現
• ソースの手がかり：特定のツールへの言及（「~~chat で」「あのメール」「そのドキュメント」）
• フィルター：クエリから明示的なフィルターを抽出します。
  • from: — 送信者／作成者で絞り込む
  • in: — チャンネル、フォルダー、場所で絞り込む
  • after: — この日付より後の結果のみ
  • before: — この日付より前の結果のみ
  • type: — コンテンツタイプ（メッセージ、メール、ドキュメント、スレッド、ファイル）で絞り込む

3. サブクエリに分解する

利用可能な各ソースについて、そのソース固有の検索構文を使った、対象を絞ったサブクエリを作成します。

~~chat:

• チャットプラットフォームで利用可能な検索ツールと読み取りツールを使用します
• フィルターを変換します。from: は送信者に、in: はチャンネル／ルームに対応させ、日付は期間フィルターに対応させます
• 適切な場合は、セマンティック検索に自然言語のクエリを使用します
• 完全一致にはキーワードクエリを使用します

~~email:

• 利用可能なメール検索ツールを使用します
• フィルターを変換します。from: は送信者に対応させ、日付は期間フィルターに対応させます
• type: は、適切に添付ファイルのフィルターまたは件名の検索に対応させます

~~cloud storage:

• 利用可能なファイル検索ツールを使用します
• ファイル名に含まれる語句、全文に含まれる語句、更新日、ファイルタイプなどのファイル検索構文に変換します
• ファイル名と内容の両方を考慮します

~~project tracker:

• 利用可能なタスク検索ツールまたはタイプアヘッドツールを使用します
• タスクのテキスト検索、担当者フィルター、日付フィルター、プロジェクトフィルターに対応させます

~~CRM:

• 利用可能な CRM クエリツールを使用します
• アカウント、連絡先、商談、およびその他の関連オブジェクトを横断して検索します

~~knowledge base:

• 概念に関する質問にはセマンティック検索を使用します
• 完全一致にはキーワード検索を使用します

4. 検索を並行して実行する

利用可能なソース全体で、すべてのサブクエリを同時に実行します。別のソースを検索する前に、あるソースの検索が終わるのを待ってはいけません。

各ソースについて：

• 変換したクエリを実行します
• メタデータ（タイムスタンプ、作成者、リンク、ソースタイプ）とともに結果を取得します
• エラーが発生した、または失敗したソースを記録します。1 つの失敗によって、他の検索が妨げられないようにしてください

5. 結果の順位付けと重複排除を行う

重複排除：

• 複数のソースに同じ情報がある場合（例：~~chat で話し合われ、メールで確認された決定）を特定します
• 結果を重複して表示するのではなく、関連する結果をまとめます
• 最も信頼性が高い、または最も完全な内容を優先します

順位付けの要素：

• 関連性：結果はクエリの意図にどれほど合致していますか？
• 新しさ：進捗や決定に関するクエリでは、より新しい結果を上位にします
• 信頼性：事実に関する質問では、公式ドキュメント > Wiki > チャットメッセージ。「何を話し合ったか」という質問では、会話 > ドキュメント
• 完全性：背景情報がより多く含まれる結果を上位にします

6. 結果を統合して提示する

生の検索結果を羅列するのではなく、統合した回答として提示します。

事実／決定に関するクエリの場合：

[Direct answer to the question]

Sources:
- [Source 1: brief description] (~~chat, #channel, date)
- [Source 2: brief description] (~~email, from person, date)
- [Source 3: brief description] (~~cloud storage, doc name, last modified)

探索的なクエリ（「X について何がわかっていますか」）の場合：

[Synthesized summary combining information from all sources]

Found across:
- ~~chat: X relevant messages in Y channels
- ~~email: X relevant threads
- ~~cloud storage: X related documents
- [Other sources as applicable]

Key sources:
- [Most important source with link/reference]
- [Second most important source]

特定のものを探す「検索」クエリの場合：

[The thing they're looking for, with direct reference]

Also found:
- [Related items from other sources]

7. エッジケースへの対応

曖昧なクエリ： クエリの解釈が複数ある場合は、検索する前に確認の質問を1つしてください。

"API redesign" could refer to a few things. Are you looking for:
1. The REST API v2 redesign (Project Aurora)
2. The internal SDK API changes
3. Something else?

検索結果がない場合：

I couldn't find anything matching "[query]" across [list of sources searched].

Try:
- Broader terms (e.g., "database" instead of "PostgreSQL migration")
- Different time range (currently searching [time range])
- Checking if the relevant source is connected (currently searching: [sources])

検索結果が一部のみの場合（一部のソースでエラーが発生した場合）：

[Results from successful sources]

Note: I couldn't reach [failed source(s)] during this search.
Results above are from [successful sources] only.

注意事項

• 常に複数のソースを並行して検索してください。順番に検索してはいけません
• 検索結果をそのまま列挙するのではなく、内容をまとめて回答してください
• ユーザーがさらに詳しく調べられるよう、出典を明記してください
• ユーザーのフィルター構文を尊重し、ソースごとに適切に適用してください
• クエリに特定の人物が含まれる場合は、すべてのソースでその人物のメッセージ、ドキュメント、言及を検索してください
• 時間的な制約があるクエリでは、ランキングで新しさを優先してください
• 接続されているソースが1つだけの場合でも、そのソースから有用な結果を提供してください