PolicyGuide、LLMエージェントを単一動作の監視から業務フローの誘導へ

導入

カスタマーサービスのLLMエージェントに求められるのは、禁止された操作を実行しないことだけではない。サービス変更の前に本人確認を行い、利用資格を調べ、条件を説明し、ユーザーの確認を得てからバックエンドのツールを呼び出す、といった一連の手順も守る必要がある。最終的な操作だけを見れば問題がなくても、途中の確認を一つ省けば、ポリシー違反になり得る。

単独の動作チェックからフローの誘導へ

一般的なランタイム保護は、エージェントが今から実行しようとしている返金、変更、情報更新などを局所的に判定する。明確に権限外の操作を止めるには有効だが、会話の中で前提条件が欠けている場合に、「何を補えば次に進めるのか」までは示さないことが多い。単にブロックするだけでは、ユーザーの依頼を適切な手順に戻すことができない。

PolicyGuideはこの問題を、ドメインごとのポリシーをワークフローグラフへコンパイルすることで扱う。グラフには必要なステップと、それらが進むための関係が表される。ユーザーの各ターンの境界でプロアクティブな検証器を呼び出し、保存されたグラフ状態から未完了の依頼を再確認する。そして、現在の段階に対応した具体的な補正方法をエージェントへ返す。結果として、検証器は「実行してはいけない」と告げるだけでなく、ポリシーに沿った次の経路を示せる。

評価で示された結果

論文はτ²-benchの航空、 小売、通信の各領域で、GPT-5.4エージェントと検証器を組み合わせて評価した。平均Pass^4は0.42から0.62へ上昇し、通信領域では0.19から0.61へ改善した。通信で効果が大きかったのは、手順の構造化がより明確で、前提条件や依存関係をグラフとして表しやすいからだと説明されている。

同じワークフローは、Claude Sonnet 4.6とGemini 2.5 Proを基盤とするエージェントにも移行できたと報告されている。さらに、敵対的なユーザーを想定した評価と、著者が設計したワークフロー水準の検証も行われた。前者では観測された比較結果の中で最も低い攻撃成功率、後者では最も高い手続き遵守が示された。ただし、これは論文で指定されたタスク、モデル、ポリシー、検証設定に基づく結果であり、あらゆる企業業務への普遍的な保証ではない。

意義と残る課題

PolicyGuideの重要な点は、ツール呼び出し単位の監視から、会話状態と業務プロセス状態を同時に管理する設計へ視点を移したことにある。企業のルールは、禁止事項の一覧だけでなく、実行可能で追跡可能なワークフローとして運用できる。エージェントにとっても、コンプライアンスは抽象的な制約ではなく、次に補うべき手順という実務的な指示になる。

一方で、更新されるポリシーや例外を正確なグラフへ落とし込む作業、複数ターンにわたる状態保存、定義済みの経路に当てはまらない事例の扱いは残された課題だ。計画、ワークフロー記憶、独立検証を組み合わせるこの方向性は、回答内容だけでなく、そこへ至る過程も管理しなければならない顧客対応システムにとって有力な設計候補になりそうだ。

出典：Hugging Face Daily Papers