consensus-voting

合意形成のための投票スキル

合意形成のための投票スキル - 推奨内容が対立する可能性のある複数のエージェント間で合意に達するための投票プロトコルと競合解決アルゴリズムを実装します。 - 複数のエージェントから投票を集める - 専門性に基づく重み付き投票 - 競合の検出と解決 - 定足数の確認 - 決定事項の記録

ステップ 1：投票パラメーターを定義する

投票セッションを設定します。

voting_session:
  topic: 'Which database to use for the new service'
  options:
    - PostgreSQL
    - MongoDB
    - DynamoDB
  quorum: 3 # Minimum votes required
  threshold: 0.6 # 60% agreement needed
  weights:
    database-architect: 2.0 # Expert gets 2x weight
    security-architect: 1.0
    devops: 1.5

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

エージェントの推奨内容を集めます。

## Vote Collection

### database-architect (weight: 2.0)

- Vote: PostgreSQL
- Rationale: Strong ACID guarantees, mature ecosystem
- Confidence: 0.9

### security-architect (weight: 1.0)

- Vote: PostgreSQL
- Rationale: Better encryption at rest, audit logging
- Confidence: 0.8

### devops (weight: 1.5)

- Vote: DynamoDB
- Rationale: Managed service, auto-scaling
- Confidence: 0.7

ステップ 3：合意を算出する

重み付き投票を適用します。

PostgreSQL: (2.0 * 0.9) + (1.0 * 0.8) = 2.6
DynamoDB:   (1.5 * 0.7) = 1.05
MongoDB:    0

Total weight: 4.5
PostgreSQL: 2.6 / 4.5 = 57.8%
DynamoDB:   1.05 / 4.5 = 23.3%

Threshold: 60% → No clear consensus

ステップ 4：競合を解決する

合意に達しない場合：

戦略 1：専門家による決定

• 分野の専門家が強い意見（信頼度 >0.8）を持つ場合は、専門家の判断を優先します

戦略 2：討議ラウンド

• 反対するエージェントに、過半数の主張への意見を求めます
• 討議後に再投票します

戦略 3：エスカレーション

• 各エージェントが挙げた長所と短所を添えて、選択肢をユーザーに提示します
• ユーザーに最終決定を委ねます

ステップ 5：決定事項を記録する

最終決定を記録します。

## Decision Record

### Topic

Which database to use for the new service

### Decision

PostgreSQL

### Voting Summary

- PostgreSQL: 57.8% (2 votes)
- DynamoDB: 23.3% (1 vote)
- Consensus: NOT REACHED (below 60% threshold)

### Resolution Method

Expert override - database-architect (domain expert)
had 0.9 confidence in PostgreSQL

### Dissenting Opinion

DevOps preferred DynamoDB for operational simplicity.
Mitigation: Will use managed PostgreSQL (RDS) to
reduce operational burden.

### Decision Date

2026-01-23

</execution_process>

<best_practices>

1. 定足数を必須にする：最低限の参加数に達する前に決定しないでください
2. 専門性に応じて重み付けする：分野の専門家には、より大きな影響力を与えます
3. 反対意見を記録する：将来の参照のために少数意見を記録します
4. しきい値を明確にする：何をもって合意とするかを事前に定義します
5. エスカレーション経路を設ける：解決できない競合に対処する手順を用意します

</best_practices>

**競合解決のリクエスト**：

The architect wants microservices but the developer prefers monolith.
Resolve this conflict.

投票プロセス：

## Voting: Architecture Style

### Votes

- architect: Microservices (weight 1.5, confidence 0.8)
- developer: Monolith (weight 1.0, confidence 0.9)
- devops: Microservices (weight 1.0, confidence 0.6)

### Calculation

Microservices: (1.5 _ 0.8) + (1.0 _ 0.6) = 1.8
Monolith: (1.0 \* 0.9) = 0.9

Microservices: 66.7% → CONSENSUS REACHED

### Decision

Microservices, with modular monolith as migration path

### Dissent Mitigation

Start with modular monolith, extract services incrementally
to address developer's maintainability concerns.

</usage_example>

二重完了ゲートプロトコル

セッションを終了する前に、2 人以上のエージェントがタスクの完了を個別に確認することを必須にし、評議会またはマルチエージェントタスクが早期に終了するのを防ぎます。

問題

1 つのエージェントが「完了」と通知しただけでは、結果が不完全な場合があります。エージェントは自身のサブタスクを終えただけで、タスク全体が完了していない可能性があります。二重完了ゲートでは、完了したかどうか自体について合意を求めます。

プロトコル

1. エージェントごとの完了通知を追跡します：{ agent_id, timestamp, signal: "complete" }
2. window_seconds（デフォルト：60s）の時間枠内に、min_completions（デフォルト：2）件の通知を要求します
3. 1 つのエージェントだけが完了を通知した場合、nudge_after_seconds（デフォルト：30s）後に、残りのエージェントへ「確認の促し」を送信します
4. fallback_timeout（デフォルト：120s）経過後も完了通知が 1 件のみの場合は、warning: "single_agent_completion" フラグを付けて、単一エージェントによる完了を受け入れます

設定

completion_gate:
  min_completions: 2 # minimum agents that must signal done
  window_seconds: 60 # time window for completion consensus
  nudge_after_seconds: 30 # send nudge to remaining agents after first completion
  fallback_timeout: 120 # accept single completion after this timeout (with warning)

擬似コード

completions = []

