systematic-literature-review

システマティック文献レビューのスキル

概要

このスキルでは、研究テーマに関する複数の学術論文を対象に、構造化された**システマティック文献レビュー（SLR）**を作成します。トピックのクエリを受け取ると、arXivを検索し、各論文から構造化されたメタデータ（研究課題、方法論、主な知見、限界）を並列に抽出して、論文全体のテーマを統合し、一貫した引用形式で最終レポートを出力します。

**academic-paper-reviewとは異なります。**そちらのスキルは、単一の論文を詳細に査読します。このスキルは、多数の論文を幅広く統合します。ユーザーが論文のURLを1件だけ提示して「この論文をレビューして」と依頼した場合は、代わりにacademic-paper-reviewを使用してください。

このスキルを使用する場合

ユーザーが次のいずれかを希望するときに、このスキルを使用してください。

• あるテーマに関する文献調査（「Transformerのアテンションの派生手法を調査して」「拡散モデルに関する文献をレビューして」など）
• 複数の論文を横断した統合（「最近の論文はXについて何を述べているか」「Yに関する論文の手法を比較して」など）
• 引用形式を統一したシステマティックレビュー（「ZについてAPA形式でSLRを作成して」など）
• あるテーマに関する注釈付き参考文献リスト
• 一定期間における分野の研究動向の概要

次の場合は、このスキルを使用しないでください。

• ユーザーが論文を1件だけ提示し、そのレビューを依頼している場合（academic-paper-reviewを使用してください）
• 複数の情報源を統合する必要のない事実に関する質問の場合（直接回答してください）
• 学術的な厳密さを必要としない一般的なウェブ調査を希望している場合（通常のウェブ検索を使用してください）

ワークフロー

ワークフローは5つのフェーズで構成されます。順番に進めてください。

フェーズ1：計画

情報を取得する前に、次の内容をユーザーに確認してください。不明な点があれば、不足している内容をまとめた確認質問を1つしてください。質問を1つずつ尋ねてはいけません。

• トピック：平易な英語で示された研究分野（例：「transformer attention variants」）。
• 範囲：論文の件数（デフォルトは20件、上限は50件）、任意の対象期間（例：「過去2年間」）、任意のarXivカテゴリ（例：cs.CL、cs.CV）。
• 引用形式：APA、IEEE、BibTeX（ユーザーが指定せず、特定の投稿先向けの執筆とも思われない場合は、デフォルトでAPAを使用します）。
• 出力先：最終レポートの保存先（デフォルトは/mnt/user-data/outputs/）。

ユーザーが「論文を50件以上」と指定した場合は、丁寧に上限を50件とし、それ以上では統合の品質が急速に低下すると説明してください。より大規模な調査を行う場合は、サブトピックごとに分割するよう案内してください。

フェーズ 2：arXiv を検索する

同梱されている検索スクリプトを呼び出してください。arXiv をほかの方法でスクレイピングしたり、独自の HTTP クライアントを作成したりしないでください。このスクリプトは、URL エンコード、Atom XML の解析、ID の正規化を適切に処理します。

python /mnt/skills/public/systematic-literature-review/scripts/arxiv_search.py \
  "<topic>" \
  --max-results <N> \
  [--category <cat>] \
  [--sort-by relevance] \
  [--start-date YYYY-MM-DD] \
  [--end-date YYYY-MM-DD]

重要 — 検索前に中心となるキーワードを 2～3 個抽出してください。 ユーザーのトピックの説明全文をクエリに渡さないでください。スクリプトを呼び出す前に、トピックを最も重要な用語 2～3 個に絞り込んでください。「コンピュータビジョンにおける」「NLP 向け」「バリエーション」「最近の」などの修飾語は省いてください。これらはクエリ文字列ではなく、--category または --start-date に指定します。

クエリの表現 — 短くしてください。 スクリプトは複数語のクエリを二重引用符で囲み、arXiv でフレーズ検索します。つまり、次のようになります。

