mcpField
C
council-review

council-review

github.com/ngmeyerエージェントワークフロー1740 回インストール22 週間前に更新
リポジトリ

council-review について

誤りの代償が大きい判断向けのマルチエージェントレビュー用スキルです。異なる推論方法を使う5人のアドバイザーが分析と相互レビューを行い、結論をまとめます。クイック、自適応停止、信頼度重み付け、3人の審査員モードも選べます。

主な機能

  1. 015種類の推論方法による並列レビュー
  2. 02匿名でのアドバイザー相互レビュー
  3. 03レビュー結論の統合
  4. 04自適応停止と信頼度重み付け
  5. 05任意の3人審査員モード

活用シーン

  1. 01アーキテクチャ案や移行戦略の比較
  2. 02実装計画や製品判断のレビュー
  3. 03API 設計やプロジェクト範囲の検討

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/ngmeyer/council-review --skill council-review

インストール後、Claude Code で/council-reviewを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

CLAUDE.md
LICENSE
README.md
docs/ideation/
2026-04-13-council-review-improvements-ideation.md
tests/
eval.sh
README.md

詳細

評議会レビュー

あらゆる質問、計画、コードを、異なる推論手法を用いる5人の独立したアドバイザーに検討させ、協力して回答を磨き、互いに匿名で査読し、信頼できる結論を導き出します。

このスキルは、**多様なマルチエージェント討論(DMAD)**パターンを実装しています。これは敵対的ではなく、協調的なものです。エージェントは対立する立場を主張するのではなく、多様な推論によって真実を探ります。

これが有効な理由(研究による裏付け)

  • 手法の多様性は、単一手法による討論を上回ります。 DMAD(ICLR 2025)は、異なる推論手法を用いるエージェントが、均質な評議会を安定して上回ることを示しています。多様な中規模モデルは、各エージェントが異なる推論アプローチを適用すると、GSM-8KでGPT-4を上回る場合があります(91%対82%)。
  • 協調的な討論は、敵対的な討論を上回ります。 M3MADBench(2026)は、あらゆるモダリティにおいて、協調的なDMADが敵対的なDiv-MADを「大幅に上回る」ことを示しています。敵対的なパラダイムは意見の相違によるノイズを生みます。自由回答の質問、計画、意思決定には、協調的な熟議が適しています。
  • 匿名のピアレビューは、プロバイダーへの偏りを防ぎます。 これは研究全体で共通しています。役割名が見えると査読者はそれに引きずられるため、ピアレビューの回答はシャッフルする必要があります。
  • 確信度の調整により、マルチンゲールの限界を打破できます。 通常のMADは単純な多数決を下回ることがよくありますが、確信度を反映した更新(「Demystifying MAD」2026)は、評議会を正解へと一貫して導きます。
  • 適応的な停止により、コストを削減できます。 llmcouncilによる収束検出のKS統計量(S2 MAD)は、収束する質問で最大94.5%のコスト削減を報告しています。
  • 真の悪魔の代弁者だけが、確実に意見の相違を引き起こします(V2)。 マルチエージェントLLMチームの合意を崩す手法のうち、浮かび上がった回答を攻撃する専任の悪魔の代弁者だけが、真の意見の相違を生み出します。穏やかな役割設定や「反対意見を述べてください」という指示は、統計的にベースラインと区別できません。推奨案に異議を唱えるLLMの悪魔の代弁者は、グループの意思決定精度を測定可能なほど高めます(OpenReview 2026、IUI 2024)。V2では、収束した回答を対象に、悪魔の代弁者が1回、必須の検討を行います。つまり、恒常的に賛成派と懐疑派に分けるのではなく、合意に対して1人の悪魔の代弁者を置きます。
  • 迎合によって評議会は時期尚早な合意に陥ります(V2)。 LLMは互いに、また質問の枠組みから暗示される回答にも同調し、その結果、評議会の精度が単独エージェントを下回ることがあります(Peacemaker-or-Troublemaker 2026、CONSENSAGENT)。V2では、アドバイザーとピアレビューのプロンプトに迎合を防ぐガードレールを追加し、構造化された独立評価のステップ(Kahnemanの仲介評価プロトコル、2019)を導入します。これにより、議長は全体的な判断を下す前に、重要な属性を個別に評価できます。

