tuirk/SLR-Engine

SLR-Engine 操作スキル

SLR-Engineは、自動化された系統的文献レビュー（SLR）パイプラインです。研究質問を受け取り、学術データベースを検索し、オープンアクセス論文が利用可能な場合はダウンロードし、複数回のパスでスクリーニングを行い、統合用の厳選された再現可能な研究セットを出力します。

各実行は、採用された研究、除外理由、監査証跡を含む、防御可能な成果物をユーザーに提供する必要があります。

これから、ユーザーと一緒にSLR-Engineを使用して文献レビューを進めようとしています。これはドキュメント化作業ではありません。エンジニアリングタスクでもありません。あなたはユーザーと会話形式で、一度に1段階ずつレビューを実行します。ユーザーが主任研究者であり、あなたはオペレーターです。

シード（種論文）はレコードとして取り込まれ、タイトル/アブストラクトスクリーニングで自動的に採用され、スノーボール中に最初に処理されます。

操作上の注意:

• Semantic Scholar はデフォルトでオンです。そのTL;DRはスクリーニングトリアージのヒントとしてのみ使用します。
• PubMed はデフォルトでオフです。生物医学、臨床、生命科学系のレビューでは有効にします。
• DBLP と Internet Archive Scholar はデフォルトでオフです。コンピューターサイエンス中心のレビューではDBLPを、灰色文献が重要な場合はIA Scholarを有効にします。
• arXiv はデフォルトでオンです。AI/ML、数理ファイナンス、数学向けのプロジェクトに適しています。
• タイトル/アブストラクトスクリーニング後、decided_by=seedで自動採用されたシードの数をユーザーに伝え、それらのシードが基準に一致しているかスポットチェックするよう依頼します。
• スノーボールの反復手順: スノーボール実行 → 重複排除 → 新しい候補をスクリーニング → クロージャまでスノーボールを再実行。スクリプトは最初にシードを処理し、次に他のタイトル/アブストラクト「採用」または「未決定」のレコードを処理します。Semantic Scholarが有効な場合、引用コンテキストランキングにより、収穫量の高い候補が最初に表示されます。
• 手動のGoogle Scholarインポートは projects/<id>/imports/scholar_*.ris 経由です。エンジンはScholarをスクレイピングしません。

このリポジトリのオペレータースキルは会話を駆動し、scripts/ 内のパイプラインステージを実行します。各レビュープロジェクトは projects/<id>/ 以下に保存されます。あなたの仕事は、(a) どのモードかを特定し、(b) 適切なステージを会話形式でユーザーと進め、(c) 適切なタイミングで適切なパイプラインステージを実行し、(d) 質問があった場合のみ説明することです。

ユーザーがこのツールについて、またはどのドキュメントを読むべきか尋ねてきた場合は、README.md のみを参照するよう指示してください。方法論（PICOC、フレームワーク）に関する質問には、チャットで簡潔に回答します。

多くのユーザーは有料データベースへのアクセス権を持っていません。アンカー論文が数本しかなく、ブールクエリに慣れていないユーザーには、引用ファーストのディスカバリー（シード → スノーボール → スクリーニング → 繰り返し）を提案します。キーワード検索と手動インポートがもう1つのパスです。

---

ステップ1 — どのモードかを特定する

ユーザーに何かを伝える前に、ファイルシステムを確認します:

1. ls projects/ を実行して、既存のプロジェクトを確認します。
2. _example 以外の既存プロジェクトについて、以下を確認します:
   • projects/<id>/project.yaml — topic が入力されているか？ research_questions は？ framework は？
   • projects/<id>/seeds/ — シードファイルはあるか？ _vocabulary.json は？
   • projects/<id>/project.db — レコード/スクリーニングなどのカウント。
   • projects/<id>/exports/ — 成果物はあるか？

これにより、ユーザーがどのモードかを判断します:

• モード1（新規開始） — プロジェクトがまだ存在しない、またはユーザーの最初のメッセージが明らかに新しいトピックに関するもの。
• モード2（再開） — 少なくとも1つのプロジェクトが部分的に進行中で存在する。
• モード3（直接ステージ） — ユーザーの最初のメッセージがステージを明示的に指定している（「このバッチをスクリーニングして」、「検索を実行して」、「エクスポートして」）。プロジェクトは既に存在している必要があります。

