ShieldAgent: LLMエージェントのための検証可能な安全ポリシー推論
先週、安全ポリシーを実行可能なコードに変換するGuardAgentについて取り上げましたが、今回はそれを明示的に上回ると主張する論文、ShieldAgent (Chen, Kang, and Li, ICML 2025, arXiv:2503.22738) を読み解いていきたいと思います。GuardAgentがプロンプトベースのガードレールに対して示した改善はすでに大きなものでしたが、ShieldAgentの確率的ルール回路が実際に残されたギャップを埋めるものなのか、それとも単にゴールポストを動かしているだけなのか。Beancountエージェントの書き戻し（write-back）の安全性をどのように構築すべきかを決定する前に、慎重に検討する価値があると考えました。
論文の概要
ShieldAgentは、LLMの安全性ではなく、エージェントの安全性に特化して設計された最初のガードレールエージェントであると自称しています。これは重要な区別です。LLMのガードレールは入力と出力を個別にスクリーニングしますが、エージェントのガードレールは、一見無害に見える一歩が有害なシーケンスの一部となり得る動的な環境において、マルチステップのアクショントラジェクトリ（行動軌跡）を推論する必要があります。論文の中心的な主張は、GuardAgentを含む既存のアプローチは依然として生のLLM推論に過度に依存しており、それが高コストで一貫性がなく、検証不可能であるという点です。
技術的な核心部分は、アクションベースの確率的ルール回路です。ポリシー文書が検証可能なルールにパースされ、各ルールにソフトな重み（マルコフ論理ネットワークのポテンシャルとして実装）が割り当てられ、スペクトラルクラスタリングによってアクション固有の回路にクラスター化されます。推論時、ShieldAgentは各エージェントアクションに関連する回路を検索し、4つの形式的な操作（Search、Binary-Check、Detect、およびStormpyモデルチェッカーを使用したFormal Verify）を実行して、確率的な安全ラベルを算出します。最終的な判断には相対的な安全条件（安全な確率と安全でない確率の差が閾値εを超える必要がある）が使用され、絶対的な確率閾値と比較して誤検知（False Positive）を減少させています。
主なアイデア
- マルコフ論理ネット ワーク上の確率的ルール回路: ソフトなルールの重みにより、ポリシーが曖昧な場合でも、矛盾したり不完全なポリシーを柔軟に処理できます。これはGuardAgentのような厳格なコード生成アプローチでは不可能です。
- 第一級の操作としての形式検証: Stormpyモデルチェックは、後付けのアドオンではなく、4つのシールド操作の1つとして組み込まれています。これがタイトルの「検証可能（verifiable）」が実際に意味するところです。
- エージェントベースの攻撃で90.4%、環境ベースの攻撃で91.7%の精度: ShieldAgent-Benchにおいて、評価されたすべてのベースラインの中で最も低い4.8%の誤検知率を達成しました。
- GuardAgentに対して平均7.4%の改善: 既存の3つのベンチマークにおいて、ST-WebAgentBench（91.1% vs 84.0%）、VWA-Adv（94.1% vs 89.9%）、AgentHarm（86.9% vs 78.4%）と、いずれも上回っています。
- APIクエリを64.7%削減し、推論速度を58.2%向上: ルール回路によって、ステップごとにトラジェクトリ全体をLLMに渡すのではなく、ターゲットを絞った検索が可能になるため、従来手法よりも大幅に高速化されています。
- オンラインコンプライアンスの大きな向上: リアルタイムモニターとして導入した場合、Shopping環境でのコンプライアンスは46.8%から65.3%に、GitLabでは22.8%から50.7%に跳ね上がりました。
- ShieldAgent-Bench: 6つのWeb環境と7つのリスクカテゴリにわたる3,110個のサンプルと、1,080個の検証済み安全ルールを含んでおり、手法とは独立して非常に有用な資産となっています。
評価できる点と懸念点
核となる考え方は健全です。生のLLMによる判断を構造化された確率的回路に置き換えることで、ガードレールはより安価に、より速く、そしてより監査可能になります。効率の向上（APIコールの64.7%削減）は、単なる「あれば良いもの」ではありません。ガードレールの呼び出しがメインエージェントにレイテンシを加える本番環境では、極めて重要です。
ベンチマークの設計も評価に値します。ShieldAgent-Benchは、実際のWeb環境における本物の敵対的攻撃アルゴリズム（AgentPoison、AdvWeb）を使用して構築されており、合成された安全データセットよりもはるかに信頼性が高いです。
しかし、いくつか懸念もあります。第一に、このシステムはポリシーの抽出、ルールの洗練、およびプランニングをGPT-4oに依存しています。つまり、ポリシー構築段階ではGPT-4oのコストとレイテンシを継承しています。著者らは「初期のポリシーモデル構築時には人間の専門家によるレビューが推奨される」と述べており、自動抽出が監視なしで導入できるほど信頼性が高くないことを暗に認めています。第二に、論文ではポリシー文書以外の事実知識を必要とするハルシネーション（幻覚）に関連するリスクにおいてパフォーマンスが低下することを認めています。会計エージェントの場合、書き込みがポリシーに準拠しているように見えても、算術的に誤っていたり、 存在しない勘定科目を参照していたりすることがあり、これは深刻なギャップとなります。第三に、ベンチマークはすべてWebエージェント環境（ショッピング、GitLab、Reddit）です。金融や会計タスクに関する評価はありません。この素晴らしい数値が、より厳格な算術的正当性が求められ、偽陰性（False Negative）が許容されないドメインにそのまま適用できるとは限りません。
また、アブストラクトで引用されている「従来手法に対して11.3%の改善」という数字と、本文で既存ベンチマークに対して引用されている「7.4%の改善」という数字が異なっている点も気になります。大きい方の数字には、著者らがベンチマークと手法の両方を管理しているShieldAgent-Bench自体が含まれていると推測され、これは評価においてよくある混同です。
金融AIにとってなぜ重要か
Beancountの書き戻しの安全性に関する問題は、ShieldAgentが対処している問題と構造的に似ています。メインエージェントが帳簿の修正案を提示し、ガードがコミット前にそれらの修正をポリシーに照らして検証する必要があります。ルール回路の考え方は明確に当てはまります。Beancountのポリシー（貸借不一致がないこと、勘定科目が存在すること、金額が正数であること、取引がユーザーによって承認されていること）は、LLMの自由形式の推論よりも、形式的な表現に適した検証可能で構造化された制約そのものです。
効率の向上は、Webエージェントよりも会計において重要かもしれません。帳簿書き戻しエージェントは、1つのセッションで数十の仕訳入力を提案する可能性があります。APIコールを64.7%削減するガードレールがあれば、リアルタイム検証が現実的になります。しかし、ハルシネーションのギャップが最大の課題です。ShieldAgentは、ポリシーには準拠しているものの事実として誤っている書き込み（金額の間違い、勘定科目の分類ミス）を捉えることができません。Beancountにとって、その失敗モードはおそらく最も一般的で、かつコストのかかるものです。ポリシー準拠のためのShieldAgentと、数値の正当性のための別の算術検証器を組み合わせたハイブリッドガードレールが、適切なアーキテクチャであると思われます。
次に読むべきもの
- AGrail: A Lifelong Agent Guardrail with Effective and Adaptive Safety Detection (Luo et al., ACL 2025, arXiv:2502.11448) — 補完的なアプローチをとっています。固定されたポリシーモデルを事前に抽出するのではなく、タスクを通じて学習する適応的な安全チェック生成を行います。ShieldAgentと比較して、ポリシー固定型とポリシー適応型のトレードオフを理解するのに役立ちます。
- Towards Verifiably Safe Tool Use for LLM Agents (arXiv:2601.08012, ICSE 2026) — システム理論的プロセス解析（STPA）を使用して、ツールを呼び出すエージェントに形式的な安全 保証を提供します。可能な限り確率的から決定論的な検証へとシフトしています。
- ST-WebAgentBench: A Benchmark for Evaluating Safety and Trustworthiness in Web Agents (arXiv:2410.06703) — ShieldAgentの評価に使用された3つの既存ベンチマークの中で最も厳格なものです。金融エージェントの評価に転用する前に、タスク設計とメトリクスの定義を理解する価値があります。
