jpskill.com
🛠️ 開発・MCP コミュニティ

search-strategy

Query decomposition and multi-source search orchestration. Breaks natural language questions into targeted searches per source, translates queries into source-specific syntax, ranks results by relevance, and handles ambiguity and fallback strategies.

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o search-strategy.zip https://jpskill.com/download/22611.zip && unzip -o search-strategy.zip && rm search-strategy.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/22611.zip -OutFile "$d\search-strategy.zip"; Expand-Archive "$d\search-strategy.zip" -DestinationPath $d -Force; ri "$d\search-strategy.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して search-strategy.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → search-strategy フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

検索戦略

不慣れなプレースホルダーが表示された場合や、どのツールが接続されているかを確認する必要がある場合は、CONNECTORS.md をご覧ください。

エンタープライズ検索の核となるインテリジェンスです。単一の自然言語の質問を、並行したソース固有の検索に変換し、ランク付けされ重複排除された結果を生成します。

目標

これを:

"What did we decide about the API migration timeline?"

接続されているすべてのソースにわたるターゲット検索に変換します:

~~chat:  "API migration timeline decision" (semantic) + "API migration" in:#engineering after:2025-01-01
~~knowledge base: semantic search "API migration timeline decision"
~~project tracker:  text search "API migration" in relevant workspace

そして、結果を単一の一貫した回答に統合します。

クエリ分解

ステップ1:クエリタイプの特定

ユーザーの質問を分類して、検索戦略を決定します。

クエリタイプ 戦略
決定 "Xについて何が決定されましたか?" 会話(~~chat、メール)を優先し、結論を示すシグナルを探します
ステータス "プロジェクトYのステータスはどうなっていますか?" 最近のアクティビティ、タスクトラッカー、ステータス更新を優先します
ドキュメント "Zの仕様書はどこにありますか?" Drive、Wiki、共有ドキュメントを優先します
人物 "Xを担当しているのは誰ですか?" タスクの割り当て、メッセージの作成者、ドキュメントの共同作業者を検索します
事実 "Xに関する当社のポリシーは何ですか?" Wiki、公式ドキュメントを優先し、次に確認の会話を優先します
時間 "Xはいつ発生しましたか?" 広範な日付範囲で検索し、タイムスタンプを探します
探索的 "Xについて何がわかっていますか?" すべてのソースにわたる広範な検索、統合

ステップ2:検索コンポーネントの抽出

クエリから以下を抽出します。

  • キーワード: 結果に表示される必要のある主要な用語
  • エンティティ: 人物、プロジェクト、チーム、ツール(利用可能な場合はメモリシステムを使用)
  • 意図シグナル: 決定を示す言葉、ステータスを示す言葉、時間を示すマーカー
  • 制約: 時間範囲、ソースのヒント、作成者フィルター
  • 否定: 除外すべきもの

ステップ3:ソースごとのサブクエリの生成

利用可能な各ソースに対して、1つ以上のターゲットクエリを作成します。

セマンティック検索を優先するケース:

  • 概念的な質問(「〜についてどう思いますか?」)
  • 正確なキーワードが不明な質問
  • 探索的なクエリ

キーワード検索を優先するケース:

  • 既知の用語、プロジェクト名、略語
  • ユーザーが引用した正確なフレーズ
  • フィルターが多いクエリ(from:、in:、after:)

トピックが異なる方法で参照される可能性がある場合は、複数のクエリバリアントを生成します。

User: "Kubernetes setup"
Queries: "Kubernetes", "k8s", "cluster", "container orchestration"

ソース固有のクエリ変換

~~chat

セマンティック検索(自然言語の質問):

query: "What is the status of project aurora?"

キーワード検索:

query: "project aurora status update"
query: "aurora in:#engineering after:2025-01-15"
query: "from:<@UserID> aurora"

フィルターマッピング: | エンタープライズフィルター | ~~chat 構文 | |------------------|--------------| | from:sarah | from:sarah または from:<@USERID> | | in:engineering | in:engineering | | after:2025-01-01 | after:2025-01-01 | | before:2025-02-01 | before:2025-02-01 | | type:thread | is:thread | | type:file | has:file |

~~knowledge base (Wiki)

セマンティック検索 — 概念的なクエリに使用します。

descriptive_query: "API migration timeline and decision rationale"

