voting-mcp

voting-mcp

原則に基づく社会的選択の集約を MCP ツールとして提供します。素朴な多数決に対する精度の向上を測定するベンチマークも備えています。

ほぼすべてのマルチエージェントシステムは、Counter(votes).most_common(1) で投票を集約し、選好の順位や信頼度を捨てています。voting-mcp は、実際の投票ルール（ボルダ、コープランド、コンドルセ、承認投票、STV、線形オピニオンプール）を呼び出し可能な MCP ツールとして提供します。それぞれの公理的な特性と、明示的に文書化された同票時の処理方法も備えています。さらに、多様な LLM のアンサンブルを推論用データセットで集約し、ブートストラップ信頼区間とともに精度を報告する、再現可能なベンチマークも含まれています。

このサーバーは純粋な計算のみを行います。stdio トランスポートを使用し、ネットワーク通信も、ファイルへの書き込みも、シークレットもありません。その設計により、OWASP MCP Top 10 に準拠しています。

インストール

# run the server directly (once published)
uvx voting-mcp

# or from source
git clone https://github.com/HrishiKabra/voting-mcp && cd voting-mcp
uv sync
uv run python -m voting_mcp.server

MCP クライアント（例：Claude Desktop の claude_desktop_config.json）に追加します。

{
  "mcpServers": {
    "voting": { "command": "uvx", "args": ["voting-mcp"] }
  }
}

ツール

各ツールは profile（{candidates, ballots}）を受け取り、同率の候補を隠さない、同率首位の候補全件を含む Result を返します。Result には、同票時の処理後の単独の winner（該当しない場合は null）、ranking、候補ごとの scores、および note が含まれます。

ツール	投票形式	備考
borda	順位付け	順位に基づく方式。コンドルセ基準と整合せず、クローンに敏感
copeland	順位付け	コンドルセ基準と整合するペアワイズ方式（勝利は+1、引き分けは+0.5）
condorcet	順位付け	ペアワイズの勝者を返します。循環がある場合は勝者なしを明示的に返します
approval	承認集合	最も多く承認された候補が勝者
stv	順位付け	単独勝者を選ぶ即時決選投票方式。クローンに強い
opinion_pool	分布	線形プール。信頼度を保持し、argmax 投票ではありません
plurality	順位付け	ベースライン（第1選択が最も多い候補）
majority	順位付け	厳密に50%超の場合に勝者を決定。それ以外は勝者なし
aggregate_rule	任意	rule 列挙値に基づいて振り分けます

同票時の処理方法は明示的なパラメーターです（デフォルトは lexicographic、ほかに none またはシード付きの random を指定できます）。

ベンチマーク

5 モデルのアンサンブル（OpenRouter 経由の OpenAI 互換クライアントを1つ含む）を ARC-Challenge で集約し、各ルールを素朴な多数決と比較します。

uv sync --extra bench
uv run python -m bench.fetch_arc --limit 200
# prints a cost estimate and STOPS; add --yes to actually call the API, --mock for a free dry run
uv run python -m bench.run_ensemble --dataset bench/datasets/arc_challenge.jsonl --limit 200 --yes
uv run python -m bench.compare --dataset bench/datasets/arc_challenge.jsonl --limit 200

すべての生の応答は bench/results/raw/ にキャッシュされます。再実行時に API が再度呼び出されることはないため、集約方法の調整は無料です。

結果

5 モデルのアンサンブル（gpt-4o-mini · gemini-2.5-flash-lite · deepseek-v3 · claude-haiku-4.5 · glm-4.7）、n = 200、ブートストラップ 95% 信頼区間。難易度の異なる 2 つのデータセットを使用しています。詳しい分析と両方のプロットは RESULTS.md をご覧ください。

MMLU-Pro（難問、ベースライン 73.5%）— 有意義な結果が得られたケース：

ルール	正解率	95% 信頼区間	多数決との差（対応あり）	p
opinion_pool	0.755	[0.695, 0.815]	+0.020 [−0.011, +0.052]	0.225
majority_vote (baseline)	0.735	[0.679, 0.788]	—	—
approval	0.701	[0.640, 0.757]	−0.035 [−0.063, −0.006]	0.014
stv	0.693	[0.630, 0.750]	−0.043 [−0.072, −0.015]	0.002
copeland	0.647	[0.580, 0.710]	−0.088 [−0.127, −0.052]	<0.001
condorcet	0.620	[0.550, 0.685]	−0.115 [−0.155, −0.079]	<0.001
majority (strict)	0.590	[0.520, 0.655]	−0.145 [−0.189, −0.105]	<0.001
borda	0.472	[0.405, 0.540]	−0.263 [−0.323, −0.206]	<0.001

Δ は、独立した信頼区間を見比べるのではなく、設問ごとの正解率の差に対する対応ありブートストラップで検定しています（同じ設問を使うため、難易度の影響が相殺されます）。

率直な結果： 価値があるのは「高度な投票方式が多数決に勝つ」ことではありません。確信度を保持するルール（opinion_pool）は、回答が不確かなときに優位になることです（+2.0pp。ベースラインを上回った唯一のルールですが、n=200 では示唆的な傾向にとどまり、有意差はありません。対応あり p=0.225）。一方で、確率分布を無理に完全な順位付けに変換すると、明確に性能が落ちます。すべての順位付けルールが対応あり p≤0.014 でベースラインを下回り、選択肢が 10 個ある borda は 0.472 まで低下します。これは、順位の下位部分の大半がノイズだからです。確信度を集約し、捨てないでください。ARC-Challenge（ベースライン 96.8%、上限に近い）では差は見られず、有意に異なるルールはありません。詳細は RESULTS.md をご覧ください。

開発

uv run pytest -q
uv run ruff check .
uv run mypy --strict src
# exercise the tools in the MCP Inspector:
npx @modelcontextprotocol/inspector uv run python -m voting_mcp.server

注：このリポジトリを iCloud 同期フォルダー（例：~/Desktop）内に置くと、iCloud が .pth ファイルを重複生成し、編集可能インストールが断続的に失敗することがあります。テストでは pythonpath=src を使用します。インポートに失敗する場合は、サーバーを PYTHONPATH=src で実行するか、リポジトリを同期フォルダーの外に移動してください。

関連研究

ここでのルールの選択は、投票ルールの設計に関する著者の研究から着想を得ています： 社会厚生とその先のための投票ルールの最適化（AAMAS）。この研究では、有権者が実際に選好を表明する方法を踏まえ、どの集約ルールが厚生を最大化するかを問いかけます。このプロジェクトでは、同じ視点を LLM アンサンブルに適用しています。ベンチマークの結果は、確信度を保持する集約（線形意見プール）が有効であり、基数的な信念を序数的な順位付けに無理に変換すると、情報が損なわれることを示しています。

ライセンス

MIT