> ## Documentation Index > Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt > Use this file to discover all available pages before exploring further. # AutomationBench でモデルを評価する > Harbor、CoreWeave Sandboxes、および任意に設定できるモデルエンドポイントを使用して AutomationBench を実行します。 CPU サンドボックスで [AutomationBench](https://github.com/zapier/AutomationBench) を実行し、シミュレートされた業務ワークフローでツール呼び出しモデルを評価します。このチュートリアルでは Harbor を使用して、タスクを個別にスケジュールし、特定のインフラストラクチャー障害を再試行し、結果を保持します。まずは 1 つのタスクから始め、サンドボックスと推論のクォータに応じて同時実行数を増やしてください。 この例では [CoreWeave Serverless Inference](/ja/products/inference/serverless) を使用します。OpenAI 互換の Chat Completions エンドポイント、モデル ID、推論キーを変更すれば、別のモデルも評価できます。

評価ワークフロー

[AutomationBench レシピ](https://github.com/coreweave/cwsandbox-recipes/tree/main/recipes/automationbench)は、ローカルマシン上で Harbor を実行します。各試行には CPU サンドボックスが割り当てられ、AutomationBench はそこにエージェントループ、シミュレートされたアプリケーション、アサーションベースの評価器をインストールします。モデルはお使いの推論エンドポイントで実行されます。サンドボックス内に GPU や実際のアプリケーションの認証情報を用意する必要はありません。 このレシピは Harbor の `BaseAgent` および `BaseEnvironment` インターフェースを実装し、公開されている CoreWeave Sandboxes ソフトウェア開発キット (SDK) の呼び出しを使用します。ネイティブの `auto-bench` 評価器を変更せずにそのまま実行し、上流の AutomationBench Harbor アダプターは必要ありません。Harbor、AutomationBench、`cwsandbox` SDK のバージョンはレシピ内で固定されています。

前提条件

開始する前に、以下を準備してください。 * ローカルマシンにインストールされた [`uv`](https://docs.astral.sh/uv/getting-started/installation/) と Git。このレシピには Python 3.13 以降が必要です。Python がインストールされていない場合は、`uv` が[対応するバージョンの Python をダウンロードします](https://docs.astral.sh/uv/concepts/python-versions/)。 * サンドボックスへのアクセス権を持つ [CoreWeave API アクセストークン](/ja/products/sandboxes/get-started#choose-a-credential)。 * 選択した同時実行数をまかなえる[サンドボックスの同時実行クォータ](/ja/products/sandboxes/reference/limits-and-quotas)と、サンドボックスあたり 2 vCPU および 4 GiB のメモリを許可するリソースポリシー。 * ツール呼び出しに対応した推論エンドポイント、APIキー、および十分な推論クォータ。この例では、[Serverless Inference](/ja/products/inference/serverless) の APIキーを作成します。 * ネットワークアクセス (お使いのマシンからサンドボックス API およびパッケージリポジトリへのアクセスと、サンドボックスから GitHub、Debian と Python のパッケージリポジトリ、および推論エンドポイントへのアクセス) 。 初回のチェックでは CPU サンドボックスを 1 つ作成します。サンドボックスのリソースと推論は別々に課金されます。評価の規模を拡大する前に、[サンドボックスの料金](https://www.coreweave.com/forge-pricing/inference-agents)と、ご利用の推論プロバイダーの[使用制限と料金](https://docs.coreweave.com/products/inference/serverless/usage-limits)を確認してください。

レシピのインストール

レシピのリポジトリをクローンし、バージョン固定済みの依存関係をインストールします。 ```bash theme={"system"} git clone https://github.com/coreweave/cwsandbox-recipes.git cd cwsandbox-recipes/recipes/automationbench uv sync --frozen cp .env.example .env ``` 以降のコマンドは、このレシピのディレクトリから実行します。ローカル環境には Harbor と Sandbox SDK が含まれています。各サンドボックスは、ベンチマークの固定済み lockfile を使用して、バージョンが固定されたチェックアウトから AutomationBench をインストールします。

モデルと認証情報を設定する

シークレットマネージャーから認証情報を読み込み、プロセスの環境変数に設定します。`CWSANDBOX_API_KEY` には CoreWeave サンドボックスの認証情報を、`MODEL_API_KEY` には推論の認証情報を設定してください。キーは `.env` ファイルに保存しないでください。 `.env` ファイルには、モデルのエンドポイント、モデル名、および必要に応じて project のみを設定します。Serverless Inference の例では、次の設定を使用します。`[WANDB-TEAM]` と `[WANDB-PROJECT]` は、アクセス権のある名前に置き換えてください。 ```bash theme={"system"} MODEL_BASE_URL="https://api.inference.wandb.ai/v1" MODEL_NAME="openai/gpt-oss-120b" MODEL_PROJECT="[WANDB-TEAM]/[WANDB-PROJECT]" ``` `MODEL_PROJECT` は、Serverless Inference の使用量のトラッキングに使用する `OpenAI-Project` ヘッダーを設定します。 このモデル ID は一例であり、必須ではありません。[利用可能なモデル](https://docs.coreweave.com/products/inference/serverless/models)から、ツール呼び出しに対応したモデルを選択してください。互換性のある別のプロバイダーや、自身でホストしているモデルを使用する場合は、`.env` ファイル内のモデル設定を置き換えてください。`[INFERENCE-HOST]` と `[MODEL-ID]` は、ご利用のプロバイダーの値に置き換えます。 ```bash theme={"system"} MODEL_BASE_URL="https://[INFERENCE-HOST]/v1" MODEL_NAME="[MODEL-ID]" ``` そのプロバイダーのキーをプロセス環境の `MODEL_API_KEY` に読み込み、`CWSANDBOX_API_KEY` は設定したままにしてください。プロバイダーが project ヘッダーを使用しない場合は、コマンドを実行する前に `.env` ファイルから `MODEL_PROJECT` を削除し、継承された `MODEL_PROJECT` 環境変数があればその設定を解除してください。エンドポイントには、サンドボックスからアクセスできる必要があります。`localhost` はお使いのマシンではなく、サンドボックス自体を指します。その他の API プロトコルを使用する場合は、ネイティブ評価器のオプションを調整する必要があります。 このレシピでは、サンドボックスの操作に CoreWeave の認証を明示的に使用します。サンドボックスのトークンはホスト上にのみ保持されます。サンドボックスの作成時に注入されるのは、モデルの設定と推論キーのみです。ジョブの設定には認証情報の値は含まれません。 認証情報の取り扱いに関する詳しいガイダンスについては、[環境変数とシークレット](/ja/products/sandboxes/client/guides/environment-variables)を参照してください。ダウンロードしたログやトレースには、タスクデータやプロバイダーのエラーメッセージが含まれる場合があるため、適切に保護してください。

セットアップチェックを実行する

シンプルなタスクを 1 つ、1 つのサンドボックスで評価します。 ```bash theme={"system"} uv run --env-file .env python run.py \ --task simple.email_sf_contact_phone_update \ --concurrency 1 \ --output results-smoke ``` 出力ディレクトリには、新しいディレクトリを指定する必要があります。Harbor はサンドボックスを起動し、AutomationBench をインストールしてタスクを実行し、結果を収集した後、サンドボックスを削除します。ジョブが完了すると、次のように出力されます： ```text theme={"system"} Harbor ジョブが完了しました。job-result.json とアーカイブ済みの試行を確認してください。 ``` `results-smoke/job-result.json` ファイルを調べて、完了した試行とエラーになった試行の数を確認します。終了ステータスがゼロであれば、エラーのままの試行や欠落している試行が残っていないことを意味します。ただし、モデルがタスクのアサーションに合格したことを意味するわけではありません。ネイティブの `agent/automationbench.json` エクスポートには、`passed`、`score`、実行時間、トークン使用量が記録されます。検証器は、`passed` と `score` を、それぞれ `pass` と `partial_credit` という名前の Harbor 報酬にマッピングします。`job-result.json` では、`stats.evals` エントリの `metrics` の下に、各報酬の試行全体での平均値が記録されます。報酬のない試行はゼロとしてカウントされます。`reward_stats` には、報酬の値ごとに該当する試行がリストされます。 エージェントは、`api` ツールセットを使用し、応答ステップは最大 50、サンドボックスごとに一度に実行するタスクは 1 つで、推論設定にはプロバイダーのデフォルトを使用します。ネイティブのタスク全体の自動修復は無効化されているため、試行の再試行は Harbor が管理します。なお、モデルクライアントが個々のリクエストを内部で再試行することはあります。

並列度を上げる

セットアップの確認が成功したら、まずは小規模なサブセットで試します。 ```bash theme={"system"} head -n 8 tasks-scored.txt > tasks-small.txt uv run --env-file .env python run.py \ --tasks-file tasks-small.txt \ --concurrency 4 \ --output results-small ``` 各試行は 2 vCPU と 4 GiB のメモリをリクエストするため、4 つの試行を同時実行すると最大で 8 vCPU と 16 GiB をリクエストします。Harbor は各タスクを個別にスケジュールするため、あるタスクが終了すると、空いた枠を別のタスクが使用できます。ただし、各サンドボックスで評価器をインストールするので、タスクごとのセットアップによるオーバーヘッドが発生します。 このレシピには、固定されたベンチマークリビジョン用のタスクリストが 2 つ含まれています。 | タスクリスト | タスク数 | 用途 | | - | -: | - | | `tasks-scored.txt` | 600 | 営業、マーケティング、オペレーション、サポート、財務、人事の各分野につき 100 タスク | | `tasks-simple.txt` | 200 | 別途用意されたシンプルなベースラインタスク | 採点対象のセットを評価するには、そのタスクリストと、クォータの範囲内で実行できる同時実行数を選択します。 ```bash theme={"system"} uv run --env-file .env python run.py \ --tasks-file tasks-scored.txt \ --concurrency 16 \ --output results-scored ``` 16 個の試行を同時実行すると、合計で最大 32 vCPU と 64 GiB をリクエストします。これは設定例であり、検証済みのスループット目標ではありません。同時実行数は段階的に増やし、推論の制限とサンドボックスのキャパシティを監視してください。 ベースラインのタスクは、別の出力ディレクトリを指定して実行してください。200 個のシンプルなタスクは、採点済みセットの分母に含めないでください。これらは公開タスクです。AutomationBench の公式リーダーボードでは別の非公開タスクセットを使用しているため、スコアを直接比較することはできません。

キャパシティおよび推論制限による失敗の再試行

このレシピでは Harbor の `RetryConfig` を設定し、元の試行の後に最大 5 回の再試行を許可します。待機時間はそれぞれ 30、60、120、240、300 秒です。再試行の許可リストには、次の例外が含まれます。 * `SandboxResourceExhaustedError` * `SandboxUnavailableError` * `SandboxRequestTimeoutError` * `EnvironmentStartTimeoutError` * `ApiRateLimitError` * `ApiUsageLimitError` Harbor はデフォルトで `ApiUsageLimitError` を再試行の対象外としています。このレシピでは、この例外を除外セットから削除し、許可リストに追加しています。アダプターは、ネイティブの評価器が出力する推論クォータおよび rate-limit の終了メッセージのうち、認識できるものを対応する Harbor の例外にマッピングします。このマッピングはプロバイダーのエラーテキストに依存するため、プロバイダーが異なる形式でエラーを報告する場合は、ログを確認してください。 キャパシティやクレジットが恒常的に不足している場合は、キャパシティやクレジットが利用可能になるまで待つ必要があります。再試行後もエラーが解消しない場合、スクリプトはゼロ以外の終了コードで終了し、最後のエラーを保持します。通常のアサーション失敗、応答拒否、不正な形式のツール呼び出し JSON、エージェントの実行タイムアウトは、再試行ポリシーのトリガーにはなりません。 Harbor は再試行の前に、失敗した試行のディレクトリを削除します。このレシピの試行終了時フックは、削除される前に各試行を結果および利用可能なログとともにアーカイブします。スコアを報告する際は、これらの試行を保持し、インフラストラクチャーの復旧を行ったことを明記してください。モデルの失敗を、再試行で得られたより良い成果に断りなく置き換えないでください。

結果と時間のかかる試行を確認する

各出力ディレクトリには、次のアーティファクトが含まれます。 | パス | 内容 | | - | - | | `job-config.json` | 認証情報の値を除いた Harbor のジョブ設定 | | `job-result.json` | 最終的なジョブ統計とエラー | | `jobs/automationbench/` | 最終的な試行、ネイティブエクスポート、ログ、検証器の報酬 | | `attempts/` | 失敗を含む、アーカイブ済みの試行 | | `sandbox-ids.jsonl` | クリーンアップ用に記録されたサンドボックス ID | タスクの所要時間とトークン使用量は、ネイティブエクスポートで確認してください。このアダプターは、Harbor の集計用エージェントトークンフィールドやコストフィールドには値を設定しません。結果とあわせて、モデル、エンドポイント、ベンチマークのリビジョン、タスクリスト、推論の設定、同時実行数、再試行ポリシーを記録してください。run を停止した場合は、エクスポート済みのタスクのみを完了した評価として報告し、結果が部分的なものであることを明記してください。 ステップ数や出力トークン数が少なくても、モデルの応答時間がタスクの所要時間の大半を占めることがあります。遅延の原因をサンドボックスのリソースと判断する前に、`model_time_s` と `tool_time_s` を比較し、`agent/eval.log` ファイルを確認してください。不正な形式のツール呼び出し JSON をプロバイダーが拒否するのは、モデルまたはプロトコルの障害であり、サンドボックスのクォータ枯渇を示すものではありません。AutomationBench は、ターンの途中で停止したロールアウトをエクスポートの `summary.aborted_tasks` フィールドに列挙します。これらのタスクごとの `errors` 配列は空になる場合があるため、タスクのエラーだけでなく、このフィールドとログも確認してください。 セットアップのタイムアウトは 11 分です。エージェントの実行には別途 45 分のタイムアウトがあり、その中で実行されるネイティブ評価コマンドのタイムアウトは 40 分です。各サンドボックスの有効期間の上限は 1 時間で、タイムアウトに達していなくても上限に達した時点でサンドボックスは終了します。エージェント実行のタイムアウトは、このポリシーでは再試行の対象になりません。

停止とクリーンアップ

フォアグラウンドの run を停止するには、Ctrl+C を押して Harbor が終了するまで待ちます。このジョブでは、ティアダウンのために `delete=True` が設定されています。プロセスが強制終了された場合やクリーンアップに失敗した場合は、残っているサンドボックスを削除する前にローカルのランナーを停止してください。ランナーが動作したままだと、削除したサンドボックスの代わりが作成されてしまいます。 ランナーが停止したら、その出力ディレクトリを使用してクリーンアップが完了したことを検証します。 ```bash theme={"system"} uv run --env-file .env python cleanup.py results-smoke ``` `results-smoke` は、停止したジョブのディレクトリに置き換えてください。このスクリプトは記録済みのサンドボックス ID のみを削除し、それぞれの終端状態を出力します。すでに存在しないサンドボックスは `not_found` と報告されます。終了コードが 0 以外の場合は、削除または終端状態の検証に失敗しているため、原因を調査してください。ホストプロセスが消失した場合でも、設定済みの有効期間の上限によってサンドボックスのライフタイムは制限されます。

検証のスコープ

レシピの開発中、ネイティブの評価器は、Serverless Inference 上の `openai/gpt-oss-120b` を使用して 8 つの CPU サンドボックスで並列実行し、公開タスク 800 件のうち 730 件の結果をエクスポートしました。この run は完了前に停止したため、その結果はベンチマークスコアとして扱えません。Harbor の再試行スケジューリングは別途検証済みです。具体的には、`SandboxResourceExhaustedError` を意図的に注入し、30 秒のバックオフを経て、実際のタスク 1 件が完了し、結果のエクスポートとクリーンアップまで行われることを確認しました。このレシピでは、初期の実験で使用していた環境フックを、公開 SDK の呼び出しを使用する `BaseEnvironment` 実装に置き換えています。このリファクタリングはオフラインテストでカバーされていますが、実際のサービスに対してはまだ実行していません。また、Harbor の同時実行数を高く設定した状態での完全なデータセットの検証も行っていません。 オフラインテストと、省略可能な制御された再試行チェックについては、[レシピの README](https://github.com/coreweave/cwsandbox-recipes/tree/main/recipes/automationbench#test-and-compatibility) を参照してください。