キーワード検索 — 正確な用語に使用します。

query: "API migration"
query: "\"API migration timeline\""  (正確なフレーズ)

~~project tracker

タスク検索:

text: "API migration"
workspace: [workspace_id]
completed: false  (ステータスクエリの場合)
assignee_any: "me"  ("私のタスク" クエリの場合)

フィルターマッピング: | エンタープライズフィルター | ~~project tracker パラメーター | |------------------|----------------| | from:sarah | assignee_any または created_by_any | | after:2025-01-01 | modified_on_after: "2025-01-01" | | type:milestone | resource_subtype: "milestone" |

結果のランキング

関連性スコアリング

各結果を以下の要素でスコア付けします(クエリタイプによって重み付けされます)。

要素 重み (決定) 重み (ステータス) 重み (ドキュメント) 重み (事実)
キーワード一致 0.3 0.2 0.4 0.3
鮮度 0.3 0.4 0.2 0.1
権威性 0.2 0.1 0.3 0.4
完全性 0.2 0.3 0.1 0.2

権威性階層

クエリタイプによって異なります。

事実/ポリシーに関する質問の場合:

Wiki/公式ドキュメント > 共有ドキュメント > メールアナウンス > チャットメッセージ

「何が起こったか」/決定に関する質問の場合:

会議メモ > スレッドの結論 > メール確認 > チャットメッセージ

ステータスに関する質問の場合:

タスクトラッカー > 最近のチャット > ステータスドキュメント > メール更新

曖昧さの処理

クエリが曖昧な場合は、推測するよりも、焦点を絞った明確化の質問を1つ行うことを優先します。

曖昧な質問: "search for the migration"
→ "いくつかのマイグレーションに関する参照が見つかりました。お探しなのは次のうちどれですか?
   1. データベースマイグレーション (Project Phoenix)
   2. クラウドマイグレーション (AWS → GCP)
   3. メールマイグレーション (Exchange → O365)"

明確化を求めるのは、次の場合のみです。

  • 非常に異なる結果を生み出す、真に異なる解釈がある場合
  • 曖昧さが検索するソースに大きく影響する場合

明確化を求めないのは、次の場合です。

  • クエリが有用な結果を生成するのに十分明確な場合
  • 軽微な曖昧さが複数の解釈からの結果を返すことで解決できる場合

フォールバック戦略

ソースが利用できない場合、または結果を返さない場合:

  1. ソースが利用できない: そのソースをスキップし、残りのソースを検索し、ギャップをメモします。
  2. ソースから結果がない: より広範なクエリ用語を試す、日付フィルターを削除する、代替キーワードを試す。
  3. すべてのソースが何も返さない: ユーザーにクエリの変更を提案する。
  4. レート制限: 制限をメモし、他のソースからの結果を返し、後で再試行することを提案する。
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Search Strategy

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

The core intelligence behind enterprise search. Transforms a single natural language question into parallel, source-specific searches and produces ranked, deduplicated results.

The Goal

Turn this:

"What did we decide about the API migration timeline?"

Into targeted searches across every connected source:

~~chat:  "API migration timeline decision" (semantic) + "API migration" in:#engineering after:2025-01-01
~~knowledge base: semantic search "API migration timeline decision"
~~project tracker:  text search "API migration" in relevant workspace

Then synthesize the results into a single coherent answer.

Query Decomposition

Step 1: Identify Query Type

Classify the user's question to determine search strategy:

Query Type Example Strategy
Decision "What did we decide about X?" Prioritize conversations (~~chat, email), look for conclusion signals
Status "What's the status of Project Y?" Prioritize recent activity, task trackers, status updates
Document "Where's the spec for Z?" Prioritize Drive, wiki, shared docs
Person "Who's working on X?" Search task assignments, message authors, doc collaborators
Factual "What's our policy on X?" Prioritize wiki, official docs, then confirmatory conversations
Temporal "When did X happen?" Search with broad date range, look for timestamps
Exploratory "What do we know about X?" Broad search across all sources, synthesize

Step 2: Extract Search Components

From the query, extract:

  • Keywords: Core terms that must appear in results
  • Entities: People, projects, teams, tools (use memory system if available)
  • Intent signals: Decision words, status words, temporal markers
  • Constraints: Time ranges, source hints, author filters
  • Negations: Things to exclude

