モデル・ツール変更で品質を落とさない回帰チェック

コードが同じでも、エージェントの挙動は変わる

AIエージェントの動作は、アプリケーションコードだけで決まりません。モデル、プロンプト、ツール定義、検索対象、権限、外部サービスの仕様、実行時の設定が組み合わさって一つの挙動を作ります。

そのため、モデルや接続先を差し替える作業は単純な部品交換ではなく、業務システムの変更として扱います。変更理由、対象範囲、期待効果、影響を受けるワークフローを記録してから評価を始めます。

変更点を棚卸しし、影響度を決める

変更の名前ではなく、実行結果へ与える影響で分類します。たとえばツールの説明文だけを直す場合でも、エージェントの選択や引数が変わるなら、外部更新に影響する変更です。

影響度は、閲覧のみ、下書き生成、要承認の更新、自動更新などの権限と、対象データの重要度を組み合わせて決めます。影響度が高いほど、評価ケースと承認者を増やします。

• モデル名、版、主要な実行設定を記録した
• プロンプト、判断ルール、ツール定義の差分を記録した
• 接続先、認証範囲、利用するデータの変更を確認した
• 影響を受けるワークフローと外部アクションを特定した

回帰テストは、業務上の不変条件を守る

回帰テストには、過去に正常完了した代表ケースだけでなく、拒否すべき依頼、入力不足、ツール障害、結果不明のケースを含めます。出力文の完全一致ではなく、最終状態、必要な承認、禁止アクション、証跡の有無を評価します。

テストデータと期待結果は変更対象から分離し、同じケースを変更前後へ実行します。差が出た場合は、それが意図した改善か、許容できる変動か、業務上の後退かを担当者が判定できる形で比較します。

• 頻度の高い正常ケースで、最終結果と処理時間を比較する
• 禁止ケースで、拒否と人への引き継ぎが維持されるか確認する
• 障害ケースで、再試行上限とSAFE_HOLDへの移行を確認する
• 費用、実行回数、修正率に想定外の増加がないか確認する

一度に全対象へ反映しない

回帰テストに合格しても、実際の入力分布や外部サービスの状態を完全には再現できません。まず内部テスト、次に限定された利用者や低影響のワークフローへ反映し、監視期間を置いてから対象を広げます。

各段階には、進行条件と切り戻し条件を設定します。重大な禁止動作、結果不明の増加、費用や待ち時間の急増が見つかった場合は、新しい構成を調整しながら使い続けず、確認済みの旧構成へ戻します。

• 変更前の構成と必要な設定を再現できる形で保存した
• 限定展開の対象、期間、監視指標を決めた
• 展開を止める数値条件と状態条件を決めた
• 切り戻し後に外部システムの整合性を確認する担当者を決めた

変更台帳を、次のテスト設計に使う

変更台帳には、変更日、変更内容、理由、評価結果、承認者、展開範囲、発生した問題を残します。モデル名だけでなく、プロンプトやツール定義など、当時の挙動を再現するために必要な構成をひとまとめにします。

問題が起きたケースは、修正後に回帰テストへ追加します。変更のたびにテスト資産を育てることで、担当者の記憶に頼らず、モデル・ツール・提供元が変わっても守るべき業務条件を維持できます。