paper-search

論文検索スキル

./scripts/search_papers.py を使って、arXiv、DBLP、OpenAlex、OpenReview （NeurIPS／ICLR／ICML）、Semantic Scholar、Crossrefを横断して論文を検索します。速度を最大化するため、デフォルトではすべてのソースを（独立した子プロセスで）並行して検索します。1つのソース内のクエリは引き続き逐次実行されます。結果はソースごとにまとめて返されます。

使用する場面

ユーザーから次のような依頼があった場合に、このスキルを使用します。

• 「2023年から2025年に発表されたXに関する論文を探してください。」
• 「NeurIPS／ICLR／ICMLでXに関する研究を検索してください。」
• 「Xについて、arXivとSemantic Scholarの検索結果を取得してください。」
• 「Xに関する最近の先行研究を見せてください。」

入力（すべて自動推定します。ユーザーに確認や уточ明を求めてはいけません）

ユーザーのメッセージから次の項目を自動的に導き出します。確認を求めず、すぐに検索を実行してください。

• query：ユーザーの質問を、焦点を絞った検索語句に言い換えます。
• start_year（int）：ユーザーが年を指定した場合は、その年をそのまま使います。「過去2年間」のような指定の場合は、今日の日付から計算します。デフォルト：2年前。
• end_year（int）：デフォルト：現在の年。
• max_papers（int）：ソースごとの結果数。デフォルト：10。
• sources：検索するソース。デフォルトでは、すべての6つのAPIソースとモデル知識ソースを、次の標準順（関連性の高い順。ユーザーがスクロールする前に最良の結果を表示するため）で使います。 semantic_scholar open_alex arxiv openreview crossref dblp model_knowledge。 ユーザーが明示的に指定した場合にのみ、ソースを限定してください。

実行方法

推奨：CLIを直接呼び出します。スクリプトは ${CLAUDE_PROJECT_DIR}/skills/paper_search/scripts/search_papers.py にあります。現在の作業ディレクトリにかかわらずコマンドが動作するよう、絶対パスで呼び出してください（cd scripts && ... に依存すると、モデルが別のフォルダーから実行されている場合に失敗します。これはよく起こります）。

以下の例では、簡潔にするため、$SEARCH はその絶対パスを表すものとします。

SEARCH="${CLAUDE_PROJECT_DIR}/skills/paper_search/scripts/search_papers.py"

基本的な検索：

python "$SEARCH" \
    --query "<QUERY>" \
    --start-year <YYYY> \
    --end-year <YYYY> \
    --max-papers 10

特定のソースに限定する場合：

python "$SEARCH" \
    --query "<QUERY>" \
    --start-year 2024 --end-year 2026 \
    --sources arxiv semantic_scholar openreview

複数クエリの統合（各クエリはすべてのソースを検索し、結果は統合、重複排除され、統合された検索語句セットに基づいて順位付けされます）：

python "$SEARCH" \
    --queries "diffusion watermarking|latent-space watermark|generative model IP protection" \
    --start-year 2024 --end-year 2026

ノイズフィルターを有効にする（関連性スコアがN未満の論文を除外します。CLIは除外件数を必ず正確に表示します。網羅性を優先する場合は省略してください）：

python "$SEARCH" --query "<QUERY>" --start-year 2024 --end-year 2026 --min-score 2

必ず --json を指定してください。 すべての検索でステップ1.5が実行され、要約は標準出力に表示されないため、要約に基づいて関連性を判定します。要約はこのファイルにのみ存在します。また、これはフィルターによってユーザーが求めていた論文が除外された場合に、ユーザーが参照できる未フィルターの記録でもあります。

python "$SEARCH" --query "<QUERY>" --start-year 2024 --end-year 2026 \
    --json /tmp/paper_search_results.json

従来のソース別表示（重複排除や順位付けを行わず、コネクターの生の出力を表示）：

python "$SEARCH" --query "<QUERY>" --start-year 2024 --end-year 2026 --raw

並列実行を無効にする場合（通常は不要です）：

python "$SEARCH" \
    --query "<QUERY>" \
    --start-year 2024 --end-year 2026 \
    --no-parallel

--no-parallel を指定した場合も、各ソースに分離されたワーカープロセスを使いますが、同時に起動するのではなく、ソースの順に実行します。

より細かく制御する必要がある場合（たとえば、CLIのテキスト出力ではなく構造化されたdictを利用する場合）は、関数を直接呼び出すこともできます。これは通常不要です。コード例については references/programmatic_api.md を参照してください。

有効なソース名

ソース	キー
arXiv	arxiv
DBLP	dblp
OpenAlex	open_alex
OpenReview	openreview
Semantic Scholar	semantic_scholar
Crossref	crossref
モデル知識（LLMの想起、API呼び出しなし）	model_knowledge

