literature-review

文献レビュー

研究課題に基づき、テーマ別で引用に裏付けられたレビュー文書を作成します。 このスキルはオーケストレーターです。検索、取得、引用の検証は兄弟スキルに委任し、このスキルはワークスペース、スクリーニング対象の文献コーパス、主張の抽出、テーマ別の統合、最終的な網羅性チェックを担当します。

使用する場面

• 「X に関する文献レビューをしてください」／「X に関する最近の研究を調査してください」
• 「2023 年以降の X の最先端は何ですか？」
• 「この N 本の論文を読んで、テーマ別に統合してください」
• 独立したサーベイが必要な場合。論文の Related Work セクション向けには、ここでコーパス構築のフェーズを実施してから、draft-related-work に引き継ぎます。

入力

• 研究課題またはトピック。対象年の範囲と、必要に応じて対象とする会議・ジャーナルを指定するのが理想的です。
• 兄弟スキルの API 利用マナーに関する取り決めのためにエクスポートされた CONTACT_EMAIL。
• 任意：ユーザーがすでに所有している論文／DOI のリスト。

このスキルが処理を委任する兄弟スキル

段階	委任先	提供するもの
検索	find-papers	dblp_search.py、crossref_search.py、s2_search.py、arxiv_search.py（このスキルのスクリプトディレクトリ内）— キー不要、レート制限、キャッシュ対応
全文	fetch-paper	resolve_oa.py — DOI／arXiv ID から、合法的な OA コピーを一時的に取得
参考文献の確認	verify-citations	Crossref／DBLP／S2 に照合してすべての BibTeX エントリを検証し、撤回を検出

これらをインラインで再実装してはいけません（学術 API に対して場当たり的に curl を実行しないでください）。 兄弟スキルのスクリプトは、レート制限、バックオフ、キャッシュ、User-Agent に関する取り決めを担います。

プロセス

フェーズ 1 — 範囲の決定

1. ユーザーと相談して、研究課題、対象年の範囲、採用基準と除外基準（それぞれ 2～4 項目）、目標件数を明確にします（10～15 本が妥当な既定値です。30 本を超える場合は、ユーザーの明示的な同意が必要です）。
2. python3 scripts/init_review.py "TOPIC" を実行します。corpus.json、themes.yml、notes/、および review.md のひな形を含む lit-review/<slug>/ が作成されます。
3. 合意した基準を corpus.json の criteria に記入します。

フェーズ 2 — 検索（find-papers に委任）

1. クエリの設計、会議・ジャーナルの列挙、スノーボール検索については、references/methodology.md に従います。
2. 対象範囲に会議・ジャーナルが指定されている場合は、venues/conferences/<id>.yml を読み、aliases ブロック（DBLP キー、S2 の会議・ジャーナル文字列、Crossref のコンテナタイトル）を確認します。これにより、会議・ジャーナル名の別名の問題を解決できます。プロファイルは出発点です。プロファイル内の情報がレビューの根拠として重要になる場合（例：どのトラックが存在するか）は、利用する前に最新の cfp_url で再確認してください。
3. 検索ヒットのバッチをすべて記録します。 python3 scripts/corpus.py --corpus <ws>/corpus.json import hits.json --source dblp --query "..."（find-papers --json の出力を受け付け、DOI で重複を除去します）。単独の論文は corpus.py add で追加します。
4. 互いに異なる複数のテーマからシード論文を選び、テーマごとに 1 本ずつ使ってスノーボール検索を行います。都合のよい 1 本だけを使うと、収集した論文群が 1 つの下位分野に偏り、他の分野を見落とすためです。各関連論文を採用するのは、研究課題の議論における役割（拡張する手法／ベースライン／評価タスク／基礎となる研究の系譜）を明確に説明でき、スクリーニングの前に共引用の妥当性チェックを行った場合に限ります。完全な手順は references/methodology.md を参照してください。
5. 検索の品質が低下している場合は、未完了として扱い、完了と見なしてはいけません。 find-papers の resolve_papers.py は、各ファンアウトに COMPLETE または PARTIAL のステータスを付け、単一のインデックスでしか確認されていない結果にフラグを立てます。あるテーマの検索結果が PARTIAL（プロバイダーがレート制限された）になった場合、または中核論文が単一インデックスでしか確認できない場合は、引用グラフの段階でフォールバックがひそかに使われています。そのテーマの再現率は運に左右されます。テーマを網羅したと判断する前に、時間を置いてレート制限された検索経路を再実行する（S2_API_KEY を追加する）か、別のプロバイダーに切り替えてください。どの論文をフォールバック経路でしか取得できなかったかを corpus.json に記録し、ギャップを監査できるようにします。

