search-strategy について
search-strategyは、社内の質問を複数の接続先に向けた並列検索へ分解し、結果を順位付けして統合するスキルです。検索意図の分類や接続先ごとのクエリ作成、結果がない場合の対応も扱います。
主な機能
- 01質問を意図別に分類
- 02接続先ごとのクエリを作成
- 03結果の順位付けと重複排除
- 04曖昧さや検索失敗への対応
- 05検索の並列実行
活用シーン
- 01チャットやメールから決定事項を探す
- 02タスク管理ツールでプロジェクト状況を確認
- 03文書やポリシーを見つける
- 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]