studydiff

StudyDiff

2つの科学研究が異なる結論に至る理由を理解できます。
すべての主張は出典と照合して検証済みです。

ライブデモ · クイックスタート · 仕組み · 例 · MCP サーバー · ロードマップ · コントリビューション

---

適切に実施された2本の論文が、正反対の結論に至ることはよくあります。通常、その理由は一方が間違っているからではなく、方法論上の違い（細胞型、用量、追跡期間、解析方法など）にあります。その違いは、読者が方法のセクションを手作業で掘り下げて見つけなければなりません。StudyDiff がその作業を担います。 2つの研究を与えると、それぞれの研究デザインを抽出し、食い違いを説明し得る差異を明らかにします。そして何より重要なのは、すべての記述を出典の本文に基づかせるため、研究結果を捏造することがありません。

実験を計画する前に、相反する2本の論文のどちらを信頼するか判断するベンチサイエンティスト向けに作られています。

他との違い

多くの「AI文献」ツールは流暢な回答を生成し、ユーザーにそれを信頼するよう求めます。StudyDiff はその逆です。

• まず根拠を示し、あとはユーザーに委ねます。 上部には研究デザインの違いを表示し、その下には各値を裏付ける原文の文を示します。検証済みの値をクリックすると、論文の本文中で該当する文がハイライトされます。
• 推測はしません。 出典に記載されていない項目は、推測せず、報告なしと表示します。
• 自ら検証します。 決定論的な根拠確認（判定役として2つ目の LLM を使いません）によって、抽出したすべての値と説明が、原文からの引用と追跡可能な数値によって裏付けられていることを確認します。検証に失敗したものは、理由として使われる前に重要度が引き下げられます。
• できないことを把握しています。 それは測定によって確かめられています。独立した2組のベンチマークセットで評価し、2つ目のセットは評価時まで未使用とし、一度だけ採点しました。以下をご覧ください。

機能するのか？測定に基づく回答

StudyDiff は以前、異なる設計上の次元を順位付けし、最上位のものを意見の不一致の原因と考えられるものとして提示していました。それを検証するベンチマークを構築しましたが、機能しません。

文献によって意見が食い違った理由がその後明らかになった、記録済みの矛盾が15件あります。各ラベルにはそれぞれ引用が付いており、正解率の数値が出る前に、先入観なしにデータセットを構築しました。StudyDiff が最上位に挙げた原因を評価した結果は次のとおりです。

Top-1 accuracy (strict)      13.3%  (95% CI 3.7-37.9%)   [2/15]
Baseline "always say assay"  13.3%  (95% CI 3.7-37.9%)   [2/15]
                             → discordant on 0 of 15 cases
Oracle ceiling (reachable)   66.7%  (95% CI 41.7-84.8%)  [10/15]
Non-assay-labelled cases      0.0%  (95% CI 0.0-22.8%)   [0/13]

順位付けは固定された事前設定（src/compare.mjs の DRIVER_RANK）であり、assay が他のすべてより上位です。2本の論文では、ほとんどの場合、手法が多少異なるため、ほぼ常に assay が異なり、15件中13件でそれが選ばれました。そして的中した2件は、どちらも assay とラベル付けされたケースです。単一の答えを当てるのと同程度というだけではなく、このデータセットのすべてのケースで、挙動が完全に同じです。

まずグラウンディングを修正する（フェーズ2）ことで、その言い訳も通用しなくなりました。誤検出による除外26件のうち20件を復元したことで、オラクル上限は33％から67％へ倍増しました。確立された原因が候補として利用できるケースは、15件中5件から10件に増えましたが、トップ1の正解率はまったく変わりませんでした。順位付けシステムは正解を新たに5回提示されたのに、そのどれも選びませんでした。

その結果、何が変わったか： アプリは主要な原因を挙げなくなりました。異なる次元を順位なしのリストで提示します。そのリストには情報価値がある（15件中10件に確立された原因が含まれる）一方、順位付けには意味がないためです。どれを選ぶかは、このツールが持っていないドメイン知識を必要とします。

今も変わらない点： どの次元が異なるか、どの次元が同一か（除外済み）、そして各値の根拠となる逐語的な文です。これらはどれも順位付けに依存しません。

2つ目のセットで確認したブラインド評価

その15件はすでに2つのフェーズにわたって読み込まれていました。失敗を分析し、スパンを再監査していたため、修正後の数値はすべて 開発セット の精度であり、ブラインド評価の測定値ではありません。そこで2つ目のセットを作成し、一度だけ測定しました。

