mixture-of-experts

Mixture of Experts（MoE）監査

Mixture of Experts パターンは、強力な批判的思考のフレームワークです。複数の独立した「専門家ペルソナ」に、単一のトピックをまったく異なる視点から分析させ、調査結果を相互に照合することで、視野が狭くなるのを防ぎます。

コードベース、機能計画、デプロイプロセス、リポジトリのガバナンススキルなど、文字どおりあらゆるものに適用できます。

使用する場面

• 「このアーキテクチャ計画を、Mixture of Experts を使ってレビューしてください」
• 「意図が重複しているスキルはありますか？」
• 「このデプロイスクリプトを、セキュリティとパフォーマンスの観点から監査してください」
• 複雑な設計上の判断に直面し、厳密かつ多角的な批評が必要な場合。

ワークフロー

1. トピックを特定する ユーザーが監査したい内容（例：「リポジトリ内のスキルの重複」「新しいキャッシュアーキテクチャ」「リリースプロセス」）を把握します。

2. 専門家ペルソナを定義する トピックに深く関係しながらも、互いに独立した視点を持つ専門家を2～3人考案します。ユーザーが幅広いサブエージェントによる調査を明示的に求めている場合、または各領域が真に独立している場合に限り、3人を超えてもかまいません。親の計画を言い換えるだけのエージェントを起動しないでください。 各専門家について、以下の項目を含む簡潔な担当範囲の契約を記述します。

   • Role：批評の視点。
   • Scope：調査する証拠またはサブシステム。
   • Out of scope：判断または編集してはならない内容。
   • Expected output：調査結果、矛盾点、または成果物に関する提案。
   • Fallback：視点の調査がタイムアウトするか、部分的な証拠しか得られない場合の対応。
   • Integration contract：調査結果が影響する具体的なドキュメント、チェック、スキル、またはコード領域。 例：
   • リポジトリのガバナンスの場合： 「コードベース監査担当者」、「スキル分析担当者」
   • システムアーキテクチャの場合： 「セキュリティ専門家」、「スケーラビリティエンジニア」、「コスト分析担当者」
   • フロントエンドコンポーネントの場合： 「アクセシビリティ監査担当者」、「パフォーマンス専門家」
   • 製品に関する主張や外部プラットフォームのサポートの場合： 「エビデンス／検証 QA」。この視点では、どのような主張がなされているか、その主張を正確に証明するエビデンスは何か、どのような検証や情報源の鮮度が必要か、そして何が主張に含まれないかを確認します。プラットフォームのサポート、生成アセット、リポジトリ横断のクリーンアップ、ベンチマークの証明、公開された互換性、外部 API に関する話題を扱うスレッドで活用してください。
   • エビデンスアーカイブ、PDSA ループ、ドッグフードの記録、テンプレート、証明パケットの場合： 「エビデンス／保持 QA」。この視点では、その成果物が ADR、最新の台帳、過去のエビデンス、公開再現性カード、テンプレート、チェック／ツール候補、削除候補のいずれなのか、それがメンテナーへの振り分け、現在のステータス、過去の来歴、公開監査のどれを目的としているのか、どの主張を保護するのか、ステータス／種類／制限事項／主張に含まれない事項が記載されているか、古い証明との乖離を防ぐ次の処置は何かを確認します。
   • E2E 実行と評価（ドッグフォーディング）の場合： 「ハーネス QA エキスパート」。ワークフロー、ツールチェーン、型付きアクション、ベンチマークループを変更する場合は、ハーネス QA の視点を加えてください。利用可能であればサブエージェントを使用し、利用できない場合はこの視点を順番に適用し、ラベルを付けてください。変更によって H2+ の成熟度を主張する場合、またはアクション／ベンチマークの挙動を変更する場合は、最終報告または PR の概要にレビュー成果物を記録してください。記録する内容は、範囲、使用したリポジトリ、実行したコマンド／アクション、到達したエビデンスレベル、残る未証明事項です。ドキュメントのみの整合性調整では、より控えめな表現を使用できます。準備状況に関する主張を変更しない限り、独立した成果物は不要です。
   • スチュワードシップ、ツール、ハーネス、成長中の製品の場合： 「世代別アーキテクチャ懐疑担当者」。この視点では、何を削除、統合、ネイティブに維持、ドキュメント／FAQ に移動、公開 API として抽出、スキーマから生成、ハーネスの証明へ昇格できるかを確認します。さらに、その設計が次のリポジトリ、次のエージェント、次のバージョン、次のメンテナーに役立つのか、それともパスのマジック、単一利用者向けのハック、過剰な主張、「全面的な採用」への逸脱、ツール依存のループを生み出すのかを問います。明確な約束は次のとおりです。Skill Steward は、リポジトリが現在の形を超えて成長したことに気づき、次に必要な最小限のレイヤーを選び、その変更によって将来の作業が減ることを証明できるよう支援します。
   • 停滞した PDSA、繰り返されるブロッカー、エビデンスループ、リポジトリの課題の場合： 「ループ圧縮／課題チューター」。この視点では、当初のユーザーの目標を何が遅らせているのか、今すぐ修正できる担当箇所はどこか、その修正を証明するネイティブのゲートは何か、どの表層をなくせるか、また、その課題をさらにエビデンス成果物を増やすのではなく、エラーメッセージ、FAQ の項目、テスト、スキーマ、スクリプト、アクション候補、最新の台帳の更新のいずれかに反映すべきかを確認します。

