search-lit

文献検索スキル

作成するすべての参考文献は、ライブデータベースの検索結果に基づいている必要があります。記憶だけを頼りに引用を作成してはいけません。思い出した引用は実在するように見えても、存在しないことがあるためです。

検索ツール：MCP（優先）＋ E-utilities（フォールバック）

優先：MCP ツール（Claude.ai リモート）

データベース	MCP ツール	用途
PubMed	mcp__claude_ai_PubMed__search_articles	クエリ、MeSH 用語で検索
PubMed	mcp__claude_ai_PubMed__get_article_metadata	PMID の完全なメタデータを取得
PubMed	mcp__claude_ai_PubMed__find_related_articles	PMID に関連する文献を検索
PubMed	mcp__claude_ai_PubMed__lookup_article_by_citation	引用を確認
PubMed	mcp__claude_ai_PubMed__convert_article_ids	PMID／DOI／PMCID 間で変換
Semantic Scholar	mcp__claude_ai_Scholar_Gateway__semanticSearch	すべてのフィールドを対象にセマンティック検索
bioRxiv/medRxiv	mcp__claude_ai_bioRxiv__search_preprints	プレプリントサーバーを検索
bioRxiv/medRxiv	mcp__claude_ai_bioRxiv__get_preprint	プレプリントの完全なメタデータを取得
CrossRef	https://api.crossref.org/works/{DOI} を指定した WebFetch	DOI を確認

フォールバック：NCBI E-utilities（Bash 経由の直接 API）

mcp__claude_ai_PubMed__* の呼び出しで、「terminated」、「not found」、「not available」、「not connected」を含むエラーが返された場合は、このセッションにおける以降の PubMed 呼び出しをすべて、同梱の E-utilities スクリプトに切り替えてください。切断後に MCP を再試行しないでください。同じ会話中には復旧しません。

EUTILS="${CLAUDE_SKILL_DIR}/references/pubmed_eutils.sh"
PARSER="${CLAUDE_SKILL_DIR}/references/parse_pubmed.py"

# Search PubMed (returns PMIDs)
bash "$EUTILS" search "diagnostic test accuracy meta-analysis radiology" 20 \
  | python3 "$PARSER" esearch

# Get article summaries as markdown table
bash "$EUTILS" fetch_json "16168343,16085191,31462531" \
  | python3 "$PARSER" esummary

# Get detailed metadata
bash "$EUTILS" fetch "16168343" \
  | python3 "$PARSER" efetch

# Generate BibTeX entries
bash "$EUTILS" fetch "16168343,16085191" \
  | python3 "$PARSER" bibtex

# Verify a citation by exact title
bash "$EUTILS" cite_lookup "Bivariate analysis of sensitivity and specificity" \
  | python3 "$PARSER" esearch

# Find related articles for a PMID
bash "$EUTILS" related "16168343" 10 \
  | python3 "$PARSER" esummary

スクリプトは呼び出しの間に 350 ms 待機します（NCBI は API キーなしで 3 リクエスト/秒、NCBI_API_KEY がある場合は 10 リクエスト/秒を許可しています）。バッチ呼び出しは順次実行してください。

MCP ツール	E-utilities コマンド	パーサーモード
search_articles	search <query> [retmax]	esearch
get_article_metadata	fetch <pmids>	efetch または bibtex
find_related_articles	related <pmid> [retmax]	esummary
lookup_article_by_citation	cite_lookup <title>	esearch → fetch
convert_article_ids	利用不可（CrossRef DOI 検索を使用）	—

---

ワークフロー

フェーズ 1：検索戦略

1. 参考文献が必要な研究テーマ、質問、または原稿のセクションを確認します。
2. 主要な概念（対象集団、介入／曝露、比較、アウトカム）からクエリを作成し、PubMed 用の MeSH 用語を含めます：（concept1 OR synonym1）AND（concept2 OR synonym2）。
3. 範囲を設定します。期間（ユーザーが指定しない場合は過去 10 年）、論文の種類、言語（デフォルトは英語）を指定します。
4. ブールクエリ、データベース、フィルターをユーザーに提示します。

**確認事項：**検索を実行する前に、ユーザーの承認を待ちます。

フェーズ 2：検索の実行

