Column

LedgerAgent：ポリシー遵守型ツール呼び出しエージェントのための構造化状態管理

AIエージェントがカスタマーサービス業務でツールを実行する際、古い・不完全な状態情報を参照することでドメインポリシーに違反する問題がある。arXivで公開された研究が、タスク状態を「台帳」として管理し実行前にポリシーを検証する手法を提案する。

2026 / 06 / 23 5 分で読める English version →

こんにちは。Affectosphere Group の井下です。

エンタープライズAIを実際の業務に導入するとき、一番怖いのは何でしょうか。

「AIが間違えること」と答える人は多いと思います。でも実務家の視点からいうと、もっと怖いことがあります。

「AIが正しいと思って、間違ったことをやってしまうこと」です。

特にカスタマーサービスや金融・保険・通信のような業務では、 AIエージェントがツール（外部APIや社内システム）を呼び出して実際のアクションを実行します。その実行が社内ポリシーに違反していたら、後から取り消すコストは非常に高くつく。

2026年6月にarXivで公開された研究（Md Nayem Uddin, Amir Saeidi, Eduardo Blanco, Chitta Baral；arXiv:2606.20529）は、この問題に真正面から取り組んでいます。

今日の3点

エンタープライズAIの失敗事例を見ていると、モデルが賢くなれば解決できる問題より、設計上の見落としから起きる問題の方が多い印象があります。

この研究が指摘するのは「状態依存ポリシー」の問題です。

たとえば、通信会社のカスタマーサービスエージェントを考えてみましょう。顧客がプランを変更しようとするとき、「まず現在のプランを確認してから変更ツールを呼び出す」という順番が正しい手順です。

ところが、エージェントが古いキャッシュ情報を参照していたり、途中のステップで状態が更新されていたりすると、「現在のプランとは矛盾する変更」を実行してしまう。

これが状態依存ポリシーの違反です。

モデルが「ポリシーを知らなかった」のではなく、「正しい状態情報にアクセスできていなかった」ために起きるミス。この区別は、対策を設計する上でとても重要です。

LedgerAgentのコアアイデアはシンプルです。

観測済みのタスク状態を、「台帳（ledger）」という別個のデータ構造として管理し、推論のたびにプロンプトへ注入する。

台帳には、エージェントがこれまでに実行したアクションの結果、現在確認されている状態情報が記録されています。ツールを呼び出す前に、台帳の情報をもとに「このアクションは現在の状態に照らしてポリシーと整合するか」を検証する。整合しなければ、そのアクションを実行前に遮断する。

重要なのは、これが推論時（inference-time）の手法だという点です。

モデルを再トレーニングするわけではありません。プロンプトに台帳を注入する形で動くため、既存のLLMベースのエージェントに後付けで組み込める。導入コストが低い設計です。

この研究が対象にしているのはカスタマーサービスですが、応用範囲はもっと広いと思います。

金融・保険では、申請の審査ステータスを正確に追跡しながら次のアクション（支払い承認、却下通知など）を実行する場面があります。審査ステータスの誤読が重大な問題につながる典型的な状態依存ポリシーの場面です。

通信会社では、複数のオプションや割引が複雑に絡み合う契約変更業務があります。「このオプションは現在の契約条件では適用できない」というルールをリアルタイムで検証しながらツールを呼び出せるかどうかが、品質に直結します。

コンプライアンスリスク管理の観点からいえば、 LedgerAgentのアーキテクチャは「実行前検証」を構造として持っています。事後のログ監査だけに頼るのではなく、実行前にポリシー違反を遮断できる設計は、規制対応コストを下げる上でも有効です。

AIエージェントが実業務に入り込んでくる速度が上がっています。

「まずは試してみて、問題が出たら直す」というアプローチは、 PoC段階では許容されても、本番運用では許されないケースが増えてきました。

特にコンプライアンス上重要な業務（金融、医療、通信、保険）では、「エージェントが実行前にポリシーを検証できているか」という問いに答えられる設計が求められます。

LedgerAgentの研究が示すのは、「状態管理を独立した構造として持つこと」がその問いへの一つの実用的な答えになりうるということです。

複数回にわたって一貫した結果が求められる設定での改善、という実験結果も重要です。業務の現場では、一度きりのシンプルなケースよりも、複数ステップが絡む複雑なケースの方が圧倒的に多いからです。

モデルの賢さを追いかけるだけでなく、「状態情報を正確に管理し、実行前に検証する構造を持つか」という設計上の問いを、導入検討の基準に加えることをおすすめします。

Md Nayem Uddin, Amir Saeidi, Eduardo Blanco, Chitta Baral (2026). LedgerAgent: Structured State Management for Policy-Adherent Tool-Calling Agents. arXiv preprint arXiv:2606.20529.

※ 本記事は一部 AI により執筆されており、間違った情報が含まれる恐れがあります。