mleswell-ai/research-synthesis

研究統合（Research Synthesis）

統合（シンセシス）とは、単一の情報源では答えられない問いに答えるものです：エビデンス全体が何を支持しているのか、どの程度確信を持てるのか、情報源間でどこが一致せず、その理由は何か、そして目の前の意思決定にとって何が導き出されるのか。単なる要約のリストは統合ではありません。

三つの問い

出力されるすべての記述は、三つの問いに耐える必要があります。手法全体とledger.pyツールは、答えを検証可能にするために存在します。

1. これは正確にはどこから来たのか？ 読まれた情報源内の名前付きの場所。答えはロケーターです。
2. それは何回別々に観察されたのか？ ひとつの研究を繰り返す10の記事は、1回の観察です。答えはリネージ（系統）の数です。
3. それは私たちにどの程度の確信を許すのか？ エビデンスの構造は確実性に上限を設定します。判断はそれより低くしかできません。

曲げることのできないルール

• 読んだものだけを引用すること。どのように読んだかを記録すること（full-text、abstract-only、secondary-citation）。完全なテキスト未満では、確信のある主張はできません。
• 参考文献、著者、年、図表、引用は記憶から一切使わないこと。見つけられない場合は、引用しないこと。
• すべての図表と引用にはロケーターがあり、読書中に取得すること。
• 情報源が報告すること（所見）、それが何を意味すると解釈するか（解釈）、何をすべきか（勧告）は分離され、最後の二つはその基礎にある所見よりも確かであることは決してありません。
• ある主張に反するエビデンスは、それを支持するエビデンスと並べて記録すること。
• 「エビデンスが不十分である」は正当な回答です。エビデンスの不在は、不在のエビデンスではありません。

モードを選択する

不明な場合は、より軽量なモードを採用し、その旨を明記してください。

モード	使用時	情報源	検索	出力
迅速	主に提供された資料からの限定的な回答	約3～10件	なしまたは軽度	簡潔なブリーフ（多くの場合チャット内）（assets/brief-template.md）
標準	実際の意思決定がかかっている場合	約10～30件	構造化、記録あり	完全なレポート（assets/report-template.md）
系統的	手法が再現可能である必要がある場合	プロトコルに従った数	網羅的、記録・計数あり	完全なレポート、プロトコル、表

二つのバリエーション：

• 一次定性データ（インタビュー、オープンな調査回答、フィードバック、チケット）：同じワークフローです。最初にreferences/qualitative-data.mdを読んでください。
• 既存の統合を評価する場合：下記「他人の統合を監査する」に進んでください。

ワークフロー

これをワーキングノートにコピーし、進捗に応じてチェックを入れていってください。順序が重要です。各ステップは次のステップに必要なものを生成し、飛ばすと既知の障害が発生します（references/failure-modes.md）。

- [ ] 1 フレーミング   問い、決定、範囲、基準を読む前に確定する
- [ ] 2 収集          台帳を開始する。検索を記録する、または提供されたコーパスを目録にする
- [ ] 3 評価          すべての情報源をスクリーニングし、評価し、リネージを割り当てる
- [ ] 4 抽出          ロケーターとともにエビデンスを台帳に抽出する
- [ ] 5 構築          情報源を横断して主張を構築する。矛盾は調整するか、説明不能とマークする
- [ ] 6 評価          確実性を各上限以下に評価し、理由を付ける
- [ ] 7 破壊的検証   要石を調べ、対立する説明を試み、主張を修正する
- [ ] 8 作成          まず回答を、決定に関連付けて書く
- [ ] 9 再読          ワークシートを確認する。`check`と`report`が正常に動作する。ルーブリックに合格する

1 フレーミング

それぞれ1～2行で確定させること：問い（「いいえ」または「場合による」と答えられる形式で）。それが役立つ決定とその利用者。範囲（人口や状況、期間、場所、情報源の種類）。そして包含・除外基準。

基準は読む前に固定すること。結果を見た後に調整された基準は、統合が著者の期待を確認するものになる方法です。変更が必要な場合は、その変更と理由を記録してください。

ユーザーには最大でも2～3つの質問を、回答が作業を変更する場合（通常は決定、範囲境界、モード）にのみ行ってください。ユーザーが答えたくない場合は、作業を進め、前提条件を出力の先頭にリストしてください。

質問フレームワーク、レビューの種類、プロトコルの概要：references/scoping-and-protocol.md。

2 収集

台帳を開始する。これにより今日の日付も固定されます。これは推測してはいけません：

python scripts/ledger.py new ledger.json --question "..." --purpose "..." --mode standard --corpus searched

