AIエージェントを信頼する前に：失敗を見抜く5段階評価

AIエージェントが「完了しました」と答えても、仕事が本当に完了したとは限りません。ファイルの保存先が違う、許可されていないツールを呼ぶ、偶然一度だけ成功する、といったことがあるからです。最終回答の自然さだけを見る評価は、外部システムを操作するエージェントには不十分です。

Anthropicは評価を入力と採点ロジックの組み合わせと説明し、モデルだけでなくプロンプト、ツール、実行環境を含むハーネス全体を試す必要があるとしています。Google Cloudは目標達成、最終応答、ツール利用、幻覚、安全性を別々に評価します。NISTも、隠れたツール呼び出しや中間状態を確認できる監査証跡の重要性を指摘しています。

ここでは、これらを小規模な自動化にも本番ワークフローにも使える5段階にまとめます。

第1段階：成功を観察可能な契約に変える

「問い合わせを上手に処理する」では評価できません。システム上で確認できる状態に変換します。

• 注文番号と返金条件が正しいか
• チケットの状態が実際に更新されたか
• 同じメールを重複送信していないか
• 許可されたツールとデータだけを使ったか
• 時間とコストの上限内で終わったか

各ケースは 初期状態 → ユーザーの目標 → 許可された行動 → 成功状態 → 禁止条件 で記述します。一つの正解文ではなく、異なる表現でも正しい状態に到達できるようにします。

正常系だけでなく、必須項目の欠落、矛盾した依頼、ツール障害、権限不足、長い文脈、悪意ある指示を含めます。少数の代表ケースから始め、本番障害が起きるたびに再現ケースを追加します。

第2段階：発言ではなく実際の状態を決定的に検査する

最後のメッセージは結果についての主張にすぎません。可能な項目はコードで確認します。

• データベースの行とフィールドが期待どおりか
• ファイルの場所、形式、スキーマが正しいか
• APIが本当に一度だけ呼ばれたか
• 金額、日時、識別子が元データと一致するか
• 失敗時に安全な停止やロールバックが行われたか

文章の明瞭さはLLMジャッジで評価できますが、存在、合計、権限、呼び出し回数は決定的な検査を優先します。これは高速で再現でき、モデル変更の影響も受けにくい方法です。

「会議を予約しました」という文を採点する代わりに、カレンダーの参加者、タイムゾーン、重複、会議リンクを確認します。その後で初めて説明の明瞭さを評価します。

第3段階：ツール利用の経路と禁止行動を見る

同じ結果でも経路の安全性は違います。承認されたCRMを読む場合と、権限外の文書を検索する場合を同じ点数にはできません。

ツールと順序、入出力の要約、変更したリソース、再試行、停止理由、人間の承認地点を記録します。

正しい順序を一つに固定すると、合理的な別経路を誤答にしてしまいます。必須チェックポイント、許容可能な経路、絶対に呼んではいけないツールを分けます。成功率と同時に、禁止行動ゼロ、不要な書き込みの削減、承認回避なしを測ります。

NISTは、エージェントが採点の抜け穴を使い、本来の目標ではなく点数だけを上げる grader gaming にも注意を促しています。正解パターンやテスト成果物を露出させず、実行履歴を人が抜き取り監査し、評価環境にも不要な権限を与えないようにします。

第4段階：品質・根拠・安全・コストを分離する

一つの総合点は失敗原因を隠します。

LLMジャッジは自由記述の大量確認に便利ですが、絶対的な判定者ではありません。モデルやプロンプトで点数が変わり、長い回答を高品質と誤認することもあります。具体的な基準と良い・悪い例を与え、人の判断と定期的に較正します。

個人情報の漏えいや無許可の決済などは平均点に混ぜず、他の高得点では相殺できない失敗ゲートにします。

第5段階：回帰評価をデプロイと本番フィードバックにつなぐ

評価はリリース前の一回限りの行事ではありません。モデル、システムプロンプト、ツールスキーマ、検索インデックスのどれかが変わるだけで行動も変わります。

推奨する流れは次のとおりです。

1. コード変更ごとに重要な小規模セットを実行する。
2. リリース候補には正常・境界・敵対セットをすべて実行する。
3. 成功率だけでなく安全失敗、コスト、遅延を比較する。
4. 低信頼・高影響のケースを人の確認へ送る。
5. 本番の失敗を匿名化し、新しい回帰ケースにする。
6. 評価セット自体の漏えい、重複、現実性も点検する。

重要ケースは複数回実行して変動を見ます。新モデルが平均を改善しても、長い文脈、特定の利用者群、ツール障害からの復旧で退行することがあるため、区分別結果を残します。

最小構成の評価仕様

エージェント機能ごとに、まず次を用意します。

• 正常5件、境界3件、敵対2件
• 各ケースの初期状態と期待する最終状態
• 決定的検査と安全ゲート
• 許可・禁止ツール、承認条件
• 3〜5項目の品質基準と人が確認する比率
• 遅延、呼び出し回数、コスト上限
• 失敗再現を追加する担当者と手順

リリース基準は結果を見る前に決めます。例えば、目標達成95%以上、安全ゲート失敗ゼロ、p95遅延20秒以下、重要ケースの退行なし、という形です。数値はリスクに合わせますが、結果を見て有利に動かしてはいけません。

信頼は流暢さではなく証拠から生まれる

良い評価は、エージェントが賢く見えるかを問いません。期待する状態を作ったか、許可された方法を使ったか、危険時に止まったか、次の更新後も再現するかを確認します。

最終回答、実際の状態、行動経路、安全と効率、回帰を分けてください。小さな決定的検査から始め、本番の失敗を評価セットへ戻します。エージェントへの信頼は印象的なデモではなく、蓄積された実行証拠から生まれます。

参考資料

• Anthropic — Demystifying evals for AI agents
• Google Cloud — Evaluate agents
• NIST — Security Considerations for AI Agents
• NIST — Cheating on AI Agent Evaluations
• NIST — Building Evaluation Probes into Agentic AI

指標としきい値は業務リスク、データの機密性、法的要件に合わせて調整してください。影響が大きい、または元に戻せない処理には独立したセキュリティ審査と人の承認を残します。