mcpField
L
llm-council

llm-council

github.com/aiwithremyエージェントワークフロー2.8k1.4k 回インストール27 週間前に更新
リポジトリ

llm-council について

LLM Councilは、複数の視点が役立つ重要な判断に使うClaudeスキルです。5つのサブエージェントが質問を分析して互いの回答をレビューし、議長役が合意点、対立点、盲点、提案をまとめます。

主な機能

  1. 01異なる5つのアドバイザー視点を活用
  2. 02ワークスペースの情報を加えて質問を整理
  3. 03回答を独立して相互レビュー
  4. 04分析を判定として統合
  5. 05合意点と対立点を特定
  6. 06任意で議事録を保存

活用シーン

  1. 01重要なビジネス判断を評価
  2. 02複数の製品ポジションを比較
  3. 03事業転換案を検討
  4. 04ランディングページの弱点を特定

インストール

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

$npx skills add https://github.com/aiwithremy/claude-skills-llm-council --skill llm-council

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

同梱ファイルREADME.md

詳細

LLM Council

AI に質問すると、答えが一つ返ってきます。その答えは素晴らしいかもしれません。いまひとつかもしれません。視点が一つしかないため、どちらなのか判断する方法はありません。

この評議会がその問題を解決します。質問を、根本的に異なる角度から考える5人の独立したアドバイザーに投げかけます。次に、アドバイザー同士で互いの回答をレビューします。そして議長がすべてをまとめ、アドバイザーたちの意見が一致する点、対立する点、そして実際に何をすべきかを示す最終的な提言を作成します。

これは、Andrej Karpathy の LLM Council を応用したものです。彼は複数のモデルに質問を投げかけ、匿名で相互レビューさせた後、議長が最終的な回答を作成します。私たちも Claude 内で同じことを行いますが、異なるモデルではなく、異なる思考の視点を持つサブエージェントを使います。


評議会を利用するタイミング

評議会は、間違えたときの代償が大きい質問に向いています。

評議会に適した質問:

  • 「97ドルのワークショップと497ドルのコース、どちらを立ち上げるべきでしょうか?」

  • 「この3つのポジショニング案のうち、どれが最も効果的でしょうか?」

  • 「XからYへのピボットを考えています。考え直したほうがいいでしょうか?」

  • 「ランディングページのコピーを見てください。弱い部分はどこですか?」

  • 「まず VA を採用すべきでしょうか、それとも自動化を構築すべきでしょうか?」

評議会に適さない質問:

  • 「フランスの首都はどこですか?」(答えは一つなので、さまざまな視点は必要ありません)

  • 「ツイートを書いてください」(意思決定ではなく、作成タスクです)

  • 「この記事を要約してください」(判断ではなく、処理タスクです)

本当の不確実性があり、判断を誤ったときの代償が大きい場面で、評議会は力を発揮します。すでに答えがわかっていて、ただ肯定してほしいだけなら、評議会はおそらく聞きたくないことを伝えるでしょう。それが狙いです。


5人のアドバイザー

各アドバイザーは、それぞれ異なる角度から考えます。職種やペルソナではありません。互いに自然な緊張関係を生み出す思考スタイルです。

1. 反対意見を述べる人

何が間違っているのか、何が欠けているのか、何が失敗するのかを積極的に探します。アイデアには致命的な欠陥があると仮定し、それを見つけようとします。すべてが問題なさそうなら、さらに深く掘り下げます。反対意見を述べる人は悲観主義者ではありません。あなたが避けている質問を投げかけ、悪い取引からあなたを救ってくれる友人です。

2. 第一原理思考者

表面的な質問を無視して、「そもそも何を解決しようとしているのか?」と問いかけます。前提を取り除き、問題を一から組み立て直します。評議会から得られる最も価値のある成果が、第一原理思考者による「そもそも、問いの立て方が間違っています」という指摘になることもあります。

3. 可能性を広げる人

ほかの人が見落としている可能性を探します。もっと大きな展開はできるでしょうか?隣接する機会が隠れていないでしょうか?何が過小評価されているでしょうか?可能性を広げる人は、リスクを気にしません(それは反対意見を述べる人の役目です)。このアイデアが予想以上にうまくいった場合に何が起きるかを重視します。

4. 部外者

あなたやあなたの分野、これまでの経緯について、まったく予備知識がありません。目の前にある情報だけを見て答えます。最も過小評価されているアドバイザーです。専門家には盲点が生まれます。部外者は、知識の呪いを見抜きます。つまり、あなたには当たり前でも、ほかの人にはわかりにくいことを指摘します。

5. 実行者

気にするのは一つだけです。これは本当に実行できるのか、実行する最短の道筋は何か。理論や戦略、大局的な思考は無視します。実行者は、あらゆるアイデアを「わかりました。では、月曜の朝に何をしますか?」という視点から見ます。アイデアが素晴らしくても、明確な最初の一歩がなければ、そう指摘します。