• "diffusion models" → 完全一致フレーズを検索します → 適切で、関連性の高い論文が返されます。
• "diffusion models in computer vision" → この 5 語の完全一致フレーズを検索します → 具体的すぎて、該当する文字列を含む論文がほとんどないため、結果が 0 件になる可能性があります。

クエリには中心となるキーワードを 2～3 個使い、分野を絞り込むには分野名をクエリに詰め込むのではなく、--category を使用してください。例：

ユーザーの依頼	適切なクエリ	不適切なクエリ
"コンピュータビジョンにおける拡散モデル"	"diffusion models" --category cs.CV	"diffusion models in computer vision"
"トランスフォーマーのアテンションのバリエーション"	"transformer attention"	"transformer attention variants in NLP"
"分子向けのグラフニューラルネットワーク"	"graph neural networks" --category cs.LG	"graph neural networks for molecular property prediction"

スクリプトは JSON 配列を標準出力に出力します。各論文には、id、title、authors、abstract、published、updated、categories、pdf_url、abs_url が含まれます。

ソート方法：

• 必ず relevance でソートしてください — arXiv の BM25 形式のスコアリングにより、検索結果がユーザーのトピックに実際に関連したものになります。submittedDate でソートすると、トピックとの関連性にかかわらず、そのカテゴリで最近投稿された論文が返されるため、トピックから外れた結果が大半を占めます。
• ユーザーが「最近の」論文を求めたり、期間を指定したりした場合は、トピックとの関連性を維持しながら期間を絞り込むため、--sort-by relevance と --start-date を組み合わせてください。たとえば、「最近の拡散モデルの論文」なら、--sort-by submittedDate ではなく、--sort-by relevance --start-date 2024-01-01 を使います。
• submittedDate によるソートが適切なのは、ユーザーが明示的に時系列順を求めている場合（たとえば、「公開された順に論文を見せてください」）に限られます。これはまれです。
• lastUpdatedDate はほとんど役に立たないため、ユーザーから求められない限り無視してください。

検索は正確に 1 回だけ実行してください。 結果が不完全に思えても、クエリを変更して再試行しないでください。arXiv の関連度ランキングはそのまま受け入れてください。異なるクエリ表現で再試行すると、ツール呼び出しを浪費し、再帰の上限に達するリスクがあります。結果が本当に空（論文 0 件）の場合は、その旨をユーザーに伝え、トピックを広げるかカテゴリフィルターを外すよう提案してください。

スクリプトが指定された件数より少ない論文を返した場合、それがそのクエリに対する arXiv の実際の検索結果数です。リストを水増しせず、実際の件数をユーザーに伝えて作業を続けてください。

スクリプトが失敗した場合（ネットワークエラー、arXiv からの HTTP 200 以外の応答）は、エラーの内容をユーザーに伝えて終了してください。論文のメタデータを捏造しないでください。

検索結果をファイルに保存しないでください — JSON はフェーズ 3 で使用するため、コンテキスト内に保持してください。ワークフロー全体で保存するファイルは、フェーズ 5 の最終レポートのみです。

フェーズ 3：メタデータを並列で抽出する

task ツールを使ってサブエージェントに抽出を必ず委任してください。自分でメタデータを抽出してはいけません。 これは必須です。具体的には、次のことを絶対にしないでください。

• ❌ 論文を処理するために、python -c "papers = [...]" や Python／bash スクリプトを書かない
• ❌ 要約を1件ずつ読んで、自分のコンテキスト内でメタデータを直接抽出しない
• ❌ このフェーズで task 以外のツールを使わない

代わりに、必ず task ツールを呼び出してサブエージェントを起動してください。その理由は、10～50件の論文を自分のコンテキスト内で抽出すると、トークンを使いすぎてフェーズ 4 の統合品質が低下するためです。各サブエージェントは、割り当てられた論文だけを含む独立したコンテキストで実行され、より整った抽出結果を生成します。