1. PubMed（search_articles、ブールクエリ）、Semantic Scholar（semanticSearch、自然言語クエリ）を検索し、プレプリントが関係する場合は bioRxiv/medRxiv（search_preprints）も検索します。
2. DOI またはタイトルの類似度に基づいて、データベース間の重複を除去します。
3. 次の表に結果をまとめ、同じ行を references/search_results.tsv に書き込みます。

| # | Title | Authors (first + last) | Year | Journal | PMID/DOI | Relevance |
|---|-------|----------------------|------|---------|----------|-----------|
| 1 | ...   | Kim J, ... Lee S     | 2024 | Radiology | 12345678 | High      |

4. どの論文を含めるか、ユーザーに選んでもらいます。

ダウンロードした件数だけでなく、情報源に存在すると示された件数を記録します

誤った件数を取得してもエラーは発生せず、誤った件数を基に作成した PRISMA フローは、その後の処理で矛盾が指摘されない限り、架空のものです。次の両方を確認してください。

• 件数がページ上限とちょうど一致する場合。 どの情報源も合計件数を報告します。 esearchresult.count、opensearch:totalResults、meta.count です。api_total と downloaded を並べて記録し、downloaded < api_total の場合、または downloaded がページ上限や ループ上限とちょうど一致する場合に、明確に失敗させます（例：ループ内の if start >= 2000: break によって、2,000 件が報告される場合）。TRUNCATED を出力し、 検索記録の書き込みを拒否してください。
• 適用されていないブール条件。 OpenAlex の search= は関連度順に並べるフリーテキスト パラメーターで、AND／OR を黙って無視します。filter=title_and_abstract.search: はこれらを 適用します。必須条件を 1 つ否定して、クエリをもう一度実行してください。ヒット件数が 減らなければ、ブール条件が無視されています。エンジンは絞り込みではなく、ランキングを 行っています。

E-utilities 経由の PubMed だけは、単純な方法で安全に処理できます。それ以外はすべて、両方を行ってください。

スクリーニング行にある DOI が、その行の論文の DOI とは限りません

パイプラインがレコードと一緒に DOI を受け取ったのではなく、タイトルの類似度に基づいて Crossref と照合し、doi 列に値を補完した場合、誤った照合先でも解決可能な、別の論文の 有効な DOI である可能性があります。それを解決し、判断の根拠にする前にタイトルを照合してください。

python3 "${CLAUDE_SKILL_DIR}/scripts/check_doi_record_match.py" --table 2_Screening/round3.tsv \
        --email <contact> --json qc/doi_record_match.json

DOI_NOT_THIS_RECORD は別の論文に解決される DOI、DOI_IS_CONTAINER は論文ではなく、号、 補遺、または会議録に解決される DOI、DOI_IS_UPDATE_NOTICE は更新対象の論文ではなく、 訂正、正誤表、または撤回通知（Crossref の update-to）に解決される DOI です。 DOI_UNRESOLVED は削除せず、解決不能として報告されます。この処理は、誤った DOI の確認が まだ容易なスクリーニング段階で実行されます。完成した参考文献リストの監査には /verify-refs を使用してください。

Phase 2.5：引用文献検索（スノーボーリング）

任意ですが、システマティックレビューや網羅的な背景調査には推奨されます（PRISMA 項目 7、 「引用文献検索で特定されたレコード」）。Semantic Scholar Graph API ヘルパーを使い、引用グラフを たどってシードセットを拡張します。

python3 "${CLAUDE_SKILL_DIR}/references/snowball.py" \
  --seed DOI:10.1000/synthetic.example,PMID:00000000 \
  --direction all \
  --pool references/library.bib \
  --out references/library.bib

• 方向：backward（シードが引用する参考文献）、forward（シードを引用する論文）、 similar（S2 の推薦）、または all（デフォルト）です。重複排除は DOI と正規化したタイトルで行い、 --pool 内および取得したセット内の両方を対象とします。
• 信頼フラグ：候補は verified=false および verified_by=semantic_scholar を付けて 書き込まれます。引用する前に、それぞれに /verify-refs（または Phase 4 の検証）を実行してください。
• 出力の仕様：references/library.bib にのみ追記します。スクリプトは manuscript/_src/refs.bib への書き込みを厳格に拒否します。
• PRISMA の行：スクリプトは Records identified through citation searching (snowballing): N raw (backward=…, forward=…, similar=…); after dedup against existing pool: M new candidates. と出力します。PRISMA フローの引用文献検索欄に M を記録してください。
• 不完全な実行：シードまたは方向の取得に失敗した場合、あるいは情報源が --limit を超えるレコードの存在を 示した場合（next ページがある場合）、スクリプトはシード／方向ごとに FAILED または TRUNCATED の行を出力し、PRISMA の行の末尾に INCOMPLETE を付けて、終了コード 1 で終了します。 これらの件数は下限値です。記録せず、実行が終了コード 0 で完了するまで再実行してください （または --limit を引き上げてください）。

