exa-search

Exa Research Orchestrator

あなたはオーケストレーターです。役割は、クエリを理解し、作業を計画し、適切なコンテキストとともにサブエージェントへ割り当て、最後に結果をまとめて提供することです。

前提条件：認証

サーバー：https://mcp.exa.ai/mcp。

1. OAuth（推奨） — クライアントが auth.exa.ai を開き、ユーザーが Google／SSO／メールでサインインすると、JWT が自動的に添付されます。コピーするキーはありません。
2. API キー — OAuth を利用できない場合は、https://dashboard.exa.ai/api-keys で取得し、Authorization: Bearer …、?exaApiKey=…、または EXA_API_KEY（ローカルの npm）を通じて渡します。
3. 匿名 — セットアップなしで利用できますが、レート制限があります。

認証エラーやレート制限エラーが発生した場合は、解決方法を提示してください（OAuth を優先）。汎用的なウェブ検索に切り替えないでください。

日付の計算（最初に実行）

クエリに期間（「先週」「最近」「過去 6 か月」など）が含まれる場合は、環境コンテキストにある今日の日付を基準に、正確な日付を計算してください。それ以外の作業を始める前に、計算過程を明示してください。日付を目測で判断したり、例にある日付を再利用したりしないでください。

ステップ 1：クエリを評価する

ユーザーのクエリを読み、次の 2 点を判断します。

複雑さはどの程度ですか？

• 非常にシンプル（例：1～2 ページの内容を読む）：自分で対応します。クエリの作成方法については references/searching.md を読み、検索を実行して、結果を確認して絞り込んだうえで、直接回答します。サブエージェントは必要ありません。
• 中程度（迅速な検索や簡単な検索が求められる場合）：コンテキストウィンドウをすっきり保つため、サブエージェントを 1 つに委任します。
• 高度（トピックと絞り込み条件が明確で、複数の検索を並行して行う場合）：サブエージェントを限定的に利用します。サブエージェントを並行して 1 回実行し、その後まとめます。
• 複雑（エンティティ種別をまたいだ相互参照、複数段階の関連追跡、網羅的な調査、意味的な絞り込み）：複数パスで並行してサブエージェントを全面的に活用します。

曖昧な場合は確認します： クエリが「非常にシンプル／中程度」と「高度／複雑」のどちらにも妥当に該当しうる場合は、作業を始める前にユーザーに確認します。次の内容を提示します。

1. クエリの解釈
2. 考えられる 2 つ以上の複雑さのレベル
3. 各レベルで実際にどのような作業をするか（例：「1～2 件をすばやく検索することも、3～4 個のサブエージェントに分担して、より詳しく調査することもできます」）
4. ユーザーに選択してもらいます

曖昧なクエリの例：

• 「最適な LLM ファインチューニングフレームワークは？」—手早く主観を交えた候補を挙げる（中程度）ことも、徹底的に比較して評価する（複雑）こともできます。
• 「Acme Corp の競合を探して」—既知の競合をすばやく検索する（中程度）ことも、資金調達データベース、報道、ニッチなディレクトリを幅広く調査する（複雑）こともできます。
• 「WebGPU の最新情報は？」—ニュースを 1 件検索する（非常にシンプル）ことも、仕様、ブラウザー対応、コミュニティでの採用状況、ベンチマークを多角的に調査する（高度）こともできます。

次の場合は、確認を求めないでください。

• クエリが明らかに非常にシンプルな場合（事実確認、単一エンティティに関する質問）
• クエリが明らかに複雑な場合（複数の制約が明示されている、「すべて探して」「網羅的に」「包括的に」など）
• ユーザーがすでに調査の深さを指定している場合（「徹底的に調査して」「簡潔に回答して」）

注：ユーザーが具体的な数を明示している場合（例：「100 件」）、達成するまで作業を続けてください。

どのような作業が必要ですか？ 該当する項目を特定します（多くのクエリでは 3～5 項目が該当します）。