フェーズ 3 — スクリーニング

1. 保留中の各論文について、タイトル＋掲載先＋（必要に応じて取得した）要旨を使い、記載された基準に照らして採用／除外を判断します。要旨の取得には find-papers の s2_search.py を使用してください。コミットするファイルに要旨を貼り付けてはいけません。
2. 理由とともに、すべての判断を記録します： python3 scripts/corpus.py --corpus ... set KEY --screened excluded --reason "out of scope: no spatial component".
3. 全文を読む前に、corpus.py stats の結果と採用リストをユーザーに提示します。対象セットを確認してください。

フェーズ 4 — 取得と抽出（fetch-paper に委任）

1. 論文を1件ずつ、リポジトリのルートから fetch-paper のリゾルバーを実行します： FP=skills/fetch-paper/scripts; python3 "$FP/resolve_oa.py" <DOI-or-arXiv-ID>. オープンアクセス版は一時的に読み込みます。arXiv HTML を優先し、次に PDF を直接読み込みます。合法的なオープンアクセス版がない場合（終了コード 3）、その論文に印を付け、検証済みのメタデータのみから統合するか、ユーザーに図書館のコピーを依頼してください。海賊版ライブラリは決して使用しないでください。
2. references/claim-extraction.md の主張記録形式を使い、根拠に基づくメモを notes/<key>.md に記録します。各主張にはアンカー（セクション／ページ）、強度ラベル、言い換えのみを含めます（逐語引用は 25 語未満とし、必ず引用符で囲みます）。要旨や論文本文は保存しないでください。メモは自分の言葉で書きます。
3. 進捗を記録します：corpus.py set KEY --fetched yes --extracted yes。

フェーズ 5 — テーマ別に整理

1. 抽出した主張を 3～6 個のテーマに分類し、themes.yml に記録して、論文にタグを付けます：corpus.py set KEY --theme <slug>。
2. references/review-structure.md に従い、統合マトリックス（論文 × テーマ × アプローチ × 評価 × 結果）を作成します。

フェーズ 6 — 引用を検証（verify-citations に委任）

1. BibTeX のひな形を生成します： python3 scripts/corpus.py --corpus ... bibtex > <ws>/references.bib. corpus.py は引用キーの唯一の信頼できる情報源です。bibtex はコーパスと完全に同じキーを持つ .bib を出力します。.bib 内のキーを手動で編集してはいけません。コーパス内で変更（corpus.py add --update）してから再生成し、コーパス、.bib、レビュー内の [@key] の間に食い違いが生じないようにしてください。
2. references.bib に対して verify-citations スキルを実行します。照合に使える機械可読の成果物を作成するため、必ず --json を付けてください： check_bibtex.py <ws>/references.bib --json <ws>/citecheck.json. 解決できない項目は修正するか削除し、撤回論文があればユーザーに知らせてください。
3. 検証済みフラグは手動ではなく、その成果物を使って設定します： python3 scripts/corpus.py --corpus <ws>/corpus.json verify-audit --report <ws>/citecheck.json. 監査では、レポートで確認されたキー（ステータス VERIFIED）に限り verified:yes を設定し、レポートで確認されなかったフラグは解除し、verified_via の来歴と日付を記録して、レポートの判定行をそのまま出力します。PARTIAL-PASS または FAIL の場合はゼロ以外の終了コードで終了するため、不完全な実行が問題なしと誤解されることはありません。
   • フラグを手動で設定する場合、corpus.py set KEY --verified yes には --source <provider>（エントリを確認したインデックスの名前）が必須となり、その値が記録されます。--verified yes のみの指定は拒否されます。
   • 「検証済み」とは、そのセッション中に権威あるインデックスがこのエントリの正式なレコードを実際に返したことを意味します。API が一度 ID を返しただけでは不十分であり、fetched:false の場合も認められません。来歴がない verified:yes のキーはゲートの不備です。corpus.py stats はそのようなキーを検出すると WARN を出します。
   • verify-citations の判定行をレビュー本文および概要／README に一字一句そのまま反映します。判定（PASS / PARTIAL-PASS / FAIL）と生の件数（検証済み N 件、フラグ別警告 M 件、スキップされたチェック K 件）を含めてください。PARTIAL-PASS を「検証済み」に格上げしたり、「PARTIAL-PASS, 11 WARN, 1 skipped」を「verified, 0 errors」にまとめたりしてはいけません。