Phase 3：精読

選択した各論文について、完全なメタデータを取得し（PubMed では get_article_metadata、 bioRxiv では get_preprint）、研究デザイン、サンプルサイズ／データセット、主要な方法、 具体的な数値を含む主な知見、著者が述べる限界を抽出します。複数の論文については、レビュー用に 文献マトリックスを作成します。

| Paper | Design | N | Key Finding | Limitation | Relevance to Our Study |
|-------|--------|---|-------------|------------|----------------------|

Phase 4：引用文献管理

検証

1. DOI や PMID を決して捏造しないでください。 見つからない場合は、該当する文献に [UNVERIFIED - NEEDS MANUAL CHECK] と記載してください。
2. すべての文献を API の結果と照合してください。著者の最初と最後、出版年、 ジャーナル、論文タイトル（言い換えではなく原文どおり）、および入手可能な場合は巻号・ページを確認します。一致しない項目にはそれぞれフラグを付けてください。
3. WebFetch https://api.crossref.org/works/{DOI} で各 DOI の解決を確認してください（CrossRef エラーの場合は「エラー処理」に従ってください）。

BibTeX の生成

検証済みかどうかにかかわらず、すべての文献について verified フラグを明示したエントリを生成してください。

@article{FirstAuthorLastName_Year_ShortKey,
  author    = {Last1, First1 and Last2, First2 and Last3, First3},
  title     = {Full Title As Retrieved From Database},
  journal   = {Journal Name},
  year      = {2024},
  volume    = {310},
  number    = {2},
  pages     = {e234567},
  doi       = {10.1001/jama.2024.12345},
  pmid      = {12345678},
  verified  = {true},
  verified_by = {pubmed+crossref},
  verified_on = {2026-04-24},
}

verified（すべてのエントリで必須）	意味
true	DOI または PMID を PubMed/CrossRef で確認済み。タイトル、著者、年がすべて一致
false	テキストから解析したが、API の検索に失敗したか、結果が一致しなかった。原稿には [UNVERIFIED - NEEDS MANUAL CHECK] を記載する必要があります
manual	検索に失敗した後、ユーザーが明示的に追加したもの。引き続き未検証です

verified_by には、確認に使用した情報源（pubmed、crossref、semantic_scholar、またはその組み合わせ）を記載します。verified_on は、直近の検証成功日を ISO 形式で記載します。下流のスクリプトはこれらのフィールドを読み取りません。/verify-refs がすべてのエントリを再確認するため、これらは信頼性を記録するものであり、信頼性を付与するものではありません。

BibTeX キーの規則：FirstAuthorLastName_Year_OneWord（例：Kim_2024_Validation）。キーは暫定的なものです。/lit-sync がエントリを Zotero にインポートするときに、Better BibTeX が引用可能なキーを割り当てます。

出力

1. エントリを references/library.bib に追記してください（上書きしないでください）。これは /lit-sync が Zotero にインポートする候補プールです。manuscript/_src/refs.bib には決して書き込まないでください。/lit-sync（Better BibTeX 経由）がこのファイルへの唯一の書き込み元です。
2. 検証ステータスを含む概要を出力してください。

Verified:    12 references (verified=true)
Unverified:   1 reference  (verified=false) [NEEDS MANUAL CHECK]
Total:       13 references

フェーズ 4b：Zotero ライブラリとの連携

Zotero へのインポートは /lit-sync の役割です。Zotero への書き込みと references/zotero_collection.json は /lit-sync が管理するため、references/library.bib を渡してください。Zotero MCP サーバーに接続されている場合は、ここで読み取り専用の操作ができます。zotero_search_items（DOI による検索）を使って候補がすでにライブラリにあるか確認し、zotero_get_annotations を使ってユーザーの過去の読書メモを参照してください。