on_agent_complete(agent_id):
  completions.push({ agent_id, timestamp: now() })

  if completions.length >= min_completions:
    window_start = completions[0].timestamp
    window_end = completions[-1].timestamp
    if (window_end - window_start) <= window_seconds:
      return CLOSE_SESSION(status: "consensus_complete")

  if completions.length == 1:
    schedule_nudge(nudge_after_seconds)
    schedule_fallback(fallback_timeout)

on_nudge_timeout():
  send_to_remaining_agents("A team member has signaled completion. Please confirm if the task is done.")

on_fallback_timeout():
  if completions.length < min_completions:
    return CLOSE_SESSION(status: "single_agent_complete", warning: "single_agent_completion")

LLM Council との統合

二重完了ゲートは、評議会セッションを終了する前に llm-council スキルによって呼び出されます。

1. ステージ 3 の統合後、各モデルに「この統合内容は完全かつ正確ですか？」と尋ねます
2. モデルは「complete」または「needs_revision」と回答します
3. ゲートを通過してセッションを終了するには、min_completions 件の「complete」通知が必要です
4. ゲートを通過できない（完了通知が不十分な）場合、議長が確認して決定します

投票プロトコル表の更新

プロトコル	使用場面	しきい値	定足数
単純多数決	通常の決定	>50%	50%
特別多数決	重要な変更	>=66%	75%
全会一致	重大な決定／取り消せない決定	100%	100%
重み付き投票	専門知識が必要な場合	可変	66%
優先順位付き投票	複数の選択肢がある場合	決選投票	75%
二重完了	評議会タスクの終了	2 エージェントが確認	100%

ルール

• 決定を下す前に、必ず定足数を満たしてください
• 専門分野の知識に応じて投票に重み付けしてください
• 今後の参考のため、反対意見を記録してください
• 評議会のセッションを終了する前に、必ず2つのエージェントによる完了の合意を得てください

関連ワークフロー

このスキルには、複雑なマルチエージェントのシナリオに対応するワークフローがあります。

• ワークフロー：.claude/workflows/consensus-voting-skill-workflow.md
• ワークフローを使用する場面：Queen/Worker トポロジーを使用したビザンチン障害耐性コンセンサスが必要な、重要なマルチエージェントの意思決定（アーキテクチャ上の決定、セキュリティレビュー、技術選定など）
• スキルを直接使用する場面：単純な投票シナリオ、または他のワークフローにコンセンサスを組み込む場合

ワークフローとの統合

このスキルは、マルチエージェントオーケストレーションにおける意思決定を可能にします。

ルーターの決定： .claude/workflows/core/router-decision.md

• ルーターが複数のレビュアーを起動し、コンセンサスを用いて意見の相違を解決します
• Planning Orchestration Matrix が、レビュー段階でのコンセンサス投票をトリガーします

アーティファクトのライフサイクル： .claude/workflows/core/skill-lifecycle.md

• コンセンサス投票によって、アーティファクトの非推奨化を決定します
• 複数のメンテナーが、互換性を損なう変更に投票します

関連ワークフロー：

• 投票前にエージェントを並列起動するための swarm-coordination スキル
• エンタープライズワークフローでは、設計レビューにコンセンサスを使用します
• .claude/workflows/enterprise/ のセキュリティレビューでは、セキュリティアーキテクトのコンセンサスが必要です

---

絶対遵守事項

1. 最低定足数を満たさない決定は、決して受け入れないでください — 定足数を満たさずに下された決定は正当性を欠きます。定足数を満たさない場合は、決定を延期するか、人間による介入を求めてください。
2. 専門分野の知識に応じて、必ず投票に重み付けしてください — 重みを等しくすると、一般的な知識を持つ開発者と専門分野のエキスパートに同じ影響力を与えてしまいます。決定の対象となる分野との関連性に応じて重み付けしてください。
3. 反対意見を決して破棄しないでください — 少数派の見解には、エッジケースやリスクに関する最も重要な兆候が含まれています。敗れた側を含め、すべての意見の根拠を記録してください。
4. エスカレーションの前に、必ず議論を経た再投票を行ってください — 議論を伴わない票の分裂は、コンセンサスの仕組みを無駄にします。人間にエスカレーションする前に、エージェントが根拠を共有して再投票する必要があります。
5. 重要な決定で棄権を認めないでください — 重大な決定での棄権は、エージェントが責任を回避していることを意味します。CRITICAL／UNANIMOUS のしきい値が適用される決定では、すべての参加者が投票しなければなりません。

アンチパターン

アンチパターン	失敗する理由	正しい対応
定足数を要求しない	ごく少数のグループが全員の代わりに決定するため、コンセンサスの正当性を欠きます	決定の種類ごとに最低参加しきい値を設定する
すべてのエージェントに等しい重みを付ける	専門分野の知識を無視し、シグナルの品質を低下させます	専門分野の知識との関連性に応じて重み付けする（範囲は 1.0～2.0）
反対意見の根拠を破棄する	エッジケースへの認識やリスクの兆候を失います	多数派・少数派を問わず、すべての投票と根拠を記録する
票が分裂した時点ですぐにエスカレーションする	意見の相違を解消できる可能性のある議論を省略します	人間にエスカレーションする前に、議論と再投票を必須とする
重要な決定で棄権を認める	難しい決定でエージェントが説明責任を回避します	CRITICAL な決定では、投票資格のあるすべての投票者の参加を必須とする

メモリプロトコル（必須）

開始前：

cat .claude/context/memory/learnings.md

完了後：

• 新しいパターン -> .claude/context/memory/learnings.md
• 発見した問題 -> .claude/context/memory/issues.md
• 下した決定 -> .claude/context/memory/decisions.md

中断を想定してください。コンテキストがリセットされることがあります。メモリに記録されていなければ、起きていないのと同じです。