SamuelChien/mega-skills-collection

エージェントパフォーマンス最適化ワークフロー

パフォーマンス分析、プロンプトエンジニアリング、継続的な反復を通じて、既存のエージェントを体系的に改善します。

[拡張思考: エージェントの最適化には、パフォーマンス指標、ユーザーフィードバック分析、高度なプロンプトエンジニアリング手法を組み合わせたデータ駆動型のアプローチが必要です。成功は体系的な評価、的を絞った改善、そして本番環境の安全性を確保するためのロールバック機能を備えた厳格なテストにかかっています。]

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

• 既存のエージェントのパフォーマンスや信頼性を向上させるとき
• 失敗モード、プロンプト品質、ツールの使用法を分析するとき
• 構造化されたA/Bテストや評価スイートを実行するとき
• エージェントの反復的な最適化ワークフローを設計するとき

このスキルを使用しない場合

• 全く新しいエージェントをゼロから構築する場合
• 利用可能な指標、フィードバック、テストケースがない場合
• タスクがエージェントのパフォーマンスやプロンプト品質に関連していない場合

手順

1. ベースラインとなる指標を確立し、代表的なサンプルを収集します。
2. 失敗モードを特定し、影響の大きい修正を優先します。
3. 測定可能な目標を設定してプロンプトとワークフローの改善を適用します。
4. テストで検証し、管理された段階で変更を展開します。

安全性

• 回帰テストなしにプロンプトの変更を展開しないでください。
• 品質や安全性の指標が悪化した場合は、すぐにロールバックしてください。

フェーズ1: パフォーマンス分析とベースライン指標

コンテキストマネージャーを使用した過去データ収集によるエージェントパフォーマンスの包括的な分析。

1.1 パフォーマンスデータの収集

使用: context-manager
コマンド: analyze-agent-performance $ARGUMENTS --days 30

以下の指標を収集します:

• タスク完了率 (成功 vs 失敗タスク)
• 応答の正確性と事実に基づく正しさ
• ツール使用効率 (正しいツール、呼び出し頻度)
• 平均応答時間とトークン消費量
• ユーザー満足度の指標 (訂正、再試行)
• 幻覚インシデントとエラーパターン

1.2 ユーザーフィードバックパターン分析

ユーザーインタラクションにおける繰り返しパターンを特定します:

• 訂正パターン: ユーザーが一貫して出力を修正する箇所
• 明確化リクエスト: あいまいさが発生しやすい一般的な領域
• タスク放棄: ユーザーが諦めてしまう箇所
• フォローアップ質問: 不完全な応答を示す指標
• 肯定的なフィードバック: 維持すべき成功パターン

1.3 失敗モード分類

根本原因ごとに障害を分類します:

• 指示の誤解: 役割やタスクの混乱
• 出力形式エラー: 構造やフォーマットの問題
• コンテキストの喪失: 長い会話での劣化
• ツールの誤用: 不適切または非効率なツール選択
• 制約違反: 安全性やビジネスルールの違反
• エッジケース処理: 異常な入力シナリオ

1.4 ベースラインパフォーマンスレポート

定量的なベースライン指標を生成します:

パフォーマンスベースライン:
- タスク成功率: [X%]
- タスクあたり平均訂正回数: [Y]
- ツール呼び出し効率: [Z%]
- ユーザー満足度スコア: [1-10]
- 平均応答レイテンシ: [Xms]
- トークン効率比: [X:Y]

フェーズ2: プロンプトエンジニアリングの改善

prompt-engineerエージェントを使用して高度なプロンプト最適化手法を適用します。

2.1 Chain-of-Thoughtの強化

構造化された推論パターンを実装します:

使用: prompt-engineer
手法: chain-of-thought-optimization

• 明示的な推論ステップの追加: 「ステップバイステップでアプローチしましょう...」
• 自己検証チェックポイントの追加: 「進める前に、検証してください...」
• 複雑なタスクのための再帰的分解の実装
• デバッグのための推論トレースの可視化

2.2 Few-Shot Exampleの最適化

成功したインタラクションから高品質のサンプルを厳選します:

• 多様なサンプルを選択して一般的なユースケースをカバーする
• 以前に失敗したエッジケースを含める
• 説明付きで肯定的な例と否定的な例の両方を示す
• サンプルを単純なものから複雑なものへ並べる
• サンプルに重要な決定ポイントを注釈する

サンプル構造:

良い例:
入力: [ユーザーリクエスト]
推論: [ステップバイステップの思考プロセス]
出力: [成功した応答]
これが機能する理由: [主要な成功要因]

悪い例:
入力: [同様のリクエスト]
出力: [失敗した応答]
これが失敗する理由: [具体的な問題]
正しいアプローチ: [修正版]

2.3 ロール定義の改善

エージェントのアイデンティティと能力を強化します:

• コアの目的: 明確で1文のミッション
• 専門知識領域: 特定の知識分野
• 行動特性: 個性とインタラクションスタイル
• ツール習熟度: 利用可能なツールとその使用タイミング
• 制約: エージェントがすべきでないこと
• 成功基準: タスク完了の測定方法

2.4 Constitutional AIの統合

自己修正メカニズムを実装します:

Constitutional Principles:
1. 応答前に事実の正確性を検証する
2. バイアスや有害なコンテンツの可能性を自己チェックする
3. 出力形式が要件に一致しているか検証する
4. 応答の完全性を確保する
5. 以前の応答との一貫性を維持する

批判と修正のループを追加します:

