AI MVPの評価セット：ローンチ前に実際のユーザータスクで試す

AIのデモは説得力があるように見えても、顧客が本当に必要としている仕事ではうまくいかないことがあります。必須の事実が抜けた洗練された回答を返したり、結論を裏付けていない文書を引用したり、ユーザーが意図していない操作を実行したりします。テスト用のプロンプトを毎回その場で考えていると、こうした失敗はなかなか見えてきません。

初期段階のプロダクトにとって現実的な答えは、大規模なベンチマークの取り組みではありません。小さな評価セットです。実際のタスク、期待される結果、そして明確な採点ルールをバージョン管理してまとめたもので、プロンプト、モデル、検索の仕組み、ワークフローのいずれかを変えるたびに実行します。「なんとなく良くなった気がする」を、比較できる証拠に変えてくれます。

モデルではなく、仕事から始める

創業者はモデル選びから始めがちです。目に見えやすく、議論しやすいからです。しかしユーザーが買うのはモデルではなく、信頼できる結果です。プロダクトが完了させるべき仕事を、顧客が使う言葉で書き出してください。「このサポートのやり取りを引き継ぎ用にまとめて」「この契約書から更新日を抜き出して」「承認済みのナレッジベースだけを使って返信案を出して」といった具合です。

それぞれの仕事がテストケースになります。役に立つケースには、ユーザーが与える入力、システムが使ってよいコンテキスト、期待される結果、そして結果を受け入れられないものにする失敗が含まれます。こうすることで、評価は汎用的なベンチマークのスコアではなく、プロダクトの価値と結びついたままになります。

最初の20ケースを現実から作る

重要なことを学ぶのに、何百もの例は必要ありません。ディスカバリーコール、手作業でこなした仕事、顧客インタビュー、サポートチケット、使用許可を得ている文書から、15〜20のケースを集めることから始めましょう。劇的なエッジケースだけでなく、ごく普通のケースも入れてください。よくあるタスクで間違えるなら、そのプロダクトは役に立ちません。

• ハッピーパスのタスク： プロダクトがきちんとこなさなければならない、通常のリクエスト。
• 曖昧なタスク： 詳細が欠けた入力で、プロダクトが推測するのではなく質問を返すべきもの。
• 根拠づけのタスク： 与えられた情報源に忠実な回答を求めるプロンプト。
• 境界のタスク： プロダクトが拒否、エスカレーション、または人によるレビューに回さなければならないリクエスト。

顧客が気づけることを採点する

生成される出力に対して、文字列の完全一致はたいてい脆すぎます。代わりに、役に立つ結果を定義する性質を採点してください。契約書の抽出ツールなら、日付が正しいこと、根拠となる箇所が示されていること、日付が存在しない場合に不確かさが明示されていることかもしれません。サポート用のコパイロットなら、要約が顧客の問題を保っていること、でっち上げの約束をしていないこと、承認済みの次のアクションを勧めていることかもしれません。

初期には、3段階のシンプルな評価基準がうまく機能します。ユーザーがそのまま行動に移せる結果は合格、部分的に役立つ結果は要レビュー、重大な誤り、根拠のない主張、安全でない振る舞いは不合格です。合格以外の結果には、短い理由を添えてください。その理由が、そのままプロダクトのバックログになります。

品質、安全性、運用を分けて見る

1つのスコアにまとめると、ワークフローを出荷できない理由が隠れてしまうことがあります。3つの軸を別々に追いましょう。品質は、回答がタスクを解決しているかを問います。安全性は、システムが許可された振る舞いとデータの境界の内側にとどまったかを問います。運用は、ワークフローが十分に速く、事業として持続できるコストで応答しているかを問います。

この分け方によって、トレードオフが見えるようになります。大きなモデルは難しい推論タスクを改善するかもしれませんが、応答時間がプロダクト内のアシスタントとして許容できる範囲を超えてしまうかもしれません。検索の更新で関連性が上がる一方、根拠のない引用が増えることもあります。各軸を独立して扱えば、チューニングするのか、ルーティングを変えるのか、人による確認ポイントを加えるのか、機能の範囲を絞るのかを判断しやすくなります。

評価セットをリリース基準として使う

意味のある変更の前後で、同じケースを実行してください。プロンプトの書き直し、新しいモデル、システム指示の変更、検索用の新しいチャンク、エージェントの新しいツールなどです。1回の会話で最新の出力が見事に見えたからといってリリースしてはいけません。ユーザーにとって大事な結果を改善または維持し、新たな安全上の失敗を生まない変更であるときにリリースします。

1. 現在の評価セットを既存の本番構成に対して実行し、ベースラインを記録する。
2. 提案された変更を加えた状態で、同じ入力と同じ採点基準を使ってもう一度実行する。
3. すべてのリグレッションを確認する。特に、境界のタスクや根拠づけのタスクでの失敗に注意する。
4. 合意した品質、安全性、レイテンシー、コストのしきい値を満たしたときにだけ出荷する。
5. 本番で起きた代表的な失敗を評価セットに加え、実際の利用からプロダクトが学べるようにする。

小さく、バージョン管理し、生きたものに保つ

最初の評価セットは認証ではありません。規律あるプロダクトの習慣です。ケース、期待される結果、採点基準、実行結果を、機能開発の作業と同じ場所に保管してください。各ケースには担当者と、存在する理由を持たせます。顧客が意味のある失敗を見つけたら、修正する前に、それを匿名化したリグレッションテストにしてください。

AI MVPは、約束した限られた仕事で頼りになるとき、信頼に足るものになります。コンパクトな評価セットがあれば、洗練されたデモが本番での高くつく驚きに変わる前に、創業者はその信頼性を意図的に高めていくことができます。

Related Posts

LiteLLMをAIデータゲートウェイにする：顧客の機密情報をモデルに届く前に守る2026年7月15日

なぜAIは難しいのか：デモが動いた後に創業者がぶつかる本当の問題2026年7月1日

From Idea to MVP: The Complete Founder's Roadmap (2026)April 13, 2026