AIエージェントが「完了」と言っても、データベースは納得しない

はじめに

AIエージェントが正しいツールを呼び出し、自然な文章を返したとしても、業務処理が完了したとは限りません。MicrosoftとHugging Faceが紹介したThinkingBoxは、評価の中心をエージェントの発言から、実際にシステムへ残した結果へ移します。エージェントを分離されたMCPツールセッションで動かし、最後にバックエンドの状態と副作用を直接確認します。

成功に見える失敗

素材では、配送センターで15日間遅延している高額なキッチン家電の問い合わせが例に挙げられています。エージェントは注文、配送状況、顧客情報、返金ポリシーを確認し、チケットを作成して経緯を記録しました。遅延補償の対象外という判断自体も正しかったとされます。

しかし、配送業者の例外処理はまだ解決していません。そのためチケットの正しい終了状態は保留でしたが、エージェントは「解決済み」に変更しました。最終回答も顧客の本来の質問に十分答えていません。ツールの履歴だけを見れば良好に見えても、データベースの状態を検査すれば失敗です。

主なポイント

• 結果を直接検査する。 必須フィールドの値、必要な副作用、意図しない追加変更の有無を実行可能なチェックで確認します。
• 1回の成功は信頼性ではない。 507件の業務タスクを、初期状態をそろえてそれぞれ20回実行し、pass@1、pass@20、20回すべて成功したタスク数を分けて報告します。
• 正常終了でも失敗は隠れる。 121,680回の有効試行では79,853回が実行可能チェックに失敗しました。そのうち67.24%は正常終了し、状態変更ツールを使い、最終ツールエラーも報告していませんでした。
• 対応範囲と安定性は別である。 Kimi-K3は507件中476件で少なくとも一度成功しましたが、20回すべて成功したのは68件でした。一方、Claude Opus 5は一度以上成功した件数が少ないものの、241件で全試行に成功しました。

意味と影響

この結果は、企業向けエージェントの評価方法に課題があることを示します。高いpass@1は処理能力を示しても、次の実行で正しい値を書き込む保証にはなりません。顧客対応、保険、銀行、旅行などのシステムでは、誤ったステータスや更新漏れ、不要な副作用が、文章の品質以上に大きな損害を生む可能性があります。

本番導入前には、バックエンドの終端条件を自動検証し、少なくとも到達範囲、単発成功率、繰り返し時の一貫性を分けて見るべきです。ThinkingBoxの意義は、新しい順位表を作ることだけではありません。エージェントの軌跡は主張にすぎず、最終的なシステム状態こそが証拠だと明確にした点にあります。

出典：Hugging Face Blog