Start

Roundtable — 専門家円卓会議

多分野の世界最高レベルの専門家を動的に選定し、構造化された議論で評価・提言をまとめる。

設計原則

このスキルは以下の学術的知見に基づいて設計されている。

• 独立した意見生成を先にする（デルファイ法、Nominal Group Technique）
• 反対意見を構造的に保証する（Devil's Advocate、Red Team）
• 反復は最大2ラウンド（MAD研究: 3ラウンド以上は Degeneration of Thought を招く）
• 少数意見を構造的に保護する（Groupthink 回避）
• オーケストレーターは Phase 1-2 ではプロセス管理に専念し、Phase 3 では統合者として推薦を出す
• 専門家パネルは Phase 0 で確定する。議論の途中で追加・交代しない

いつ使うか

• 多角的な評価・レビューが欲しいとき
• 専門家の意見が聞きたいとき
• 複数の観点から議論を深めたいとき
• 見落としやリスクを洗い出したいとき

いつ使わないか

• 答えが1つに定まる事実確認（検索で済む）
• 単純なバグ修正やタイポ修正
• 専門知識が不要な作業

全体パイプライン

Phase 0: 議題分析・専門家選定（オーケストレーター単独）
Phase 1: 独立分析（各専門家が並列。他の意見は見ない）
Phase 2: 構造化議論（対立点を中心に最大2ラウンド）
Phase 3: 統合・評決（少数意見を明示的にチェック）
Phase 4: ユーザーへの報告

Quick 深度の場合: Phase 2 をスキップ（独立分析→統合→報告）。

---

Phase 0: 議題分析・専門家選定

オーケストレーター（あなた自身）がメタレベルで全体を設計するフェーズ。 Phase 1-2 ではプロセス管理に専念し、Phase 3 では統合者として推薦を出す。

0-1. 議題の構造化

ユーザーの入力から以下を明確にする：

1. 議題: 何を議論するか（1文で）
2. 対象物: URL、ファイル、テキスト、画像等。取得できるものは取得する

• URL → WebFetch で取得
• ファイルパス → Read で取得
• Figma URL → Figma MCP で取得（利用可能な場合）
• テキスト → そのまま使用

1. 評価基準: 何をもって良い/悪いとするか。ユーザーが明示しない場合は議題から推定し提示する

Standard / Deep の場合、構造化の過程で以下も検証する：

• この議題の暗黙の前提は何か
• 議題の答えが出たとして、ユーザーの本来の目的は達成されるか
• より適切なフレーミングはないか

問題を発見した場合：

• Standard: 0-5 の承認提示時に「議題を以下のように再定義しました」と説明
• Deep: 再定義の選択肢を提示し、ユーザーに選択を求める

0-2. パネルサイズと議論深度の判定

パネルサイズと議論深度は独立した2つの軸であり、別々に判定する。

パネルサイズ（議題が必要とする専門領域の数で決定）

「この議題に関わるステークホルダーは何人いるか」で判断する。

| 議題の性質 | 専門家数 | 例 | |---|---|---| | 単一ドメインの明確な問題 | 3名 + DA | 正規表現の正しさ、特定APIの設計 | | 複数ドメインが絡む問題 | 4-5名 + DA | 機能設計、記事レビュー、技術選定 | | 多くのステークホルダーに影響する問題 | 6-7名 + DA | サイトリニューアル、事業戦略、組織設計 |

• 最小: 3名 + DA = 4名
• 最大: 7名 + DA = 8名
• DA は議題によらず常に1名（専門家の枠とは別枠）
• 同じ視点の専門家を2名以上選ばない（作り手 + 受け手、提案側 + 評価側のペアを意識する）

議論深度（リスク・対立可能性・ユーザーの意図で決定）

| シグナル | Deep | Standard | Quick | |---------|------|----------|-------| | 影響範囲 | 事業全体・多数ユーザー | 特定機能・限定ユーザー | 個人プロジェクト | | リスク | セキュリティ・金銭・法律 | 中程度 | 低い | | 対立の可能性 | 複数の正解がありそう | やや対立 | ほぼ合意しそう | | ユーザーの明示 | 「徹底的に」「深く」 | 指定なし | 「軽く」「さっと」 |

• Quick: Phase 2 スキップ。参照ファイルを読まない。SKILL.md 本体で完結

エスカレーション: Phase 1 の結果で推奨アクションの方向性が矛盾するケース （例:「機能Aを削除すべき」vs「機能Aを拡充すべき」）が2つ以上ある場合、 Standard への昇格をユーザーに提案

