メニュー
多分野の専門家を動的に選定し、構造化された議論で多角的な評価・提言をまとめる。 「専門家に聞きたい」「レビューして」「多角的に評価して」「議論して」等で使用。 Webサイト、コード、事業戦略、デザイン、組織設計等あらゆるドメインに対応。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
対話または既存トークンファイル（W3C DTCG / CSS variables など）をもとに、プロダクトに合った DESIGN.md を生成する。AIがつくるUIに一貫性を。
セッション間のコンテキストを構造化して保存する。 「引き継ぎ」「セッション保存」「handoff」「コンテキスト保存」等で使用。 通常は自動保存（L1/L2）で十分。明示的に高品質な保存をしたいときに呼ぶ。
世の中のベストプラクティスをWeb検索・SNS検索・ツール検索で調査し、鮮度・信頼性・多角的視点を 考慮して構造化レポートにまとめる。「ベストプラクティスを調べて」「best practice」「最適な方法」 「推奨される方法」「どうするのが正解か調べて」「世の中ではどうやっているか」等で使用。 技術・ビジネス・教育・デザイン等あらゆるドメインに対応。
SOC 職業分類に基づく
| 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)