Literature Review Council

マルチエージェント文献レビュー パイプライン

Google ADK（Agent Development Kit）を使用して構築された、マルチエージェント文献レビュー パイプラインです。YAML 設定に基づき、専門エージェントを調整してサブトピックを反復的に調査します。各トピックについて、学術的な視点と実務的な視点から検索し、ピアレビューのアンサンブルで研究成果を評価して、十分な根拠に基づくレポートをまとめます。

Kaggle の「AI Agents: Intensive Vibe Coding Capstone」に提出したキャップストーンプロジェクトとして構築されました。

mcp-name: io.github.Ravicha2/lit-review-council

開発の動機

文献レビューは息苦しい作業です。何百もの論文、相反する主張、そして情報のノイズの中から明確なシグナルを見つけるのは困難です。Andrej Karpathy の LLM Council は、マルチエージェントによる議論が単一のプロンプトよりも鋭い回答を引き出すことを示しました。このプロジェクトは、その知見を研究分野に応用しています。

複雑なトピックを調査する LLM には、多様な根拠の不足と自己優遇バイアス（自身の出力を優先する傾向）という 2 つの問題があります。

このパイプラインは、次の方法でその両方に対処します。

1. 階層型オーケストレーション：プランナーエージェントが、設定された研究トピックを複数のウェーブからなる実行グラフに分割します。基礎的な概念（ウェーブ 1）は並列で実行し、統合に依存するトピック（ウェーブ 2）は、ウェーブ 1 から抽出したコンテキストを使って順次実行します。
2. 情報源の分離：トピックごとに、独立した 2 つのトラックを設け、それぞれにエクスプローラー（検索）エージェントとレポーター（執筆）エージェントを配置します。学術トラックでは、ArXiv、OpenAlex、学術出版社を検索します。実務者トラックでは、GitHub とエンジニアリング文書を検索します。
3. ピアレビューアンサンブル：3 人のレビュー担当者（研究者、エンジニア、中立者）が、匿名化されたレポートを評価します。ボルダ方式の投票で順位を集計するため、特定のレビュー担当者が結果を支配することはありません。
4. ハルシネーション対策のガードレール：統合エージェントの出力を解析し、検証します。(Author, Year) や [1] のような対応する出典のない引用は却下されます。最終レポート内のすべての URL が元の参照情報に存在する必要があり、存在しない場合は実行を再試行します（最大 2 回）。ブログ／フォーラム階層の情報源が 50％を超えると、ブログ階層の比率チェックで警告します。

セットアップとインストール

PyPI と MCP Registry に公開されています。クローンや手動設定は不要です。

1. MCP Registry（推奨、1 コマンド）

このサーバーは MCP Registry に登録されているため、1 つのコマンドでインストールできます。JSON の編集や設定ファイルは不要です。

Claude Code：

claude mcp add lit-review-council \
  -e OPENROUTER_API_KEY=sk-or-your-key \
  -e GITHUB_TOKEN=ghp_your-token \
  -e TAVILY_API_KEY=tvly_your-key \
  -- uvx lit-review-council

VS Code： MCP Registry で「lit-review-council」を検索し、インストールをクリックしてください。または、MCP Registry の掲載ページを開き、VS Code にインストールをクリックしてください。

その他の MCP クライアント： 下記のセクション 2 をご覧ください。

接続すると、lit_review_council_instructions プロンプトを利用して、AI エージェントをレビューのワークフロー全体に沿って案内できます。

2. 手動設定（Claude Desktop、Cursor など）

クライアントの MCP サーバー設定に、次の内容を追加してください。

{
  "mcpServers": {
    "lit-review-council": {
      "command": "uvx",
      "args": ["lit-review-council"],
      "env": {
        "OPENROUTER_API_KEY": "sk-or-your-key",
        "GITHUB_TOKEN": "ghp_your-token",
        "TAVILY_API_KEY": "tvly_your-key",
        "OPENALEX_API_KEY": "your-key"
      }
    }
  }
}

クライアント	設定パス
Claude Desktop（Mac）	~/Library/Application Support/Claude/claude_desktop_config.json
Claude Desktop（Win）	%APPDATA%\Claude\claude_desktop_config.json
Cursor	.cursor/mcp.json

3. ローカル開発環境のセットアップ

git clone https://github.com/Ravicha2/lit-review-council && cd lit-review-council
cp .env.example .env   # fill in your keys
uv run python main.py --config topics.yaml --output okf_output --question "Your Research Question"

環境変数