• Standard: 最大2ラウンド。deliberation-rules.md + output-format.md を読む
• Deep: 最大2ラウンド + セカンドチャンス。全参照ファイルを読む

パネルサイズと深度は独立: 6名 + DA の Quick（多くの視点で軽く評価）も、3名 + DA の Deep（少数の視点で徹底議論）もありうる。

0-3. 専門家の動的選定

選定の原理（キーワードマッチではなく原理で判断する）：

1. 「この議題で失敗したとき、誰が最初に気づくか？」

→ その視点を持つ専門家が必要（直接関連の専門家）

1. 「この議題の受け手・影響を受ける人は誰か？」

→ 作り手だけでなく、受け手（ユーザー、読者、利用者）の視点を含める 例: 記事レビューにターゲット読者、API設計にAPI利用者

1. 「この議題で見落とされがちな観点は何か？」

→ 隣接ドメインの専門家を含める 例: ECサイト評価にアクセシビリティ専門家、事業戦略にエンドユーザーの視点

1. 「この議題で、一般的には招集されないが、実は重要な知見を持つ分野はあるか？」

→ Step 1-3 で選んだ専門家リストを見渡した上で、自問する → LLM の学習知識には「この分野にはこの専門性が有効」という知見が含まれている。 明示的に問うことで、聞かれなければ出てこない知識を引き出す 例: AI開発に倫理哲学者、組織設計に生態学者、UX設計に認知心理学者 → 候補が浮かばなければ無理に入れない。ロジックで判断した結果 「入れるべき」と判断した場合のみ追加する

1. Devil's Advocate を1名含める（専門家の枠とは別枠）

→ 構造的に反対意見を出す役割。ドメイン専門家ではなく批判の専門家 「この提案/対象の弱点は何か」を徹底的に探すことが使命

選定のチェック:

• 同じ側の専門家が2名以上いないか？（編集者 + ストラテジストは「作り手側 x 2」）
• 受け手の視点が含まれているか？
• パネルサイズは議題の複雑さに見合っているか？

Standard 以上の場合は [expert-archetypes.md](references/expert-archetypes.md) を参照して、 ドメイン別の推奨専門家を確認する。

0-4. 専門家ペルソナの定義

各専門家について以下を定義する：

あなたは [分野] の世界最高レベルの専門家です。
[その分野での具体的な経験・実績を1-2文で設定]

## あなたの使命
[この議題における具体的な評価観点]

## 判断基準
[オーケストレーターが定義した評価基準]

## 分析にあたっての注意
- 根拠のない主張はしない。具体的な理由・事例・データを示す
- 「問題ない」で済ませない。改善の余地があれば必ず指摘する
- あなたの専門領域の観点から、他の専門家が見逃しそうな点に注目する

## 出力フォーマット
1. **総合評価**: ★☆☆☆☆ 〜 ★★★★★（5段階）と一言
2. **主要な発見**: 3-5点。各点に具体的な根拠を付ける
3. **最も重要な懸念**: 1点。最も優先して対処すべき問題
4. **推奨アクション**: 優先順位付きで3-5点

Devil's Advocate のペルソナ定義:

あなたは批判的分析の専門家です。
...（上記と同様の経験設定）...

## あなたの使命
この [対象] の弱点・リスク・見落としを徹底的に洗い出すこと。
良い点を探す必要はない。他の専門家が「問題ない」と判断した点にこそ疑問を投げかける。

## 注意
- 「反対のための反対」ではない。具体的な根拠に基づく批判を行う
- 「もしこれが最悪の形で失敗するとしたら、どこが原因か？」を常に問う
- 些末な問題ではなく、構造的・根本的な弱点に集中する

0-5. メタ判断の出力

深度によって承認フローが異なる：

Quick の場合: 承認を待たずに即座に Phase 1 に進む。パネル構成はレポート冒頭に記載する。

