claude-skills/

Anthropic公式スキル・プラグインの日本語ディレクトリ

last sync 22h ago
スキルKnowledge Work

🔍search

プラグイン
Enterprise Search
引数
<query>

説明

すべての接続済みソースを一度のクエリで横断検索します。 次のような場合に使用: - 「あのドキュメントを探して…」 - 「〇〇についてどう決定したっけ…」 - 「〇〇に関する会話はどこにあった…」 - チャット、メール、クラウドストレージ、プロジェクトトラッカーなど、どこに存在するかわからない意思決定・ドキュメント・ディスカッションを探したいとき

原文を表示

Search across all connected sources in one query. Trigger with "find that doc about...", "what did we decide on...", "where was the conversation about...", or when looking for a decision, document, or discussion that could live in chat, email, cloud storage, or a project tracker.

ユースケース

  • 複数のソースからドキュメントを探すとき
  • 意思決定の経緯を確認するとき
  • 特定のトピックに関する会話を検索するとき
  • 保存場所が不明な情報を探すとき

本文(日本語訳)

Search コマンド

見慣れないプレースホルダーが含まれている場合や、接続済みのツールを確認したい場合は、CONNECTORS.md を参照してください。

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


手順

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

検索を開始する前に、どの MCP ソースが利用可能かを確認します。利用可能なツールリストから接続済みのツールを特定してください。主なソース:

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

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

ツールを横断して検索するには、少なくとも 1 つのソースを接続する必要があります。
MCP の設定から ~~chat、~~email、~~cloud storage などのツールを追加してください。

対応ソース: ~~chat、~~email、~~cloud storage、~~project tracker、~~CRM、~~knowledge base、
およびその他の MCP 接続済みサービス。

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

検索クエリを分析し、以下の要素を把握します:

  • 意図: ユーザーは何を探しているか?(決定事項・ドキュメント・人物・ステータス更新・会話)
  • エンティティ: 言及されている人物・プロジェクト・チーム・ツール
  • 時間的条件: 新しさを示すシグナル(「今週」「先月」「特定の日付」)
  • ソースのヒント: 特定ツールへの言及(「~~chat で」「そのメール」「そのドキュメント」)
  • フィルター: クエリから明示的なフィルターを抽出する:
    • from: — 送信者 / 作成者で絞り込む
    • in: — チャンネル・フォルダ・場所で絞り込む
    • after: — この日付以降の結果のみ
    • before: — この日付以前の結果のみ
    • type: — コンテンツ種別で絞り込む(メッセージ・メール・ドキュメント・スレッド・ファイル)

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

利用可能な各ソースに対して、そのソース固有の検索構文を用いたターゲット型サブクエリを作成します:

~~chat:

  • チャットプラットフォームで利用可能な検索・読み取りツールを使用する
  • フィルターを変換: from: → 送信者、in: → チャンネル / ルーム、日付 → 時間範囲フィルター
  • セマンティック検索が適切な場合は自然言語クエリを使用する
  • 完全一致が必要な場合はキーワードクエリを使用する

~~email:

  • 利用可能なメール検索ツールを使用する
  • フィルターを変換: from: → 送信者、日付 → 時間範囲フィルター
  • type: は添付ファイルフィルターまたは件名検索に適宜マッピングする

~~cloud storage:

  • 利用可能なファイル検索ツールを使用する
  • ファイルクエリ構文に変換: ファイル名の一致・本文の一致・更新日・ファイル種別
  • ファイル名とコンテンツの両方を考慮する

~~project tracker:

  • 利用可能なタスク検索・タイプアヘッドツールを使用する
  • タスクのテキスト検索・担当者フィルター・日付フィルター・プロジェクトフィルターにマッピングする

~~CRM:

  • 利用可能な CRM クエリツールを使用する
  • Account・Contact・Opportunity などの関連オブジェクトを横断して検索する

~~knowledge base:

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

4. 並列で検索を実行する

利用可能なすべてのソースに対して、サブクエリを同時に実行します。あるソースの結果を待ってから別のソースを検索することはしないでください。

各ソースに対して:

  • 変換済みクエリを実行する
  • メタデータ(タイムスタンプ・作成者・リンク・ソース種別)付きで結果を取得する
  • 失敗したソースやエラーを返したソースを記録する — 1 つの失敗が他の検索をブロックしないようにする

5. 結果をランク付けして重複を排除する

重複排除:

  • 複数のソースに同じ情報が出現している場合を特定する(例: ~~chat で議論された決定事項がメールでも確認されている場合)
  • 重複を個別に表示するのではなく、関連する結果をグループ化する
  • より信頼性が高い、または内容が充実したバージョンを優先する

ランク付けの基準:

  • 関連性: クエリの意図にどれだけ合致しているか
  • 新しさ: ステータス / 決定事項のクエリでは新しい結果を上位に置く
  • 権威性: 事実確認のクエリでは「公式ドキュメント > Wiki > チャットメッセージ」、「何を議論したか」のクエリでは「会話 > ドキュメント」を優先する
  • 完全性: より多くのコンテキストを含む結果を上位に置く

6. 統合された結果を表示する

レスポンスは、生の検索結果のリストではなく、統合された回答としてフォーマットします:

事実確認 / 決定事項のクエリの場合:

[質問への直接的な回答]

