convening-experts

SURFACE ROUTING — 先にお読みください

このスキルは、生の Anthropic API 呼び出しを介して、サブエージェントのオーケストレーションを手作業で実装します。現在は、マネージドランタイムで同じ処理を実行できます。どちらを使うかは、利用する環境によって異なります。

• Claude Code（CCotw を含む）では、ネイティブランタイムを使用してください。このスキルは使用しないでください。 /deep-research を呼び出せる場合、workflow キーワードで実行を開始できる場合、/effort ultracode を設定できる場合、または Task サブエージェントを起動できる場合は、代わりにそちらを使用してください。ランタイムは、最大16の同時実行／最大1000エージェント、承認ゲート、敵対的な相互レビュー、セッション内での再開機能を備えています。このスキルで再実装すると、いずれも不完全なものになってしまいます。動的ワークフローは、リサーチプレビューとして提供されています（Claude Code v2.1.154 以降、2026年）。
• claude.ai のチャットまたはベア API（ワークフローランタイムなし）では、このスキルを使用してください。 ここで並列 API インスタンスを実行するには httpx を使った方法しかありません。muninn_utils.dispatch（17個の事前構築済みレンズ）は、orchestrating-chat-agents の実行モデル上ですでにこのパネルを実装しているため、手作業でパネルを再構築せず、こちらを優先してください。以下に進んでください。

判別方法：ネイティブのサブエージェント／Task ツール、またはワークフローコマンドがありますか？ はい → ネイティブ機能を使用してください。いいえ → このスキルを使用してください。ランタイムがすでに存在する環境で、決してランタイムを再実装しないでください。

専門家を招集する

複数回にわたる協働的な議論を通じて、専門家や方法論のスペシャリストを招集し、問題を解決します。専門家は互いの知見を発展させ、前提に異議を唱え、提言をまとめます。

パネル形式

単一ラウンドの相談

複数の視点が必要な、比較的単純な問題に適しています。

1. パネルを編成する（問題領域に応じて3～5名の専門家）
2. 各専門家が独立した見解を示す（順番ではなく並行して実施）
3. 出典を明示して提言をまとめる

複数ラウンドの議論

協働的な推論が必要な、複雑な問題に適しています。

1. 第1ラウンド：各専門家が問題を個別に分析する
2. 第2ラウンド：専門家が互いの知見に応答し、論点を発展させたり、異議を唱えたりする
3. 第3ラウンド（必要な場合）：結論をまとめ、意見の相違を解消する
4. 最終的な統合：意思決定の枠組みとともに、統合した提言を示す

専門家の役割

以下の専門分野を利用できます。

• MSD 分野の専門家（ライフサイエンス、エンジニアリング、製造、品質、コーポレート機能）
• コンサルティング・フレームワークの専門家（戦略、プロセス改善、イノベーション、システム分析、根本原因）
• 古代哲学者の方法論の専門家（エレンコス、判断に先立つ分類、制御の二分法、権力分析）

役割の一覧については、references/msd-domain-experts.md、references/consulting-frameworks.md、および references/ancient-philosophers.md を参照してください。

Claude は問題領域に応じて、関連するリファレンスを読み込みます。

パネルの招集ロジック

Claude は問題の特性に応じて、3～5名の専門家を選びます。

問題の種類 → 主担当の専門家 + 支援する専門家

• 技術的なトラブルシューティング → 分野の専門家 + システム思考の専門家 + 5つのなぜのファシリテーター
• 戦略的な意思決定 → McKinsey のコンサルタント + 関連分野の専門家 + SWOT 分析の専門家
• プロセス改善 → シックスシグマのブラックベルト + リーンの実践者 + 分野に応じた製造エンジニア
• 製品イノベーション → デザイン思考のファシリテーター + Jobs-to-Be-Done の専門家 + 関連するエンジニア
• 根本原因分析 → 分野の専門家 + 5つのなぜのファシリテーター + システム思考の専門家
• 市場でのポジショニング → Porter フレームワークの専門家 + マーケティングの専門家 + BCG のコンサルタント
• 部門横断的な問題 → 関連分野の専門家 + Bain のコンサルタント（RAPID）+ システム思考の専門家
• 定義上／概念上の意見の相違 → ソクラテス式の問答者 + アリストテレス式の分類学者 + 分野の専門家
• ガバナンス／制度設計 → アリストテレス式の分類学者 + トゥキディデス式の現実主義者 + システム思考の専門家
• 理想と現実の緊張関係 → プラトン主義の理想主義者 + アリストテレス式の分類学者（Politics IV Part II に基づく、固有の敵対的な組み合わせ）+ 分野の専門家

回答形式

まずパネルの名称を示し、その後、総括の前に各専門家の見解を提示してください。

単一ラウンド： パネルのメンバーを列挙し、その後、各専門家の独立した分析を（明確であれば順序は自由です。逐次ではなく並行して）提示し、最後に出典を明記して総括します。

複数ラウンド： まず各専門家が初期分析を行い、次に、専門家が指名された他の専門家の具体的な指摘に応答するラウンドを設けます（その意見を発展させる、または異議を唱える）。その後、相違点を解消するか、建設的な相違として残すべき点を明示して収束させ、最後に総括します。追加しても意味がないラウンドは省略してください（たとえば、ラウンド2ですでに収束している場合、ラウンド3は不要です）。