変数	用途	必須
OPENROUTER_API_KEY	OpenRouter 経由の LLM アクセス	はい
GITHUB_TOKEN	実務者トラック（GitHub 検索）	はい
TAVILY_API_KEY	両トラックでのウェブ検索	はい
OPENALEX_API_KEY	学術トラック（OpenAlex API）	いいえ
ENG_MODEL	エンジニアエージェント用のモデル	いいえ（デフォルト：openrouter/moonshotai/kimi-k2.6）
RESEARCH_MODEL	研究エージェント用のモデル	いいえ（デフォルト：openrouter/z-ai/glm-5.1）
JUDGE_MODEL	レビュー担当者と統合エージェント用のモデル	いいえ（デフォルト：openrouter/deepseek/deepseek-v4-pro）

アーキテクチャ

パイプラインは4 つのステージで構成され、並列処理と逐次的な依存関係のバランスを取るため、トピックを2 つのウェーブに分けて実行します。

なぜ 2 つのウェーブなのですか？

すべての調査トピックが独立しているわけではありません。「真理維持システム」のような基礎概念など、並列して調査できるトピックがある一方で、「TMS を使ったマルチエージェントの連携」のように、先行トピックから統合された理解に依存するトピックもあります。

プランナーエージェントは topics.yaml を読み込み、トピックを次のように分類します。

• ウェーブ 1 — 並列実行できる、独立したトピックです。このウェーブのすべてのトピックは、ステージ 1→2→3 のパイプライン全体を同時に進みます。
• ウェーブ 2 — 逐次実行する、依存関係のあるトピックです。これらのトピックを正確に調査するには、ウェーブ 1 から抽出したコンテキストが必要です。

ディスティラーによるウェーブ間の引き継ぎ

ウェーブ 1 の完了後、ディスティラーエージェントはウェーブ 1 のトピックファイルを読み込み、基礎的な調査結果を簡潔にまとめます。この抽出されたコンテキストは、追加の背景情報としてウェーブ 2 のすべてのトピックのプロンプトに挿入されます。これにより、ウェーブ 2 のエクスプローラーとレポーターはゼロから調査を始めるのではなく、検証済みのウェーブ 1 の結論を土台に作業できます。

これにより、重複する検索を防ぎ、最終的な OKF バンドル全体の一貫性を高めます。

ステージの概要

Stage 0 (Orchestration)
├── Planner agent organizes YAML topics into Wave 1 (parallel) and Wave 2 (sequential)
└── Distiller agent summarizes completed Wave 1 topics to provide prior context to Wave 2

Stage 1 (Parallel Fan-out per Topic)
├── Academic Track (SequentialAgent)
│   ├── academic_explorer  → searches ArXiv, OpenAlex, Tavily (scholarly domains)
│   └── academic_reporter  → writes Researcher report with structured references
└── Practitioner Track (SequentialAgent)
    ├── practitioner_explorer → searches GitHub, Tavily (engineering domains)
    └── practitioner_reporter → writes Engineer report with structured references

Stage 2 (Peer Review Ensemble per Topic)
├── researcher_reviewer  → ranks anonymized reports (Researcher perspective)
├── engineer_reviewer    → ranks anonymized reports (Engineer perspective)
└── technical_reviewer   → ranks anonymized reports (Neutral perspective)
    → Borda-count tally → winning report selected

Stage 3 (Synthesis & Persistence)
├── synthesis agent → condensed final brief with YAML frontmatter
│   → citation validation loop (rejects hallucinated/dangling URLs, retries up to 2x)
└── Writes out to an interconnected Markdown OKF bundle (index.md and topic files)

検索プロバイダー

プロバイダー	ドメイン	使用者
ArXiv API	arxiv.org	学術エクスプローラー
OpenAlex API	openalex.org	学術エクスプローラー
Tavily (scholarly)	acm.org, ieee.org, springer.com, sciencedirect.com, nature.com, science.org, wiley.com	学術エクスプローラー
GitHub API	github.com	実務エクスプローラー
Tavily (engineering)	github.com, docs.microsoft.com, aws.amazon.com, cloud.google.com, medium.com, dev.to	実務エクスプローラー

すべてのプロバイダーで、429/5xx エラーに対して指数バックオフを伴う tenacity のリトライを使用します。

ソースのティア

すべての参考資料を、次の 4 つのティアのいずれかに分類します。

• peer_reviewed: ArXiv のプレプリント、ACM/IEEE の論文、会議録
• established_project: 十分な採用実績（スター数、活発なメンテナンス）がある GitHub リポジトリ
• vendor_doc: 企業やプロジェクトの公式ドキュメント
• blog_or_forum: Medium、個人ブログ、Stack Overflow、Reddit

引用ソースの半数を超えるものが blog_or_forum ティアの場合、統合ステップで警告が表示されます。

出力

パイプラインは、可能な場合はウェーブに分けて実行しながら、各トピックについてすべてのステージを実行します。完了すると、指定された出力ディレクトリに相互に関連付けられた Markdown バンドル（OKF 形式）を生成します。このバンドルには、各トピックの個別ファイルへのリンクをまとめた index.md が含まれます。