💬 NLP

PolicyBank: Evolving Policy Understanding for LLM Agents

この論文は、事前テストからの修正フィードバックを通じて構造化されたポリシー知見を反復的に洗練させるメモリ機構「PolicyBank」を提案し、LLM エージェントが自然言語で記述された曖昧な組織ポリシーのギャップを自律的に埋め、既存手法が失敗するシナリオでも人間のオラクルに近い精度を達成できることを示しています。

原著者： Jihye Choi, Jinsung Yoon, Long T. Le, Somesh Jha, Tomas Pfister

公開日 2026-04-20

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Jihye Choi, Jinsung Yoon, Long T. Le, Somesh Jha, Tomas Pfister

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

ポリシーバンク：AI 助手が「ルール」を自ら学び直す仕組み

この論文は、**「AI 助手が、不完全なマニュアル（ルール）を、失敗から学んで自ら修正し、より賢く働くようになる仕組み」**について書かれています。

少し難しい専門用語を使わず、日常の例え話を使って解説します。

1. 問題：完璧なマニュアルなんて存在しない

想像してください。新しい**「カスタマーサポートの新人（AI）」が雇われました。
会社は彼に、「自然言語（普通の言葉）」で書かれたマニュアル**を渡します。

マニュアルの例：
「お客様がフライトの遅延を訴え、変更やキャンセルを希望する場合のみ、50 ドルの補償券を渡してください。」

新人 AI はこのマニュアルを忠実に守ります。
しかし、ある日、「ゴールド会員のお客様」が「フライトが遅れたので補償が欲しい」と言ってきました。でも、「飛行機は変えたくない（キャンセルもしたくない）」と言っています。

マニュアルの通り： 「変更・キャンセルの希望がないから、補償は NG！」と断ります。
本当の会社の意図： 「遅延で迷惑をかけたゴールド会員には、飛行機を変えなくても補償すべきだ！」

ここで AI は**「マニュアルには忠実だが、間違っている」状態になります。
これがこの論文が扱う「仕様と実態のギャップ（Policy Gap）」**です。
自然言語で書かれたルールは、どうしても曖昧だったり、抜けがあったりします。AI がマニュアルを「絶対の真理」として受け止めると、こうして理不尽な対応をしてしまうのです。

2. 既存の AI の限界：「失敗」を「学習」できない

これまでの AI の学習システム（メモリー機能）は、「成功した例」を覚えて、同じことを繰り返すことに特化していました。
「どうすればタスクを成功させるか？」を学ぶのです。

でも、今回の問題（マニュアルが間違っている場合）では、「マニュアル通りにやったのに失敗した」という経験が必要です。
従来のシステムは、「マニュアル通りにやったのだから、それは『成功』だ（あるいは単なる能力不足だ）」と判断してしまい、「マニュアル自体がおかしい」という根本的な問題に気づきません。
まるで、「間違った地図を信じて歩き続け、目的地にたどり着けないのに、自分の足が悪いせいだ」と思い込んでいる状態です。

3. 解決策：PolicyBank（ポリシーバンク）

そこで登場するのが、この論文が提案する**「PolicyBank（ポリシーバンク）」**です。

これは単なる「過去の会話記録」ではなく、**「ツールごとのルール解釈を整理したデータベース」**のようなものです。

仕組みのイメージ：

試行とフィードバック：
AI がタスクを実行し、もし開発者（またはテスト担当者）から「それは違うよ、ゴールド会員には補償すべきだ」という訂正フィードバックが返ってきます。
分析する「政策エージェント」：
PolicyBank には、**「ルール修正の専門家（Policy Agent）」**という別の AI がいます。彼が、AI の失敗とフィードバックを分析します。
- 「あ、これは AI の計算ミスじゃないな。マニュアルの『変更・キャンセル必須』という条件が、ゴールド会員には適用されないという**『抜け』**があるんだな」
メモリの更新：
専門家 AI は、マニュアルの「変更・キャンセル必須」という部分を、**「ゴールド会員や保険加入者は例外」**という新しいルールとして、PolicyBank に書き込みます。
次のタスク：
次のお客様が来たら、AI は PolicyBank を見て、「あ、このお客様はゴールド会員だから、変更しなくても補償券を出していいんだ」と判断します。