--corpusはsupplied、searched、またはmixedです。台帳は、プロトコル、検討されたすべての情報源、およびそのエビデンスを持つすべての主張を保持する単一のJSONファイルです。これは統合のワーキングメモリであり、ディスク上に保持し、最新の状態に保つ必要があります。フィールドと入力例：references/evidence-ledger.mdおよびexamples/flexible-start/。

提供されたコーパス：すべてのアイテムにソースID（S1、S2、...）を割り当て、レポートで統合が提供されたもののみをカバーしていると明記してください。

検索：

• 分野の語彙を学ぶために短く広いクエリから始め、その後絞り込みます。
• すべてのクエリを台帳に記録します。場所、クエリ、日付、結果の数。
• オリジナルに当たること。記事が研究を報告している場合、研究を見つけて引用し、入手できない場合は記事を引用し、secondary-citationと記録します。
• 意図的に帰無結果、反対の所見、未発表または灰色の資料を検索してください。発表されたエビデンスは肯定的な結果を過剰に代表しています。
• 参考文献リストを逆方向に、引用を順方向にたどってください。
• 新しい検索がほとんど既知のソースを返す場合、またはモードの予算が尽きた場合に停止し、その旨を明記してください。

大規模または分割可能なジョブでサブエージェントが利用可能な場合：references/parallel-research.md。

3 評価

各候補に基準を適用する。除外されたソースは理由とともに台帳に残ります。

含まれた各ソースについて記録すること：

• 評価（high、moderate、low、very-low）と具体的な懸念事項。この質問に対する適合性を評価し、評判ではありません：references/source-appraisal.md；
• リネージ（L1、L2、...）。ソースは、一つの起源にたどる場合にリネージを共有します：研究とそのプレプリント、プレス報道とフォローアップ、一つのデータセットに関する複数の論文、一つの報告書を言い換えた複数のページ。確実性は引用数ではなく、リネージ数に依存します。

4 抽出

各ソースについて、質問に関連するものをエビデンスアイテムとして記録します：ソースID、ロケーター、種類（quote、paraphrase、data）、テキスト。人口と状況、およびそれがどこまで一般化できるかを制限するものを含めてください。デフォルトではパラフレーズし、決定的な言葉だけを引用します。都合の良いことではなく、ソースが報告していることを記録します。

5 構築

一度に一つのソースではなく、ソースを横断して作業します。

1. 方法を選択する：質問とエビデンスに適合するように。定性または混合エビデンスにはテーマ別統合。多様な定量エビデンスには効果の構造化サマリーを用いたナラティブ統合。メタ分析は、研究が平均が意味を持つほど十分に類似している場合にのみ使用します。 references/synthesis-methods.md
2. エビデンスをそれが言うことによってグループ化する。ソースや共有語彙によってではなく。
3. 各グループを主張として書く：間違っている可能性のある文。「フィードバックのタイミング」はトピックです。「遅延フィードバックは保持タスクでは即時フィードバックより優れていたが、手続きタスクでは優れていなかった」は主張です。
4. エビデンスを両方向で添付する：それを支持するアイテムと、それに矛盾するアイテム。
5. 各矛盾をアイテムのreconciledフィールドで調整する：人口、尺度、用量、時間軸、比較、研究デザインの質、利害の違い。何も説明しない場合は、unexplainedと書いてください。調整されていない矛盾は上限を下げます。
6. 有意な研究と非有意な研究を単純に数えて決して比較しないこと。 方向、大きさ、範囲を報告してください。効果を報告または比較する前に、references/quantitative-evidence.mdを読んでください。
7. 正直に数えること：「14人の参加者のうち9人」、「5つの試験のうち3つ」であり、「ほとんど」ではありません。

決定が必要とするだけの主張を持ち、それ以上は持たないこと。読者がそれらを頭の中で保持できない場合、グループ化は完了していません。

6 評価

python scripts/ledger.py ceilings ledger.json

これは、各主張について、記録されたエビデンスが運べる最高の確実性と、それを制約するものを出力します：一つのリネージ、全文で読まれた確かなものがない、調整されていない矛盾、または推奨の下にある弱い主張。

次に判断します。各主張のcertaintyをその上限以下に設定し、バイアスのリスク、非一貫性、非直接性、不精確さ、およびおそらく不足しているエビデンスのために引き下げ、何がそれを設定したかを示す一文のrationale（理由）を付けてください。主張を一致するように表現してください：

確実性	表現
高い	「XはYを増加させる」
中程度	「XはおそらくYを増加させる」
低い	「XはYを増加させるかもしれない」
非常に低い	「XがYを増加させるかどうかは不明である」

ルール、定性および非研究エビデンス、作業例：references/certainty.md。

7 破壊的検証

読者が行う前に、結論を壊そうと試みてください。

python scripts/ledger.py keystones ledger.json