論文を約 5 件ずつのバッチに分け、各バッチについて subagent_type: "general-purpose" を指定して task ツールを呼び出してください。各サブエージェントには論文の要約をテキストとして渡し、構造化された JSON を返させます。

同時実行数の上限：1 ターンにつきサブエージェントは最大 3 つです。 DeerFlow ランタイムは MAX_CONCURRENT_SUBAGENTS = 3 を適用し、同じターンにそれを超えて起動しようとしたものは通知なしに破棄します。そのことは LLM に通知されないため、以下のラウンド戦略を必ず守ってください。

ラウンド戦略 — 自分で分割数を計算せず、次の判断表を使用してください。

論文数	約 5 件ずつのバッチ	ラウンド数	1 ラウンドあたりのサブエージェント数
1–5	1 バッチ	1 ラウンド	サブエージェント 1 つ
6–10	2 バッチ	1 ラウンド	サブエージェント 2 つ
11–15	3 バッチ	1 ラウンド	サブエージェント 3 つ
16–20	4 バッチ	2 ラウンド	3 + 1
21–25	5 バッチ	2 ラウンド	3 + 2
26–30	6 バッチ	2 ラウンド	3 + 3
31–35	7 バッチ	3 ラウンド	3 + 3 + 1
36–40	8 バッチ	3 ラウンド	3 + 3 + 2
41–45	9 バッチ	3 ラウンド	3 + 3 + 3
46–50	10 バッチ	4 ラウンド	3 + 3 + 3 + 1

同じターンに 3 つを超えるサブエージェントを絶対に起動しないでください。 行に「2 ラウンド（3 + 1）」とある場合、最初のターンで 3 つのサブエージェントを並列で起動し、3 つすべての完了を待ってから、2 ターン目に 1 つのサブエージェントを起動することを意味します。メインエージェントレベルでは、ラウンドを必ず順番に実行してください。

論文数が表の行の間に該当する場合（例：論文が 23 件）、次の行のレイアウトに切り上げますが、実際に必要なバッチ数だけを起動してください。判断表は構成を示すものであり、厳密な指示ではありません。

バッチ分けはメインエージェントレベルで行ってください。 フェーズ 2 ですでにすべての論文の要約を取得しているため、各サブエージェントにはテキストのみを渡します。サブエージェントはネットワークやサンドボックスにアクセスする必要はありません。テキストを読んで JSON を返すことだけが役割です。arxiv_search.py を再実行するようサブエージェントに依頼しないでください。トークンを無駄にし、レート制限のリスクも高まります。

各サブエージェントに渡す内容（構造化プロンプト）：

Execute this task: extract structured metadata and key findings from the
following arXiv papers.

Papers:
[Paper 1]
arxiv_id: 1706.03762
title: Attention Is All You Need
authors: Ashish Vaswani, Noam Shazeer, ...
published: 2017-06-12
abstract: <full abstract text>

[Paper 2]
arxiv_id: ...
...

For each paper, return a JSON object with these fields:
- arxiv_id (string)
- title (string)
- authors (list of strings)
- published_date (string, YYYY-MM-DD)
- research_question (1 sentence, what problem the paper tackles)
- methodology (1-2 sentences, how they tackle it)
- key_findings (3-5 bullet points, what they actually found)
- limitations (1-2 sentences, what they acknowledge or what is obviously missing)

Return the result as a JSON array, one object per paper, in the same
order as the input. Do not include any text outside the JSON — no
preamble, no markdown fences, just the array.

サブエージェントの結果の解析：task ツールは、Task Succeeded. Result: [...JSON...] のような固定プレフィックス付きの文字列を返します。JSON の解析を試みる前に、Task Succeeded. Result: のプレフィックス（または Task failed.／Task timed out. のプレフィックス）を削除してください。バッチが失敗した場合や、解析できない JSON が返された場合は、その内容を記録し、影響を受けた論文を記してから、残りのバッチを続行してください。1 つのバッチの失敗によって統合作業全体を失敗させてはいけません。