フェーズ 5：全文の取得

オープンアクセス取得カスケードの唯一の実装先である /fulltext-retrieval に委任してください。ここで OA 取得を再実装しないでください。references/library.bib の検証済み候補 DOI を渡してください。

ENGINE="${CLAUDE_SKILL_DIR}/../fulltext-retrieval/fetch_oa.py"
# extract DOI + Title (and PMID/FirstAuthor when available) → worklist.tsv
python3 "$ENGINE" worklist.tsv -o pdfs/ -e <contact-email> --report pdfs/retrieval_report.json

DOI のみのリストではなく、検証済みの書誌タイトルを作業リストに記載してください。取得レポートにある source_identity と file_sha256 をレコードとともに保持してください。ダウンロードの成功とタイトルの一致だけでは PDF は検証されません。引用する前に、矛盾、未解決または入手不可の証拠、ハッシュが変化したファイルを確認してください。古いレポートで識別情報のフィールドが欠けている場合は未評価を意味します。また、consistent であっても、論文の主張を検証するものではなく、表紙部分の情報との整合性を示す参考情報にすぎません。

Zotero に保存済みの PDF およびプロキシを考慮した取得には、/lit-sync のフェーズ 2.7 を使用してください。pdfs/manual_needed.txt にある DOI については、所属機関のアクセス手段（所属機関の購読契約、プロキシまたは VPN）、文献複写、または責任著者のみを利用してください。ペイウォールや出版社のアクセス制御を決して回避せず、許可されていない PDF ミラーを設定しないでください。

フェーズ 6：ギャップ分析

原稿の執筆中に呼び出された場合は、原稿中のインライン引用を抽出し、検索結果と比較して、具体的なギャップを報告してください。引用されていない重要論文、新しい版がある古い文献、欠けている方法論上の文献（統計手法、報告ガイドライン）などが該当します。

---

専門的な検索モード

モード：原稿用参考文献候補プール

原稿の参考文献候補プールを提示します。通常は、参考文献の十分性チェックで、草稿が目標数に達していない、または名前の挙がった手法が引用されていないと判定された場合に、/write-paper の Step 7.3c（または /self-review の Phase 2.5c-2）から呼び出されます。独自研究の参考文献リストにも直接利用できます。

独自研究論文では、簡易検索で見つかる約10件ではなく、検証済みの候補を 25～40件 提示します。その分野の文献が本当に少ない場合は、候補が少ないことを黙って示すのではなく、明確に伝えてください。より厳しい投稿先ジャーナルの参考文献上限や、指定されたユーザーの範囲がある場合は、それに従ってください。

候補を 6つのカテゴリ で網羅してください。

1. 背景／疾患負担／臨床的背景 — なぜこの問いが重要なのかを示す文献。
2. 研究ギャップを定義する先行研究 — 原稿が発展させる、または反証する研究。
3. 比較対象／類似デザインのコホート — 結果を比較する対象となる研究。
4. 方法／統計学の標準的な出典 — 名前の挙がった各手法、モデル、スコア、方程式、診断基準の原典（例：競合リスクモデル、多重代入、E-value、eGFR方程式、一致度統計量）。このカテゴリで、方法に関する名前の挙がった手法の不足を補います。
5. 報告ガイドラインの出典 — STROBE、TRIPOD(+AI)、CONSORT、PRISMA(-DTA)、STARD など。
6. 解釈／メカニズム／限界を裏付ける文献 — 考察の主張に根拠を与える文献。

候補ごとに PMID/DOI、検証状況、候補カテゴリ、対象となる原稿セクション、必要な理由を一文で報告してください。項目は Phase 4 を経て references/library.bib にのみ追加します。このモードで提示するのは候補です。採用するかどうかはユーザーが決めます。また、原稿の参考文献ファイルには追加しません。

モード：研究の先行性チェック

研究を設計する前に実施してください。背景検索（「このトピックについて何が書かれているか」）だけでは見落としが生じます。代わりに、次の4つの具体的な問いを尋ねてください。

