MetaScreener: 複数のオープンソースLLMを合議させてシステマティックレビューのスクリーニングを自動化する

スクリーニングのどこを機械に渡すのか

システマティックレビューの最初の関門は、検索で集まった数千件のタイトルと抄録を読み、事前に決めた適格基準に照らして残すか捨てるかを判断する作業である。二重スクリーニングが推奨される場面では同じ判断を二人が独立に行うため、コストは件数に比例して膨らむ。MetaScreenerはこの一次ふるいをLLMに任せ、確信度の高いものは自動判定、低いものだけを人間に戻す。対象読者はメタアナリシスやエビデンス統合を日常的に行う研究者で、PICO/PEO/SPIDERのような構造化された基準をすでに持っていることが前提になる。基準が曖昧なままでは、後述するルールエンジンも要素合議も機能しない。

Hierarchical Consensus Networkという4層構造

READMEが示すアーキテクチャはHierarchical Consensus Network（HCN）と呼ばれる4層のパイプラインである。第1層は推論層で、アップロードされた.ris/.bib/.csv/.xlsxを読み、DeepSeek、Qwen、Llama、KimiなどのモデルをOpenRouter経由で並列に走らせる。第2層はルールエンジンで、自動除外のためのハードルールとスコア減点のソフトルールを適用する。第3層でCalibrated Confidence Aggregation（CCA）とElement Consensus Scoring（ECS）が生のスコアを確率に写像し、P/I/C/O単位の一致度を計算する。第4層のDecision RouterがTier 0からTier 3へ振り分け、Tier 0はハードルールによる除外、Tier 1とTier 2は自動判定、Tier 3だけが人間のレビューに回る。単一モデルの出力をそのまま使わず、複数モデルの合議とルール適用を挟んでから最終判定に至る流れが明確に定義されている。

信頼度キャリブレーションと能動学習の位置づけ

このツールの中心的な主張は、LLMの生のスコアをそのまま確率として扱わないことにある。READMEによればPlatt scalingまたはIsotonic regressionによる事後キャリブレーションで、生スコアを真の確率に写像する。これによりTier 1とTier 2の閾値設定が、モデルの自己申告する確信度ではなく統計的な意味を持つ。加えて人間のフィードバックを取り込み、モデルの重みを再調整する能動学習ループが用意されている。ここは評価が分かれる設計だ。キャリブレーションはラベル付きの検証データがあって初めて意味を持つ。レビュー開始時点で正解ラベルが存在しないのが普通であり、最初の数百件を人間が判定して学習データを用意する運用を想定していると読める。再現性についてはtemperature=0.0、seed=42、全判定に監査証跡を残すとREADMEは説明しており、判定の追跡可能性を重視している。

導入: pip、Docker、ソースからの3経路

最も短い経路はpip install metascreenerを実行し、python -m metascreenerでWeb UIを起動する方法である。http://localhost:8000でVue 3製の画面が開く。Pythonを入れたくない場合はdocker pull chaokunhong/metascreener:latestでイメージを取得し、docker run -p 8000:8000 -e OPENROUTER_API_KEY="sk-or-v1-your-key-here" chaokunhong/metascreenerとして起動する。開発者向けにはuvとNode.js 18+が必要で、git cloneの後にuv sync --extra devを実行し、python run.pyでFastAPIバックエンド（8000番）とVite開発サーバー（5173番）を同時に立ち上げる。APIキーの設定はWeb UIのSettingsページに貼るか、export OPENROUTER_API_KEYで環境変数に渡す。前提はPython 3.11以上とOpenRouterのAPIキーで、キーは無料登録後に従量課金で発行される。

モデル選択とコストのトレードオフ

対応モデルはOpenRouter経由で15種類あり、Flagship（DeepSeek V3、Qwen 3、Kimi K2.5）、Strong（Llama 4 Maverick、GLM 5、MiniMax M2.7、Nous Hermes 4、Nvidia Nemotron、Cogito 671B、AI21 Jamba）、Lightweight（Gemma 3 27B、Mistral Small 4、Phi 4）の3階層に分類されている。READMEが示すプリセットは3つで、Balancedは4モデルで1論文あたり約0.005ドル、Precisionはthinking系2つと大規模2つで約0.009ドル、Budgetはアンカー1つと高速モデル3つで約0.003ドルとされている。ここで注意したいのは、コストがモデル数と論文数の積で効いてくる点だ。1万件のタイトル・抄録をPrecisionプリセットで処理すれば、READMEの単価が正しければ約90ドルになる。予算プリセットとの差は3倍であり、合議の多様性をどこまで買うかの判断が費用に直結する。単価はあくまでREADMEの記載値であり、実際の請求額はプロバイダの価格改定で変わる。

向かない場面と代替手段

MetaScreenerが適さないのは、まずAPIキーを外部に出せない環境である。推論はすべてOpenRouter経由で行われるため、未発表データや機密性の高い研究計画を扱う場合、外部APIへの送信が許容されるかを先に確認する必要がある。オフラインで完結させたいなら、同じPythonで書かれたスクリーニング支援ツールであるASReviewを検討する価値がある。ASReviewはLLMの合議ではなく、能動学習と関連性フィードバックによる優先順位付けで人間の読む順番を最適化する。判定を自動化するのではなく、人間が読む件数を減らす方向の設計であり、判定の最終責任を常に人間に残す。モデルの合議と確率キャリブレーションが欲しいのか、読む順番の最適化だけで足りるのかで選択は変わる。もう一つの限界は、PICO/PEO/SPIDERに落とせない基準、たとえば方法論の質や倫理記述の有無だけで除外するようなレビューでは、要素合議の仕組みが活かしにくいことだ。

ライセンスと保守の見取り図

ライセンスはApache-2.0で、商用利用や改変、再配布が許容される寛容型である。ただしApache-2.0は特許条項と変更表示の義務を含むため、フォークして配布する場合は変更点の明示が必要になる。これは法的助言ではないので、実際の運用は所属機関の規則に従って確認してほしい。保守の観点では、既定ブランチmainへの最終pushが2026年6月11日、直近のリリースはfp-audit-protocol-v1.0（2026年5月8日）で、その前がv2.0.0a4（2026年2月26日）とv2.0.0a3（2026年2月25日）である。安定版の系譜がまだ整っておらず、2.0系はアルファ表記のままである点は導入判断に影響する。fp-audit-protocolという名称から、偽陽性の監査手順を固定する動きが見えるが、READMEにはこのプロトコルの詳細な説明がない。研究の再現性を重視するなら、このリリースが何を固定したのかをリポジトリ側で直接確認する必要がある。

編集部の結論

すでにOpenRouterのAPIキーを持ち、スクリーニング作業の一次ふるいを自動化したい研究チームには向いている。逆に、APIキーを外部サービスに渡せない環境や、判定根拠を完全にオフラインで再現する必要がある規制下のプロジェクトには適さない。導入前に確認すべきは、自分のレビュー課題でPlatt/Isotonicキャリブレーションが意味を持つだけのラベル付きデータが手元にあるか、そしてTier 3に落ちる件数が人間の処理能力に収まる範囲かどうかである。

公式情報源

1. ChaokunHong/MetaScreener on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases