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

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

[拡張思考: エージェント最適化にはパフォーマンスメトリクス、ユーザーフィードバック分析、高度なプロンプトエンジニアリング技術を組み合わせたデータドリブンアプローチが必要です。成功は系統的評価、的を絞った改善、本番環境の安全性のためのロールバック機能を伴う厳密なテストに依存します。]

このスキルを使用するタイミング

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

このスキルを使用しないタイミング

• 新しいエージェントをゼロから構築している
• メトリクス、フィードバック、またはテストケースが利用できない
• タスクがエージェントのパフォーマンスまたはプロンプト品質に関連していない

手順

1. ベースラインメトリクスを確立し、代表的な例を収集する。
2. 障害モードを特定し、影響度の高い修正を優先する。
3. 測定可能なゴールとともにプロンプトおよびワークフローの改善を適用する。
4. テストで検証し、段階的な管理された方法で変更をロールアウトする。

安全性

• リグレッションテストなしでプロンプト変更をデプロイしないでください。
• 品質またはセーフティメトリクスが低下した場合は、迅速にロールバックします。

フェーズ 1: パフォーマンス分析とベースラインメトリクス

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

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

Use: context-manager
Command: analyze-agent-performance $ARGUMENTS --days 30

以下を含むメトリクスを収集します:

• タスク完了率（成功したタスク vs 失敗したタスク）
• レスポンス精度と事実的正確性
• ツール使用効率（正しいツール、呼び出し頻度）
• 平均レスポンス時間とトークン消費量
• ユーザー満足度指標（修正、再試行）
• ハルシネーション事件とエラーパターン

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

ユーザーインタラクションにおける反復的なパターンを特定します:

• 修正パターン: ユーザーが一貫して出力を変更する場所
• 明確化リクエスト: あいまいさが共通する領域
• タスク放棄: ユーザーが諦める地点
• フォローアップ質問: 不完全なレスポンスの指標
• 肯定的フィードバック: 保持する成功パターン

1.3 障害モード分類

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

• 命令理解の失敗: ロールまたはタスクの混乱
• 出力フォーマットエラー: 構造またはフォーマットの問題
• コンテキスト損失: 長い会話の劣化
• ツール誤用: 不正確または非効率なツール選択
• 制約違反: セーフティまたはビジネスルール違反
• エッジケース処理: 異常な入力シナリオ

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

定量的なベースラインメトリクスを生成します:

Performance Baseline:
- Task Success Rate: [X%]
- Average Corrections per Task: [Y]
- Tool Call Efficiency: [Z%]
- User Satisfaction Score: [1-10]
- Average Response Latency: [Xms]
- Token Efficiency Ratio: [X:Y]

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

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

2.1 Chain-of-Thought の強化

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

Use: prompt-engineer
Technique: chain-of-thought-optimization

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

2.2 Few-Shot 例の最適化

成功したインタラクションから高品質な例を選別します:

• 多様な例を選択し、一般的なユースケースをカバー
• 以前に失敗したエッジケースを含める
• 肯定例と否定例の両方を表示し、説明を付ける
• 例を順序付け、シンプルから複雑へ
• 例に注釈を付け、重要な決定ポイントを明記

例の構造:

Good Example:
Input: [ユーザーリクエスト]
Reasoning: [ステップバイステップの思考プロセス]
Output: [成功したレスポンス]
Why this works: [重要な成功要因]

Bad Example:
Input: [類似したリクエスト]
Output: [失敗したレスポンス]
Why this fails: [具体的な問題]
Correct approach: [修正版]

2.3 ロール定義の精緻化

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

• コア目的: 明確で単一文のミッション
• 専門領域: 特定の知識領域
• 行動特性: パーソナリティとインタラクションスタイル
• ツール習熟度: 利用可能なツールと使用時期
• 制約: エージェントが行わないべきこと
• 成功基準: タスク完了を測定する方法