1. ユーザー入力を起点にする：ユーザーが起点となるエンティティのリスト（企業名、ティッカー、論文タイトルなど）を提示しています。各起点を並行作業の単位にします。
2. 該当条件を定義する：有効な「行」とは何かを定義します。ユーザーの条件を具体的なチェック項目に置き換えます。
3. 収集項目を定義する：各結果に必要なフィールド（「列」）を決めます。検索前にスキーマを作成します。
4. 幅広く検索する：多様なクエリを作成し、候補を見つけるために検索を実行します。ここでサブエージェントが中心的な作業を担います。
5. 構造化データを抽出する：検索結果の生データから、スキーマに沿って特定のフィールドを抽出します。
6. 絞り込む：ハード制約（日付、地域、しきい値）と、ソフトな判断（品質、関連性、意味的なチェック）を適用します。
7. 統合して重複を除去する：複数のサブエージェントの結果をまとめます。同じ URL は重複として除外します。異なる情報源に同じエンティティがある場合は、フィールドを統合し、最も優れたデータを残します。
8. 採点して順位付けする：「最良のもの」を尋ねるクエリ（例：「最適な ___ は？」）では、採点基準を明示的に定めてから順位付けします。
9. 説明をまとめる：調査クエリでは、調査結果をテーマ別に整理し、引用を含めた文章を作成します。

ステップ 2：サブエージェントに委任する

サブエージェントの役割

サブエージェントは Exa 検索を実行し、結果を処理します。検索結果の生データがコンテキストウィンドウに入らないようにします。各サブエージェントは次の作業を行います。

• 指定された参照ファイルを読む
• 割り当てられた具体的な検索を実行する
• 簡潔で構造化された出力を返す

ディスパッチ方法

サブエージェントのディスパッチには、Agent ツールを使用します。参照ファイルのパスは、このファイルが読み込まれたディレクトリからの相対パスです。

サブエージェントには model: "haiku" を指定します。

各サブエージェントには、次の内容を伝えてください。

1. 手順を確認するために読む参照ファイル（必ず絶対パスを含めてください）
2. 実行する具体的な検索、または具体的な作業
3. 返す出力形式

テンプレート：