既知の成果物(PR、草稿、仕様)をストレステストする場合は、別の/adversarial-reviewスキルを使用してください。この場合は、単独の批評者による敵対的な検証が適切です。

使用する場面

この評議会は、間違えた場合の損失が大きい質問に向いています。

適している例: アーキテクチャの決定、実装計画、PRレビュー、製品に関する意思決定、移行戦略、API設計、命名、価格設定、スコープの決定
適していない例: 事実の検索、文章作成、単純なはい/いいえの質問、明白な正解が1つしかないもの
別のツールを使用: 既存の成果物に対する単独の批評者によるストレステスト → /adversarial-review

フラグ

フラグ効果
--quickライトモード:アドバイザー3人と議長で構成し、相互レビューは行いません(11回ではなく4回の呼び出し)。
--adaptiveKS統計量による適応的な停止。複数ラウンドの議論を実行し、2ラウンド連続で回答の分布がイプシロン未満に収束したら停止します。収束する質問では、コストを最大94.5%削減できます。
--confidence信頼度を反映した統合。各アドバイザーが自身の信頼度(1~10)を評価し、各ピアの信頼度も評価します。議長による統合では、多数決ではなく信頼度で重み付けします。信頼度の低い合意には、黄色の警告を表示します。
--measure-diversityアドバイザーの回答後、各回答における推論の特徴の重複度を評価します。推論方法が異なるにもかかわらず評議会が同意した場合、その合意が演出的なものかもしれないという兆候として報告します。
--jury(V2) 単独の議長を3人の審査員団に置き換えます。できれば異なるモデルファミリーから選びます。各審査員が個別に統合し、簡単な調整ステップで結果をまとめます。単独の審査員では信頼性が不十分な、判断が拮抗するケースや重大な判定に適しています(審査員による陪審/PoLL)。

フラグは組み合わせて使用できます:/council-review --adaptive --confidence "Should we adopt GraphQL?" は、収束時に停止し、信頼度で重み付けした審議を実行します。

5人のアドバイザー

#アドバイザー観点推論方法見つける問題
1反対論者何が失敗するでしょうか?逆向きの推論 — リリース後に失敗したと仮定し、その原因をさかのぼります高揚しているときに見落としがちな「素晴らしく聞こえますが……」という問題
2第一原理思考家実際に何を解決しようとしているのでしょうか?分解 — 主張を基本要素に分け、それぞれを問い直します「最適化する変数を間違えています」
3拡張論者どのようなメリットを見落としているでしょうか?類推 — 隣接する分野では、これをどのように異なる方法で解決したでしょうか?「考え方の幅が狭すぎます」
4部外者事前知識なしで、初めて目にする視点素朴な質問 — 参加したばかりの人に説明するように説明し、理解に内部知識が必要な点を指摘します知識の呪いによる盲点
5実行者月曜の朝に何をしますか?依存関係の図式化 — 何が何を妨げているでしょうか? クリティカルパスは何でしょうか?最初の実行可能な一歩がない、すばらしい計画

自然な対立関係: 反対論者と拡張論者(下振れと上振れ)、第一原理思考家と実行者(再考とリリース)。部外者が全員の議論を正します。

5つの推論方法は、入れ替え可能な観点ではありません。それぞれ異なる認知操作です。これがDMADの要点です。同じモデルでも、推論方法を変えます。


実行フロー

ステップ0:事前確認

<pre_flight>

$ARGUMENTS からフラグを解析します:

  • --quick が含まれている場合:ライトモードを使用します(後述)。
  • --adaptive が含まれている場合:KS統計量による適応的な停止を有効にします(ステップ3.5)。
  • --confidence が含まれている場合:信頼度を反映した統合を有効にします(ステップ2および4)。
  • --measure-diversity が含まれている場合:多様性の検証を有効にします(ステップ2.5)。
  • --jury が含まれている場合:統合時に3人の審査員団を使用します(ステップ4)。
  • 分類する前に、入力からフラグを取り除きます。

