⚖️

複数LLMに構造化された議論をさせるCLI「Polylogue」を作った

に公開

tl;dr

  • テーマを入れるだけで複数LLMが構造化された議論をするCLIを作った
  • テーマに応じて6つの合議手法(収束・発散)をLLMが自動選択
  • ペルソナの役割に応じてモデルを自動で割り当て

デモ

npx polylogue "スタートアップの技術選定:TypeScript monorepo vs マイクロサービス"

デモ

使い方

初回実行時にAPI keyの設定が対話的に走るので、事前準備は不要です。

npx polylogue "議論したいテーマ"

プロバイダはAnthropicかOpenAIを選べます。キーを変更したくなったら npx polylogue configure で再設定できます。

なぜ作ったか

Claudeと設計の壁打ちをしていると、1つのモデルだけでは視点が偏るのが気になっていました。ウェブ検索を指示に含めたり、CodexをMCP経由で呼んでレビューさせたりと個別には対処していましたが、体系的に多角的な議論ができているわけではありません。

最近はClaudeのAgent Teamsで複数の視点を持って推論できるようになりましたが、Claude以外のモデルも組み込みたいですし、テーマに応じた議論の構造化やペルソナ設計を毎回手作業でやるのも面倒です。

なので、テーマを入れるだけで構造化された議論が走るCLIを実験的に作ってみました。コードはOSSとして公開しています。

https://github.com/nszknao/polylogue

テーマに応じた合議手法の自動選択

対応している合議手法は6つです。テーマに応じてLLMが自動で選択します。

手法 タイプ 概要
Round Robin 汎用 全員が順番に発言。幅広い探索向き
Devil's Advocate 収束 1人が批判役として全案に反論。提案のストレステスト向き
Dialectical 収束 チーム対立で正反合。明確な対立軸があるテーマ向き
NGT 発散 個別起案→共有→投票。集団思考を避けてアイデア発散
Stepladder 発散 1人ずつ議論に参加。全員の声を均等に拾う
Delphi 収束 匿名で複数ラウンド。予測や不確実なテーマの合意形成向き

最初はRound Robin(全員が順番に発言)だけで作っていたんですが、批判的ペルソナを入れても最終ラウンドで「ニッチだが可能性はある」みたいに軟化してしまいます。全員が同じモデレーターサマリーを読んでから最終見解を述べるので、構造的に収束しやすのだと思われます。Devil's Advocateは批判役が最後まで批判を維持する構造なので、Dialecticalはチーム対立なので妥協しにくい。手法によって議論の力学が変わるのが面白いです。

役割に応じたモデルの割り当て

同じモデルだけでペルソナを分けても、結局似た論点・語彙になってしまうのが気になっていました。実際に試してみると、推論が得意なモデル、発想を広げるのが得意なモデル、ウェブ検索ができるモデルでは議論への貢献の仕方がかなり違います。

そこでペルソナ生成時にLLM自身が model_category(reasoning/creative/web_search)を推奨し、それを実モデルにマッピングする方式にしました。推論役・発散思考役・市場調査役などに、それぞれ適したモデルが自動で割り当たります。

実際の議論の出力例

同じテーマ「LLMの出力をプロダクションコードにそのまま使うべきか?」をRound RobinとDevil's Advocateで走らせてみました。

Round Robin では、最終ラウンドで全員がほぼ同じ結論に収束しました。

生成AIアーキテクト: 結論:本番コードへの「無審査そのまま投入」はNG。ただし低リスク領域に限り、CIで静的解析・テスト・脆弱性/依存監査・生成記録を満たす場合のみ条件付き自動採用は可。高リスク領域は人間レビュー必須。

セキュリティレビュアー: 結論:LLM出力の本番への"無審査投入"は不可。許容されるのは低リスク領域に限る条件付き採用で、CIのSAST/依存関係監査/十分なテストを満たし、生成元記録を残すこと。認証・権限・課金・秘密情報は人手レビュー必須。

5人全員が「原則NG、条件付きOK」で着地しています。モデレーターサマリーを全員が読んでから最終意見を述べる構造なので、自然と合意に寄っていきます。

Devil's Advocate では、批判役(AIプロダクト戦略家)が提案側の前提を突きました。

AIプロダクト戦略家(批判役): 3案とも妥当だが、前提がやや保守的。最大の弱点は「LLM出力=危険」で一括りにしており、リスクはタスク依存なのに一律禁止に寄っている点。短寿命な内部ツールや低権限・低影響の変更でも同じ統制を課すと生産性を毀損。

この批判を受けて、提案側も立場を修正しました。

ソフトウェアアーキテクト: その指摘は妥当です。私の主張は「一律禁止」ではなく「無条件直投入に反対」です。提案を修正し、変更をリスク分類して統制を段階化します。

結論は似ていますが、Devil's Advocateでは「一律禁止は過剰」という批判が最後まで残り、提案側が自ら論点を修正する流れになりました。Round Robinでは出てこなかった「保守的すぎるリスク」という視点が、構造的に引き出されているのが面白いです。

今後やりたいこと

  • 現状はペルソナの役割とモデルの対応が固定なので、議論の文脈や過去のセッションの傾向に応じて動的にモデルを切り替えたい
  • 議論が本当に多角的だったか、合意に流れていないかを定量的に評価する仕組みがほしい。セッション記録はJSONLで残しているので、ここから分析できるはず
  • 自動生成されたペルソナを議論開始前にユーザーが編集・追加・削除できるようにしたい
GitHubで編集を提案

Discussion