技術要約: LEDGER – LLMエージェントの監査のための主張・証拠トレースグラフ

問題提起

大規模言語モデル（LLM）エージェントが、単発の質問応答システムから、ツール利用、コード実行、ファイル編集、アーティファクト生成を伴う長期的な技術的ワークフローを実行可能なインタラクティブなワーカーへと進化するにつれ、生産性の主要なボトルネックは、出力生成から**監査可能性（Auditability）**へとシフトしています。既存のオブザーバビリティ・システム（例：LangSmith）は、実行イベント（プロンプト、ツール呼び出し、エラー、中間出力）に関する詳細な可視性を提供しますが、この可視性は監査可能性と同義ではありません。

レビュー担当者は現在、「フラットな記録」の問題に直面しています。つまり、特定の結論を支持するどのアクション、アーティファクト、および検証ステップが関連しているかを判断するために、セッションの論理構造を手動で再構成しなければならないという問題です。この手動による再構成は、労力が大きく、セッションの複雑さに比例してスケールが悪くなり、最終的な主張とその根拠となる具体的な証拠との間の直接的な系譜（リネージ）を不明瞭にします。本論文は、効果的な監査には、レビュー担当者が線形なログを読むのではなく、報告された結果から、それを生成した具体的なアクションやアーティファクトへと遡ることができる、**証拠中心（Evidence-centered）**のアプローチが必要であると主張しています。

メソドロジー：LEDGERシステム

著者らは、修正されていないインタラクティブなエージェントセッションの傍らで動作するサイドカー型のトレーシングおよびレビューシステムであるLEDGER（Layered Evidence and Decision Graphs for Execution Review）を導入します。LEDGERは既存のオブザーバビリティを置き換えるものではなく、捕捉された記録を、人間によるレビューのために設計された階層的な意味論的トレースグラフへと再構成するものです。

1. キャプチャとトレース記録

LEDGERの基礎は、捕捉されたセッションデータの、解釈を伴わない安定した基盤である**トレース記録（Trace Record）**です。

• メカニズム: システムは、ライフサイクルフック（例：SessionStart, PreToolUse, PostToolUse）とトランスクリプト再構成を使用して、メッセージ、ツール呼び出し、結果、およびファイル操作を含むJSONペイロードをキャプチャします。
• 完全性: これらの記録は、ソースとなるトランスクリプトへのリンクを含め、セッションの元の順序と内容を保持します。これらは、推論された構造とは異なる「真実のソース（Source of Truth）」として機能します。

2. 階層型グラフの構築

LEDGERは、トレース記録を以下の3層のグラフ構造に整理します。

• 証拠ノード（Evidence Nodes）: 密接に関連するトレース記録（例：ツール呼び出しとその結果）を、検査可能な作業単位へとグループ化します。これらは、タイプ（Action vs. Artifact）およびカテゴリ（例：user_message, tool_call, control, artifact）によって分類されます。アーティファクトノードは、コードパッチ、プロット、表、またはコマンド出力などの検査可能なオブジェクトを具体的に表します。
• ワークフローノード（Workflow Nodes）: 関連する証拠ノードを、より高レベルのタスクフェーズ（例：context, plan, inspect, execute, validate, claim）へとグループ化します。この抽象化により、レビュー担当者はイベント単位ではなく、フェーズレベルでセッションを俯瞰できます。
• 意味論的エッジ（Semantic Edges）: 型付けされた有向エッジがノード間を接続し、関係性を定義します。主なエッジタイプは以下の通りです：
  • uses: ある作業単位がアーティファクトを消費する。
  • produces: ある作業単位がアーティファクトを作成または変更する。
  • checked_by: 変更が特定のステップによって検証される。
  • supports: 証拠が主張を正当化する。
  • informs: 結果が後続の計画を形成する。
  • frames: 要件がタスクのコンテキストを設定する。

3. インターフェースとレビューワークフロー

システムは、以下を統合したローカルダッシュボードを提供します。

