実行前に確認する：LLMエージェントの静かな失敗を減らす方法

導入

大規模言語モデルが端末操作、リポジトリの編集、外部ツールの呼び出しを担うようになると、最も危険な失敗が必ずしも例外を発生させるとは限りません。コマンドが正常に終了し、コード編集も適用されたように見えても、結果が意図と異なる場合があります。このような「静かな失敗」は実行系から成功として報告されるため、発見が難しくなります。

arXiv論文『Look Before You Leap: Pre-Action Verification for LLM Agents』は、操作が反映される前に検証するという防御策を提案しています。検証器は安価で決定論的であることを重視し、確信が持てない場合には無理に判定せず、操作を拒否してエージェントに修正や再試行を促します。

主なポイント

• コマンド検証は段階化できる。 9930件のコマンドと482個のツールを対象にした評価では、無効なコマンドの95.8%を検出し、誤検知率は10.0%でした。構文検査とバイナリ検査は誤検知ゼロで、全エラーの約半分を検出しました。報告された誤検知はすべてフラグ検査に由来し、その限界はヘルプテキストの網羅性に左右されます。
• 編集形式が失敗の見え方を決める。 検索・置換やdiffのように内容を基準にする形式は、対象が一致しないと明確に失敗しやすい一方、行番号や関数名に依存する形式は誤った場所へ適用されやすくなります。1行のずれがあるテストでは、行番号編集の99.1%がファイルを破損させ、関数名編集の12.7%が別の関数に適用されました。
• 拒否は失敗ではなく回復手段になる。 不確かな操作を拒否する方針では、選択的groundingが誤検知率7.0%で再現率0.958に達しました。アンカーと適用前検証を組み合わせた方式では、8320回中1回だけ静かな誤適用が発生し、その割合は0.01%でした。

意義と影響

重要なのは、監視を実行後だけに置かないことです。一般的な流れは、モデルが操作を生成し、実行し、結果を観察するというものです。しかし処理が成功したという事実だけでは、正しい対象が変更されたか、ユーザーの意図に沿っているかは分かりません。実行前検証は、意図した効果を生むための条件がまだ残っているかを先に確認します。

エージェント向けのツールAPIも、単純な成功・失敗だけでなく、対象、前提条件、アンカー、拒否状態を表現できる設計が望まれます。コード編集では行番号だけに頼らず、内容アンカー、パッチ検証、周辺コンテキストの確認を組み合わせるべきです。シェル操作では、構文と実行ファイルの確認を低コストな基礎層とし、引数の検証にはドキュメントの範囲という限界を明示する必要があります。

もちろん、この仕組みだけでユーザーの高次の意図を証明できるわけではありません。それでも、見えない誤りを明確な拒否へ変え、修正と再試行を可能にする点で、実用的な安全策になり得ます。

出典：arXiv