出力スキーマ

search_papers() は、ソース名を論文辞書のリストに対応付ける辞書を返します。

{
  "arxiv": [
    {
      "title": str,
      "authors": [str, ...],
      "year": int,
      "abstract": str,
      "url": str,
      "venue": str,
      "citation_count": int,
      "publication_date": str,
      "source": str,
      "doi": str | None,
      "arxiv_id": str | None
    }, ...
  ],
  "semantic_scholar": [...],
  ...
}

CLI の出力（デフォルト）：重複を除去し、関連度順に並べた単一のリストです。複数のソースにまたがる重複は、DOI、次に arXiv ID、最後に正規化したタイトルの順で照合して1件にまとめます。その際、最もシグナルの強いソースのフィールド、最大の引用数、「Sources:」の出典情報を保持します。すべての論文には、クエリに対する語彙的な関連度スコアが付与されます。調査・レビューをタイトルに含む論文には [survey] タグが付けられ、リストの末尾に移動されます（除外はされません）。--min-score が指定されない限り、フィルタリングは行われません。指定された場合は、除外件数が表示されます。ソースごとのヒット件数と「N cross-source duplicate records merged」の行が、リストの前に表示されます。--raw を指定すると、従来のソースごとにグループ化された出力に戻ります。

ユーザーへの出力

実行後、CLI のランキング順で、重複のない論文をすべて表示します（すでに重複が除去され、関連度順に並んでいます）。その後に Model Knowledge セクション、続いて概要を表示します。--raw を指定した場合は、次の順序でソースごとのグループに戻します：Semantic Scholar、OpenAlex、arXiv、OpenReview、Crossref、DBLP、Model Knowledge。

保持された結果の中でも、網羅性は重要です。このスキルを使うユーザーは、文献レビュー、関連研究の調査、先行技術の確認を行っています。Step 1.5 を通過したものはすべて、完全な形で表示します。要約は表を補完するものであり、表の代わりにはなりません。そのため、「スペース節約」のために結果を短い要約にまとめないでください。除外してよいのは、Step 1.5 がユーザー自身の質問との関連性がないと判断した論文だけであり、その場合も「判断に迷う場合は残す」というルールに従う必要があります。

Step 1: フィルターを通過したすべての結果を表示する

デフォルト（統合ランキング表示）：Step 1.5 で残された重複のない論文をすべて、CLI のランキング順を維持して、1つの Markdown 表に表示します。タグが付いている場合は、タイトルのセルに [survey] を付けます。ソースごとのヒット件数と統合された重複件数の行を表の上に再現し、--min-score が使用された場合は除外件数の行も表示します。

per-source hits: semantic_scholar=10, open_alex=10, arxiv=10 … · 22 unique (8 duplicates merged)

| #   | Title       | Date    | Venue   | Citations | Score | Sources |
|-----|-------------|---------|---------|-----------|-------|---------|
| [1](paper url) | Title here | 2024-03 | NeurIPS | 42 | 5 | SS, arXiv |
| [2](paper url) | [survey] Title here | 2023-11 | ICLR | 10 | 4 | OpenAlex |

--raw の場合：ソース見出しの下に、ソースごとに1つずつ表を表示します（従来の形式）。ソースからの結果が0件の場合は、その旨を明記します（例：「### OpenReview（論文0件）— この期間内に一致する結果はありません」）。

検索中にエラーが発生した場合、スクリプトはそれらを stderr に出力します。ユーザーにも必ず伝え、隠さないでください。

ステップ 1.5：関連性フィルター（セマンティック、必ず実行）

語彙スコアは順位付けを行いますが、意味を理解するわけではありません。一般的な単語によるノイズを拾い、同義語だけで一致するものを見落とします。たとえば、「生成モデルの IP 保護」に関する論文は「電子透かし」のクエリに対してスコアが 0 になる一方、対象の集合内では最も近い先行研究かもしれません。そのため、要旨を読み、該当しないものを除外してください。

実行するタイミング：検索のたびに必ず実行し、順位付けされた集合内のすべての論文を対象にします。

使用するモデル：ご自身、つまりこのスキルをすでに実行しているモデルです。トークンを節約するために、より安価で高速な階層へ引き継いではいけません。これは自由形式の意図判定であり、固定リストとの照合によるラベリングではありません。「関連性」の境界はユーザーの質問だけで決まり、どこにも明記されていないからです。より安価な階層では、隣接する分野の研究を無関係と体系的に誤判定します。また、厳格なフィルターを適用すると、その誤りは見えず、取り返しもつきません。

方法：