つまり、AI は「マニュアル（仕様書）」そのものを書き換えるのではなく、「マニュアルの解釈（インサイト）」をアップデートし続けるのです。

4. 実験結果：劇的な改善

研究者たちは、航空会社や小売店のシミュレーションでこの仕組みを試しました。

従来の AI： マニュアルのギャップがあるタスクでは、ほぼ 0% の成功率でした。「マニュアル通りだから」という理由で、理不尽な対応を繰り返します。
PolicyBank を使った AI： 失敗から学び、ルール解釈を修正した結果、人間が正解だと考える行動に 82% も近づきました。

まるで、**「完璧なマニュアルがない中で、先輩のアドバイス（フィードバック）を元に、自分なりの『正解の解釈』を積み重ねていく、優秀な新人」**のようになっています。

5. まとめ：なぜこれが重要なのか？

この研究が示しているのは、**「AI を完璧にするには、完璧なマニュアルを書く必要はない」**ということです。

従来の考え方： マニュアルを完璧に書き上げないと、AI は使えない。
この論文の考え方： マニュアルに穴があっても、AI が**「フィードバックを通じて自らルール解釈を進化させる」**仕組みがあれば、実社会で使えるようになる。

PolicyBankは、AI が「言われたこと」を盲目的に守るロボットから、「言われたことの意味」を理解し、状況に合わせて**「より良い判断」**を下せるパートナーへと成長させるための、重要な一歩です。

一言で言うと：
「マニュアルが不完全でも、AI が『失敗とフィードバック』からルール解釈を自らアップデートし、人間が本当に望む行動をできるようになる新しい仕組み」です。

PolicyBank: LLM エージェントのための進化するポリシー理解に関する技術的サマリー

本論文「PolicyBank: Evolving Policy Understanding for LLM Agents」は、大規模言語モデル（LLM）エージェントが組織のポリシー下で動作する際、自然言語で記述された不備のある仕様（曖昧さや論理的欠落）を、インタラクションとフィードバックを通じて自律的に修正・進化させるための新しいアプローチ「PolicyBank」を提案しています。

以下に、問題定義、手法、主要な貢献、実験結果、および意義について詳細にまとめます。

1. 問題定義：仕様と真の要件の乖離（Policy Gap）

LLM エージェントは、ドメインエキスパートによって自然言語（NL）で記述されたポリシー（例：航空会社の運航遅延時の補償規定など）に従って動作します。しかし、現実の NL 仕様には以下の問題が頻繁に存在します。

曖昧性、未定義、論理的矛盾: 仕様書が完全でなく、真の要件（True Requirements）と一致しないケースが多い。
「従順だが誤った」行動: エージェントが仕様書を文字通り忠実に実行しても、組織の意図した行動（真の要件）と異なる結果を招く「アライメント失敗（Alignment Failure）」が発生する。
- 例: 「遅延し、かつ変更・キャンセルを希望する場合にのみ補償する」という仕様がある場合、遅延のみで変更を希望しない顧客への補償を拒否してしまうが、本来は遅延さえあれば補償すべきという真の要件があるケース。

既存のメモリ機構や自己進化エージェントは、タスク実行能力の向上（Type I: 実行失敗）に焦点を当てており、仕様自体の欠陥による失敗（Type II: アライメント失敗）に対しては、仕様を「不変の真実」として扱い、誤った行動を強化してしまっていました。

研究課題: エージェントが、事前テストやデプロイ後のフィードバックを通じて、仕様と真の要件の乖離（Policy Gap）を自律的に検知し、解釈を修正して閉じることができるか？

2. 手法：PolicyBank

PolicyBank は、エージェントがポリシーの解釈を反復的に洗練させるための構造化されたメモリ機構です。

2.1 基本的なアーキテクチャ