確認対象	判定
研究課題	既に取り上げられている／一部取り上げられている／未検討
サンプリングフレーム（対象集団、使用する記録、対象年）	既に取り上げられている／一部取り上げられている／未検討
測定軸（コード化または測定する対象と、その粒度）	既に取り上げられている／一部取り上げられている／未検討
投稿先ジャーナル	同ジャーナルですでに発表済み／近接する内容あり／未検討

それぞれに個別の判定を付けてください。ある軸では独自性があっても、別の軸ではすでに十分に研究されている場合があります。4つを1つの回答にまとめると、その違いが見えなくなります。ジャーナルの行は見栄えのためではありません。ある研究デザインが、サンプリングフレーム、コード化の軸、投稿先ジャーナルのすべてで既存論文と一致していたことがあります。しかも、そのジャーナルは第一候補でした。多くの場合、このモードはプロジェクトを終わらせるのではなく、主張の範囲を絞り込みます（例：「誰も調べていない」から「出所別に分析した人はいない」へ）。そして、範囲を絞った主張は査読を通過します。

競合相手のように検索してください。トピックだけでなく、正確なサンプリングフレーム、正確な測定指標、ジャーナル独自のサイトを検索します。4つの判定と、それぞれの根拠となる論文を報告し、最終的な判断はユーザーに委ねてください。

モード：系統的検索

系統的レビューや包括的な文献セクションの場合：

1. 検索戦略全体を記録します（PRISMA準拠）。
2. データベース、検索日、検索クエリ、検索結果数を記録します。
3. 各スクリーニング段階での採用／除外を追跡します。
4. PRISMAフローダイアグラム用のデータ概要を出力します。

モード：クイック引用

ユーザーが説明する単一の参考文献（「胸部X線画像のAIに関するSmithの2023年の論文」など）について、詳細情報を使ってPubMedとSemantic Scholarを検索し、上位3件の候補を提示します。ユーザーが確認した候補のBibTeXエントリを生成します。

モード：関連論文

PMIDまたはDOIから、find_related_articles とSemantic Scholarの引用ベースの推奨を使って関連論文を取得し、関連性順に並べます。重複を考慮し、PRISMAで件数を集計できる構造的な文献拡張（後方＋前方＋類似）には、代わりに references/snowball.py を使う Phase 2.5：引用文献検索 を利用してください。

モード：Embase ブラウザー自動化

Embase には公開 API がありません。検索に Embase を含める必要がある場合は、${CLAUDE_SKILL_DIR}/references/embase_browser.md を読んでください。Chrome 自動化によるエクスポート手順、CSV の行形式、PubMed → Embase のクエリ変換が記載されています。

---

エラー処理

• 検索結果が 0 件の場合は、クエリの範囲を広げ（概念を 1 つ削除するか、より広範な MeSH 用語を使用して）、再試行してください。
• CrossRef の HTTP エラー（トークン節約ルール）：
  • 403（レート制限）： 再試行しないでください。CrossRef をスキップし、代わりに PubMed のタイトル検索で確認してください。
  • 303（リダイレクト）： 可能であればリダイレクトに従ってください。できない場合は CrossRef をスキップし、PubMed にフォールバックしてください。
  • セッション中に最初の CrossRef 403/303 が発生した後は、N 回の再試行によるトークンの浪費を避けるため、残りすべての文献で CrossRef をスキップし、PubMed のタイトル確認に直接進んでください。
  • 生のエラーメッセージ（「Request failed with status code 403.」）を出力しないでください。最後に次の要約を 1 行だけ報告してください：CrossRef unavailable for {N} references (rate-limited). Verified via PubMed instead.
• 上記のルールに従っても CrossRef で DOI を解決できない場合は、PubMed でタイトルを検索し、その文献の存在を確認してください。
• いずれの方法でも文献を確認できない場合は、次のように記載してください：「この文献は確認できませんでした。提出前に手動で確認してください。」確認できていない文献を黙って含めないでください。

既知の制限

• check_doi_record_match.py は、類似度のしきい値を使ってタイトルを比較し、構造化された Crossref フィールド（type、update-to）を読み取ります。研究プロトコルや複数部構成の論文の第 2 部は、タイトルが行のタイトルと単語または数字 1 つ分異なるだけでは、その行が示す論文と区別されません。これを示す構造化フィールドがないためです。問題なく実行が終了しても、「不一致を検出しなかった」という意味であり、すべての DOI が正しいことの証明ではありません。