新しいプロンプトを1回試して「直った」と喜んだら、翌日の実行では同じ不具合が再発した——AIエージェントの評価でよくある落とし穴です。エージェントの出力は非決定的なため、1回の実行結果だけでは改善したのか偶然当たっただけなのか区別できません。限られた評価予算の中で、何回トライアルを回せば判断材料として十分なのかを設計します。

なぜ1回の実行結果を信用してはいけないのか

LLMエージェントの出力は実行ごとに変動するため、1回の合否判定だけでは改善と偶然を区別できません。

エージェントは同じ入力・同じプロンプトでも、サンプリングのランダム性やツール呼び出しの順序、外部APIの応答タイミングによって結果が変わります。1回だけ実行して「成功したから直った」「失敗したから悪化した」と判断すると、本当は変わっていないのに評価結果だけが上下して見える事態が起きます。これは特にプロンプト変更やモデルのバージョンアップを判断する場面で危険です。1回の成功で本番にリリースし、翌週に同じ不具合で問い合わせが増える——という失敗は、複数回の実行結果を見ていれば避けられたケースがほとんどです。各試行をトライアルと呼び、エージェント評価ではこのトライアルを複数回積み重ねて初めて意味のある判断ができます。

pass@kとpass^kは何を測り分けるのか

pass@kはk回中1回でも成功する確率、pass^kはk回すべてが成功する確率を測る指標です。

Anthropicのエージェント評価に関する技術記事では、複数トライアルの結果を集約する指標としてpass@kとpass^kの2つを提唱しています。pass@kは「k回の試行で少なくとも1つ正解を得る確率」、pass^kは「k回すべてが成功する確率」を表します。使い分けの基準は製品要件です。1回でも成功すれば十分な用途（情報検索ツールの呼び出しなど）はpass@kで評価し、毎回同じ品質が求められる用途（顧客対応の自動応答など）はpass^kで評価します。1回あたりの成功率が75%のタスクで3回連続成功する確率は0.75の3乗で約42%にしかなりません。一貫性を求めるほど合格基準は厳しくなることを、この指標は数値で示してくれます。pass@kの統計的な推定方法は、コード生成モデルの評価で発表された不偏推定量の定義が元になっており、サンプル数が少ないと推定値の分散が大きくなることが知られています。

少ない予算では何回トライアルすればよいか

判断材料として最低3回、リリース可否のような重要な意思決定には5回以上のトライアルを目安にします。

学術的な検証では数百回のサンプリングで分散を抑えることが推奨されますが、中小企業の評価予算でそれを毎回行うのは現実的ではありません。実務では次の目安で十分です。

1. 日常の動作確認（n=3）: 開発中のプロンプト調整や軽微な修正の確認には3回実行し、3回とも結果が一致するかを見ます
2. リリース判断（n=5）: 本番デプロイ前のゲート判定では5回実行し、成功率の差が偶然のばらつきで説明できる範囲かを確認します
3. 境界的な結果は追加実行: 5回中2〜3回成功のような曖昧な結果が出た場合は、判断を保留してさらに3回追加し合計8回で見直します

```python
def should_promote(trials_before: list[bool], trials_after: list[bool]) -> str:
rate_before = sum(trials_before) / len(trials_before)
rate_after = sum(trials_after) / len(trials_after)
diff = rate_after - rate_before

5回中1回分（20pt）未満の差は誤差の範囲として判断を保留

この程度のヒューリスティックでも、1回実行だけで判断するよりはるかに誤判定を減らせます。重要なのは「n=1で決めない」という原則を評価フローに組み込むことです。

CIの回帰テストや本番A/Bテストとどう役割分担するか

多重トライアル設計はリリース前のゲート判定が主戦場で、CIの全件回帰テストや本番A/Bテストとは担当範囲が異なります。

多重トライアルサンプリングは、少量のタスクに対してリリース判断の確度を上げるための手法です。これは次の2つの評価層とは役割が異なります。CIパイプラインに組み込むゴールデンデータセットの回帰テストは、スピード優先で基本1トライアルのまま広いカバレッジを確保する設計です。一方で本番トラフィックを使ったA/Bテストは、十分な母数が自然に集まるため個別タスクの複数トライアルは不要です。多重トライアル設計が必要なのは、この2層の間にある「少数の重要タスクについて、限られた手動実行回数でリリース可否を決めたい」という場面です。既存の回帰テストやA/Bテストの仕組みを持つチームでも、リリースゲートとなる重要タスクだけはn=5のトライアル設計を追加することで、判定の信頼度を補強できます。

参考

• Demystifying evals for AI agents — Anthropic Engineering
• Evaluating Large Language Models Trained on Code — arXiv:2107.03374

まとめ

AIエージェントの評価を1回の実行で済ませると、改善と偶然の区別ができず誤った判断につながります。

1. 1回の実行結果では判断しない: エージェントの出力は非決定的であることを前提に評価フローを組む
2. pass@kとpass^kを用途で使い分ける: 1回成功で十分かすべて一貫して成功すべきかで指標を選ぶ
3. 日常確認はn=3、リリース判断はn=5が目安: 曖昧な結果は追加トライアルで判断を保留する
4. CI回帰テスト・本番A/Bテストとは役割が別: 多重トライアルは少数の重要タスクのリリースゲートに充てる

限られた評価予算でも、トライアル回数の設計ひとつで判定の信頼度は大きく変わります。評価基盤の設計からKuu株式会社のエージェントAI運用管理サービスでご相談いただけます。