フェーズ 7 — 草稿作成

1. references/review-structure.md の構成テンプレートに従って、review.md を作成します。
2. 先行研究に関するすべての事実に、コーパスキー [@key] または \cite{key} を付けます。主張はノートのアンカーまでたどれる必要があります。ノートがない場合、その主張は記載しないでください。

フェーズ 7b — 前方参照の照合

草稿（および関連研究の計画）が、手法、ベースライン、バックボーンを「X を拡張する」「Y と比較する」「W バックボーンを基盤とする」といった枠として文章中に挙げています。裏付けのないものが残らないよう、次の手順を実施してください。

1. python3 scripts/forward_refs.py <ws>/review.md [plan.md] --corpus <ws>/corpus.json を実行します。名前の挙がった手法／ベースライン／バックボーンを抽出し、検証済みのコーパスと照合して、未解決の項目を文献検索の作業リストとして出力します。
2. 実際に不足している文献については、完全なパイプライン（find-papers → screen → fetch-paper → extract → verify-citations）に戻して処理し、コーパスが完成したと宣言する前に追加します。引用可能な文献ではない項目（ユーザー自身のシステム、データセット、メトリクス）のみを除外します。リストを消すために引用を捏造してはいけません。
3. 実際の文献が作業リストに残らなくなるまで、再実行します。

フェーズ 8 — ゲート

1. コーパスと references.bib のキーが一致していることを確認します。 python3 scripts/corpus.py --corpus <ws>/corpus.json check-keys <ws>/references.bib。失敗した場合は、コーパスから .bib を再生成します （corpus.py bibtex）。キーを手作業で編集して整合させてはいけません。
2. python3 scripts/check_review.py <ws>/review.md --bib <ws>/references.bib を実行します。未知のキー、未検証または除外対象の引用、.bib にない引用キー（キーの不一致）、プレースホルダーマーカー、40 語を超える逐語引用があると失敗します。引用されていない収録論文や、引用のない長い段落がある場合は警告します。
3. RESULT: PASS になるまで修正して再実行します。合格した文書のみを納品し、レビューが網羅性ゲートに合格したことをユーザーに伝えてください。

出力

• lit-review/<slug>/review.md — テーマ別レビュー。すべての主張に引用が付され、check_review.py のゲートを通過しています。
• lit-review/<slug>/corpus.json — 監査可能な記録。検索、理由を含むスクリーニング判断、検証状況が記録されています。
• lit-review/<slug>/references.bib — 検証済みの BibTeX。
• lit-review/<slug>/notes/ — 論文ごとの、出典に基づいたノート（パラフレーズのみ）。

ガードレール

• 引用を捏造したり、誇張したりしてはいけません。論文をレビューに含めるのは、実際の検索結果に見つかった場合に限ります。引用を掲載するのは、verify-citations に合格した後に限ります。主張を裏付ける証拠がない場合は、その旨を記載してください。
• 著作権：論文の本文と要旨は必要に応じて取得し、一時的に処理します。ワークスペース、リポジトリ、レビューには決して書き込まないでください。メタデータ（DOI、タイトル、著者、BibTeX フィールド）は問題ありません。25 語未満の引用は、引用であることを明示し、出典を記載します。
• 礼儀：すべてのネットワークアクセスは、関連スキルのスクリプトを通じて行います（ホストごとに毎秒 1 リクエスト以下、User-Agent に CONTACT_EMAIL を設定、429 時のバックオフ、.cache/ を使用）。
• ユーザーに代わって、何かを送信または投稿してはいけません。
• スクリーニングの判断と最終的なテーマ構成をユーザーに提示し、承認を得てください。範囲に関する判断はユーザーが行います。

参考資料

• references/methodology.md — クエリ設計、会議録の列挙パターン、役割に基づく採用基準と共引用の妥当性チェックを伴う複数シードのスノーボール検索、停止基準、スクリーニングプロトコル、前方参照の照合。
• references/claim-extraction.md — 根拠に基づくノートの形式、アンカーと確度のラベル、ノートに関する著作権ルール。
• references/review-structure.md — レビュードキュメントのテンプレート、統合マトリクス、引用の構文、draft-related-work および write-abstract への引き継ぎ。