プロンプトインジェクションは入力検査だけで止まらない、権限から絞る
AI・自動化
AIエージェント評価は最終回答だけでは足りない、失敗した手順を測る
AIエージェントの品質は、最終回答、そこに至る手順、終了時の状態を分けて測る。回答が正しく見えても、必要なツールを使わず、依頼された処理が完了していなければ合格にはできない。OpenAIの評価ガイドは、動作の調査にはモデルの呼び出し、ツール、引き継ぎ、安全制約を記録したトレースを使い、繰り返し比較する段階でデータセットと評価実行へ進む手順を示している。
本番導入前には代表的な依頼を固定し、回答、操作、安全制約、費用、遅延の合格条件を決める。導入後は実際に見つかった失敗を再現可能なケースへ加え、プロンプトやモデル、ツールを変更するたびに同じ条件で走らせる。総合点だけにまとめず項目別に残せば、回答の改善と引き換えに操作の失敗が増えた変更も見つけられる。
代表タスクから小さな評価セットを作る
最初に選ぶのは、実際の運用で判断が分かれる依頼だ。ここでは小規模チーム向けの作業上の目安として、まず10〜20件を提案する。通常の依頼に加え、情報が足りない依頼、権限外の操作、ツールの失敗、担当エージェントへの引き継ぎが必要な依頼を入れる。この件数から本番全体の成功率を推定するのではなく、重要な失敗を早く見つけるための初期セットとする。
Anthropicのエージェント評価解説は、エージェントが複数ターンでツールを使い環境の状態を変えるため、途中の誤りが連鎖し得ると説明している。同解説が示す返品対応の例では、会話の評価に加えて本人確認や返金ツールの利用、返金状態を確かめる。初期ケースにも、こうした「答えられたか」と「処理されたか」が分かれる依頼を含めたい。
各ケースには入力文だけでなく、開始時の状態、使えるツール、許された操作、期待する終了状態を記す。「適切に対応する」では採点者ごとに判定が変わるため、何が確認できれば合格かを具体化する。人が同じ実行記録を見て判定を割るケースは、エージェントを直す前に課題文や合格条件を見直す必要がある。
回答・手順・終了状態に合格条件を分ける
採点項目は、利用者に返した回答、途中で行った操作、実際に残った結果に分ける。たとえば条件付きの返金依頼なら、回答には処理内容の説明、手順には必要な本人確認と許されたツールの利用、終了状態には返金の記録を求める。「返金しました」という一文は、状態変更が成功した証拠にはならない。
手順の検査では、必要な引き継ぎが起きたか、禁止されたツールを呼んでいないか、失敗した呼び出しを成功と扱っていないかを確認する。ただし、すべてのツール呼び出しを同じ順番に固定すると、妥当な別の解き方まで不合格にする。本人確認のように順序自体が要件となる部分を明示し、それ以外は満たすべき条件と結果を判定する。
費用と遅延は正誤と別の欄に記録する。同じタスクで回答品質が保たれていても、不要なツール呼び出しや長い再試行が増えれば運用上の負担は変わる。一方、安全制約違反や誤った状態変更は、平均点で相殺せず、ケース単位で検出する条件にする。
失敗を追えるトレースと再現できる環境を残す
トレースには、後から判定をやり直せる情報を同じ実行IDで結び付ける。入力、使用したモデルとプロンプトの版、ツールの呼び出しと返り値、引き継ぎ、制約による停止、最終回答、所要時間を残す。状態を変えるタスクでは、操作前後の状態を別途確かめられるようにする。記録の目的は長いログを集めることではなく、失敗した箇所を特定することだ。
再実行では環境もそろえる。検索結果、在庫、権限設定などが変わると、同じ入力でも結果が変わるため、回帰用ケースでは初期状態とツール応答を固定するか、差を記録する。複数の試行が前の試行の変更を引き継がないよう、状態を戻すことも必要になる。実際の利用記録からケースを作る際は、評価に不要な個人情報を除いたうえで、伏せた情報が合否に必要な条件まで消していないか確かめる。
期待した結果がない場合は、最後の返答から遡って原因を分ける。必要なツールを選ばなかったのか、呼び出しが失敗したのか、失敗を示す返り値を読み違えたのかで修正箇所は異なる。回答文だけを採点していると、操作が失敗しても自然な説明を返した実行が合格に紛れ込む。
自動採点を人の判定で監査する
機械的に確認できる条件には、まず決定的な検査を使う。成果物の有無、禁止ツールの呼び出し、状態変更の成否、出力形式などは、明確な条件に落とし込みやすい。費用や遅延も同じケースの実行条件をそろえて比較する。こうした判定を曖昧な総合評価へ混ぜると、何が変わったのか追いにくくなる。
説明の分かりやすさや、複数の妥当な答えがある依頼にはLLM評価者を使える。その際は判断基準と見せる証拠を限定し、証拠が足りなければ判定保留を返せるようにする。「良い回答か」を一度に問うより、依頼に答えたか、根拠を示したか、未完了の操作を完了と述べていないかを分けたほうが、判定理由を監査しやすい。
人は不合格例だけでなく、合格例からも一部を抜き取ってトレースを読む。不合格が課題文や採点規則の誤りなら、エージェントの変更では解決しない。合格例に禁止操作や未完了の処理が見つかれば、採点器が見逃している。人の判定と自動採点が食い違ったケースを残し、評価基準の修正にも使う。
失敗を回帰ケースに変え、変更時のゲートにする
再現できた失敗は、入力だけでなく、原因、期待する振る舞い、合否の検査を一組にして追加する。OpenAI Cookbookの実装例では、架空企業の資料を扱うエージェントの実行トレースに、模擬的な人のフィードバックとモデルの所見を結び付け、再実行できる評価と検証ゲートへ変えている。自動生成された評価項目も、そのまま採用せず、人が期待する動作を測れているか確認する必要がある。
プロンプト、モデル、ツール、引き継ぎ規則を変えたら、変更前後で同じケースを走らせる。安全制約違反と状態変更の失敗は個別に止める条件とし、回答品質、費用、遅延はそれぞれ差を見る。ケース全体の平均だけでは、ある依頼で得た改善が別の依頼の重大な失敗を覆い隠す。
結果が揺れるケースは同じ条件で複数回試し、合否の変動とトレースの内容を合わせて判断する。導入後には利用者からの報告や運用中に見つけた失敗を選んで加え、使われなくなった条件は見直す。評価セットを固定したままにせず、実際に起きた失敗を次の変更時に再検出できる形で残すことが、回帰ゲートの役割になる。
関連記事：
関連記事
ニュースレターを購読
Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。
0