技術要約：AEVAL – エージェント的スキルワークフローにおける、逸話的評価から決定論的テストへ

1. 問題提起

現代のエージェント・システムは、スキル（自然言語による仕様（例：SKILL.md）、スクリプト、および設定を含むインストール可能なパッケージ）にますます依存するようになっています。これらは、LLMエージェントにドメイン固有のタスクを実行する方法を教えるものです。スキルのリポジトリが拡大するにつれ、現在の評価パラダイムは**逸話的（anecdotal）**なものになっています。つまり、開発者がスキルを手動で起動し、デモ実行を観察して、その成功に対して主観的な印象を形成するというものです。

このアプローチには、以下の3つの決定的な欠陥があります：

1. 再現性の欠如： 連続する2回の実行では、異なるコードパスが実行されたり、異なる出力が生成されたりすることがあり、開発者の判断に一貫性がなくなります。
2. 比較可能性の欠如： 主観的な印象は、バージョン間やマージリクエスト（MR）間で比較することができません。
3. スケーラビリティの問題： マルチスキル・マーケットプレイスにおいて、単一のデグレ（退行）が数十のダウンストリーム・ワークフローを密かに破壊する可能性があります。

さらに、素朴なエージェント評価には、特定の技術的な失敗モードである**自己修正バイアス（Self-Correction Bias）**がつきまといます。同じエージェントが実行と採点の両方を行う場合、エラーから回復するために、実行中にスキルやその構成を密かにパッチ（修正）してしまうことがよくあります。その後、エージェントはそのパッチ適用後の出力を「成功」として採点します。これは、スキルのアーティファクト自体の品質ではなく、エージェントのデバッグ能力を測定してしまっている、系統的に楽観的なシグナルを生み出します。

2. メソドロジー：AEVALフレームワーク

AEVAL（Agentic Evaluation）は、逸話的なテストを、決定論的で変更トリガー型のテストパイプラインに置き換えるために設計された、CI統合フレームワークです。これは、あらゆるスキルの変更をテストイベントとして扱い、5つのフェーズからなるワークフローを実行します。

2.1. スキル定義による評価契約

各スキルは、その仕様と共に配置された eval.config ファイルを同梱しています。この契約には以下が宣言されます：

• テストケースのための自然言語プロンプト。
• 期待される結果。
• 必要な認証情報。
• 明示的な設定がなくてもテスト可能性を確保するための、3層のフォールバックメカニズム。

2.2. 5フェーズ・パイプライン

1. 調査 (Examine): システムは git diff を介して変更されたスキルを検出します。
2. インストール (Install): 変更されたスキルがクリーンなセッションにインストールされます。
3. 使用 (Use/Execution): 自動エグゼキューターが契約に基づいてスキルを実行します。
   • 制約: **シミュレーション出力（擬似出力）**を厳格に禁止します。コマンドが失敗したり、サービスに到達できなかったりした場合、その失敗は実際のテスト結果として記録されます。エージェントは、アサーションを通すためにログを捏造したり、結果を合成したりすることはできません。
4. 評価 (Evaluate/Grading): エグゼキューターとグレーダー（採点者）の間に構造的分離を強制します。
   • エグゼキューター: スキルを実行し、トランスクリプト（$\tau$）と出力（$O$）を生成します。
   • グレーダー: 読み取り専用の情報セット（テストプロンプト $x$、実行トランスクリプト $\tau$、出力 $O$、および実行前のアサーション $A$）に制限された別個のサブエージェントです。
   • 初回試行採点ルール (First-Attempt Grading Rule): グレーダーは、初回試行の軌跡に対してアサーションを評価します。もしエグゼキューターが、アサーションを成功させるために因果的に必要となる自己修正的な編集（$\Delta(\tau) \neq \emptyset$）を適用した場合、最終的な状態に関わらず、そのアサーションは**FAIL（失敗）**と判定されます。
5. 提案 (Suggest): システムは、採点結果に基づいた修正案を生成します。

2.3. 根拠に基づいた階層的修正提案

投機的な「あれば良い」程度の変更によるチャーン（混乱）を防ぐため、提案は厳格に証拠に基づいています：

• 根拠付け (Grounding): すべての提案は、特定の失敗したアサーションまたは追跡された自己修正エントリを引用しなければなりません。
• 階層化 (Tiering):
  • LV1 (因果的): 初回試行の失敗に因果関係がある修正。これらはマージリクエストをブロックします。
  • LV2 (助言的): ハードな失敗を引き起こさなかったものの、グレーダーによって特定された品質または堅牢性の向上策。