要石（キーストーン） とは、主張がなしでは成り立たないリネージです。それを取り除くと、主張はエビデンスを失うか、述べられたように評価できなくなります。次に、結論が依存する各主張について：

• 要石：各要石ソースを全文で再読すること。それが正しい場合、他に何が真実であるはずか、そしてそれはどこかで見られるか？
• 対立する説明：同じエビデンスの最良の代替説明（偶然、選択、交絡、測定、逆因果、利害関係のある情報源）を書くこと。二つを区別する観察に名前を付け、それを探すこと。
• 反転：台帳だけから、反対を期待する誰かが書くであろう結論を下書きすること。その下書きが弁護可能なところでは、主張は誇張されています。
• 移転可能性：エビデンスは、決定が関係する設定と同様の設定から来ていますか？そうでない場合は、間接的として扱い、評価を下げてください。
• 沈黙：主張が真実であれば存在するはずのエビデンスは何か、そしてそれは検索されたか？

これによって明らかになったものを台帳に入れてください（新しい矛盾するアイテム、変更された評価、狭められた主張）。何も見つからないことは、それが真実である場合には許容できる結果です。サブエージェントが存在する場合、このステップを台帳のみを与えられた新しい読者に任せてください。

8 作成

まず回答を。レポートには7つのパートがあります（迅速ブリーフでは方法を省略可）：

1. 結論：2～4文で回答を、その確実性を伝える表現で。
2. これが決定にとって何を意味するか：解釈と勧告、ラベル付きで。「行動しない」や「エビデンスはこれを決定できない」を正直な場合に含め、結論を変えるものは何かを示す。
3. 所見：主張ごとに小見出し、主張として書き、そのID（[C1]）、Certainty:行と理由、エビデンスと引用（[S3, S7]）、そしてそれが誰に当てはまるかを含める。
4. エビデンスが一致しない箇所、そしてその理由。
5. ギャップと限界：エビデンスの、そしてこの統合の。
6. これがどのように行われたか：質問、基準、検索、数、評価、方法。
7. 情報源：IDごとに引用されたすべての情報源。

エビデンスが許すところでは断定的に、許さないところでは平明に述べてください。すべての文を均等に曖昧にすることは、強い所見と弱い所見の違いを隠してしまいます。それは読者が最も必要とするものです。

9 再読

python scripts/ledger.py worksheet ledger.json

ワークシートは、そのロケーターで再読しなければならないエビデンスをリストします：すべての図表、すべての引用、要石からのすべてのもの。各ソースを開き、比較してください。次に結果を記録します：

python scripts/ledger.py mark ledger.json confirmed C1.s1 C1.s2
python scripts/ledger.py mark ledger.json mismatch C2.s1 --note "表3は0.30ではなく0.03を示している"

確認する前に、台帳とレポートの不一致を修正してください。再読せずにアイテムを確認済みとマークすることは、誤った引用を捕捉する唯一のチェックを無効にします。

次にチェックを実行し、報告されたものを修正し、両方がクリーンになるまで繰り返します：

python scripts/ledger.py check ledger.json
python scripts/ledger.py report report.md ledger.json

python scripts/ledger.py explain <CODE>は、なぜルールが存在するかを説明します。迅速モード以外では、必要なエビデンスが確認されていない場合、reportは失敗します。付録については、python scripts/ledger.py tables ledger.jsonがエビデンス表をレンダリングし、trace ledger.json C1は任意の主張のソースへのパスを示します。

最後に、ドラフトをreferences/quality-rubric.mdに対して採点し、合格点を下回るものを修正してください。

統合の更新

新しいエビデンスが到着したら、既存の台帳にソースを追加し、as_ofを新しい日付に設定し、抽出し、ceilingsとkeystonesを再度実行してください。新しいリネージは上限を引き上げる可能性があり、新しい矛盾は上限を引き下げる可能性があります。protocol.deviationsの下で何が変更されたかを記録し、レポートでどの結論が動いたか、そしてその理由を述べてください。

他人の統合を監査する

1. その暗黙の質問、基準、方法を再構築する。
2. その結論が依存しているものから始めて、引用をソースに対してチェックする。読んでいないソースが「実際に」何を言っているかを断言せず、未確認として報告する。
3. references/quality-rubric.mdで採点し、references/failure-modes.mdに対してテストする。
4. 最初に評決を報告し、次に何が有効か、何が支持されていないか、そしてそれを修正するための具体的な変更を重要度順に報告する。

参考ファイル

ファイル	読むタイミング
references/scoping-and-protocol.md	質問のフレーミング、レビュータイプの選択、プロトコルの作成時
references/source-appraisal.md	ソースの評価またはリネージの割り当て時
references/evidence-ledger.md	編集...

[翻訳のため省略]