| name | start |
| description | 多分野の専門家を動的に選定し、構造化された議論で多角的な評価・提言をまとめる。 「専門家に聞きたい」「レビューして」「多角的に評価して」「議論して」等で使用。 Webサイト、コード、事業戦略、デザイン、組織設計等あらゆるドメインに対応。
|
| argument-hint | [議題や対象（URL、ファイル、テキスト等）] |
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文で）
- 対象物: URL、ファイル、テキスト、画像等。取得できるものは取得する
- URL → WebFetch で取得
- ファイルパス → Read で取得
- Figma URL → Figma MCP で取得（利用可能な場合）
- テキスト → そのまま使用
- 評価基準: 何をもって良い/悪いとするか。ユーザーが明示しない場合は議題から推定し提示する
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. 専門家の動的選定
選定の原理（キーワードマッチではなく原理で判断する）：
-
「この議題で失敗したとき、誰が最初に気づくか？」
→ その視点を持つ専門家が必要（直接関連の専門家）
-
「この議題の受け手・影響を受ける人は誰か？」
→ 作り手だけでなく、受け手（ユーザー、読者、利用者）の視点を含める
例: 記事レビューにターゲット読者、API設計にAPI利用者
-
「この議題で見落とされがちな観点は何か？」
→ 隣接ドメインの専門家を含める
例: ECサイト評価にアクセシビリティ専門家、事業戦略にエンドユーザーの視点
-
「この議題で、一般的には招集されないが、実は重要な知見を持つ分野はあるか？」
→ Step 1-3 で選んだ専門家リストを見渡した上で、自問する
→ LLM の学習知識には「この分野にはこの専門性が有効」という知見が含まれている。
明示的に問うことで、聞かれなければ出てこない知識を引き出す
例: AI開発に倫理哲学者、組織設計に生態学者、UX設計に認知心理学者
→ 候補が浮かばなければ無理に入れない。ロジックで判断した結果
「入れるべき」と判断した場合のみ追加する
-
Devil's Advocate を1名含める（専門家の枠とは別枠）
→ 構造的に反対意見を出す役割。ドメイン専門家ではなく批判の専門家
「この提案/対象の弱点は何か」を徹底的に探すことが使命
選定のチェック:
- 同じ側の専門家が2名以上いないか？（編集者 + ストラテジストは「作り手側 x 2」）
- 受け手の視点が含まれているか？
- パネルサイズは議題の複雑さに見合っているか？
Standard 以上の場合は 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 開始: 「統合・評決を行います」
各エージェントに渡すもの：
- ペルソナ定義（Phase 0 で作成）
- 議題の説明
- 対象物（テキスト、URL取得結果、ファイル内容等）
- 評価基準
各エージェントに渡さないもの：
- 他のエージェントの存在や意見
- 「正しい答えを出してください」等の指示（研究で効果なし〜逆効果）
- 投票結果や多数派情報
全エージェントの分析が揃ったら 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名だけが指摘している点 → 保護対象としてフラグ
対立点がなければ Phase 3 に進む。
Round 1: 対立点への反論
対立点について、関連するエージェントにのみ反論を求める（選択的参加）。
「関連する」の判定基準（オーケストレーターの恣意性を防ぐ）：
- Phase 1 で当該論点に直接言及した専門家
- 当該論点が専門領域に含まれる専門家
- 選択の理由はレポートの「議論プロセス」セクションに記載する
エージェントのコンテキスト再構成（サブエージェントはステートレスなため）：
Phase 2 のエージェントには以下を渡し、Phase 1 での自分の分析を再認識させる：
- Phase 1 と同じペルソナ定義
- Phase 1 でのそのエージェント自身の出力全文
- 対立点の要約（下記テンプレート）
要約の対称性チェック（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 に「現在の合意傾向の弱点は何か」を問う
- 他のエージェントに新しい論点があるか確認
収束条件（いずれかを満たせば終了）：
- 全エージェントが同じ結論に達した
- 前ラウンドと比較して新しい具体的証拠・データ・事例を含む論点が出ない
（同じ主張の言い換えは新規論点と認めない）
- Round 2 に到達（ハードキャップ。追加ラウンドは精度向上に寄与しない）
Phase 3: 統合・評決
オーケストレーターが統合者として最終的な推薦を出すフェーズ。
Phase 1-2 ではプロセス管理に専念していたが、ここでは事前定義された基準に基づいて判断を行う。
3-1. 合意事項のまとめ
全専門家が一致した点を箇条書きでまとめる。
3-2. 対立の解決
対立が残った点について、以下の基準で重み付ける：
- 根拠の具体性: コード例・データ・仕様書の引用を含む意見 > 抽象的な意見
- 専門領域との一致度: その論点に最も関連する専門家の意見を重視
- 反論への応答品質: 反論に対して具体的に応答できた意見 > 無視した意見
使わないもの: エージェントの自己申告による確信度（研究で過剰自信が確認されており信頼不可）
3-3. 少数意見チェック（必須・全深度で省略不可）
- 多数派の結論と矛盾する少数意見をすべてリストアップ
- 各少数意見を以下の2軸で判定する：
| 根拠あり | 根拠なし |
|---|
| 影響大（見逃すと重大な問題） | 必ず採用 | 採用（リスクが高いため） |
| 影響小（見逃しても軽微） | 採用を推奨 | 棄却可（理由を明記） |
- 棄却する場合は具体的な理由を記述する（「多数派だから」は不可）
- 最終レポートに少数意見セクションを含める（少数意見がない場合も明記）
3-4. セカンドチャンス（Deep のみ）
二段階確認（統合結果を見せた後の sycophancy を防ぐ）：
- Step 1（事前コミット）: 統合結果を見せる前に、各エージェントに
「Phase 1-2 でのあなたの結論は今も変わらないか？ 変わった場合は理由を述べよ」と確認する
- Step 2（統合結果の提示と差分検出）: 統合結果の要約を見せ、
「あなたの結論と統合結果に差分がある場合、指摘してください」と問う
意見変更の判定ルール（差分の有無ではなく、変更理由の質で判断する）：
- 変更理由に新たな根拠（データ、事例、論理的推論）がある → 正当な変更として採用
- 変更理由が「統合結果を見て納得した」レベル → sycophancy の兆候。元の意見を尊重
- Step 1 で「変わらない」と答えたのに Step 2 で根拠なく意見を変えた場合も同様
ここで出た正当な指摘は最終レポートに反映する。
Phase 4: ユーザーへの報告
出力フォーマットの詳細は output-format.md を参照。
以下は必須セクション：
# 円卓会議レポート: [議題]
## エグゼクティブサマリ
[3-5行で結論。最も重要な発見と推奨アクションを含む]
## 専門家パネル
| 専門家 | 役割 | 総合評価 |
|---|---|---|
| [名前] | [分野] | ★★★★☆ |
## 合意事項
[全専門家が一致した点]
## 主要な議論と結論
### [論点1]
- **結論**: [採用された見解]
- **賛成側の根拠**: [具体的に]
- **反対側の根拠**: [具体的に]
- **判断理由**: [なぜこちらを採用したか]
## 少数意見（見逃してはいけない指摘）
[1名だけが指摘したが重要な点。棄却した場合はその理由]
## 推奨アクション
1. **[最優先]** ...
2. **[高]** ...
3. **[中]** ...
## 議論の限界
- この分析は[単一の LLM モデル / 複数モデル混合]によるペルソナベースの議論であり、[モデル固有の盲点は検出できない / モデル多様性により緩和されているが完全ではない]
- [この議論でカバーできなかった観点、追加調査が必要な点]
不確実性の表現
確信度に応じて文体を使い分ける：
| 確信度 | 文体 | 使う場面 |
|---|
| 高 | 「〜である」「〜が必要」 | 全員合意 + 具体的根拠あり |
| 中 | 「〜と考えられる」「〜が推奨される」 | 多数派合意 or 条件付き結論 |
| 低 | 「〜の可能性がある」「〜を検討すべき」 | 少数意見 or 根拠が限定的 |
レポート提示後、ユーザーから追加質問や深掘り依頼があれば対応する。
設計の限界
このスキルの構造的な限界を理解した上で使用すること。
-
デルファイ法に近い構造: サブエージェント方式（デフォルト）での Phase 1→2 は、
MAD 研究が前提とするステートフルな動的議論ではなく、デルファイ法に近い
「構造化された独立レビューの統合」である。Agent Teams 直接議論オプションを
使用した場合のみ、局所的に動的なやりとりが実現される
-
同一モデルの擬似的多様性: 全エージェントが同一の LLM モデルであり、
ペルソナの違いによる多様性は本質的に限定される。モデル固有のバイアスは
検出できない。高リスク・高影響の議題では人間の専門家の確認を推奨する
-
オーケストレーターの要約バイアス: Phase 2 で対立点を要約する際、
オーケストレーターのフレーミングが議論の方向を左右する。
deliberation-rules.md の要約品質ルールで緩和しているが、完全には排除できない
参考資料（深度に応じて読み込む）
Quick: 参照ファイルを読まない。SKILL.md 本体で完結する。
Standard: deliberation-rules.md + output-format.md を読む。
Deep: 全参照ファイルを読む。
設計参考: デルファイ法、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)