すべてのラウンドが完了したら、バッチごとの配列を単一の論文メタデータオブジェクトのリストにまとめ、順序を維持してください。

フェーズ 4：統合と書式設定

最終版の SLR レポートを作成します。ここでは、論文横断の統合（テーマ分析）と引用の書式設定を行います。

論文横断の統合：レポートは論文の一覧にとどまってはなりません。最低限、次の点を明らかにしてください。

• テーマ：対象論文全体に見られる、繰り返し取り上げられている研究の方向性、アプローチ、または問題の捉え方を 3～6 個示します。
• 収束点：複数の論文が一致している知見です。
• 相違点：論文間で結論が異なる箇所や、互換性のない方法論を採用している箇所です。
• 研究の空白：文献全体でまだ扱われていないことです（多くの場合、「limitations」フィールドに明記されています）。

論文数が少なすぎる、または論文の内容が多様すぎてテーマ分析ができない場合（例：関連性の薄い異なるサブトピックを扱う論文が 5 件ある場合）は、レポートでその旨を明記してください。存在しないテーマを無理に作り出してはいけません。

引用の書式設定：正確な形式はユーザーの希望によって異なります。ユーザーが指定した形式に合うテンプレートファイルだけを読み込み、3 つすべてを読むことは避けてください。

• templates/apa.md — APA 第 7 版。社会科学と多くの CS ジャーナルの標準です。ユーザーが APA を指定した場合、または形式を指定していない場合に使用します。
• templates/ieee.md — IEEE の番号付き引用形式。IEEE の学会またはジャーナルへの投稿を目指している場合、または IEEE を明示的に指定した場合に使用します。
• templates/bibtex.md — BibTeX エントリー。ユーザーが BibTeX、LaTeX に言及した場合、または機械可読な参考文献を希望する場合に使用します。重要：arXiv 論文は @article ではなく @misc として引用します。この点は BibTeX テンプレートに明記されています。

各テンプレートには、引用のルールとレポート全体の構成（エグゼクティブサマリー、テーマ、論文ごとの注釈、参考文献、方法論セクション）が含まれています。レポート本文はテンプレートの構成に厳密に従い、フェーズ 3 のメタデータを使って内容を埋めてください。

フェーズ 5：保存して提示

レポート全体を /mnt/user-data/outputs/slr-<topic-slug>-<YYYYMMDD>.md に保存します。<topic-slug> は、トピックを小文字にしてハイフンでつないだものです（例：transformer-attention）。その後、そのパスを指定して present_files ツールを呼び出し、ユーザーがダウンロードできるようにします。

チャットメッセージには、ファイルを開かなくてもすぐに内容の価値が伝わるよう、短いプレビューを表示してください。

1. エグゼクティブサマリー — レポート冒頭の 3～5 文の段落を、一字一句そのまま掲載します。
2. テーマの一覧 — フェーズ 4 の統合で特定したテーマを箇条書きにします（各テーマの名前と 1 行の概要のみで、テーマセクション全文は含めません）。
3. 論文数とファイルへの案内 — 例：「論文 20 件の論文ごとの注釈と書式設定済み参考文献を含むレポート全体を slr-transformer-attention-20260409.md に保存しました。」

レポート全体（2,000 語以上）をチャット内に貼り付けないでください。論文ごとの注釈、参考文献、方法論はファイルに含めます。プレビューは、ユーザーがレポートの概要を確認し、開くかどうか判断できるようにするためのものです。

例

例 1：一般的なSLRの依頼

ユーザー：「最近のTransformerのアテンション亜種について、論文20本を対象に、APA形式でシステマティック・リテラチャー・レビューをしてください。」

手順：

