技術要約：アプリケーション特化型エージェント評価のためのCopy-on-Write（CoW）スコアリング

問題提起

大規模言語モデル（LLM）ベースのエージェントをプロダクション・ソフトウェア・システムにデプロイする際、評価のギャップという重大な課題に直面している。エージェントはエンタープライズツールや消費者向けアプリケーションにますます統合されているが、既存の評価メカニズムでは、特定のアプリケーション・コンテキストにおける信頼性を確保するには不十分である。

• 構成概念妥当性の低さ： 標準的なベンチマークは、現実世界のアプリケーション環境、ツール、ワークフローの複雑さを反映できないことが多い。
• レプリカの限界： このギャップを埋めるためのレプリカやシミュレーション環境の作成は、リソース集約的でコストがかかり、「ドリフト（実環境との乖離）」が生じやすい。
• 信頼性のリスク： プロダクション環境で直接動作するエージェントは、データの誤消去、重要なレコードの上書き、ツールの誤用といった致命的なエラーを引き起こすリスクがあり、これらは詳細な評価なしには分離や防止が困難である。

現在の手法は、エージェントをターゲットとなるアプリケーション環境内で直接、かつ特定の失敗箇所を特定できるほどの粒度で評価する能力を欠いている。

手法：Copy-on-Write (CoW) スコアリング

著者らは、PostgreSQLレベルの隔離メカニズムを用いて、アプリケーション環境内で直接エージェントの操作を評価するためのフレームワークであるCopy-on-Write (CoW) スコアリングを提案している。このアプローチは、レプリカによるコストやドリフトを回避しながら、セッションの隔離を維持する。

1. CoW メカニズム

このフレームワークは、プロダクション・データを変更することなく、エージェントによる書き込みをインターセプトして隔離する、データベースレベルのCopy-on-Writeパターンを活用している。実装は4つのコンポーネントで構成される：

• ベース・テーブル（Base Tables）： 基盤となるプロダクション・データを含む。
• 変更用テーブル（Changes Tables）： ベース・テーブルと構造は同一だが、追加のメタデータ列（session_id, operation_id, cow_updated_at, cow_deleted）が含まれる。これらのテーブルには、特定のエージェント・セッション中に書き込まれた行のみが格納される。
• ビュー（Views）： ベース・テーブルと変更用テーブルをマージするSQLビュー。読み取りはビューに対して行われ（最新の状態を返す）、書き込みはリダイレクトされる。
• トリガー（Triggers）： ビュー上の INST {E} OF トリガーが書き込み操作をインターセプトする。ベース・テーブルを修正する代わりに、トリガーは影響を受けた行のコピーを作成し、書き込みを適用し、CoWメタデータを付与して、結果を変更用テーブルに挿入する。

このセットアップにより、エージェントはプロダクションに書き込んでいるかのように動作できるが、すべての変更はそのセッション専用の変更用テーブルに隔離される。

2. スコアリング・フレームワーク

CoW スコアリングは、グラウンド・トゥルース（GT）セッション（理想的なワークフローを実行した人間によって記録されたもの）と、エージェント・セッション（同じプロンプトを用いて実行されたLLMエージェントによるもの）を比較する。比較は2つの粒度で行われる：

• セッション・レベル・スコア： 最終的なデータベースの状態を評価する。
  • 構造スコア ($s_{struct}$): マッチした行（GTセッションとエージェント・セッションの両方に存在する行）の割合を、変更された総行数に対する比率として算出する。これは、欠落した行（生成されなかったGT行）と余分な行（GTに対応するエージェント行がないもの）を考慮している。
  • コンテンツ・スコア ($s_{content}$): 全てのマッチした行における、フィールドごとの平均類似度。SQLデータ型に基づいたデフォルトの比較器（例：数値に対する完全一致、JSONに対する深い等価性、テキストに対するシーケンス・マッチング）を使用して計算される。
• 操作レベル・スコア： 個々のアクションの有用性を定量化する。
  • 構造的有用性 ($u_{struct}$): 操作が適用される前と後での、セッション・レベルの構造スコアの変化量。
  • コンテンツ的有用性 ($u_{content}$): 特定の操作によって書き込まれた行の平均コンテンツ類似度。