eval/cases-heldout.json は、記録された矛盾をさらに15件集めたものです。ケースを1件も選ぶ前に作成し、コミットしたプロトコル（eval/HELDOUT-PROTOCOL.md）に従ってキュレーションしました。キュレーターは開発セットのケースごとの失敗を知らされておらず、分野も意図的に変えています。微生物叢、海洋生態学、毒性学、心理学、集中治療、腫瘍学、感染症です。開発セットと論文も矛盾も共有していません。selftest がこれを機械的に検証します。

Top-1 accuracy (strict)      13.3%  (95% CI 3.7-37.9%)   [2/15]
Baseline "always say assay"  20.0%  (95% CI 7.0-45.2%)   [3/15]
                             → discordant on 1 of 15 cases
Oracle ceiling (reachable)   73.3%  (95% CI 48.0-89.1%)  [11/15]
Non-assay-labelled cases      0.0%  (95% CI 0.0-24.3%)   [0/12]

未知のデータでは、事前分布による予測のスコアは、定数予測を下回ります。ちょうど1件の差です。信頼区間はほぼ完全に重なり、2つの戦略が異なるのは15件中1件だけです。したがって、正直に言えるのは、毎回 assay と推測する方法と区別できないままだということであり、劣っているということではありません。

変わらないのは最後の行です。両方のセットを通じて、確立された原因が assay 以外だった25件について、事前分布はそのいずれも特定できませんでした。 また、ここでの上限値は開発セットの66.7%より高く、73.3%です。つまり、抽出によって正解がランキングモデルの前に提示される頻度は上がりましたが、それが選ばれる頻度は上がりませんでした。これは、開発ループが一度も見ていないデータで再現されたPhase 1～2の結論であり、結論をより強固にできる唯一の方法です。

この数値はそのまま報告し、開発セットの数値と合算することは決してありません。これらを合計して「n=30」の数値にすると、すでに読み込んだデータをブラインドデータとして再び見せかけることになります。この結果に基づいて src/ の内容を変更したものはありません。このセットは事前登録された単一の評価条件で一度取得しましたが、スコアリングは一度で完了したわけではありません。最初の実行では1本の論文の取得に失敗し、n=14と報告されました。その後、その論文を取得してセット全体をスコアリングしました。両方の数値、スコアリング前の敵対的検証で発見・修正された16件の不備、および各ラベルの根拠は、要約して省略することなく、ファイル固有の来歴ブロックに記録されています。

npm run eval:heldout            # the blind number, offline and free
npm run eval:selftest:heldout   # set integrity, incl. zero overlap with the dev set

手法全体、事前登録された判断、誤った予測すべてについては、eval/README.md と eval/PHASE2.md をご覧ください。ベンチマークセットは、開発用の eval/cases.json と、ホールドアウト用の eval/cases-heldout.json です。

npm run eval            # offline, free, no API key — regenerates the numbers above
npm run eval:selftest   # validates the harness maths and set integrity

eval/cache/ と eval/cache-heldout/ は意図的にコミットされています。ビルド出力ではなく、エビデンスです。公開されている数値は、鵜呑みにするのではなく、リポジトリ内の成果物から再現できます。

クイックスタート

60秒以内で、APIキーもネットワークも不要です。

git clone https://github.com/nickjlamb/studydiff && cd studydiff
npm install
npm run demo                        # explains a real, famous contradiction
npm run demo -- resveratrol-sirt1   # a second worked example
npm run demo -- treg-stability      # a third: Treg lineage stability

ウェブアプリを実行します。

cp .env.example .env    # add ANTHROPIC_API_KEY for live comparisons
npm run serve           # http://localhost:4173

組み込みのサンプルはキャッシュ済みデータで実行されるため、キーは不要です。ライブデータと比較するには、キーを追加し、PMID / DOI、PDF をアップロード、または 貼り付け の入力欄を使います。

仕組み

flowchart LR
  IN["Two papers<br/>PMID · DOI · PDF · text"] --> R["Retrieve<br/>PubMed / PMC / PDF"]
  R --> E["Extract<br/>Claude → structured study cards"]
  E --> V["Verify<br/>deterministic grounding"]
  V -- "ungrounded → not reported" --> E
  V --> C["Compare<br/>divergent vs. shared design"]
  C --> X["Present<br/>divergent dimensions + ruled out"]