• グラフビュー: ワークフロー層と証拠層の2レベルの可視化により、レビュー担当者は高レベルのフェーズから具体的な証拠へと遡ることができます。
• アーティファクト検査: グラフからリンクされた特定のプロット、パッチ、または表などの基礎となるアーティファクトへの直接的なインデックス参照。
• トレース構築の監査: 生のトレース記録とグラフの更新を表示することで、レビュー担当者がエージェントのエラーとトレーシングのエラー（すなわち、どのようにグラフが生のデータから構築されたか）を区別できるようにします。

主な貢献

1. 主張・証拠トレースグラフの構築: 修正されていないエージェントセッションを、アーティファクトノードが検査可能な証拠を表し、型付けされたエッジが主張とそれを支持するアクションおよび検証ステップを明示的に接続する、階層的な意味論的グラフへと解析する手法。
2. 証拠中心のレビューインターフェース: グラフレベルの監査パスとソース記録およびアーティファクトを統合し、レビュー担当者がワークフローの論理構造と生の証拠の間を流動的に移動できるようにするダッシュボード。
3. キャプチャと解釈の分離: 決定論的なソース記録（トレース記録）と、推論された構造（証拠/ワークフローノード）を厳格に分離する設計。これにより、グラフが真実のソースではなく、あくまで監査の補助手段であることを保証します。

結果とケーススタディ

論文では、ライブトレーシングが有効なCodexエージェントを用いた2つのケーススタディを通じて、LEDGERの妥当性を検証しています。

• ケーススタディ1：表形式データ分析: エージェントが大気質データを分析し、日次パターンレポートを生成しました。トレースグラフは、生成されたプロットや要約表を通じて、最終的な主張をソースとなるデータクリーニングのステップまで遡る**アーティファクトのリネージ（系譜）**を正常に露出させました。また、エラーと修復のシーケンスも強調し、依存関係の欠如によるスクリプト実行の失敗がどのように追跡され、パッチが当てられ、再検証されたかを示し、修復プロセスを透明化しました。
• ケーススタディ2：コードベースへの機能追加: エージェントがNetworkXライブラリに最短経路ユーティリティを追加しました。グラフは、初期の実装と、その後の回帰テストおよびガードパッチを区別しました。レビュー担当者は、設計上の決定（特定のモジュールに機能を配置すること）をリポジトリの調査とドキュメントの読解に遡って追跡し、さらに挙動を検証した特定のテストへと進むことができました。

両方のケースにおいて、システムは「監査パス」を明示的にする能力を示し、レビュー担当者が単に「主張がなされたか」だけでなく、「それがどのように具体的なアーティファクトやチェックによって支持されたか」を検証できるようにしました。

意義と主張

本論文は、LEDGERを、オブザーバビリティにおける必然的な進化として位置づけています。その意義は、可視性（何が起きたかを見ること）から、監査可能性（なぜその結論が信頼できるのかを理解すること）へのパラダイムシフトにあります。

• 控えめな主張: 著者らは、グラフの構築は完全には決定論的ではないことを明示しています（トレーサーはどの記録がどのグループに属するかを解釈し、意味論的エッジを割り当てます）。したがって、グラフは監査の補助として提示されています。インターフェースは、レビュー担当者がグラフの構築方法を検証できるように、基礎となる記録を常に可視に保つよう設計されています。
• 今後の方向性: 今後の課題として、モデルによる推論された構造を、より強力なインストルメンテーションやプロベナンス（由来）を認識するバックエンドを通じて、決定論的または独立して検証可能な構造に置き換えること、および決定論的な関係と推論された関係をより明確に区別するための視覚的語彙を改善することを提案しています。

最終的に、LEDGERは、ソース記録へのアクセスを維持しながら、アクション、アーティファクト、および結論の間のつながりを検査可能かつ辿れるものにすることで、複雑なエージェントのワークフローにおける人間による監視の高まるニーズをサポートすることを目指しています。