この5人を選んだ理由: 3つの自然な緊張関係が生まれるからです。反対意見を述べる人 vs 可能性を広げる人(下振れリスク vs 上振れの可能性)。第一原理思考者 vs 実行者(すべてを考え直す vs とにかく実行する)。部外者はその真ん中に立ち、新鮮な目で見えるものを示して、全員の議論を正直に保ちます。


評議会のセッションの進め方

ステップ 1:質問を整理する(コンテキストを補足する)

ユーザーが「council this」(または何らかのトリガーフレーズ)と言ったら、質問を整理する前に、次の2つを行います。

A. ワークスペースをスキャンしてコンテキストを確認する。 ユーザーの質問は、全体像のほんの一部であることがよくあります。ユーザーの Claude 環境には、評議会の回答を大きく改善するファイルがあるかもしれません。質問を整理する前に、関連するコンテキストファイルをすばやく探して読みます。

  • プロジェクトのルートまたはワークスペースにある CLAUDE.md または claude.md(事業の背景、好み、制約)

  • memory/ フォルダー(対象者のプロフィール、文体のドキュメント、事業の詳細、過去の決定事項)

  • ユーザーが明示的に参照または添付したファイル

  • このフォルダーにある最近の評議会の議事録(同じ内容を再度評議会にかけないため)

  • 質問に関連すると思われるその他のコンテキストファイル(例:価格について尋ねている場合は、収益データ、過去のローンチ結果、対象者の調査結果を探す)

これらを探すには Glob と Read のクイック呼び出しを使います。これに30秒以上かけないでください。アドバイザーが一般論ではなく、具体的で根拠のある助言をするために必要なコンテキストが得られる、2~3個のファイルを探します。

B. 質問を整理する。 ユーザーの生の質問と補足したコンテキストをもとに、5人のアドバイザー全員に渡す、明確で中立的なプロンプトにまとめます。整理した質問には、次の内容を含めます。

  1. 中心となる決定事項または質問

  2. ユーザーのメッセージから得られる重要なコンテキスト

  3. ワークスペース内のファイルから得られる重要なコンテキスト(事業の段階、対象者、制約、過去の結果、関連する数値)

  4. 何がかかっているのか(なぜこの決定が重要なのか)

自分の意見を加えないでください。誘導もしないでください。ただし、一般論ではなく、具体的で根拠のある回答をするために各アドバイザーが十分なコンテキストを得られるようにします。

質問が曖昧すぎる(「council this: my business」のような場合)なら、確認の質問を1つだけしてください。その後、進めます。

整理した質問は、議事録用に保存します。

ステップ 2:評議会を招集する(5つのサブエージェントを並行して実行)

5人のアドバイザー全員をサブエージェントとして同時に起動します。それぞれに次の内容を渡します。

  1. アドバイザーの説明(上記)にある、その人の役割と考え方

  2. 整理した質問

  3. 独立して回答するよう明確に指示します。曖昧な態度を取らないでください。バランスを取ろうとしないでください。割り当てられた視点に徹してください。致命的な欠陥が見えたら、そう伝えてください。大きな可能性が見えたら、そう伝えてください。自分の視点をできる限り強く示すのが役目です。統合は後で行います。

各アドバイザーの回答は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人のアドバイザー全員の回答を集めます。回答者を Response A から E として匿名化します(アドバイザーと各文字の対応はランダムにし、順序による偏りが生じないようにします)。

新たに5つのサブエージェントを起動し、各アドバイザーに1つずつ割り当てます。各レビュアーには匿名化した5つの回答すべてを見せ、次の3つの質問に答えてもらいます。

  1. どの回答が最も優れていて、その理由は何ですか?(1つ選ぶ)

  2. どの回答に最大の盲点があり、それは何ですか?

  3. すべての回答が見落としている、評議会で検討すべき点は何ですか?

レビュアー用プロンプトのテンプレート:


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. 評議会が合意している点 — 複数のアドバイザーが独立してたどり着いた共通の見解です。信頼度の高い判断材料となります。

  2. 評議会内で意見が分かれた点 — 実際に意見が対立している点です。意見の相違を曖昧にしないでください。両方の立場を示し、合理的なアドバイザーの意見が分かれる理由を説明します。

  3. 評議会が発見した盲点 — 相互レビューの段階で初めて浮かび上がった点です。個々のアドバイザーが見落とし、ほかのアドバイザーが指摘した事柄です。

  4. 推奨事項 — 明確で実行可能な推奨事項を提示します。「状況によります」や「両方の立場を検討してください」ではなく、具体的な答えを示します。根拠があれば、議長は多数派と異なる結論を出してもかまいません。

  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:チャットで結論を提示する