対象範囲の検証: 評議会を招集する前に、入力が本当に評議会を必要とするかを判断します。質問が純粋な事実に関するもの、答えが明らかに1つしかないもの、または意味のあるトレードオフがないものの場合は、その旨を直接伝えます:「これは評議会を必要としません — [直接の回答]。実質的な利害とトレードオフのある判断には /council-review を使用してください。」些細な質問にエージェントを起動しないでください。

残りの入力を分類します:

  1. PR — 数値、または /pull/ を含むURL。gh pr view を使ってPRの差分と説明を取得します。
  2. ファイルパス — ファイル拡張子で終わる文字列、または既存のファイルを指す文字列。ファイルの内容を読み取ります。
  3. 計画/判断/質問 — その他すべて。そのまま使用します。

PRとファイルの場合は、実際の内容を読み取り、それを枠組みに含めた質問にします。URLだけを渡さないでください。アドバイザーには内容が必要です。

</pre_flight>

ステップ 1:コンテキストを収集して論点を整理する

コンテキストの自動収集 — 論点を整理する前に、以下のプロジェクトファイルを読みます(存在しないものはスキップします)。

  • README.md — プロジェクトの内容
  • CLAUDE.md または AGENTS.md — 規約、アーキテクチャ、パターン
  • 最近の git ログ(git log --oneline -10)— 最近の変更内容
  • ユーザーが言及したファイル、またはトピックに関連するファイル
  • PR をレビューする場合は、PR の差分と説明

生の入力を、明確で中立的なプロンプトにまとめ直します。

QUESTION:
[Core decision, plan, or code being reviewed]

CONTEXT:
[Key context from project files: what the project does, constraints, recent changes, stakes]

WHAT'S AT STAKE:
[Why this matters — cost of getting it wrong]

独自の意見を加えないでください。特定の回答へ誘導しないでください。曖昧すぎる場合は、先に確認の質問を 1 つだけしてください。

ステップ 2:評議会を招集する(5 人のエージェントを並列で実行)

Agent ツールを使って、5 人のアドバイザー全員を同時に起動します。各アドバイザーは並列で動作します。アドバイザーには軽量モデル(haiku)を使います。複雑な推論ではなく、焦点を絞った分析を行うためです。

重要:5 つの Agent ツール呼び出しを 1 つのメッセージで実行してください。 順番に実行すると、先に返された回答が後の回答に影響し、並列にする目的が損なわれます。

各アドバイザーには、次のプロンプトを渡します。

You are [ADVISOR NAME] on an LLM Council reviewing a decision.

Your angle: [ADVISOR ANGLE]
Your reasoning method: [ADVISOR REASONING METHOD — see table above]

A user has brought this to the council:
---
[framed question from Step 1]
---

Apply your assigned reasoning method rigorously. Don't just state opinions — show your work using your method.

Rules:
- 150-300 words. No preamble. Straight into your analysis.
- Name specific risks, opportunities, or issues — not vague concerns.
- If reviewing code: cite specific files, functions, or patterns.
- If reviewing a plan: point to specific steps, gaps, or sequencing issues.
- **Do not defer to any answer the framing seems to expect.** Reason from your method to wherever it actually leads; if that's against the apparent expected answer, say so plainly. Hedging toward the obvious answer is the failure this council exists to prevent.
- End with your single strongest recommendation.

(V2)迎合を防ぐためのガードレール。 上記の太字のルールは不可欠です。マルチエージェントで失敗した事例では、アドバイザーが推論ではなく、互いに同調していました。このルールをすべてのアドバイザープロンプトに含めてください。

