ServiceDock
2026年8月17日 更新
約4分で読めます
エージェントに同じ質問をしても、返ってくる文章は毎回少しずつ違います。すると期待する答えと突き合わせる、という普通のテストが成立しません。
今回は5通りの応答を用意して、2つの判定方法にかけました。完全一致と、条件を満たすかどうかの判定です。結果を先に言うと、完全一致は正しい応答を2つ不合格にしました。
答えの文章ではなく、答えが満たすべき条件を書きます。言い回しの違いを許しつつ、内容の正しさだけを見る形にします。
エージェントのテストが普通のプログラムと違うのは、同じ入力でも出力が一定でない点です。ここを踏まえないとテストが機能しません。
通常のテストは、入力に対する出力を1つ決めて突き合わせます。計算の結果や変換後の値なら、これで問題ありません。
ところがエージェントの答えは文章です。「30日以内なら返品できます」も「購入から30日以内であれば返品を承ります」も、内容としては同じ正解です。文字列としては一致しません。
そこで、答えそのものではなく答えが満たすべき条件を書きます。「30日という期限に触れている」「未開封という条件に触れている」といった形です。
こうすると、言い回しが違っても内容が正しければ合格になります。逆に、大事な条件が抜けていれば言い回しが自然でも不合格にできます。
エージェントのテストで確認したいのは、答えの正しさだけではありません。どのツールを選んだか、おかしな入力に耐えるかも対象になります。
特に最後の点は重要です。OWASPは、利用者の入力がエージェントの挙動や出力を意図しない形に変えてしまう問題を最上位の弱点として挙げています。普通の質問だけでテストしても、この種の問題は見つかりません。
毎回同じ文章を返させようとすると、モデルの良さを削ることになります。求めるのは表現の固定ではなく、内容の正しさです。同じ意味なら言い方が変わってよい、と割り切ると設計が楽になると編集部は考えています。
A Prompt Injection Vulnerability occurs when user prompts alter the LLM's behavior or output in unintended ways.原文OWASP Top 10 for LLM Applications「LLM01:2025 Prompt Injection」 この内容の有効期限2027-02-17
同じ質問への5通りの応答を、2つの判定方法にかけました。完全一致は言い回しの違いを不合格にし、条件判定は内容だけを見ました。
エージェントのテストの方式を比べるため、実際に判定してみました。返品条件を尋ねたときの5通りの応答を用意しています。
5通りのうち3つは内容として正しく、言い回しだけが違います。1つは未開封の条件が抜けており、1つは問い合わせ先を案内するだけで何も答えていません。
function assertions(r) {
const checks = [
{ name: '期限30日に触れている', ok: /30日/.test(r) },
{ name: '未開封の条件に触れている', ok: /未開封/.test(r) },
{ name: '問い合わせに丸投げしていない', ok: !/お問い合わせください/.test(r) },
];
return { pass: checks.every((c) => c.ok), failed: checks.filter((c) => !c.ok) };
}
同じ質問への5通りの応答を判定する
応答1: 完全一致=合格 / 条件判定=合格
応答2: 完全一致=不合格 / 条件判定=合格
応答3: 完全一致=不合格 / 条件判定=合格
応答4: 完全一致=不合格 / 条件判定=不合格
不足: 未開封の条件に触れている
応答5: 完全一致=不合格 / 条件判定=不合格
不足: 期限30日に触れている, 未開封の条件に触れている, 問い合わせに丸投げしていない
完全一致での合格: 1 / 5
条件判定での合格: 3 / 5
差が出ました。完全一致は1件しか合格させていません。応答2と3は内容として正しいのに、言い回しが違うだけで不合格になりました。
この誤検知が問題です。正しい応答が不合格になると、失敗を見ても「またか」と流すようになります。そうなるとテストは意味を失います。
条件判定なら、応答2と3は合格します。落ちるのは本当に問題のある応答4と5だけです。落ちたときに必ず原因がある状態を保てます。
もう1つの利点が、出力の詳しさです。応答4は「未開封の条件に触れている」だけが不足と出ています。どこを直せばよいかが判定結果から分かります。
応答5は3つとも不足しています。この差も意味があります。1つだけ足りない応答と、何も答えていない応答は、対応の優先度が違うためです。
完全一致は正しい応答を落としてしまう。条件判定なら内容だけで判断できる。
While techniques like Retrieval Augmented Generation (RAG) and fine-tuning aim to make LLM outputs more relevant and accurate, research shows that they do not fully mitigate prompt injection vulnerabilities.原文OWASP Top 10 for LLM Applications「LLM01:2025 Prompt Injection」 この内容の有効期限2027-02-17
文字列の有無で判定できる条件は機械に任せられます。判断が要る部分は残るので、そこは人が見る前提で設計します。
エージェントのテストを組むとき、全部を自動化しようとすると行き詰まります。機械で判定できるものから始めるのが現実的です。
一方で、説明が分かりやすいか、言い方が失礼でないかといった点は機械では測れません。ここは人が読むか、別のモデルに採点させることになります。
ただし採点させる場合、採点する側も間違えます。機械的に判定できる条件まで採点に回すと、結果が不安定になります。切り分けが重要です。
普通の質問だけでテストしていると、攻撃に対する挙動が分かりません。OWASPが指摘するとおり、入力の仕方によってモデルは意図しない動きをします。
指示を上書きしようとする入力、無関係な操作を要求する入力を、あらかじめテストに入れておきます。詳しくはエージェントのセキュリティの記事で扱っています。
判定の性質で担当を分ける。機械で見られるものを人に回さない。
Prompt Injection vulnerabilities exist in how models process prompts, and how input may force the model to incorrectly pass prompt data to other parts of the model, potentially causing them to violate guidelines, generate harmful content, enable unauthorized access, or influence critical decisions.原文OWASP Top 10 for LLM Applications「LLM01:2025 Prompt Injection」 この内容の有効期限2027-02-17
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る