Menu
多分野の専門家を動的に選定し、構造化された議論で多角的な評価・提言をまとめる。 「専門家に聞きたい」「レビューして」「多角的に評価して」「議論して」等で使用。 Webサイト、コード、事業戦略、デザイン、組織設計等あらゆるドメインに対応。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
対話または既存トークンファイル（W3C DTCG / CSS variables など）をもとに、プロダクトに合った DESIGN.md を生成する。AIがつくるUIに一貫性を。
セッション間のコンテキストを構造化して保存する。 「引き継ぎ」「セッション保存」「handoff」「コンテキスト保存」等で使用。 通常は自動保存（L1/L2）で十分。明示的に高品質な保存をしたいときに呼ぶ。
世の中のベストプラクティスをWeb検索・SNS検索・ツール検索で調査し、鮮度・信頼性・多角的視点を 考慮して構造化レポートにまとめる。「ベストプラクティスを調べて」「best practice」「最適な方法」 「推奨される方法」「どうするのが正解か調べて」「世の中ではどうやっているか」等で使用。 技術・ビジネス・教育・デザイン等あらゆるドメインに対応。
| name | start |
| description | 多分野の専門家を動的に選定し、構造化された議論で多角的な評価・提言をまとめる。 「専門家に聞きたい」「レビューして」「多角的に評価して」「議論して」等で使用。 Webサイト、コード、事業戦略、デザイン、組織設計等あらゆるドメインに対応。 |
| argument-hint | [議題や対象（URL、ファイル、テキスト等）] |
多分野の世界最高レベルの専門家を動的に選定し、構造化された議論で評価・提言をまとめる。
このスキルは以下の学術的知見に基づいて設計されている。
Phase 0: 議題分析・専門家選定（オーケストレーター単独）
Phase 1: 独立分析（各専門家が並列。他の意見は見ない）
Phase 2: 構造化議論（対立点を中心に最大2ラウンド）
Phase 3: 統合・評決（少数意見を明示的にチェック）
Phase 4: ユーザーへの報告
Quick 深度の場合: Phase 2 をスキップ（独立分析→統合→報告）。
オーケストレーター（あなた自身）がメタレベルで全体を設計するフェーズ。 Phase 1-2 ではプロセス管理に専念し、Phase 3 では統合者として推薦を出す。
ユーザーの入力から以下を明確にする：
Standard / Deep の場合、構造化の過程で以下も検証する：
問題を発見した場合：
パネルサイズと議論深度は独立した2つの軸であり、別々に判定する。
「この議題に関わるステークホルダーは何人いるか」で判断する。
| 議題の性質 | 専門家数 | 例 |
|---|---|---|
| 単一ドメインの明確な問題 | 3名 + DA | 正規表現の正しさ、特定APIの設計 |
| 複数ドメインが絡む問題 | 4-5名 + DA | 機能設計、記事レビュー、技術選定 |
| 多くのステークホルダーに影響する問題 | 6-7名 + DA | サイトリニューアル、事業戦略、組織設計 |
| シグナル | Deep | Standard | Quick |
|---|---|---|---|
| 影響範囲 | 事業全体・多数ユーザー | 特定機能・限定ユーザー | 個人プロジェクト |
| リスク | セキュリティ・金銭・法律 | 中程度 | 低い |
| 対立の可能性 | 複数の正解がありそう | やや対立 | ほぼ合意しそう |
| ユーザーの明示 | 「徹底的に」「深く」 | 指定なし | 「軽く」「さっと」 |
パネルサイズと深度は独立: 6名 + DA の Quick（多くの視点で軽く評価）も、3名 + DA の Deep（少数の視点で徹底議論）もありうる。
選定の原理（キーワードマッチではなく原理で判断する）：
「この議題で失敗したとき、誰が最初に気づくか？」 → その視点を持つ専門家が必要（直接関連の専門家）
「この議題の受け手・影響を受ける人は誰か？」 → 作り手だけでなく、受け手（ユーザー、読者、利用者）の視点を含める 例: 記事レビューにターゲット読者、API設計にAPI利用者
「この議題で見落とされがちな観点は何か？」 → 隣接ドメインの専門家を含める 例: ECサイト評価にアクセシビリティ専門家、事業戦略にエンドユーザーの視点
「この議題で、一般的には招集されないが、実は重要な知見を持つ分野はあるか？」 → Step 1-3 で選んだ専門家リストを見渡した上で、自問する → LLM の学習知識には「この分野にはこの専門性が有効」という知見が含まれている。 明示的に問うことで、聞かれなければ出てこない知識を引き出す 例: AI開発に倫理哲学者、組織設計に生態学者、UX設計に認知心理学者 → 候補が浮かばなければ無理に入れない。ロジックで判断した結果 「入れるべき」と判断した場合のみ追加する
Devil's Advocate を1名含める（専門家の枠とは別枠） → 構造的に反対意見を出す役割。ドメイン専門家ではなく批判の専門家 「この提案/対象の弱点は何か」を徹底的に探すことが使命
選定のチェック:
Standard 以上の場合は expert-archetypes.md を参照して、 ドメイン別の推奨専門家を確認する。
各専門家について以下を定義する：
あなたは [分野] の世界最高レベルの専門家です。
[その分野での具体的な経験・実績を1-2文で設定]
## あなたの使命
[この議題における具体的な評価観点]
## 判断基準
[オーケストレーターが定義した評価基準]
## 分析にあたっての注意
- 根拠のない主張はしない。具体的な理由・事例・データを示す
- 「問題ない」で済ませない。改善の余地があれば必ず指摘する
- あなたの専門領域の観点から、他の専門家が見逃しそうな点に注目する
## 出力フォーマット
1. **総合評価**: ★☆☆☆☆ 〜 ★★★★★（5段階）と一言
2. **主要な発見**: 3-5点。各点に具体的な根拠を付ける
3. **最も重要な懸念**: 1点。最も優先して対処すべき問題
4. **推奨アクション**: 優先順位付きで3-5点
Devil's Advocate のペルソナ定義:
あなたは批判的分析の専門家です。
...（上記と同様の経験設定）...
## あなたの使命
この [対象] の弱点・リスク・見落としを徹底的に洗い出すこと。
良い点を探す必要はない。他の専門家が「問題ない」と判断した点にこそ疑問を投げかける。
## 注意
- 「反対のための反対」ではない。具体的な根拠に基づく批判を行う
- 「もしこれが最悪の形で失敗するとしたら、どこが原因か？」を常に問う
- 些末な問題ではなく、構造的・根本的な弱点に集中する
深度によって承認フローが異なる：
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 2 では対立点の深掘りが重要。 それぞれに最適な実行方式が異なる（ハイブリッド方式）。
Phase 1: サブエージェントで並列起動（独立性を構造的に保証）
run_in_background: true で並列起動モデル混合（クロスプロバイダー環境でのみ推奨）: 異なるプロバイダーのモデルを 専門家ごとに割り当てることで、同一モデルの擬似的多様性問題を緩和できる。 MAD 研究で最も安定した効果が確認されている手法。
model フィールドで異なるプロバイダーを指定可能
（例: 専門家A = Claude, 専門家B = GPT, DA = Gemini）Phase 2: 対立点ごとに最適な方式を選択
サブエージェント利用不可（fallback）: まずユーザーに通知し、続行の確認を取る。 「サブエージェントの並列実行が利用できないため、逐次実行で代替します。 独立性の保証が限定的になります。Quick 深度に変更しますか？」 ユーザーが続行を選んだ場合、各専門家を逐次実行する。 独立性を擬似的に担保するため、以下のルールを守る：
各フェーズ開始時にユーザーに中間報告を行う：
各エージェントに渡すもの：
各エージェントに渡さないもの：
全エージェントの分析が揃ったら Phase 2 に進む。 Quick 深度の場合は Phase 2 をスキップし Phase 3 に直行する。
Quick 深度での DA 保護: Quick では Phase 2 がスキップされるため、 DA の批判が議論で深掘りされない。Phase 3 で DA の出力を少数意見と同等に 保護的に扱い、DA が指摘した点のうち他の専門家が触れていない点は 少数意見チェックの対象に必ず含める。
Phase 1 の全結果をオーケストレーターが分析し、3つに分類する：
対立点がなければ Phase 3 に進む。
対立点について、関連するエージェントにのみ反論を求める（選択的参加）。
「関連する」の判定基準（オーケストレーターの恣意性を防ぐ）：
エージェントのコンテキスト再構成（サブエージェントはステートレスなため）： Phase 2 のエージェントには以下を渡し、Phase 1 での自分の分析を再認識させる：
要約の対称性チェック（Deep のみ。オーケストレーターの要約バイアスを緩和する）： 対立点の要約を作成したら、それを伝える前に各エージェントに 「この要約はあなたの主張を正確に反映していますか？ 修正があれば指定してください」 と確認する。修正があれば反映してから議論を開始する。 注意: 同一モデル環境では、フレーミングバイアスの検出は構造的に困難である （チェック者も同じフレーミング傾向を持つ）。脱落や事実誤認の検出には有効だが、 過信しないこと。
Standard の場合: 対称性チェックは省略し、代わりに要約とともに 元の出力の該当箇所を引用として渡す（要約のみへの依存を緩和する）。
各エージェントに伝えること：
あなたの分析について、別の専門家から異なる見解が出ています。
[対立点の要約]:
- あなたの見解: [要約]
- 別の見解: [要約]
この対立について、あなたの観点から改めて分析してください。
意見を変える場合も、維持する場合も、具体的な根拠を示してください。
各エージェントに伝えないこと：
Agent Teams が利用可能な環境で、以下の条件を満たす対立点がある場合、 2名の専門家を直接対話させることができる：
直接議論を使わない場合は、上記のオーケストレーター仲介方式で Round 1 を実施する。
Round 1 で収束しなかった論点について：
収束条件（いずれかを満たせば終了）：
オーケストレーターが統合者として最終的な推薦を出すフェーズ。 Phase 1-2 ではプロセス管理に専念していたが、ここでは事前定義された基準に基づいて判断を行う。
全専門家が一致した点を箇条書きでまとめる。
対立が残った点について、以下の基準で重み付ける：
使わないもの: エージェントの自己申告による確信度（研究で過剰自信が確認されており信頼不可）
| 根拠あり | 根拠なし | |
|---|---|---|
| 影響大（見逃すと重大な問題） | 必ず採用 | 採用（リスクが高いため） |
| 影響小（見逃しても軽微） | 採用を推奨 | 棄却可（理由を明記） |
二段階確認（統合結果を見せた後の sycophancy を防ぐ）：
意見変更の判定ルール（差分の有無ではなく、変更理由の質で判断する）：
ここで出た正当な指摘は最終レポートに反映する。
出力フォーマットの詳細は 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: 全参照ファイルを読む。
| ファイル | 内容 | 読む条件 |
|---|---|---|
| expert-archetypes.md | 専門家アーキタイプ集・選定原理 | Deep、または専門家選定に迷った場合 |
| deliberation-rules.md | 議論ルール・収束条件・少数意見保護 | Standard 以上 |
| 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)