生成AIにコード解析のような判断業務を一発で任せると、Uberの実測では誤検知が8割を超えました。複数のLLMに相互検証させ、さらに人が確認する二段構えにして、ようやく10%台前半まで下がっています。「AIが下書き、別系統が検証、人が最終確認」という設計にしない限り、検査業務はAIに載りません。
Uberが公開した実測値は何を測ったものか
Uber Engineeringが、同社のGoコードから性能上のアンチパターン（非効率な書き方）を検出するツール「PerfInsights」の運用実績を公開しました（出典：Uber Engineering（著者: Ryan Hang、Sung Whang、Joseph Wang ほか1名以上）、2025-07-22、https://www.uber.com/us/en/blog/perfinsights/）。
最初に前提を明示します。この記事はUber社自身による発表であり、同社は当該ツール（PerfInsightsおよびLLMCheck）の開発者かつ運用者本人です。掲載されている数値はすべて自社計測・自社推計であり、第三者による検証や外部監査は行われていません。読者は「製品の提供者が自社製品の効果を報告している」という前提で数字を読む必要があります。
そのうえで、公開された数字はAIに検査業務を任せたい企業にとって珍しく具体的です。特に「LLM単体だと誤検知がどれだけ出るか」を実運用ベースで開示した点に価値があります。多くのベンダー発表が成功後の数字だけを出す中で、導入前の状態が語られているためです。
誤検知8割超から10%台前半へ、何を挟んだのか
PerfInsightsの中核は、LLMにコードを読ませて性能上の問題箇所を指摘させる仕組みです。ところが初期段階では、LLMが挙げた指摘のうち8割超が誤検知でした。10件指摘されたら8件は的外れという状態で、これは実務に載せられる水準ではありません。
Uberが導入したのは、単一のLLMの出力をそのまま信じない設計です。具体的には、複数のLLMに同じ検出結果を評価させる「jury of LLMs（LLMによる陪審）」方式と、二重のバリデーション工程を挟みました。その結果、誤検知率は10%台前半（原文では low teens）まで下がっています。
| 指標 | 導入前 | 導入後 | 条件・注意点 |
|---|---|---|---|
| アンチパターン検出の誤検知率 | 80%超 | 10%台前半 | 分母は「PerfInsightsが検出したアンチパターン件数」。コード全体・サービス全体ではない。自社計測、外部検証なし |
| 検証済み検出件数（日次） | 265件（2025年2月・日平均、単日最高500件） | 176件（2025年6月） | 4か月で33.5%減。対象はUberのGoモノレポ |
| 1件あたりの検出・修正工数 | 14.5時間 | 約1時間（93.10%削減） | 「約1時間」はツールの実行時間。14.5時間は年間267件換算からの逆算で、実測タイムスタディではない |
| 年間削減見込み | — | 約3,800時間／年 | 4か月で89件減の実績を年換算（267件）した将来推計。計上済みの実績ではない |
| ハルシネーション発生率 | — | 80%超の削減 | LLMCheckダッシュボード導入による自社計測。削減前後の絶対率、分母件数ともに非開示 |
対象範囲は、UberのGoモノレポ内の自社保有サービスコードです。オープンソース依存と内部ランタイム関数は検出対象から明示的に除外されています。上位10のGoサービスが主な対象で、期間は2025年2月から6月までの4か月間です。
中小企業にとって、この数字はどこまで使えるのか
「で、うちに関係あるのか」に答えます。関係するのは設計原則であって、削減時間の絶対値ではありません。
使える部分は明確です。
- LLMに検査・チェック業務を一発で任せる設計は、誤検知8割超という水準から始まる可能性が高い
- 複数モデルによる相互検証を挟むと誤検知は大きく下がるが、それでも10%台前半は残る
- 残った誤検知を吸収するのは人の確認工程であり、人を外す前提の設計は成立しない
- 検出件数そのものが4か月で33.5%減っている。検査ツールは「見つける」だけでなく「問題の発生自体を減らす」方向に効く
この構造は、請求書チェック、図面確認、原稿校正、契約書のリスク条項洗い出しといった中小企業の検査工程にそのまま移植できます。AIが下書きを作り、別の系統が検証し、人が最終判断する。工程を3つに割るだけで、AI単体運用より精度が上がるという実測が一つ増えたと理解してください。評価の設計そのものについては自社の評価基準を先に作る話も併せてご覧ください。
一方、使えない部分もはっきりしています。年間3,800時間という削減見込みは、Uberという超大規模テック企業のコードベース規模とエンジニア単価を前提にした推計です。従業員数十名規模の会社がこの数字を自社に当てはめると、事実誤認になります。参照すべきは「93.10%削減」という比率でもなく、「単体では使えない、二段構えなら使える」という構造の方です。
この発表が語っていない限界
誠実に書きます。この記事には、読者が割り引いて読むべき点が複数あります。
- 失敗と未解決課題の記述がない。初期の問題は「Early iterations suffered from noisy, inconsistent outputs（初期は出力がノイズだらけで一貫性がなかった）」と過去形の克服談として書かれており、現時点で残る限界の記述がありません。都合の悪い結果は基本的に開示されていないと見るべきです
- 精度の表現に幅がある。誤検知率「10%台前半（low teens）」は正確な数値ではありません。11%と19%では実務上の意味がまったく違います。ハルシネーション「80%超削減」も、削減前後の実数が非開示です
- 主要な数字が推計。14.5時間も3,800時間も実測ではありません。3,800時間は4か月の実績（89件減）を年換算した将来予測であり、実現済みの削減実績ではありません
- 93.10%削減の比較対象が揃っていない。「約1時間」はツールの実行時間であり、検出結果を人が確認・修正する時間を含まない可能性が高いです。人の作業時間と機械の実行時間という性質の異なる量を並べている疑いがあります
- 再現に必要な情報が欠けている。検証に使用したLLMの具体的なモデル名も、陪審を構成するモデル数も開示されていません。同じ手法を他社が再現できるだけの情報は記載されていません
- 実績はGoのみ。「言語非依存の設計」とは述べていますが、示された実績はUberのGoモノレポに限定されます。しかも自社保有コードのみで、オープンソース依存と内部ランタイム関数は除外されています
複数モデルを組み合わせる設計は、当然ながらモデル呼び出し回数の増加を意味します。1件の判定に何回LLMを呼ぶかで運用費は変わりますが、この記事にコストの記載はありません。判定の精度と費用の釣り合いについてはコストを含めた評価の考え方が参考になります。
TOEの読み筋
TOEでは未実施です。PerfInsightsは公開されたツールではなくUber社内基盤であり、同一構成を外部が再現することはできません。以下は公開情報からの読み筋であり、当社での検証結果ではありません。
そのうえで、中小企業がこの発表から取り出すべきは次の3点だと考えます。
第一に、AI導入の失敗パターンが一つ確定しました。「AIに判定させて、そのまま結果を使う」設計です。Uberほどの技術力とデータを持つ組織でも、単体運用では誤検知8割超から始まっています。自社で試して精度が出なかったとき、原因はモデル選定より工程設計にある可能性を先に疑うべきです。
第二に、検証工程は必ずしも高価ではありません。同じ入力を別のプロンプト・別のモデルに投げ、判定が割れたものだけ人が見る。この程度の構成でも、全件を人が見る運用より工数は減ります。中小企業が真似られるのはこの粒度です。
第三に、期待値の置き方です。誤検知が10%台前半まで下がっても、10件に1件強は間違っています。「人の確認をなくす」ゴールを設定した瞬間にこのプロジェクトは失敗します。設定すべきは「人が見る件数を減らす」です。導入の第一歩の考え方は中小企業の最初の一歩にまとめています。
最後に一点。この記事の数字は、提供者自身が自社製品について語ったものです。数字の方向性は参考になりますが、絶対値を自社の稟議資料に転記することは勧めません。自社で小さく計測した数字の方が、他社の大きな数字より意思決定には役立ちます。
まとめ
- Uberの実測では、LLM単体によるGoコードのアンチパターン検出は誤検知率が80%超だった（対象：UberのGoモノレポ内の自社保有コード、オープンソース依存と内部ランタイム関数は除外）
- 複数LLMによる相互検証（jury of LLMs）と二重バリデーションを挟むことで、誤検知率は10%台前半まで低下した。ただし「low teens」という幅のある表現で、正確な値は非開示
- 検証済み検出件数は2025年2月の日平均265件（単日最高500件）から2025年6月の176件へ、4か月で33.5%減少した
- 14.5時間→約1時間（93.10%削減）および年間約3,800時間の削減は、いずれも実測ではなくUberの規模を前提とした自社推計であり、中小企業がそのまま自社に当てはめてはならない
- この記事はUber社自身による発表であり、同社はPerfInsightsおよびLLMCheckの提供者本人である。すべて自社計測で第三者検証はなく、現時点で残る限界の記述もない
- 中小企業が持ち帰るべきは絶対値ではなく設計原則。「AIが下書き→別系統で検証→人が最終確認」の二段構えを、請求書チェックや図面確認など自社の検査工程に移植する形が現実的