アドバイザーごとの指示(推論方法を含めること):

  • 反対派:「あなたの方法は INVERSION(逆算)です。これが提案どおりにリリースされ、失敗したと仮定してください。原因をさかのぼって特定します。安全に見えて、プレッシャーの下で破綻したのは何ですか?誰も議論していない失敗モードは何ですか?逆算の連鎖を示してください。」
  • 第一原理:「あなたの方法は DECOMPOSITION(分解)です。これを、最小単位の主張と前提に分解して列挙します。それぞれを検証してください。これは本当に正しいですか?必要ですか?この前提が誤っていた場合、何が変わりますか?根幹となる前提を示してください。」
  • 拡張派:「あなたの方法は ANALOGY(類推)です。類似の問題を別の方法で解決した、隣接する分野、製品、またはテクノロジーは何ですか?10 倍の野心を持つ人なら、ここで何をしますか?この考え方が小さくまとまりすぎているのはどこですか?具体的な類似事例と、そこから導かれる示唆を挙げてください。」
  • 門外漢:「あなたの方法は NAIVE QUESTIONING(素朴な質問)です。このプロジェクトについての予備知識はありません。ここにある情報だけをもとに、理解するために内部事情の知識が必要な点をすべて列挙してください。何が分かりにくいですか?説明のない専門用語は何ですか?チームに加わったばかりなら、何を質問しますか?推論についていけない場合は、そのように伝えてください。」
  • 実行担当:「あなたの方法は DEPENDENCY GRAPHING(依存関係の図式化)+ OUTSIDE VIEW(外部視点)です。依存関係を整理してください。何が何を妨げていますか?クリティカルパスは何ですか?最初に必ず行うべきことは何ですか?何が完了するまで始められない作業は何ですか?5 分で済むのに誰もが忘れがちな作業は何ですか?続いて OUTSIDE VIEW(V2)を適用してください。ベースレートを示します。同様の取り組みは、計画上の見込みではなく、実際にはどのような結果になっていますか?この計画の見積もりにある楽観バイアスを、該当する参照クラスに照らして指摘してください。実行の順序を示してください。」

--confidence が有効な場合は、すべてのアドバイザープロンプトに次を追加してください。

After your analysis, end with:
CONFIDENCE: [1-10]
RATIONALE: [one sentence — what would change your confidence up or down?]

これにより、議長が統合時に重み付けする、較正された自己評価が得られます。

ステップ 2.5:多様性の検証(--measure-diversity の場合のみ)

5 人のアドバイザーから回答がすべて集まり、ピアレビューを始める前に、推論の重複度を評価します。

  1. 各回答から、根幹となる主張を抽出します(アドバイザー 1 人につき上位 3~5 件)。
  2. ペアごとの重複度を算出します。同じ結論の主張が、2 つ以上の回答にいくつ含まれていますか?
  3. 多様性スコアを 1 つ報告します。
    • 多様性が高い(重複度 < 30%) — アドバイザーは実際に異なる視点で考えています。合意を信頼します。
    • 多様性が中程度(重複度 30~60%) — 部分的な一致があります。評価結果では、共有されている前提に触れます。
    • 多様性が低い(重複度 > 60%) — 異なる方法を使っているにもかかわらず、アドバイザーは同じ推論に収束しています。見せかけの合意として警告します。議長は、これを 1 人のアドバイザーの意見として扱うべきです。

これにより、「5 人のアドバイザーが賛成」と言っていても、実際には 1 つのプロンプト誘導パターンが支配的だった、という状況を検出できます。

ステップ 3:匿名ピアレビュー(5 エージェントを並列実行)

5 人のアドバイザーの回答をすべて収集します。対応関係をランダム化してください。アドバイザー 1 が常に回答 A にならないようにします。次に、5 人のレビュアーエージェントを並列で起動します(haiku を使用)。

各レビュアーには、匿名化された 5 つの回答をすべて提示します。

You are reviewing the outputs of an LLM Council. Five advisors independently answered:

---
[framed question]
---

**Response A:** [randomized advisor response]
**Response B:** [randomized advisor response]
**Response C:** [randomized advisor response]
**Response D:** [randomized advisor response]
**Response E:** [randomized advisor response]

Answer these three questions. Be specific. Reference responses by letter.

1. Which response is strongest? Why? (one sentence)
2. Which has the biggest blind spot? What is it missing? (one sentence)
3. What did ALL five responses miss that the council should consider? (This is the most valuable question — think hard.)
4. **(V2)** Where these responses agree, is the agreement genuine — or could it be conformity to a shared framing? Flag any consensus that looks like deference rather than independent reasoning.

Keep under 150 words. Be direct. No preamble.

