エージェント用サンドボックスの採算を「使える成果」で測る

Modalは2026年10月19日、競合負荷下のVeraで同等のx86 GNRに対し最大2倍のサンドボックスタスク処理量を報告した。同社のベンチマーク結果であり、一般的な保証ではない。Modalの発表

購入側が次に問うべきなのは、ハードウェアの成績がどのように運用成果へつながるかだ。以下はOMNの分析である。合意した時間内に完了し、受け入れ基準を満たしたタスクの総費用を比べる。プロセッサーの順位だけでは、この判断はできない。

まず分母を決める

仮に、2台のサーバーの費用が1時間当たり4ドルと6ドルで、合格タスクをそれぞれ800件と1,200件処理するとする。どちらも1件当たり0.5セントだ。後者は容量が大きいが、単価は下がっていない。後者で期限を満たすのが900件だけなら、条件を満たす成果1件の費用は約0.67セントに上がる。これは計算例であり、製品価格や実測結果ではない。

受け入れ条件は比較前に決める。コーディングなら、テストに合格し、使える修正を作ること。データ処理なら、出力が完全で、所定の形式に合うことなどだ。再試行は実行回数の追加であって、納品件数の追加ではない。失敗した試行の資源消費は費用に含め、成功した成果には数えない。

こうすれば、議論の中心は機械の動作量から、組織が必要とする結果へ移る。忙しく動くサーバーが、割安なサーバーとは限らない。

タスク構成を固定する

公開されているAgentless Agent Benchは、ネットワークを使わない事前起動済みの正解手順50件を使い、検証済みの完了を数える。モデル応答の待ち時間は除外する。ベンチマークのリポジトリ

これは推論の品質を測る試験ではない。購入判断の試験では、モデル、プロンプト、タスク構成、成功条件、ツール権限を変えず、実行環境だけを変える。そうしないと、推論や仕事の選び方の違いをハードウェアの改善と取り違えかねない。

タスクの重み付けにも注意したい。短い確認が多数あり、長いビルドが少数ある仕事を考える。あるホストは確認を多く終えても、ビルドをすべて期限に遅らせるかもしれない。総件数とともに種類別の結果を示し、重要な仕事には個別のサービス目標を置く。簡単なタスクの大量完了で、重要な仕事の失敗を隠してはならない。

役に立つ同時実行の限界を探す

起動できるサンドボックス数より、仕事の流入を段階的に増やし、サービスの約束を守れなくなる地点を調べるほうが有用だ。各段階で合格率、中央値の待ち時間、高パーセンタイルの待ち時間、総費用を記録する。1日の平均だけでなく、繁忙時を試す。

有効な容量とは、合意した条件をすべて満たせる最大の持続的な到着率である。実運用ではその境界より低いところに余裕を残す。入念に準備した1分間のピークを処理できても、長く続く負荷増加、ホスト障害、環境の再構築が重なる状況に耐えるとは限らない。

比較は2つに分ける。同じ予算で得られる合格成果の数と、同じサービス品質に必要な予算だ。前者は購買力、後者は費用を測る。分けて考えれば、価格の高い性能プランをコスト削減と呼び違えにくい。

課金と待ち行列を一緒に見る

Modalの資料では、サンドボックスは要求資源と実使用量の大きいほうを基準に課金される。資源の資料

したがって、試験にはハードウェアだけでなく課金方式も含める。実際の請求基準、メモリー、ストレージ、ネットワーク、使われていない予約容量を記録する。処理量の改善を、想像上の値引きに置き換えてはいけない。提供側の運用効率が上がっても価格は下がらない場合があり、利用側の応答が速くなっても請求額は減らない場合がある。

Linux PSIは資源による停止時間を測る。カーネル資料 タスクの時刻記録と照合してホストの資源圧力とアプリケーションの遅延を分け、その区別が期限超過の予測に役立つかを確かめる。

容量の利益と現金の利益を分ける

グラフ上の容量増加は連続的でも、サーバー購入や一部の契約は小数単位に分けられない。ピーク時の目標を満たすために3台必要なサービスを考える。新構成が理論上の必要台数を2.5台へ減らしても、実際には3台分の支払いが残るかもしれない。課金単位を本当に減らす、他の仕事をまとめる、契約を変えるときに初めて現金の節約になる。これも例示であり、特定事業者の契約を説明するものではない。

効果が次の増設を先送りする形で現れる場合もある。それには価値があるが、今月の請求額削減とは別の項目にする。どの需要水準で利益が得られ、基盤運営者、アプリケーションチーム、最終顧客の誰が受け取るのかを書く。そうしなければ、技術側の効率改善が、財務側で実現済みの節約と誤解される。

不確実性の幅も残したい。代表的な複数の運用期間で比較を繰り返し、最良の1回で予算を組まない。需要や合格率の小さな変化で購入判断が逆転するなら、契約規模を小さくして証拠を増やす。堅実な判断は、楽観的な前提がすべて同時に成立することを必要としない。

移行費用も判断に入れる

ハードウェア変更には実装費用がある。イメージと依存関係の検証、成果物の再ビルド、出力の照合、試験中の混在環境の維持にはエンジニアの時間が必要だ。珍しい依存関係が重要なタスクを止めるなら、平均成績がよくても、その例外は判断材料になる。

現実的な評価期間に見込む合格タスク数で、移行費用を割り振る。閑散時も確認したい。高稼働率では割安な容量でも、需要が少なく不規則なら購入に見合わないことがある。すべての仕事を同じホスト形式へ移す必要はない。

段階的な導入は選択肢を残す。入力と受け入れ条件が明確な種類の仕事から始め、対照群と比較する。費用全体と遅い側の処理時間が継続して条件内に収まってから範囲を広げる。開始条件と同じくらい、撤退条件も明確にする。

購入判断に必要な4項目

再現可能なタスク構成、失敗や未使用の契約容量を含む費用範囲、品質と時間の基準、元に戻す手順を求める。得たい効果が容量増加なのか、請求額削減なのか、納品の高速化なのかも明記する。これらは同時に得られる場合があるが、互いの代わりにはならない。

より重要なのは、実行基盤をエージェント製品と同じ成果に結び付けて評価することだ。期限内に渡せた、使える仕事を数える。その数が総費用より速く増えたとき、経済的な改善が成立する。それまでは処理量の結果は、厳密な試験を始める理由であって、翌四半期の予算に削減額を書き込む理由ではない。