ensemble-solving

アンサンブルによる問題解決

異なるアプローチを用いる3つのサブエージェントを起動して複数の解決策を並行して生成し、評価して最適な結果を選択します。

使用するタイミング

起動フレーズ：

• 「〜の選択肢を教えてください」
• 「〜する最善の方法は何ですか？」
• 「さまざまなアプローチを検討してください」
• 「代替案を見てみたいです」
• 「〜のアプローチを比較してください」
• 「どのアプローチを使うべきですか？」

適したタスク：

• トレードオフのあるアーキテクチャの決定
• 複数の有効な実装方法があるコード生成
• 異なる設計思想に基づく API 設計
• ネーミング、ブランディング、ドキュメントのスタイル
• リファクタリング戦略
• アルゴリズムの選定

アンサンブルを使わないタスク：

• 簡単な検索や構文に関する質問
• 原因が1つのバグ修正
• ファイル操作、git コマンド
• 決定論的な設定変更
• 明らかな解決策が1つしかないタスク

動作内容

1. タスクを分析して、アンサンブルアプローチが有効かどうかを判断します
2. 適切な多様化戦略を使って3つの異なるプロンプトを生成します
3. 3つのサブエージェントを並行して起動し、それぞれ独立して解決策を作成します
4. 重み付けされた基準に基づいてすべての解決策を評価します
5. 説明と代替案の概要を添えて最善の解決策を返します

アプローチ

ステップ1：タスクの種類を分類する

該当するカテゴリを判断します：

• コード生成：関数、クラス、API、アルゴリズム
• アーキテクチャ／設計：システム設計、データモデル、パターン
• クリエイティブ：文章作成、ネーミング、ドキュメント

ステップ2：アンサンブルオーケストレーターを呼び出す

Task tool with:
- subagent_type: 'ensemble-orchestrator'
- description: 'Generate and evaluate 3 parallel solutions'
- prompt: [User's original task with full context]

オーケストレーターが処理する内容：

• プロンプトの多様化
• 並行実行
• 解決策の評価
• 最適解の選定

ステップ3：結果を提示する

オーケストレーターは次の内容を返します：

• 最適解（全内容）
• 3つのアプローチすべての評価スコア
• 最適解が選ばれた理由
• 代替案が適している場合

多様化戦略

コード（制約のバリエーション）：

アプローチ	重視する点
シンプルさ	コードを最小限にし、最大限に読みやすくする
パフォーマンス	効率的で最適化されている
拡張性	明確な抽象化、拡張のしやすさ

アーキテクチャ（アプローチのバリエーション）：

アプローチ	重視する点
トップダウン	要件 → インターフェース → 実装
ボトムアップ	プリミティブ → 構成 → 構造
水平展開	他の分野からの類推

クリエイティブ（ペルソナのバリエーション）：

アプローチ	重視する点
エキスパート	技術的な正確さ、権威性
実践的	リリース重視、実用性
革新的	創造的、型破り

評価基準

基準	基本の重み	説明
正確性	30%	問題を正しく解決している
完全性	20%	すべての要件に対応している
品質	20%	どれだけよく作り込まれているか
明確さ	15%	どれだけ理解しやすいか
洗練度	15%	どれだけシンプルで美しいか

重みはタスクの種類に応じて調整されます。

例

ユーザー：「レートリミッターを実装する最善の方法は何ですか？」

スキル：

1. コード生成として分類します
2. ensemble-orchestrator を呼び出します
3. 3つのアプローチを生成します：
   • シンプル：メモリ内カウンターを使うトークンバケット
   • パフォーマンス：アトミック操作を使うスライディングウィンドウ
   • 拡張性：バックエンドを差し替え可能なストラテジーパターン
4. 評価により、拡張性のあるアプローチを選択します（スコア 8.4）
5. 説明を添えて、完全な実装を返します

出力：

## Selected Solution

[Full rate limiter implementation with strategy pattern]

## Why This Solution Won

The extensible approach scored highest (8.4) because it provides
a clean abstraction that works for both simple use cases and
complex distributed scenarios. The strategy pattern allows
swapping Redis/Memcached backends without code changes.

## Alternatives

- **Simple approach**: Best if you just need basic in-memory
  limiting and will never scale beyond one process.

- **Performance approach**: Best for high-throughput scenarios
  where every microsecond matters.

成功基準

• 実質的に異なる解決策を3つ生成する
• 明確な評価理由を提示する
• 確信を持って最適解を選択する
• 代替案を用途とともに要約する
• トレードオフをユーザーが理解できる

トークンコスト

単一の試行と比べて約4倍のオーバーヘッドがあります。次の場合に有効です：

• 重大な影響を伴うアーキテクチャの決定
• 最初の試みが最適であることが少ないクリエイティブな作業
• 代替案を見ることに価値がある学習シナリオ
• 長期にわたって保守するコード

統合

• feature-planning：アーキテクチャの決定にアンサンブルを利用できます
• code-auditor：分析の観点にアンサンブルを利用できます
• plan-implementer：選ばれたアプローチを実行します