7月13日、Jeff Gothelfが「How to Collect Product Feedback When Your AI Gives Every User a Different Answer」と題した記事を公開した。AIプロダクトにおけるフィードバック収集の根本的な問題を論じた記事で、「オーバーライド率」の計測や30〜50件の出力サンプルを分布として週次レビューする手法など、すぐに実践に移せる代替アプローチを提示している。NPSやサポートチケットといった従来手法が「記述対象が一貫している」という前提に依存しており、確率的な出力を返すAIフィーチャーとは根本的に相性が悪いという指摘は、多くのプロダクトチームに刺さる内容だ。
「再現手順」が意味をなさない世界
従来のソフトウェアでは、1件のバグレポートはすべてのユーザーの体験を代弁できた。スクリーンショットを撮り、再現手順を書けば、チームは問題を確認できた。
AIフィーチャーはその前提を二方向から壊す。同じユーザーが別の日に異なる出力を受け取り、異なるユーザーが同じ日に異なる出力を受け取る。NPS、サポートチケット、フィードバックウィジェット――これらはすべて「記述対象が一貫している」という仮定の上に成り立っている。
Jeff Gothelf自身の経験として、妻がClaudeに質問して解決策が使えなかった後、自分が同じ質問を別の言い回しで試すと全く異なる回答が返ってきた、というエピソードが紹介されている。これはペルソナ単位の差異ではなく、個人ユーザー単位の差異だ。ユーザー数が多いほど、「出荷したものが大多数に価値を届けているか」の確認は困難になる。
3つの代替手法
1. 意見ではなく「次の行動」を計測する
ユーザーがAIの出力を見た直後に何をしたか――これが最も正直なフィードバックだとGothelfは言う。
- 出力をそのまま受け入れたか
- 大幅に編集してから使ったか
- 3回クエリを打ち直したか
- コピーしたあとフローを離脱したか
これらは「修正・上書きイベント」であり、意見と違って観測・計測できる。まず1つの指標から始めることが推奨されており、例として「オーバーライド率」（AIの出力をユーザーが修正または破棄した割合）が挙げられている。オーバーライド率が高いタスク種別は、モデルの挙動やプロンプト設計に改善余地があるシグナルとして機能する。逆にオーバーライド率が低い領域は、ユーザーがAI出力をそのまま価値として受け取っている証左にもなる。
ポイントは、ユーザーが何を感じたかではなく、何をしたかを見ることだ。
2. 1件のチケットではなく、分布全体をレビューする
週1回、実際の出力から30〜50件のランダムサンプルを抽出し、チームで簡単なルーブリック（採点基準）を使ってスコアリングする。質問は3つ程度で十分だという。
- 正確か？
- ユーザーの目的に対して有用か？
- トーンは適切か？
見るべきは平均スコアではなく、分布の広がりだ。ワースト10%こそがフィードバックバックログになる。平均が高くても分布が広い場合、一部のユーザーに深刻な体験を与えている可能性がある。週次でこのサンプルレビューを続けることで、単発の悪い出力を「たまたま」として流さず、パターンとして捉え直す習慣が生まれる。
注意点として、合成テストプロンプトではなく実ユーザーの文脈を持つ実際の出力を使うことが強調されている。自分たちで作ったテストデータは、ユーザーが実際に置かれている状況より「優しい」分布になりがちだからだ。
3. 再現手順ではなく「文脈」を記録する
従来型チャンネル経由でフィードバックが届いたとき、反射的に「何をクリックしたか」を聞いてしまう。AIフィーチャーで聞くべきは、モデルが何を見ていたかだ。リクエストの内容、周辺コンテキスト、その出力が品質分布のどのあたりに位置するか。
フィードバックをこのコンテキストのクラスターでタグ付けすると、パターンが浮かび上がる。不満は均等には分布せず、特定のタスク種別に集中することが多い。「AIがたまに間違える」という曖昧な問題が、ロードマップに載せられる具体的な課題に変わる。再現手順の代わりに文脈を記録するこのアプローチは、チームがAI出力の品質劣化をユーザーの報告を待たずに能動的に把握する仕組みとしても機能する。
核心にある問いの転換
記事の締めくくりとして、Gothelfはこう問いかける。「次に誰かがAIフィーチャーへのフィードバックを持ってきたとき、それに対応する前に『ユーザーはその後何をしたか？』と聞け。誰もそれに答えられないなら、あなたはまだAIプロダクトのフィードバックを収集できていない。分布の1回の引き結果に対する意見を集めているだけだ。」
「ベンディングマシン型」（vending machine model）モデル――入力に対して固定の出力が返るという発想――はAIによって陳腐化した。フィードバック設計もそれに合わせて作り直す必要がある。なお、本記事はプロダクトマネージャーと開発チームが扱うプロダクトフィードバックループを対象としており、モデル評価パイプライン（evals）の設計とは守備範囲が異なる。evalsはモデル自体の能力を系統的に評価するための仕組みであり、本記事が扱う「ユーザーの行動から品質をモニタリングする」アプローチとは相補的な関係にある。evalsについてはLenny's Newsletterの専門解説が参考になるとされている。
詳細はHow to Collect Product Feedback When Your AI Gives Every User a Different Answerを参照していただきたい。