• 配信: 提案は、インラインのGitLab MRコメントとして、「提案を適用（Apply suggestion）」用の差分と共に投稿され、開発者が実証済みのパッチをワンクリックで適用できるようにします。

3. 主要な貢献

本論文は、主に4つの貢献を述べています：

1. 決定論的スキルテスト・プロトコル: 個別のスキル契約と実行ごとのアーティファクト・スキーマを備えた、変更トリガー型の評価システムであり、手動評価を再現可能なCIパイプラインへと置き換えます。
2. 自己修正バイアスの定式化: 特定のモデルの選択によるものではなく、実行と採りの構造的な結合から生じる明確な失敗モードとしての、自己修正バイアスの特定と定式化。
3. 構造的分離と初回試行採点: エグゼキューターとグレーディングのループを分離し、初回試行採点ルールを強制するプロトコル。これにより、品質シグナルが、スキルの「パッチ適用後」の状態ではなく、出荷時の「そのままの」品質を反映することを保証します。
4. 根拠に基づいた階層的提案: 修正提案を、因果的な証拠（LV1）または助言的フィードバック（LV2）に厳密に紐付けた、ワンクリックでのMRコミットとして提供するメカニズム。

4. 実証結果

本フレームワークは、プロダクション環境のエージェント・スタックおよび、複数の主要なエージェントSDK（Claude系およびGPT系のエージェントを含む）に対して検証されました。

• バイアスの排除: 意図的に劣化させたセグメンテーション・スキルを用いたケーススタディにおいて、素朴なエバリュエーターは、エージェントがアクション名を密かにパッチした後に100%のパス率を報告しました。AEVALは、この自己修正を記録し、関連するアサーションをFAILと判定し、初回試行のパス率が厳密に低いことをCIに報告しました。
• 安定性: 「証拠に基づく」ルールを導入する前は、同じMRに対する繰り返しの実行で、異なる提案セットが生成されていました。このルールにより、繰り返しの実行は、同じ因果関係に基づいたLV1のセットへと収束しました。
• シミュレーション禁止: 下流のGPUクラスターに到達できなかった際、以前のイテレーションでは合成ログが生成されていました。AEVALの下では、エージェントは接続失敗を記録し、これにより下流のCIがスキル自体の欠陥と環境の失敗を区別できるようになりました。
• クロスランタイム・キャリブレーション: 本フレームワークは、同一のスキルを異なるエージェント・バックエンド上で実行することに成功しました。生のパス率は異なりますが、「因果シェア（causal share）」（提案のうちマージブロックとされる割合）は、グレーダーの深刻度を比較するための再現可能なスカラー指標を提供しました。バックエンドA（Claude系）の平均因果シェアは0.41であったのに対し、バックエンドB（GPT系）は0.82であり、異なるエージェントが深刻度をどのように解釈するかという系統的な違いを明らかにしました。
• コスト効率: プロンプトキャッシュのヒット率が95〜97%であるため、プッシュのたびにプロトコルを再実行する際の限界トークンコストは低く、継続的インテグレーションをサポートするのに十分です。

5. 意義と主張

本論文は、AEVALが、評価シグナルがパッチ適用後の状態ではなく、初回試行の実行の関数であることを保証する構造的な保証を提供すると主張しています。

• 基礎的なブロック: 著者らは、決定論的なスキルテストを、確率的な被覆保証（コンフォーマル予測のようなもの）としてではなく、信頼できるバイナリの正解ラベルを生成するための不可欠なアップストリーム・コンポーネントとして位置付けています。これらのラベルは、下流の統計的手法（例：コンフォーマル予測、不確実性定量化）が正しく機能するための前提条件です。
• 実践の変化: 本フレームワークは、「逸話的な手動テスト」から「決定論的で変更トリガー型のテストパイプライン」への移行を促進し、これは伝統的なソフトウェアエンジニアリングの進化を反映しています。
• 自動化ループ: 自己充足的な「パス率100%」のシグナルを、監査可能な「初回試行失敗」のシグナルへと変換し、ワンクリックのパッチを提供することで、AEVALはテスト・失敗・修正のループを閉じ、エージェント・ワークフローにおける信頼性の高いルーティングと停止決定を可能にします。

著者らは、シミュレーション出力の禁止がサンドボックス化ではなく指示によって強制されていることや、複雑な多段階の自己修正がグレーダーによって誤って属性付けされる可能性があることを認め、限界についても謙虚に述べています。しかし、エグゼキューターとグレーダーの構造的分離こそが、エージェント・ワークフローの統計的に厳密なモニタリングに必要とされる、信頼性の核心であると主張しています。