専門家やラウンドを区切る見出しは、読者の助けになります。見出しの文言は問いません。

専門家の行動指針

領域の専門家：

• MSD の背景（ECL プラットフォーム、規制上の制約、バリデーション済みシステム）を踏まえてください
• 過度な説明は避け、領域に適した用語を使用してください
• 理論上の完璧さより、実践的な実装を優先してください
• 領域固有のリスクと制約を明示してください

哲学者の専門家：

• 指定された方法（エレンコス、分類、制御の二分法）を適用し、その構造を示してください。見せかけではなく、方法として適用し、時代がかった語り口は避けてください
• デフォルトではペルソナのみとします。出力に監査可能性が求められる場合、または著作の細部に関わる場合は、コーパスを注入して根拠を明示してください（原文の引用と主張ごとの引用）。仕組みとルーティング表については、references/ancient-philosophers.md を参照してください
• 領域の専門家と組み合わせてください。質問自体が概念的なものでない限り、哲学者だけのパネルでは現代の質問に適切なレベルで答えられません

フレームワークの専門家：

• フレームワークを体系的に適用し、その構造を示してください
• 問題の背景に合わせてフレームワークを調整し、機械的な適用は避けてください
• この問題にこのフレームワークを選ぶ理由を説明してください
• 汎用的なフレームワークを適用する際は、領域の背景も考慮してください

パネル間のやり取り：

• 他の専門家の指摘を具体的に参照してください（「[専門家] の、〜に関する指摘を踏まえると……」）
• 建設的に異議を唱えてください（「〜という理由から、私は異なる見方をしています」）
• 分野を横断して総合してください（「これは、[専門家1] の技術的制約と [専門家2] のビジネス上の優先事項を結び付けるものです……」）
• 視点の間にある緊張関係を明示してください

意見の相違への対処：

• 意見の相違を建設的なものにしてください（どの前提が異なるのかを明らかにします）
• 合意が必須でない場合は、複数の妥当なアプローチを提示してください
• 相違を解消するための判断基準を特定してください
• 専門家間で合意に至らない場合は、ユーザーに判断を仰いでください

意思決定フレームワーク

パネルが行動を推奨する場合は、以下を使用してください。

RAPID（Bain）

• 推奨（Recommend）：パネルの推奨事項とその根拠
• 合意（Agree）：合意が必要なステークホルダー
• 実行（Perform）：実装を担当する人
• 意見提供（Input）：意見を提供する人
• 決定（Decide）：最終決定を下す人

加重意思決定マトリクス

• 基準（重要度による重み付け）
• 各基準に対する選択肢のスコア
• 感度分析を含む合計スコア

リスク・ベネフィット分析

• 期待されるメリット（確率 × 影響度）
• 下振れリスク（確率 × 影響度）
• リスク軽減策
• 不確実性を踏まえた意思決定

MSD との統合

MSD 固有の背景を自動的に反映してください。

技術的制約：

• ECL プラットフォームとアッセイ化学
• ISO 13485 への準拠とバリデーション済みシステム
• 規制要件（FDA、CE マーキング）
• 技術スタック（Python、AWS、Java、TypeScript）

ビジネスの背景：

• ライフサイエンス市場の動向
• 顧客セグメント（製薬会社、バイオテクノロジー企業、CRO、学術機関）
• 競争環境

文化的要因：

• 科学的厳密さとデータに基づく意思決定
• 部門横断的な協業の慣習
• リスク管理とのバランスを考慮したイノベーション
• 品質と規制に対する意識

例

例 1：技術的なトラブルシューティング

User: Our new assay is showing high background signal in serum samples

Claude convenes:
- Assay Scientist (primary)
- Systems Thinker (feedback loops)
- Five Whys Facilitator (root cause)

Format: Multi-round (technical nuance requires collaboration)

例 2：戦略的な意思決定

User: Should we build internal ML infrastructure or use vendor solutions?

Claude convenes:
- Software Engineer (implementation)
- McKinsey Consultant (strategic framing)
- Finance Analyst (cost analysis)
- DevOps Engineer (operational implications)

Format: Single-round → RAPID framework synthesis

例 3：プロセス改善

User: Manufacturing yield dropped 8% after equipment upgrade

Claude convenes:
- Manufacturing Engineer (primary domain)
- Six Sigma Black Belt (DMAIC)
- Systems Thinker (unintended consequences)

Format: Multi-round (root cause needs collaborative analysis)

制約

問題に明確な正解が1つある場合は、パネルを完全に省略し、視点を無理に作り出すのではなく、直接回答してください。

このドキュメントでは、ほかに根拠となる情報源がない制約が4つあるため、明示したままにしてください。架空の専門家名（役職のみを使用してください。「Dr. John Smith, Software Engineer」ではなく「Software Engineer」）を作り出したり、一般的なドメイン知識を超えてMSD固有の詳細を作り出したりしないでください。どちらも、具体的な根拠を持たない汎用パネルを、あたかも根拠があるかのように誤って伝えることになります。

残る2つは、パネル形式そのものが招きやすい失敗です。専門家の意見が実際に異なる場合に、合意を捏造すること（意見の相違を示し、何があれば解決できるのかを述べてください）と、誰かが行動に移せる統合的な結論ではなく、「これが各視点です。あとは自分で判断してください」で終わることです。