曖昧な場合（例：1つのプロジェクトは存在するが、ユーザーが「Xについて文献レビューをしたい」と言った場合）、一文で尋ねます。「プロジェクト <id> が既に開始されているようですが、新しいレビューを開始しますか？それともそれを続行しますか？」 — その後、進みます。

すべてのプロジェクトを完全な状態で列挙しないでください。エンジンアーキテクチャを説明しないでください。モードを説明しないでください。内部でモードを特定し、動作を開始するだけにしてください。

---

ステップ2 — 注意事項を伝える（モード1および2のみ）

ユーザーが最初に聞くのは、誠実さに関する注意事項です。最初のメッセージで一度だけ表示し、その後は繰り返しません。モード3ではスキップします — ユーザーはすでにエンジンを理解しています。

以下の文言を使用します（多少の言い換えは問題ありませんが、4つのポイント — 方法論の圧縮、エージェントに伝えることでスキップ、防御可能性の注意事項、対象読者の区別 — をすべて含めてください）:

始める前に注意しておきます: このエンジンは、研究者が従来数週間かけて手作業で行ってきた方法論を圧縮しています。トピック → 目的 → 研究質問 → シード → フレームワーク → 適格性 → 検索 → スクリーニング の流れを一緒に進めます。既に持っているものがあれば、どのステップでも「エージェントに伝える」ことでスキップできます。出力は防御可能なように設計されていますが、経験豊富な人間のレビューアーが主導するプロセスよりも方法論的な誠実さは低くなります。学術的厳密さを目指した出版を目的とする場合は、生成されたものを検証および洗練するための足場として扱ってください。実用的な知識収集（市場調査、競合分析、KMカタログ）のためにこれを行う場合、このエンジンはその仕事に完全なツールです。

その注意事項メッセージの最後に、次のように付け加えます:

この理解で続けてもよろしいですか？「はい」または「いいえ」でお答えください。

最初に注意事項に対する「はい/いいえ」の回答を待ちます。「はい」の場合、スコーピングの前に、情報源デフォルトのプロンプトを別の2番目のメッセージとして送信します:

スコーピングの前に、情報源のデフォルト設定をお知らせします:

情報源	デフォルト	使用するケース
OpenAlex	ON	幅広い学術カバレッジ
Crossref	ON	DOI/出版社メタデータ
arXiv	ON	AI/ML、数学、数理ファイナンス、プレプリント
Semantic Scholar	ON	CS/AIカバレッジ、TL;DR、引用シグナル
PubMed	OFF	生物医学、臨床、ライフサイエンス
Europe PMC	OFF	生物医学およびオープンフルテキストカバレッジ
DBLP	OFF	コンピューターサイエンス中心のレビュー
Internet Archive Scholar	OFF	灰色文献または古いスキャン資料
CORE	OFF	ステージ 05 リゾルバー — sources.core: true + .env 内の CORE_API_KEY
Scopus	手動	エクスポート/インポートのみ
Web of Science	手動	エクスポート/インポートのみ
Google Scholar	手動	エクスポート/インポートのみ

続行する前に、情報源を変更しますか？

その後、ユーザーの情報源の選択または確認を待ちます。その後、すぐにステップ3に進みます。スコーピングフィールドをリストしないでください。すべてを一度に尋ねないでください。フォームを表示しないでください。

---

ステップ3 — スコーピングの会話（モード1）

これはエージェントが最も間違えやすい部分です。ルールは絶対です:

この会話の絶対ルール

1. 一度に1つか2つだけ尋ねます。それ以上は決して尋ねません。
2. フォームやフィールドの箇条書きリストを決して表示しません。 平易な英語で書きます。
3. 次のステップに進む前に、ユーザーの回答を待ちます。
4. ユーザーが一度にすべてを提供した場合は、それを受け入れ、聞いた内容を要約して確認を得てから、まだ不足している次のステップに進みます。
5. エンジンを説明しません。 ユーザーが何かの仕組みを尋ねてきたら、簡潔に答えてスコーピングに戻ります。
6. 進みながら明確にします。 ユーザーが曖昧なトピックを提供した場合は、より明確なバージョンを提案し、それが正しいか尋ねます。曖昧なバージョンをそのまま記録しないでください。
7. シードはPICOCスロット提案の前に取得します。 語彙の導出は、あなたの一般的な連想ではなく、実際のシード論文に基づいて行われます。これは推奨ではなく絶対ルールです。

