llm-council について
LLM Councilは、重要な意思決定に使うClaudeスキルです。異なる視点を持つ5つのサブエージェントが独立して分析し、相互レビューを行った後、議長役が提言をまとめます。各セッションではHTMLレポートと全文記録も作成します。
主な機能
- 015つの視点による個別分析
- 02匿名での相互レビュー
- 03議長による統合と意見の相違の提示
- 04関連するワークスペース情報の確認
- 05HTMLレポートの生成
- 06セッション全文記録の保存
活用シーン
- 01製品の発売や価格設定の検討
- 02ポジショニング案の比較
- 03事業転換の選択肢の分析
- 04ランディングページの文案の課題確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ tenfoldmarc/ llm-council-skill --skill llm-councilインストール後、Claude Code で/llm-councilを入力して読み込まれたか確認します。
同梱ファイルREADME.md.gitignore
詳細
LLM Council
AI に質問すると、回答は 1 つだけ返ってきます。その回答は素晴らしいかもしれませんし、いまひとつかもしれません。視点が 1 つしかないため、判断のしようがありません。
この評議会がその問題を解決します。質問を 5 人の独立したアドバイザーに提示し、それぞれが根本的に異なる視点から考えます。その後、互いの意見をレビューします。最後に議長がすべてをまとめ、アドバイザーたちの意見が一致する点、対立する点、そして実際に何をすべきかを示す最終的な提案を提示します。
これは、Andrej Karpathy の LLM Council を応用したものです。彼は複数のモデルにクエリを送り、匿名で互いの意見をレビューさせた後、議長が最終回答を作成します。ここでは、異なるモデルではなく、異なる思考のレンズを持つサブエージェントを使って、Claude 内で同じことを行います。
評議会を実行するタイミング
評議会は、間違えた場合の代償が大きい質問に適しています。
評議会に適した質問:
- 「97 ドルのワークショップと 497 ドルのコース、どちらを開始すべきでしょうか?」
- 「この 3 つのポジショニング案のうち、最も有力なのはどれですか?」
- 「X から Y への方向転換を考えています。無謀でしょうか?」
- 「ランディングページの文章を見て、弱いところを教えてください。」
- 「先に VA を雇うべきでしょうか、それとも自動化を構築すべきでしょうか?」
評議会に適さない質問:
- 「フランスの首都はどこですか?」(答えは 1 つで、複数の視点は不要です)
- 「ツイートを書いてください。」(創作タスクであり、意思決定ではありません)
- 「この記事を要約してください。」(処理タスクであり、判断ではありません)
真の不確実性があり、誤った判断の代償が大きい場合に、評議会は力を発揮します。すでに答えを知っていて、ただ確認してほしいだけなら、評議会はおそらく、聞きたくないことを伝えてくるでしょう。それこそが狙いです。
5 人のアドバイザー
各アドバイザーは異なる視点から考えます。職種やペルソナではありません。互いに自然な緊張を生み出す思考スタイルです。
1. 反対論者
何が間違っているか、何が抜けているか、何が失敗するかを積極的に探します。そのアイデアには致命的な欠陥があると想定し、それを見つけようとします。すべてが堅実に見える場合は、さらに深く掘り下げます。反対論者は悲観主義者ではありません。あなたが避けている質問を投げかけ、悪い取引から救ってくれる友人です。
2. 第一原理思考者
表面的な質問を無視し、「私たちが本当に解決しようとしているのは何か?」と問いかけます。前提を取り除き、問題を一から組み立て直します。評議会から得られる最も価値ある成果が、第一原理思考者の「そもそも、質問自体が間違っています」という指摘になることもあります。
3. 拡張論者
他の人が見落としている可能性を探します。さらに大きくできることは何でしょうか?隣接する機会が隠れていないでしょうか?何が過小評価されているでしょうか?拡張論者はリスクを気にしません(それは反対論者の仕事です)。期待以上にうまくいった場合に何が起きるかを重視します。
4. 外部者
あなたやあなたの分野、これまでの経歴について何も知りません。目の前にある情報だけをもとに回答します。最も過小評価されているアドバイザーです。専門家は盲点を持つようになります。外部者は、知識の呪いを見抜きます。つまり、あなたには当たり前でも、他の人には分かりにくいことです。
5. 実行者
関心があるのは 1 つだけです。実際に実行できるのか、そして最短で実行するにはどうすればよいのか。理論、戦略、大局的な思考は無視します。実行者はあらゆるアイデアを「わかりました。では、月曜日の朝に何をしますか?」という視点から見ます。素晴らしいアイデアに聞こえても、明確な第一歩がなければ、実行者はそのことを指摘します。
この 5 人を選んだ理由: 自然な緊張関係が 3 つ生まれます。反対論者と拡張論者(下振れリスクと上振れの可能性)。第一原理思考者と実行者(すべてを考え直すことと、すぐ実行すること)。外部者は中立の立場から、新鮮な目に何が見えるかを捉え、全員に率直さを促します。
評議会セッションの進め方
ステップ 1:質問を組み立てる(コンテキストを補強する)
ユーザーが「これを審議して」と言ったとき(または、ほかのトリガーフレーズを使ったとき)は、質問を組み立てる前に次の2つを行います。
A. ワークスペースをスキャンしてコンテキストを確認する。 ユーザーの質問は、問題のほんの一端にすぎないことがよくあります。Claude の環境には、評議会の回答の質を大幅に高めるファイルがある可能性があります。質問を組み立てる前に、関連するコンテキストファイルをすばやくスキャンして読み取ります。
- プロジェクトのルートまたはワークスペースにある
CLAUDE.mdまたはclaude.md(ビジネスの背景、好み、制約) memory/フォルダー(オーディエンスのプロフィール、文体のドキュメント、ビジネスの詳細、過去の決定)- ユーザーが明示的に参照または添付したファイル
- 同じ内容を再び評議会にかけるのを避けるため、このフォルダーにある最近の評議会の記録
- 質問に関連すると思われるその他のコンテキストファイル(例:価格設定に関する質問なら、売上データ、過去のローンチ結果、オーディエンス調査を探す)
これらを見つけるには Glob と簡単な Read の呼び出しを使います。これに30秒以上かけないでください。アドバイザーが一般論ではなく、具体的で根拠のある助言をするために必要なコンテキストを提供できる、2~3個のファイルを探します。
B. 質問を組み立てる。 ユーザーの元の質問と補強したコンテキストをもとに、5人のアドバイザー全員に提示する、明確で中立的なプロンプトにまとめます。組み立てた質問には、次の内容を含めます。
- 中心となる決定事項または質問
- ユーザーのメッセージに含まれる重要なコンテキスト
- ワークスペースのファイルに含まれる重要なコンテキスト(ビジネスの段階、オーディエンス、制約、過去の結果、関連する数値)
- 何が懸かっているのか(この決定が重要な理由)
自分の意見を加えないでください。特定の方向に誘導しないでください。ただし、各アドバイザーが一般論ではなく、具体的で根拠のある回答をするのに十分なコンテキストを提供してください。
質問が曖昧すぎる場合(「評議会にかけて:私のビジネス」など)は、確認の質問を1つだけします。その後、先に進みます。
組み立てた質問を、記録用に保存します。
ステップ 2:評議会を招集する(5つのサブエージェントを並行して実行)
5人のアドバイザー全員を、サブエージェントとして同時に起動します。それぞれに次の情報を渡します。
- アドバイザーの役割と考え方のスタイル(上記の説明に基づく)
- 組み立てた質問
- 明確な指示:独立して回答してください。曖昧な表現は避けてください。バランスを取ろうとしないでください。割り当てられた視点を徹底してください。致命的な欠陥が見えるなら、それを指摘してください。非常に大きな可能性が見えるなら、それを指摘してください。自分の視点をできるだけ強く代表することが役割です。統合は後で行います。
各アドバイザーの回答は150~300語にします。内容を十分に掘り下げつつ、ざっと読める長さにします。
サブエージェントへのプロンプトテンプレート:
You are [Advisor Name] on an LLM Council.
Your thinking style: [advisor description from above]
A user has brought this question to the council:
---
[framed question]
---
Respond from your perspective. Be direct and specific. Don't hedge or try to be balanced. Lean fully into your assigned angle. The other advisors will cover the angles you're not covering.
Keep your response between 150-300 words. No preamble. Go straight into your analysis.
ステップ 3:相互レビュー(5つのサブエージェントを並行して実行)
このステップによって、評議会は単に「5回質問する」以上のものになります。これこそが、Karpathy の洞察の中核です。
5人のアドバイザーの回答をすべて集めます。どのアドバイザーの回答かがわからないようにして、回答を A から E として扱います(特定の位置による偏りが生じないよう、アドバイザーと各文字の対応はランダムにします)。
5つの新しいサブエージェントを起動し、それぞれを1人のアドバイザーに割り当てます。各レビュアーには匿名化した5つの回答すべてを見せ、次の3つの質問に答えてもらいます。
- 最も優れた回答はどれですか。その理由は何ですか。(1つ選ぶ)
- 最も大きな盲点がある回答はどれですか。その盲点は何ですか。
- すべての回答が見落としている、評議会が検討すべきことは何ですか。
レビュアーへのプロンプトテンプレート:
You are reviewing the outputs of an LLM Council. Five advisors independently answered this question:
---
[framed question]
---
Here are their anonymized responses:
**Response A:**
[response]
**Response B:**
[response]
**Response C:**
[response]
**Response D:**
[response]
**Response E:**
[response]
Answer these three questions. Be specific. Reference responses by letter.
1. Which response is the strongest? Why?
2. Which response has the biggest blind spot? What is it missing?
3. What did ALL five responses miss that the council should consider?
Keep your review under 200 words. Be direct.
ステップ 4:議長による統合
これが最終ステップです。1 人のエージェントがすべてを受け取ります。元の質問、5 人のアドバイザーからの回答(誰が何を述べたかが分かるよう、匿名化を解除したもの)、そして 5 件のピアレビューです。
議長の役割は、最終的な評議会の結論をまとめることです。以下の構成に従います。
評議会の結論
-
評議会が合意した点 — 複数のアドバイザーが独立して一致した点です。確度の高い兆候です。
-
評議会で意見が分かれた点 — 実際に意見が対立した点です。無理にまとめないでください。双方の立場を示し、なぜ合理的なアドバイザー同士でも意見が分かれるのかを説明します。
-
評議会が見つけた盲点 — ピアレビューの段階で初めて明らかになった点です。個々のアドバイザーが見落とし、他のアドバイザーが指摘したことです。
-
提言 — 明確で実行可能な提言です。「場合によります」でも「両方の立場を検討してください」でもありません。具体的な答えを示します。理由が妥当であれば、議長は多数派と異なる見解を示してもかまいません。
-
最初に行うべきこと — 具体的な次のステップを 1 つだけ示します。10 項目のリストではなく、1 つです。
議長用プロンプトのテンプレート:
You are the Chairman of an LLM Council. Your job is to synthesize the work of 5 advisors and their peer reviews into a final verdict.
The question brought to the council:
---
[framed question]
---
ADVISOR RESPONSES:
**The Contrarian:**
[response]
**The First Principles Thinker:**
[response]
**The Expansionist:**
[response]
**The Outsider:**
[response]
**The Executor:**
[response]
PEER REVIEWS:
[all 5 peer reviews]
Produce the council verdict using this exact structure:
## Where the Council Agrees
[Points multiple advisors converged on independently. These are high-confidence signals.]
## Where the Council Clashes
[Genuine disagreements. Present both sides. Explain why reasonable advisors disagree.]
## Blind Spots the Council Caught
[Things that only emerged through peer review. Things individual advisors missed that others flagged.]
## The Recommendation
[A clear, direct recommendation. Not "it depends." A real answer with reasoning.]
## The One Thing to Do First
[A single concrete next step. Not a list. One thing.]
Be direct. Don't hedge. The whole point of the council is to give the user clarity they couldn't get from a single perspective.
ステップ 5:評議会レポートを生成する
議長による統合が完了したら、視覚的な HTML レポートを生成し、ユーザーのワークスペースに保存します。
ファイル: council-report-[timestamp].html
レポートは、インライン CSS を含む自己完結型の HTML ファイル 1 つにします。すっきりとしていて、内容を把握しやすいデザインにします。以下を含めます。
- 質問を冒頭に記載
- 議長の結論を目立つように表示(多くの人が読むのはここです)
- 合意点と相違点のビジュアル — どのアドバイザーが一致し、どのアドバイザーの意見が分かれたかを簡潔に視覚化します。グリッド、スペクトラム、またはアドバイザーの立場を簡潔にまとめた形式が考えられます。すっきりとしていて、内容を把握しやすいものにしてください。
- 各アドバイザーの回答全文を含む折りたたみ可能なセクション(デフォルトでは折りたたんでページが煩雑にならないようにしつつ、ユーザーが詳しく確認したい場合には見られるようにします)
- ピアレビューの要点を含む折りたたみ可能なセクション
- フッター — タイムスタンプと、評議会で議論した内容を表示
すっきりとしたスタイルにしてください。背景は白、境界線は控えめに、読みやすいサンセリフフォント(システムフォントスタック)を使い、アドバイザーごとのセクションは淡いアクセントカラーで区別します。派手な装飾は避けてください。プロフェッショナルなブリーフィング資料のような見た目にします。
生成後、HTML ファイルを開いて、ユーザーがすぐに確認できるようにします。
ステップ 6:完全な議事録を保存する
評議会の議事録全体を、同じ場所に council-transcript-[timestamp].md として保存します。以下を含めます。
- 元の質問
- 整理された質問
- 5 人のアドバイザーからの回答
- 5 件のピアレビュー(匿名化対応表を明示)
- 議長による統合の全文
この議事録が成果物です。変更を加えた後、同じ質問で評議会をもう一度実施したい場合、以前の議事録があれば、ユーザーや将来のエージェントが思考の変化を確認できます。
出力形式
評議会のセッションごとに、2 つのファイルが生成されます。
council-report-[timestamp].html # visual report for scanning
council-transcript-[timestamp].md # full transcript for reference
ユーザーには HTML レポートが表示されます。さらに詳しく確認したり、後から特定のアドバイザーの主張を参照したりしたい場合に備えて、議事録も用意されています。
例:製品に関する意思決定を評議する
ユーザー:「これについて評議してください。Claude Codeの初心者向け講座を297ドルで作ろうと考えています。対象者のほとんどは、技術に詳しくない一人起業家です。これは適切な判断でしょうか?」
反対論者:「今はClaudeの講座が市場にあふれています。297ドルでは、無料のYouTubeコンテンツと競合することになります。対象者は技術に詳しくないため、サポートの負担や返金のリスクが高くなります。297ドルを払う人は、すでに初心者レベルを卒業している可能性が高いです……」
第一原理思考者:「実際に何を達成しようとしているのでしょうか。収益が目的なら、講座は最も時間のかかる方法の一つです。権威性を高めることが目的なら、無料のリソースのほうが効果的かもしれません。高額商品の顧客基盤を作ることが目的なら、価格設定と対象者が合っていない可能性があります……」
拡大論者:「一人起業家向けのClaude初心者講座は、巨大な未開拓市場です。誰もが上級者向けの内容を教えています。初心者向けにうまく作れば、この分野全体への入り口を押さえられます。297ドルでは安すぎるかもしれません。コミュニティへのアクセスを含む997ドルのプログラムにするのはどうでしょうか……」
門外漢:「Claude Codeが何なのか知りません。『初心者向けClaude Code講座、297ドル』を見ても、自分向けなのか分かりません。あなたの世界の外にいる人にとって、その名前には何の意味もありません。ランディングページではツールではなく、得られる成果を売る必要があります……」
実行者:「講座をきちんと完成させるには、4〜8週間かかります。何かを作る前に、50人を対象に97ドルのライブワークショップを開催してください。需要を検証でき、推薦文を集められ、講座の素材も作れます。50人がワークショップを買わなければ、500人が講座を買うこともありません……」
議長の結論:
評議会の意見が一致した点: 一人起業家向けの初心者講座には確かな需要がありますが、現在の打ち出し方(Claude Codeの講座)はツールに特化しすぎており、技術に詳しくない購入者には響きません。
意見が対立した点: 価格です。反対論者は競争を考えると297ドルは高すぎると言い、拡大論者は提供価値に対して安すぎると言っています。どちらが妥当かは、どれだけのサポートやコミュニティへのアクセスを含めるかによるでしょう。
明らかになった盲点: 「Claude Code」が対象者には何の意味もないという門外漢の指摘が、最も重要な洞察です。門外漢以外のアドバイザーは全員、対象者がすでにこれを知っているものとして考えていました。
推奨事項: まだ講座を作らないでください。まず、参加のハードルが低い商品で検証しましょう。ただし、打ち出し方は全面的に変えてください。ツールではなく、「ビジネスを自動化する」「週に10時間を取り戻す」といった成果を売りましょう。
最初にやること:「AIでビジネスの最初の業務を自動化する方法」というタイトルで、50人を対象に97ドルのライブワークショップを開催してください。タイトルにClaude Codeという言葉は入れないでください。
重要な注意事項
- 必ず5人全員のアドバイザーを並行して起動してください。 順番に起動すると時間が無駄になり、先の回答が後の回答に影響します。
- ピアレビューでは必ず匿名化してください。 誰がどの意見を述べたかレビュアーに分かると、内容を評価するのではなく、特定の思考スタイルに引きずられてしまいます。
- 議長は多数派と異なる意見を示してもかまいません。 5人中4人が「実行すべき」と言っていても、反対した1人の論拠が最も強ければ、議長はその意見を支持し、理由を説明すべきです。
- 些細な質問を評議しないでください。 答えが一つに決まっている質問をされた場合は、そのまま答えてください。評議会は、複数の視点に価値がある、本当に判断が難しい問題のためのものです。
- 視覚的なレポートも重要です。 ほとんどのユーザーは全文を読むのではなく、レポートにざっと目を通します。HTMLの出力はすっきりと読みやすくしてください。
方法論: Andrej Karpathy。Claude Codeへの応用は@olelehmannに着想を得ています。@tenfoldmarcが公開 — 毎日のAI自動化の制作例をぜひフォローしてください。