consensus-voting

コンセンサス投票スキル

目的

ドメインの専門知識が重要となる重大な決定について、複数エージェントによる重み付け投票を実行します。共同での統合を行うディベートや、並列生成を行う N バージョン方式とは異なり、このスキルではセキュリティ、認証、データ処理に関する変更を対象に、専門性に応じた重み付けを行う構造化投票に重点を置きます。

パターン分析から得られた重要な知見

~/.amplihack/.claude/context/DISCOVERIES.md（パターン適用性分析）より：

投票と専門家判断の選択基準

投票が有効な場合：

• 敵対的な環境（個々のノードを信頼できない）
• 二者択一または単純な離散的選択
• 客観的な品質指標が存在しない
• 正しさより合意が重要

専門家判断が有効な場合：

• 協調的な環境（行為者が誠実）
• 複雑な品質の側面がある
• 客観的な評価基準が存在する
• 合意より正しさが重要

このスキルでは、両方を戦略的に使用します：専門家判断で評価し、重み付け投票で決定します。

このスキルを使用する場面

自動トリガー（高リスク領域）：

• セキュリティの実装（認証、認可）
• 暗号化と暗号コード
• 機密データの処理（PII、認証情報）
• 権限およびアクセス制御の変更
• 重要なアルゴリズムの実装

明示的なトリガー：

• 複数のアプローチが競合する重要な設計上の決定
• ステークホルダーの賛同が重要な場合
• 検証が必要な二者択一または離散的な選択
• 本番コードのリスクを軽減する決定

次の用途には使用しないでください：

• 複雑なトレードオフ分析（代わりに debate-workflow を使用）
• コード生成（代わりに n-version-workflow を使用）
• 単純な実装上の選択
• 主観的な品質評価

設定

投票設定

投票モード：

• simple-majority - 50% 以上の票で可決
• supermajority - 66% 以上の票で可決（セキュリティのデフォルト）
• unanimous - 100% の合意が必要

エージェントの選択：

• auto - 検出されたドメインに基づいてエージェントを選択（デフォルト）
• manual - エージェントを明示的に指定
• comprehensive - 関連するすべてのエージェントが投票

重みの調整：

• static - ドメインごとに固定の重み（デフォルト）

ドメイン専門性の重み

エージェント	セキュリティ	認証	データ	アルゴリズム	一般
security	3.0	2.5	2.5	1.5	1.0
reviewer	1.5	1.5	1.5	2.0	2.0
architect	1.5	2.0	2.0	2.5	2.0
tester	1.0	1.5	1.5	2.0	1.5
optimizer	0.5	0.5	0.5	2.5	1.0
cleanup	0.5	0.5	0.5	1.0	1.5

重みの解釈：

• 3.0 = ドメインの専門家（票の重みは 3 倍）
• 2.0 = 高い専門性（票の重みは 2 倍）
• 1.0 = 一般的な能力（標準の票）
• 0.5 = 周辺的な関連性（票の重みは半分）

実行プロセス

ステップ 1：決定のドメインを検出する

変更または決定を分析し、主要なドメインを特定します：

• analyzer エージェントを使用してコードや提案を調査
• キーワードを検出：auth、encrypt、password、token、permission、credential
• ファイルパスを特定：auth/、security/、crypto/
• 分類：SECURITY | AUTH | DATA | ALGORITHM | GENERAL

ドメイン検出のトリガー：

SECURITY: encrypt, decrypt, hash, salt, vulnerability, CVE, injection
AUTH: login, logout, session, token, jwt, oauth, password, credential
DATA: pii, gdpr, sensitive, personal, private, secret, key
ALGORITHM: sort, search, calculate, compute, process, transform

ステップ 2：投票エージェントを選択する

検出されたドメインに基づいて、関連するエージェントを重み付けして選択します。

SECURITY ドメインの場合：

• security エージェント（重み：3.0）- 主な専門家
• architect エージェント（重み：1.5）- システム設計の観点
• reviewer エージェント（重み：1.5）- コード品質の確認
• tester エージェント（重み：1.0）- テスト容易性の評価

AUTH ドメインの場合：

• security エージェント（重み：2.5）- セキュリティへの影響
• architect エージェント（重み：2.0）- 統合パターン
• reviewer エージェント（重み：1.5）- 実装品質
• tester エージェント（重み：1.5）- 認証フローのテスト

