「正しい」が決定的でない場合のエージェント動作の検証

現代のソフトウェアテストは脆い仮定に基づいています：正しい振る舞いは再現可能であるということです。決定的なコードではこの仮定はほぼ成立しますが、GitHub Copilot Coding Agent（エージェントモード）のような自律エージェント、特に「コンピュータ使用」の統合を探求するにつれて、この仮定はすぐに崩れます。

エージェントが単純なコード提案からUI、ブラウザ、IDEなどの実際の環境と対話するようになると、正しさはマルチパスになります。ローディング画面が現れたり消えたり、タイミングが変動し、複数の有効なアクションシーケンスが同じ結果に至ることがあります。GitHub Actionsワークフローがこの変動に対応できるほど堅牢でない限り、エージェントがタスクを成功させてもテストが失敗するという「偽陰性」が発生し、本番環境を停止させます。

このブログ記事では、脆いステップバイステップのスクリプトを超えて、エージェント検証のための独立した「トラストレイヤー」を構築する方法を探ります。必須の成果に焦点を当てるモデルを示し、説明可能で軽量、かつ実際のCIパイプラインに対応できる検証方法を提供します。

エージェント駆動検証の課題

GitHub ActionsパイプラインがCopilot Agent Modeに依存して実際のワークフローを検証していると想像してください。エージェントはコンピュータ使用を活用し、コンテナ化されたクラウド環境内をナビゲートするかもしれません。火曜日のビルドはグリーンでしたが、水曜日にはコード変更がないにもかかわらずテストが失敗しました。何が起こったかというと、ホストランナーでの軽微なネットワーク遅延により、ローディング画面が数秒長く続きました。エージェントは待機し、適応し、タスクを正しく完了しました。しかしCIパイプラインは実行を失敗としてマークしました——タスクが失敗したのではなく、実行パスが記録されたスクリプトやアサーションのタイミングに一致しなかったからです。エージェントは失敗していません。検証が失敗したのです。これにより、エージェント駆動テストにおける「信頼ギャップ」を生み出す3つの反復的な問題点が浮き彫りになります：偽陰性（タスクは成功したがテストランナーが変動を許容できなかった）、脆弱なインフラ（タイミングやレンダリング、環境ノイズによりテストが失敗する）、コンプライアンスの罠（結果は正しいが、エージェントの振る舞いが自動テストの期待から逸脱したため回帰としてフラグされる）。

私たちは移行期にあります。GitHub Copilot Coding Agentのようなエージェントシステムは開発を加速していますが、従来の検証アプローチは依然として硬直的です。決定的なソフトウェアでは、正しさは特定の入力と既知の出力を一致させることと同義です。しかしエージェントでは、その間のプロセスは意図的に非決定的です。正しさは一連の定められたステップに従うことではなく、「必須の成果を確実に達成すること」です。これらのシステムを拡大するには、「偶発的なノイズ」（例：ローディング画面）と「重大な障害」（例：データ保存の失敗）を区別できる検証フレームワークが必要です。正しさは「これは起こったか？」から「成功が本物であるためには何が起こらなければならなかったか？」へと移行します。

既存のテストアプローチが自律エージェントで機能しない理由

従来のテストツールは実行パスが固定されている場合にうまく機能します。振る舞いが分岐すると、ツールは破綻し始めます——エンジニアリングが悪いからではなく、安定したシーケンスを前提としているからです。Copilot Coding Agent（コンテナ環境でのナビゲーションを含む）に適用すると、4つの一般的なパラダイムで限界が明らかになります：アサーションベーステスト（手動で仕様を記述する必要があり、有効な代替パスを考慮できない）、記録再生ツール（環境ノイズに非常に敏感）、ビジュアル回帰テスト（実行フローを理解せずにスクリーンショットを比較）、MLオラクル（大量のトレーニング例を必要とし、不可解）。これらのアプローチは実装が異なりますが、共通の構造的仮定を共有しています：正しさは観察可能な状態の特定のシーケンスへの準拠によって定義される。エージェントシステムではその仮定は崩れます。真の開発者の信頼を構築するには、線形スクリプトのチェックを超えて、構造化された振る舞いの検証に移行しなければなりません。

正しさの再定義：必須行動とオプション行動