3. サブエージェントを起動する 現在のホストで利用可能なサブエージェント機能を使って、これらの専門家を個別に起動してください。それぞれの視点から対象トピックを監査するよう、明確なプロンプトを与えてください。ユーザーが実装を明示的に依頼していない限り、読み取り専用の視点は読み取り専用のままにしてください。サブエージェントのツールが利用できない場合は、専門家の視点を順番に適用し、並列実行ではない MoE であることを明記してください。

4. 所見を相互参照する すべてのサブエージェントから報告が届くまで待つか、宣言済みのフォールバック地点で終了してください。それぞれの独立した批評を統合します。構造上の矛盾、見落とされたエッジケース、保守上の落とし穴、（リポジトリスキルの場合は）意図の重複がないか確認してください。視点の処理がタイムアウトした場合、または利用できないエビデンスが返された場合は、missing_lens、partial_lens、timed_out_lens、superseded_lens のいずれかとしてラベル付けしてください。そのうえで、再試行する、確信度を下げて続行する、または不足している視点により、より強い主張ができないと明記する、のいずれかを行ってください。MoE の結果が実装、エビデンス、準備状況に関する主張に影響する場合は、レンズのステータスを簡潔にまとめてください。

   レンズのステータスをまとめる例：

   | Lens | Status | Integration |
   |------|--------|-------------|
   | Evidence QA | integrated | limited the claim ceiling |
   | Operations QA | partial | accepted as input, not proof |
   | Skeptic | timed_out | no stronger claim based on this lens |
   

   Skeptic レンズが有効な場合は、新しいツールを推奨する前に、最小限で有用なレイヤーと、削除または統合できる選択肢を示してください。広範な構成に関する質問では、有効な対応が分割、圧縮、昇格、降格、削除、または既存の仕組みを維持することのどれかも示してください。Evidence / Retention QA レンズが有効な場合は、新しい証拠を推奨する前に、成果物のステータス、保護対象の主張、保持・処分の経路を示してください。批評によって永続的なドキュメント、スキル、契約、またはツールが変わる場合は、新しいドクトリンを作成するのではなく、docs/evidence/ の Pattern Promotion Review を作成するか、作成を推奨してください。 リポジトリ全体に広がる問題については、MoE がレーン候補やレーン間の矛盾を発見してもかまいません。これらの所見は、助言的な批評の入力に限られます。書き込みを許可したり、作業者を割り当てたり、結果を承認したり、親による統合を置き換えたりするものではありません。親レーンの契約と直接修正の権限は multi-agent-handoff に属します。

5. 出力モードを選択する

   • 読み取り専用の批評モード： ユーザーが分析、議論、批評、または検証のみを求めている場合は、所見をチャットで要約します。ファイルや計画は作成しないでください。
   • 実装計画モード： ユーザーが計画または承認済みの変更を求めている場合は、簡潔な実装計画または学習成果物を作成します。
   • 実行モード： ユーザーが実装を明示的に承認した場合は、対象範囲を最小限に絞って変更を適用し、検証します。検証、ジェネレーター、または鮮度チェックを省略するか、実行できない場合は、実行していないコマンド、その理由、およびその結果として立証できていない主張を正確に記録します。

6. ユーザーに提示する 重要な所見、矛盾、実行可能な推奨事項を先に示してください。統合の最後に、次のいずれかの処置を示します。

   • chat_only：有用な批評のみで、永続的な変更はありません。
   • promote_to_artifact：ADR、FAQ、エビデンスノート、スキル、ドキュメントマップ、または Pattern Promotion Review を更新します。
   • convert_to_check：繰り返し確認される決定論的な事実は、テスト、バリデーター、ジェネレーター鮮度チェック、またはハーネスプローブにします。
   • compress_existing：重複するガイダンスやナビゲーションを統合しつつ、個別の真実を維持します。
   • delete_or_retire：有用な内容を別の場所に反映した後、古くなったガイダンス、証拠、または足場を削除します。
   • leave_native：作業をリポジトリ既存のコマンド、フレームワーク、または担当者の領域に残します。

   MoE の結果から実装に進む場合は、実行を multi-agent-handoff に引き継ぐか、主張の上限を明示したうえで親の管理下に置いてください。MoE の所見だけではレーンの最終状態にならず、一時的な証拠や作業者の証拠がソース所有になるわけでもありません。 次の手順でファイルを変更するか、対象範囲を広げる場合に限り、承認を求めてください。

簡潔なルール：独立性のために起動し、矛盾のために統合し、将来の動作を変えるものだけを永続化します。

インストール

npx skills add arenukvern/skill_steward --skill mixture-of-experts

ソース

references/sources.md を参照してください。