数値の帰属を訂正しました（2026年10月7日）。旧稿の「6,259件・450万回・本番成功率56.6%・約37ポイント差」は、引用した arXiv:2602.16666 v3 の実験条件・結果として裏づけられません。導入判断の根拠に使わないでください。既存タイトルの「9割、本番6割」も検証済みの一般則ではありません。 見出しに残る表現と、今回確認した根拠を区別してください。訂正内容は説明文・本文・全FAQにも示しています。
30秒で要点
- 引用先v3は15モデル、GAIAの165課題、τ-bench airlineの26課題を使った評価です。数千の実運用エージェントを追った調査として紹介していた旧説明を訂正します。
- ベンチマークは条件をそろえた比較に役立ちます。自社の成功率へ読み替える前に、タスク・分母・実行条件・成功判定を確かめます。
- 一貫性・頑健性・予測可能性・安全性を分けて記録し、小規模な試行と本番導入の資格を混同しません。
引用先で確認した範囲を、旧主張と分ける
表が収まらない場合は、横にスクロールできます
| 旧稿の説明 | 今回の扱い |
|---|---|
| 6,259件の実運用エージェント、450万回の実行 | 引用先v3の実験対象の説明とは一致せず、根拠から外す |
| 本番成功率56.6%、内部評価との差37ポイント | 同論文に基づく自社・市場の成功率として使わない |
| プレプリントで査読状況不明 | arXivメタデータには「Accepted at ICML 2026」と記載。本文の適用限界は別に確認 |
| 2026年4月のBerkeley報告で主要評価がほぼ満点 | 旧稿の記述に対応する一次資料を今回同定できず、事実として採用しない |
2026年10月7日にv3のHTMLと書誌情報を再読しました。公開抄録は信頼性を一つの成功率へ圧縮せず、整合性・頑健性・予測可能性・安全性の4軸に12の指標を置く枠組みとして説明し、メタデータにはICML 2026採択の記載があります。採択や指標の存在は、自社業務の安全性や本番成績を保証しません。
この訂正は「逆に本番でも高精度だ」と証明するものではありません。誤った根拠を外したうえで、何を測って自社の判断をするかを整理します。
比較する前に、分母と成功条件をそろえる
表が収まらない場合は、横にスクロールできます
| 用語 | この本文での使い方 | 確認する条件 |
|---|---|---|
| ベンチマークスコア | 決められた課題集合と採点方法で得た値 | データ版、ツール、モデル版、試行回数 |
| 自社のタスク成功率 | 定義した業務タスクが成功条件を満たした割合 | 人の介入を含めるか、期限、やり直し、費用 |
| 一貫性 | 同じ条件で繰り返した結果の安定性 | 平均だけでなく各回の成否 |
| ゲーム可能性 | 採点規則への適合と実際の達成がずれる問題 | 成功判定の独立確認と抜け道の有無 |
同じ「90%」でも、初回だけの値か、何度も試して最良を採った値かでは違います。回答を作れたことと、正しい外部処理を期限内に完了したことも別です。入力表記、権限、遅延、欠損データを含む自社の条件を定義せず、ベンダー資料の値をそのまま目標へ移さないでください。
架空例：14回成功しても、全回成功は4課題
以下は分母の違いを学ぶための著者の架空データです。実エージェントの性能、論文の結果、タイトルの数値を検証したデータではありません。
表が収まらない場合は、横にスクロールできます
| 課題 | 1回目 | 2回目 | 3回目 | 3回とも成功 |
|---|---|---|---|---|
| A | 成功 | 成功 | 成功 | はい |
| B | 成功 | 成功 | 成功 | はい |
| C | 成功 | 成功 | 成功 | はい |
| D | 成功 | 成功 | 成功 | はい |
| E | 成功 | 成功 | 失敗 | いいえ |
実行を分母にすると14 / 15 = 約93.3%。課題を分母に「3回とも成功」を数えると4 / 5 = 80%です。どちらかだけが正しいのではなく、問いが違います。少数の架空例から将来の失敗率や統計的な精度は推定しません。Eの失敗が外部送信の誤りなら、平均値が高いから許容するという扱いもできません。
精度以外に見る四つの軸
表が収まらない場合は、横にスクロールできます
| 軸 | 観察するもの | ベンダーや自社への質問 |
|---|---|---|
| 一貫性 | 同じ条件の各回の成否と出力 | 再試行を含む平均か。各回のログはあるか |
| 頑健性 | 表記・順序・欠損・ツール障害での変化 | 条件を変えた同じ課題でも成功判定は同一か |
| 予測可能性 | 失敗・不確実さの申告と実際の成否 | 自信の表現は検証したか。保留は正しく数えたか |
| 安全性 | 不許可の操作、誤送信、被害の広がり | 権限、上限、確認者、停止・復旧の手段は何か |
四軸は結果を整理するための見取り図です。自信のある文章だけで予測可能性が高いとはみなしません。安全性は他の高得点で帳消しにする項目にせず、許されない操作を具体的に定義します。答えを即答できないベンダーを断定的に評価するより、提示できる証拠と未検証の範囲を書面で確認するほうが有用です。
導入前の四手順：小さな試行から確認事項を見つける
次は著者の探索的な進め方です。論文の実験手順の再現でも、3回試せば安全を証明できる基準でもありません。
- 自社に近い課題を5〜10件選ぶ。 正常例だけでなく不足情報も含め、成功条件・人の介入・費用・時間上限を先に書く。秘密情報を含まない検証用データを使う。
- 各課題を同一条件で3回ずつ試す。 各回の成否と理由を残す。失敗を再実行で上書きせず、最初と再試行を分ける。
- 入力の表記や順序を変える。 意味が同じかを人が確認し、何を変えたときに成否が変わったかを記録する。
- 曖昧さや例外を与える。 不明点を確認するか、不許可の操作を保留するかを見る。外部へ実送信しない隔離環境から始める。
この段階の成果は「任せてよいと証明したこと」ではなく、追加すべき課題と確認手順の発見です。重大な意思決定や不可逆な操作には、件数を増やすだけでなく認可・人の確認・監視・復旧の設計が必要です。
評価記録を導入判断へ戻す
表が収まらない場合は、横にスクロールできます
| 残す欄 | 書く内容 |
|---|---|
| 条件 | 課題ID、入力版、モデル・ツール・権限、実行時点 |
| 成功定義 | 何を達成し、何をしてはいけないか |
| 各回の結果 | 成否、保留、介入、費用、時間、失敗理由 |
| 採用範囲 | 使う業務、必須の人の確認、追加評価が必要な条件 |
すでに導入して困っている場合はAIエージェントの失敗パターン、構成の違いはAIエージェントの種類、準備全体は導入チェックリストで確認できます。本記事は、それらへ進む前に「この数値は何を数えたものか」をそろえるためのものです。状況を整理するツールも論点整理の補助であり、評価試験や安全性の証明の代わりにはなりません。