Step 3: Generate Sub-Queries Per Source

For each available source, create one or more targeted queries:

Prefer semantic search for:

  • Conceptual questions ("What do we think about...")
  • Questions where exact keywords are unknown
  • Exploratory queries

Prefer keyword search for:

  • Known terms, project names, acronyms
  • Exact phrases the user quoted
  • Filter-heavy queries (from:, in:, after:)

Generate multiple query variants when the topic might be referred to differently:

User: "Kubernetes setup"
Queries: "Kubernetes", "k8s", "cluster", "container orchestration"

Source-Specific Query Translation

~~chat

Semantic search (natural language questions):

query: "What is the status of project aurora?"

Keyword search:

query: "project aurora status update"
query: "aurora in:#engineering after:2025-01-15"
query: "from:<@UserID> aurora"

Filter mapping: | Enterprise filter | ~~chat syntax | |------------------|--------------| | from:sarah | from:sarah or from:<@USERID> | | in:engineering | in:engineering | | after:2025-01-01 | after:2025-01-01 | | before:2025-02-01 | before:2025-02-01 | | type:thread | is:thread | | type:file | has:file |

~~knowledge base (Wiki)

Semantic search — Use for conceptual queries:

descriptive_query: "API migration timeline and decision rationale"

Keyword search — Use for exact terms:

query: "API migration"
query: "\"API migration timeline\""  (exact phrase)

~~project tracker

Task search:

text: "API migration"
workspace: [workspace_id]
completed: false  (for status queries)
assignee_any: "me"  (for "my tasks" queries)

Filter mapping: | Enterprise filter | ~~project tracker parameter | |------------------|----------------| | from:sarah | assignee_any or created_by_any | | after:2025-01-01 | modified_on_after: "2025-01-01" | | type:milestone | resource_subtype: "milestone" |

Result Ranking

Relevance Scoring

Score each result on these factors (weighted by query type):

Factor Weight (Decision) Weight (Status) Weight (Document) Weight (Factual)
Keyword match 0.3 0.2 0.4 0.3
Freshness 0.3 0.4 0.2 0.1
Authority 0.2 0.1 0.3 0.4
Completeness 0.2 0.3 0.1 0.2

Authority Hierarchy

Depends on query type:

For factual/policy questions:

Wiki/Official docs > Shared documents > Email announcements > Chat messages

For "what happened" / decision questions:

Meeting notes > Thread conclusions > Email confirmations > Chat messages

For status questions:

Task tracker > Recent chat > Status docs > Email updates

Handling Ambiguity

When a query is ambiguous, prefer asking one focused clarifying question over guessing:

Ambiguous: "search for the migration"
→ "I found references to a few migrations. Are you looking for:
   1. The database migration (Project Phoenix)
   2. The cloud migration (AWS → GCP)
   3. The email migration (Exchange → O365)"

Only ask for clarification when:

  • There are genuinely distinct interpretations that would produce very different results
  • The ambiguity would significantly affect which sources to search

Do NOT ask for clarification when:

  • The query is clear enough to produce useful results
  • Minor ambiguity can be resolved by returning results from multiple interpretations

Fallback Strategies

When a source is unavailable or returns no results:

  1. Source unavailable: Skip it, search remaining sources, note the gap
  2. No results from a source: Try broader query terms, remove date filters, try alternate keywords
  3. All sources return nothing: Suggest query modifications to the user
  4. Rate limited: Note the limitation, return results from other sources, suggest retrying later

Query Broadening

If initial queries return too few results:

Original: "PostgreSQL migration Q2 timeline decision"
Broader:  "PostgreSQL migration"
Broader:  "database migration"
Broadest: "migration"

Remove constraints in this order:

  1. Date filters (search all time)
  2. Source/location filters
  3. Less important keywords
  4. Keep only core entity/topic terms

Parallel Execution

Always execute searches across sources in parallel, never sequentially. The total search time should be roughly equal to the slowest single source, not the sum of all sources.

[User query]
     ↓ decompose
[~~chat query] [~~email query] [~~cloud storage query] [Wiki query] [~~project tracker query]
     ↓            ↓            ↓              ↓            ↓
  (parallel execution)
     ↓
[Merge + Rank + Deduplicate]
     ↓
[Synthesized answer]