9月7日、Jeff Gothelfが「How to write a definition of done for an AI feature」と題した記事を公開した。「evalが通れば出荷できる」——そう判断しているチームに、Gothelfは根本的な問いを突きつける。evalはシステムの振る舞いを検証できても、ユーザーが実際に行動を変えたかどうかは一切測定しない。eval単体の「完了の定義」は、誰の役にも立たない高品質なシステムを生み出すリスクをはらんでいる。
evalはPRDではなく「完了の定義」の一部である
AIプロダクト開発の文脈で「evals are the new PRD」という言説が広まりつつある。BraintrustのAmeya BhatawdekarやMind the ProductのLisa Murkin（同題の記事）がそれぞれこのテーマで記事を公開し、OpenAIのCPO Kevin Weilも「_Writing evals is the most important thing a PM can do in the AI era._」と述べている。
ここでいうeval（エバリュエーション）とは、AIシステムの出力品質を検証するテスト群のことだ。出力が正確か、ブランドのトーンに合っているか、有害な内容を含まないかといった観点で合否を判定する。ユーザーの入力やモデルによって出力が変わるAI機能では、事前に要件を固める従来型のPRDよりも、こうしたテストベースのアプローチの方が現実的だという主張は理解できる。
しかしGothelfはここに問題を見る。evalはシステムの振る舞いを評価するものであり、ユーザーの行動変容を捉えない、と。
米スーパーマーケットチェーンAlbertsonsの例がわかりやすい。同社はAIショッピングアシスタントを導入した結果、会話型検索を使ったユーザーは支出が10%増加し、高機能版を使ったユーザーは最大26%増加したと報告している（Wall Street Journal、2026年8月）。Albertsons上級副社長のJill Pavlovichはその理由を「_買い忘れがなくなるから_」と説明している。
この「買い忘れを防ぐ」という体験こそが、ユーザーをリピーターにする本質的な価値だ。しかしevalは「在庫のある商品を返答できるか」「食事制限を考慮できるか」は検証できても、「ユーザーが買い忘れをしなくなったか」は検証できない。eval単体では、この肝心な部分が抜け落ちる。
AI機能の「完了」に付け加えるべき4つの要素
Gothelfはeval suite（evalの集合体）に以下の4点を加えることで、プロダクトとして真に「完了」と言える定義になると提案している。
許容するevalスコアの具体的な数値 「evalが通ること」ではなく、「94%以上」のように出荷に必要なスコアを明文化する。
そのAI機能が動かすべきユーザーアウトカム evalごとに、ユーザーにどんな行動変容を期待するかを1文で明記する。これがないと、evalは「うまく動くが誰の役にも立たないシステム」の品質保証になりかねない。
失敗時の責任者の明記 evalスコアやアウトカム目標を達成できなかった際に、原因を調査してモデル・UX・コンテンツのどこに問題があるかを判断する担当者を具体的に指名する。
本番データによるevalセットの更新日 evalデータセットはチームが「こう使われるだろう」と想定して作ったものだ。実際のユーザー行動データを反映してevalを更新するタイミングを事前に決めておく。
Gothelfが特に強調するのは2番目の「ユーザーアウトカムの明記」だ。残り3つはすでにevalに組み込まれていることが多いが、ユーザー視点の成果指標を入れることで初めてプロダクトとして出荷可能な「完了の定義」になる、と述べている。
evalとアウトカムは車の両輪
Albertsonsの例で整理すると、evalが担うのは「正しい商品を返す」「リストのフォーマットが正しい」「食事制限に対応する」といった出力品質の検証だ。一方、バスケットサイズの増加というビジネス上の結果を引き出しているのは、「今週の夕食に何を作るかを認識し、足りない食材を提案する」というユーザー体験の質であり、evalはこの部分を自動的には測定しない。
この構造はAlbertsonsに限った話ではない。たとえばカスタマーサポートのAI機能であれば、evalは「回答が正確か」「トーンが適切か」を検証できるが、「ユーザーが問題を自己解決できるようになったか」「再問い合わせが減ったか」はアウトカム指標として別途定義しなければ見えてこない。evalスコアが高くても、ユーザーが結局サポート担当者にエスカレーションし続けているなら、プロダクトとして「完了」とは言い難い。
evalスコアはあくまでアウトプットの指標であり、ユーザーへの価値提供を示すものではない。 両者を組み合わせることで初めて、AI機能の「完了」を正しく定義できる。Gothelfの提案は、テクニカルな品質保証とプロダクトとしての成果責任を同一のドキュメントに統合するという、シンプルだが見落とされがちな原則を改めて言語化したものだといえる。AIプロダクト開発が「とりあえずevalを書く」フェーズから「ユーザーに何をもたらすかを定義する」フェーズへ移行するうえで、参照すべき実践的な指針だ。
詳細はHow to write a definition of done for an AI featureを参照していただきたい。