--confidence が有効な場合は、4 つ目の質問を追加します。

4. Rate your confidence in your answers above (1-10). What would change it?
ステップ 3.5:適応型停止(--adaptive のみ)

--adaptive が有効な場合、評議会はアドバイザー → レビュー → 議長という単一の流れではなく、複数のラウンドにわたって動作します。各ラウンドの後に、次の処理を行います。

  1. そのラウンドのアドバイザーの回答をすべて収集します(5 件)。
  2. コルモゴロフ–スミルノフ統計量を使って、回答の分布を前のラウンドの回答と比較します。粗いフィンガープリントを使用します。各回答から異なる主張の集合を抽出し、ラウンド間でジャカード距離に基づく距離を計算します。
  3. 分布の変化が 2 ラウンド連続でイプシロン(デフォルト:0.1)を下回った場合、停止して議長による統合に進みます。
  4. それ以外の場合は、各アドバイザーに前のラウンドの回答を提示して更新を求め、アドバイザーラウンドをもう一度実行します。
  5. 最大 5 ラウンドとします。コストが際限なく増えるのを防ぐための厳格な上限です。

--adaptive によって早期停止した場合、議長には最終ラウンドの回答とともに、次の 1 行の注記を渡します。「評議会は N ラウンド後に収束しました(KS 変化量がイプシロンを下回りました)。」

固定モード(--adaptive なし)の場合は、アドバイザーラウンドを 1 回実行した後、ステップ 3 のピアレビューに直接進みます。

ステップ 3.7:コンセンサスへの悪魔の代弁者(V2 — 必須)

これは、V2 で追加される中で最も効果の高いものです。エビデンスは明白です。開始時のソフトな反対意見の提示(コントラリアンアドバイザー)は、実質的な意見の相違を引き起こす効果においてベースラインと統計的に区別できません。一方、形成されつつある回答を攻撃する専任の悪魔の代弁者だけが効果を発揮し、意思決定の正確性を測定可能な形で高めます。

  1. アドバイザーの回答とピアレビューから、形成されつつあるコンセンサス回答を 1 文で特定します(評議会は何を推奨する方向に傾いていますか)。本当にまだ回答が形成されていない場合は、その旨を記してステップ 4 に進みます。

  2. 悪魔の代弁者エージェントを 1 つ起動します。強力なモデルを使用してください(haiku は不可)。このエージェントには鋭い批判が求められます。プロンプトは次のとおりです。

    The council is converging on this answer:
    ---
    [emerging consensus answer, stated plainly]
    ---
    To this question:
    ---
    [framed question]
    ---
    
    Your job is to make the strongest possible case that this answer is WRONG.
    Not "here are some risks" — argue that following it is a mistake.
    - What does the consensus overlook that, if true, flips the decision?
    - Construct the concrete scenario in which this answer fails badly.
    - What evidence would the council need to see to abandon this answer — and is it actually present, or assumed?
    Steelman the opposite of the consensus. 200 words max. End with: the ONE thing that, if the council can't rebut it, should change the verdict.
    
  3. 悪魔の代弁者の出力を、ほかのすべての情報とともに議長に渡します。これは最初から支持者と懐疑者を 2 対 2 にする構成ではありません。調査で特に効果が示された構成、すなわち収束した回答への鋭い攻撃を 1 つ加えるものです。

--quick モードでも、悪魔の代弁者は実行します(最も低コストで高い価値をもたらす追加機能です。呼び出しは 1 回)。これは --quick でも省略してはならない唯一のステップです。

ステップ 4:議長による統合

1人のエージェントがすべてを受け取ります。元の質問、5人のアドバイザー全員の回答(名前と推論方法を明らかにしたもの)、5件のピアレビュー、合意に対する悪魔の代弁者の攻撃(V2)、多様性スコア(--measure-diversity を指定した場合)、信頼度評価(--confidence を指定した場合)です。この処理には、利用可能な最良のモデルを使用します(デフォルトのままにし、軽量モデルを指定しないでください)。

