AIプロダクト、どこまで作ってから顧客に見せる？

顧客に見せるには、ログインも管理画面も、ひと通り作っておいた方がよいのではないか。AIプロダクトの試作では、そんなふうに機能が増えていきがちです。でも、今回確かめたいことが「この結果を仕事で使いたいか」なら、その全部は必要ないかもしれません。

試作の範囲は、製品の完成度ではなく、次に判断したい問いで決めます。操作を理解できるか。結果に価値があるか。実際のデータで処理が成立するか。この3つは、同じ試作でまとめて確かめる必要がありません。

「どこまで作るか」の前に、一つだけ問いを置く

たとえば、問い合わせへの回答案を作るAIを考えているとします。「便利だと思いますか」と完成イメージを見せるだけでは、返ってきた感想を次の開発へつなげにくくなります。

「担当者は、回答案と参照元を見て送信前の確認ができるか」なら、観察する操作が決まります。「回答案を用意すると、調べ直しや書き直しを含む負担が減るか」なら、必要なのは使ったあとの作業です。似た問いですが、用意するものが違います。

GOV.UKのプロトタイプガイドも、紙のスケッチから動くコードまで、その時点の目的に合う試作を選ぶ考え方を示しています。本記事ではこれを踏まえ、AIプロダクトの検証を3種類の選択肢に分けます。出典：Making prototypes

図の要点をテキストで読む

試作範囲の比較。操作確認には画面と回答例を用意し、本物のAI処理は作らない。結果の価値の確認には人が作る回答案を用意し、自動検索や送信は作らない。実データの検証にはFAQ検索から回答案までを実装し、全機能の管理画面は作らない。3つは順番ではなく選択肢であり、PMFの証明ではない。

3つは順番ではなく選択肢です。分からないことに合わせて選び直します。画像を押すと拡大できます。

操作を確かめたいなら、まず画面を試す

回答案を確認する画面なら、問い合わせ本文、回答案、参照元、修正欄を用意します。裏側で本物のAIが動いていなくても、用意した回答例を表示することで、必要な情報を見つけられるかを確かめられます。

ここで見たいのは「きれいですね」という評価ではありません。説明なしで参照元を開けるか。修正と送信の違いが分かるか。答えが出なかったときに、次にすることを理解できるか。操作をお願いし、迷った場所を記録します。

ただし、用意した回答が自然に見えても、AIの回答品質を確かめたことにはなりません。動作速度、データへの接続、本番での誤りも、この試作だけでは分かりません。

画面で確かめるのは、画面を使う行動です。裏側の能力まで、検証済みにしないことです。

結果の価値を確かめたいなら、人が裏で支えてもよい

「この回答案があれば仕事が進むか」を知りたいなら、人が資料を探し、回答案を整えて渡す試作も考えられます。検証の参加者には、人が処理に関わることと、まだ自動化されていない範囲を説明します。人が作った成果を、AIが自動生成したようには見せません。

ここでは、回答案を受け取ったあとを見ます。どこを直したか。結局どの資料を探し直したか。確認に時間がかかり、最初から書いた方がよかった部分はないか。成果物を渡すだけでなく、その後の仕事まで観察します。

この方法で手応えを得ても、同じ品質をAIが出せるとは限りません。人の判断に依存した箇所を記録しておけば、次の技術検証の対象になります。逆に、人が丁寧に作っても使われないなら、生成機能を増やす前に、困りごとの捉え方を見直せます。

実データで成立するかを確かめるなら、細くつなぐ

権限付きのFAQから必要な情報を取り出せるか。根拠がないときに保留できるか。待ち時間や処理コストは許容できるか。こうした問いには、実際に動く処理が必要です。

それでも、製品全体を作る必要はありません。「一種類の問い合わせを受け取り、許可されたFAQを検索し、参照元付きの回答案を担当者へ返す」という一連の細い経路を実装します。管理機能を広げる前に、この経路を確かめます。

実データを使うなら、試作であっても、利用許可、入力してよい情報、保存先と保持期間、閲覧権限を確認します。検証環境のアクセスを制限し、メール送信などの外部操作は必要がなければ接続しません。機能を削ることと、情報の扱いを曖昧にすることは別です。

また、試作用のコードをそのまま本番へ移せるとは限りません。認証、障害対応、負荷、監視などは別途確認が必要です。GOV.UKのガイドも、プロトタイプのコードをそのまま本番へコピーしないよう注意しています。出典：Making prototypes

作る範囲を決める、検証メモの記入例

どの試作を選んでも、問いと観察する事実を一組にします。次は「人が支える試作」を選んだ場合の架空例です。実際の顧客評価や成果の報告ではありません。

記録では、事実と解釈を分けます。「参照元を開かずに回答案を修正した」は観察です。「参照元の場所に気づかなかったのでは」は仮説です。その場の質問や次の試作で確認するまでは、理由まで決めつけません。

よい反応があっても、まだ確かめていないことがある

試してもらった人が使えたこと、繰り返し使うこと、会社が費用を払うことは、それぞれ別の判断です。利用者の好反応だけで、購入条件や継続利用まで確認できたとは扱えません。

今回分かったことと、残る問いを分ける

試作がうまく動いたことだけで、PMF（市場に受け入れられ、継続して使われる状態）を確認したとは言えません。課題・解決策・事業の検証を広く整理したい場合は、Fit Journeyを解説した記事も参考にしてください。

顧客に見せる前に、説明できる状態にする

準備できたかどうかは、機能数ではなく、今回見せるものと見せないものを説明できるかで判断します。「ここは人が作っています」「この画面は操作確認用です」「実際の送信は行いません」。その境界を伝えたうえで、確かめたい行動をお願いできれば、完成品でなくても検証を始められます。

次の一回で何を知りたいのか。その答えを得るために必要なところまで作る。増やす機能を考える前に、この一文を書いてみてください。

出典確認日：2026年9月8日。イラスト・解説図は本記事用にAI生成し、内容を確認したものです。