FDEのAI運用｜モデル・プロンプト変更時の回帰テストと比較表

AIモデルやプロンプトを変更するときは、変更前にできていた業務が変更後もできるかを、同じ入力と合格条件で比べます。この確認が回帰テストです。「新しいモデルだからよくなるはず」「一度試したら自然な文章が出た」だけでは、現場で必要な動作が保たれているか判断できません。

本記事では、中小企業の問い合わせ返信の下書きを例に、FDEと業務担当者が行う変更前後の確認手順を紹介します。図解と比較画面は86研究所が作成した説明用の例です。掲載する文章・版名・判定は架空データで、実在モデルの評価や顧客事例ではありません。

執筆：86研究所 ／ 内容確認日：2026年10月6日

FDEの仕事は、AIを導入した後の変更にも続く

AIの運用では、モデルだけでなく、指示文、参照資料、検索設定、外部ツールの設定も変わります。返信を短くするための修正が、重要な条件の省略につながる場合もあります。ひとつの失敗を直した結果、別の質問で悪化していないかを確かめる必要があります。

FDEは業務と実装をつなぎ、何を比較し、誰が合否を判断し、どの条件なら本番へ反映するかを整理します。基本的な役割はFDEの仕事内容もご覧ください。

Anthropicの公式解説では、評価用の入力と成功条件を定義すること、実行ごとのばらつきを考慮すること、従来できていた処理を守る回帰評価を区別することが説明されています。本記事では、この考え方を問い合わせ業務の変更確認へ応用しています。参照：Demystifying evals for AI agents。

最初に「何を変えたか」を記録する

モデルとプロンプトと参照資料を同時に変えると、結果が悪化した原因を特定しにくくなります。可能な範囲で変更を分け、旧版と新版の違いを記録します。複数を同時変更する必要がある場合は、その一式をひとつの版として保存してください。

• モデルの識別子と、記録できる範囲のバージョン情報
• プロンプトの版と変更箇所
• 参照資料・検索設定・外部ツールの版
• 実行日時、入力、設定、会話履歴の有無
• 今回変えたい動作と、変えてはいけない動作

「納期の回答を分かりやすくする」が目的なら、「未確認の納期を断定しない」は維持する条件です。変更の目的と守る条件を分けて書くと、文章の好みだけで採用を決めにくくなります。

問い合わせ業務で用意する6種類のテスト

成功しやすい通常例だけでなく、過去に困った例や情報不足の例も含めます。実際の問い合わせを使うときは、試験に不要な個人情報を除き、利用できる範囲を確認します。

件数だけを増やすより、業務上異なる失敗を含めることを優先します。最初の集合は小さくても構いませんが、それだけで全業務の安全性を保証したと考えないでください。運用で見つかった失敗を追加し、頻度の高い入力や業務への影響が大きいケースを継続的に見直します。

合格条件は、文章の一致と業務の成立を分ける

返信の表現が違っていても、条件を満たしていれば合格にできる場合があります。逆に、丁寧な文章でも根拠のない納期が含まれていれば不合格です。用途に応じて確認方法を組み合わせます。

• 形式：必要な項目がある、決めた形式で読み取れる、宛先が一致する。
• 内容：根拠と一致する、条件を省略しない、情報不足を断定で埋めない。
• 処理結果：下書きが保存された、担当者へ引き継がれた、未承認の送信が発生していない。
• 運用負荷：応答時間、利用量、失敗、担当者による修正の手間が許容範囲にある。

数値や形式の確認はプログラムで、人が読む説明の適切さは業務担当者が確認するなど役割を分けます。AIに採点させる場合も、その判定を人が点検し、基準に合っているかを確認します。AIの採点結果だけで採用を確定しない設計にすると、見落としを検討できます。

実画面：平均点より「悪化したケース」を見る

下の画面は、架空の旧版Aと新版Bを比較する台帳デモを、ブラウザーで実際に表示して撮影したものです。通常質問は両方合格でも、納期未確定のケースでは新版が断定してしまう、という説明用データを入れています。

このデモでは「悪化したケースだけを表示」の切り替えを確認しました。画面の判定はあらかじめ用意した架空データで、AIを実行して得た結果ではありません。重要なのは、どの条件が崩れたかと、次に何を直すかを一緒に見られることです。

業務上重大な誤りを、他の通常質問の改善で相殺しないようにします。例えば無断送信や根拠のない確約は、平均点とは別の切り替え停止条件として業務責任者と合意します。合格率を出す場合も、母数、対象ケース、試行回数、判定方法を併記します。

比較するときにそろえる条件

同じ質問でも、会話履歴や参照資料が違えば比較が難しくなります。旧版と新版へ同じ入力と初期状態を渡し、外部情報が変わる場合はその内容も記録します。検証用に保存したデータを使う場合は、本番の最新情報を使った確認とは分けて扱います。

一回だけの結果で判断せず、重要なケースは複数回試して、どの程度結果が変わるかを見ます。試行回数に万能な数はありません。業務への影響と出力のばらつきから決め、全試行の失敗も記録します。また、調整に使ったケースだけに合わせ込みすぎないよう、別の確認用ケースも用意します。

記録欄は「ケースID／入力／根拠／合格条件／旧版の結果／新版の結果／失敗の分類／確認者／次の対応」が基本です。秘密情報は必要以上に記録せず、評価データの閲覧範囲と保存期間を決めます。

合格後も、小さく切り替えて監視する

試験を通過しても、本番には未経験の入力があります。最初は対象者や対象業務を限定し、失敗・修正件数・遅延・利用量を確認します。異常時に誰が止めるか、どの版へ戻すか、戻した後に処理済みの案件をどう扱うかまで決めておきます。

以前のモデルが利用終了している場合は、同じ版へ戻せないこともあります。切り替え前に提供状況を確認し、代替版、機能の一時停止、手動対応などの選択肢を準備します。戻し方は設定を保存しただけで終わらず、検証環境で確認します。

人へ戻す条件はAI自動化の承認・例外処理、設定や手順の保管はFDEの引き継ぎチェックも参照してください。

FDEへ相談するときに持ち寄るもの

今使っている指示文、うまくいった入力、失敗した入力、業務上許容できない結果を、共有可能な形にして用意します。「どのモデルが最強か」だけでなく、「自社のどの仕事をどの条件で成立させたいか」を相談の中心にすると、確認方法を具体化できます。

86研究所のFDE伴走支援では、業務整理からAI活用設計、実装、運用改善までを案内しています。モデルやプロンプト変更時の確認範囲、評価用データの扱い、継続的な監視・保守の対応可否は、対象業務に応じて個別に整理します。無料AI業務診断で相談する。

よくある質問

プロンプトを一行変えるだけでも確認は必要ですか？

変更した指示が関係するケースと、重要な既存ケースを確認します。変更量より、業務への影響で範囲を決めます。

公開ベンチマークが高ければ自社のテストは不要ですか？

不要にはなりません。自社の資料、入力、権限、外部連携を含む条件は公開ベンチマークとは異なるため、自社の成功条件で確認します。

回帰テストがあれば誤りを完全に防げますか？

完全には防げません。試験で確認した範囲を明らかにし、本番の監視、担当者への引き継ぎ、停止や復旧の手順と組み合わせます。