Maneesh Sharmaは、フルスタックのエージェント型AI品質エンジニアリング・プラットフォームをリードするTestMu AIのCOOである。
昨年、ほぼあらゆる企業が「AI機能」をリリースしたように見えた。まるで命令のようだった。ダッシュボードにCopilotを追加し、ドキュメント向けにRAG（検索拡張生成）ボットを構築し、サポートキューを自動化する、といった具合に。
だが今、エンジニアリングのリーダーと向き合い、彼らのRAGエージェントが実際に動いているのかと尋ねると、返ってくるのはデータではなく「感覚」であることが多い。「速くなった気がする」とか「要約が詳しく見える」といった話だ。
しかし、それでは取締役会の場で通用しない。出力が正確なのか、それとも自信満々にハルシネーションを起こしているだけなのかを知らないまま、推論コストに6桁ドルを投じているリスクがあると思う。多くのリーダーがスピード向上を期待している一方で、実際に影響を測定しているチームはごく一部にとどまるという、大きな「ハイプ・ギャップ」が生じている。
要するに、私たちは目隠しをしたまま飛んでいる。そして、この経済環境において目隠し飛行は墜落を意味する。
「感覚頼み」のAIエンジニアリングの問題
従来のソフトウェアでは、ユニットテストは合格か不合格かのどちらかだ。バイナリ。シンプル。入力が2+2なら出力は4である。5が返ってきたらデプロイを止める。生成AIは確率的であり、設計上、非決定的だ。同じ質問を2回すれば、おそらく2つの異なる答えが返ってくる。
この非決定性は、従来の品質保証（QA）チームを怯えさせる。どうテストすればよいかわからないからだ。そこで、手作業の抜き取りチェックに頼る。開発者が5つの出力を眺めて「いい感じだ」と言い、本番環境に投入してしまう。
私はこれを「感覚ベースのエンジニアリング」と呼んでいる。うまくいっている間はうまくいく。だが、うまくいかなくなるまでの話だ。法務ボットが存在しない判例をでっち上げたり、医療サマリーが用量をハルシネーションで捏造したりするまで。
AIの評価は、レイテンシや稼働率と同じように扱う必要があると私は考える。数値が必要だ。コスト削減のためにGPT-4からより安価なオープンソースモデルへ切り替えた結果、RAGパイプラインの精度が92%から85%へ落ちたのなら、顧客が苦情を言う前にそれを把握しなければならない。
間違えることの金銭的コスト
取締役会が気にするのは金だ。だから金の話をしよう。ハルシネーションのコストは単なる「恥」ではない。定量化可能な負債である。
重大なハルシネーション・インシデントのコストは、深刻な医療過誤の含意を伴い得る。カスタマーサービスのような低リスクの環境でさえ、ボットが1ドルでシボレー・タホを売ると約束したスクリーンショットが拡散すれば、評判管理や返金対応のコストが発生する。
私たちは「トークン対価値」の危機にも直面している。GPT-4oのような巨大モデルを、0.002ドルのファインチューニング済みLlamaモデルで十分にこなせる単純な分類タスクに使っているチームを見かける。しかし、精度をベンチマークしていないため、切り替えるのが怖いのだ。安価なモデルが「十分に良い」ことを示す指標がないため、最も高価なモデルを使い続けるという「恐怖税」を支払っている。
AI精度のベンチマークに何を使うべきか
従来の自然言語処理（NLP）指標、たとえばBLEU（翻訳に使われてきた二言語評価補助）では、ここでは役に立たない。これらは単語の重なりを測る。正解が「空は青い」で、AIが「天空は紺碧だ」と言った場合、BLEUでは失敗になる。人間なら合格だとわかる。
だからこそ、新しい「LLM-as-a-judge」フレームワークが広がっている。これが2026年の標準である。強力な「教師」モデル（Gemini 3 ProやClaude 4.5など）を使って、より小さな「生徒」モデルの宿題を採点できる。これにより、AIエージェントを具体的で実行可能な指標でスコアリングできる。
• Faithfulness（忠実性）：AIは、文脈に存在しない事実を作り出していないか。これはハルシネーションを検出する。
• Answer Relevance（回答の関連性）：ユーザーの質問に実際に答えているか。それとも丁寧に取りとめなく話しているだけか。
• Context Precision（コンテキスト精度）：検索システムはそもそも正しい文書を見つけられているか。RAGの検索が悪ければ、生成も悪くなる。
さらに、GPQA（大学院レベルのGoogle検索では解けないQ&A）やSWE-bench（ソフトウェアエンジニアリング・ベンチマーク）のような厳しいベンチマークでもテストし、限界を押し広げるべきだ。
評価のための「ゴールデンデータセット」を構築する
多くのエンジニアリングチームは、評価用データセットを見せてほしいと私が言うと固まってしまう。ベンチマークを始める前に、完璧にラベル付けされた行が何千も必要だと思い込むからだ。それは進捗を阻む神話である。「ビッグデータ」は不要だが、実データは必要だ。
私はチームに、完璧を待つのをやめ、次のワークフローでただちに「シルバーデータセット」を作り始めるよう助言している。
• 本番ログを収集する：ユーザーが完璧な英語を話すことを前提にした合成テストを書くのをやめる。ログを見に行く。直近の1,000件のクエリを引き出す。実ユーザーはタイプミスをし、スラングを使い、曖昧な質問をする。合成テストでは見落としがちなものだ。
• 摩擦でフィルタする：つまずきを探す。「低評価」ボタンを押されたクエリや、結果を得るためにボットへ3回再プロンプトしたクエリを50件抽出する。これらの「失敗モード」にROIが宿る。
• 人手で検証する：ここは省けない手作業だ。プロダクトマネジャーやシニア開発者のようなドメインエキスパートに、難しい50問それぞれの決定版となる「正解（ground truth）」を作成してもらう。
このベースラインができれば、推測は終わる。このデータセットはセーフティネットになる。プロンプト変更をマージする前や、コスト削減のためにGPT-4からより小さなLlamaモデルに切り替える前に、ゴールデンデータセットを走らせる。精度スコアが下がれば、顧客がログインする前にユーザー体験を壊したことがわかる。
精度のROIは効率である
精度は効率の指標である。社内のコーディングアシスタントが30%の確率で悪いコードを生成するなら、開発者は速くコーディングしているのではない。生成されたゴミのデバッグをしているだけだ。
エンジニアリングリーダーは、「リクエストレイテンシ」と並んで「意味的な精度（semantic accuracy）」を示すダッシュボードを要求しなければならない。特定のツールが高い精度を維持しつつテストカバレッジを55%向上させると証明できるなら、予算を正当化できる。証明できないなら、推測に過ぎない。
総じて、AIを魔法のように扱うのをやめ、ソフトウェアとして扱い始める必要がある。測定する。ベンチマークする。最適化する。