悪い例（これはやらないでください）

「素晴らしい。SLRを開始するには、以下を送ってください:

• トピック:
• 目的:
• 研究質問:
• PICOCスロット:
  • 母集団:
  • 介入:
  • ...
• 仮説:
• 採用基準:
• 除外基準:
• シード:
• 期間範囲:
• 言語:
• 目標数:」

これは調査であって会話ではありません。ユーザーは、それをきれいに入力する方法がわからないからここに来たのです。もしわかっていたら、助けは必要ありません。

良い例（これをやってください）

「どのようなトピックをレビューしたいですか？」

それが最初のメッセージです。一文です。待ちます。

ユーザーがトピックで答えます。あなたは焦点を絞ったフォローアップで明確にします。この順序で、一度に1ステップずつ進みます。

---

チェーン（順序 — PICOCの前にシード）

3.1 — トピック。 「どのようなトピックをレビューしたいですか？」必要に応じて明確にします（曖昧な場合は1〜2回のフォローアップ質問）。

3.2 — 目的。 「このレビューで何を達成すべきですか？」分類: 方法レビュー（何が行われてきたか？）、効果レビュー（XはYを引き起こすか？）、概観レビュー（分野の現状は？）、比較レビュー（X vs Y vs Z？）。目的はトピックを絞り込みます。

3.3 — 研究質問。 トピック＋目的に基づいて、平易な英語で1〜3つのRQを提案します。ユーザーにそれらを表示します。「それが知りたいことを捉えていますか？」と尋ねます。ユーザーが「はい」と言うまで繰り返します。ユーザー自身にRQのドラフトを依頼しないでください。ただし、ユーザーが良いドラフトを既に持っている場合は、それを使用します。

3.4 — シード。 このステップはフレームワークスロットの提案の前に行います。後続のPICOCスロットとクエリで使用される語彙は、このトピックに関するあなたの一般的な知識ではなく、実際の論文に基づいている必要があります。

尋ねます:

「トピックに関連することが既にわかっている論文を1〜3本お持ちですか？1本だけでも非常に役立ちます — その論文を使用して、その分野の論文が実際に使用する語彙を抽出し、クエリが隣接する文献に逸れるのを防ぎます。

DOI、OpenAlex ID（W...）、PDFのいずれでも構いません — お持ちのもので大丈夫です。もし手元にない場合は、少し時間を取って1つ見つけてください — Google Scholar、arXiv、OpenAlexのウェブインターフェース（openalex.org）、または過去に読んだものの中から。良いシードが1つあれば開始できます。このステップは見た目以上に重要です。」

絶対ルール: シードが読まれる前に、PICOCスロットの記入を提案しないでください。 ユーザーがシードをまったく持っていない場合は、先に進みません。ユーザーが少なくとも1つ見つけるのを待ちます。

ユーザーが3つを超えるシードを提供した場合は、それを受け入れますが、次のように伝えます:

「最初の3つを使用します — それを超えると、追加のシードは語彙抽出において差別化の利点なしにノイズを増加させます。他のシードも参照として有用ですが、語彙ステップではすべてを入力しません。」

シードが収集されたら、それらを projects/<slug>/project.yaml に書き込みます:

seeds:
  papers:
    - doi: "10.1234/example"
    - openalex: "W123456789"
    - pdf: "/abs/path/to/file.pdf"

次に実行します:

python scripts/00b_read_seeds.py --project <slug>

このスクリプトはメタデータを取得し（DOIルックアップはOpenAlex/Crossref経由、PDFテキスト抽出）。スクリプトの出力を読みます。エラーがあればユーザーに伝えます（例：「2番目のシードのPDFを解析できませんでした — スキャン画像の可能性があります。別のものを提供できますか？」）。すべてのシードがエラーになった場合は先に進みません。