(V2)まず、評価項目を個別に検討します。 推奨案を書く前に、議長は判断を左右する独立した重要属性を3~5個挙げます(例:アーキテクチャの判断なら、可逆性、影響範囲、最初の価値を得るまでの時間、チームの習熟度)。そして、全体的な結論をまだ形成せずに、それぞれを証拠に照らして個別に評価します。個別評価を終えてから、議長は総合的な判断をまとめます。これにより、一貫性バイアス(早い段階で答えを決め、すべての属性をその答えに合うように解釈すること)を防ぎます。Kahneman/Lovallo/Sibony、『Mediating Assessments Protocol』(2019年)。

(V2)--jury: 議長を1人にする代わりに、理想的には異なるモデルファミリーから3人の議長を選び、それぞれが個別に完全な統合(評価項目の個別検討を含む)を行います。その後、短い調整プロセスで、3人の判断が一致する点(信頼度の高い結論)と、意見が分かれる点(本当に判断が難しいケースとして明示)を示します。1人の判断者では信頼性が不十分な、重大な決定や判断が難しい決定に使用してください。

デフォルトの統合(多数派を考慮): 議長は、アドバイザー間の意見の一致とピアレビューのシグナルを考慮し、悪魔の代弁者による最も強力な指摘に対し、明示的に反論するか、認める必要があります。

信頼度を加味した統合(--confidence): 議長は、各アドバイザーの貢献度に、その自己評価の信頼度とピア評価の信頼度を掛け合わせた重みを付けます。信頼度の低い多数派は結論で明示し、信頼度の高い少数意見は、より大きな重みを付けて残します。

多様性を考慮した統合(--measure-diversity): 多様性スコアが Low の場合、議長は結論に「審議会は独立した推論ではなく、共有された前提に基づいて意見が一致しました」と明記し、推奨案の信頼度を下げます。

議長は、次の構成を厳密に使用します。

## Council Verdict: [Topic — 5 words max]

### Where the Council Agrees
[Points where multiple advisors converged independently — these are high-confidence signals]

### Where the Council Clashes

For each disagreement, classify it:

**[Value Tension]** — Both sides are valid; the right choice depends on priorities.
[Present both sides clearly. Name the tradeoff.]

**[Error Catch]** — One advisor found a real flaw the others missed.
[Name the flaw, who caught it, and why it matters.]

### Blind Spots Revealed
[Things only the peer review caught — the "what did ALL five miss?" answers]

### Mediating Assessments  *(V2)*
[The 3–5 independent attributes the decision turns on, each scored separately against the evidence — stated BEFORE the recommendation so the reader sees the inputs to the judgment, not just the conclusion.]

### Devil's Advocate — and the Council's Answer  *(V2)*
[The strongest case that the emerging answer is wrong (from Step 3.7), and the chairman's explicit rebuttal or concession. If the Devil's Advocate's one key point can't be rebutted, the verdict must change to reflect it.]

### Confidence Profile  *(only with --confidence)*
[Which advisors were confident vs hedging? Where did peer-rated confidence diverge from self-rated? What does the confidence pattern tell us?]

