Harborを使って実際のタスクでエージェントをテストする方法 - Xander Song、Arize AI

하이라이트

• Harborは、隔離されたDocker環境と実際のタスク指示、副作用を検証するスクリプト（ベリファイア）を用いてエージェントを自動評価するオープンソースフレームワークである。

• タスクと試行は完全に独立しており、Daytonaなどのプロバイダー上で200前後のワーカーを並列稼働させて評価パイプラインを高速に実行できる。

• タスクを確実に解くスクリプト「オラクル」を用意することで、エージェントのトークン費用を消費する前に環境設定やベリファイアの正常性を検証できる。

• ベリファイアはエージェントの内部実装を関知せず、環境内に生じた副作用のみを判定するため、実装のリファクタリングを行ってもテストスイートが壊れない。

• エージェントの軌跡（トラジェクトリ）をATIF形式からOpenTelemetryベースのOpenInference仕様に変換することで、Phoenix上でのUI可視化や実験比較が可能になる。

• 集計処理にSQLツールを使うようプロンプトを1箇所調整したことで、不要なAPIページネーションが解消され、ターン数とツール呼び出し総数が減少した。

• 実用的な評価の成否は、テスト対象のコーディングエージェント単体ではなく、MCPサーバー、スキル、CLIなど周囲の統合環境全体をDockerコンテナに封入できるかどうかに依存する。

타임라인

1. 00:00 - 07:48

   Harborの基本概念とコアアーキテクチャ

   エージェント開発において感覚的なリリースを脱却し、確証に基づく評価を実現するためのフレームワーク構造が提示される。LLMの確率的な挙動を考慮し、1つのタスクに対して設定可能な試行回数（トライアル）を独立したコンテナで実行する。一連のタスク、試行、検証、ログ収集のサイクル全体を「ジョブ」として管理する。

   • Harborは、自然言語指示、Dockerベースの環境、副作用を検証するベリファイアで構成される。
   • ベリファイアはタスクごとに0/1や合否の報酬を出力し、結果をreward.txtに書き込む。
   • オラクルスクリプトを使用すれば、エージェントのAPIコストをかける前にテスト環境自体の不具合を洗い出せる。
   • エージェントの実行過程はATIF形式のJSONトレースとして記録される。
2. 07:49 - 13:59

   マイグレーション修正タスクに見る副作用ベースの検証設計

   SQLマイグレーション修正の具体例では、SQL定義ファイルとエラーを起こすデータをコンテナにシードし、エージェントが終了コード0および期待されるカラム構成を達成したかを検証スクリプトで判定する。内部の軌跡に依存しない統合テストの性質を持たせることで、エージェントの安全なリファクタリングが可能になる。

   • ベリファイアはエージェント実行後にDockerコンテナ内へマウントされ、カンニングを防止する。
   • 検証ツールはエージェントの実装を知らないブラックボックスとして環境の副作用のみを判定する。
   • 実装とテストの結合度を下げることで、プロンプトや内部ツールの変更時にもテストの破損を防げる。
3. 14:00 - 17:08

   サンドボックスによる水平スケーリングと評価メトリクス

   Claude Code（Opus 5）やCodex（GPT-5）などの異なるモデル構成を、同一データセットかつ複数トライアル（k=1, 2, 3）で並列テストするワークフローが示される。全トライアルが互いに干渉しない環境で実行されるため、大規模なデータセットに対しても再現性のある集計メトリクスを素早く算出できる。

   • 各タスク・各試行が独立したDockerコンテナで動作するため、クラウドサンドボックス上で完全な並列化が可能である。
   • Daytona上で約200の並行ワーカーを稼働させ、大規模なテストスイートを短時間で実行する。
   • pass@kなどの集計指標を算出し、確率的なエージェントの性能を統計的に把握する。
4. 17:09 - 20:46

   Arize PhoenixおよびOpenInferenceとの連携

   OpenInferenceはオープンソース標準として寄贈されたセマンティック規約であり、AIアプリケーションの動作構造をテレメトリとして統一する。Harbor単独でもCLIや内蔵UIで運用可能だが、Phoenixを接続することで実験のバージョン管理や時系列での指標追跡が容易になる。

   • Harborのデータセット、ジョブ、報酬は、Phoenixのデータセット、実験、評価プリミティブに直接対応する。
   • ATIF形式の軌跡はOpenTelemetry拡張であるOpenInference形式へ変換される。
   • 専用UIによって、LLM呼び出しやツール呼び出しの内部ステップおよび報酬推移を可視化できる。
5. 20:47 - 33:17

   Phoenix開発現場におけるDocker封入アーキテクチャ

   本番環境のOTLPパイプラインを再現するのではなく、検証済みのトレースデータを含むSQLiteファイルをコンテナ内に直接配置するアプローチを採る。複雑な外部依存をモック化してメンテナンスの泥沼に陥るリスクを避け、システム全体をコンテナに収めることで現実的なタスクを完結させる。

   • Phoenixサーバーは単一ノード構成のため、SQLiteデータを含むシステム全体を単一Dockerイメージに集約できる。
   • CLI、MCPサーバー、サーバーサイドエージェント（Pixie）の3つのインターフェースを対象にテストを実施する。
   • Harbor本体はホスト上で動作するオーケストレーターであり、規約通りのスクリプト群をコンテナ内でキックする。
6. 33:18 - 43:30

   SQLツール追加とプロンプト改善の実践的検証

   モデルごとの累計コスト集計など、API経由ではツール呼び出し回数が膨れ上がるタスクに対し、直接SQLを発行させる修正を施す。厳密なブラックボックス検証にとどまらず、ツール呼び出し最適化を目的に軌跡を直接検査する柔軟なベリファイア設計の有効性も説明される。

   • 集計タスクに対してエージェントがRESTやGraphQLのページネーションを過剰に繰り返す問題をSQLツールで解決した。
   • 集計時にはGraphQLよりSQLツールを使うようプロンプトを更新し、その効果をHarbor上で検証した。
   • Claudeを用いて合成質問とオラクルクエリのデータセットを構築し、検証スクリプトの基準とした。
   • 最適化目的の評価では、副作用だけでなく軌跡内部のSQL利用有無を検証対象とする場合がある。
7. 43:31 - 55:52

   Phoenix UIによるジョブ比較とスキルの回帰テスト

   実験比較画面では、集計クエリにおけるSQL利用への遷移やステップ数削減が確認される。スキル定義が重複して意図しない動作を引き起こす問題に対し、特定スキルの発火判定テストと副作用テストの使い分けが議論される。評価の難しさはフレームワークの操作自体よりも、本物の挙動を引き出す高品質なデータをコンテナに準備することにある。

   • プロンプト変更前後のジョブを比較し、報酬を維持したままGraphQL呼び出し数とターン数が減少した事実を確認した。
   • エージェントの回帰テストはPlaywrightに類似しており、スキルの正常系ワークフローを固めることが基盤となる。
   • 評価の本質は基盤モデル単体ではなく、自社開発のMCPサーバーやスキルを含めた統合システムの検証にある。
   • 現実的で品質の高い評価用データを調達・整理することがエージェントテストにおける最大の難所である。