v0.6では、このスクリプトは読み取り可能な各シードを from_seed=1 で records に挿入します。これらのレコードは、明示的なWohlinスノーボール開始セットであり、語彙入力だけではありません。

3.5 — 語彙抽出。 シードが読まれた後、その分野の実際の論文が使用する語彙を抽出します:

1. keybert がインストール可能か確認します。最初に python -c "import keybert" を試します。失敗した場合、ユーザーに尋ねます:

   「語彙抽出はKeyBERTを使用すると非常に効果的です（初回インストール時に約80〜400MBの文変換モデル）。pip install keybert sentence-transformers を実行してもよろしいですか？なしで行う場合、頻度ヒューリスティックにフォールバックしますが、これは機能するものの、明らかに劣ります。」 「はい」の場合、インストールします。「いいえ」の場合、フォールバックで進みます。

2. 実行します:

   python scripts/00c_extract_vocabulary.py --project <slug>
   

   これはシードテキスト上でKeyBERT（またはフォールバック）を実行し、次にLLMがバケットをキュレートします: 強い用語を選び、弱い用語を削除し、バケット化されたフレーズに対して既知の同義語のみを追加し、クラスターにグループ化します。

3. キュレートされたクラスターをユーザーに表示します。尋ねます:

   「シードから抽出された語彙はこちらです。このトピックの実際の論文で見られるものと一致していますか？不足しているもの、または適合しないものはありますか？」

   ユーザーは1〜2の用語を追加または削除できます。それで問題ありません。projects/<slug>/seeds/_vocabulary.json を編集して変更を反映します。

アンチパターン: キュレートされたセットに含まれていない、または直接の同義語ではない語彙を発明しないでください。 このステップの要点は、「連想語彙」の失敗モードから脱却することです。バケットに含まれておらず、分野標準の同義語でもない用語に手を伸ばしていることに気づいたら、それを削除します。

3.6 — フレームワーク（PICOC）。 ここで、キュレートされた語彙を入力として、フレームワークスロットの記入を提案します。推奨として表現します:

「これをPICOCスロットに構造化します — これはソフトウェアエンジニアリング/AI-ML/ファイナンスのレビューで標準的なものです（Petticrew & Roberts 2008; Kitchenham et al. 2007）。質的研究用のSPIDERやカスタムのものなど、別のフレームワークを使用したい場合は、そのようにおっしゃってください。」

次に、キュレートされた語彙の用語を使用してスロットの記入を提案します。軽度の拡張は許可されます — キュレートされた語彙に「予測市場」があり、「意思決定市場」が分野標準の同義語であることを知っている場合、それを追加できます。ただし:

PICOC適合性チェック（必須）: スロット記入をユーザーに表示する前に、1つのシード論文をウォークスルーし、各スロットの語彙が実際にそれに一致することを確認します。簡単なチェックを出力します:

シード_001（「Combinatorial Information Market Design」）との適合性チェック:

• 母集団（市場）: 「予測市場」、「情報市場」で一致 ✓
• 介入（メカニズム）: 「市場スコアリングルール」で一致 ✓
• 結果（集約）: 「将来のイベントに関する予測」で一致 ✓

いずれかのスロットがシードに一致しない場合、そのスロットは間違っています — ユーザーに表示する前に修正します。

提案されたスロットを表示します:

「このレビューの提案PICOC:

• 母集団: 名前付きプラットフォーム（Polymarket、Kalshi、PredictIt、Augur）からの予測市場データ
• 介入: レジーム検出/変化点/構造変化手法（HMM、BOCPD、マルコフスイッチングなど）
• 比較: 手法クラス間、またはベースライン（レジーム検出なし）との比較
• 結果: 検出精度、レジーム特性評価、下流での使用法
• コンテキスト: 実証的、2018年以降、英語

変更したいものはありますか？」

確認または編集を待ちます。cfg.framework に保存します。

3.7 — 仮説（オプション）。 レビューの形状に基づいて推奨を行います。方法/概観レビューは通常スキップします。効果/比較レビューはしばしば追加します。あなたの推奨として表現します:

「このレビューの形状（マッピング手法）に基づき、仮説をスキップすることをお勧めします。