脆いテストを超えてトラストレイヤーを構築するには、「正しい」の定義を根本的に変えなければなりません。エージェントシステムでは、正しい実行は同一に見える必要はありません。共通の論理構造を共有する必要があります。エージェントの振る舞いを3つのカテゴリに分類できます：必須状態（成功のために発生しなければならないマイルストーン、例えば「検索結果」画面）、オプションの変動（環境に応じて変化するローディングスピナーなどの偶発的な状態）、収束パス（ホットキーとメニューの使用など異なるステップのシーケンスが最終的に同じ結果に合流する）。ローディング画面は表示されることもあればされないこともありますが、検索結果は表示されなければなりません。これらの中で正しさを決定するのは一つだけです。

直感から理論へ：支配分析

「必須」と「偶発」の振る舞いの区別は、コンパイラ理論に根ざした支配関係の概念です。制御フローグラフにおいて、開始からBへのすべてのパスがAを通過しなければならない場合、ノードAはノードBを「支配」します。支配分析をエージェント実行トレースに適用することで、どの状態が強制か、どの状態がオプションか、異なるパスがどこで収束するかを自動的に識別できます。これにより、正しさの最小限で説明可能な定義を抽出できます。

実行をグラフとしてモデル化、スクリプトではなく

エージェントの振る舞いの複雑さを捉えるには、実行を線形の1次元スクリプトとして扱うことから脱却しなければなりません。私たちのフレームワークは、プレフィックスツリーアクセプタ（PTA）として知られるグラフベースの構造で振る舞いをモデル化します。ノードは観察可能な状態（UIエージェントの場合はスクリーンショット、開発エージェントの場合はコードスナップショット）を表し、エッジは状態間の遷移（クリック、キーストローク、API呼び出し）を表します。グラフにより、分岐と収束を表現できます——これらは線形スクリプトでは不可能な概念です。分岐はローディング画面の有無のような非決定的な環境変化を説明し、収束は異なるパスが再び合流するポイントを識別し、エージェントが変動をうまくナビゲートして主要タスクフローに戻ったことを示します。表現をステップのシーケンスから構造化された振る舞いモデルにシフトすることで、エージェントが異なるパスを取ったことを罰するのをやめ、論理的に健全なパスに従ったかを検証し始めます。

解決方法：正しさへの構造的アプローチ

エージェントを実験的なデモから本番級のインフラに移行するために、私たちのチームは新しい検証アルゴリズムを開発しました。これは硬直したスクリプトに頼るのではなく、例から学習します。テストには複雑な非決定的環境を選びました：Visual Studio Codeを「コンピュータ使用」でナビゲートするAIエージェントです。わずか2〜10の成功セッションを観察することで、アルゴリズムは自動的に「グラウンドトゥルース」モデルを構築し、エージェントの有効な変動と実際の障害を区別します。ワークフローは以下の通りです：キャプチャ（PTA構築：成功トレースを収集しPTAグラフに変換）、一般化（セマンティックマージ：3層の等価性検出フレームワークを使用してトレースを統合グラフにマージ。高速ビジュアル指標とLLMセマンティック分析を組み合わせる）、スケルトン抽出（支配分析を適用して「必須状態」を特定し、「オプション」状態を自動的にフィルタリング）。このアプローチは、手動仕様や大規模モデルトレーニングを必要としないため、ユニークに強力です。結果のモデルは実際の実行状態のグラフであるため、決定は完全に説明可能です。検証が失敗した場合、アルゴリズムはどの必須状態が見逃されたかを特定することで明確な失敗理由を提供します。

状態の等価性：2つの状態が「同じ」かどうかの判断はエージェント検証で最も難しい問題です。私たちは3層の等価性検出フレームワークを使用して解決します：ビジュアル指標（高速知覚ハッシュと構造的類似性）、セマンティック分析（あいまいな場合にマルチモーダルLLMを使用）、保守的マージ（等価と確信できる場合のみ状態をマージ）。これは単純なピクセル比較でも「LLMの手振り」でもありません。LLMを防御的かつ控えめに使用して特定の曖昧さを解決することで、フレームワークは堅牢でありながら実際の回帰を検出する精度を維持します。