2.4 Constitutional AI 統合

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

Constitutional Principles:
1. レスポンスする前に事実的正確性を検証する
2. 潜在的なバイアスまたは有害なコンテンツについて自己チェック
3. 出力フォーマットが要件に一致することを検証
4. レスポンスの完全性を確保
5. 以前のレスポンスとの一貫性を維持

批評と改訂ループを追加します:

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

2.5 出力フォーマットのチューニング

レスポンス構造を最適化します:

• 構造化テンプレート (一般的なタスク用)
• 動的フォーマット (複雑さに基づく)
• 段階的開示 (詳細情報の場合)
• Markdown 最適化 (可読性の場合)
• コードブロックフォーマット (構文ハイライト付き)
• テーブルとリスト生成 (データ提示用)

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

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

3.1 テストスイート開発

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

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

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

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

Use: parallel-test-runner
Config:
  - Agent A: Original version
  - Agent B: Improved version
  - Test set: 100 representative tasks
  - Metrics: Success rate, speed, token usage
  - Evaluation: Blind human review + automated scoring

統計的有意性テスト:

• 最小サンプルサイズ: バリアントあたり 100 タスク
• 信頼レベル: 95% (p < 0.05)
• 効果量計算 (Cohen's d)
• 将来のテストの検定力分析

3.3 評価メトリクス

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

タスクレベルメトリクス:

• 完了率 (二項成功/失敗)
• 正確さスコア (0-100% 精度)
• 効率スコア (実行ステップ数 vs 最適)
• ツール使用の適切性
• レスポンスの関連性と完全性

品質メトリクス:

• ハルシネーション率 (レスポンスあたりの事実的エラー)
• 一貫性スコア (以前のレスポンスとの一致)
• フォーマット準拠 (指定された構造に一致)
• セーフティスコア (制約順守)
• ユーザー満足度予測

パフォーマンスメトリクス:

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

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

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

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

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

監視とロールバック機能を備えた安全なロールアウト。

4.1 バージョン管理

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

Version Format: agent-name-v[MAJOR].[MINOR].[PATCH]
Example: customer-support-v2.3.1

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

バージョン履歴を保持します:

• Git ベースのプロンプトストレージ
• 改善の詳細を含む変更ログ
• バージョンごとのパフォーマンスメトリクス
• ロールバック手順のドキュメント化

4.2 段階的ロールアウト

段階的なデプロイメント戦略:

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

4.3 ロールバック手順

迅速な復旧メカニズム:

Rollback Triggers:
- 成功率がベースラインから 10% 以上低下
- 重大エラーが 5% 以上増加
- ユーザー苦情が急増
- タスクあたりのコストが 20% 以上増加
- セーフティ違反が検出される

Rollback Process:
1. モニタリングで問題を検出
2. チームに直ちに警告
3. 以前の安定版に切り替え
4. 根本原因を分析
5. 修正と再テストを行い、再試行前に確認

4.4 継続的な監視

リアルタイムのパフォーマンストラッキング:

• 主要メトリクスのダッシュボード
• 異常検知アラート
• ユーザーフィードバック収集
• 自動リグレッションテスト
• 週単位のパフォーマンスレポート

成功基準

エージェント改善は以下の場合に成功しています:

• タスク成功率が 15% 以上向上
• ユーザー修正が 25% 以上減少
• セーフティ違反の増加がない
• レスポンス時間がベースラインの 10% 以内に留まる
• タスクあたりのコストが 5% を超えて増加しない
• 肯定的なユーザーフィードバックが増加

デプロイ後レビュー

本番環境での 30 日間の使用後:

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

継続的改善サイクル

定期的な改善のペースを確立します:

• 週単位: メトリクスを監視し、フィードバックを収集
• 月単位: パターンを分析し、改善を計画
• 四半期: 新しい機能を伴う主要なバージョン更新
• 年単位: 戦略レビューとアーキテクチャ更新

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

制限事項

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