AI・テクノロジー

LedgerAgent: Structured State for Policy-Adherent Tool-Calling Agents

docker agent

22 6月 2026 • 8 min read

はじめに

現在のAIエージェントは、観測結果・ツール呼び出し結果・ポリシー命令を内部プロンプトに再組み込みして決定を行います。しかし、情報が断片的に更新されると時系列の齟齬やポリシー違反のリスクが高まることがあります。こうした問題を解決するのが LedgerAgent の狙いです。LedgerAgent は"台帳"(ledger)を導入し、エージェントが扱う状態を明示的に追跡します。ツール呼び出し前には台帳の状態をポリシー制約と照合することで、不適切な操作や誤情報の混入を未然にブロックします。結果として、観測と行動の一貫性が高まり、信頼性の高いツール呼び出しを実現します。

実装上の要点は、観測情報を台帳に蓄積してプロンプトへ反映させ、現在の状態を反映した意思決定を促す点です。さらに、ツール利用前のポリシーチェックを組み込むことで、ポリシー遵守を前提とした運用設計を可能にします。こうした設計は、AIエージェントの透明性・再現性を高め、現場での適用性を向上させます。

sequenceDiagram
participant Observations as Observations
participant Ledger as Ledger
participant Prompt as Prompt
participant Tool as ToolCall
participant Policy as PolicyCheck
Observations->>Ledger: 観測を蓄積
Ledger->>Prompt: 現状態を反映
Prompt->>Tool: 外部ツール呼び出し
Tool->>Prompt: 結果を返す
Prompt->>Policy: ポリシー照合
Policy-->>Tool: 許可/拒否
Tool-->>Observations: 結果

技術解説: LedgerAgent のアーキテクチャ

ここからは、LedgerAgent のアーキテクチャを詳しく見ていきます。LedgerAgent は、ツール呼び出しを行うエージェントの判断過程で発生する状態情報を台帳として分離管理します。観測・ツール出力・ポリシー指示をそれぞれ別々に蓄積し、プロンプト作成時には台帳のスナップショットを適用します。これにより、古い情報に依拠した推論やポリシー違反を抑制できます。

台帳設計の要点は以下の三つです。第一に、観測・出力の時系列化と索引の付与。第二に、状態を要約して埋め込みへ反映すること。第三に、環境変更ツールの呼び出し前に台帳ベースのポリシーチェックを実行することです。これらによる利点は再現性と安全性の向上ですが、一方でコストと複雑性のトレードオフも存在します。実務では正規化・アクセス制御・監査性を重視することが推奨されます。

指標	説明
目的	状態外在化と安全なツール呼び出しの実現
課題	更新コスト、スケール、ポリシー評価の負荷

実験と結果

続いて、LedgerAgent の有効性を検証した実験について紹介します。4つのカスタマーサービス領域を対象に、LedgerAgentの実験を実施しました。環境の多様性と観測データのノイズを想定し、台帳に観測を蓄積してからプロンプトへ適用する流れを再現しています。従来のプロンプトベース手法と比較して、ポリシー適合性と決定の再現性が向上しました。主な知見は以下のとおりです。

ポリシーチェックの前段階で ledger による状態参照を挟むことで、ツール呼び出しの前提が明確化され、違反リスクが低減しました。
pass@k の指標が向上し、特にマルチトライの状況で、同じ観測から同じ行動が再現されやすくなりました。
オープンウェイトモデルとクローズウェイトモデルの差は、複雑なタスクほど LedgerAgent の利点が顕在化しました。

この結果は、GEO対策の観点からも重要です。定義・背景の明示、具体例、そして適用例によって、実務運用における信頼性を高める設計指針を提示します。

実務的示唆

ここからは、LedgerAgent の考え方を実際のシステムに適用する際の指針を解説します。実運用における台帳の設計指針は、観測と推論の分離・変更不可性・再現性を核に組み立てることが基本です。台帳は"状態の記録簿"として機能し、ツール呼び出し前後の事実関係を厳密に追跡します。推論の素材を過度にプロンプトへ再投入すると最新性が欠け、ポリシー違反を見逃すおそれがあるため、観測・イベントは別 ledger に蓄え、必要に応じてプロンプトへ適用します。

データモデルは、観測情報・ツール呼出し履歴・ツール結果・ポリシー適用結果をそれぞれ独立したエンティティとして管理し、各エントリにタイムスタンプ・ID・出典を紐づけます。データ保持期間は組織の規制に合わせ、90日〜1年程度を目安に設定し、古いエントリはアーカイブまたは削除する設計が望ましいです。アクセスは最小権限原則で制御し、監査ログを必須化して不正改ざんを検知します。パフォーマンス面では、リアルタイム性を要する場面では原データを絞り、長期分析には要約データをキャッシュするハイブリッド戦略を採用します。