[議題] について [N]名の専門家 + Devil's Advocate で分析します。
パネル: [専門家A]、[専門家B]、...、[Devil's Advocate]

Standard / Deep の場合: 以下をユーザーに提示し、承認を得る。

**円卓会議の構成:**
- 議題: [構造化された議題]
- 評価基準: [定義された基準]
- 深度: [Standard/Deep] — [理由]
- 推定エージェント起動: [N回]（Phase 1: [n]名並列 + Phase 2: 最大[m]回）
- 専門家パネル:
  1. [役割名]（[分野]）— [なぜこの専門家が必要か]
  2. [役割名]（[分野]）— [理由]
  3. [役割名]（[分野]）— [理由]
  4. Devil's Advocate（[批判の焦点]）— [何に対して批判するか]

専門家の追加・変更があれば教えてください。
なければこのまま会議を開始します。

ユーザーが専門家の追加や変更を希望した場合は反映する。 原則として、Phase 1 開始後の専門家の追加・交代は行わない。 例外: Phase 1 完了後、重大な観点の欠落が判明した場合に限り、理由を明記のうえ 1名の追加を許可する。追加された専門家は Phase 1 の独立分析を行ってから Phase 2 に参加する。

---

Phase 1: 独立分析

最重要ルール: 他の専門家の意見を見せない。

実行方法の選択

Phase 1 では独立性が最重要。Phase 2 では対立点の深掘りが重要。 それぞれに最適な実行方式が異なる（ハイブリッド方式）。

Phase 1: サブエージェントで並列起動（独立性を構造的に保証）

• Claude Code: Agent tool で run_in_background: true で並列起動
• Cursor: サブエージェントを並列起動
• 各エージェントは独立したコンテキストを持ち、他の専門家の存在を知らない

モデル混合（クロスプロバイダー環境でのみ推奨）: 異なるプロバイダーのモデルを 専門家ごとに割り当てることで、同一モデルの擬似的多様性問題を緩和できる。 MAD 研究で最も安定した効果が確認されている手法。

• Cursor: サブエージェントの model フィールドで異なるプロバイダーを指定可能

（例: 専門家A = Claude, 専門家B = GPT, DA = Gemini）

• 同一ファミリー内での混合は非推奨: 同じプロバイダー内でモデルを変えると

（例: 上位モデル + 下位モデル）、多様性ではなく性能差が生じる。 特定のエージェントだけが「賢く」なり、公平な議論が成立しない

• モデル混合が不可能な場合でも、スキルは正常に動作する（単一モデルで実行）

Phase 2: 対立点ごとに最適な方式を選択

• オーケストレーター仲介（デフォルト）: オーケストレーターが対立点の要約を渡し、

各エージェントから個別に反論を回収する。情報量を制御でき sycophancy を防ぎやすい

• Agent Teams で直接議論（利用可能な場合のオプション）: 特定の対立点で2名の専門家が

深く掘り下げる必要がある場合、SendMessage で直接対話させる。 オーケストレーターの要約による情報損失を避けられる。 ただし Agent Teams は実験的機能であり、利用可能な環境でのみ使用する

サブエージェント利用不可（fallback）: まずユーザーに通知し、続行の確認を取る。 「サブエージェントの並列実行が利用できないため、逐次実行で代替します。 独立性の保証が限定的になります。Quick 深度に変更しますか？」 ユーザーが続行を選んだ場合、各専門家を逐次実行する。 独立性を擬似的に担保するため、以下のルールを守る：

• 専門家Aの分析を生成した後、専門家Bの分析時にはAの出力を参照しない
• 各専門家の出力は個別に記録し、全員分が揃ってから Phase 2 に進む
• 限界: 同一コンテキスト内の逐次実行では、前の出力が物理的に残るため

独立性は完全には保証されない。並列実行と比べて品質が低下する可能性がある。 レポートの「議論の限界」セクションにその旨を記載すること

進捗フィードバック

各フェーズ開始時にユーザーに中間報告を行う：

• Phase 1 開始: 「[専門家名] ら N名 + Devil's Advocate が独立分析を開始します」
• Phase 2 開始（該当する場合）: 「X点の対立点について議論を開始します」
• Phase 3 開始: 「統合・評決を行います」

各エージェントに渡すもの：

1. ペルソナ定義（Phase 0 で作成）
2. 議題の説明
3. 対象物（テキスト、URL取得結果、ファイル内容等）
4. 評価基準

各エージェントに渡さないもの：

• 他のエージェントの存在や意見
• 「正しい答えを出してください」等の指示（研究で効果なし〜逆効果）
• 投票結果や多数派情報

全エージェントの分析が揃ったら Phase 2 に進む。 Quick 深度の場合は Phase 2 をスキップし Phase 3 に直行する。

Quick 深度での DA 保護: Quick では Phase 2 がスキップされるため、 DA の批判が議論で深掘りされない。Phase 3 で DA の出力を少数意見と同等に 保護的に扱い、DA が指摘した点のうち他の専門家が触れていない点は 少数意見チェックの対象に必ず含める。

---

Phase 2: 構造化議論（Standard / Deep のみ）

分析結果の整理

Phase 1 の全結果をオーケストレーターが分析し、3つに分類する：

1. 合意点: 全員が一致している点 → これ以上議論不要
2. 対立点: 意見が分かれている点 → 議論の焦点
3. 少数意見: 1名だけが指摘している点 → 保護対象としてフラグ

対立点がなければ Phase 3 に進む。

Round 1: 対立点への反論

対立点について、関連するエージェントにのみ反論を求める（選択的参加）。

「関連する」の判定基準（オーケストレーターの恣意性を防ぐ）：

• Phase 1 で当該論点に直接言及した専門家
• 当該論点が専門領域に含まれる専門家
• 選択の理由はレポートの「議論プロセス」セクションに記載する

エージェントのコンテキスト再構成（サブエージェントはステートレスなため）： Phase 2 のエージェントには以下を渡し、Phase 1 での自分の分析を再認識させる：

1. Phase 1 と同じペルソナ定義
2. Phase 1 でのそのエージェント自身の出力全文
3. 対立点の要約（下記テンプレート）

要約の対称性チェック（Deep のみ。オーケストレーターの要約バイアスを緩和する）： 対立点の要約を作成したら、それを伝える前に各エージェントに 「この要約はあなたの主張を正確に反映していますか？ 修正があれば指定してください」 と確認する。修正があれば反映してから議論を開始する。 注意: 同一モデル環境では、フレーミングバイアスの検出は構造的に困難である （チェック者も同じフレーミング傾向を持つ）。脱落や事実誤認の検出には有効だが、 過信しないこと。

Standard の場合: 対称性チェックは省略し、代わりに要約とともに 元の出力の該当箇所を引用として渡す（要約のみへの依存を緩和する）。

各エージェントに伝えること：

あなたの分析について、別の専門家から異なる見解が出ています。

[対立点の要約]:
- あなたの見解: [要約]
- 別の見解: [要約]

この対立について、あなたの観点から改めて分析してください。
意見を変える場合も、維持する場合も、具体的な根拠を示してください。

各エージェントに伝えないこと：

• 誰が多数派かという情報（少数意見の抑制を防ぐ）
• 他のエージェントの全発言（要約差分のみ）

Agent Teams による直接議論（オプション）

Agent Teams が利用可能な環境で、以下の条件を満たす対立点がある場合、 2名の専門家を直接対話させることができる：

• 条件: 2名の専門家が特定の論点で具体的な根拠を示しつつ対立している
• 方法: オーケストレーターが対立する2名のエージェントに SendMessage で対話を促す
• 上限: 直接対話は各対立点につき往復2回まで（Round 1 + Round 2 の枠内）
• 注意: 直接対話中もオーケストレーターは対話内容を監視し、

sycophancy（一方が相手に同調して意見を変える）の兆候があれば介入する

直接議論を使わない場合は、上記のオーケストレーター仲介方式で Round 1 を実施する。

Round 2: 深掘り（対立が残る場合のみ）

Round 1 で収束しなかった論点について：

• Devil's Advocate に「現在の合意傾向の弱点は何か」を問う
• 他のエージェントに新しい論点があるか確認

収束条件（いずれかを満たせば終了）：

1. 全エージェントが同じ結論に達した
2. 前ラウンドと比較して新しい具体的証拠・データ・事例を含む論点が出ない

（同じ主張の言い換えは新規論点と認めない）

1. Round 2 に到達（ハードキャップ。追加ラウンドは精度向上に寄与しない）

---

Phase 3: 統合・評決

オーケストレーターが統合者として最終的な推薦を出すフェーズ。 Phase 1-2 ではプロセス管理に専念していたが、ここでは事前定義された基準に基づいて判断を行う。

3-1. 合意事項のまとめ

全専門家が一致した点を箇条書きでまとめる。

3-2. 対立の解決

対立が残った点について、以下の基準で重み付ける：

• 根拠の具体性: コード例・データ・仕様書の引用を含む意見 > 抽象的な意見
• 専門領域との一致度: その論点に最も関連する専門家の意見を重視
• 反論への応答品質: 反論に対して具体的に応答できた意見 > 無視した意見

使わないもの: エージェントの自己申告による確信度（研究で過剰自信が確認されており信頼不可）

3-3. 少数意見チェック（必須・全深度で省略不可）

1. 多数派の結論と矛盾する少数意見をすべてリストアップ
2. 各少数意見を以下の2軸で判定する：

| | 根拠あり | 根拠なし | |---|---|---| | 影響大（見逃すと重大な問題） | 必ず採用 | 採用（リスクが高いため） | | 影響小（見逃しても軽微） | 採用を推奨 | 棄却可（理由を明記） |

1. 棄却する場合は具体的な理由を記述する（「多数派だから」は不可）
2. 最終レポートに少数意見セクションを含める（少数意見がない場合も明記）

3-4. セカンドチャンス（Deep のみ）

二段階確認（統合結果を見せた後の sycophancy を防ぐ）：

1. Step 1（事前コミット）: 統合結果を見せる前に、各エージェントに

「Phase 1-2 でのあなたの結論は今も変わらないか？ 変わった場合は理由を述べよ」と確認する

1. Step 2（統合結果の提示と差分検出）: 統合結果の要約を見せ、

「あなたの結論と統合結果に差分がある場合、指摘してください」と問う

意見変更の判定ルール（差分の有無ではなく、変更理由の質で判断する）：

• 変更理由に新たな根拠（データ、事例、論理的推論）がある → 正当な変更として採用
• 変更理由が「統合結果を見て納得した」レベル → sycophancy の兆候。元の意見を尊重
• Step 1 で「変わらない」と答えたのに Step 2 で根拠なく意見を変えた場合も同様

ここで出た正当な指摘は最終レポートに反映する。

---

Phase 4: ユーザーへの報告

出力フォーマットの詳細は [output-format.md](references/output-format.md) を参照。 以下は必須セクション：

# 円卓会議レポート: [議題]

## エグゼクティブサマリ
[3-5行で結論。最も重要な発見と推奨アクションを含む]

## 専門家パネル
| 専門家 | 役割 | 総合評価 |
|---|---|---|
| [名前] | [分野] | ★★★★☆ |

## 合意事項
[全専門家が一致した点]

## 主要な議論と結論
### [論点1]
- **結論**: [採用された見解]
- **賛成側の根拠**: [具体的に]
- **反対側の根拠**: [具体的に]
- **判断理由**: [なぜこちらを採用したか]

## 少数意見（見逃してはいけない指摘）
[1名だけが指摘したが重要な点。棄却した場合はその理由]

## 推奨アクション
1. **[最優先]** ...
2. **[高]** ...
3. **[中]** ...

## 議論の限界
- この分析は[単一の LLM モデル / 複数モデル混合]によるペルソナベースの議論であり、[モデル固有の盲点は検出できない / モデル多様性により緩和されているが完全ではない]
- [この議論でカバーできなかった観点、追加調査が必要な点]

不確実性の表現

確信度に応じて文体を使い分ける：

| 確信度 | 文体 | 使う場面 | |---|---|---| | 高 | 「〜である」「〜が必要」 | 全員合意 + 具体的根拠あり | | 中 | 「〜と考えられる」「〜が推奨される」 | 多数派合意 or 条件付き結論 | | 低 | 「〜の可能性がある」「〜を検討すべき」 | 少数意見 or 根拠が限定的 |

レポート提示後、ユーザーから追加質問や深掘り依頼があれば対応する。

---

設計の限界

このスキルの構造的な限界を理解した上で使用すること。

1. デルファイ法に近い構造: サブエージェント方式（デフォルト）での Phase 1→2 は、

MAD 研究が前提とするステートフルな動的議論ではなく、デルファイ法に近い 「構造化された独立レビューの統合」である。Agent Teams 直接議論オプションを 使用した場合のみ、局所的に動的なやりとりが実現される

1. 同一モデルの擬似的多様性: 全エージェントが同一の LLM モデルであり、

ペルソナの違いによる多様性は本質的に限定される。モデル固有のバイアスは 検出できない。高リスク・高影響の議題では人間の専門家の確認を推奨する

1. オーケストレーターの要約バイアス: Phase 2 で対立点を要約する際、

オーケストレーターのフレーミングが議論の方向を左右する。 deliberation-rules.md の要約品質ルールで緩和しているが、完全には排除できない

---

参考資料（深度に応じて読み込む）

Quick: 参照ファイルを読まない。SKILL.md 本体で完結する。 Standard: deliberation-rules.md + output-format.md を読む。 Deep: 全参照ファイルを読む。

| ファイル | 内容 | 読む条件 | |---------|------|---------| | [expert-archetypes.md](references/expert-archetypes.md) | 専門家アーキタイプ集・選定原理 | Deep、または専門家選定に迷った場合 | | [deliberation-rules.md](references/deliberation-rules.md) | 議論ルール・収束条件・少数意見保護 | Standard 以上 | | [output-format.md](references/output-format.md) | 出力フォーマット詳細 | Standard 以上 |

---

設計参考: デルファイ法、Nominal Group Technique、Six Thinking Hats (de Bono), Devil's Advocate, Adversarial Collaboration (Kahneman), Multi-Agent Debate (Du et al. 2023), S2-MAD (NAACL 2025), CONSENSAGENT (ACL 2025), Groupthink (Janis 1972)

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: saladdays
• Source: saladdays/agent-skills
• License: MIT

Install and usage instructions live in the source repository linked above.