• 初期応答の生成
• 原則に対する自己批判
• 問題が検出された場合の自動修正
• 出力前の最終検証

2.5 出力形式の調整

応答構造を最適化します:

• 一般的なタスク用の構造化テンプレート
• 複雑さに基づく動的フォーマット
• 詳細情報のための段階的開示
• 読みやすさのためのマークダウン最適化
• シンタックスハイライト付きのコードブロックフォーマット
• データ表示のためのテーブルとリストの生成

フェーズ3: テストと検証

A/B比較を伴う包括的なテストフレームワーク。

3.1 テストスイートの開発

代表的なテストシナリオを作成します:

テストカテゴリ:
1. ゴールデンパスシナリオ (一般的な成功ケース)
2. 過去に失敗したタスク (回帰テスト)
3. エッジケースとコーナーシナリオ
4. ストレステスト (複雑でマルチステップのタスク)
5. 敵対的入力 (潜在的なブレークポイント)
6. クロスドメインタスク (機能の組み合わせ)

3.2 A/Bテストフレームワーク

元のエージェントと改善されたエージェントを比較します:

使用: parallel-test-runner
設定:
  - エージェントA: 元のバージョン
  - エージェントB: 改善されたバージョン
  - テストセット: 100の代表的なタスク
  - 指標: 成功率、速度、トークン使用量
  - 評価: ブラインド人間レビュー + 自動スコアリング

統計的有意差検定:

• 最小サンプルサイズ: バリアントあたり100タスク
• 信頼水準: 95% (p < 0.05)
• 効果量の計算 (コーエンのd)
• 将来のテストのための検出力分析

3.3 評価指標

包括的なスコアリングフレームワーク:

タスクレベルの指標:

• 完了率 (成功/失敗のバイナリ)
• 正解スコア (0-100%の正確性)
• 効率スコア (実行ステップ数 vs 最適)
• ツール使用の適切性
• 応答の関連性と完全性

品質指標:

• 幻覚率 (応答あたりの事実誤認数)
• 一貫性スコア (以前の応答との整合性)
• フォーマット準拠 (指定された構造に一致)
• 安全性スコア (制約の遵守)
• ユーザー満足度予測

パフォーマンス指標:

• 応答レイテンシ (最初のトークンまでの時間)
• 総生成時間
• トークン消費量 (入力 + 出力)
• タスクあたりのコスト (API使用料)
• メモリ/コンテキスト効率

3.4 人間による評価プロトコル

構造化された人間によるレビュープロセス:

• ブラインド評価 (評価者はバージョンを知らない)
• 明確な基準を持つ標準化されたルーブリック
• サンプルあたり複数の評価者 (評価者間信頼性)
• 定性フィードバックの収集
• 嗜好ランキング (A vs B 比較)

フェーズ4: バージョン管理とデプロイ

監視とロールバック機能を備えた安全な展開。

4.1 バージョン管理

体系的なバージョニング戦略:

バージョン形式: agent-name-v[MAJOR].[MINOR].[PATCH]
例: customer-support-v2.3.1

MAJOR: 機能の大幅な変更
MINOR: プロンプトの改善、新しい例
PATCH: バグ修正、軽微な調整

バージョン履歴を維持:

• Gitベースのプロンプトストレージ
• 改善詳細を含む変更ログ
• バージョンごとのパフォーマンス指標
• 文書化されたロールバック手順

4.2 段階的ロールアウト

段階的な展開戦略:

1. アルファテスト: 内部チームによる検証 (トラフィック5%)
2. ベータテスト: 選択されたユーザー (トラフィック20%)
3. カナリアリリース: 段階的増加 (20% → 50% → 100%)
4. フルデプロイ: 成功基準達成後
5. 監視期間: 7日間の観察ウィンドウ

4.3 ロールバック手順

迅速な復旧メカニズム:

ロールバックトリガー:
- 成功率がベースラインから10%以上低下
- クリティカルエラーが5%以上増加
- ユーザーからの苦情が急増
- タスクあたりのコストが20%以上増加
- 安全性違反が検出

ロールバックプロセス:
1. 監視で問題を検出
2. すぐにチームに警告
3. 以前の安定バージョンに切り替え
4. 根本原因を分析
5. 再試行前に修正と再テスト

4.4 継続的監視

リアルタイムのパフォーマンス追跡:

• 主要指標のダッシュボード
• 異常検出アラート
• ユーザーフィードバック収集
• 自動回帰テスト
• 週次パフォーマンスレポート

成功基準

エージェントの改善は以下の場合に成功とみなされます:

• タスク成功率が15%以上向上
• ユーザー訂正が25%以上減少
• 安全性違反の増加なし
• 応答時間がベースラインの10%以内に維持
• タスクあたりのコストが5%以上増加しない
• 肯定的なユーザーフィードバックが増加

デプロイ後レビュー

本番稼働から30日後:

1. 蓄積されたパフォーマンスデータを分析
2. ベースラインと目標を比較
3. 新たな改善機会を特定
4. 学んだ教訓を文書化
5. 次の最適化サイクルを計画

継続的改善サイクル

定期的な改善サイクルを確立:

• 毎週: 指標の監視とフィードバックの収集
• 毎月: パターンの分析と改善の計画
• 四半期毎: 新機能を伴うメジャーバージョンアップデート
• 毎年: 戦略的レビューとアーキテクチャの更新

覚えておいてください: エージェントの最適化は反復的なプロセスです。各サイクルは以前の学習に基づいて構築され、安定性と安全性を維持しながら徐々にパフォーマンスを向上させます。

制限事項

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