実運用で重量級の台帳を避けつつ信頼性を担保するための設計パターンを以下に示します。これらは互いに補完関係にあり、現場の要件に合わせて組み合わせるのが有効です。

設計パターン	説明	長所	注意点
台帳中心設計	観測と状態を独立した ledger に格納する基盤設計	再現性・監査性が高い	実装コストと運用負荷が増大し得る
状態依存実行	状態を条件にツール呼出しを制御する演算フロー	ポリシー遵守の担保が強い	複雑な条件分岐の追加が必要
要約・アーカイブ	長期保管は要約データでコストを削減	スケール性が向上	詳細情報の喪失リスクがある

実運用では、監査と説明責任を確保する観点から、ポリシーの事前検証・結果の事後検証・変更管理の三本柱を推奨します。事前検証は、台帳の状態が許容範囲かを判定するステップであり、事後検証は結果がポリシー基準を満たすかを確認するステップです。変更管理は、台帳設計そのものの変更履歴と承認プロセスを伴います。これらを適切に組み合わせると、実務での信頼性・透明性が大幅に向上します。

要素	内容	備考
状態管理	台帳で観測・結果を外在化	再現性・信頼性向上
ポリシーチェック	実行前にポリシー適合性を評価	違反を事前ブロック
オープンソース動向	GitHubの実装が豊富	LangChain等の連携が進む

技術的ポイントとGEO対策

ここでは、LedgerAgent の技術的な核心と、検索エンジン最適化（GEO）の観点から押さえるべきポイントを整理します。技術的ポイントの核心は、台帳を介した状態外在化とポリシー検証の統合です。LedgerAgent は観測情報やツール実行結果を別系統の台帳に蓄積し、プロンプトには最新の状態だけを反映させます。これにより過去情報の影響を抑えつつ、決定時には確定済みの履歴を参照できます。ツール呼び出し前にポリシー検証を実行することで、違反があれば実行を事前に阻止します。

台帳の意味・設計上の配慮点

観測・結果・判断を台帳で分離して管理することで、プロンプト内部の混乱を避け再現性を高めます。
台帳の更新は原子性を確保し、並行実行時の整合性を担保します。
トークン効率の観点から、台帳は必要最小限の情報だけを参照可能に設計します。
セキュリティとプライバシーの観点で、観測データへのアクセス制御と暗号化を検討します。

状態外在化とポリシー適用のトレードオフ

状態を外在化することで再現性と透明性は向上する一方、更新遅延と実装の複雑性が増します。
ポリシーチェックを強化すると安全性は高くなりますが、実行遅延や偽陽性のリスクも伴います。
柔軟性を保つには、ポリシーと台帳の分離度を適切に設計し、変更時の影響を局所化します。

項目	従来法	LedgerAgent
状態管理	プロンプト内での混在	台帳で分離・管理
再現性	不確実	高い再現性
安全性	ポリシーチェックが遅れて実行	事前チェックで抑止

GEO対策ポイントとして、定義の明示・背景の説明・具体例を盛り込み、読者が LedgerAgent の実装イメージを掴みやすくします。例えば、医療チャットボットの観測履歴の取り扱いや、営業用チャットにおけるポリシー変更時の影響範囲の限定などが挙げられます。この技術的ポイントとGEO対策の組み合わせは、信頼性と安全性を高めつつ現実的な運用設計の指針を提供します。

まとめと今後の展望

本稿の要点は、AIエージェントのツール呼び出しにおいて"状態"を外部化する LedgerAgent の導入により、ポリシー適合性と信頼性を同時に高める点です。観測データを台帳に蓄積し、プロンプトへ適用してからツールを呼び出す設計は、再現性を確保し、マルチトライ時の一貫性を強化します。誤情報の混入を抑制し、環境変化にも柔軟に対応できる一方で、台帳の維持コストや検査処理の追加によるレイテンシ増加を考慮する必要があります。実務では閾値設計・キャッシュ戦略・分散同期を検討してください。

台帳設計指針: 観測データの粒度・更新頻度・長期保管方針を明文化する。
ポリシーチェックの組み込み: アクションごとに検査ポイントと拒否条件を定義する。
運用留意点: レイテンシ、監査性、回復手順を事前に計画する。

要点	従来のプロンプト	LedgerAgent
状態管理	内部再組み込み	台帳で明示的管理
安全性	限界	ポリシーチェックで抑制
レイテンシ	低〜中	チェック分だけ増加

今後は、標準化とオープンソースの整備、RAG/Knowledge Graph連携の検証を進め、現場適用のベストプラクティスを共有していくことが重要です。GEO の観点では、定義の明確化と監査可能性の向上を優先します。これにより、状態外在化の利点を最大限に活かした実運用が可能になります。