1. --json <path> を指定して CLI を再実行する（または実行してもらう）と、そのファイルを読みます。そのファイルには順位付けされた各レコードの要旨が含まれていますが、標準出力には含まれていません。
2. 論文ごとに、言い換えた検索クエリではなく、ユーザーの元の質問に照らして relevant | irrelevant を判定します。言い換えた検索クエリは、ユーザーが実際に尋ねた内容より情報が失われています。判定はタイトルと要旨の両方に基づいてください。要旨を読んでいない論文を irrelevant と判定してはいけません。
3. 迷ったら relevant にしてください。 irrelevant は明らかに別の内容を扱う論文に使い、確信が持てない論文には使いません。厳格なフィルターを安全に適用するための唯一のルールです。ユーザーには除外したものが見えないため、除外する側に立証責任があります。
4. irrelevant と判定した論文はすべて、表示する表から除外します。

表示方法：フィルター適用後の表を 1 つだけ表示します。除外した論文は表示せず、それらを折りたたみセクションにまとめることもしません。フィルターが実行され、何件が除外されたか分かるように、ヒット件数の行に件数を記載します。

per-source hits: semantic_scholar=10, open_alex=10, arxiv=10 … · 22 unique (8 duplicates merged) · 5 filtered as irrelevant

--json ファイルが出力されている場合は、未フィルターの集合がそのファイルにあることを一度だけ伝えてください。フィルターで除外しすぎた場合にユーザーが確認できる唯一の方法であり、1 行で済みます。

ステップ 2：検索結果全体の要約

すべての論文を表示した後、以下のセクションを包括的に要約し、指定された順序で記載してください。

1. 概要：使用したクエリ、対象年の範囲、見つかった論文の総数。対象コーパスの範囲を説明する文を 1～2 文添えます。
2. 傾向：時間的なパターン（例：「2024 年に関心が急増」）、主要な発表先、手法の変化、繰り返し登場する著者グループや研究室。
3. 主なテーマ：結果全体にわたる主要な研究テーマ／クラスターを 3～6 件挙げ、それぞれに 1 行の説明と代表的な論文番号を 2～3 件付けます。
4. キーワードの頻度：タイトルから抽出した頻出の技術用語／概念とその件数を表にします（要旨は JSON スキーマに含まれていますが、CLI では表示されません）。形式： | キーワード | 件数 |。上位 5 件を含めます。
5. 採択論文の被引用数上位：すべてのソースを対象に、採択論文のうち被引用数上位 5 件を、被引用数順に表で示します。形式：| 順位 | タイトル | 年 | 被引用数 |。
6. 筆頭著者別の被引用数上位：この結果セットに含まれる論文の被引用数合計に基づいて、筆頭著者上位 5 名を表にします。形式：| 順位 | 著者 | セット内の論文数 | 被引用数合計 |。 著者列には著者名だけを記載してください（例：Jane Doe）。 この列に論文タイトル、所属、発表先、その他の情報を付け加えてはいけません。論文数と被引用数の合計は、それぞれ専用の列に記載します。
7. おすすめの読み方：ユーザーの元の質問に最も関連し、影響力の大きい論文を 3～5 件選び、基礎的なものから最近のものへと読み進める順序で並べます。それぞれに 1 行の選定理由を付けます。

依存関係と失敗時の動作

• arXiv：arXiv API を使用します。
• DBLP：DBLP API を使用します。
• OpenAlex：OpenAlex API を使用します。
• OpenReview：pip install openreview-py が必要です。
• Semantic Scholar：Semantic Scholar API を使用します。
• Crossref：Crossref API を使用します。
• モデルの知識：API 呼び出しはありません。論文はモデル自身のトレーニングデータから想起されます。高速で無料ですが、モデルの知識カットオフに制限され、ハルシネーションが起こりやすくなります。責任を持って利用する方法については、以下の「モデルの知識ソース」セクションを参照してください。

HTTP 429/500/502/503/504 の応答には、上限付きの再試行が適用されます。ソースが引き続き失敗する場合、そのワーカーはエラーを出力し、ほかのソースのワーカーは処理を続けます。これらのエラーをユーザーに伝えてください。

HTTP タイムアウトの設定

すべてのネットワークソースでは、接続タイムアウトとソケットの読み取りアイドルタイムアウトを個別に設定します。

環境変数	デフォルト	意味
PAPER_SEARCH_CONNECT_TIMEOUT_SECONDS	15	TCP/TLS 接続のタイムアウト
PAPER_SEARCH_TIMEOUT_SECONDS	300	応答バイトが届かない状態を許容する時間
PAPER_SEARCH_<SOURCE>_TIMEOUT_SECONDS	未設定	ソースごとの読み取りアイドルタイムアウトの上書き設定。例：PAPER_SEARCH_OPEN_ALEX_TIMEOUT_SECONDS
PAPER_SEARCH_MAX_ATTEMPTS	4	最初のリクエストを含む最大試行回数

