マルチエージェント・ブレインストーミング（構造化設計レビュー）

目的

単一エージェントの設計を、堅牢で、レビュー検証済みの設計に変換します。 複数の制約付きエージェントを使用して、正式なピアレビュープロセスをシミュレートします。

このスキルが存在する理由：

• 隠された仮定を浮き彫りにする
• 失敗モードを早期に特定する
• 非機能的制約を検証する
• 実装前に設計をストレステストする
• アイデアの群れのカオスを防ぐ

これは並列ブレインストーミングではありません。 これは強制されたロールを持つ順序的設計レビューです。

---

運用モデル

• 1 つのエージェントが設計する
• 他のエージェントがレビューする
• エージェントは自らのマンデートを超えてはいけない
• 創造性は集中化され、批判は分散される
• 決定は明示的に記録される

プロセスはゲート制御されており、設計によって終了します。

---

エージェント・ロール（交渉不可）

各エージェントは厳密なスコープ制限の下で動作します。

1️⃣ プライマリ・デザイナー（リード・エージェント）

ロール：

• 設計を所有する
• 標準的な brainstorming スキルを実行する
• 決定ログを保持する

可能なこと：

• 説明を求める質問を行う
• 設計と代替案を提案する
• フィードバックに基づいて設計を修正する

不可能なこと：

• 最終設計を自己承認する
• レビュアーの異議を無視する
• ロック後に要件を発明する

---

2️⃣ スケプティック / チャレンジャー・エージェント

ロール：

• 設計が失敗することを想定する
• 弱点とリスクを特定する

可能なこと：

• 仮定に質問する
• エッジケースを特定する
• 曖昧性または過信を強調する
• YAGNI 違反にフラグを立てる

不可能なこと：

• 新機能を提案する
• システムを再設計する
• 代替アーキテクチャを提供する

プロンプトガイダンス：

「この設計が本番環境で失敗することを想定してください。なぜでしょうか？」

---

3️⃣ 制約ガーディアン・エージェント

ロール：

• 非機能的制約と実世界の制約を強制する

焦点領域：

• パフォーマンス
• スケーラビリティ
• 信頼性
• セキュリティ＆プライバシー
• 保守性
• 運用コスト

可能なこと：

• 制約を違反する設計を却下する
• 制限の説明を要求する

不可能なこと：

• 製品目標について議論する
• 機能変更を提案する
• 明記された要件を超えて最適化する

---

4️⃣ ユーザー・アドボケート・エージェント

ロール：

• エンドユーザーを代表する

焦点領域：

• 認知負荷
• ユーザビリティ
• フロー明確性
• ユーザーの観点からのエラー処理
• 意図と体験のミスマッチ

可能なこと：

• 紛らわしいまたは誤解を招く側面を特定する
• 不適切なデフォルトまたは不明確な動作にフラグを立てる

不可能なこと：

• アーキテクチャを再設計する
• 機能を追加する
• 明記されたユーザーの目標をオーバーライドする

---

5️⃣ インテグレータ / アービター・エージェント

ロール：

• 紛争を解決する
• 決定をファイナライズする
• 終了基準を強制する

可能なこと：

• 異議を受け入れるか却下する
• 設計修正を要求する
• 設計が完了したことを宣言する

不可能なこと：

• 新しいアイデアを発明する
• 要件を追加する
• 根拠なくロック済み決定を再開する

---

プロセス

フェーズ 1 — 単一エージェント設計

1. プライマリ・デザイナーが標準的な brainstorming スキルを実行する
2. 理解ロックが完了し確認される
3. 初期設計が作成される
4. 決定ログが開始される

他のエージェントはまだ参加しません。

---

フェーズ 2 — 構造化レビュー・ループ

エージェントは順序立てて 1 つずつ以下の順序で呼び出されます：

1. スケプティック / チャレンジャー
2. 制約ガーディアン
3. ユーザー・アドボケート

各レビュアーの場合：

• フィードバックは明示的でスコープ化される必要があります
• 異議は仮定または決定を参照する必要があります
• 新機能は導入されない場合があります

プライマリ・デザイナーは：

• 各異議に応答する
• 必要に応じて設計を修正する
• 決定ログを更新する

---

フェーズ 3 — 統合とアービトレーション

インテグレータ / アービターは以下を確認します：

• 最終設計
• 決定ログ
• 未解決の異議

アービターは明示的に決定する必要があります：

• どの異議が受け入れられるか
• どれが却下されるか（根拠付き）

---

決定ログ（必須成果物）

決定ログは以下を記録する必要があります：

• 下した決定
• 検討された代替案
• 提起された異議
• 解決策と根拠

完成した決定ログなしに有効な設計は存在しません。

---

終了基準（ハード・ストップ）

以下のすべてが真である場合にのみ、マルチエージェント・ブレインストーミングを終了できます：

• 理解ロックが完了した
• すべてのレビュアーエージェントが呼び出された
• すべての異議が解決されたか明示的に却下された
• 決定ログが完成した
• アービターが設計を受け入れ可能と宣言した

いずれかの基準が満たされていない場合：

• レビューを続行する
• 実装に進まない ルーティングまたはオーケストレーション層によってこのスキルが呼び出された場合、最終的な処分を明示的に以下のいずれかとして報告する必要があります：APPROVED、REVISE、または REJECT（簡潔な根拠付き）。

---

このスキルが防ぐ失敗モード

• アイデアの群れのカオス
• 幻覚による合意
• 過信に満ちた単一エージェント設計
• 隠された仮定
• 早すぎる実装
• 終わりのない議論

---

重要な原則

• 1 人のデザイナー、多くのレビュアー
• 創造性は集中化される
• 批判は制約される
• 決定は明示的である
• プロセスは終了する必要がある

---

最後の注意

このスキルは 1 つの質問に自信を持って答えるために存在します：

「この設計が失敗した場合、早期に問題を捉えるために合理的なあらゆる対策を講じたのか？」

答えが不明確な場合は、このスキルを終了しないでください。

使用時期

上記の概要で説明されたワークフローまたはアクションを実行する場合、このスキルが適用されます。

制限事項

• 上記で説明されたスコープに明確に一致するタスクの場合にのみ、このスキルを使用してください。
• 出力を環境固有の検証、テスト、または専門家レビューの代替として扱わないでください。
• 必要な入力、権限、安全性境界、または成功基準が不足している場合は、停止して説明を求めてください。