search-strategy について
自然言語の質問をソース別の並列検索に分解し、結果を順位付けして重複を除いた回答にまとめる検索戦略スキルです。接続済みの企業データソースを対象に、チャット、Wiki、プロジェクトトラッカー向けの検索方法を示します。
主な機能
- 01質問の種類を判定して検索方針を選択
- 02キーワード、エンティティ、意図、条件を抽出
- 03各ソース向けにクエリを変換
- 04検索結果の順位付けと重複排除
- 05曖昧さへの対応とフォールバックの指針
- 06各ソースの検索を並列実行
活用シーン
- 01チャットやメールから決定事項を探す
- 02プロジェクトトラッカーや最近の更新で状況を確認
- 03Wikiや共有ドキュメントで仕様を探す
- 04複数の接続済みソースを横断して調査
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/search-strategyを入力して読み込まれたか確認します。
詳細
検索戦略
見慣れないプレースホルダーがある場合や、どのツールが接続されているか確認する必要がある場合は、CONNECTORS.md を参照してください。
エンタープライズ検索の中核となるインテリジェンスです。自然言語による1つの質問を、ソースごとの並列検索に変換し、順位付けと重複排除を行った結果を生成します。
目標
これを：
"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つの回答を作成します。
クエリの分解
ステップ1：クエリの種類を特定する
検索戦略を決めるために、ユーザーの質問を分類します。
| クエリの種類 | 例 | 戦略 |
|---|---|---|
| 意思決定 | 「Xについて、何を決定しましたか？」 | 会話（~~chat、メール）を優先し、結論を示す表現を探します |
| ステータス | 「Project 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\"" (exact phrase)
~~project tracker
タスク検索：
text: "API migration"
workspace: [workspace_id]
completed: false (for status queries)
assignee_any: "me" (for "my tasks" queries)
フィルターの対応付け：
| エンタープライズフィルター | ~~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/Official docs > Shared documents > Email announcements > Chat messages
「何が起きたか」や意思決定に関する質問の場合：
Meeting notes > Thread conclusions > Email confirmations > Chat messages
ステータスに関する質問の場合：
Task tracker > Recent chat > Status docs > Email updates
曖昧さへの対処
クエリが曖昧な場合は、推測するよりも、焦点を絞った確認の質問を1つすることを優先します。
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)"
確認を求めるのは、次の場合に限ります。
- 結果が大きく異なる、明確に別々の解釈が実際に存在する
- 曖昧さによって、検索するソースの選択に大きな影響がある
次の場合は確認を求めないでください。
- 有用な結果を返せる程度にクエリが明確である
- 複数の解釈に基づく結果を返せば、軽微な曖昧さを解消できる
フォールバック戦略
ソースを利用できない場合や、結果が返されない場合は、次のようにします。
- ソースを利用できない場合：そのソースをスキップし、残りのソースを検索して、不足があることを伝えます
- ソースから結果が返されない場合：クエリの用語を広げ、日付フィルターを外し、別のキーワードを試します
- すべてのソースから何も返されない場合：ユーザーにクエリの変更を提案します
- レート制限がある場合：制限について伝え、他のソースからの結果を返し、後でもう一度試すよう提案します
クエリの拡張
最初のクエリで返される結果が少なすぎる場合：
Original: "PostgreSQL migration Q2 timeline decision"
Broader: "PostgreSQL migration"
Broader: "database migration"
Broadest: "migration"
次の順序で制約を取り除きます。
- 日付フィルター（全期間を検索）
- ソース／場所のフィルター
- 重要度の低いキーワード
- 中心となるエンティティ／トピックの用語だけを残す
並列実行
ソース間の検索は常に並列で実行し、順次実行しないでください。検索全体の所要時間は、すべてのソースの合計ではなく、最も遅い単一のソースとほぼ同じになるようにします。
[User query]
↓ decompose
[~~chat query] [~~email query] [~~cloud storage query] [Wiki query] [~~project tracker query]
↓ ↓ ↓ ↓ ↓
(parallel execution)
↓
[Merge + Rank + Deduplicate]
↓
[Synthesized answer]