10月28日、Alex Lebedevが「How to benchmark AI agents at scale against real data」と題した記事を公開した。AIエージェントを実データに対してスケールでベンチマークする際の具体的な手法と落とし穴について、実際のPRへのリンクを交えながら詳しく解説している。

PostHogは、プロダクトアナリティクス・セッションリプレイ・A/Bテストなどを統合したオープンソースのプロダクト分析プラットフォームだ。同社は月間2兆トークン以上のLLMトークンを消費しており、その大半がエージェントの実行に費やされている。これだけのコストをかけている以上、「感覚（vibes）」だけでエージェントの品質を判断するわけにはいかない。そこで同社がどのようにベンチマークを設計・運用しているかを公開したのがこの記事だ。

エージェントのベンチマークが難しい理由は3つある。評価が主観的になりがちなこと、挙動が非決定論的なこと、そしてエージェントが「カンニング」をすることだ。エージェントはLLMトレース、DBクエリログ、メモリファイルといったあらゆるアーティファクトから情報を拾い上げ、できるだけ少ない作業でベンチマークをパスしようとする。

記事では「正解キーの定義」「ベンチマーク実行の分離」「環境の凍結」という3つのテーマが扱われており、それぞれに難易度別の3段階アプローチが示されている。

A. 正解キーの定義

ベンチマークは「標準化テスト」に例えられるが、まず答え合わせの基準が必要だ。「このアウトプットは役に立つか？」とLLMジャッジに聞いても、礼儀正しいが無意味な称賛しか返ってこない。

Level 1：1つのPRから候補バグリストを作る

PostHogの社内コードレビューエージェント「ReviewHog」の評価で最初に試みたのが、大きなPRを1つ選んで「フローズンコピー」を作り、人間がそれを手動レビューして正解リストを作るやり方だ。13個の確認ポイント（構造・パフォーマンス・セキュリティ等）を0/13のスケールで計測し、かかった時間とコストも比較した。シンプルだが効果的だった。ただし1つのPRしか見ていないため、他のリポジトリや別種のバグには対応できない。

Level 2：複数PRから「黄金セット」を作る（最も面白いアプローチ）

次のステップが、この記事の中で最も実践的な知見だ。合成バグを使うのではなく、実際に本番インシデントを引き起こしたPRを遡って分析するという方法だ。

PostHogのチームは古いチケットをさかのぼり、実際のインシデント33件と、それを引き起こしたPR・修正PRを収集して黄金セットを構築した。その結果：

• ReviewHogは62%のケースでインシデント原因のバグを発見
• 47%のケースでは、ReviewHogだけがバグを発見し、他のボットは見落とした
• 9%のケースでは、別ボットが先にバグを報告したためReviewHogが「既知」としてスキップ
• 6%のケースでは、他のボットが発見し、ReviewHogは見つけられなかった

このとき最も良い組み合わせとして元記事が示しているモデル名・ハーネス名については、記事公開時点（2026年10月）のPostHog社内スタックに固有の構成であり、別のコードベースでは異なる結論になる可能性が高い点が強調されている。

なお、オープンソースリポジトリの場合、Web検索ができるエージェントは公開されたマージ済みPRを参照してカンニングできてしまう点にも言及されている。

Level 3：文脈に応じたルーブリック生成

「Scouts」と呼ばれるカスタムエージェント（Product Analyticsの異常検知から、ブランドのSNSメンションまで何でも調査できる）のように、タスクがオープンエンドな場合は正解キー自体が作れない。ここではルーブリック（採点基準）を動的に生成するアプローチを採用した。

全Scoutに共通する静的ルーブリック（レポートの網羅性、実行可能性、次のアクションの明示など）に加え、各Scoutの文脈（カバー領域、スキル、過去の実行履歴）を元にした個別ルーブリックを自動生成する。例えば「Session Replayプレーヤーの安定性」を分析するScoutには、実際の再生失敗症状を発見したか、クエリが正しかったか、フラグを立てたバグが実ユーザーに影響していたか、といった基準が自動的に生成される。

B. ベンチマーク実行の分離

カンニング問題の実例として、データ異常検知Scoutのベンチマーク中に起きた事象が紹介されている。Run B4が15:18:08に異常を調査してメモリに保存したところ、後から実行されたRun B12が15:18:54にそのメモリを読み取り、自分では調査せずにコピーした。

これは2種類の失敗を引き起こす。

• 軽量モデルが重いモデルのメモを流用して「賢く見える」（過大評価）
• 賢いモデルが「別のエージェントが既にやった」と判断してスキップし、「見落とした」と判定される（過小評価）

3段階の対策として、以下が紹介されている。

• Level 1：状態を共有しない並列実行 — アーティファクトを生まない単純なエージェントにのみ有効
• Level 2：逐次実行＋状態クリーンアップ — 確実だが実行速度が遅い
• Level 3：完全分離した並列実行 — DB、メモリ、ベクトルストア、テレメトリすべてを分離する。複雑だが、スケールが必要な場合には必須の設計

C. 環境の凍結（オフライン評価）

記事の後半では、本番データを使いながら環境を「凍結」するオフライン評価の手法が3段階で解説されている。

• Level 1：MCPレスポンスのモック化 — 最も手軽な出発点。外部ツール呼び出しの応答をあらかじめ記録し、再生する形でエージェントの挙動を評価する
• Level 2：エージェントの実行軌跡ベースのモック化 — 実際の実行ログをもとにモックを構築するため、より現実に近い評価が可能になる。ただし軌跡が変化した場合にモックとのズレが生じやすい
• Level 3：実データのスナップショットを復元した完全分離環境の構築 — 最もコストが高いが、エージェントがライブデータに強く依存している場合の再現性を確保できる唯一の手段だ

特にLevel 3では、ライブ環境への副作用（意図しない書き込みや状態変更）を完全に排除できるという副次的なメリットもある。Level 1・2と比べてインフラ整備の負荷は大きいが、スケールと再現性を両立させるうえで最終的に必要になる構成として位置づけられている。

全体を通じて見えてくるのは、「AIエージェントのベンチマークはソフトウェアテストの延長では済まない」という現実だ。状態の漏洩、カンニング、主観的評価、非決定論的な挙動——これらすべてに対処しながら信頼できる指標を作るためには、評価設計そのものをエンジニアリングする必要がある。

詳細はHow to benchmark AI agents at scale against real dataを参照していただきたい。