ソース:
- [ソース 1: 簡単な説明] (~~chat, #チャンネル名, 日付)
- [ソース 2: 簡単な説明] (~~email, 送信者名, 日付)
- [ソース 3: 簡単な説明] (~~cloud storage, ドキュメント名, 最終更新日)

探索的なクエリの場合(「X について何がわかっているか」):

[すべてのソースの情報を組み合わせた統合サマリー]

検索済みソース:
- ~~chat: Y チャンネルで X 件の関連メッセージ
- ~~email: X 件の関連スレッド
- ~~cloud storage: X 件の関連ドキュメント
- [その他該当するソース]

主要ソース:
- [最も重要なソース(リンク / 参照付き)]
- [2 番目に重要なソース]

「見つける」クエリの場合(特定のものを探している場合):

[探しているもの(直接的な参照付き)]

その他の関連アイテム:
- [他のソースから見つかった関連アイテム]

7. エッジケースに対応する

曖昧なクエリの場合: クエリが複数の意味に解釈できる場合は、検索前に 1 つだけ確認の質問をします:

「API 再設計」はいくつかの内容が考えられます。以下のどれをお探しですか?
1. REST API v2 の再設計(プロジェクト Aurora)
2. 内部 SDK API の変更
3. その他

結果がない場合:

「[クエリ]」に一致するものが [検索済みソースのリスト] から見つかりませんでした。

以下をお試しください:
- より広い検索語(例: 「PostgreSQL マイグレーション」の代わりに「データベース」)
- 別の時間範囲(現在の検索範囲: [時間範囲])
- 関連ソースが接続されているかどうかの確認(現在の検索対象: [ソース])

一部のソースが失敗した場合(部分的な結果):

[成功したソースからの結果]

注意: 今回の検索中に [失敗したソース] に接続できませんでした。
上記の結果は [成功したソース] のみのものです。

備考

  • 常に複数のソースを並列で検索すること — 順次実行は不可
  • 結果は回答として統合すること — 生の検索結果をそのまま列挙しない
  • ユーザーがさらに深掘りできるよう、ソースの出典を明記すること
  • ユーザーのフィルター構文を尊重し、各ソースに適切に適用すること
  • クエリに特定の人物が言及されている場合は、すべてのソースでその人物のメッセージ / ドキュメント / 言及を検索すること
  • 時間的に重要なクエリでは、ランク付けで新しさを優先すること
  • 1 つのソースしか接続されていない場合でも、そのソースから有用な結果を提供すること
原文(English)を表示

Search Command

If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.

Search across all connected MCP sources in a single query. Decompose the user's question, run parallel searches, and synthesize results.

Instructions

1. Check Available Sources

Before searching, determine which MCP sources are available. Attempt to identify connected tools from the available tool list. Common sources:

  • ~~chat — chat platform tools
  • ~~email — email tools
  • ~~cloud storage — cloud storage tools
  • ~~project tracker — project tracking tools
  • ~~CRM — CRM tools
  • ~~knowledge base — knowledge base tools

If no MCP sources are connected:

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. Parse the User's Query

Analyze the search query to understand:

  • Intent: What is the user looking for? (a decision, a document, a person, a status update, a conversation)
  • Entities: People, projects, teams, tools mentioned
  • Time constraints: Recency signals ("this week", "last month", specific dates)
  • Source hints: References to specific tools ("in ~~chat", "that email", "the doc")
  • Filters: Extract explicit filters from the query:
    • from: — Filter by sender/author
    • in: — Filter by channel, folder, or location
    • after: — Only results after this date
    • before: — Only results before this date
    • type: — Filter by content type (message, email, doc, thread, file)

3. Decompose into Sub-Queries

For each available source, create a targeted sub-query using that source's native search syntax:

~~chat:

  • Use available search and read tools for your chat platform
  • Translate filters: from: maps to sender, in: maps to channel/room, dates map to time range filters
  • Use natural language queries for semantic search when appropriate
  • Use keyword queries for exact matches

~~email:

  • Use available email search tools
  • Translate filters: from: maps to sender, dates map to time range filters
  • Map type: to attachment filters or subject-line searches as appropriate

~~cloud storage:

  • Use available file search tools
  • Translate to file query syntax: name contains, full text contains, modified date, file type
  • Consider both file names and content

~~project tracker:

  • Use available task search or typeahead tools
  • Map to task text search, assignee filters, date filters, project filters

~~CRM:

  • Use available CRM query tools
  • Search across Account, Contact, Opportunity, and other relevant objects

~~knowledge base:

  • Use semantic search for conceptual questions
  • Use keyword search for exact matches

4. Execute Searches in Parallel

Run all sub-queries simultaneously across available sources. Do not wait for one source before searching another.

For each source:

  • Execute the translated query
  • Capture results with metadata (timestamps, authors, links, source type)
  • Note any sources that fail or return errors — do not let one failure block others

5. Rank and Deduplicate Results

Deduplication:

  • Identify the same information appearing across sources (e.g., a decision discussed in ~~chat AND confirmed via email)
  • Group related results together rather than showing duplicates
  • Prefer the most authoritative or complete version

Ranking factors:

  • Relevance: How well does the result match the query intent?
  • Freshness: More recent results rank higher for status/decision queries
  • Authority: Official docs > wiki > chat messages for factual questions; conversations > docs for "what did we discuss" queries
  • Completeness: Results with more context rank higher

6. Present Unified Results

Format the response as a synthesized answer, not a raw list of results:

For factual/decision queries:

[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)

For exploratory queries ("what do we know about 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]

For "find" queries (looking for a specific thing):

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

Also found:
- [Related items from other sources]

7. Handle Edge Cases

Ambiguous queries: If the query could mean multiple things, ask one clarifying question before searching:

"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?

No results:

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])

Partial results (some sources failed):

[Results from successful sources]

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

Notes

  • Always search multiple sources in parallel — never sequentially
  • Synthesize results into answers, do not just list raw search results
  • Include source attribution so users can dig deeper
  • Respect the user's filter syntax and apply it appropriately per source
  • When a query mentions a specific person, search for their messages/docs/mentions across all sources
  • For time-sensitive queries, prioritize recency in ranking
  • If only one source is connected, still provide useful results from that source

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。