mcpField
R
research

research

github.com/warpdotdevエージェントワークフロー63621.8k 回インストール1 週間前に更新
リポジトリ

research について

リポジトリ調査をサブエージェントに委任し、根拠付きの要約を受け取るスキルです。多数のファイルを読む必要があるコーディングエージェント向けです。

主な機能

  1. 01広範なコード調査の委任
  2. 02根拠付きの要約を取得
  3. 03ログ、差分、API利用状況の調査
  4. 04調査ノイズによるコンテキスト消費の抑制

活用シーン

  1. 01テスト失敗の原因を追跡
  2. 02リポジトリ内のシンボル利用箇所を把握
  3. 03大規模なプルリクエストを要約

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/warpdotdev/common-skills --skill research

インストール後、Claude Code で/researchを入力して読み込まれたか確認します。

詳細

リサーチ

質問に答えるために、答えを見つける作業をサブエージェントに委任する際に、このスキルを使用します。そうすることで、その作業の副産物であるファイルの内容、ログのノイズ、行き止まりの読み込みが、あなた自身のコンテキストに入り込むことはありません。裏付けとなる証拠とともに要点を絞った回答が返ってくるため、本来のタスクに集中できます。

重要な理由

コンテキストウィンドウは、最も貴重で限りあるリソースです。重要なファイルが3つだとわかるまでに20個のファイルを読むと、関係のない17個分のノイズでコンテキストが恒久的に汚染され、その後の判断の質が低下します。サブエージェントにノイズを吸収してもらい、必要な情報だけを受け取るのです。アーカイブ全体を机に広げるのではなく、同僚に資料を調べてもらって報告してもらうようなものです。

使用する場面

答えそのものより、答えを導き出す作業のコストがはるかに大きい場合は、リサーチの委任を検討してください。たとえば、次のような場合です。

  • 関連する数個のファイルを見つけるために、多数のファイルを読む必要がある。
  • 長いテスト出力、CI ログ、スタックトレースを調べて、失敗の原因を特定する必要がある。
  • リポジトリ全体で、あるパターン、API、シンボルがどのように使われているかを調査する必要がある。
  • 大きな差分や PR を読んで要約する必要がある。
  • 質問に、個別に調査できる複数の要素が含まれている。

適している例:

  • 「このテストが失敗する根本原因は何ですか?」(サブエージェントがログとコードを調査し、あなたには原因を報告します)
  • 「コードベース全体で SessionManager はどのように使われていますか?」(サブエージェントが検索して読み、呼び出し箇所をまとめて報告します)
  • 「この4,000行の PR の変更内容と理由を要約してください。」(サブエージェントが差分を読み、概要を報告します)

委任しない例:

  • 読むべきファイルが2〜3個で、すでに把握している場合。自分で直接読んでください。委任すると、コンテキストを節約できないまま遅延が増えます。
  • 単一の grep や1行で済む検索。自分で実行してください。
  • 次の作業に生の素材が必要な場合。 読み込むファイルをこれから編集するのであれば、委任は逆効果です。変更を加えるために、結局は自分で読み直す必要があります。リサーチの委任が有効なのは、出力が結論となる場合であり、直接作業するための素材となる場合ではありません。

サブエージェントを使うには、遅延とトークンのコストがかかります。そのため、ノイズを避けるメリットがそのコストを上回るかどうか、常に検討してください。

実行方法

検索用モデルを使ってローカルで起動する

リサーチ用サブエージェントは、親エージェントがファクトリーエージェントやクラウドエージェントである場合も含め、必ずローカルエージェントとして起動してください。リモートで起動してはいけません。

自分自身のモデルではなく、検索タスクに適したモデルを選んでください。リサーチ用サブエージェントは分析ではなく、検索して要点をまとめる役割です。簡単な検索には gpt-6-luna-medium を、より複雑なリクエスト(たとえば、呼び出し箇所をたどってデータフローを追う場合)には gpt-6-luna-xhigh を使用してください。

単独で起動するか、並列で起動するか

基本は単一のサブエージェントです。互いに独立していて、途中で見つかった情報を共有する必要がない要素に質問を分けられる場合に限り、複数のサブエージェントを並列で起動してください。たとえば、「認証、請求、レート制限の仕組みをそれぞれ調べる」は、独立した3つの調査を同時に進められます。各エージェントが同時に調査できるため、独立性が高い場合は並列実行が有効です。ただし、一貫した1つの質問を無理に分割しないでください。

サブエージェントに明確な指示を与える

サブエージェントはあなたの意図を共有していないため、指示を明確に伝えてください。適切な調査依頼には、次の内容を含めます。

  • 答えるべき質問の正確な内容。
  • 調査対象の場所(リポジトリのパス、ブランチ、把握している場合は関連するファイルやシンボル)。
  • 読み取り専用であること。明示的に変更を求められていない限り、調査と報告のみを行い、ファイルを変更しないこと。
  • どのような形式の出力を求めるか(以下を参照)。
求めるのはシグナルであり、逐語録ではありません

サブエージェントには、生のダンプではなく、** distilled された回答とその根拠** を返すように指示してください。具体的には:

  1. 質問に対する直接的な回答。
  2. 重要な根拠: 正確なファイルパスとシンボル (例: src/session.rs:142、fn reconnect) を挙げてもらい、重要な箇所へすぐに飛べるようにします。
  3. 意外な点や、遭遇した注意事項・不明点。

要は、ノイズはサブエージェント側にとどめておくことです。返ってきたレポートが膨らみすぎている場合は、同じ サブエージェントに焦点を絞ったフォローアップを送り、回答を引き締めるよう依頼してください。コンテキストを保持しているため、低コストで洗練できます。

回答を得た後

蒸留された結果に基づいて作業します。後で編集のために元のファイルが必要だと判明した場合は、その時点で直接読みます。どのファイルが重要か正確に把握できているので、20 個ではなく 3 個のファイルを読むだけで済みます。

コメント