1. フェーズ1：トピック（Transformerのアテンション亜種）、範囲（論文20本、期間はデフォルト）、形式（APA）を確認します。不明点がある場合に限り、確認質問を1つだけします（例：「特定の期間をご希望ですか。それとも直近3年をデフォルトにしますか？」）。
2. フェーズ2：arxiv_search.py "transformer attention" --max-results 20 --sort-by relevance --start-date 2023-01-01。
3. フェーズ3：論文20本 → 第1ラウンド＝サブエージェント3つ × 論文5本＝15本を調査、第2ラウンド＝サブエージェント1つ × 論文5本＝5本を調査。結果を統合します。
4. フェーズ4：templates/apa.mdを読み、その構成に沿ってレポートを作成し、テーマと各論文の注釈をフェーズ3のメタデータから記入します。
5. フェーズ5：slr-transformer-attention-20260409.mdに保存し、present_filesを呼び出します。

例 2：曖昧さを含む少数論文の依頼

ユーザー：「拡散モデルに関する論文をいくつか調査してください。」

手順：

1. フェーズ1：「いくつか」は曖昧です。質問を1つします：「論文は何本がよいですか。10本、20本、30本のいずれかをお選びください。また、引用形式のご希望はありますか（デフォルトはAPAです）。」
2. ユーザーが「10本、BibTeX」と回答します。
3. フェーズ2：arxiv_search.py "diffusion models" --max-results 10 --category cs.CV。
4. フェーズ3：論文10本 → 1ラウンドで、サブエージェント2つ × 論文5本。
5. フェーズ4：templates/bibtex.mdを読み、@articleではなく@miscエントリで整形します。
6. フェーズ5：保存して提示します。

例 3：対象範囲外の依頼

ユーザー：「この論文（https://arxiv.org/abs/1706.03762）をレビューしてもらえますか？」

これは文献調査ではなく、単一論文の査読です。このスキルは使用しないでください。代わりにacademic-paper-reviewへ引き継いでください。

注意事項

• 前提条件：subagent_enabledがtrueである必要があります。フェーズ3では、メタデータを並列抽出するためにtaskツールが必要です。このツールは、実行時設定（config.configurable.subagent_enabled）でsubagent_enabledがtrueに設定されている場合にのみ読み込まれます。この設定がないと、利用可能なツールにtaskツールが表示されず、フェーズ3を想定どおりに実行できません。
• 設計上、対象はarXivのみです。このスキルはSemantic Scholar、PubMed、Google Scholarを検索しません。DeerFlowユーザーが調査を希望することの多いCS／ML／物理学／数学のプレプリントの大部分をarXivが網羅しています。複数の情報源を対象とする学術検索は、このスキル内ではなく、専用のMCP サーバーで行うものです。
• 上限は50本です。これはフェーズ3の並列処理戦略（1ラウンドあたりサブエージェント最大3つ、各約5本、最大約3ラウンド）に基づいています。50本を超える調査では統合の品質が低下するため、トピックを分割して行うことを推奨します。
• フェーズ3ではサブエージェントを有効にする必要があります。このスキルの並列抽出ステップではtaskツールが必須で、実行時にsubagent_enabled=trueの場合にのみ利用できます。サブエージェントを利用できない場合は、フェーズ3の並列処理計画を実行すると主張しないでください。代わりに、完全なワークフローにはサブエージェントを有効にする必要があるとユーザーに伝えるか、依頼を絞り込む、または分割して手作業でレビューすることを提案してください。
• サブエージェントの結果はオブジェクトではなく文字列です。JSONペイロードを解析する前に、必ずTask Succeeded. Result: ／Task failed.／Task timed out.のプレフィックスを取り除いてください。
• idフィールドにはarXiv IDのみが入ります（例：1706.03762）。URLでも、バージョン接尾辞付きのIDでもありません。必要な場合は、abs_url／pdf_urlに完全なURLが格納されています。
• 列挙ではなく統合を行います。最終レポートではテーマを特定し、論文間で知見を比較する必要があります。論文を順番に並べるだけのレポートは、失敗例にあたります。テーマを見つけられない場合は、作り上げず、その旨を明示してください。