プロンプトを直したら別物になった——LLMエージェントに「回帰テスト」を入れる評価セットの作り方
プロンプト（LLMへの指示文）は、語順や表現を少し変えただけでも出力が変わりうることが、多くの研究や実務報告で指摘されている。エージェント（LLMが複数の手順やツールを自律的に使い分けて作業する仕組み）では、途中の判断のずれが後段に連鎖し、最終結果が大きく変わる場合もある。
ソフトウェア開発では、修正後に既存の機能が壊れていないかを確認する回帰テストが定着している。同じ考え方をLLMにも応用する動きが広がっていると見られる。
本記事では、表計算ソフトでも始められる評価セット（テスト用の入力と期待基準をまとめたもの）の作り方を整理する。
なぜプロンプトを直しただけで挙動が変わってしまうのか？
確率的な生成が「分岐」を生む
LLMは確率的に文章を生成する仕組みのため、入力のわずかな違いが出力の分岐に影響しやすい。人間にとっては「言い換え」程度の修正でも、LLMにとっては別の入力として扱われる場合がある。
改善の「副作用」が別の場面で出る
特定の事例の不具合を直すために指示を追加すると、別の事例での挙動が悪化することがある。たとえば「回答は簡潔に」と加えた結果、詳しい説明が必要な依頼でも説明が省かれるようになるケースである。こうした副作用は、修正した本人が意図していない場所に現れやすい。
原因がプロンプトとは限らない
モデルのバージョン更新でも同様の変化が起こりうる。挙動が変わったときに、プロンプトの修正が原因なのか、モデル側の変化が原因なのかを切り分けるには、比較できる基準が必要になる。
目視確認では見落としが出る
修正後に数件を試して「問題なさそう」と判断する方法は、確認範囲が偏りやすい。直したい事例ばかりを見てしまい、他の事例の変化を見落とす原因になると言える。
LLMエージェントの回帰テストは、通常のソフトウェアのテストと何が違うのか？
完全一致では判定できない
従来のソフトウェアのテストでは、「入力Aなら出力はB」という完全一致で合否を判定できる。一方、LLMの出力は毎回表現が揺れるため、完全一致での判定は適さない場面が多い。「同じ意味・同じ条件を満たしているか」を見る設計が必要になる。
途中経過も評価対象になる
エージェントの場合、最終的な回答だけでなく、次のような途中経過も評価対象になりうる。
- どのツールを呼び出したか
- 処理をどの順序で進めたか
- 不要なツール呼び出しをしていないか
最終回答が正しく見えても、途中で誤った手順を踏んでいれば、別の入力で問題が表面化する可能性がある。
目的は「完璧な正解率」より「差分の検知」
LLMの評価では、正解率100%を目指すことよりも、修正の前後で何が変わったかを検知することに価値があると整理できる。「前より悪くなったケースが出ていないか」を確認できれば、回帰テストとしては機能する。
評価セットには、どのようなケースを入れればよいのか？
3種類のケースをバランスよく入れる
| 種類 | 内容 | 例（社内問い合わせ対応エージェントの場合） |
|---|---|---|
| 典型的な依頼 | 日常的に最も多い依頼 | 「経費精算の締め日を教えて」 |
| 境界的な依頼 | 対応可否や判断が分かれやすい依頼 | 「規程にない出張費の扱いを知りたい」 |
| 失敗しやすい依頼 | 過去に誤りが出た、または誤りやすい依頼 | あいまいな指示、情報不足の質問、範囲外の相談 |
運用で起きた失敗は優先的に追加する
実際の運用で起きた失敗事例は、再発防止のテストとして優先的に追加する価値が高いと見られる。一度起きた失敗は、プロンプト修正の過程で再発する可能性があるためである。
件数は20〜50件から始める
最初から数百件を用意しようとすると、作成と採点の負担で止まりやすい。20〜50件程度の小規模なセットから始める方法が現実的と言える。運用しながら、失敗が見つかるたびに足していけばよい。
各ケースに記録しておく項目
- 入力：エージェントに渡す依頼文
- 期待する振る舞い：どう対応してほしいか（正解の文章そのものではなく、満たすべき条件）
- 確認観点：何を見て合否を決めるか
- 重要度：高・中・低など。悪化したときの影響の大きさ
正解が一つに決まらない出力は、どう採点すればよいのか？
出力が揺れる以上、採点方法を工夫する必要がある。代表的な方法は次の3つで、組み合わせて使うのが一般的と見られる。
1. ルールベース採点：機械的に判定できる項目を先に切り出す
次のような項目は、人の判断を介さずに判定できる。
- 必須キーワードが含まれているか
- 出力形式（JSONなど、プログラムが読み取りやすいデータ形式）を守っているか
- 禁止表現が使われていないか
判定のぶれがなく、スプレッドシートの関数でも処理しやすい。まずここから整備すると効率がよい。
2. ルーブリック：段階評価で基準をそろえる
ルーブリック（採点基準表）は、「根拠を示しているか」「指示された範囲を逸脱していないか」といった観点を、たとえば0〜2点の段階で評価するものである。各点数が何を意味するかを文章で定義しておくと、担当者による判定のずれを抑えやすい。
3. LLM-as-a-judge：別のLLMに採点を任せる
LLM-as-a-judge（別のLLMに採点役を任せる手法）は、採点の効率化に有効とされる。一方で、採点に偏りや揺れがあることも知られている。人手による抜き取り確認と併用することが望ましい。
合否だけでなく「点数」と「理由」も残す
合否のみの記録では、悪化の原因をたどりにくい。点数と判定理由を短く残しておくと、後から変化の理由を追いやすくなる。
スプレッドシートだけで、評価セットの管理はどこまでできるのか？
基本は「1行1ケース」の表
次のような列構成が基本になる。
| ID | カテゴリ | 入力 | 期待基準 | 重要度 | v1結果 | v2結果 | 判定 |
|---|---|---|---|---|---|---|---|
| 001 | 典型 | 経費精算の締め日は？ | 締め日を明記し、規程名を示す | 高 | 合格 | 合格 | 変化なし |
| 014 | 境界 | 規程にない出張費の扱いは？ | 断定せず、担当部署への確認を案内 | 高 | 合格 | 不合格 | 悪化 |
バージョン名を列に持たせて横並びで比較する
「v1」「v2」のようにプロンプトのバージョン名を列に持たせると、修正ごとの結果を横並びで比較できる。バージョンごとに、どの文言を変えたかを別シートにメモしておくと、後から経緯を追いやすくなる。
関数やピボットテーブルで集計する
悪化の自動判定（判定列の例）
=IF(AND(F2="合格",G2="不合格"),"悪化",IF(AND(F2="不合格",G2="合格"),"改善","変化なし"))
カテゴリ別の合格率（例：典型ケース、v2の結果）
=COUNTIFS(B:B,"典型",G:G,"合格")/COUNTIF(B:B,"典型")
ピボットテーブルを使えば、カテゴリ別・重要度別の合格率や、「悪化」と判定されたケースの抽出も可能である。
自動化が必要になる段階
件数が増え、評価の実行そのものを自動化したくなった段階が、専用の評価ツールやスクリプトへの移行を検討するタイミングと位置づけられる。それまでは、スプレッドシートで十分に運用できる場合が多い。
評価は、いつ、どのような手順で回せばよいのか？
実行タイミングの目安
次の変更の前後が、実行タイミングの目安になる。
- プロンプトの修正
- ツール定義（エージェントが使える機能の設定）の変更
- モデルの更新
基本の手順
- 修正前に評価を実行し、結果をベースラインとして保存する ベースラインとは、比較の基準となる結果のことである。
- 修正を加える
- 同じ評価セットで再実行する
- ベースラインとの差分を比較する
- 悪化したケースについて判断する
揺れへの対処：重要なケースは複数回実行する
同じ入力でも出力は揺れる。そのため、重要度の高いケースは複数回（たとえば3〜5回）実行して、合格する頻度の傾向を見る方法がある。1回の結果だけで一喜一憂しないための工夫である。
判断の記録を残す
悪化したケースについては、修正を取り下げるか、許容するかを判断し、その理由を記録しておく。「このケースの悪化は、他の改善と引き換えに許容した」という履歴が残っていれば、後から同じ議論を繰り返さずに済む。
評価セットの運用で陥りやすい落とし穴は何か？
評価セットへの過剰適合
評価セットの点数を上げることだけを目的にプロンプトを調整しすぎると、過剰適合（テスト用の入力にだけ合わせすぎて、未知の入力への対応力が下がること）が起こりうる。評価セットとは別に、確認用のケースを少数取っておく方法も考えられる。
ケースの固定化
ケースを作ったまま放置すると、実際の利用状況とずれていく。利用者の依頼傾向は変わるため、定期的な見直しが必要と言える。
採点基準のあいまいさ
採点基準があいまいなままだと、担当者ごとに判定が割れ、前後比較の信頼性が下がる。「合格とする例」と「不合格とする例」を数件ずつ添えておくと、判断がそろいやすい。
実データの取り扱い
個人情報や機密情報を含む実データを評価セットに使う場合は、氏名や会社名を置き換えるなどの匿名化が必要になる。スプレッドシートの共有範囲にも注意が求められる。
まとめ：今日から何を始めればよいのか？
- プロンプト修正の影響は目視では捉えきれないため、評価セットによる回帰テストが有効と見られる。
- 最初は、過去の失敗事例を中心とした20〜50件のスプレッドシートで十分に着手できる。
- ルールベースの採点と人手の確認を組み合わせ、運用しながらケースと基準を更新していくことが現実的な進め方と言える。
まずは、これまでに起きた「困った出力」を5件ほど書き出し、1行1ケースの表にすることが最初の一歩になる。そこに期待基準と、修正前の結果を記録しておけば、次にプロンプトを直すときから、変化を見える形で確認できる。