決定的なのは、フレームousクがアクションのシーケンスではなく最終的なデータベースの状態を比較するため、セッション・レベルのスコアが、結果に到達するためにエージェントが辿った特定の経路に対して不変（インバリアント）である点である。

主な貢献

1. 新しい評価フレームワーク： 高価なレプリカ環境を回避し、アプリケーション環境内で直接エージェントを低コストかつ高忠実度に評価することを可能にする、CoW スコアリングの導入。
2. オープンソースの実装： データベースのセットアップ（ベース/変更テーブル、ビュー、およびトリガーの作成）を処理し、スコアリング・パイプラインを提供するPythonライブラリ agent-cow のリリース。
3. 粒度の高い診断： 構造的なエラー（行の欠落/過剰）とコンテンツのエラー（不正確な値）を区別することで、操作レベルでの具体的な失敗モードを浮き彫りにする能力。
4. 実証的検証： オープンソースのプロジェクト管理プラットフォームである Plane を用いた予備研究により、特定のツール・サーフェスの問題を特定し、修正後の改善を測定できることを実証。

結果：Plane のケーススタディ

著者らは、Plane アプリケーションにおける20のワークフローに対して、5つの言語モデル（GPT-5, GPT-4.1, Gemini-3.1-Pro, Gemini-3.1-Flash-Lite, Gemini-2.5-Pro）を評価した。

• 初期の知見： スコアリングにより、以下のような明確な失敗モードが明らかになった：
  • 語彙の不一致（Vocabulary Mismatch）： プロンプトで使用されている用語（例：「issue」）が、アプリケーションの内部用語（例：「work item」）と異なる場合に、エージェントは苦戦した。例えば、Gemini-2.5-Proは「issues」の検索時に繰り返し断念し、GPT-4.1は検索文字列について誤った仮定を行った。
  • ハルシネーションと余分な書き込み： GPT-4.1は時折、操作名やパラメータをハルシネーション（幻覚）し、Gemini-3.1-Flash-Liteは、要求されていないラベルやアサインイーの更新などの余分な書き込みを行った。これらは、CoW による隔離なしには検出が困難なものである。
• 反復的な改善： 診断スコアに基づき、用語（「issues」が「work items」として認識されるようにすること）を一致させるようツール・サーフェスが更新された。
  • 測定可能な利得： 語彙の不一致の影響を強く受けていたモデルは、大幅なスコア向上を示した。Gemini-2.5-Proは 54%、GPT-4.1は 47% 向上した。
  • 安定性： 初期スコアが高かったモデル（例：GPT-5, Gemini-3.1-Pro）は変動が最小限であり、スコアリング・メカニズムの安定性を裏付けた。

意義と主張

本論文は、CoW スコアリングをより安全なエージェント・デプロイメントのための実用的なツールとして位置づけている。その主な意義は、チームが以下のことを可能にする点にある：

• 失敗の局所化： 特定のアプリケーション・コンテキスト内で、エージェントがデータベースの書き込み操作において、どこで成功し、どこで失敗するかを正確に特定する。
• 効率的なイテレーション： レプリカ環境を構築・維持するオーバーヘッドなしに、モデルのプロンプト、ツール・サーフェス、および検索メカニズムに関する低コストなイテレーションを促進する。
• 構成概念妥当性のギャップを埋める： ジェネリックなベンチマークではなく、デプロイされる特定のアプリケーションに直接関連する評価データを提供する。

著者らは、フレームワークが手動で作成されたグラウンド・トゥルース・セッションに依存しており、アプリケーション特化型のデータセットを構築するのと同等の初期投資が必要になることを謙虚に述べている。また、現在の実装は書き込み操作に焦点を当てていることも認めているが、読み取りパターンも追加の診断信号を提供し得る。本フレームワークは、普遍的なベンチマークとしてではなく、アプリケーション特化型の検証のための補完的な手法として提示されている。