1. 取得 — PubMed/PMC クライアントが、全文から抄録へのフォールバック機能を備え、どこまで読み込んだかをタグ付けします（fulltext / abstract / pasted）。アップロードされた PDF はサーバー側でテキストを抽出します。
2. 抽出 — Claude が各論文を所定の 研究カード（種、モデル、アッセイ、用量、タイミング、エンドポイント、サンプルサイズ、統計、知見、限界）に変換します。すべての項目に逐語的な根拠の引用が付き、記載のない項目は not reported になります。
3. 検証 — まず根拠を確認します。引用が出典に含まれていない値や、数値の出所をたどれない値は、not reported に格下げされます。StudyDiff は検証していない事実を引用できません。
4. 比較 — 決定論的に比較します。両方の論文に記載されている設計の側面、そのうち異なるもの、同一のものを判定します。相違は設計の側面に対するトークンの重なりで検証し、結論そのものは厳密な不等式で比較します。これは、手法のリストでは 内容 が重要なのに対し、結論では 極性 が重要だからです。
5. 提示 — 相違する側面を順位付けせずに示し、それぞれについて両方の論文の値と、その根拠となる逐語的な文を提示します。同一の側面は明示的に 除外 します。StudyDiff は、どちらかを原因として指名しません。測定した結果、原因ではないとわかりました。

この保証を支えているものは2つあります。API キーがサーバーの外に出ないこと、そして検証が決定論的であることです。根拠の確認と比較にはモデルの判断が一切関与しないため、同じ検証済みのエビデンスからは、常に同じ相違点が導かれます。

Claude を使う理由

StudyDiff の信頼性は、Claude を使っていることだけでなく、Claude の使い方に由来します。

• ツール使用による構造化抽出。 各論文は、Claude（Sonnet）の強制適用されるツールスキーマを通じて研究カードに変換されます。そのため、すべての項目が検証済みの状態で返され、逐語的な根拠の引用 が付きます。自由形式のテキスト解析や、「おおむね JSON」の失敗はありません。
• 主張をエビデンスに対応付ける推論。 Claude は方法や抄録の文章を読み、設計の値と、その根拠となる正確な文の両方を特定します。これは、非構造化の論文を比較可能で監査可能なカードに変換するうえで難しい部分です。
• Claude が提案し、根拠確認で選別。 StudyDiff は LLM を判定者として使いません。決定論的なチェックで Claude の出力を出典と照合し、裏付けのない内容は表示する前に格下げします。Claude のツール使用による抽出と、LLM を使わない検証を組み合わせることで、ツールが自身の出力を信頼できるようになり、LLM を評価者として使う際によくある落とし穴を回避できます。
• Claude Code で構築。 パイプライン、UI、堅牢化、デプロイを含むアプリ全体が、単一のエージェントループで Claude Code を使って反復的に構築されました。

例

質問	論文	StudyDiff が見つけたこと
マウスモデルはヒトの炎症を再現しますか？	Seok 2013 と Takao & Miyakawa 2015	同じデータセットから正反対の結論に至っており、その違いは 遺伝子選択戦略 に起因します。
レスベラトロールは SIRT1 を活性化しますか？	Howitz 2003 と Beher 2009	アッセイのアーティファクト — Fluor de Lys ペプチド基質と天然基質の違いです。
生体内で Treg 系譜は安定していますか？	Zhou 2009 と Rubtsov 2010	T 細胞をめぐる画期的な論争です。系譜が安定か不安定かは、運命追跡法 の違いに起因します。

3つすべてをオフラインデモとして利用できます（npm run demo / npm run demo -- resveratrol-sirt1 / npm run demo -- treg-stability）。

使用方法

• Web アプリ（npm run serve） — サンプル、PMID/DOI 検索、PDF のアップロード、またはテキストの貼り付けができます。パイプラインの各ステップがリアルタイムで表示され、根拠のある値をクリックすると、ソース内で該当箇所がハイライト表示されます。また、各値を裏付ける一字一句そのままの文章をすべて含む、再現可能な Markdown レポートをエクスポートできます。
• MCP サーバー（npm run mcp） — Claude や任意のエージェントから、矛盾分析エンジンを直接呼び出せます。MCP サーバーを参照してください。
• CLI — node src/cli.mjs --q "Does resveratrol activate SIRT1?" 12939617 19843076
• デプロイ — DEPLOY.md（Railway + カスタムドメイン）を参照してください。