### Diversity Check  *(only with --measure-diversity)*
[Diversity score and what it means for the verdict's reliability.]

### Recommendation
[Clear, actionable recommendation. Not "it depends." Not "consider both options." A real answer with reasoning. The chairman CAN disagree with the majority if the dissenter's reasoning is strongest, OR if confidence/diversity signals undermine the apparent consensus.]

### What You Lose
[If you follow this recommendation, what does the strongest dissenting voice say you're giving up? Name the specific risk or missed opportunity. This is NOT a hedge — it's informed consent.]

### Do This First
[Single concrete next step. Not a list. Not three options. One thing to do right now.]

**How to verify:** [2-3 concrete checks to confirm the recommendation was right. What should you measure? What should you look for after N days/weeks? **(V2)** Include the outside-view check: what's the base rate for efforts like this, and what early signal would tell you you're tracking worse than the reference class?]
ステップ 5:結果を提示する

議長の結論をチャットに直接表示します。その後、ユーザーが希望する場合は、全記録を折りたたみ可能なセクションまたは別ファイルで提供します。


ライトモード(--quick)

--quick が渡された場合は、簡略化した審議会を実行します。

  1. アドバイザーは3人のみ: Contrarian、Executor、Outsider(最も行動指向の強い3つの視点)
  2. ピアレビューなし — ステップ 3 全体を省略
  3. 悪魔の代弁者(V2)は引き続き実行 — ステップ 3.7 は、--quick で省略してはならない、コストの低い唯一のステップです
  4. 議長による統合:3件の回答と悪魔の代弁者による指摘を使用
  5. 出力形式は同じですが、処理はより高速です(エージェント呼び出しは12回ではなく5回)
  6. --confidence および --measure-diversity と併用可能ですが、--adaptive とは併用できません(複数ラウンドは節約できる分よりもコストがかかります)。

日常的な決定、手早い感触の確認、または網羅性よりも時間が重要な場合に使用してください。

コスト予算

モードエージェント呼び出し数最適な用途
Full(デフォルト)12(アドバイザー 5 人+レビュアー 5 人+デビルズアドボケイト 1 人+議長 1 人)重大な意思決定
Quick(--quick)5(アドバイザー 3 人+デビルズアドボケイト 1 人+議長 1 人)日常的な意思決定、直感の確認
Adaptive(--adaptive)7~27(アドバイザー 5 人 × N ラウンド+レビュアー 5 人+デビルズアドボケイト 1 人+議長 1 人、早期終了時は N ≤ 5)収束にかかるコストが重要な、答えが定まっていない問い
Confidence(--confidence)12(Full と同じ。プロンプトはやや長め)確信度の適切な調整が重要な意思決定
Measure-diversity(--measure-diversity)12(同期的な重複スコアリングのステップを追加。エージェント呼び出し数は増えません)合意が見せかけではないことの検証
Jury(--jury)+2(議長を 1 人から 3 人に増やす。可能なら多様なモデルを使用)判断が拮抗する場合/重大な判定の信頼性向上

フラグは組み合わせて使用できます。--adaptive --confidence --measure-diversity を同時に指定すると、呼び出し数は最大 26 回で、さらに多様性スコアリングと確信度による重み付けが加わります。

大量処理には高速なモデル、統合には優れたモデルを使用します。最も重要なのは議長の推論の質です。

注意点

  • アドバイザーは必ず並列で起動してください。 順番に実行すると、先に得られた回答が後の回答に影響します。
  • ピアレビューでは必ず匿名化してください。 ラベルが見えると、レビュアーは「The Contrarian」や「First Principles」の意見を重視してしまいます。文字をシャッフルしてください。
  • 議長は多数派の意見を覆すことができます。 投票数より推論の質が重要です。Contrarian が他の全員の見落とした本当の欠陥を見つけた場合、議長はその意見を支持すべきです。
  • 些細な問いを評議会にかけないでください。 事前チェックで見つかるはずです。正解が 1 つなら、そのまま回答してください。
  • コンテキストは非常に重要です。 入力が一般的だと、出力も一般的になります。自動コンテキストステップではプロジェクトファイルを読み込むため、アドバイザーが状況を把握できないまま判断することはありません。
  • 同一モデルの制約。 このスキルでは、モデルの多様性(Karpathy のオリジナルでは異なる LLM を使用)ではなく、ペルソナ/手法の多様性(同一モデルで異なる推論手法を使用)を活用します。最も重大な意思決定では、別のモデルファミリーからセカンドオピニオンを得ることを検討してください。または --measure-diversity を使って、評議会が早期に収束していないことを検証してください。
  • 答えが定まっていない問いには、敵対的な議論より協調的な議論が適しています。 M3MADBench 2026 によると、敵対的な議論は、すべてのモダリティにおいて協調的な議論より劣ります。既知の成果物(PR、草案、仕様)のストレステストには、別の /adversarial-review スキルを使用してください。これは異なる操作であり、入力も異なります。
  • 確信度の調整精度は、モデルの確信度調整能力に左右されます。 異論を唱える側の推論が具体的で、多数派の推論が曖昧な場合は、確信度の低い異論であっても真剣に検討してください。
  • (V2)Contrarian は Devil's Advocate ではありません。 Contrarian は最初に逆の立場を取ります(穏やかな枠組みで、実際の意見の相違を引き出す効果がベースラインと同等かを検証します)。ステップ 3.7 の Devil's Advocate は、収束した回答を攻撃します。これは証拠が特に有効だと示している構成です。呼び出しを節約するためにステップ 3.7 を省略しないでください。このスキルで最も効果の大きいステップです。
  • (V2)仲介評価は推奨の前に行います。 議長が先に判定を書いてから属性スコアを後付けすると、このプロトコルが防ぐはずの一貫性バイアスが再現されます。属性を個別に採点してから、統合してください。
  • (V2)--jury が役立つのは、審査員に違いがある場合だけです。 同じモデルを 3 回実行しても、ほとんど見せかけにすぎません。異なるモデルファミリーを使用するか、少なくとも独立したコンテキストを使用してください。3 人全員の一致を本当のシグナルとして扱い、意見の分裂は本当に判断が拮抗しているものとして扱ってください。

変更履歴

V2.1 (2026-05-27)

非推奨の --adversarial モードを完全に削除しました(フラグ、モードのセクション、コストの行、解析ステップ)。このモードはM3MADBenchのエビデンスと矛盾し、V2で必須となった「悪魔の代弁者対コンセンサス」のステップに取って代わられたうえ、実際に「/adversarial-reviewと同じではないのか」という混乱を招いていました。2つのスキルは明確に分けられています。council-review=未決定の事項(組み込みの悪魔の代弁者を含む)、/adversarial-review=完成した成果物のストレステストです。「協調型は敵対型を上回る」というエビデンスと、/adversarial-reviewへの相互リンクは維持しています。

V2 (2026-05-26)

skillforge optimizeで最適化しました。成果に関する調査概要:V2の成果に関する調査概要。各変更はエビデンスに基づき、パッケージングではなく意思決定の結果を対象としています。

  • **必須の悪魔の代弁者(Step 3.7)**が形成されつつあるコンセンサスを攻撃します。これは、真の意見の相違を確実に引き起こし、精度を高めることが示された唯一の構成です(OpenReview 2026、IUI 2024)。Contrarianによる討論開始時の反転は、柔らかな枠付けにすぎず、ベースラインと同等の結果しか検証できません。
  • アドバイザーとピアのプロンプトに迎合を防ぐガードレールを追加し、真の同意と同調を区別する新しいピアレビューの質問を加えました(Peacemaker-or-Troublemaker 2026、CONSENSAGENT)。
  • 議長による統合に媒介評価を追加しました。全体的な判断の前に、独立した属性を3~5項目採点し、一貫性バイアスに対処します(Kahneman/Lovallo/Sibony 2019)。
  • Executorと「検証方法」に、アウトサイドビュー/ベースレートの確認を追加しました(参照クラス予測法;Kahneman/Tversky、Flyvbjerg)。
  • --jury — 判断が難しい場合に、多様なモデルを使う3人の議長が対応します(裁判官団/PoLL)。

検証。 2段階で実施しました。(1)「モノリスからマイクロサービスへ移行すべきか?」を題材にした、構造化された単一モデル評価:V1 3.2 → V2 4.6。(2)独立したA/Bテスト(2026-05-27):「シード段階のスタートアップはKubernetesを採用すべきか?」を題材に、実際に別プロセスで動作するエージェント(claude -p)を使用しました。議長層の変更のみを分離して評価するため、両群でアドバイザーを同一にし、どちらの判定かを知らないブラインド評価者が採点しました(順序バイアスを避けるため、V1を先に提示):V1 3.8 → V2 4.8(決断力、洞察力、較正、実行可能性、リスクの表面化)。最大の向上は、リスクの表面化が3→5、較正が3→4でした。評価者がV2の勝因として挙げた理由は、ベースレート/アウトサイドビュー、悪魔の代弁者による反論、独立した属性採点と、まさにV2の仕組みを示していました。このA/Bテストでは、アドバイザー層の変更(迎合を防ぐガードレール、アウトサイドビューのプロンプト)は同一に保たれており、これらの変更は引き続き論理的な検討によってのみ妥当性が確認されています。

クレジット

コメント