agent-orchestration-improve-agent

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

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

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

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

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

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

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

手順

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

安全性

• 回帰テストなしでプロンプトの変更をデプロイすることは避けてください。
• 品質や安全性の指標が後退した場合は、速やかにロールバックしてください。

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

context-manager を使用して履歴データを収集し、エージェントのパフォーマンスを包括的に分析します。

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

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

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

• タスク完了率 (成功したタスクと失敗したタスク)
• 応答の正確性と事実の正しさ
• ツール使用の効率性 (正しいツール、呼び出し頻度)
• 平均応答時間とトークン消費量
• ユーザー満足度の指標 (修正、再試行)
• ハルシネーションの発生とエラーパターン

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 思考の連鎖の強化

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

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

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

2.2 少数ショット例の最適化

成功したやり取りから高品質な例を厳選します:

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

例の構造:

Good Example:
Input: [User request]
Reasoning: [Step-by-step thought process]
Output: [Successful response]
Why this works: [Key success factors]

Bad Example:
Input: [Similar request]
Output: [Failed response]
Why this fails: [Specific issues]
Correct approach: [Fixed version]

2.3 役割定義の洗練

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

• 中心的な目的: 明確で一文のミッション
• 専門分野: 具体的な知識領域
• 行動特性: パーソナリティと対話スタイル
• ツールの習熟度: 利用可能なツールとその使用場面
• 制約: エージェントが行うべきでないこと
• 成功基準: タスク完了を測定する方法

2.4 Constitutional AI の統合

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

Constitutional Principles:
1. Verify factual accuracy before responding
2. Self-check for potential biases or harmful content
3. Validate output format matches requirements
4. Ensure response completeness
5. Maintain consistency with previous responses

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

• 初回レスポンスの生成
• 原則に照らした自己批判
• 問題が検出された場合の自動修正
• 出力前の最終検証

2.5 出力形式のチューニング

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

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

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

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

3.1 テストスイートの開発

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

Test Categories:
1. Golden path scenarios (common successful cases)
2. Previously failed tasks (regression testing)
3. Edge cases and corner scenarios
4. Stress tests (complex, multi-step tasks)
5. Adversarial inputs (potential breaking points)
6. Cross-domain tasks (combining capabilities)

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

オリジナルと改善版のエージェントを比較します:

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% の精度）
• 効率性スコア（最適な手順数と実際の手順数の比較）
• ツール使用の適切さ
• レスポンスの関連性と完全性

品質指標:

• ハルシネーション率（レスポンスあたりの事実誤認）
• 一貫性スコア（以前のレスポンスとの整合性）
• フォーマット準拠（指定された構造との一致）
• 安全性スコア（制約の遵守）
• ユーザー満足度の予測

パフォーマンス指標:

• レスポンスレイテンシ（最初のトークンまでの時間）
• 総生成時間
• トークン消費量（入力 + 出力）
• タスクあたりのコスト（API 利用料金）
• メモリ/コンテキストの効率性

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

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

• ブラインド評価（評価者はバージョンを知らない）
• 明確な基準を備えた標準化されたルーブリック
• サンプルごとに複数の評価者（評価者間信頼性）
• 定性的フィードバックの収集
• 選好ランキング（A と B の比較）

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

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

4.1 バージョン管理

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

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

MAJOR: Significant capability changes
MINOR: Prompt improvements, new examples
PATCH: Bug fixes, minor adjustments

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

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

4.2 段階的ロールアウト

段階的なデプロイ戦略:

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

4.3 ロールバック手順

迅速な復旧メカニズム:

Rollback Triggers:
- Success rate drops >10% from baseline
- Critical errors increase >5%
- User complaints spike
- Cost per task increases >20%
- Safety violations detected

Rollback Process:
1. Detect issue via monitoring
2. Alert team immediately
3. Switch to previous stable version
4. Analyze root cause
5. Fix and re-test before retry

4.4 継続的な監視

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

• 主要指標を表示するダッシュボード
• 異常検知アラート
• ユーザーフィードバックの収集
• 自動リグレッションテスト
• 週次のパフォーマンスレポート

成功基準

エージェントの改善は、次の条件を満たしたときに成功とみなされます:

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

デプロイ後のレビュー

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

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

継続的な改善サイクル

定期的な改善のサイクルを確立します。

• Weekly：指標を監視し、フィードバックを収集します
• Monthly：傾向を分析し、改善を計画します
• Quarterly：新機能を含むメジャーバージョンの更新を行います
• Annually：戦略を見直し、アーキテクチャを更新します

エージェントの最適化は反復的なプロセスです。各サイクルで前回の学びを積み重ね、安定性と安全性を維持しながら、パフォーマンスを段階的に向上させます。