GuardAgent: コード実行によるLLMエージェントの確定的安全性の強化
書き戻し（write-back）を行うエージェントにおける中心的な安全性の問題は、「本来実行すべきでないアクションをいかに阻止するか」という点にあります。GuardAgent（Xiangら、ICML 2025）は、専用のガードレールエージェントを提案しています。これは、ターゲットエージェントのアクションが実行される前に、定められた安全ポリシーに照らしてすべてのアクションをチェックする独立したLLMエージェントです。Bean Labsにとって、「エージェントが会計ルールに違反せずに帳簿に書き込めるか」という問いは譲れないものであり、この論文は私たちの研究課題の核心に位置しています。
論文の概要
UIUC、エモリー大学、UCバークレーの研究 者らによる論文「GuardAgent: Safeguard LLM Agents by a Guard Agent via Knowledge-Enabled Reasoning」は、著者らが主張するところの、LLMシステムのための初の汎用ガードレールエージェントを紹介しています。核心となる考え方はシンプルです。安全上の制約をターゲットエージェントのプロンプトに直接埋め込む（無視されたり忘れられたりする可能性がある）のではなく、ターゲットエージェントのアクションを傍受し、規定のポリシーに照らして検証する独立したエージェントとしてGuardAgentを実行します。
この仕組みは2つの段階で構成されます。まず、LLMが安全ポリシーとターゲットエージェントが提案した入出力を読み取り、何をチェックすべきかを記述した段階的なアクションプランを作成します。次に、呼び出し可能な関数が事前定義されたツールボックスを使用して、そのプランを実行可能なPythonコードに変換します。外部のPythonインタープリタがそのコードを実行し、確定的な「はい/いいえ」の判定を下します。メモリ・モジュールが過去のタスクのセット（ポリシー、プラン、コード）を保存し、レーベンシュタイン距離を用いて類似の過去事例を検索することで、追加の微調整なしで数例（few-shot）のインコンテキスト学習を可能にします。この論文では、著者らが導入した2つの新しいベンチマークでこのアプローチを評価しています。
主なアイデア
- コード実行は自然言語による判定に勝る。 安全性の判断がLLMのテキストではなくコードとしてレンダリングされると、出力は確定的になります。Pythonエンジンが許可またはブロックを行い、最終的な判断ステップでのハルシネーションのリスクが排除されます。LLMは正しい最終回答ではなく、正しいコードを生成するだけで済みます。
- 2つのカスタムベンチマーク。 EICU-AC（316例）は、3つのユーザーロールと10のデータベースを持つヘルスケアデータベース上でのEHRAgentのアクセス制御をテストします。Mind2Web-SC（200例）は、SeeActウェブエージェントの6つの安全ポリシーをテストします。これらはいずれも、この論文のために著者らによって作成されました。
- ラベル精度は98.7%および90.0%（GPT-4）。EICU-ACとMind2Web-SCにおいてそれぞれ高い精度を達成しました。重要なのは、ターゲットエージェントがアクションを許可されるべき場合に、タスクを正常に完了できるかという最終応答の精度が、両方の設定で100%に維持されている点です。
- ハードコードされた安全ルールは大幅に失敗する。 ポリシーをターゲットエージェントのシステムプロンプトに直接埋め込むと、2つのベンチマークで81.0% / 77.5%の精度しか得られず、さらにターゲットエージェントが正当なタスクの29.2% / 71.0%に失敗するという、実用性と安全性の容認できないトレードオフが生じました。
- LlamaGuardはこの用途には不適切。 コンテンツモデレーションのベースラインは約50%の精度（偶然とほぼ同等）に留まりました。これは、LlamaGuardが有害なテキストを対象として設計さ れており、「エージェントのアクションが特定のアクセス制御ルールに違反しているか」を推論するようには作られていないためです。
- ツールボックスの削除は約8ポイントの損失。 呼び出し可能な関数ライブラリがない場合、EICU-ACでのGuardAgentの精度は98.7%から90.8%に低下します。ただし、必要な関数を自律的に定義することで一部を補完しています（明示的な指示がなくても出力の68%がコードを生成しており、著者らはこれをコード生成設計を支持する証拠としています）。
評価と限界
コード実行によって確定的な強制ポイントが得られるという中心的なアーキテクチャの洞察は非常に有用であり、アブレーション・スタディも誠実に行われています。ハードコードされた安全ルールとの比較は特に説得力があり、単にプロンプトにルールを追加するだけの安易な設計は、安全性を確実に強制できない一方でターゲットの利便性を低下させることを示しています。
しかし、評価には明らかな限界もあります。2つのベンチマークは規模が小さく（316例と200例）、著者ら自身が構築したものであるため、過学習のリスクがあります。EICU-ACは本質的にアクセス制御マトリックス（ロール × データベース）であり、構造化され列挙可能な問題です。これはコードが元々得意とする分野です。Mind2Web-SCはより複雑であり、そこでの90.0%という数字は一見印象的ですが、著者らはルール5（「映画、音楽、ビ デオ」をカバー）が広範なオープンワールド推論を必要とするため、最も多くの失敗を引き起こしたと認めています。これは、現実の金融エージェントが常に直面する種類のルールです。
メモリ・モジュールは文字列の類似性によってデモンストレーションを検索しますが、これは繰り返されるポリシータイプにはうまく機能するものの、全く新しいポリシーでは劣化するでしょう。また、フレームワーク全体が「信頼されたコンテキスト」を前提としています。つまり、安全ポリシー自体が信頼できる管理者によって提供される必要があります。攻撃者がポリシーを書き換えたり、ツールボックスに安全でない関数が含まれていたりする場合、GuardAgentは保護を提供できません。この論文では、敵対的なポリシー操作はモデル化されていません。後続の研究（ShieldAgent、arXiv:2503.22738；AGrail、arXiv:2502.11448）はすでにこれらのギャップを指摘しており、ShieldAgentはより広範なベンチマークでGuardAgentに対して平均11.3%の改善を報告しています。
なぜ金融AIにとって重要なのか
Beancountの書き戻しエージェントには、単なる安全プロンプト以上のものが必要です。つまり、作業を行うエージェントとは構造的に分離された、会計ルールを強制する仕組みが必要なのです。GuardAgentのアーキテクチャはこれに直接適合します。ガードエージェントが、書き込み が実行される前に、すべての提案された仕訳入力を会計ルール（貸借一致、ロックされた期間への投稿禁止、照合済み取引の変更禁止など）に照らしてチェックします。コード実行による強制レイヤーは、複式簿記の計算がまさにコードで確実に処理できる構造化された列挙可能なチェックそのものであるため、特に魅力的です。
正直な限界としては、GuardAgentは安全ポリシーを事前に列挙し、ツールボックスにエンコードできることを前提としています。実際のBeancountの運用では、一部の制約は暗黙的（ユーザーが長年築き上げてきた帳簿の慣習に従う）であり、一部は動的（予算の変更、勘定科目の再構成）です。GuardAgentは、事前に指定できない制約をどのように処理すべきかについては教えてくれません。それがより困難な問題であり、依然として未解決のままです。
次に読むべきもの
- ShieldAgent (arXiv:2503.22738, ICML 2025) — GuardAgentをベースに、検証可能な安全ポリシー推論とShieldAgent-Bench（6つのウェブ環境にわたる2,000例）を導入。GuardAgentに対して11.3%の改善と、APIコールの64.7%削減を報告。
- AGrail (arXiv:2502.11448) — タスクごとのデモンストレーションを必要とせず、エージェントのタスク間で転移可能な適応的安全チェックを提案。GuardAgentのスケーラビリティの限界に直接対応。
- ToolSafe (arXiv:2601.10156) — ツール呼び出しエージェントのための、フィードバックを伴うプロアクティブなステップレベルのガードレール。GuardAgentの入出力インターセプトモデルよりもきめ細かな制御。