設定値はすべて正の値である必要があります。不正な値、ゼロ、負の値、NaN、無限大の場合、ワーカーの起動前に失敗します。読み取りタイムアウトの 300 秒は、ソース処理全体に対する予算ではありません。ソケットレベルで進行し続ける場合、応答にかかる合計時間はそれより長くなることがあります。

モデルの知識ソース

model_knowledge ソースはほかのソースとは異なり、API もスクリプト呼び出しもありません。代わりに、CLI の検索が返された後、クエリと年の範囲に合致する論文を自分自身のトレーニングデータから 5～10 件追加で想起し、出力内で別のソースとして提示します。

含める理由

API 検索は高精度ですが、次の 2 つのよくあるケースでは再現率が低くなります。

1. 基礎となる古い論文：研究者が常に引用する一方、キーワード検索では見つからない論文です（例：クエリが最近の派生手法に関する場合の、元祖 BERT または ResNet の論文）。
2. 分野横断的な古典的論文：API が十分にインデックス化していない学会やジャーナルに掲載された論文です。

モデルによる想起は API を補完し、新しいキーワード検索では常に見つかるとは限らない「誰もが知っている」論文を提示します。

データの追加方法

CLI の実行が完了した後：

1. クエリのトピックについて、知っていることを振り返ります。
2. トレーニングデータから、クエリと年の範囲に合致する論文を最大 10 件挙げます。タイトル、主著者、発表年、掲載先、および関連する理由を一文で記載します。
3. API の検索結果と重複しないようにします。論文がいずれかの API ソースにすでに表示されている場合は、model_knowledge には重ねて記載しません。
4. 確信度を正直に示します。モデルの知識の列には被引用数もライブ URL もありません。論文の存在や記憶が正確かどうか確信が持てない場合は、確定情報として提示せず、表で (uncertain — verify) と記載します。

ここで正直さが重要な理由

論文タイトルのハルシネーションは、このタスクにおける典型的な LLM の失敗です。「Smith et al., 2023, NeurIPS」のような架空の情報も Markdown の表では実在する論文と同じように見え、ユーザーには見分ける方法がありません。このソースの目的は、リストを水増しすることではなく、API が見落とした実在する論文を提示することです。妥当な確信を持って 5 件以上を想起できない場合は、件数を減らしてください。モデルの知識のセクションが空でも問題ありません。正直な対応です。

表示形式

ほかのソースと同じ表形式を使用します。ただし、確認済みのリンクがないため、URL 列には正規の論文 URL ではなく、検索クエリ（例：arXiv または Google Scholar の検索）へのリンクを設定してもかまいません。

### Model Knowledge (N papers, may include uncertain entries)

| #   | Title       | Year | Venue   | Notes |
|-----|-------------|------|---------|-------|
| [1](https://scholar.google.com/scholar?q=Title) | Title here | 2018 | NeurIPS | Foundational; often cited by recent work on X |
| [2](...) | Title here | 2024 | ICLR | (uncertain — verify) |

記憶から信頼できる被引用数を示せないため、「Citations」列を「Notes」に置き換えます。

例

ユーザー：「2023 年から 2024 年のロボティクス向け拡散ポリシーに関する論文を探してください。」

実行（「実行方法」セクションで定義されている $SEARCH を使用）：

python "$SEARCH" \
    --query "diffusion policy robotics" \
    --start-year 2023 --end-year 2024 \
    --max-papers 10

特定のソースのみを検索するには：

python "$SEARCH" \
    --query "diffusion policy robotics" \
    --start-year 2023 --end-year 2024 \
    --sources arxiv openreview semantic_scholar \
    --max-papers 10

その後、出力を読み、上記のルールに従って要約します。

重要な注意事項

• 最終レポートを記録してください。 検索完了後、次の場所に Markdown ファイルを 1 つ作成してください。 ${CLAUDE_PROJECT_DIR}/allinone.md
  • 内容：「すべてのソースの全結果を表示」テーブル全体に続けて、「検索結果全体の要約」セクションを、この順序で省略せずに記載します。
• レポート全体をユーザーに表示してください。 詳細なレポート全体をインラインで返します。すべての論文、すべてのテーブルに加え、分析と推論も含めてください。 テーブルを要約にまとめたり、「容量を節約する」ために結果を省略したりしないでください。
• 確認を求めないでください。 入力はすべて自動推定されます（「入力」セクションを参照）。最初のターンですぐに検索を実行してください。
• エラーはそのまま提示してください。 ソースでエラーが発生した場合は、隠したり、やみくもに再試行したりせず、stderr メッセージをユーザーに報告してください。