# AIエージェントをソフトウェアに組み込むプラクティス # Eval Harness｜評価ハーネス 🎯 プロンプトを変えたら品質が下がっていた、モデルが更新されていつの間にか精度が劣化していた――気づいたのはユーザクレームの後でした。評価ハーネスがあれば、デプロイ前に検知できます。 🔥 解決する課題 AIエージェントは確率的であり、コードの単体テストのように全入力に対して正解が決定論的に定まりません。ハルシネーションは個別の目視確認では検出しきれず、LLMドリフト（プロバイダ側のモデル更新による品質変動）は自チームが何も変更していなくても発生します。評価ハーネスがなければ、品質劣化は本番のユーザクレームとして初めて顕在化します。 💡 提案パターン ゴールデンデータセット（入力と期待出力のペア）と自動評価関数（完全一致・LLM-as-Judge・カスタムメトリクス）を組み合わせた評価パイプラインを構築します。プロンプト・モデル・コードの変更ごとにCIで回帰検知を行い、変更がなくても日次〜週次の定期実行でLLMドリフトを検知します。評価はオフライン（デプロイ前バッチ）、オンライン（本番サンプリング）、シャドウ（A/B比較）の3層で実施します。回帰ゲートの閾値は安全性カテゴリでは劣化0件を推奨します。 ✅ 選定条件 使うとき： - エージェントが本番トラフィックを処理し、プロンプト・モデル・コードを継続的に変更する - 品質変化を定量的に示す必要がある（SLA遵守・規制報告等） - ゴールデンデータを作成・維持できるドメイン知識がある 使わないとき： - プロトタイプ段階でプロンプトが日単位で大幅に変わる - 出力がクリエイティブ生成（小説・詩）で正解の定義が困難 - 後段に決定論的検証ロジックがあり誤りが自動修正される ⚠️ 落とし穴 - ゴールデンデータは腐敗します。仕様変更に伴い期待出力が古くなると正しい出力が「回帰」と判定されます。オーナーと最終更新日を付与し定期棚卸ししてください - LLM-as-Judgeも確率的です。温度0でも判定が揺れる場合があるため、重要ケースでは3回実行の多数決を検討してください - ベースラインスコアの更新タイミングを明示的に定めておかないと、劣化が見えなくなります 🔧 実装方針 - ゴールデンデータセット（入力と期待出力のペア）にカテゴリ・評価関数名・期待キーワードを構造化して定義し、カテゴリ別に集計・回帰判定します - 評価パイプラインはオフライン（CI上でのデプロイ前バッチ）、オンライン（本番サンプリング）、シャドウ（新旧A/B比較）の3層で運用します - 回帰ゲートはベースラインとの相対比較で判定し、安全性カテゴリでは劣化0件、一般カテゴリでは概ね2%以内の劣化を閾値とします - シャドウ実行では副作用を持つツール実行をドライランにし、カナリアデプロイではsticky sessionで同一ユーザーを同一バージョンに固定します - ゴールデンデータにオーナーと最終更新日を付与し、仕様変更に伴う腐敗を定期棚卸しで防止します #AIエージェント# #ソフトウェアアーキテクチャ#