llm-council について
llm-councilは、複数モデルによる合議で意思決定を検討するスキルです。重要な計画やアーキテクチャの判断に向け、独立回答、匿名評価、議長モデルによる統合を行い、記録を検索可能なwikiに保存できます。
主な機能
- 013段階の合議プロセス
- 02モデルによる並列個別回答
- 03匿名回答の順位付け
- 04議長モデルによる統合
- 05プロバイダーとモデルの選択
- 06記録のwiki保存
活用シーン
- 01重要な計画のレビュー
- 02アーキテクチャ案の比較
- 03矛盾する学習ルールの解決
- 04後で検索するための議論保存
MCP 対応
providers MCP サーバーの run_provider_task ツールを呼び出し、合議の実行やプロバイダー状態の確認ができます。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/llm-councilを入力して読み込まれたか確認します。
同梱ファイルscripts/council.js
詳細
LLM Council
Anthropic および OpenAI 互換プロバイダーを使用する、Karpathy の LLM Council パターンです。
使用する場面
- 重要度の高い計画のレビュー（
/planが N ファイルのしきい値を超える場合） - 学習ルールが競合した場合 → 投票によって再解決
- ユーザーが
/council "<query>"または/wiki councilを実行する場合 - 複数の視点を記録しておきたいアーキテクチャ上の決定
- 今後の参照用として、議論を Wiki ページに保存する場合
3 つのフェーズ
- 個別回答：各モデルが並行して回答します
- ランキング：各モデルが匿名化された他のモデルの回答を順位付けします
- 統合：議長モデルがすべての回答とランキングを読み、最終回答を作成します
プロバイダーの設定
プラグインの設定ダイアログで任意のキーを設定してください。providers MCP サーバーの run_provider_task ツールを、task: "council" および args: ["run", "<query>", "--provider", "openai"] とともに使用します。プロバイダーのステータスを確認するには、args: ["providers"] を渡してください。チャットでキーの提示を求めたり、既存の認証情報やシェル設定から読み取ったりしないでください。
スタンドアロン CLI で使用する場合は、以下の pro-workflow 専用変数を明示的に設定してください。最初に設定されたプロバイダーがデフォルトになります。--provider でプロバイダーを明示的に選択できます。プロバイダーの設定を参照してください。
| スタンドアロン CLI 変数 | プロバイダー | デフォルトのベース URL |
|---|---|---|
PRO_WORKFLOW_ANTHROPIC_API_KEY | Anthropic | https://api.anthropic.com |
PRO_WORKFLOW_OPENAI_API_KEY | OpenAI | https://api.openai.com/v1 |
PRO_WORKFLOW_OPENROUTER_API_KEY | OpenRouter | https://openrouter.ai/api/v1 |
PRO_WORKFLOW_FIREWORKS_API_KEY | Fireworks | https://api.fireworks.ai/inference/v1 |
LLM_COUNCIL_BASE_URL + PRO_WORKFLOW_LLM_COUNCIL_API_KEY | カスタム OpenAI 互換 | （ユーザー指定） |
実行ごとに --provider openai|anthropic|openrouter|fireworks|custom で上書きできます。
プロバイダーごとのデフォルトのモデル構成は scripts/council.js にあり、--models CSV および --chairman <id> で上書きできます。
コマンド
プラグインセッションでは、これらの実行引数を run_provider_task に渡してください。以下の直接コマンドは、認証情報を明示的に設定したスタンドアロン CLI のインストール向けです。
node $SKILL_ROOT/scripts/council.js run "<query>" [--models id1,id2,id3] [--chairman id] [--provider <name>] [--wiki <slug>]
node $SKILL_ROOT/scripts/council.js providers
node $SKILL_ROOT/scripts/council.js show <session-id>
--wiki <slug> を指定すると、完全なトランスクリプトが <wiki>/derived/council/<session-id>.md に書き込まれ、wiki-cli.js page を使って登録されるため、FTS5 検索に表示されます。
出力
各セッションで以下が出力されます。
~/.pro-workflow/council/<session-id>/
├── config.json # query, models, chairman, provider
├── phase1_responses.json # raw API responses per model
├── phase2_rankings.json # anonymized ranking outputs
├── phase3_synthesis.txt # chairman's final answer
└── final_output.md # human-readable bundle
コンソールには Markdown バンドルが出力されます。必要に応じて pbcopy / tee にパイプしてください。
厳守事項
- ランキングフェーズを省略しないでください。これは Council パターンの中核です。
- 生の回答をそのままディスクに保存してください。保存時に要約してはいけません。
- ランキング用に回答を匿名化してください。モデルに表示するのは、他のモデルの名前ではなく
Response A/B/C/...です。 - 議長には、実際の名前とランキングの両方を見せてください。
- 3 つすべてのフェーズをユーザーに表示してください。フェーズを省略してはいけません。
コストへの注意
対応プロバイダーでは、スクリプトが呼び出しごとのレイテンシとトークン数をログに記録します。見積もるには、プロバイダーの料金を掛けてください。Council のコストは、len(models)^2（各モデルが他のすべてのモデルを順位付けするため）に加えて議長分のコストを加えたものに比例して増加します。
デフォルトの Council サイズ：3～5 モデルです。モデル数を増やすと、ランキングの呼び出し回数が指数関数的に増加します。
Wiki との併用
/wiki council agent-memory "should we adopt episodic memory in our agents?"
agent-memory Wiki のコンテキストをシステムプロンプトのプレフィックスとして読み込み、Council を実行し、トランスクリプトを wiki/derived/council/<id>.md に保存します。トランスクリプトは /wiki ask から検索できるようになります。