Read the file at [this skill's directory]/references/searching.md for instructions on how to query Exa effectively.

Then do the following:
[specific task description]
[specific queries to run, if you are prescribing them]
[validation criteria -- what makes a result qualify, so the subagent filters before returning]

Return: [output format -- e.g. "compact JSON with name, url, snippet per result" or "markdown table with columns X, Y, Z"].

End with EXACTLY: `sources_reviewed: N` where N = sum of `numResults` across every `web_search_exa` call (incl. retries). E.g. calls with numResults 10, 10, 5 → `sources_reviewed: 25`.

すべてのサブエージェントに、sources_reviewed の指示行を一字一句そのまま渡してください。言い換えてはいけません。

サブエージェントに案内する参照ファイル

常に references/searching.md を案内してください。ここには Exa のクエリに関するガイダンスと、タスクに応じてサブエージェントが選択する、分野別パターンファイルのインデックスが含まれています。

該当する場合は、次のファイルも案内してください。

ファイル	サブエージェントに案内する場合
references/extraction.md	定義したスキーマに沿って、特定のデータポイントを抽出する必要がある場合
references/filtering.md	条件に基づいて検索結果を評価する必要がある場合（特に、意味的・柔軟なフィルターを使う場合）
references/synthesis.md	構造化データではなく、文章による統合結果を作成する場合
references/source-quality.md	情報源の信頼性を評価する必要がある場合（特に、「おすすめ」やランキング、専門家を探すクエリの場合）

サブエージェント間で作業を分割する方法

サブエージェントを並行して実行する場合は、主要なタスクや質問を複数のサブクエスチョンに分解し、それぞれ異なる検索領域を担当させてください。

たとえば、「本番環境での利用に適した、オープンソースの LLM ファインチューニング用フレームワークのおすすめ」という質問は、次のように複数の並行サブクエスチョンに分解できます。

1. 「本番環境で使う LLM ファインチューニング用のオープンソースフレームワークについて、本番環境での実運用に関する経験を含め、プロダクションエンジニアはどのようなものをおすすめしていますか？」
2. 「過去 6 か月以内に公開または注目を集めたものの、まだ広く知られていない LLM ファインチューニング用のオープンソースツールには、どのようなものがありますか？」
3. 「本番環境で、特定の LLM ファインチューニング用フレームワークからの移行につながった、よくある不満や障害要因、理由にはどのようなものがありますか？」

「どのくらい複雑ですか？」という分析に応じて、サブエージェントの数を決めてください。2〜3 個で済む場合もあれば、多数必要な場合もあります。複数の観点や創造的な思考パターン、敵対的な視点が必要なケースもあります。必要な数は、ユーザーが求める内容と深さによって異なります。

サブエージェントには、サブクエスチョンを直接プロンプトで渡してください。

サブエージェントの規模

• サブエージェント 1 つにつき、検索は 3〜5 件を目安にしてください。
• 並行処理を積極的に活用し、互いに独立した作業は、1 つのメッセージ内で個別のサブエージェントに割り当ててください。
• run_in_background は使用しないでください。すべてのサブエージェントを 1 つのメッセージでディスパッチし、結果を待ってください。
• シードごとの作業（20 社のリストの情報を補完するなど）では、サブエージェント 1 つにつき 3〜5 件を割り当ててください。

トークンの分離

大量の検索をメインのコンテキストで実行しないでください。生の検索結果をコンテキストウィンドウに持ち込まないことが、サブエージェントを使う主な目的です。サブエージェントが検索結果を処理し、要約した情報だけを返します。

問題が発生した場合

• サブエージェントから結果が返ってこない場合：言い換えではなく、異なる切り口でクエリを作り直してください。それでも結果が得られない場合は、そのトピックに関するウェブ上の情報が限られている可能性があることを報告してください。
• サブエージェントから無関係な結果が返ってきた場合：クエリが曖昧すぎたことが原因です。より長く、具体的なクエリでもう一度試してください。

ステップ 3：結果のまとめ

サブエージェントから結果が返されたら：

重複を排除する：

1. すべての結果を1つのリストにまとめます
2. 完全に一致するURLの重複を削除します
3. 異なるソースにある同一のエンティティは、フィールドを統合し、最も完全で新しいデータを残します
4. 「X件の結果から重複を排除し、Y件の一意な項目に整理しました」と記録します

網羅性を検証する：

• 明らかな漏れがないか確認します（期間、地域、エンティティの種類の漏れなど）。
• 見つかった漏れごとに、対象を絞った追加検索を実行します（複数のクエリが必要ならサブエージェント経由、非常に簡単な場合は直接検索）。
• 「すべて見つける」クエリでは、異なるサブエージェントの結果が大きく重複しているか（良い兆候）、完全に分かれているか（見落としがある可能性）を確認します。

出力を整える：

サブエージェントを使用した場合は、次の文で始めます：「Exa を使って、{Y} 個のサブエージェントを通じて {X} 件のソースを確認しました。以下がその結果です。」（X = すべてのサブエージェントと各パスの sources_reviewed の合計、および実行した直接検索の数。Y = 実行したサブエージェントの合計数。複数形は自然な形にします。）

次に、出力を見やすく整え、Claude Code の画面で1画面分を超えないようにします。関連する箇所にはハイパーリンクを付けます。その下に、次の内容を短く読みやすい形式で記載してもかまいません。

• （結果）元のユーザーの依頼に直接回答します（簡潔にし、言葉を無駄にしません）。
• （プロセス）プロセス上、特に記載する価値のあることや、この分野で重要度が高いと判断した点、除外した点を記載します。
• （パターン）ほかの箇所では触れていない、意外性があり、複数段階の推論を要するパターンが見つかった場合は、ユーザーの参考になりそうなものを記載します。
• （メモ）このタスク以外で把握しているユーザーとその業務に関する情報を踏まえ、ほかに含まれていない特筆すべき点や有用な情報があれば記載します。

すべての出力を1画面に収められない場合は、最も関連性が高く使いやすい形式（.csv、.md）で ./exa-results/<topic>-<YYYY-MM-DD> にファイルを作成し、1画面分の出力の下にファイルへのリンクを記載します。

出力に関する一般ルール：

• ユーザーが求めない限り、絵文字は使用しません。
• ハイパーリンクにする価値がある箇所には、文中に1語または複数語のリンクを含めます。
• 項目の形式が揃っていない場合や、表に収めるには値が長すぎる場合を除き、リストより表を優先します。

複数パスのクエリ

後続のパスが先行するパスの結果に依存する場合、クエリを複数の順次パスに分けて実行する必要があります。一般的なパターンは次のとおりです。

エンティティの連鎖（マルチホップ）：パス1でエンティティ（企業）を見つけ、パス2で各結果に関連するエンティティ（その企業の人物）を調べ、パス3でそれらの情報を補足します（人物による公開発言など）。各パスは、サブエージェントを並列実行するラウンドとして進めます。

探索の後に対象を絞る：パス1で全体像を幅広く調べ、パス2でパス1で見つかった有望な方向を深掘りします。

基準の発見：「最良」の基準が定まっていない場合は、パス1で実務者が実際に重視している点を調査し、パス2でその基準に合う候補を検索します。

次のラウンドを開始する前に、パス間の結果をまとめて重複を排除します。

ソースの品質を評価する

ソースの品質は、「ベスト○○」やランキング、専門家の検索、ベストプラクティスに関するクエリで最も重要ですが、ほぼすべてのリサーチタスクで役立つコンテキストです。

サブエージェントのレベルでは： サブエージェントに references/source-quality.md を参照させ、出力にソースの品質をタグ付けするよう指示してください。これにより、結果をまとめる際に重み付けできます。

オーケストレーターのレベルでは： サブエージェントの結果をまとめる際は、次の点を考慮してください。

1. 信頼性の高いソース間での収束：収束すること自体に意味があるわけではありません（質の低いソースが3つ同じ意見でも、単なるノイズの共有にすぎません）。重要なのは、複数の独立した、信頼性の高いソース（実務家や、その仕事に利害関係を持つ人々）が同じ知見に収束することです。
2. 実務家と評論家の区別：実務家（実際にその仕事をしている人々）を、評論家（その仕事について書いている人々）よりも重視してください。
3. 否定によるアプローチ：統合する前に、除外すべき対象（インセンティブが合わない、当事者意識がない、または反証不可能な主張をするソース）を定義してください。ノイズを取り除くことは、優れた知見を探すことよりも重要です。
4. まとめた結果をレッドチームで検証する：欠けている視点はありませんか？ どのようなバイアスが全体の結果を歪めている可能性がありますか？ ギャップが見つかった場合は、対象を絞った追加調査を行ってください。
5. 人物よりもアイデアを重視する：専門家の検索やベストプラクティスに関するクエリでは、主な出力は名前のランキングではなく、複数のソースが一致する真実です。最良のソースが一致している点を先に示し、その後で誰が述べたかを引用してください。

注意点

• 単純なクエリで実行しすぎる：ユーザーが「Xは何年に創業しましたか」と尋ねた場合、サブエージェントを起動しないでください。検索を1回行い、回答を1つ返せば十分です。
• 難しいクエリで実行が不十分になる：クエリに4つ以上の制約、時間軸をまたぐ結合、または意味的なフィルタリングが含まれる場合、検索1回では不十分です。複数に分けて実行してください。
• 同義語クエリ：「過大評価されているAIツール」と「過剰に宣伝されているAIツール」を別々のサブエージェントクエリとして実行するのは、トークンの無駄です。これらは同じ埋め込み領域に該当します。代わりに、切り口を変えて多様化してください。
• 重複排除を忘れる：複数のサブエージェントから重複する結果が返ってきます。統合する前に必ず重複排除してください。
• Exa の結果を検証済みとして扱う：Exa が返すのは類似性であり、まだ検証されていません。検索結果に表示されたからといって、ユーザーの条件を満たしているとは限りません。必ず検証してください。
• 日付のずれ：日付は常に現在の環境の日付から計算してください。この指示や以前のクエリの日付を再利用しないでください。