数カ月前、私のチームはクラウドブラウザインフラプロバイダーを信頼性、レイテンシー、コストで比較するオープンソースのベンチマーク「Browser Arena」を公開した。私の会社は1位にランクインしている。これは偶然ではなく、その理由について語りたい。
数値を操作したからではない。このベンチマークはオープンソースで再現可能であり、誰でも実行すれば同じ結果が得られる。問題はもっと根本的なところにある。このカテゴリーのベンチマークはすべてベンダーによって公開されており、どのベンダーのベンチマークもそのベンダーを1位に位置づけているのだ。カテゴリー全体の実際のベンチマークを見れば、このパターンは容易に見つけられる。名指しはしないが、パターンは明白だ。あるベンチマークでは速度、別のベンチマークでは信頼性、また別のものではステルス性、さらに別のものではコールドスタートが優位性を決める指標となっており、いずれの場合もルールを設定した者がリーダーとなっている。もちろん私たちのベンチマークでは、加重合成スコアで私たちがリードしていることになっている。
これらの結果はいずれも不正ではない。すべて実在するものを測定している。だが、いずれも異なるものを測定しており、何を測定するかの選択こそが、誰が勝つかを決めるのだ。
異なるベンチマーク、異なる問い
公開されている4つのベンチマークが実際に何を測っているのかを考えてみよう。
あるベンダーは、数千回の実行を通じて最小限のライフサイクル、すなわち作成、接続、ナビゲーション、解放にかかる時間を測るリモートブラウザーのベンチマークを公開した。公開された数字では、そのベンダーは競合よりも大幅に高速だった。しかし当初の比較対象は不完全だった。後に2社のプロバイダーが追加されると、いずれも当初の首位企業より速い結果を示した。このテストは1つの問いにはうまく答えている。ブラウザーをどれだけ速く起動し、停止できるか、という問いである。同時に、その答えは誰が比較対象に含まれているかに左右されることも示している。
別のベンダーは異なるアプローチを取った。同じベンチマークの変種を第三者機関に依頼して実施させ、そのスポンサーが1位にランクインする結果を得た。そして彼らはその結果を軸にマーケティングを展開した。オリジナルと同様に、当初の対象は狭く、後から追加されたプロバイダーは公開されたリーダーを上回る結果を出した。スポンサー付きベンチマーク自体が本質的に無効というわけではないが、通常のインセンティブを逆転させる。数値を出す会社が、ランクインされる会社の1社から報酬を得ているのだ。加えて、読者はその関係性を、結果ほど明確に認識することは稀だ。
3つ目のベンダーは、さまざまなサイトにおける数千件の本番環境のセキュリティチェックイベントを基にしたステルス性のベンチマークを公開し、プロバイダーがアンチボット検知をどれだけ回避できるかでスコア化した。そのベンダーのクラウドサービスが首位に立っている。方法論には現実的な批判の余地がある。私たちが自分たちで実行したところ、実行ごとのばらつきが大きかったため、その数字は安定した順位というより、ある時点のスナップショットを捉えている可能性が高い。それでも、問いは鋭い。ブラウザーはそもそもボットとしてフィンガープリントされることを回避できるのか、という問いである。
私たちが構築したBrowser Arenaは、1,000回の逐次実行および並列実行を通じて、信頼性、レイテンシー、コストを重み付けした複合指標で全プロバイダーを採点する。重みは調整可能で、購入者は自社の優先順位をモデル化できる。この重み付けこそが、私たちの方法論が私たちに有利に働き始める点である。
方法論が主張に変わるとき
ベンダーのベンチマークに欠陥が指摘されたとき、例えば、あるプロバイダーが不利な条件でテストされていた、競合が除外されていた、といった場合、公正な期待は、作成者がその指摘に向き合うことだ。そうしなければ、誰もが記憶するのは当初の順位である。
私はこのカテゴリー全体で、こうしたことが起きるのを見てきた。あるベンチマークは、公開者に有利に働く条件で競合をテストし、修正すれば首位を失うような指摘には応答しない。別のベンチマークは外部からの貢献を拒むため、比較対象は公開時に作成者が選んだもののままになる。いずれにせよ、数字は公開され続ける。
私たちは、この2つの落とし穴を避けるためにベンチマークを構築した。各プロバイダーは、自社のインフラから最大限の性能を引き出せる条件でテストされ、誰でも手法に貢献したり異議を唱えたりできる。私たちは複数のスコアリング関数を提供している。それを変更すれば、別のプロバイダーが首位に立つ。誤解しないでほしい。これは依然として私たちのベンチマークである。それでも少なくとも、内部をのぞき、変更し、私が間違っていることを証明できる。
購入者が本当に測るべきもの
公開ベンチマークは、どのプロバイダーが自社のユースケースに合うかを教えてはくれない。重要な軸は、ワークロードに完全に依存するからだ。あるプロバイダーはコールドスタートでは最速でも、対象サイトの半数で失敗するかもしれない。ステルス性のランキングで首位でも、大量処理には遅すぎるかもしれない。時間当たりでは安くても、成功したタスク当たりでは高くつくかもしれない。だからこそ、自分たちが実際に重視するワークフローに対して、自分たちでテストを実行しなければならない。
• 対象サイトから始める。 エージェントが本番環境でアクセスするドメインから、実際のURLをいくつか選ぶ。保護されたサイトにアクセスするなら、それらを含めるべきだ。主に自社インフラにアクセスするだけなら、基本的な接続テストでは何も分からない。
• パイプライン全体を測定する。 ナビゲーションが止まったり、抽出に失敗したりするなら、高速なコールドスタートにはほとんど意味がない。重要なのは、「タスク開始」から「有効な出力を伴うタスク完了」までの時間である。
• 実際の同時実行数でテストする。 50または100の同時セッション下での性能は、1セッション時の性能とはまったく異なることがある。ワークロードがバーストするなら、そのバーストを測定すべきだ。
• 時間当たりではなく、成功したタスク当たりのコストを追跡する。 価格が半分でも失敗率が2倍のプロバイダーは、完了タスク当たりでは同じコストになる。再試行のためのエンジニアリングを含めれば、さらに高くなる。請求額を、利用可能な出力を伴って完了したタスク数で割ることだ。これにより、時間単価では隠れてしまう信頼性の問題が浮かび上がる。
• テールを見る。 平均値は良くてもP99（99パーセンタイル・レイテンシー）が悪いプロバイダーは、デバッグが難しい問題を継続的に生む。エージェントのワークフローでは、テールレイテンシーが中央値よりもユーザー体験の品質をよく予測することが多い。
これからの道筋
ブラウザーインフラのカテゴリーはまだ初期段階にあり、その中のプロバイダーは実際の技術的選択を行っている。コールドスタートに最適化するものもあれば、ステルス性に最適化するもの、コストに最適化するものもある。ベンダーのベンチマークは、そうした選択を浮かび上がらせる。判決ではない。
今日、ブラウザーインフラを評価しているなら、あなたが費やせる最も価値ある1時間は、私のものを含め、別のベンチマークを読むことではない。実際の本番ワークロードに似た、小さく再現可能なテストを構築し、それを2、3社のプロバイダーに対して自分で実行することである。
