平均精度が隠しているもの

デモでエージェントがタスクをすいすいこなすのを見ると、「これなら本番投入できそう」と思いますよね。ところが同じ質問を投げ直すと結果が変わる、というケースが少なくありません。金融取引の突合や契約書の義務条項チェックのようなミッションクリティカルな業務では、この「たまに失敗」がそのままサービス障害につながります。

問題は、多くのベンチマークがこのばらつきを平均値の裏に隠してしまうことです。IBM Researchの公開資料によると、AppWorld上でGPT-4.1ベースのReActエージェントは5回繰り返し実行で平均77.4%の成功率（Mean@5）を記録しました。しかし5回すべて成功したタスクは53.0%に過ぎません。この24.4ポイントの差が、いわゆる**一貫性ギャップ（Consistency Gap）**です。

💡 用語の整理

  • Mean@k: k回実行した平均成功率。リーダーボードで言う「精度」。
  • Pass^k: k回すべて成功したタスクの割合。ユーザーが体感する実信頼性。
  • Pass@k: k回のうち少なくとも1回成功。コード生成論文でよく使われる楽観的指標。

常に Pass^k ≤ Mean@k ≤ Pass@k が成立します。似た記号ですが、問いかけは正反対です。

これはモデルを大きくすれば解決する問題ではありません。能力（capability）と一貫性（consistency）は直交する軸であり、賢いのにムラがあるエージェントはいくらでも存在します。

根拠資料: IBM Research - ALTK-Evolve Consistency

AI agent reliability dashboard comparing Mean@k and Pass^k metrics on benchmark tasks Technical Structure Concept

なぜエージェントは「反転」するのか：SharpとFlat

エージェントがAPIを選び、引数を渡し、リトライ可否を判断するあらゆる瞬間は、次トークンの確率分布からのサンプリングです。重要なのはその分布の「形」です。

  • Sharp distribution: 単一トークンに確率質量が集中。2位との差が大きく、毎回同じ選択になる。
  • Flat distribution: 複数トークンが近い確率で並ぶ。実質コイントスに近い。

Sharpな分布はGPU浮動小数点の非結合性やリクエストバッチングといったプラットフォームノイズに揺らぎません。一方、Flatな分布はそのわずかな揺らぎで順位が反転します。さらにトラジェクトリは数十の意思決定が連鎖するため、ステップごとの小さな反転確率が累積し、ラン全体が変わる確率が大きくなります。24ポイントのギャップはここから生まれます。

greedy decodingでも防げない理由

Greedy decodingや固定シードは「分布をトークンに変換する方法」を統制するだけで、分布そのものには触れません。ホスト型エンドポイントではランごとに確率がわずかに揺らぐため、temperature 0でも今日はA、明日はBに転び得ます。

診断 → 修正のパイプライン

ステップ1: Consistency Analyzerによる検出

記録済みトラジェクトリ1本を入力し、各意思決定ステップをcontrolled resamplingで再生します。決定ステップあたりモデル呼び出し1回、k=5 completionを一度に取得する方式（デフォルト）で、オフラインで1度だけ実行します。新しいツール呼び出しも、環境相互作用も、エンドツーエンド再実行も不要です。結果はステップごとのconsistency scoreとしてスコアカードに記録されます。完全なブラックボックス — logitsも、モデル内部も、追加計装も不要。既存のトレースだけで動きます。

ステップ2: ターゲット型ガイドラインの生成

フラグされたステップごとに、ALTK-Evolve標準フォーマットのconsistency guideline候補が生成されます。実際にGPT-4.1がAppWorldタスクから生成した例を見てみましょう:

[Guideline 1] ノート本文のチェックボックス風マーカーを数える際は、
単純なsubstring countではなく行アンカー付き正規表現を使うこと。
ノートタイトルに凡例行として同じ記号が繰り返される場合が多い。

[Guideline 2] ノート検索結果は常に複数マッチを確認し、
正しいノートであることを検証してから進めること。

タスク固有の知識ではありません。文字列カウントのバグや未検証の検索結果は、AppWorld全体で不確実性が高く現れる意思決定ポイントです。Analyzerは「失敗」ではなく「不安定さ」を狙います。 今回はたまたま正解したが次回は誤り得るステップを捕まえるのです。

📊 注意: ここで言うガイドラインは、プロンプトエンジニアリングのfew-shot例とは性格が異なります。トラジェクトリから自動蒸留された再利用可能な判断ルールとお考えください。

Consistency Analyzer resampling decision points in an LLM agent trajectory to detect flip-prone steps Development Concept Image

実測結果：ギャップを半減、精度は維持

AppWorld test_normal（168タスク）、GPT-4.1 ReActエージェントで評価しました。タスクごとにベースラインのトラジェクトリ1本からガイドラインを抽出し、新規5ランでテストしています。