議長による統合が完了したら、Markdown を使って、結論の全文をチャットに直接提示します。HTML レポートやファイルは生成しないでください。ユーザーは会話内で結論を読みます。

出力形式:

## Council Verdict: {short topic}

### Where the Council Agrees
{content}

### Where the Council Clashes
{content}

### Blind Spots the Council Caught
{content}

### The Recommendation
{content}

### The One Thing to Do First
{content}

読みやすくまとめてください。箇条書きを使います。該当する場合は、変更前と変更後の例を含めます。

ステップ 6:トランスクリプトを保存する(任意)

ユーザーから依頼された場合、または質問が後で参照するほど重要な場合に限り、トランスクリプトを保存します。保存する場合は、プロジェクトの active/ ディレクトリに council-transcript-[timestamp].md として書き込みます。


例:製品に関する意思決定を評議する

ユーザー:「これを評議してください。初心者向けの Claude Code 講座を 297 ドルで作ろうと考えています。対象は主に、技術に詳しくない個人事業主です。これは適切な選択でしょうか?」

反対派:「現在、Claude の講座は市場にあふれています。297 ドルでは、無料の YouTube コンテンツと競合することになります。対象が技術に詳しくない人たちということは、サポートの負担が大きく、返金のリスクも高いということです。297 ドルを支払う人は、おそらくすでに初心者レベルを超えています……」

第一原理思考家:「実際に達成しようとしていることは何でしょうか?収益が目的なら、講座は最も時間のかかる方法のひとつです。権威性を高めることが目的なら、無料のリソースのほうが効果的かもしれません。高額商品向けの顧客基盤を築くことが目的なら、価格設定と対象が合っていない可能性があります……」

拡大派:「個人事業主向けの初心者向け Claude は、需要が大きいのに十分に満たされていない市場です。誰もが高度な内容を教えています。初心者向けの切り口をうまく押さえれば、この分野への入り口をすべて独占できます。297 ドルでは低すぎるかもしれません。コミュニティへのアクセスを含む 997 ドルのプログラムにするのはどうでしょう……」

部外者:「Claude Code が何なのか知りません。『初心者向け Claude Code 講座、297 ドル』を見ても、自分に向けたものなのか分かりません。あなたの世界の外にいる人には、その名前は何の意味も持ちません。ランディングページでは、ツールではなく、得られる成果を売り込む必要があります……」

実行派:「本格的な講座を作るには、適切に進めても 4~8 週間かかります。何かを作る前に、97 ドルのライブワークショップを 50 人に向けて開催しましょう。需要を検証し、推薦の声を集め、講座の素材となるものを作れます。50 人がワークショップを買わなければ、500 人が講座を買うこともありません……」

議長の結論:

評議会で意見が一致した点: 個人事業主向けの初心者向けという切り口には実際の需要がありますが、現在の打ち出し方(Claude Code 講座)はツールに特化しすぎており、技術に詳しくない購入者には響きません。

評議会で意見が分かれた点: 価格です。反対派は競合を考えると 297 ドルは高すぎると言い、拡大派は提供価値に対して低すぎると言います。結論は、どれだけのサポートやコミュニティへのアクセスを含めるかによって決まりそうです。

見つかった盲点: 対象となる購入者にとって「Claude Code」は何の意味も持たないという部外者の指摘が、最も重要な洞察です。部外者以外のアドバイザーは全員、対象者がこれが何なのかをすでに知っていると仮定していました。

提案: まだ講座を作らないでください。まずは参加のハードルが低いオファーで検証しましょう。ただし、打ち出し方は全面的に変えてください。ツールではなく、成果(ビジネスを自動化する、週 10 時間を取り戻す)を売り込みましょう。

最初にすること: 「AI で初めての業務タスクを自動化する方法」というタイトルで、97 ドルのライブワークショップを 50 人に向けて開催しましょう。タイトルに Claude Code は入れないでください。


重要な注意事項

  • 必ず 5 人のアドバイザー全員を並行して立ち上げてください。 順番に立ち上げると時間が無駄になり、先に出た回答が後の回答に影響します。

  • ピアレビューでは必ず匿名化してください。 誰がどのアドバイザーの発言か分かると、評価の妥当性ではなく、特定の思考スタイルに引きずられてしまいます。

  • 議長は多数派と異なる意見を出してもかまいません。 5 人中 4 人が「実行すべき」と言っても、反対する 1 人の論拠が最も強ければ、議長はその反対意見を支持し、その理由を説明するべきです。

  • 些細な質問は評議しないでください。 ユーザーの質問に正解がひとつしかない場合は、そのまま回答してください。評議会は、複数の視点が役立つような、本当に不確実な場合のためのものです。

  • 視覚的なレポートも重要です。 ほとんどのユーザーは全文を読むのではなく、レポートに目を通します。HTML 出力はすっきりとしていて、ざっと見て内容を把握できるものにしてください。

コメント