Vincent Koc · 04:21 「我々の AI アプリケーションは静的ではない、 にもかかわらず、 我々は静的ソフトウェアのように扱っている」
Vincent Koc は Comet AI 開発者プラットフォーム。 LLM 評価・観測・本番運用のためのツール群を提供。 Uber / Netflix / 英国の銀行など大手企業の AI 評価ベンチマークを支援。 公式: comet.com で evaluation 研究を率いる立場。 加えて OSS coding agent harness 「 OpenCode SST が主導する OSS coding agent harness。 Claude Code に対抗するオープン版として 2026 年に登場、 タスクごとに skills を自己生成して harness 自身を進化させる構造が特徴。 Vincent Koc はコアコントリビューターの 1 人 」 のコアコントリビューター。 自分のことを 「フレンドリーな技術カナリア」 と呼び、 「2013 年 VR ゴーグルを警告 5 分のところを 3 時間使って 3 時間嘔吐した」 等の自虐エピソードで、 「先に試してから報告するスタイル」 を象徴する。
本講演の核心主張は 「evals are dead」 という業界ジョークに半分の真理がある、 という挑発的な問題提起。 静的ベンチマーク中心の評価方法は agentic AI の時代に通用しない。 解決策として提示されるのが malleable evals — agent と共に進化する live なシステムとしての評価設計。
1、 静的ソフトウェアの評価方法 (unit test / regression / CI/CD / chaos engineering) をそのまま AI に当てはめる罠 — AI アプリケーションは静的じゃないのに、 我々は静的扱いしてる。 ベンチマークも手作りのデータセットも、 毎週 production 後にどうやって更新するのか答えがない
2、 prompt engineering → context engineering → intent engineering の進化 — 2023 年の 「ランダム単語をぶち込んで効果を祈る」 段階は終わり、 2025 年は context (rag、 tool calling) で steerable に。 2026 年は intent engineering — 機械が intent に基づいて self-optimize する、 評価の側もそれに追従する必要がある
3、 80/20 ルールの adaptive 側 = 20% にこそビジネスを破壊するリスクが集中 — 80% の挙動は static eval で済む、 でも 20% の adaptive な挙動 (「変な使い方をする顧客」「想定外の質問パターン」) こそが本番事故の温床。 そこを evals が自己進化して捉える設計が必要
着眼点
「我々の AI アプリケーションは静的ではないのに、 静的ソフトウェアのように扱っている」 (04:21)
Koc が指摘する根本ミスマッチ。 「ソフトウェアを ship する時、 unit test を変えることがある、 比較的早い。 でも現実的には、 ソフトウェア自体が malleable になってる」 (05:34)。
具体例として OpenCode を挙げる: 「harness 自体が自己変化する。 skills を作りたい、 他のこともしたい — それに合わせて harness が adapt する」 (06:20)。 ソフトウェアが光速で出荷される時代に、 ベンチマークがどう keep up するのか?
「Prompt engineering は 2023 年で死んだはず、 でも今でもやってる人がいる」 (06:25 - 07:30)
Koc の挑発的な評価系譜論。 「prompt engineering — ランダムな単語を AI に叩き込んで結果が良くなることを祈る、 これは医薬品の偶然発見に近い」 (06:30)。 肝臓病の薬を作ったら痛み止めになった、 という偶然と同じ構造で、 systematic な改善経路がない。
その後 context engineering へ移行 — 「rag や tool calling で agent を steerable にできた、 評価も部分ごとに分解できた。 でもこれでも頭を打てなかった」 (07:09)。
2026 年は intent engineering — 「機械が intent に基づいて self-optimize できる、 OpenCode などの harness で実証されている」 (08:36)。 ここで評価系は新しい段階に入る — 個々のユーザー experience が全部違うので、 一律な benchmark では捉えきれない。
「80% は static で済む、 でも 20% がビジネスを破壊する」 (13:30 - 14:05)
Koc の最後のフレーミング。 「80% は static stuff、 intentful manner で定義済 — でも残り 20% は常に変わり続ける。 その 20% こそがあなたのビジネスを台無しにする。 誰かが変な質問をする、 agent を奇妙な方法で使う — そして absolute hell」 (13:30)。
解決策の方向性: 「evals を static なデータセットではなく、 code として、 ソフトウェアとして、 living agent として扱う。 ある時点のスナップショットではなく、 self-optimizing な growing solution として」 (13:59)。 self-curating eval suites from traces、 always-on optimization、 telemetry-in-the-loop による self-healing — これらが malleable eval の構成要素。
「Calcification problem」 — 評価の石灰化と Karpathy auto-research の接続
Koc が独自に名付けた 「eval calcification (評価の石灰化)」 問題。 「ペーパータイトルにしたい」 と笑いを取りつつ、 静的データセットが時間と共に硬化して、 actual な agent 挙動と乖離する現象を指す。
解決のヒントとして Karpathy の auto-research 概念を引用 — 「goal を設定 → target を設定 → 機械が自分で tune する」 (11:31)。 これを評価に応用すれば、 評価データセットや 「正解集合」 が起点ではなく、 「end state (= ユーザーが達成したい状態) こそが eval」 という反転が成立する。 evals が code に近づき、 機械が間に挟まる構造。
動画の構成
- (00:00) オープニング、 友好的カナリア、 VR 嘔吐エピソード
- (01:15) 講演者紹介、 Comet での評価業務、 大手企業の benchmark 運用
- (01:32) 「evals are dead」 という業界ジョーク、 半分の真理
- (01:53) ソフトウェアエンジニアリングの evaluation 系譜 (unit test、 regression、 CI/CD、 chaos engineering)
- (02:49) 現状の AI/DS 評価 = static benchmark + handcraft + offline eval、 chaos engineering の不在
- (04:21) 「AI アプリは静的じゃないのに、 静的扱いしてる」
- (05:00) Adaptive testing for LLM evals 論文の紹介
- (05:34) ソフトウェア自体が malleable 化、 OpenCode の自己進化
- (06:30) prompt engineering の 「ランダムワード薬学」
- (07:30) context engineering へ、 rag + tool calling で部分評価可能に
- (08:36) intent engineering、 機械が intent から self-optimize
- (09:50) intentful machine の評価困難性 — ユーザー experience がそれぞれ違う
- (10:21) eval の必要性は今こそ高まっている、 「observability is dead」 論への反論
- (11:31) intent-based outcome、 rubric / self-curating from traces / always-on / telemetry-in-the-loop の 4 構成要素
- (12:18) eval calcification problem、 Karpathy auto-research との接続
- (13:30) 80/20 ルール、 20% の adaptive がビジネスを破壊する
- (13:59) eval を living agent として扱え、 ある時点ではなく self-optimizing solution
- (14:30) クロージング、 sales pitch ではなく conceptual map として持ち帰って欲しい
出典
AI Engineer Europe 2026 公式 YouTube プレイリストより。 動画 ID は AI Engineer 公式チャネルで確認可能。
用語集
- Malleable Evals
- Vincent Koc の提唱する評価アプローチ。 静的なベンチマークではなく、 agent と共に進化する live なシステムとしての評価設計。 self-curating eval suites from traces、 always-on optimization、 telemetry-in-the-loop による self-healing、 intent-based outcome の 4 つを構成要素とする。
- eval calcification (評価の石灰化)
- Koc が独自に名付けた問題。 静的データセットが時間と共に硬化して、 actual な agent 挙動と乖離する現象。 「ペーパータイトルにしたい」 と本人が笑いを取った。
- Intent Engineering
- 2026 年の評価系譜の最新段階。 prompt engineering (2023) → context engineering (2024-25) の次。 機械が intent (ユーザーが達成したい状態) に基づいて self-optimize する。 evaluation も intent に追従して進化する必要がある。
- 80/20 problem
- Koc のフレーミング。 agent の挙動のうち 80% は static eval で十分捉えられる、 でも残り 20% の adaptive な挙動 (「変な使い方をする顧客」 「想定外の質問パターン」) こそが本番事故の温床。 この 20% を eval が自己進化して捕捉する設計が malleable eval の本質。
- OpenCode
- SST が主導する OSS coding agent harness。 Claude Code に対抗するオープン版として 2026 年に登場、 タスクごとに skills を自己生成して harness 自身を進化させる構造が特徴。 Vincent Koc はコアコントリビューターの 1 人。 講演内では 「harness 自体が malleable」 の実証例として引用。