ロリー・ヴォス / Laurie Voss · 17:06 「Eval を書きすぎてはいけない。 Agent が予想より賢く tool を 2 つ飛ばしたら、 prescriptive な eval は false negative を出す。 Agent はあなたが書いた eval より clever になりうる」
ロリー・ヴォス (Laurie Voss) が AI Engineer Europe 2026 の最終セッションで 2 時間にわたって解説した、 Agent Eval の hands-on workshop。 ヴォスは npm Inc の共同創業者として 2010 年代に JavaScript 業界で広く知られた人物で、 現在は Arize AI で開発者体験担当ヘッドを務める。 npm でパッケージマネジメントの evangelist だった彼が、 今 AI eval の伝道師になっている、 という業界の世代交代を体現する人物配置。
Workshop の核心メッセージは 「Eval は ML エンジニアリングの専門用語に縛られすぎている。 AI エンジニアにとって eval は「テスト」 でしかない」 という分かりやすい reframing。 これは MEMEX 既存記事の Sally-Ann Delucia (Arize) Hierarchical Memory や Amy Boyd / Nitya Narasimhan (Microsoft) Mind the Gap と同じ流れにある Observability + Eval の生産現場知識で、 単独動画として完成度が高い。
「Vibes 問題」 — 評価なしで AI を出荷する罠
ヴォスが Workshop 冒頭で提示する問題定義は具体的だ。 「多くの人が AI 機能を作って、 数件 query を叩いて 『なんか正しく見える』 で出荷する。 そして予想外の入力で失敗する。 Edge case で失敗する。 Adversarial に攻撃的な入力で失敗する。 そして最も多い失敗の仕方は、 ユーザーがあなたが想定していた以上に dumb な質問をすること」。
この最後の指摘がヴォスの実務知見の deep さを示す。 Agent failure の主因は通常考えられる adversarial attack ではなく、 「ユーザーが Agent の想定する vocabulary を知らないこと」 — Agent は専門用語を期待しているが、 ユーザーは日常語で聞く。 Production agent の信頼性問題の原典がここにある。
「 Vibes 問題 Laurie Voss が AI Engineer Europe 2026 で提示した AI eval 不在時の失敗パターン。 開発者が AI 機能を作って数件 query を試して『なんか正しく見える』 (vibes-based) で出荷した結果、 edge case / adversarial / 予想外 vocabulary で失敗する症候群。 通常の unit test では捕まらない理由は、 同じ prompt が毎回違う出力を生成し、 そのどれもが正しい可能性があるため (string match の不可能性)。 Vibes チェックから formal eval への移行が必要で、 Anthropic Claude Code チーム、 Descript、 Bolt 等の実例 の対処方法は unit test では足りない。 同じ prompt が毎回違うテキストを生成するが、 そのどれもが正しい可能性がある。 単純な string match は使えない。 結果的に多くのチームは human review に逃げるが、 これも scale しない、 regression を捕まえない、 CI で走らない、 という 3 つの欠点を抱える」 とヴォスは整理する。
具体例: 「system prompt を変えて tone の問題を直したら、 bot は確かに親切になったが、 同時に product feature を hallucinate し始めた」。 Eval なしでは tone 変更が hallucination を引き起こす副作用を捕まえられない。 これに対して「 Faithfulness eval LLM-as-judge eval の標準パターンの 1 つ。 LLM が回答時に source material (RAG で渡された文書、 system prompt 等) のみに基づいて回答しているかを判定する。 hallucination 防止の中核。 例: 顧客サポート bot が会社の docs を渡された場合、 その docs に書かれていない feature を作り出していないか、 別の LLM が判定する。 Arize の built-in eval として提供される は、 bot が source material を正しく使っているかを判定できる」 — 異なる失敗モードを別の eval で検出する戦略。
Eval の三種類 — Code / LLM-as-judge / Human
ヴォスが提示する eval の分類は実務的に重要だ。
| 種類 | 特徴 | 使いどころ | 欠点 |
|---|---|---|---|
| Code eval | 決定論的 Python / TypeScript、 ms で実行、 コスト ~0 | format validation、 length limits、 forbidden phrases、 required fields | complex / nondeterministic な出力には brittle |
| LLM-as-judge | production よりも強い LLM を judge として使う、 rubric で grading | semantic correctness、 faithfulness、 tone、 内容判定 | 時間・コスト・nondeterministic (judge 自身が間違える) |
| Human | 「gold standard」 だが scale しない | golden data set 構築、 LLM judge の meta-evaluation | 疲労で50% 程度間違える、 CI で 1 日数千回は不可能 |
ヴォスの強調: 「この 3 つは競合する approach ではなく相補的。 real eval suite は 3 つ全部を同時に使う」。 これは Vincent Koc (Comet) の Malleable Evals の主張 — 「静的ベンチマーク 1 種類では不足、 multiple 評価手段を組み合わせる」 — と整合する重要な業界 consensus。
Human annotator の 50% 間違いの指摘は痛烈だ: 「 人間評価者の疲労による失敗率 Laurie Voss が Workshop で開示した実務知見。 LLM 出力の人間評価を専業で 1 日中続けると、 疲労で約 50% の確率で間違える。 これは大規模 hyperscaler が国家規模で人員を雇用しても、 production agent の eval を人間だけでスケールさせることが構造的に不可能であることを示す。 Workshop では『Meta や Google なら小国の人口を雇えるかもしれないが、 それでもコスト的に成立しない』 と整理。 結果、 human evaluation は golden data set 構築と LLM judge の meta-evaluation に限定し、 production 評価は LLM-as-judge と code eval に任せる現代の eval architecture が確立した 。 Meta や Google が小国の人口を雇えても、 cost-effective ではない」。 だから human は golden data set 構築と LLM judge の meta-evaluation に限定、 production 評価は LLM-as-judge と code eval で回す、 という現代の eval architecture。
「Agent makes it harder」 — Cascading failures の構造
Workshop の中盤で重要な視点が登場する。 「Single LLM call の eval も難しいが、 agent はさらに難しい — cascading failures があるから」。 Agent は tool を順に呼ぶ。 各 step で正しい tool を選んだか、 正しい parameter を渡したか、 出力を正しく解釈したか、 を全て検証する必要がある。 そして multi-agent system になると、 routing LLM が正しい sub-agent を選んだか、 sub-agent 内部で何が起きたか、 戻り値が正しく上流に伝わったか、 までが eval の対象になる。
ヴォスの実例 — 「Tesla について report を書け」 と agent に頼んだとき: 「最初の research agent が 『Tesla? あー、 Nikola Tesla のことね』 と勘違いして、 18 世紀の発明家について全部調べ上げる。 そしてその情報を元に投資ケースを書いて、 上司に転送される。 これが Cascading failure Multi-step agent の失敗パターン。 初期の小さな誤判定が後続の step で増幅され、 最終出力が radically 間違うが、 各 step は internally consistent に見えるため発見が困難。 Laurie Voss の Tesla / Nikola Tesla 取り違え例が典型。 Eval architecture では、 step-level eval (各 tool call が正しいか) と end-to-end eval (最終出力が正しいか) を組み合わせることで cascading failure を捕まえる 」。 各 step は internally consistent だが、 全体として radically wrong。
最重要警告 — 「Eval を書きすぎてはいけない」
Workshop で最も MEMEX 編集視点で重要な指摘がこれだ。 多くの eval guide が見落とす point:
「Agent は逆方向にも 『予想外』 になりうる。 Eval を書く時の hazard は、 too prescriptive に書きすぎること。 『tool A を呼んで、 tool B を呼んで、 decision C を経て答えを出すべき』 という eval を書いてはいけない。 Agent はあなたより clever な方法を見つけるかもしれない。 これは特に model を upgrade した時に起きる — 新しい model は古い model がやっていたことを fewer steps でやる。 あなたの eval は too prescriptive だと壊れる」 (17:06)
これは Karpathy の Software 3.0 / Agentic Engineering での「verifiability matters」 主張と微妙に対立する論点だ。 Karpathy は「検証可能領域 (math / coding / games) で AI は速く進化する」 と主張するが、 ヴォスは「検証可能性を eval に組み込みすぎると、 Agent の clever 化を阻害する」 という反対側の警告を出している。
Workshop の実用結論: 「end-state を eval せよ、 path を eval するな」。 「Tesla の report が書けたか」 を eval して、 「tool A → B → C を経たか」 は eval しない。 後者は agent の future improvement を硬直化させる。
Capability eval → Regression eval の昇格パターン
ヴォスが提示する eval life cycle の整理も重要だ。
- Capability eval Laurie Voss が定義する eval の第 1 段階。 Agent が現時点で失敗する課題、 これから climbing する hill を意図的に提示する eval。 Agent が 100% pass するまで開発で繰り返し走らせる : agent が現在失敗する、 これから climbing する hill。 100% pass まで開発で繰り返し走らせる
- Regression eval Capability eval が 100% pass まで到達した後に、 test suite に加えられる eval。 Agent が以前できていたことを将来も continue してできるかを保証する。 新機能追加、 model upgrade、 prompt 変更で過去の能力が壊れないかをチェックする continuous monitoring の中核 : capability eval が 100% pass まで到達したら、 test suite に加えて 「以前できていたこと」 を継続的に保証する
- 反復: 新しい capability eval を追加して新しい hill を上る。 過去のは全部 regression eval として保護する
この「常に capability eval を regression eval に昇格させていく」 動的構造が、 production agent の長期信頼性の core。 Eval suite は時間とともに reactive にしか拡張されない (失敗を見て初めて eval を追加する) ことが多いが、 ヴォスの整理は proactive な eval 設計 (常に climb 中の hill を 1 つ持つ) を提案する。
Arize Phoenix — Open Source の Eval Platform
Workshop の hands-on 部分は Arize Phoenix を使う。 これは Arize の open source AI observability platform で、 enterprise 版 Arise AX とは別系統。 ヴォスは「サインアップで間違って AX に行ってしまう人がいる」 と警告するほど混同しやすいが、 Phoenix は自分の laptop でも動く完全 open source で、 trace を保存・分析する UI、 eval の実行、 experiment 機能を提供する。
技術スタック:
- OpenTelemetry (hotel) Observability の業界標準プロトコル。 Kubernetes logs から各種クラウドモニタリングまで広く使われる。 Arize Phoenix も OpenTelemetry を基盤とする。 LLM 特化の拡張として OpenInference があり、 prompt text / completion text / token counts / model name / tools invoked 等の AI 特有メタデータを標準化 : hotel と略称。 Kubernetes 等のあらゆる observability で使う標準プロトコル
- OpenInference OpenTelemetry の上に Arize / 業界各社が共同で構築した LLM 特化拡張プロトコル。 prompt text、 completion text、 token counts、 model name、 invoked tools 等の AI 特有メタデータを標準化。 全主要 LLM SDK (Anthropic / OpenAI / Gemini / 各 agent framework) に対応する instrumentation パッケージが用意されており、 2 行のコード (import + register) で全 SDK の trace 収集が始まる : hotel の LLM 特化拡張。 prompt / completion / token / model / tool calls を標準化
- 2 行で auto-instrument 開始: `phoenix.register(project_name=..., auto_instrument=True)` でほぼ全 SDK (Anthropic / OpenAI / Gemini / CrewAI / LangChain / LlamaIndex 等) の trace 収集が動き出す
ヴォスの実演 agent は「Financial analysis agent」 — stock ticker を渡すと 2 つの sub-agent (research → write report) で財務 report を作る簡単な agent。 意図的に Claude Haiku を使う: 「確実に dumb なので、 mistake を出してくれる、 eval の demo に最適」。 これも実務的な judgement で、 demo 用に reliably weak な model を選ぶ smart な設計。
LLM-as-judge の落とし穴 — Meta-evaluation の必要性
Workshop の後半は LLM judge の信頼性に踏み込む。 「LLM judge も nondeterministic で、 自身が間違える可能性がある」。 だから Meta-evaluation LLM-as-judge の judge 自身が正しく判定しているかを検証する process。 Workshop でヴォスは『eval を eval する eval』 と表現。 通常は人間が作った golden data set (known good answers) に対して LLM judge が同じ判定をするかを測る。 これによって LLM judge を deploy する前に、 その judge が本当にあなたの基準で判定しているかを確認する。 Production agent の品質保証の最後の砦 が必要 — 「eval を eval する eval」。
実装方法: human annotator (前述の 50% rule に注意しながら) で golden data set を作り、 LLM judge がその golden data set に同じ判定を下すかを測る。 LLM judge の prompt を tune して、 judge が人間の基準と合うようにする。 これは production agent の品質保証の最後の砦。
Explanation field — Actionability の鍵
ヴォスが LLM judge の独自利点として挙げるのは explanation field。 Code eval は pass / fail のみだが、 LLM judge は「なぜ fail だったか」 の説明文を返す。
実例 (Workshop で提示): User prompt 「Tokyo の budget travel recommendations を教えて」 に対して、 agent が travel recommendations を出したが具体的な cost が抜けていた場合 — LLM judge の explanation: 「Travel recommendations は提供されたが、 budget travel という要件に対して費用情報がない。 Subtle な distinction だが、 元の request の主旨に従っていない」。
これが actionable な eval を作る。 「prompt に何を追加すべきか」 のヒントが explanation から取れる。 数千 trace 規模で eval を回すと、 「同じ種類の失敗が反復される pattern」 が見え、 これが systematic な prompt の問題 (vs. 一回の confused agent) を識別する基準になる。
ただし新しい問題: 「数千 explanation を人間が読むのも疲れる」。 解決策: 第 3 の LLM を投入して explanation を category 化する。 「LLM が LLM の説明を LLM で要約する」 — Workshop の表現 「It's LLMs all the way down」 が現代の eval architecture を端的に描いている。
編集所見 — Arize 流 eval の MEMEX 的位置づけ
この Workshop が MEMEX で取り上げる価値は 3 つ:
(1) Eval の脱神秘化 — ヴォスは ML エンジニアリングの jargon (rubric、 trace、 span、 meta-evaluation) を AI engineer に向けて「これは結局テストだ」 と reframe した。 これは Arize Alex Lamb の Optimising Agents in Prod 等の他の Arize 系コンテンツと一貫した思想で、 「ML 専門家以外も eval を書ける」 democratization の中核。
(2) 「Prescriptive eval」 への警告 — Workshop の 17:06 「Agent は予想より clever になる」 という指摘は、 一見当たり前だが多くの eval guide が見落とす point。 これは Karpathy の verifiability 主張 と微妙に緊張する論点で、 「検証可能性を強く埋め込むほど Agent の柔軟性を狭める」 という設計上の trade-off を示す。 MEMEX の編集軸として、 この 2 つの視点 (検証可能性重視 vs. agent flexibility 重視) を同時に持つことが業界実情を正確に伝える。
(3) Open source platform の重要性 — Arize Phoenix が open source で laptop でも動くこと、 OpenTelemetry + OpenInference という業界標準への適合は、 「vendor lock-in なしで production agent の eval が組める」 ことを意味する。 これは Anthropic Project Glasswing や Anthropic の Enterprise 戦略 とは別軸の「Open eval infrastructure」 という方向性で、 業界全体の AI 信頼性の底上げに直結する。
Laurie Voss という人物配置自体も注目すべきだ。 npm Inc 共同創業者として 2010 年代の JavaScript ecosystem を支えた人物が、 2026 年に AI eval の伝道師になっている。 Package management の democratization (誰でも JS ライブラリを使える) から、 Eval の democratization (誰でも production AI を testable にできる) への transition は、 開発者向け infrastructure の世代交代を体現する人物 trajectory。 MEMEX として彼を 人物プロフィール に追加する候補に値する。
関連リソース
- Malleable Evals — 静的ベンチマークから適応評価へ (Vincent Koc / Comet) — 同じ eval theme の別アプローチ
- 階層メモリ・コンテキスト管理 (Sally-Ann Delucia / Arize) — 同じ Arize エコシステム
- Mind the Gap — エージェント・オブザーバビリティの全貌 (Microsoft) — Observability 横断テーマ
- Playground in Prod — エージェントを本番で最適化 (Arize) — Production agent の方法論
- バイブコーディングからエージェント工学へ — Andrej Karpathy — Verifiability の対比論点
- Arize Phoenix GitHub — Open source eval platform