MCP サーバー

StudyDiff のエンジンは Model Context Protocol サーバーでもあるため、エージェントはブラウザーを使わず、同じ根拠付けパイプラインを通じて、2 本の論文がなぜ食い違うのかをツール呼び出しで尋ねられます。

公式 MCP Registry には io.github.nickjlamb/studydiff として、npm には studydiff-mcp として公開されています。

ツール	機能
compare_studies(paperA, paperB, question?)	2 本の論文に対して完全なパイプラインを実行します。各論文には {id}（PMID または DOI）、あるいは {citation, text} を指定します。ANTHROPIC_API_KEY が必要です。
compare_example(example)	キャッシュ済みの実行例を実行します — API キーもネットワークも不要です。根拠付きの出力を確認する最も手軽な方法です。
list_examples()	組み込みの実行例を一覧表示します。

Web アプリがエクスポートするものと同じ、監査可能なレポートを返します。判定、異なる設計上の側面（順位付けなし）と同一の側面（除外済み）、各値とそれを裏付ける一字一句そのままの文章、検証件数、そして意見の相違を解決するために必要な証拠が含まれます。根拠のないフィールドは推測せず、報告なしとして返されます。また、このツールは勝者を選んだり、主な要因を指名したり、計算していない確信度を報告したりすることはありません。

Claude Code に追加します：

claude mcp add studydiff -- npx -y studydiff-mcp

…または Claude Desktop（claude_desktop_config.json）に追加します：

{
  "mcpServers": {
    "studydiff": {
      "command": "npx",
      "args": ["-y", "studydiff-mcp"],
      "env": { "ANTHROPIC_API_KEY": "sk-ant-..." }
    }
  }
}

compare_studies の実行にのみ ANTHROPIC_API_KEY が必要です。設定しなくても、list_examples と compare_example は引き続き動作します — キャッシュ済みのサンプルはキーもネットワークも不要で実行できます。（ローカルのクローンから実行する場合は、コマンドを node /absolute/path/to/studydiff/src/mcp.mjs に置き換えてください。）

あとは、次のように尋ねるだけです：

studydiff を使って PMID 19633673 と 20929851 を比較してください — なぜ食い違うのですか？

キーをすぐに用意できない場合は、list_examples を実行してから compare_example("treg-stability") を実行すれば、完全にオフラインで動作します。

プロジェクト構成

src/ncbi.mjs        PubMed / PMC retrieval (+ DOI resolution, source-depth tagging)
src/pdf.mjs         PDF text extraction (pure JS)
src/extract.mjs     Claude tool-use → structured study cards
src/grounding.mjs   deterministic verification (OpenGATE)
src/compare.mjs     divergence detection (divergent vs. shared design dimensions)
eval/               driver-ranking benchmark: two sets of 15 cited contradictions (dev + held-out) + scorer
src/gaps.mjs        bounded "observed across these papers"
src/pipeline.mjs    orchestration: retrieve → extract → verify → compare
src/report.mjs      shared Markdown report (answer, drivers, quotes, verification)
src/server.mjs      web server + streaming API (+ rate limiting, caching)
src/mcp.mjs         MCP server: compare_studies / compare_example / list_examples
public/index.html   single-file dashboard UI
fixtures/           cached real papers for the offline demos

ロードマップ

キーワード検索と結果選択機能、バッチ比較、3 本以上の論文の比較が、今後取り組む項目です。ベンチマークは完了しており、ブラインド評価でも結果は維持されたため、次に取り組むのは機能の追加ではなく精度です。測定された上限を引き上げるための抽出の改善と、決定論的な根拠付けでは検出できない、文章による誇張を見つける含意チェックを行います。試行済みで取りやめた項目も含む全リストは、ROADMAP.md を参照してください。

コントリビューション

コントリビューションを歓迎します — セットアップ方法と、信頼性の保証を維持するための不変条件については、CONTRIBUTING.md を参照してください。

来歴

StudyDiff は、Anthropic のハッカソン Built with Claude: Life Sciences（Builder トラック）向けに開発されました。このリポジトリ内のアプリケーションコードはすべて、イベント開催中に一から作成されました。根拠付けには OpenGATE を、PDF の抽出には unpdf を使用しており、どちらも公開済みの依存関係です。検索には公開 NCBI E-utilities を使用し、抽出には Claude API を使用します。

ライセンス

MIT © Nick Lamb