📝 発表の要約
AIプロダクト時代において、KPI（数値指標）だけでは品質を担保できず、「Evals（自社専用の評価セット）」という第二の評価系が必要になる、という発表です。重要なのは、Evalsの本質は技術的な評価の実装ではなく、「自社にとっての良い仕事とは何か」を定義する organisational な営みだという指摘です。※本発表ではEvalsの実装方法には一切触れません。
■ Evals（Evaluations）とは
- AIの出力が自社にとって期待品質に合っているかを継続的に確かめるための「自社専用評価セット」
- AIは出力が非決定的なため、従来のテスト手法では品質が測れない → 新しい評価手法として注目されている
🧩 Evals設計で直面する「困った」の正体
事例：CS対応へのAI導入プロジェクト
問い合わせデータを大量に集め、「よい回答」のお手本を作って期待通りのAI学習・評価を実現しようとした。しかし実際に着手すると……「よい回答」の定義が人によって違う、状況依存性が高すぎてルールが書けない、線引きが暗黙知で明文化できない、「お客様のために」という漠然とした指針しかない——といった「できない理由」が次々に表面化した。
Evalsを設計しようとすると、「自社が『良い仕事』と呼んでいるものを誰も定義していなかった」ことが露呈する。
つまりEvalsの設計とは、技術導入というより組織の自己理解を深めるプロセスそのもの。
■ Evalsを作るために必要な4ステップ
- 業務を棚卸しする
- 期待値を言語化する
- ベテラン同士で合意形成する
- 例外処理・線引きを明文化する
本来やるべきだった業務定義がずっと放置されていたのが、AI導入を機にようやく進むようになった、というのが今のよくあるパターン。
■ 一度作ったら終わりではない
- 運用で想定外の失敗（変な案内でクレーム、特定ケースに弱い、例外的な依頼）が出てくるのは普通
- 失敗を都度Evalsに反映し、評価セットを進化させ続ける必要がある
- 長期的には、AIの良し悪しは「失敗を学習に変える仕組みをどれだけ持っているか」で決まる
■ エンジニア丸投げはNG
- Evals設計＝「良い仕事」の定義、AIと人の責任の線引き、例外ルール、期待値の実例化、継続的な育成
- 評価結果への対処にはエンジニアが必要だが、本質的な設計には業務理解と経営視点が必要
📉 なぜKPIではダメなのか
■ 「KPIが良いのに品質は壊れている」は昔からあった
- 営業の架電件数を追う → 形式だけの短いコールが増える
- CSの対応件数を追う → テンプレ回答ばかりの低品質対応が増える
- 開発のストーリーポイント消化を追う → こなしやすい小さいチケットばかり切られる
つまり「KPIハック」は今に始まった話ではなく、本来KPIとは別に「期待する品質のアウトプットが出ているか」を見るべきだった。しかし従来は「個人に対する信頼」が品質評価の代わりになっていた。
■ 人間にはKPIの外にブレーキがあったが、AIにはない
- 表の評価系：KPI（CVR・継続率・応答率 など）
- 裏で働いていた力：ソーシャルな歯止め（同僚の目・顧客の反応・自分のプライド・罪悪感 など）
- この裏の力があったから「KPIが良ければだいたい品質も良いだろう」が成立していたが、AIにはそのブレーキがない
■ 「KPIを精緻に設計すればいい」では不十分な理由
- 品質を数字にしようとすると、結局プロキシメトリクス（代理指標）を取ることになる
- プロキシメトリクスは必ずKPIハックの餌食になる（同じところをぐるぐる回る）
- だから「自社にとっての良い仕事」を定義し、KPIとは別系統で評価する＝Evals が必要
🚀 まずやってみてほしいこと（実践エクササイズ）
- 「良い仕事」の定義を決められる人を2人（以上）集める
- 互いに相談せず、同じ入力に対する「良い出力」をそれぞれ書き出す
- 突き合わせる → 割れたところが「未定義の場所」
割れるのは答えだけでなく、トーン・否定の仕方・踏み込み／先回りの度合い・例外対応など多岐にわたる。
うまくいかないことを「AIの問題」として諦めるか、「自分たちの言語化の問題」として向き合うか。
結局難しいのは技術的に評価をどう組み込むかではなく、「自社の自己理解の解像度をどう上げるか」だった——というのが発表の結論。