AIエージェントの失敗は、長い工程の状態として残る

AgentBenchは、OS、データベース、ウェブ、買い物、知識グラフ、家庭環境、ゲーム、推理を含む八つの環境で二十九のAPI型・オープンモデルを評価しました。上位の商用モデルとオープンモデルの差に加え、長期推論、意思決定、指示追従が主要な失敗要因だと報告しています。[1]

文章生成なら誤答を棄却して終われますが、エージェントは誤った検索条件、予約、送信、更新を次の状態として残します。途中の各回答が自然でも、最終的なデータベース状態が目的と違えば失敗です。評価単位を会話の一往復から、開始状態、操作列、最終状態、取り消し可能性へ広げる必要があります。

工程ごとに、実行前後で必ず成り立つ状態条件を定義します。たとえば対象レコード、権限、金額、送信先が予定差分と一致しないなら、次の操作へ進ませません。言語上の説明が正しくても状態条件を破れば失敗とし、観測不足、計画誤り、ツール引数、ツール側障害を別々に記録すれば、モデル能力以外の代替説明も検証できます。[1]

WebArenaは、電子商取引、掲示板、共同ソフトウェア開発、コンテンツ管理など、機能するウェブ環境で長い工程の課題を評価しました。原論文の最良のGPT-4ベースエージェントの終端成功率は14.41%で、人の78.24%を大きく下回りました。[2]

この差は現在のモデル能力をそのまま表すランキングではありません。重要なのは、成功を文章のもっともらしさではなく、サイトの状態や返答が意図した条件を満たしたかで判定した点です。[2] 自社での受入試験でも、クリック数やツール呼び出し成功に加え、注文、権限、金額、記録が望む終端状態になったかを機械検証することを提案します。

導入前は、本番と同じ画面やAPIを使いながら変更を確定しない影運用で、予定操作と人の実操作を比較します。ツール呼び出しが成功しても終端状態が違う案件、正しい終端へ偶然到達したが不要操作を含む案件を分けます。代表工程で人の手順と同じ検証規則を通過できない間は、環境が似ていても自律実行へ移しません。[2]

τ-benchは、小売と航空の二領域で、模擬利用者との対話、業務ポリシー、API操作を同時に評価しました。当時のGPT-4oを含む関数呼び出しエージェントでも成功は50%未満で、小売では八回すべて成功するpass^8が25%未満でした。[3]

本番で同じ依頼が表現や会話順の違いだけで別結果になるなら、平均成功率が高くても運用は安定しません。代表案件を一度ずつ流すだけでなく、言い換え、情報の提示順、途中の確認質問を変えて反復します。成功率に加え、全試行成功、重大失敗ゼロ、不要操作、規則違反を別の指標にします。

再現性の合格条件は平均成功だけでなく、同じ目的の言い換えや情報順の変更で重大失敗が再発しないことです。失敗が特定表現だけに集中するなら入力理解、会話が長いほど増えるなら状態保持、同じ段階で増えるならツール境界を疑います。反復で結果が揺れる案件は、安定するまで承認付き経路または手動処理へ戻します。[3]

WebArenaが終端状態で成功を判定し、τ-benchが反復成功を扱うことは、会話が完了しても実環境の処理が部分的に残る可能性を評価対象へ入れる根拠になります。[2] [3] 業務では、依頼全体の成功・失敗だけでなく、実行済み、未実行、重複、取消待ちを工程別に決算し、確認時刻も残します。

決算票には、一つの実行IDの下で、予定した操作、実際のツール応答、外部状態の確認、後続工程への引渡し、残った副作用を記録します。ツールが成功を返しても外部状態を確認できなければ確定にせず、反対に応答が途切れても状態が更新済みなら再実行へ進ませません。応答と状態が矛盾する案件は人へ回し、状態照合に使った手順も版管理します。

仮想例として、予約作成後に通知だけが失敗した場合、依頼全体を最初から再実行すると予約が重なるおそれがあります。予約は確定、通知は未完了として分け、通知だけを再開するか、予約を取り消して全体を戻すかを決算票から選びます。自然な完了文を成功証拠にはせず、選択理由も残します。

各工程には、処理開始前、外部更新後、後続引渡し後のどこから再試行できるかを定義します。再試行地点ごとに、既に確定した操作、再実行してよい操作、重複を検知する識別子、取り消し手段を結びます。状態が分からない場合は自動再試行を止め、人へ渡す状態と確認責任者を指定し、地点を越える承認者も定めます。

取り消せない操作が含まれる場合は、元に戻すことだけを前提にせず、訂正通知、反対操作、別記録の追加など、業務として受け入れる補完行為を決めます。補完後の状態が目的を満たすか、残る不利益を誰が承認するかまでを試験し、技術的なエラー解消だけで完了にせず、補完期限も設定します。

完了証明には、最終状態、未処理項目、実行した補完、手動引継ぎ先、再開禁止区間を含めます。同じ依頼の言い換え試験とは別に、途中で応答が切れる、状態確認が遅れる、手動介入が入る条件を試し、部分成功から正しく再開できる工程だけを自律範囲へ加えます。未処理が残る証明には有効期限を付け、発行した実行IDも残します。

• SETTLE：予定・実行済み・未実行・重複・取消待ちを決算する
• CHECKPOINT：再試行地点と、確定済みの外部状態を固定する
• COMPENSATE：取消不能時の補完行為と残る不利益を定める
• CERTIFY：未処理、引継ぎ先、再開禁止区間を完了証明へ残す

導入候補を、読むだけ、下書き、可逆な更新、金銭・権限・外部送信を伴う更新に分けます。初期段階では読み取りと下書きに限定し、操作前に現在状態と予定差分を表示します。高影響操作には許可されたツールと引数の上限を設け、実行直前の人の承認と実行後の状態照合を必須にします。

ログには、利用者の目的、参照した規則、各ツールの入力と返り値、状態差分、保留理由を残します。失敗時はモデルだけを責めず、観測不足、計画、規則検索、引数生成、ツール、確認のどこで壊れたかを分類します。自動化率を上げる前に、停止、取り消し、手動引き継ぎを同じ試験で通すことが、長い工程を安全にする条件です。さらに、承認者が判断に必要とした根拠を画面に残し、形だけの承認を成功として数えない評価にします。

自律範囲の所有者は業務工程ごとに置き、技術チームだけで拡大を決めないようにします。業務所有者が許容する最終状態と影響を定め、システム所有者が権限と取消手段を保証し、品質担当が失敗標本を保守します。取消不能な操作、検証できない結果、承認根拠が表示できない操作は、自動化率にかかわらず境界外へ戻します。

• 開始条件：初期状態、目的、許可されたツール、禁止操作を機械的に確認する
• 継続条件：各操作後の状態が予定差分と一致した場合だけ次工程へ進む
• 承認条件：外部送信、金銭、権限変更では対象と差分と根拠を人へ提示する
• 停止条件：状態不一致、規則競合、取消不能、検証不能のいずれかで手動へ引き継ぐ