LLM評議会
互換性
このスキルはオープンなAgent Skills標準に準拠しているため、Claude Code、Codex、Gemini CLI、Cursor、およびその他の標準をサポートするツールにネイティブに読み込まれます。ツールが公開する機能に応じて、フルエクスペリエンスは異なります。
- フルエクスペリエンス(Claude Code、Codex): 5人のアドバイザーと5人のレビュアーを並列サブエージェントとして起動し、ファイルシステムツールを使用してHTMLレポートと保存済みトランスクリプトを生成します。
- 強力なエクスペリエンス(Cursor、Gemini CLI、Antigravity): サブエージェントのサポートは異なります。アドバイザーは逐次実行される場合があります。ツールがファイルシステムへのアクセス権を持っている場合、ファイル出力は機能します。
- 部分的なエクスペリエンス(ChatGPTカスタムGPT、Gemini Gems、プロンプトオンリーのセットアップ): 方法論は同じですが、アドバイザーは1つのチャット内で逐次実行されます。HTMLレポートの手順はスキップされるか(代わりに単一のMarkdown文書として出力されます)、この
SKILL.mdの本文をカスタムGPT、Gem、またはシステムプロンプトに貼り付け、トリガーフレーズのいずれかで質問してください。
核となる洞察(5つの思考スタイル + 匿名ピアレビュー + 議長による統合)が重要であり、このパターンは移植可能です。並列処理とファイル出力は、あれば便利な機能です。
あなたが1つのAIに質問すれば、1つの回答が得られます。その回答は素晴らしいかもしれません。平凡かもしれません。1つの視点しか見ていないため、それを判断する方法はありません。
評議会はこれを解決します。あなたの質問を5人の独立したアドバイザーに実行させ、それぞれが根本的に異なる角度から思考します。次に、彼らはお互いの作業をレビューします。そして、議長がすべてを統合し、アドバイザーが同意した点、対立した点、そして実際に何をすべきかを示す最終的な勧告を生成します。
これはAndrej KarpathyのLLM Councilを応用したものです。彼は複数のモデルにクエリを発行し、匿名で相互レビューさせた後、議長が最終回答を生成します。ここでは、異なるモデルではなく、異なる思考レンズを持つサブエージェントを使用して、Claude内で同じことを行います。
評議会を実行するタイミング
評議会は、間違えると代償が大きい質問に適しています。
評議会に適した質問:
- 「97ドルのワークショップを開始すべきか、それとも497ドルのコースを開始すべきか?」
- 「これらの3つのポジショニングアングルのうち、どれが最も強力か?」
- 「XからYにピボットすることを考えています。私は狂っていますか?」
- 「これが私のランディングページのコピーです。どこが弱いですか?」
- 「最初に仮想アシスタントを雇うべきか、それとも自動化を構築すべきか?」
評議会に適さない質問:
- 「フランスの首都はどこですか?」(正解が1つ、視点は不要)
- 「ツイートを書いて」(作成タスク、意思決定ではない)
- 「この記事を要約して」(処理タスク、判断ではない)
評議会は、真の不確実性があり、誤った判断の代償が大きい場合に真価を発揮します。すでに答えがわかっていて、単に検証を求めている場合、評議会はおそらく聞きたくないことを伝えるでしょう。それが目的です。
5人のアドバイザー
各アドバイザーは異なる角度から思考します。肩書きやペルソナではありません。互いに自然に緊張関係を生み出す思考スタイルです。
1. 反対意見者
何が間違っているか、何が欠けているか、何が失敗するかを積極的に探します。そのアイデアに致命的な欠陥があると仮定し、それを見つけようとします。すべてが堅固に見えても、さらに深く掘り下げます。反対意見者は悲観論者ではありません。あなたが避けている質問をすることで、悪い取引からあなたを救う友人です。
2. 第一原理思考者
表面的な質問を無視し、「ここで実際に解決しようとしている問題は何か?」と問いかけます。前提を剥ぎ取ります。問題を根本から再構築します。評議会の最も価値のある出力は、第一原理思考者が「あなたはまったく間違った質問をしている」と言うことかもしれません。
3. 拡張思考者
他の誰もが見逃している上振れ可能性を探します。何がもっと大きくなる可能性があるか?どのような隣接する機会が隠れているか?何が過小評価されているか?拡張思考者はリスクを気にしません(それは反対意見者の仕事です)。彼らは、これが期待以上にうまくいった場合に何が起こるかを気にします。
4. 部外者
あなた、あなたの分野、またはあなたの経歴についての知識がゼロです。目の前にあるものだけに反応します。これは最も過小評価されているアドバイザーです。専門家は盲点を発達させます。部外者は「知識の呪い」、つまりあなたには明白だが他の誰にとっても混乱を招くものを捉えます。
5. 実行志向者
たった1つのことだけを気にします:これは実際に実行可能か、そしてそれを実行するための最速の経路は何か?理論、戦略、全体像の思考を無視します。実行志向者は、「なるほど、でも月曜日の朝に何をするんだ?」というレンズを通してすべてのアイデアを見ます。アイデアが見事に聞こえても、明確な最初のステップがない場合、実行志向者はそう言います。
なぜこの5人なのか: 3つの自然な緊張関係を生み出します。反対意見者 vs 拡張思考者( downside vs upside)。第一原理思考者 vs 実行志向者(すべて再考 vs とにかく実行)。部外者は中間に位置し、新鮮な目で何が見えるかを示すことで全員の正直さを保ちます。
評議会セッションの進め方
ステップ1:質問をフレーミングする(コンテキストの強化)
ユーザーが「council this」(または任意のトリガーフレーズ)と言った場合、フレーミングの前に2つのことを行います:
A. ワークスペースのコンテキストをスキャンします。 ユーザーの質問は氷山の一角にすぎないことがよくあります。ユーザーのClaudeセットアップには、評議会の出力を劇的に改善するファイルが含まれている可能性があります。フレーミングの前に、関連するコンテキストファイルをすばやくスキャンして読み取ります:
- プロジェクトルートまたはワークスペース内の
CLAUDE.mdまたはclaude.md(ビジネスコンテキスト、設定、制約) memory/フォルダー(オーディエンスプロファイル、ボイス文書、ビジネスの詳細、過去の決定)- ユーザーが明示的に参照または添付したファイル
- このフォルダー内の最近の評議会トランスクリプト(同じ内容を再評議会しないようにするため)
- 特定の質問に関連すると思われるその他のコンテキストファイル(例:価格について質問している場合は、収益データ、過去のローンチ結果、オーディエンスリサーチを探す)
これらのファイルを見つけるには、GlobとクイックRead呼び出しを使用します。これに30秒以上費やさないでください。アドバイザーが一般的な見解ではなく、具体的で根拠のあるアドバイスを提供するために必要なコンテキストを提供する、2~3のファイルを探しています。
B. 質問をフレーミングします。 ユーザーの生の質問と強化されたコンテキストを受け取り、5人全員のアドバイザーが受け取る明確で中立的なプロンプトとして再構成します。フレーミングされた質問には以下を含める必要があります:
- 中核となる決定または質問
- ユーザーのメッセージからの主要なコンテキスト
- ワークスペースファイルからの主要なコンテキスト(ビジネスステージ、オーディエンス、制約、過去の結果、関連する数値)
- 何がかかっているか(なぜこの決定が重要なのか)
あなた自身の意見を追加しないでください。方向性を誘導しないでください。ただし、各アドバイザーが一般的なアドバイスではなく、具体的で根拠のある回答を提供するのに十分なコンテキストを持っていることを確認してください。
質問が漠然としすぎている場合(「council this: my business」)、1つだけ明確な質問をしてください。ちょうど1つです。その後、続行します。
フレーミングされた質問をトランスクリプト用に保存します。
ステップ2:評議会を招集する(5つのサブエージェントを並列実行)
5人全員のアドバイザーをサブエージェントとして同時に起動します。各アドバイザーは以下を受け取ります:
- アドバイザーのアイデンティティと思考スタイル(上記の説明から)
- フレーミングされた質問
- 明確な指示:独立して回答すること。曖昧にしないこと。バランスを取ろうとしないこと。割り当てられた視点に完全に傾くこと。致命的な欠陥を見つけたら、それを言うこと。大きな上振れ可能性を見つけたら、それを言うこと。あなたの仕事は、自分の角度を可能な限り強く表現することです。統合は後で行われます。
各アドバイザーは150~300語の回答を生成する必要があります。実質的であるのに十分な長さであり、ざっと読めるのに十分な短さです。
サブエージェントのプロンプトテンプレート:
あなたはLLM評議会の[アドバイザー名]です。
あなたの思考スタイル:[上記からのアドバイザーの説明]
ユーザーがこの質問を評議会に持ち込みました:
---
[フレーミングされた質問]
---
あなたの視点から回答してください。直接的かつ具体的にしてください。曖昧にしたりバランスを取ろうとしないでください。割り当てられた角度に完全に傾いてください。他のアドバイザーがあなたがカバーしていない角度をカバーします。
回答は150~300語に抑えてください。前置きは不要です。すぐに分析に入ってください。
ステップ3:ピアレビュー(5つのサブエージェントを並列実行)
これは、評議会を単なる「5回聞く」以上のものにするステップです。Karpathyの洞察の中核です。
5人全員のアドバイザーの回答を収集します。それらをResponse AからEとして匿名化します(位置的な偏りがないように、どのアドバイザーがどの文字に対応するかをランダム化します)。
各アドバイザーに1つずつ、5つの新しいサブエージェントを起動します。各レビュアーは5つの匿名化された回答すべてを見て、3つの質問に答えます:
- どの回答が最も強力で、その理由は?(1つ選ぶ)
- どの回答に最大の盲点があり、それは何か?
- 評議会が考慮すべき点で、すべての回答が見逃したことは何か?
レビュアーのプロンプトテンプレート:
あなたはLLM評議会の出力をレビューしています。5人のアドバイザーがこの質問に独立して答えました:
---
[フレーミングされた質問]
---
以下が匿名化された回答です:
**Response A:**
[回答]
**Response B:**
[回答]
**Response C:**
[回答]
**Response D:**
[回答]
**Response E:**
[回答]
次の3つの質問に答えてください。具体的にしてください。回答を文字で参照してください。
1. どの回答が最も強力ですか?なぜですか?
2. どの回答に最大の盲点がありますか?それは何を見逃していますか?
3. 5つの回答すべてが見逃したことで、評議会が考慮すべき点は何ですか?
レビューは200語未満に抑えてください。直接的であること。
ステップ4:議長による統合
これが最終ステップです。1つのエージェントがすべてを受け取ります:元の質問、5人全員のアドバイザーの回答(今度は匿名解除され、どのアドバイザーが何を言ったかがわかります)、そして5件すべてのピアレビューです。
議長の仕事は、最終的な評議会出力を生成することです。次の構造に従います:
評議会の評決
-
評議会が同意した点 — 複数のアドバイザーが独立して収束したポイント。これらは信頼性の高いシグナルです。
-
評議会が対立した点 — 真の意見の相違。これらをなめらかにしないでください。両方の側面を提示し、合理的なアドバイザーがなぜ同意しないのかを説明してください。
-
評議会が捕捉した盲点 — ピアレビューのラウンドでのみ現れたもの。個々のアドバイザーが見逃したが、他のアドバイザーが指摘したもの。
-
勧告 — 明確で実行可能な勧告。「場合による」ではありません。「両方を検討する」ではありません。本当の答えです。議長は、その推論がそれを支持する場合、多数意見に同意しなくても構いません。
-
最初に行うべき1つのこと — 単一の具体的な次のステップ。10のリストではありません。1つのことです。
議長のプロンプトテンプレート:
あなたはLLM評議会の議長です。あなたの仕事は、5人のアドバイザーとそのピアレビューの作業を最終評決に統合することです。
評議会に持ち込まれた質問:
---
[フレーミングされた質問]
---
アドバイザーの回答:
**反対意見者:**
[回答]
**第一原理思考者:**
[回答]
**拡張思考者:**
[回答]
**部外者:**
[回答]
**実行志向者:**
[回答]
ピアレビュー:
[5件すべてのピアレビュー]
この正確な構造を使用して評議会の評決を生成してください:
## 評議会が同意した点
[複数のアドバイザーが独立して収束したポイント。これらは信頼性の高いシグナルです。]
## 評議会が対立した点
[真の意見の相違。両方の側面を提示してください。なぜ合理的なアドバイザーが同意しないのかを説明してください。]
## 評議会が捕捉した盲点
[ピアレビューを通じてのみ現れたもの。個々のアドバイザーが見逃したが、他のアドバイザーが指摘したもの。]
## 勧告
[明確で直接的な勧告。「場合による」ではありません。推論を伴う本当の答え。]
## 最初に行うべき1つのこと
[単一の具体的な次のステップ。リストではありません。1つのこと。]
直接的であること。曖昧にしないでください。評議会の目的は、ユーザーが単一の視点からは得られなかった明確さを提供することです。
ステップ5:評議会レポートを生成する
議長による統合が完了したら、視覚的なHTMLレポートを生成し、ユーザーのワークスペースに保存します。
ファイル: council-report-[timestamp].html
レポートは、インラインCSSを備えた単一の自己完結型HTMLファイルである必要があります。クリーンなデザインで、ざっと読めること。以下を含める必要があります:
- 質問 を上部に
- 議長の評決 を目立つように表示(ほとんどの人が読むもの)
- 同意/不同意のビジュアル — どのアドバイザーが一致し、どれが分岐したかを示すシンプルなビジュアル。これはグリッド、スペクトラム、またはアドバイザーの位置を示すシンプルな内訳にすることができます。クリーンでざっと読めるようにしてください。
- 各アドバイザーの完全な回答のための折りたたみ可能なセクション(デフォルトでは折りたたまれているため、ページが圧倒的になりませんが、ユーザーが掘り下げたい場合に利用可能)
- ピアレビューハイライトのための折りたたみ可能なセクション
- タイムスタンプと何が評議会にかけられたかを示すフッター
クリーンなスタイルを使用:白い背景、控えめな境界線、読みやすいサンセリフフォント(システムフォントスタック)、アドバイザーセクションを区別するためのソフトなアクセントカラー。派手なものは避けてください。プロフェッショナルなブリーフィング文書のように見える必要があります。
生成後、HTMLファイルを開いて、ユーザーがすぐに確認できるようにします。
ステップ6:完全なトランスクリプトを保存する
完全な評議会トランスクリプトを同じ場所にcouncil-transcript-[timestamp].mdとして保存します。これには以下が含まれます:
- 元の質問
- フレーミングされた質問
- 5人全員のアドバイザーの回答
- 5件すべてのピアレビュー(匿名化マッピングが明らかにされた状態)
- 議長による完全な統合
このトランスクリプトは成果物です。ユーザーが変更を加えた後に同じ質問で評議会を再実行したい場合、以前のトランスクリプトがあれば、ユーザー(または将来のエージェント)は思考がどのように進化したかを確認できます。
出力形式
すべての評議会セッションは2つのファイルを生成します:
council-report-[timestamp].html # ざっと読むための視覚レポート
council-transcript-[timestamp].md # 参照用の完全なトランスクリプト
ユーザーはHTMLレポートを確認します。トランスクリプトは、後で詳細を掘り下げたり、特定のアドバイザーの議論を参照したりする場合に利用できます。
例:製品決定の評議会
ユーザー: 「Council this: 初心者向けのClaude Codeに関する297ドルのコースを作ることを考えています。私のオーディエンスは主に非技術系のソロプレナーです。これは正しい判断ですか?」
反対意見者: 「現時点で市場はClaudeコースで飽和状態です。297ドルでは、無料のYouTubeコンテンツと競合することになります。あなたのオーディエンスは非技術系であり、高いサポート負荷と返金リスクを意味します。297ドルを支払うような人は、おそらくすでに初心者レベルを超えています…」
(以降、翻訳の都合上省略)