DATA ドメインの場合：

• security エージェント（重み：2.5）- データ保護
• architect エージェント（重み：2.0）- データアーキテクチャ
• reviewer エージェント（重み：1.5）- データの取り扱いパターン
• tester エージェント（重み：1.5）- データ検証

ALGORITHM ドメインの場合：

• optimizer エージェント（重み：2.5）- パフォーマンス分析
• architect エージェント（重み：2.5）- 設計パターン
• tester エージェント（重み：2.0）- 正確性のテスト
• reviewer エージェント（重み：2.0）- コード品質

ステップ 3：エージェントに判断を提示する

選択された各エージェントに、以下を提示します。

• 明確な判断内容
• 選択肢（該当する場合）
• 関連するコンテキストと制約
• 評価基準

判断プロンプトのテンプレート：

## Decision Required: [TITLE]

**Domain:** [SECURITY | AUTH | DATA | ALGORITHM]
**Your Weight:** [X.X] (based on domain expertise)

### Context

[Relevant background and constraints]

### Options

1. [Option A]: [Description]
2. [Option B]: [Description]
3. [Reject Both]: Propose alternative

### Evaluation Criteria

- Security implications
- Implementation complexity
- Maintainability
- Risk assessment

### Your Vote

Provide:

1. Your vote (Option 1, 2, or Reject)
2. Confidence level (HIGH, MEDIUM, LOW)
3. Key reasoning (2-3 sentences max)
4. Any conditions or caveats

ステップ 4：投票を集める

各エージェントから、構造化された投票を集めます。

agent: security
weight: 3.0
vote: Option 1
confidence: HIGH
reasoning: "Option 1 follows OWASP best practices for credential storage. Option 2 uses deprecated hashing algorithm."
conditions: ["Ensure salt length >= 16 bytes", "Use constant-time comparison"]

ステップ 5：重み付き結果を計算する

重み付き投票の計算：

For each option:
  weighted_score = sum(agent_weight * confidence_multiplier)

Where confidence_multiplier:
  HIGH = 1.0
  MEDIUM = 0.7
  LOW = 0.4

計算例：

エージェント	重み	投票	確信度	スコア
security	3.0	A	HIGH	3.0
architect	1.5	A	MEDIUM	1.05
reviewer	1.5	B	HIGH	1.5
tester	1.0	A	LOW	0.4

Option A Score: 3.0 + 1.05 + 0.4 = 4.45
Option B Score: 1.5
Total Weighted Votes: 5.95
Option A Percentage: 74.8% (SUPERMAJORITY)

ステップ 6：投票のしきい値を適用する

設定された投票モードに基づいて判定します。

simple-majority（50％以上）：

• 重み付きスコアが最も高い選択肢が 50％を超える場合、その選択肢が勝ちます
• 50％を超える選択肢がない場合は、議論に進むか、却下します

supermajority（66％以上）：（セキュリティのデフォルト）

• 勝利する選択肢は、重み付き投票の 66％を超える必要があります
• 高リスクな判断に対して、より強力な検証を行います

unanimous（100％）：

• すべてのエージェントが同意する必要があります（まれで、最も厳しい基準）
• 反対意見が 1 つでもあれば、判断は保留されます

ステップ 7：合意結果を報告する

合意に達した場合：

## Consensus Voting Result

**Decision:** [Selected Option]
**Domain:** SECURITY
**Threshold:** Supermajority (66%+)
**Result:** PASSED (74.8%)

### Vote Summary

| Agent     | Weight | Vote | Confidence |
| --------- | ------ | ---- | ---------- |
| security  | 3.0    | A    | HIGH       |
| architect | 1.5    | A    | MEDIUM     |
| reviewer  | 1.5    | B    | HIGH       |
| tester    | 1.0    | A    | LOW        |

### Key Reasoning (from highest-weighted agents)

- **security (3.0):** "Option 1 follows OWASP best practices..."

### Conditions/Caveats

- Ensure salt length >= 16 bytes
- Use constant-time comparison

### Dissenting View

- **reviewer (1.5):** "Option B has simpler implementation..."

合意に達しなかった場合：

## Consensus Voting Result