構造化メモリ（Policy Bank）: ポリシーを単なるテキストとしてではなく、ツールレベルの「洞察（Insights）」として格納します。各エントリは以下の構造を持ちます。
- TRIGGER: 適用条件
- PRECONDITIONS: 検証ステップ
- ELIGIBILITY: 許可条件
- ACTION: 実行手順
- KEY INSIGHT: 仕様（ $\pi_{spec}$ ）と真の要件（ $\pi_{req}$ ）の乖離を埋めるために学習された差分（例：「変更を希望しなくても、ゴールド会員には補償する」）
Policy Agent（ポリシーエージェント）: 各タスク完了後、実行軌跡（Trajectory）と開発者からのフィードバック（正解/不正解、および理由）を分析し、メモリを更新します。
- 更新操作: 新しいエントリの追加、既存エントリの修正、変更なしのいずれかを選択。
- 失敗の分類: 実行失敗（能力不足）とアライメント失敗（仕様不足）を区別し、後者に対しては仕様の解釈を修正する方向に学習します。
動的なポリシー検索: エージェントは会話の文脈変化に応じて retrieve_policy() ツールを呼び出し、関連するポリシーエントリを動的に取得します。これにより、コンテキストウィンドウの制限を回避しつつ、必要なルールを正確に適用できます。

2.2 評価ベンチマークの拡張（ $\tau$ -Bench 拡張）

既存の $\tau$ -Bench を拡張し、以下の 3 種類の構造的な「ポリシーギャップ」を意図的に含んだタスクセットを作成しました。

曖昧な範囲（Ambiguous Scope）: 例示リストを網羅的と誤解させる仕様。
未定義の例外（Under-Specified Exceptions）: 正当な例外（境界条件）が明記されていない仕様。
論理的矛盾（Logical Contradiction）: 実際には独立している変数を条件として結びつけている仕様。

さらに、親タスク（ギャップ発見元）に対して、シスタータスク（単純化版、異なるインスタンス版、複雑化版）を生成し、学習したポリシーの一般化能力と堅牢性を評価します。

3. 主要な貢献

問題の定式化: 「実行失敗」と「アライメント失敗（仕様ギャップによるもの）」を明確に区別し、LLM エージェントにおける「進化するポリシー理解（Evolving Policy Understanding）」という新たな課題を定義しました。
PolicyBank の提案: 仕様の不備を自律的に修正し、ツールレベルの構造化されたポリシー洞察を維持・更新するメモリ機構を設計しました。
評価基盤の構築: 実行失敗とアライメント失敗を分離して評価できる、 $\tau$ -Bench を拡張した厳密なテストベッドを提供しました。

4. 実験結果

Gemini-3.0-Pro と Claude-4.5-Opus などの最先端モデルを用いた実験で、以下の結果が得られました。

既存手法の限界: 従来のメモリ機構（Synapse, AWM, ReasoningBank など）は、ポリシーギャップが発生するシスタータスクにおいて、成功率がほぼゼロに落ち込みました。これらは「成功した軌跡」から学習する傾向があり、仕様そのものが間違っている場合の修正ができませんでした。
PolicyBank の性能:
- ギャップの解消: PolicyBank は、人間のパフォーマンス（Human Oracle）とのギャップを最大 82% まで縮小しました。
- 一般化能力: 親タスクでフィードバックを受け取った後、シスタータスク（異なるユーザー、複雑な状況など）においても高い成功率を維持しました。
- 一貫性の向上: pass^k メトリック（複数試行での安定性）において、PolicyBank は他手法を大きく上回り、エージェントの振る舞いを安定化させました。
フィードバックの重要性: 単なる正解/不正解（Reward Only）よりも、「なぜそれが正しいか」を説明する自然言語フィードバック（Reward + Explanation）がある場合、学習効率が劇的に向上しました。

5. 意義と結論

本論文は、LLM エージェントが単にタスクを遂行するだけでなく、「仕様そのものの不備」を認識し、修正する能力を持つことの重要性を示しました。

実用性: 組織のポリシーは頻繁に変更され、また初期仕様には必ず曖昧さが含まれます。PolicyBank は、手動でのルール書き換えなしに、エージェントがテストとフィードバックを通じてこれらのギャップを埋め、真のビジネス要件に適合する行動を自律的に習得することを可能にします。
将来展望: 大規模なテストベッドの構築、ノイズのあるフィードバックへの耐性強化、オープンソースモデルへの適用、および形式的検証レイヤーとの統合などが今後の課題として挙げられています。

総じて、PolicyBank は、LLM エージェントが複雑で不完全な自然言語制約下で、より信頼性高く、人間と協調して動作するための重要な基盤技術を提供しています。