指標ベースラインガイドライン適用変化
Mean@5（全体）77.4%81.0%+3.6pp
Pass^5（全体）53.0%69.0%+16.0pp
一貫性ギャップ24.4pp12.0pp-12.4pp
Pass^5（Medium）--+22.9pp (+44%)
Pass^5（Hard）--+14.3pp (+45%)
Pass^5（Easy）--+12.2pp

重要なポイントを整理します。

  • ギャップが半減: Pass^5が53% → 69%に上昇し、Mean@5も77.4% → 81.0%へ。以前不安定だったタスクの約1/3が「毎回成功するタスク」に変わりました。
  • Mean@5は絶対に落とさない: これはnice-to-haveではなくハード要件でした。Mean@5を犠牲にしてPass^5を上げるのは、不安定さを別の場所に移すだけで、解決ではありません。
  • 一般化する: 同一シナリオの別変種タスクに適用してもPass^5が+13.0pp上昇。同タスク数値（+16.0pp）より3ポイント低い程度です。トラジェクトリ1本のパッチではなく、転移可能なパターンを捉えている証拠です。
  • 弱いモデルでより鮮明: gpt-oss-120bでは同タスクPass^5が10.1% → 16.1%（+6.0pp）に上昇し、類似タスク一般化（+8.7pp）が同タスク利得を上回りました。トラジェクトリの暗記ではなく、再利用可能な失敗パターンを捉えたシグナルです。

この技術の限界と注意点

  • 診断コストは無料ではない: 決定ステップあたりLLM呼び出し1回が追加されます。トラジェクトリが長いとコストは線形に増加します。本番トラフィックではサンプリング比率の調整を推奨します。
  • k=5はデフォルト値に過ぎない: タスク特性に応じてkを増やせば診断は安定しますが、コストは比例して増えます。
  • ガイドライン自体が汚染され得る: 誤ったトラジェクトリから抽出したガイドラインは逆効果になり得ます。検出段階の信頼度閾値管理が重要です。
  • ベンチマーク特化のリスク: AppWorldで上手くいったからといって、別ドメイン（例: 社内ワークフロー）で自動的に通用すると仮定してはいけません。

日本の開発現場における適用文脈

日本企業の受託開発や金融システムにエージェントを組み込む場面では、この指標が特に有用です。発注者が求めるのは「平均77%成功」ではなく**「同じ要求に常に同じ結果」**だからです。特に決済・突合・審査のような業務では、たった一度の反転が監査上の問題に直結します。

実務では次の順序を推奨します:

  1. 既存ログからトラジェクトリを20〜30本抽出し、Consistency Analyzerでスコアカードを出してみてください。グラウンドトゥルースなしで動作します。
  2. 上位の不安定ステップを対象にガイドラインを生成し、システムプロンプトまたはRAGコンテキストに注入します。
  3. デプロイ前にA/BでPass^kを比較してください。Mean@kだけ見ていると改善の有無を見落とします。

関連して、AIが生成したコードをそのまま本番に出す際のリスク管理戦略はAI生成コードの本番リスク管理ガイドでより深く扱っています。Kubernetes環境で対話型オブザーバビリティを構築する方法も、エージェント運用の観点で参考になります。

Production server running AI agent workflows with consistency guidelines injected at inference time Dev Environment Setup

本番にエージェントを載せるなら

まとめると次の通りです。

  • Mean@kの隣にPass^kを必ずレポートする。 平均だけでは「安定したエージェント」と「運の良いエージェント」を区別できません。k=3を回すだけでも、知らなかったギャップが見えてきます。
  • 難易度が上がるほどギャップは広がると予想する。 最も難しいティアで、平均値は最も誤解を招きます。
  • より大きなモデルに走る前に一貫性を取る。 一貫性は能力と直交する軸です。より強いモデルはMean@kを上げますが、ギャップを自動的に縮めるわけではありません。
  • 診断にグレーダーもライブリプレイも不要。 決定ステップあたりLLM呼び出し1回（k=5 completion）で十分です。グラウンドトゥルースなし、環境にタスクを投げ直すことなく動作します。本番トラフィックでエンドツーエンド再実行が不可能な状況で使える理由はここにあります。

次のステップ学習方向

  1. 実際に動かす: ALTK-EvolveオープンソースリポジトリにConsistency Analyzerとガイドライン生成コードが含まれています。自分のタスクに組み込んでスコアカードから始めてみてください。
  2. 原著論文を読む: 全体の方法論と評価はarXiv技術レポートにまとまっています。
  3. 評価パイプラインを再設計: 既存ベンチマークがMean@kしかレポートしていないなら、Pass^kを追加するだけでチームの意思決定品質が変わります。

精度の数字が自分のタスクで再現しないなら、それは実力の問題ではなく指標選択の問題かもしれません。まずPass^kを測ってみてください。

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。