支配分析による本質の抽出：複数の実行トレースが統合グラフにマージされると、アルゴリズムは支配分析を適用してタスクのコアスケルトンを分離します。状態Aが状態Bを支配するのは、開始からBへのすべての可能なパスがAを通過しなければならない場合です。必須状態をタスク完了の支配者として定義します。数学的関係を計算することで、アルゴリズムは自動的に「必須」マイルストーンと「偶発的」ノイズを区別します。VS Code実験では、「検索ダイアログ」状態は数学的支配者であるため必須マイルステーンとして識別されます——検索をトリガーせずに結果に到達することは論理的に不可能です。一方、「ローディング」画面は何も支配しません。高速な実行ではバイパスされるため、アルゴリズムはそれを必須ではなくオプションの変動としてフラグします。これらの必須ノードを支配サブツリーに抽出することで、正しさの最小限で説明可能な定義を作成します。

新しい実行の検証：支配木がグラウンドトゥルースとして確立されると、新しい未検証の実行の検証は、完全一致を探すのではなく構造比較のプロセスになります。トポロジカル部分列マッチングを使用します：新しいトレースがリファレンスと同一である必要はなく、必須状態が正しい相対順序で出現する必要があります。追加状態の扱い：リファレンスシーケンスがA→B→CでエージェントがA→X→B→Y→Cを生成した場合、テストは合格です（追加状態は偶発的ノイズとして扱われます）。障害検出：必須状態がスキップされるか、必要な論理順序から外れた場合にのみ障害がトリガーされます。スコアリングと説明可能性：フレームワークは単なる合格/不合格以上のものを提供します。リファレンスモデルの総状態数に対するマッチした必須状態の割合としてカバレッジを計算し、失敗理由（例：「状態'検索結果'が'検索ダイアログ'の後に到達しなかった」）を提供します。これにより、検証は「ブラックボックス」から開発者がエージェントと環境をデバッグできる診断ツールに変わります。

評価からの教訓

実験では、支配木法をエージェントの自己評価（CUAが自身の成功を報告）と比較しました。結果：支配木法は正確性100%、精度100%、再現率100%、F1スコア100%を達成し、CUA自己評価（正確性82.2%、F1スコア69.8%）を大幅に上回りました。最も重要なのは、エージェントの内部自己評価が「バグではない」シナリオを完全に識別できなかったことです（F1スコア0%）。独立したトラストレイヤーは、障害が製品回帰ではなくエージェント実行エラーである場合の識別で52.2%のF1スコアを達成しました。構造的検証は自己報告成功を大きく上回ります。

開発者ワークフローへの統合

トラストレイヤーフレームワークが効果的であるためには、研究プロトタイプを超えて開発者が日常的に使用するシステムに統合されなければなりません。統合ポイントには以下が含まれます：GitHub Actionsパイプライン（環境ノイズによる偽陰性を削減）、回帰テスト（安定バージョンの検証済みトレースからグラウンドトゥルースモデルを作成）、エージェント評価（エージェントの自己報告ではなく必須マイルストーンのヒット率を測定）、UI自動化（複雑なデスクトップおよびWebアプリの堅牢な自動化）。目標はエージェントを「実験的デモ」から「本番インフラ」に移行することです。

現在の制限と将来の作業

現在のフレームワークにはいくつかの境界があります：成功トレースの要件（2〜10の成功実行トレースが必要）、LLM依存性（セマンティック等価性チェックにマルチモーダルLLMアクセスが必要であり、外部API依存性とレイテンシを導入）、時間的ブラインドスポット（状態の持続時間をまだ検出できない）。将来の作業には、時間的および負の制約の追加、階層的およびマルチモーダル抽象化（低レベルスクリーンショットを高レベル概念にクラスタリング）、オンライン学習（新しい成功実行を検証するたびに支配者を再計算）が含まれます。

これが今重要な理由

AIエージェントが実験的なデモからコアインフラに移行するにつれて、検証も進化しなければなりません。脆いスクリプトから回復力のあるシステムへ。他のブラックボックスモデルを判断するブラックボックスモデルは必要ありません。開発者が検査し、推論し、信頼できる構造的保証が必要です。古典的なコンパイラ理論（支配分析）とマルチモーダルAIを組み合わせることで、少数の例から説明可能で堅牢な成功の定義を学習できることを実証しました。このトラストレイヤーフレームワークは、効率的な学習、運用上の堅牢性、完全な透明性を提供します。コンピュータ使用のAIネイティブ開発ライフサイクルへの採用が増える中、これらの保証は不可欠です。検証可能な自律性への旅は始まったばかりです。