AIの試作品を商品にするなら、機能を束ねる前に、誰が使い、誰が買い、何が減る・変わるのか、どこまでをAIと人で提供するのかを分けて決める。この整理が、最初の検証対象を選ぶ出発点です。決めるといっても、正解を確定する必要はありません。顧客に確かめられる仮説にすることを目指します。
動くものはある。社内でも試している。機能一覧やLP案も作れる。それでも誰向けの商品として売るか決まらないなら、利用者の便利さ、購入者の判断、提供する仕事の範囲が混ざっていないかを見直しましょう。新規事業の担当者も経営者も、個人で商品をつくる人も、次に必要なのは追加機能より、商品化の前提を確かめる相手と問いです。
誰が使うか — 社内実践を顧客の利用場面に置き直す
まず、手元のAIがどの作業を担っているかを書き出します。そのうえで、社外の誰が、どのような場面で同じ作業に困っていると考えるのかを言葉にしてください。「AIを活用したい企業」では、話を聞く相手も、試してもらう業務も定まりません。役割、困る場面、現在の対処まで絞ります。
社内で分かったことと、社外で確かめることを分ける
社内実践は商品化の材料になります。ただし、自社では使える情報がそろっている、開発者にすぐ聞ける、出力の直し方を知っている、といった条件がないかを確かめる必要があります。社外の利用者にも同じ準備や判断を求めるなら、それが可能かは別に検証します。
- 利用場面 — 誰が、何を始めようとしたときに困るのか。
- 現在の対処 — いまは何を使い、どこを手作業で補っているのか。
- 利用条件 — 必要な情報を用意でき、出力の内容を確認できるのか。
- 社内実践の根拠 — 実際に確認できたことと、社外でも成り立つと考えているだけのことは何か。
対象者が浮かばなければ、利用者像の具体化が次の仕事です。機能への感想を集める前に、想定する相手が最近その作業をしたときの流れを聞きましょう。困った箇所と対処の実態から、試作品を当てる場面を選びます。
誰が買うか — 利用者の評価と購入の判断を分ける
利用者が便利だと感じても、それだけで購入が決まるとは限りません。使う人と費用を負担する人、導入を決める人が同じかを確認します。個人事業主のように同じ人が担う場合も、使う立場での評価と、事業の支出としての判断を分けて聞くことはできます。
購入者を考えるときは、役職名だけで終えないことです。何のための支出として検討するのか、現在の方法から切り替える理由は何か、何が分かれば判断できるのかまで確かめます。利用者からの要望を、そのまま購入条件と扱わないようにしましょう。
- 支出の目的 — どの困りごとを解決するために、お金を使うのか。
- 比較する対象 — 現在のツールや手作業を続ける場合と、何を比べるのか。
- 判断する相手 — 誰が導入を決め、ほかに誰の確認が必要なのか。
- 必要な材料 — 判断のために、利用結果や提供範囲の何を知りたいのか。
試用への協力と、支払い意思の確認は分けて記録します。利用者が試す時間を取ってくれても、購入者が対価を払う判断まで進んだとは限りません。利用者の評価しかないなら、次は購入を判断する相手に、提案と条件を確認する段階です。
何が減る・変わるか — 機能を導入前後の違いで説明する
提供価値は、AIができる処理を並べるだけでは伝わりません。顧客がいま行っている仕事のうち、何が減り、どの状態まで進めるようになるのかを書きます。「業務を効率化する」で止めず、情報を探す手間、確認のやり直し、次の判断を待つ箇所など、対象業務で確かめられる変化に置き換えましょう。
前後の作業まで含めて比べる
AIの処理が終わっても、顧客の仕事が終わるとは限りません。入力の準備、出力の確認、修正、次の担当への受け渡しまでたどります。途中の作業だけが軽くなっても、別の箇所に負担が移っていれば、そのまま価値が出たとは判断できません。
- 導入前 — 何を用意し、どの手順で作業し、何をもって完了としているか。
- 提案する変化 — どの作業を減らし、どの判断や行動へ進めるようにしたいか。
- 残る負担 — 顧客に必要な準備、確認、修正は何か。
- 確かめる方法 — 同じ業務範囲で、現在の方法と試した後をどう比べるか。
まだ試していない変化は、期待する価値として記録します。効果を説明するために、根拠のない削減率や成果を置く必要はありません。何を観察すれば改善を判断できるかを先に決め、実際の利用で確認した範囲だけを説明してください。
ここで購入者の判断にも戻ります。利用者の負担が減ることが、その相手にとって対価を払う理由になるのか。変化は確認できても購入理由が分からないなら、機能追加の前に、解決の優先度や今の方法で足りている点を聞く必要があります。
どう提供するか — AIと人が担う範囲を決める
同じAIを使っていても、顧客が自分で操作する商品と、人が準備や確認を担って結果を届けるサービスでは、顧客に求める作業が変わります。提供形態は、利用者が使い切れるか、購入者が何に対価を払うかと合わせて考えます。
顧客が操作する場合
顧客が材料を用意し、AIを操作し、出力を確認できるかを試します。操作の説明だけで進められるのか、途中で支援が必要になるのかも観察してください。AIだけで処理する範囲を広げる場合も、判断できない入力や使えない出力を誰に戻すかは決めておきます。
人を組み合わせる場合
提供側が情報の整理、出力の確認、修正まで担うなら、その作業を商品に含める範囲として明記します。顧客に何を渡せば提供完了なのか、追加の対応はどこから必要なのかもそろえましょう。人の対応時間と費用を含め、その条件で継続して提供できるかを確かめます。
検証中に人が補った作業を、AIだけで実現できた成果として扱わないことです。誰がどこを補ったかを残せば、人を含む提供を続けるのか、自動化を検討するのか、顧客に求める条件を変えるのかを判断できます。最初から提供形態を固定せず、利用の実態に合わせて見直します。
最初の検証は、商品化を左右する未確認の点から選ぶ
ここまでの項目を、確認済みの事実と仮説に分けて並べます。そのうえで、この前提が外れたら商品としての提案を変える必要がある箇所を選びましょう。手元の試作品で見せやすい機能より、次の判断を変える問いを優先します。
- 利用場面が曖昧なら、想定する利用者に最近の作業と現在の対処を聞く。
- 買う理由が曖昧なら、購入を判断する相手に、解決の優先度と導入条件を確かめる。
- 価値が曖昧なら、業務範囲を絞って試してもらい、準備や修正を含む変化を観察する。
- 提供形態が曖昧なら、顧客と提供側の分担を決めて試し、支援が必要だった箇所を記録する。
検証前には、どの反応や行動が見られたら次へ進むかも書いておきます。想定した変化が確認できたら、購入条件など残る仮説へ進む。課題はあるが使い切れないなら、分担や提供範囲を変える。解決の優先度が低いと分かったら、今の対象への作り込みを止めて見直す。相手に会えなかった場合は未確認として扱い、需要がないという結論にはしません。
まずは、自社のAI実践について「使う人・買う人・変わること・提供形態」を書き、根拠を添えてみてください。根拠のない項目から、確かめる相手、方法、結果を受けて決めることを選ぶ。そこまで決まれば、次に必要なのが顧客への聞き取りなのか、試用なのか、提案の見直しなのかを判断できます。
商品化の前提を整理するところで迷う場合は、PROTOCOREへの相談も選択肢です。手元のAI実践と未確認の点をもとに、顧客・提供価値・提供形態から事業を考え、次に何を確かめるかを整理するところから始められます。