カスタマーサービスを担うAIエージェントが払い戻しや個人情報の開示といった取り返しのつかないアクションを実行する前に、ポリシー違反を自動で検出・遮断するフレームワーク「LedgerAgent」がarXiv（2606.20529）で発表されました。タスクの状態を会話プロンプトに埋め込む従来手法に代えて「台帳（ledger）」と呼ぶ構造化ステート管理を導入し、ツール呼び出し前にポリシー制約を検証することで一貫性指標を改善しています。4つのカスタマーサービスドメインで複数のLLM（Large Language Model、大規模言語モデル）バックエンドを使って評価されており、特に厳格な複数試行基準下での改善が顕著です。
背景と文脈
LLMを使ったカスタマーサービスエージェントの課題は、応答の品質だけではありません。ツール呼び出し（tool calling：LLMが外部のAPIや関数を呼び出して実際のシステム操作を実行する機能）を通じて払い戻し処理・アカウント変更・個人情報の参照などを行う場合、社内ポリシーに違反したアクションを実行してしまうリスクがあります。
既存のアプローチでは、ポリシールールや会話の文脈をシステムプロンプトに直接埋め込み、LLMがそれを読んで判断するよう求めます。しかしこの方式には2つの根本的な弱点があります。1つは「参照ミス」で、多ターンの会話が進むにつれてLLMが過去の状態を見落としたり古い情報を参照したりする問題です。もう1つは「構文的な正しさと意味的な違反の乖離」で、ツール呼び出しの構文は正しくてもポリシー上は違反になるケースをLLMが気づかないことがあります。
技術/ビジネス面
LedgerAgentの核心は2つのコンポーネントの組み合わせです。1つ目が「台帳（ledger）」と呼ぶ構造化ステートトラッカーです。これはタスクの進捗状態（何が確認済みか、何が未解決か、顧客の要求はどこまで処理されたか）を会話テキストから切り離して専用の構造体として管理します。LLMが推論するタイミングでこの台帳の内容がプロンプトに注入されるため、LLMは常に最新の正確な状態を参照できます。
2つ目が「推論前ポリシー検証」です。LLMがツール呼び出しを生成した後、実際に実行される前に台帳の状態とポリシー制約を照合します。ポリシー違反と判定された呼び出しは実行されず、LLMに別の対応を求めます。つまり問題が起きてから修正するのではなく、問題が起きる前に止める設計です。
評価はMd Nayem Uddin氏ら4名の研究チームが設計した4つのカスタマーサービスシナリオ（返品処理、アカウントロック解除、料金変更、プライバシーリクエストなど）で実施されました。複数回の試行で一貫して正しい判断ができるかどうかを問う厳格な基準で、従来手法との差が明確に出ています。
これからどうなるか
LedgerAgentが解決しようとしている問題は、カスタマーサービスに限りません。社内ナレッジベースへのアクセス制御、金融取引エージェント、医療情報の参照エージェントなど、「LLMが実際のシステムを操作する」あらゆる場面でポリシー準拠の問題は存在します。
開発者がLLMエージェントに払い戻し・変更・削除などの「副作用を持つツール」を持たせる場合、このような事前検証レイヤーの設計が製品の信頼性を左右します。特にエンタープライズ向けのサービスでは法的・コンプライアンス上の要件もあり、「LLMの判断を信じる」だけでは不十分なケースが増えています。LedgerAgentのアーキテクチャは、そうした場面でのリファレンス実装として参照する価値があります。
まとめ
LedgerAgentはタスク状態の台帳管理とツール実行前のポリシー検証を組み合わせることで、カスタマーサービスLLMエージェントのポリシー準拠性を高めます。ツール呼び出しエージェントを本番環境で運用する開発者にとって、状態管理と制約チェックの設計指針として参考になる研究です。
参考リンク
アイキャッチ画像: Photo by Markus Winkler on Unsplash
