なぜエージェントの評価は難しいのか
チャットAIの評価は、突き詰めれば「入力に対する出力」の採点でした。エージェントの評価が難しくなるのは、そこに3つの困難が加わるからです。
- 経路が毎回違う。同じタスクを依頼しても、どのツールをどの順番で何回呼ぶか、途中でどう判断するかが実行のたびに変わります。最終結果だけを見ても「たまたま成功した」のか「確実に成功する」のかを区別できません。
- 単発の成功と繰り返しの成功は別物。1回試して成功しても、同じタスクを連続で回すと成功率は大きく下がり得ます。デモの成功率をそのまま本番の信頼性と見なすのは危険です。
- 判定そのものが揺れる。途中経過の良し悪しをAIに採点させる方法(LLM-as-judge)は便利ですが、判定器自体が偏ることがあります。人手でつけた正解ラベルと突き合わせて較正しない限り、判定を鵜呑みにはできません。
「一度動いた」は信頼性の証明にはなりません。経路・繰り返し・判定という3つの困難を前提に、評価そのものを設計し直す ― これが運用の出発点です。
評価は3つの層で測る ― 結果・軌跡・本番
「完遂したか」だけを見ていると、上のような「たまたま成功」を弾けません。何を達成したか(結果)・どう達成したか(軌跡)・本番でどう振る舞うかの3層に分けて測るのが実務の基本です。
| 層 | 何を測るか | 主な指標 |
|---|---|---|
| ➀ 最終結果 | タスクが完遂されたか | タスク完遂率。エージェントの「完了しました」という自己申告を信じず、作られたはずのレコード・ファイル・状態を機械的に検証する |
| ➁ 軌跡 | どう完遂したか | ツール呼び出しの正しさ、ステップ数、無駄な再試行やループの有無、禁止操作がゼロか、エラーからの回復 |
| ➂ 本番 | 実トラフィックでの振る舞い | 完遂率の推移、人による差し戻し率、エスカレーション率、コスト/タスク、利用者評価 |
鍵は➀の判定を終了状態の機械検証で行うことです。「正しい文面を返したか」ではなく「下書きが1件できているか/何も書き込まれていないか」を確認できれば、判定はそのまま自動化できます。➀に➁の軌跡と➂の本番指標を重ねて、はじめて信頼性を語れるようになります。
ゴールデンタスク ― 「何回中何回動いたか」で語る
評価は一度きりの試験ではなく、育てて回し続ける運用です。その中核になるのがゴールデンタスクセット ― 代表的なタスクと「期待する終了状態」をセットにした正解集合です。作り方には決まった順序があります。
- 4区分を最初から揃える。正常系だけでなく、エッジケース、拒否すべきタスク、敵対的入力(注入など)を含めます。件数は10件からでも始められますが、件数の多さより4区分が揃っていることを優先します。目安は正常5・エッジ3・拒否1・敵対的1程度の比率です。
- 期待値は終了状態で書く。「経費精算の下書きが1件作成され、勘定科目が旅費交通費である」「いかなる書き込みも発生せず、範囲外である旨の応答が返る」のように、出力文面ではなく何が起きた/起きなかったかで書きます。拒否・敵対的の期待値は「何が起きないか」で表現します。
- 繰り返し実行で測る。各タスクを1回でなく複数回(例:4〜8回)走らせ、「全回成功した割合」を信頼性の指標にします。「10回中10回」なのか「10回中7回」なのかで、任せてよい範囲はまったく変わります。
- 本番の失敗を還流して育てる。本番で起きた失敗・差し戻し・上限の発火事例を週次でセットに追加し、四半期に一度は陳腐化したタスクを棚卸しします。
ゴールデンタスクは一度作って終わりの資料ではなく、育て続ける資産です。「拒否すべき」「敵対的」をゼロにしたまま自律性のレベルを上げてはいけません。モデルやプロンプト、ツールを変更するたびに、模擬環境(サンドボックス)でこのセットを回して回帰を確認します。
すべての実行を記録する ― トレースと監査ログ
評価が「毎回動くか」を測るものだとすれば、トレースは「今日、実際に何をしたか」を残すものです。1タスク=1トレースを原則に、計画から各ツール呼び出し(ツール名・引数・結果・所要時間・コスト)、途中判断、最終結果までを時系列で1本に記録します。運用担当が押さえるべき論点は4つです。
- 後から再構成できること。「どの指示に基づき・何を根拠に・どのツールを呼び・何を実行したか」を再現できる状態にします。これは障害調査だけでなく、社内監査や顧客への説明責任の基盤になります。
- 人の関与も記録する。誰が・何を・いつ承認/差し戻したか(HITL)もトレースに含め、責任の所在を辿れるようにします。
- ログ自体を守る。ツールの引数や結果には機微情報が混じります。マスキング・閲覧権限・保持期間を設計します。
- 保存はメリハリをつける。失敗・差し戻し・上限発火のタスクは全件保存し、成功タスクはサンプリング。保持期間は性能ログとしてではなく監査要件から逆算します。
数字で見張る ― ダッシュボードとコストの上限
トレースが貯まっていれば、運用ダッシュボードは「集計して並べるだけ」になります。逆に出せない指標があれば、それはトレース設計の穴です。項目は5区分で1画面に収めるのが目安です。
| 区分 | 指標の例 | 見方・頻度 |
|---|---|---|
| 信頼性 | タスク完遂率／評価セットの全回成功率 | 低下トレンドはモデルや入力データ変化のサイン。週次 |
| 品質 | 差し戻し率／人へのエスカレーション率 | 急増は品質劣化、ゼロ張り付きは承認の形骸化疑い。週次 |
| コスト | コスト/タスクの中央値・外れ値件数 | 外れ値はアラートで即時通知。日次 |
| 安全 | 禁止操作の検知件数／敵対的テストの通過率 | 検知件数は常時ゼロが正常。1件でも即調査 |
| 挙動 | ステップ数の分布／上限の発火件数 | 分布が右に伸び始めたらループ増加の予兆。週次 |
勘所は「眺める監視は続かない」ことです。人は毎日画面を見続けられません。閾値を決めてアラートに任せ、人は外れ値と月次レビューに集中するのが現実的です。
コストで見るべき単位は「1呼び出し」ではなく「1タスク=多段呼び出し」です。ループや再試行で桁が容易に変わるため、コスト/タスクを標準指標にして外れ値を自動検知します。そして暴走と静かな積み上がりの両方を捕まえるために、上限を多段で設けます。上限は勘で置かず、平均単価から導くのが定石です。
| 階層 | 設定の考え方 | 発火時の対応 |
|---|---|---|
| タスク上限 | 平均単価の数倍(例:5倍)。正常なばらつきは通し、暴走だけ止める | 経過を添えて人へ |
| 部門の日次上限 | 月額から1日あたりを逆算。少額タスクの静かな積み上がりを検知 | 運用担当へ通知 |
| 全体の月次上限 | 月予算の少し上を最後の砦に | 全体停止＋原因調査 |
重要なのは、上限を「設定した」で終わらせないことです。実際に発火するかを定期テストで確かめ、「効いている」ことを確認します。平均単価はモデル更新やプロンプト変更で動くため、上限も再計測とセットで見直します。
インシデントの初動5ステップ ― 速さが被害を決める
エージェントのインシデントは「誤った実行の連鎖」です。被害の大きさは、当日の頑張りよりも初動の速さと平時の設計で決まります。手順は次の5ステップに固定しておきます。
- 検知。多くの場合、最初に異常を教えるのは内容ではなく「量」です。コスト/タスクの外れ値アラートが、質の異常より先に鳴ります。コスト監視は財布の管理を超えた検知網になります。
- 止める。kill switchで該当エージェントを即時停止します。原因が分からなくても構いません。判断に迷う間は止める側に倒すのが原則です。
- 隔離・特定する。トレースから、きっかけ(注入疑いの確認)・実行された操作の全リスト・影響範囲を洗い出します。あわせて原因となったデータやツールを隔離します。
- 原因特定と復旧(戻す)。実行済みの操作をロールバックします。戻せるかどうかは設計時にほぼ決まっており、下書き止まりや取り消し可能な実装であれば、復旧は削除や取り消しだけで済みます。戻せない操作は連絡・訂正フローへ回します。
- 再発防止(封じる)。該当ケースを敵対的テストに追加して回帰で防ぎ、上限・権限・自律性レベルを見直します。
架空のモデルケースで考えてみます。ある請求書処理エージェント(下書き止まりの権限設定)が、受領PDFに埋め込まれた注入指示に反応したとします。最初の検知はコスト/タスクの外れ値アラート、原因不明のまま数分でkill switch、トレースで支払先マスタの変更下書きが複数件と特定、確定データへの書き込み権限がそもそも無かったため復旧は下書きの削除だけ ― という流れです。被害を限定したのは事後の対応力ではなく、下書き止まりの設計・量の異常を捉える検知網・「誰がどの条件で止めてよいか」を決めた停止訓練という、すべてインシデント前に仕込まれた備えでした。四半期に一度、kill switchと初動手順を実際に流す停止訓練を運用に組み込んでおくことをおすすめします。
まとめ ― 定着させ、FAQで支える
評価・監視・インシデント対応の型は、作っただけでは形骸化します。運用開始前と定期レビューで確認するチェックリストを用意し、1つでも空欄があればそこを次の整備対象にする ― この地道な運用が「毎回動く」を支えます。現場で必ず出る問いには、あらかじめFAQで答えを用意しておくと定着が早まります。
- 評価セットを作る時間がない: 10件(正常6・エッジ2・拒否1・敵対的1)からで構いません。本番の失敗を還流する仕組みを先に作るほうが早く育ちます。
- サンドボックスが用意できない: 読み取り専用＋下書き止まりの構成なら本番でも一部評価できます。書き込み操作の評価はテスト用テナントが揃うまで、自律性の昇格を凍結します。
- トレースが大量で保存コストが重い: 失敗系は全件、成功系はサンプリング。保持期間は監査要件から逆算します。
- どの数字が揃えば自律性を上げてよいか: 評価セットの全回成功率・本番の差し戻し率・敵対的テストの全通過、の3点セットを基準にします。
設計し、防御を固めて本番に載せたエージェントを、測り・記録し・止められる状態で回し続ける ― それがここまでのすべてです。次回は、代表的なユースケースごとに、どこから着手し何を成熟の目安にするかをまとめたプレイブックを解説します。