**Decision:** NO CONSENSUS
**Domain:** AUTH
**Threshold:** Supermajority (66%+)
**Result:** FAILED (52.3%)

### Recommendation

- Escalate to `/amplihack:debate` for structured trade-off analysis
- OR: Gather more information and re-vote
- OR: Accept simple majority with documented risk

ステップ 8：判断を記録する

• 投票結果をセッションの判断記録に記録します
• 今後参照できるよう、投票の根拠を記録します

トレードオフ

利点：

• 高リスクなドメインでの構造化された意思決定
• ドメインの専門知識に適切な重み付けがされます
• 根拠を含む明確な監査証跡
• 二択や離散的な選択肢では、全員参加の議論よりも迅速です

コスト：

• 議論ほど細かな検討はできません（統合がありません）
• 明確な選択肢が必要です（生成的ではありません）
• 重みの調整には実データが必要です
• 創造的な代替案を見落とす可能性があります

次の場合に使用します： 判断が離散的で、ドメインの専門知識が重要であり、監査証跡が必要な場合

例

例 1：パスワードハッシュの実装

コンテキスト： 新しい認証システムで、bcrypt、argon2id、PBKDF2 のどれを使うか選択します

ドメイン検出： AUTH（パスワード、ハッシュ）

選択されたエージェント：

• security（2.5）、architect（2.0）、reviewer（1.5）、tester（1.5）

投票：

• security：argon2id（HIGH）-「OWASP の最新の推奨事項であり、メモリハードです」
• architect：argon2id（MEDIUM）-「ライブラリのサポートが充実しており、最新の設計です」
• reviewer：bcrypt（HIGH）-「本番環境での実績が豊富です」
• tester：argon2id（MEDIUM）-「パラメーターを設定でき、テストが容易です」

結果： argon2id が 68.2％で勝利（特別多数の基準を達成）

例 2：API レート制限のアプローチ

コンテキスト： トークンバケット、スライディングウィンドウ、固定ウィンドウの比較

ドメイン検出： SECURITY（レート制限、保護）

選出されたエージェント：

• security（3.0）、optimizer（1.5）、architect（1.5）、reviewer（1.5）

投票：

• security：トークンバケット（HIGH） - 「バースト攻撃に対する最善の保護」
• optimizer：スライディングウィンドウ（MEDIUM） - 「リソース利用率が向上」
• architect：トークンバケット（MEDIUM） - 「業界標準で、十分に理解されている」
• reviewer：スライディングウィンドウ（LOW） - 「実装がより簡単」

結果： トークンバケットが69.4%で勝利（特別多数決を通過）

例 3：合意に至らないケース

コンテキスト： 新機能におけるマイクロサービスとモノリスの比較

ドメイン検出： ALGORITHM（一般的なアーキテクチャ）

選出されたエージェント：

• architect（2.5）、optimizer（2.5）、reviewer（2.0）、tester（2.0）

投票：

• architect：マイクロサービス（MEDIUM） - 「長期的なスケーラビリティが向上」
• optimizer：モノリス（HIGH） - 「運用がよりシンプルで、オーバーヘッドが少ない」
• reviewer：モノリス（MEDIUM） - 「初期段階では保守がより簡単」
• tester：マイクロサービス（LOW） - 「テストは難しくなるが、分離性が高い」

結果： 合意なし（52.1%） - /amplihack:debate にエスカレーション

他のワークフローとの統合

Debate への引き継ぎ

投票で合意に至らなかった場合：

1. 投票結果と根拠を記録します
2. 投票のコンテキストを指定して Skill(debate-workflow) を呼び出します
3. 投票から得られた知見を使って、議論の観点を設定します

N-Version 実装後

コンセンサス投票を使って、N-Version 実装から選択します：

1. N-Version によって3つ以上の実装を生成します
2. コンセンサス投票で最適な案を選択します
3. ドメインの専門家が、選択に対して重み付けされた影響力を持ちます

哲学との整合性

このスキルでは、以下を徹底します：

• エビデンスに基づく意思決定： 投票には根拠が必要です
• ドメインの専門知識： 重みは能力を反映します
• 透明性の高いトレードオフ： 異論を記録します
• 監査証跡： 投票記録全体を保持します
• 適切な厳格さ： 高リスクのドメインでは自動的に起動します